Mc0071 Augest 2012 Answer New

7/30/2019 Mc0071 Augest 2012 Answer New

1/35

August 2012

Master of Computer Application (MCA) Semester 3 MC0071

Software Engineering 4 Credits (Book ID: B0808 & B0809)Assignment Set 1 (60 Marks)

1. Explain Iterative Development Model in detail

ANS: The iterative enhance model counters the third limitation of the waterfall model and

tires to combinea benefit of both prototyping and the waterfall mode. The basic idea is that

the software should be developed in increments, each increment adding some functionalcapability to the system until the full system is implemented. At each step, extensions and

design modifications can be made. An advantage of this approach is that it can result in

better testing because testing each increment is likely to be easier than testing the entire

system as in the waterfall model. The increment models provide feedback to the client i.e.,

useful for determining the final requirements of the system.

In the first step of this model , a simple initial implementation is done for a subset of the overallproblem. This subset is one that contains some of the key aspects of the problem that are easy tounderstand and implement and which form a useful and usable system. A project control list is

created that contains, in order, all the tasks that must be performed to obtain the finalimplementation this project control list gives a idea of how far the project is at any given step from

the final system.Each step consists of removing the next task from the list, designing the implementation for

the selected task, coding and testing the implementation, performing an analysis of the

partial system obtained after this step, and updating the list as a result on the analysis.

These three phases are called the design phase, implementation phase and analysis phase.The process is integrated until the project control list is empty, at which time the final

implementation of the system will be available. The iterative enhancement process model is

shown in below diagram:

Iterative Development Model

The project control list guiders the iteration steps and keeps track of all tasks that must be

done. Based on the analysis, one of the tasks in the list can include redesign of defective

components or redesign of the entire system. Redesign of the system will occur only in the


2/35

initial steps. In the later steps, the design would have stabilized and there is less chance of

redesign. Each entry in the list is a task that should be performed in one step of the iterative

enhancement process and should be completely understood. Selecting tasks in this manner

will minimize the chance of error and reduce the redesign work. The design and

implementation phases of each step can be performed in a top-down manner or by using

some other technique.

One effective use of this type of model is for product development, in which the

developers themselves provide the specifications and therefore have a lot of control onwhat specifications go in the system and what stay out.In a customized software

development, where the client has to essentially provide and approve the specifications,

it is not always clear how this process can be applied. Another practical problem with

this type of development project comes in generating the business contract-how will the

cost of additional features be determined and negotiated, particularly because the client

organization is likely to e tied to the original vendor who developed the first version.Overall, in these types of projects, this process model can be useful if the "core"

Of the applications to be developed is well understood and the "increments" can be easily defined

and negotiated. in client-oriented project, this process has the major advantage that the client'sorganization does not have to pay for the entire software together, it can get the main part of the

software developed and perform cost benefit analysis for it before enhancing the software withmore capabilities.

2. Describe the Object Interface Design

ANS: Object Interface design is concerned with specifying the detail of the object interfaces. Thismeansdefining the types of the object attributes and the signatures and the semantics of the objectoperations. If an object-oriented programming language is being used for implementation, it is

natural to use it to express the interface design.Designers should avoid interfaces representation information in their interface design. Rather,the representation should be hidden and object operations provided to access and update the

data.If the representation is hidden, it can be changed without affecting the objects that usethese attributes. This leads to a design which is inherently more maintainable. For example, anarray representation of a stack may be changed to a list representation without affecting otherobjects, which use the stack.

Design Evolution

An important advantage of an object-oriented approach to design is that it simplifies the problemof making changes to the design. The reason for this is that object state representation does notinfluence the design. Changing the internal details of an object is unlikely to affect any other

system objects. Furthermore, because objects are loosely coupled, it is usually straightforward tointroduce new objects without significant effects on the rest of the system. To illustrate therobustness of the object-oriented approach, assume that pollution-monitoring capabilities are to beadded to each weather station. This involves adding an air quality meter to compute the amount ofvarious pollutants in the atmosphere. The pollution readings are transmitted at the same time as theweather data. To modify the design, the following changes must be made: Figure.below showsweather station and the new objects to the system. The abbreviation NO inAir quality stands for nitrous oxide.


3/35

Fig: New objects to support pollution monitoring

(1)An object Air quality should be introduced as part of Weather station at the same level asWeather data.

(2)An operation Transmit pollution data should be added to Weather station to send thepollution information to the central computer. The weather station control software must bemodified so that pollution readings are automatically collected when the system is switched on.

(3)Objects representing the types of pollution, which can be monitored, should be added.Levelsof nitrous oxide, smoke and benzene can be measured.

(4)A hardware control object Air quality meter should be added as a sub-object to Air quality.Thishas

attributes representing each of the types of measurement, which can be made. The addition ofpollution data collection does not affect weather data collection in any way. Datarepresentationsare encapsulated in objects so they are not affected by the additions to the design.

Function Oriented Design

A function-oriented design strategy relies on decomposing the system into a set of interactingfunctions with a centralized system state shared by these functions as shown in figure below.Functions may also maintain local state information but only for the duration of their execution.


4/35

Fig: A function-oriented view of design

Function-oriented has been practiced informally since programming began. Programs were

decomposed into subroutines, which were functional in nature. In the late 1960s and early 1970sseveral books were published which described top-down functional design. They specifically

proposed this as a structured design strategy. These led to the development of many designmethods based on functional decomposition. Function-oriented design conceals the details of an

algorithm in a function but system state information is not hidden. This can cause problems

because a function can change the state in a way, which other functions do not expect. Changes to

a function and the way in which it uses the system state may cause unanticipated changes in thebehavior of other functions. A functional approach to design is therefore most likely to be

successful when the amount of system state information is minimized and information sharing is

explicit. Systems whose responses depend on a single stimulus or input and which are not

affected by input histories are naturally functionoriented. Many transaction-processing systems

and business data-processing systems fall into this class. In essence, they are concerned withrecord processing where the processing of onerecord is not dependent on any previous processing.

3.Explain why it is important to describe software designs.

ANS:

When we're talking about software system design, we're talking about something larger thanjust a piece of software. Often software systems are large programs or systems comprised ofseveral programs and subsystems. In many cases systems of larger sizes need to be well designedin order to perform sufficiently well under heavy load. So, software system design is the practiceof extracting the needed information about what a system should do and then coming about viadesign, research and prototyping w/a way to solve the problem in a way that yields sufficientperformance w/o wasting time or resources in the process. It is excruciatingly hard, or perhapsimpossible to create a software system that works well w/o enough design.

However, one way to design systems is through prototyping, but it still isn't really possible to

come about w/a prototype that is good enough w/o understanding the actual problem wellenough. So, no matter what kind of a approach you take to solving the problem of creating a

well-working software system, you cannot live w/o design. There are just different approachesto it. The design might be very thought out, or it may emerge. But the time to think it out has to

be put in there in one way or the other.

Software is what enables us to use computer hardware effectively and is needed for our modernlife. A software designer changes people's needs into computer programmes to enable people to

meet their objectives. Most electrical items have software in them. Some don't like light bulbs.

Software is instructions to hardware to do things. A software designers design a set of

instructions so a computer will do helpful things for people. A software designer produces

computer programmes, a functional specification to agree the design with the customer and a

programme to realise the design. Software is involved with everything so software designers

work for both companies and freelance. It is very hard to find a company which doesn't have

software designers. To be a software designer maths is essential. Employers look for maths and

science skills and good communication skills. You can be a software designer without


5/35

qualifications but it is very unlikely.

Software designers plan and write computer programmes to meet functional requirements.

Software designers design the features of programmes such as the features of Microsoft word or

the features of an oven. Everything we do on the computer is a result of software design.

4. Write an overview on the Rational Unified Process.

Ans: The Rational Unified Process provides six guidelines to implement successful projects.

These sixbest practices were developed from Rationals experience while developing large and

complex systems. They were also designed to help drive the use of tools offered in Rationals

product line. The designers of the RUP continue to evolve the process as methods and practices

mature through their application [1]. The six basic principles are outlined below in figure 1.


6/35

The Rational Unified Process supports an iterative approach to development that helps inidentifying risk proactively, reducing re-factor cost, and building models with easy exit strategy.

Rational Unified Process recommends using use-cases and scenarios to capture functionality

requirements. The Rational Unified Process supports component-based software development.

Components are non-trivial modules, subsystems that fulfill a clear function. The Rational

Unified Process provides a systematic approach to defining an architecture using new and existing

components [2]. RUP encourages visual software models to depict architectures and component.

Frequent verification of quality should be reviewed with respect to the requirements based on

reliability, functionality, application performance and system


7/35

performance. Control changes to software are recommended by the process. The process describes

how to control, track and monitor changes to enable iterative development.

Per Kroll and Walker Royce updated the six best practices in IBM Rational e-zine , October

2005, as follows:

1.Adapt the process.2.Balance competing stakeholder priorities.3.Collaborate across teams.4.Demonstrate value iteratively.5.Elevate the level of abstraction.6. Focus continually on quality.Every project is different in its appeal. Complexity, size, dependent variables, distributed teamare some of the factors which impacts the project. Identifying dependent factors helps in

adjusting the process to fit it. Project size must be optimal and must be decided based on therequirement. Process must be introduced slowly in initial part of the project and it must be

implemented intensely at later parts of the project. Periodic reviews in RUP helps to identify riskproactively and continuously improve the process. Appropriation of process strength is dependent

on project size, distributed teams, complexity, stakeholders and other dependent factors. Moreformal control is required when a project meets following criteria.

Project members are distributed in different

place User community is large and

distributed.

Large projects

Many stakeholders

Defining and understanding business needs is an important aspect while implementing RUP. Key

players needs to identify the business needs and try to prioritize business and stakeholder needs.Per Kroll and Walker Royce argue strongly about having center development activities aroundstakeholder needs. Performing value analysis on leverage of assets, balancing user needs andreusing the assets are some of their suggested best practices. Collaboration across the team is wellrequired to build a high efficient team. Per Kroll and Walker Royce mentions effectivecollaboration can be obtained by

*Motivating individual on the team.*Encouraging cross functional collaboration.*Integrated collaboration across business, software and operation team.*Providing feasible environment for effective collaboration.

Iterative value based development is one of the best practice. Delivering incremental value helps

in obtaining early and continuous feedback. This early feedback helps in reducing re-factoring

cost. Per Kroll and Walker Royce argue to elevate the level of abstraction by reusing existing

assets. Reusability can be impacted by system complexity, loose coupling, and cryptic

architectures. Reusability can be obtained by having modular design, and simple architecture.

5. Describe the Capability Maturity Model.

Ans: The Capability Maturity Model developed by the Software Engineering Institute (SEI) atCarnegieMellon University is a model for identifying the organizational processes required to


8/35

ensure software process quality. The Capability Maturity Model (CMM) (see Table 3.1) is a

multistaged, process definition model intended to characterize and guide the engineeringexcellence or maturity of anorganizations software development processes. The Capability

Maturity Model: Guidelines for Improving the Software Process (1995) contains an authoritativedescription. See also Paulk etal. (1993) and Curtis, Hefley, and Miller (1995) and, for general

remarks on continuous process improvement, Somerville, Sawyer, and Viller (1999) (see Table3.2). The model prescribes practices for planning, engineering, and managing software

development and maintenance and addresses the usual goals of organizational systemengineering processes: namely, quality improvement, risk reduction, cost reduction, predictable

process, and statistical quality control(Oshana & Linger 1999)

Table 3.1:Profile of Capability Maturity Mode

Table 3.2: Profile of Process Improvement Models

However, the model is not merely a program for how to develop software in a professional,

engineering-based manner; it prescribes an evolutionary improvement path from an ad hoc,

immature process to a mature, disciplined process (Oshana & Linger 1999). Walnau, Hissam,

and Seacord (2002) observe that the ISO and CMM process standards established the context

for improving the practice of software development by identifying roles and behaviors that

define a software factory.The CMM identifies five levels of software development maturity inan organization: At level 1, the organizations software development follows no formal

development process.

The process maturity is said to be at level 2 if software management controls have beenintroduced and some software process is followed. A decisive feature of this level is that the

organizations process is supposed to be such that it can repeat the level of performance that it

achieved on similar successful past projects. This is related to a central purpose of the CMM:

namely, to improve the predictability of the development process significantly. The major

technical requirement at level 2 is incorporation of config-uration management into the process.Configuration management (or change management, as it is sometimes called) refers to theprocesses used to keep track of the changes made to the development product (including all the


9/35

intermediate deliverables) and the multifarious impacts of these changes. These impacts range

from the recognition of development problems; identification of the need for changes; alteration

of previous work; verification that agreed upon modifications have corrected the problem and that

corrections have not had a negative impact on other parts of the system; etc. An organization issaid to be at level 3 if the development process is standard and consistent. The project

management practices of the organization are supposed to have been formally agreed on, defined,

and codified at this stage of process maturity.

Organizations at level 4 are presumed to have put into place qualitative and quantitativemeasures of organizational process. These process metrics are intended to monitor developmentand to signal trouble and indicate where and how a development is going wrong when problemsoccur.

Organizations at maturity level 5 are assumed to have established mechanisms designed to

ensure continuous process improvement and optimization. The metric feedbacks at this stage are

not just applied to recognize and control problems with the current project as they were in level-4

organizations. They are intended to identify possible root causes in the process that have allowedthe problems to occur and to guide the evolution of the process so as to prevent the recurrence ofsuch problems in future projects, such as through the introduction of appropriate new technologies

and tools.The higher the CMM maturity level is, the more disciplined, stable, and well-defined thedevelopment process is expected to be and the environment is assumed to make more use of

automated tools and the experience gained from many past successes (Zhiying 2003). The

staged character of the model lets organizations progress up the maturity ladder by setting process

targets for the organization. Each advance reflects a further degree of stabilization of anorganizations development process, with each level institutionaliz[ing] a different aspect of the

process (Oshana & Linger 1999).

Each CMM level has associated key process areas (KPA) that correspond to activities that must

be formalized to attain that level. For example, the KPAs at level 2 include configurationmanagement, quality assurance, project planning and tracking, and effective management ofsubcontracted software. The KPAs at level 3 include intergroup communication, training,process definition, product engineering, and integrated software management. Quantitative

process management and development quality define the required KPAs at level 4. Level 5institutionalizes process and technology change management and optimizes defect prevention.

The CMM model is not without its critics. For example, Hamlet and Maybee (2001) object to itsoveremphasis on managerial supervision as opposed to technical focus. They observe thatagreement on the relation between the goodness of a process and the goodness of the product isby no means universal. They present an interesting critique of CMM from the point of view of

the so-called process versus product controversy. The issue is to what extent software engineers

should focus their efforts on the design of the software product being developed as opposed tothe characteristics of the software process used to develop that product.

The usual engineering approach has been to focus on the product, using relatively straightforwardprocesses, such as the standard practice embodied in the Waterfall Model, adapted to helporganize the work on developing the product. A key point of dispute is that no one has really

demonstrated whether a good process leads to a good product. Indeed, good products have been

developed with little process used, and poor products have been developed under the guidance of

a lot of purportedly good processes. Furthermore, adopting complex managerial processes to

oversee development may distract from the underlying objective of developing a superior product.

Hamlet and Maybee (2001) agree that, at the extremes of project size, there is no particularargument about the planning process to follow. They observe that for small-scale projects, the cost


10/35

of a heavy process management structure far outweighs the benefits; however, for very large-scale

projects that will develop multimillion-lines systems with long lifetimes, significant projectmanagement is clearly a necessity. However, in the midrange of projects with a few hundred

thousand lines of code, the trade-offs between the managed model of development and thetechnical model in which the management hierarchy is kept to an absolute minimum are less

obvious; indeed, the technical model may possibly be the superior and more creative approach.

Bamberger (1997), one of the authors of the Capability Maturity Model, addresses what shebelieves are some misconceptions about the model. For example, she observes that the motivation

for the second level, in which the organization must have a repeatable software process, arisesas a direct response to the historical experience of developers when their software development isout of control (Bamberger 1997). Often this is for reasons having to do with configurationmanagement or mismanagement! Among the many symptoms of configuration mismanagement

are: confusion over which version of a file is the current official one; inadvertent side effectswhen repairs by one developer obliterate the changes of another developer; inconsistencies

among the efforts of different developers; etc.

6. Describe the round-trip problem solving approach?

Ans :

Round-Trip Problem-Solving Approach:-

The software engineering process represents a round-trip framework for problem solving in a

business context in several senses.

The software engineering process is a problem-solving process entailing that software

engineering should incorporate or utilize the problem-solving literature regardless of its

interdisciplinary sources. The value of software engineering derives from its success in solving business and human

problems. This entails establishing strong relationships between the software process and the

business metrics used to evaluate business processes in general.

The software engineering process is a round-trip approach. It has a bidirectional character,which frequently requires adopting forward and reverse engineering strategies to restructure and

reengi-neer information systems. It uses feedback control loops to ensure that specifications are

accurately maintained across multiple process phases; reflective quality assurance is a critical

metric for the process in general.

The nonterminating, continuing character of the software development process is necessary torespond to ongoing changes in customer requirements and environmental pressures.

Book ID: B0808

1. Describe the following with respect to Software Design:

a. The design process

b. Design Methods

c. Design description

d. Design strategies.


11/35

Ans:

Software design is a process of problem solving and planning for a software solution. After thepurpose and specifications of software are determined, software developers will design or employ

designers to develop a plan for a solution. It includes low-level component and algorithmimplementation issues as well as the architectural view.

The software requirements analysis (SRA) step of a software development process yieldsspecifications that are used in software engineering. If the software is "semiautomated" oruser

centered, software design may involve user experience design yielding a story board to help

determine those specifications. If the software is completely automated (meaning no useroruser

interface), a software design may be as simple as a flow chart or text describing a planned

sequence of events. There are also semi-standard methods like Unified Modeling Language andFundamental modeling concepts. In either case some documentation of the plan is usually the

product of the design.

A software design may beplatform-independent orplatform-specific, depending on theavailability of the technology called for by the design.

Software design can be considered as putting solution to the problem(s) in hand using the

available capabilities. Hence the main difference between Software analysis and design is that the

output of the analysis of a software problem will be smaller problems to solve and it should notdeviate so much even if it is conducted by different team members or even by entirely different

groups. But since design depends on the capabilities, we can have different designs for the sameproblem depending on the capabilities of the environment that will host the solution (whether it is

some OS, web, mobile or even the new cloud computing paradigm). The solution will depend also

on the used development environment (Whether you build a solution from scratch or using

reliable frameworks or at least implement some suitable design patterns)

[edit] Software design topics

[edit] Design concepts

The design concepts provide the software designer with a foundation from which more

sophisticated methods can be applied. A set of fundamental design concepts has evolved. They

are:

1. Abstraction - Abstraction is the process or result of generalization by reducing theinformation content of a concept or an observable phenomenon, typically in order to retain

only information which is relevant for a particular purpose.

2. Refinement - It is the process of elaboration. A hierarchy is developed by decomposing amacroscopic statement of function in a stepwise fashion until programming language

statements are reached. In each step, one or several instructions of a given program are

decomposed into more detailed instructions. Abstraction and Refinement arecomplementary concepts.


12/35

3. Modularity - Software architecture is divided into components called modules.4. Software Architecture - It refers to the overall structure of the software and the ways in

which that structure provides conceptual integrity for a system. A good softwarearchitecture will yield a good return on investment with respect to the desired outcome of

the project, e.g. in terms of performance, quality, schedule and cost.

5. Control Hierarchy - A program structure that represents the organization of a programcomponent and implies a hierarchy of control.

6. Structural Partitioning - The program structure can be divided both horizontally andvertically. Horizontal partitions define separate branches of modular hierarchy for each

major program function. Vertical partitioning suggests that control and work should be

distributed top down in the program structure.

7. Data Structure - It is a representation of the logical relationship among individual elementsof data.

8. Software Procedure - It focuses on the processing of each modules individually9. Information Hiding - Modules should be specified and designed so that information

contained within a module is inaccessible to other modules that have no need for such

information

[edit] Design considerations

There are many aspects to consider in the design of a piece of software. The importance of each

should reflect the goals the software is trying to achieve. Some of these aspects are:

Compatibility - The software is able to operate with other products that are designed forinteroperability with another product. For example, a piece of software may be backward-

compatible with an older version of itself.

Extensibility - New capabilities can be added to the software without major changes to theunderlying architecture.

Fault-tolerance - The software is resistant to and able to recover from component failure. Maintainability - A measure of how easily bug fixes or functional modifications can be

accomplished. High maintainability can be the product of modularity and extensibility.

Modularity - the resulting software comprises well defined, independent components.That leads to better maintainability. The components could be then implemented and

tested in isolation before being integrated to form a desired software system. This allows

division of work in a software development project.

Reliability - The software is able to perform a required function under stated conditionsfor a specified period of time.

Reusability - the software is able to add further features and modification with slight or nomodification.


13/35

Robustness - The software is able to operate under stress or tolerate unpredictable orinvalid input. For example, it can be designed with a resilience to low memory conditions.

Security - The software is able to withstand hostile acts and influences. Usability - The software user interface must be usable for its target user/audience. Default

values for the parameters must be chosen so that they are a good choice for the majority ofthe users.

Software development methodology

A software development methodology orsystem development methodology in softwareengineering is a framework that is used to structure, plan, and control theprocess of developing an

information system.

[edit] History

The software development methodology (also known as SDM) framework didn't emerge until the

1960s. According to Elliott (2004) the systems development life cycle (SDLC) can be consideredto be the oldest formalized methodology frameworkfor building information systems. The main

idea of the SDLC has been "to pursue the development of information systems in a very

deliberate, structured and methodical way, requiring each stage of the life cycle from inception of

the idea to delivery of the final system, to be carried out rigidly and sequentially"[1]

within the

context of the framework being applied. The main target of this methodology framework in the

1960s was "to develop large scale functionalbusiness systems in an age of large scale businessconglomerates. Information systems activities revolved around heavy data processing and number

crunching routines".[1]

[edit] As a noun

As a noun, a software development methodology is a framework that is used to structure, plan,and control theprocess of developing an information system - this includes the pre-definition of

specific deliverables and artifacts that are created and completed by a project team to develop or

maintain an application.[2]


14/35

The three basic approaches applied to software development methodology frameworks.

A wide variety of such frameworks have evolved over the years, each with its own recognizedstrengths and weaknesses. One software development methodology framework is not necessarily

suitable for use by all projects. Each of the available methodology frameworks are best suited to

specific kinds of projects, based on various technical, organizational, project and team

considerations.[2]

These software development frameworks are often bound to some kind of organization, which

further develops, supports the use, and promotes the methodology framework. The methodology

framework is often defined in some kind of formal documentation. Specific software development

methodology frameworks (noun) include:

Rational Unified Process (RUP, IBM) since 1998. Agile Unified Process (AUP) since 2005 by Scott Ambler

[edit] As a verb

As a verb, the software development methodology is an approach used by organizations andproject teams to apply the software development methodology framework (noun). Specificsoftware development methodologies (verb) include:

1970s


15/35

Structured programming since 1969 Cap Gemini SDM, originally from PANDATA, the first English translation was published

in 1974. SDM stands for System Development Methodology

1980s

Structured systems analysis and design method (SSADM) from 1980 onwards Information Requirement Analysis/Soft systems methodology

1990s

Object-oriented programming (OOP) developed in the early 1960s, and became adominant programming approach during the mid-1990s

Rapid application development (RAD), since 1991 Dynamic systems development method (DSDM), since 1994 Scrum, since 1995 Team software process, since 1998 Extreme programming, since 1999

[edit] Verb approaches

Every software development methodology approach acts as a basis for applying specificframeworks to develop and maintain software. Several software development approaches have

been used since the origin of information technology. These are:[2]

Waterfall: a linear framework Prototyping: an iterative framework Incremental: a combined linear-iterative framework Spiral: a combined linear-iterative framework Rapid application development (RAD): an iterative framework

Extreme Programming

[edit] Waterfall development

The Waterfall model is a sequential development approach, in which development is seen as

flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design,

implementation, testing (validation), integration, and maintenance. The first formal description of

the method is often cited as an article published by Winston W. Royce[3]

in 1970 although Royce

did not use the term "waterfall" in this article.

The basic principles are:[2]


16/35

Project is divided into sequential phases, with some overlap and splashback acceptablebetween phases.

Emphasis is on planning, time schedules, target dates, budgets and implementation of anentire system at one time.

Tight control is maintained over the life of the project via extensive writtendocumentation, formal reviews, and approval/signoff by the user and information

technology management occurring at the end of most phases before beginning the next

phase.

The Waterfall model is a traditional engineering approach applied to software engineering. It hasbeen widely blamed for several large-scale government projects running over budget, over time

and sometimes failing to deliver on requirements due to the Big Design Up Front approach.

Except when contractually required, the Waterfall model has been largely superseded by more

flexible and versatile methodologies developed specifically for software development. See

Criticism of Waterfall model.

[edit] Prototyping

Software prototyping, is the development approach of activities during software development, the

creation of prototypes, i.e., incomplete versions of the software program being developed.


Not a standalone, complete development methodology, but rather an approach to handleselected parts of a larger, more traditional development methodology (i.e. incremental,

spiral, or rapid application development (RAD)).

Attempts to reduce inherent project risk by breaking a project into smaller segments andproviding more ease-of-change during the development process.

User is involved throughout the development process, which increases the likelihood ofuser acceptance of the final implementation.

Small-scale mock-ups of the system are developed following an iterative modificationprocess until the prototype evolves to meet the users requirements.

While most prototypes are developed with the expectation that they will be discarded, it ispossible in some cases to evolve from prototype to working system.

A basic understanding of the fundamental business problem is necessary to avoid solvingthe wrong problem.

[edit] Incremental development

Various methods are acceptable for combining linear and iterative systems development

methodologies, with the primary objective of each being to reduce inherent project risk by

breaking a project into smaller segments and providing more ease-of-change during thedevelopment process.


17/35


A series of mini-Waterfalls are performed, where all phases of the Waterfall are completedfor a small part of a system, before proceeding to the next increment, or

Overall requirements are defined before proceeding to evolutionary, mini-Waterfalldevelopment of individual increments of a system, or

The initial software concept, requirements analysis, and design of architecture and systemcore are defined via Waterfall, followed by iterative Prototyping, which culminates in

installing the final prototype, a working system.

[edit] Spiral development

The spiral model.

The spiral model is a software development process combining elements of both design andprototyping-in-stages, in an effort to combine advantages oftop-down and bottom-up concepts. It

is a meta-model, a model that can be used by other models.


Focus is on risk assessment and on minimizing project risk by breaking a project intosmaller segments and providing more ease-of-change during the development process, as

well as providing the opportunity to evaluate risks and weigh consideration of projectcontinuation throughout the life cycle.

"Each cycle involves a progression through the same sequence of steps, for each part of theproduct and for each of its levels of elaboration, from an overall concept-of-operation

document down to the coding of each individual program."[4]

Each trip around the spiral traverses four basic quadrants: (1) determine objectives,alternatives, and constraints of the iteration; (2) evaluate alternatives; Identify and resolve

risks; (3) develop and verify deliverables from the iteration; and (4) plan the next

iteration.[5]


18/35

Begin each cycle with an identification of stakeholders and their win conditions, and endeach cycle with review and commitment.

[6]

[edit] Rapid application development

Rapid application development (RAD) is a software development methodology, which involves

iterative development and the construction ofprototypes. Rapid application development is a termoriginally used to describe a software development process introduced by James Martin in 1991.


Key objective is for fast development and delivery of a high quality system at a relativelylow investment cost.

Attempts to reduce inherent project risk by breaking a project into smaller segments andproviding more ease-of-change during the development process.

Aims to produce high quality systems quickly, primarily via iterative Prototyping (at anystage of development), active user involvement, and computerized development tools.These tools may include Graphical User Interface (GUI) builders, Computer Aided

Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-

generation programming languages, code generators, and object-oriented techniques.

Key emphasis is on fulfilling the business need, while technological or engineeringexcellence is of lesser importance.

Project control involves prioritizing development and defining delivery deadlines ortimeboxes. If the project starts to slip, emphasis is on reducing requirements to fit thetimebox, not in increasing the deadline.

Generally includesjoint application design (JAD), where users are intensely involved insystem design, via consensus building in either structured workshops, or electronically

facilitated interaction.

Active user involvement is imperative. Iteratively produces production software, as opposed to a throwaway prototype. Produces documentation necessary to facilitate future development and maintenance. Standard systems analysis and design methods can be fitted into this framework.

[edit] Other practices

Other methodology practices include:

Object-oriented development methodologies, such as Grady Booch's object-orienteddesign (OOD), also known as object-oriented analysis and design (OOAD). The Boochmodel includes six diagrams: class, object, state transition, interaction, module, and

process.[7]


19/35

Top-down programming: evolved in the 1970s by IBM researcherHarlan Mills (andNiklaus Wirth) in developed structured programming.

Unified Process (UP) is an iterative software development methodology framework, basedon Unified Modeling Language (UML). UP organizes the development of software into

four phases, each consisting of one or more executable iterations of the software at thatstage of development: inception, elaboration, construction, and guidelines. Many tools and

products exist to facilitate UP implementation. One of the more popular versions of UP isthe Rational Unified Process (RUP).

Agile software development refers to a group of software development methodologiesbased on iterative development, where requirements and solutions evolve via collaborationbetween self-organizing cross-functional teams. The term was coined in the year 2001

when the Agile Manifesto was formulated.

[edit] Subtopics

[edit] View model

The TEAF Matrix of Views and Perspectives.

A view model is framework which provides the viewpoints on the system and its environment, tobe used in the software development process. It is a graphical representation of the underlying

semantics of a view.

The purpose of viewpoints and views is to enable human engineers to comprehend very complexsystems, and to organize the elements of the problem and the solution around domains of

expertise. In the engineering of physically intensive systems, viewpoints often correspond to

capabilities and responsibilities within the engineering organization.[8]

Most complex system specifications are so extensive that no one individual can fully comprehend

all aspects of the specifications. Furthermore, we all have different interests in a given system and

different reasons for examining the system's specifications. Abusiness executive will ask different

questions of a system make-up than would a system implementer. The concept of viewpointsframework, therefore, is to provide separate viewpoints into the specification of a given complex

system. These viewpoints each satisfy an audience with interest in some set of aspects of the


20/35

system. Associated with each viewpoint is a viewpoint language that optimizes the vocabulary and

presentation for the audience of that viewpoint.

[edit] Business process and data modelling

Graphical representation of the current state of information provides a very effective means for

presenting information to both users and system developers.

example of the interaction between business process and data models.[9]

Abusiness model illustrates the functions associated with the business process beingmodeled and the organizations that perform these functions. By depicting activities and

information flows, a foundation is created to visualize, define, understand, and validate the

nature of a process.

A data model provides the details of information to be stored, and is of primary use whenthe final product is the generation of computersoftware code for an application or the

preparation of a functional specification to aid a computer software make-or-buy decision.

See the figure on the right for an example of the interaction between business process and

data models.[9]

Usually, a model is created after conducting an interview, referred to asbusiness analysis. Theinterview consists of a facilitator asking a series of questions designed to extract required

information that describes a process. The interviewer is called a facilitator to emphasize that it isthe participants who provide the information. The facilitator should have some knowledge of the

process of interest, but this is not as important as having a structured methodology by which the

questions are asked of the process expert. The methodology is important because usually a team of

facilitators is collecting information across the facility and the results of the information from all

the interviewers must fit together once completed.[9]


21/35

The models are developed as defining either the current state of the process, in which case thefinal product is called the "as-is" snapshot model, or a collection of ideas of what the process

should contain, resulting in a "what-can-be" model. Generation of process and data models can be

used to determine if the existing processes and information systems are sound and only needminor modifications or enhancements, or if re-engineering is required as a corrective action. The

creation of business models is more than a way to view or automate your information process.

Analysis can be used to fundamentally reshape the way your business or organization conducts its

operations.[9]

[edit] Computer-aided software engineering

Computer-aided software engineering (CASE), in the field software engineering is the scientificapplication of a set of tools and methods to a software which results in high-quality, defect-free,

and maintainable software products.[10]

It also refers to methods for the development of

information systems together with automated tools that can be used in the software developmentprocess.[11]

The term "computer-aided software engineering" (CASE) can refer to the software

used for the automated development ofsystems software, i.e., computer code. The CASE

functions include analysis, design, and programming. CASE tools automate methods fordesigning, documenting, and producing structured computer code in the desiredprogramminglanguage.[12]

Two key ideas of Computer-aided Software System Engineering (CASE) are:[13]

Foster computer assistance in software development and orsoftware maintenanceprocesses, and

An engineering approach to software development and or maintenance.Typical CASE tools exist forconfiguration management, data modeling, model transformation,

refactoring, source code generation, and Unified Modeling Language.

[edit] Integrated development environment


22/35

Anjuta, a C and C++ IDE for the GNOME environment

An integrated development environment (IDE) also known as integrated design environmentorintegrated debugging environmentis a software application that provides comprehensive facilities

to computer programmers for software development. An IDE normally consists of a:

source code editor, compilerand/orinterpreter, build automation tools, and debugger(usually).

IDEs are designed to maximize programmer productivity by providing tight-knit components with

similaruser interfaces. Typically an IDE is dedicated to a specificprogramming language, so as toprovide a feature set which most closely matches theprogramming paradigms of the language.

[edit] Modeling language

A modeling language is any artificial language that can be used to express information orknowledge orsystems in a structure that is defined by a consistent set of rules. The rules are used

for interpretation of the meaning of components in the structure. A modeling language can be

graphical or textual.[14]

Graphical modeling languages use a diagram techniques with named

symbols that represent concepts and lines that connect the symbols and that represent relationships

and various other graphical annotation to represent constraints. Textual modeling languagestypically use standardised keywords accompanied by parameters to make computer-interpretableexpressions.

Example of graphical modelling languages in the field of software engineering are:

Business Process Modeling Notation (BPMN, and the XML form BPML) is an example ofaprocess modeling language.

EXPRESS and EXPRESS-G (ISO 10303-11) is an international standard general-purposedata modeling language.

Extended Enterprise Modeling Language (EEML) is commonly used for business processmodeling across layers.

Flowchart is a schematic representation of an algorithm or a stepwise process, Fundamental Modeling Concepts (FMC) modeling language for software-intensive

systems.

IDEF is a family of modeling languages, the most notable of which include IDEF0 forfunctional modeling, IDEF1X for information modeling, and IDEF5 for modelingontologies.


23/35

LePUS3 is an object-oriented visual Design Description Language and a formalspecification language that is suitable primarily for modelling large object-oriented (Java,

C++, C#) programs and design patterns.

Specification and Description Language(SDL) is a specification language targeted at theunambiguous specification and description of the behaviour of reactive and distributedsystems.

Unified Modeling Language (UML) is a general-purpose modeling language that is anindustry standard for specifying software-intensive systems. UML 2.0, the current version,

supports thirteen different diagram techniques, and has widespread tool support.

Not all modeling languages are executable, and for those that are, using them doesn't necessarily

mean that programmers are no longer needed. On the contrary, executable modeling languages are

intended to amplify the productivity of skilled programmers, so that they can address more

difficult problems, such asparallel computing and distributed systems.

[edit] Programming paradigm

Aprogramming paradigm is a fundamental style ofcomputer programming, in contrast to asoftware engineering methodology, which is a style of solving specific software engineering

problems. Paradigms differ in the concepts and abstractions used to represent the elements of a

program (such as objects, functions, variables, constraints...) and the steps that compose a

computation (assignation, evaluation, continuations, data flows...).

Aprogramming language can support multiple paradigms. For example programs written in C++

orObject Pascal can be purelyprocedural, or purely object-oriented, or contain elements of both

paradigms. Software designers and programmers decide how to use those paradigm elements. In

object-oriented programming, programmers can think of a program as a collection of interacting

objects, while in functional programming a program can be thought of as a sequence of stateless

function evaluations. When programming computers or systems with many processors,process-oriented programming allows programmers to think about applications as sets of concurrent

processes acting upon logically shared data structures.

Just as different groups in software engineering advocate different methodologies, differentprogramming languages advocate differentprogramming paradigms. Some languages are

designed to support one paradigm (Smalltalksupports object-oriented programming, Haskell

supports functional programming), while other programming languages support multiple

paradigms (such as Object Pascal, C++, C#, Visual Basic, Common Lisp, Scheme, Python, Ruby,and Oz).

Many programming paradigms are as well known for what methods theyforbidas for what they

enable. For instance, pure functional programming forbids using side-effects; structured

programming forbids using goto statements. Partly for this reason, new paradigms are often

regarded as doctrinaire or overly rigid by those accustomed to earlier styles.[citation needed]

Avoidingcertain methods can make it easier to prove theorems about a program's correctness, or simply to

understand its behavior


24/35

2. Describe the following with respect to Software Testing:

a. Control Structure Testing

b. Black Box Testing

c. Boundary Value Analysisd. Testing GUIs

e. Testing Documentation and Help Facilities

Ans:

(a) Control Structure testing:

Within an imperative programming language, a control flow statement is a statement whose

execution results in a choice being made as to which of two or more paths should be followed. For

non-strict functional languages, functions and language constructs exist to achieve the same result,

but they are not necessarily called control flow statements. Control structure testing is a group of

white-box testing methods.

1.0 Branch Testing 1.1 Condition Testing 1.2 Data Flow Testing 1.3 Loop Testing1.0 Branch Testing:

This is also called Decision Testing. "For every decision, each branch needs to be executed at leastonce." shortcoming - ignores implicit paths that result from compound conditionals. Treats a

compound conditional as a single statement. (We count each branch taken out of the decision,

regardless which condition lead to the branch.)

This example has two branches to be executed:IF ( a equals b) THEN

statement 1

ELSE

statement 2END IF

This examples also has just two branches to be executed, despite the compoundconditional:IF ( a equals b AND c less than d ) THEN

statement 1

ELSE

statement 2END IF

This example has three branches to be executed:IF ( a equals b) THEN

statement 1

ELSEIF ( c equals d) THEN

statement 2

ELSE

statement 3


25/35

END IF

END IF

Obvious decision statements are if, for, while, switch. Subtle decisions are return (booleanexpression), ternary expressions, try-catch. For this course you don't need to write test cases for

IOException and OutOfMemory exception.

1.1 Condition Testing:

Condition testing is a test construction method that focuses on exercising the logical conditions in

a program module.

Errors in conditions can be due to:

Boolean operator error Boolean variable error Boolean parenthesis error Relational operator error Arithmetic expression error

definition: "For a compound condition C, the true and false branches of C and every simplecondition in Cneed to be executed at least once."Multiple-condition testing requires that all true-false combinationsof simple conditions beexercised at least once. Therefore, all statements, branches, and conditions are necessarily

covered.

1.2 Data Flow Testing:

Selects test paths according to the location of definitions and use of variables. This is a somewhatsophisticated technique and is not practical for extensive use. Its use should be targeted to

modules with nested if and loop statements.

1.3 Loop Testing:

Loops are fundamental to many algorithms and need thorough testing.

There are four different classes of loops: simple, concatenated, nested, and unstructured.

(b) Black Box Testing:

Black box testing takes an external perspective of the test object to derive test cases. These tests

can be functional or non-functional, though usually functional. The test designer selects valid and

invalid inputs and determines the correct output. There is no knowledge of the test object's internalstructure.

This method of test design is applicable to all levels of software testing: unit, integration,functional testing, system and acceptance. The higher the level, and hence the bigger and more

complex the box, the more one is forced to use black box testing to simplify. While this method

can uncover unimplemented parts of the specification, one cannot be sure that all existent paths

are tested also known as functional testing. A software testing technique whereby the internal

workings of the item being tested are not known by the tester. For example, in a black box test on


26/35

a software design the tester only knows the inputs and what the expected outcomes should be and

not how the program arrives at those outputs. The tester does not ever examine the programming

code and does not need any further knowledge of the program other than its specifications.

The advantages of this type of testing include:

The test is unbiased because the designer and the tester are independent of each other.

The tester does not need knowledge of any specific programming languages.

The test is done from the point of view of the user, not the designer.

Test cases can be designed as soon as the specifications are complete.

The disadvantages of this type of testing include:

The test can be redundant if the software designer has already run a test case.

The test cases are difficult to design.

Testing every possible input stream is unrealistic because it would take a inordinate amount of

time; therefore, many program paths will go untested.

(c) Boundary Value Analysis:

Boundary value analysis is a software testing design technique in which tests are designed toinclude representatives of boundary values. Values on the edge of an equivalence partition or at

the smallest value on either side of an edge. The values could be either input or output ranges of asoftware component. Since these boundaries are common locations for errors that result in

software faults they are frequently exercised in test cases.

For an example where the input values were months of the year expressed as integers, the input

parameter 'month' might have the following partitions:

The boundaries are the values on and around the beginning and end of a partition. If possible test

cases should be created to generate inputs or outputs that will fall on and to either side of each

boundary. This would result in three cases per boundary. The test cases on each side of a

boundary should be in the smallest increment possible for the component under test. In the

example above there are boundary values at 0,1,2 and 11,12,13. If the input values were definedas decimal datatype with 2 decimal places then the smallest increment would be the 0.01.

Where a boundary value falls within the invalid partition the test case is designed to ensure thesoftware component handles the value in a controlled manner.Boundary value analysis can be

used throughout the testing cycle and is equally applicable at all testing phases.

After determining the necessary test cases with equivalence partitioning and subsequent boundary

value analysis, it is necessary to define the combinations of the test cases when there are multiple

inputs to a software component.

(d) Testing GUIs:

GUI testing is an area of growing importance, facing a number of severe challenges. A fewmethods have been proposed for GUI testing. However it is still not clear how to define GUI test

cases and how many actions should be comprised of a GUI test case. In this paper we propose an

approach that defines GUI test cases as a sequence of primitive GUI actions and treats GUI test

suites as an inner hierarchy of formal language. This is not only theoretically solid but alsopractically convenient. The dimension of a GUI test suite and the order of a GUI test case can be


27/35

defined uniquely. A convenient procedure is available that generates higher-order test cases from

lower-order test cases. Three testing experiments with a real-world Internet browser reveal that

second-order test cases may significantly outperform first-order test cases in GUI testing and

should be generated to perform particular GUI functions. In addition, the number of actionsapplied during testing should be used to replace the number of tests performed during testing to

evaluate the effectiveness of GUI testing processes

GUI testing is an area of growing importance, facing a number of severe challenges. A fewmethods have been proposed for GUI testing. However it is still not clear how to define GUI test

cases and how many actions should be comprised of a GUI test case. In this paper we propose an

approach that defines GUI test cases as a sequence of primitive GUI actions and treats GUI test

suites as an inner hierarchy of formal language. This is not only theoretically solid but alsopractically convenient. The dimension of a GUI test suite and the order of a GUI test case can be

defined uniquely. A convenient procedure is available that generates higher-order test cases from

lower-order test cases. Three testing experiments with a real-world Internet browser reveal thatsecond-order test cases may significantly outperform first-order test cases in GUI testing and

should be generated to perform particular GUI functions. In addition, the number of actionsapplied during testing should be used to replace the number of tests performed during testing to

evaluate the effectiveness of GUI testing processes. This paper provides a potential link between

formal language theory and GUI testing.

(e) Testing Documentation and Help Facilities:

Manual testing is the process of manually testing software for defects. It requires a tester to play

the role of an end user, and use most of all features of the application to ensure correct behavior.

To ensure completeness of testing, the tester often follows a written test plan that leads them

through a set of important test cases.

For small scale engineering efforts (including prototypes), exploratory testing may be sufficient.

With this informal approach, the tester does not follow any rigorous testing procedure, but rather

explores the user interface of the application using as many of its features as possible, usinginformation gained in prior tests to intuitively derive additional tests. The success of exploratory

manual testing relies heavily on the domain expertise of the tester, because a lack of knowledge

will lead to incompleteness in testing. One of the key advantages of an informal approach is to

gain an intuitive insight to how it feels to use the application. Large scale engineering projects that

rely on manual software testing follow a more rigorous methodology in order to maximize thenumber of defects that can be found.

A systematic approach focuses on predetermined test cases and generally involves the following

steps.1.Choosea high level test plan where a general methodology is chosen, and resources such as

people, computers, and software licenses are identified and acquired.

2.Writedetailed test cases, identifying clear and concise steps to be taken by the tester, withexpected outcomes.

3.Assignthe test cases to testers, who manually follow the steps and record the results.

4.Authora test report, detailing the findings of the testers. The report is used by managers to

determine whether the software can be released, and if not, it is used by engineers to identify andcorrect the problems.


28/35

A rigorous test case based approach is often traditional for large software engineering projects thatfollow a Waterfall model.

3. Draw possible data flow diagram of system design for the following

application. Part of the electronic mail system which presents a mail form to

a user, accepts the completed form and sends it to the identified destination.

Ans:

Data Flow Diagrams:Because data is important for the effective functioning of an enterprise, the creation of data flowdiagrams to organise the ever-increasing amounts of data an enterprise generates is of great use

and offers a number of resulting benefits. It has been said that one picture can tell a thousandwords and so a data flow diagram can be described as the graphical overview of an enterprise,

giving a broader understanding of what is happening within an enterprise as a result. Functioning

in similar ways to statistical analysis, a data flow diagram can ultimately guide an enterprise to

greater success by identifying problem areas which can consequently be fixed and aid in further

improving business development.

Flow diagrams can be further defined as interface design diagrams containing elements of systemanalysis and design. Because planning is a vital part of the creation and development of websites

through the interface design process, plans can be visualized at best in the form of a diagram.Interface design diagrams are called many things but are more frequently described as:

Structure Diagrams (or Sitemaps): these are abstracted representations of the content

organisation and navigation on a website, providing a bigger picture of the information space. All

content on a a website is presented in these diagrams.

Process Flow Diagrams: these are specifically flow diagrams and allow for workflow analysis tobe accurately carried out. Actions within a website and the options available for users to perform

certain actions are represented. Diagrams showing how users move through content laid out.

Wireframes: functioning as graphical inventories of information, navigation and interactive

website elements, they represent information and functionality required to support users. They are

combined with flow diagrams to illustrate a process with relevant screen layouts.

Architecture Diagrams: diagrams illustrating the technical construction of the website withconcerns to how and where a back-end system interacts with a front-end interface.

Book ID: B0809

1. What are the main characteristics of successful teams?

Ans:


29/35

useful to have a structure to follow to make sure that nothing is overlooked. Nothing here is likelyto be brand new to anyone, but it is the pure acknowledgement and reminding of the process that

can help the problems to be solved.

1. Problem Definition

The normal process for solving a problem will initially involve defining the problem you want tosolve. You need to decide what you want achieve and write it down. Often people keep the

problem in their head as a vague idea and can so often get lost in what they are trying to solve that

no solution seems to fit. Merely writing down the problem forces you to think about what you are

actually trying to solve and how much you want to achieve. The first part of the process not onlyinvolves writing down the problem to solve, but also checking that you are answering the right

problem. It is a check-step to ensure that you do not answer a side issue or only solve the part of

the problem that is most easy to solve. People often use the most immediate solution to the first

problem definition that they find without spending time checking the problem is the right one to

answer.

2. Problem Analysis

The next step in the process is often to check where we are, what is the current situation and what

is involved in making it a problem. For example, what are the benefits of the current

product/service/process? And why did we decide to make it like that? Understanding where the

problem is coming from, how it fits in with current developments and what the current

environment is, is crucial when working out whether a solution will actually work or not.Similarly you must have a set of criteria by which to evaluate any new solutions or you will not

know whether the idea is workable or not. This section of the problem solving process ensures

that time is spent in stepping back and assessing the current situation and what actually needs to

be changed.

After this investigation, it is often good to go back one step to reconfirm that your problem

definition is still valid. Frequently after the investigation people discover that the problem they

really want to answer is very different from their original interpretation of it.

3. Generating possible Solutions

When you have discovered the real problem that you want to solve and have investigated the

climate into which the solution must fit, the next stage is to generate a number of possible

solutions. At this stage you should concentrate on generating many solutions and should notevaluate them at all. Very often an idea, which would have been discarded immediately, when

evaluated properly, can be developed into a superb solution. At this stage, you should not pre-

judge any potential solutions but should treat each idea as a new idea in its own right and worthyof consideration.

4. Analyzing the Solutions

This section of the problem solving process is where you investigate the various factors abouteach of the potential solutions. You note down the good and bad points and other things which are

relevant to each solution. Even at this stage you are not evaluating the solution because if you do

so then you could decide not to write down the valid good points about it because overall youthink it will not work. However you might discover that by writing down its advantages that it has

a totally unique advantage. Only by discovering this might you choose to put the effort in to

develop the idea so that it will work.


30/35

5. Selecting the best Solution(s)

This is the section where you look through the various influencing factors for each possible

solution and decide which solutions to keep and which to disregard. You look at the solution as awhole and use your judgments as to whether to use the solution or not. In Innovation Toolbox,

you can vote using either a Yes/No/Interesting process or on a sliding scale depending on howgood the idea is. Sometimes pure facts and figures dictate which ideas will work and which will

not. In other situations, it will be purely feelings and intuition that decides. Remember thatintuition is really a lifetimes experience and judgments compressed into a single decision.

6. Planning the next course of action (Next Steps)

This section of the process is where you write down what you are going to do next. Now that you

have a potential solution or solutions you need to decide how you will make the solution happen.

This will involve people doing various things at various times in the future and then confirming

that they have been carried out as planned. This stage ensures that the valuable thinking that has

gone into solving the problem becomes reality. This series of Next Steps is the logical step tophysically solving the problem.

6. Describe Classic Invalid assumptions in the context of Process Life Cyclemodels.

Ans:

Classic Invalid Assumptions:-Four unspoken assumptions that have played an important role in the history of softwaredevelopment are considered next.

First Assumption: Internal or External Drivers: The first unspoken assumption is that softwareproblems are primarily driven by internal software factors. Granted this supposition, the focus of

problem solving will necessarily be narrowed to the software context, thereby reducing the role of

people, money, knowledge, etc. in terms of their potential to influence the solution of problems.

Excluding the people factor reduces the impact of disciplines such as management (people as

managers); marketing (people as customers); and psychology (people as perceivers). Excludingthe money factor reduces the impact of disciplines such as economics (software in terms of

business value cost and benefit); financial management (software in terms of risk and return); and

portfolio management (software in terms of options and alternatives). Excluding the knowledge

factor reduces the impact of engineering; social studies; politics; language arts; communicationsciences; mathematics; statistics; and application area knowledge (accounting, manufacturing,

World Wide Web, government, etc).

It has even been argued that the entire discipline of software engineering emerged as a reactionagainst this assumption and represented an attempt to view software development from a broader

perspective. Examples range from the emergence of requirements engineering to the spiral model

to humancomputer interaction (HCI). Nonetheless, these developments still viewed non-software-focused factors such as ancillary or external drivers and failed to place software


31/35

development in a comprehensive, interdisciplinary context. Because software development prob-

lems are highly interdisciplinary in nature, they can only be understood using interdisciplinary

analysis and capabilities. In fact, no purely technical software problems or products exist because

every software product is a result of multiple factors related to people, money, knowledge, etc.,rather than only to technology.

Second Assumption: Software or Business Processes:A second significant unspoken

assumption has been that the software development process is independent of the businessprocesses in organizations. This assumption implied that it was possible to develop a successful

software product independently of the business environment or the business goals of a firm. Thisled most organizations and business firms to separate software development work, people,

architecture, and planning from business processes. This separation not only isolated the software-

related activities, but also led to different goals, backgrounds, configurations, etc. for software as

opposed to business processes. As a consequence, software processes tended to be driven by their

internal purposes, which were limited to product functionality and not to product effectiveness.

This narrow approach had various negative side effects on software development. For example,

the software process was allowed to be virtually business free. Once the product was finalized, itwas tested and validated only for functionality, as opposed to being verified for conformity tostakeholder goals. As a result, even if the product did not effectively solve the underlying business

problems or create a quantifiable business value for the organization, it could still pass its test.

Because software development was not synchronized with the business process, software

problems could be solved without actually solving business problems.

Third Assumption: Processes or Projects: A third unspoken assumption was that the software

project was separate from the software process. Thus, a software process was understood as

reflecting an area of computer science concern, but a software project was understood as abusiness school interest. If one were a computer science specialist, one would view a qualitysoftware product as the outcome of a development process that involved the use of good algo-

rithms, data base deign, and code. If one were an MIS specialist, one would view a successful

software system as the result of effective software economics and software management.

This dichotomy ignored the fact that the final product was identical regardless of who produced itor how it was produced. The assumption reinforced the unwise isolation of project management

from the software development process, thus increasing the likelihood of product failure. In

contrast to this assumption, interdisciplinary thinking combines the process with the project;

computer science with the MIS approach; and software economics with software design and

implementation in a unified approach. Just as in the case of the earlier assumptions, thisassumption overlooks the role of business in the software development process.

Fourth Assumption: Process Centered or Architecture Centered: There are currently two

broad approaches in software engineering; one is process centered and the other is architecturecentered. In process-centered software engineering, the quality of the product is seen as emergingfrom the quality of the process. This approach reflects the concerns and interests of industrial

engineering, management, and standardized or systematic quality assurance approaches such as

the Capability Maturity Model and ISO. The viewpoint is that obtaining quality in a product

requires adopting and implementing a correct problem-solving approach. If a product contains an


32/35

error, one should be able to attribute and trace it to an error that occurred somewhere during the

application of the process by carefully examining each phase or step in the process.

In contrast, in architecture-centered software engineering, the quality of the software product isviewed as determined by the characteristics of the software design. Studies have shown that 60 to

70 percent of the faults detected in software projects are specification or design faults. Becausethese faults constitute such a large percentage of all faults within the final product, it is critical to

implement design-quality metrics. Implementing design-quality assurance in software systems andadopting proper design metrics have become key to the development process because of their

potential to provide timely feedback. This allows developers to reduce costs and developmenttime by ensuring that the correct measurements are taken from the very beginning of the project

before actual coding commences. Decisions about the architecture of the design have a major

impact on the behavior of the resulting software particularly the extent of development required;

reliability; reusability; understandability; modi-fiability; and maintainability of the final product,

characteristics that play a key role in assessing overall design quality.

However, an architecture-centered approach has several drawbacks. In the first place, one only

arrives at the design phase after a systematic process. The act or product of design is not just amodel or design architecture or pattern, but a solution to a problem that must be at leastreasonably well defined. For example, establishing a functional design can be done by defining

architectural structure charts, which in turn are based on previously determined data flow

diagrams, after which a transformational or transitional method can be used to convert the data

flow diagrams into structure charts. The data flow diagrams are outcomes of requirements analysis

process based on a preliminary inspection of project feasibility. Similarly, designing object-oriented architectures in UML requires first building use-case scenarios and static object models

prior to moving to the design phase.A further point is that the design phase is a process involving architectural, interface, component,data structure, and database design (logical and physical). The design phase cannot be validated or

verified without correlating or matching its outputs to the inputs of the software development

process. Without a process design, one could end up building a model, pattern, or architecture that

was irrelevant or at least ambivalent because of the lack of metrics for evaluating whether thedesign was adequate. In a comprehensive process model, such metrics are extracted from

predesign and postdesign phases. Finally, a process is not merely a set of documents, but aproblem-solving strategy encompassing every step needed to achieve a reliable software product

that creates business value. A process has no value unless it designs quality solutions.

6. Describe the following:

a. Importance of people in problem solving process

b. Human driven software engineering

Ans:

a. Importance of people in problem solving process


33/35

It is useful to have a structure to follow to make sure that nothing is overlooked. Nothing here islikely to be brand new to anyone, but it is the pure acknowledgement and reminding of the process

that can help the problems to be solved.

1. Problem Definition

The normal process for solving a problem will initially involve defining the problem you want tosolve. You need to decide what you want achieve and write it down. Often people keep the

problem in their head as a vague idea and can so often get lost in what they are trying to solve that

no solution seems to fit. Merely writing down the problem forces you to think about what you are

actually trying to solve and how much you want to achieve. The first part of the process not onlyinvolves writing down the problem to solve, but also checking that you are answering the right

problem. It is a check-step to ensure that you do not answer a side issue or only solve the part of

the problem that is most easy to solve. People often use the most immediate solution to the first

problem definition that they find without spending time checking the problem is the right one to

answer.

2. Problem Analysis

The next step in the process is often to check where we are, what is the current situation and what

is involved in making it a problem. For example, what are the benefits of the current

product/service/process? And why did we decide to make it like that? Understanding where the

problem is coming from, how it fits in with current developments and what the current

environment is, is crucial when working out whether a solution will actually work or not.Similarly you must have a set of criteria by which to evaluate any new solutions or you will not

know whether the idea is workable or not. This section of the problem solving process ensures

that time is spent in stepping back and assessing the current situation and what actually needs to

be changed.

After this investigation, it is often good to go back one step to reconfirm that your problem

definition is still valid. Frequently after the investigation people discover that the problem they

really want to answer is very different from their original interpretation of it.

3. Generating possible Solutions

When you have discovered the real problem that you want to solve and have investigated the

climate into which the solution must fit, the next stage is to generate a number of possible

solutions. At this stage you should concentrate on generating many solutions and should notevaluate them at all. Very often an idea, which would have been discarded immediately, when

evaluated properly, can be developed into a superb solution. At this stage, you should not pre-

judge any potential solutions but should treat each idea as a new idea in its own right and worthyof consideration.

4. Analyzing the Solutions

This section of the problem solving process is where you investigate the various factors abouteach of the potential solutions. You note down the good and bad points and other things which are

relevant to each solution. Even at this stage you are not evaluating the solution because if you do

so then you could decide not to write down the valid good points about it because overall youthink it will not work. However you might discover that by writing down its advantages that it has

a totally unique advantage. Only by discovering this might you choose to put the effort in to

develop the idea so that it will work.


34/35

5. Selecting the best Solution(s)

This is the section where you look through the various influencing factors for each possible

solution and decide which solutions to keep and which to disregard. You look at the solution as awhole and use your judgments as to whether to use the solution or not. In Innovation Toolbox,

you can vote using either a Yes/No/Interesting process or on a sliding scale depending on howgood the idea is. Sometimes pure facts and figures dictate which ideas will work and which will

not. In other situations, it will be purely feelings and intuition that decides. Remember thatintuition is really a lifetimes experience and judgments compressed into a single decision.

6. Planning the next course of action (Next Steps)

This section of the process is where you write down what you are going to do next. Now that you

have a potential solution or solutions you need to decide how you will make t

Mc0071 Augest 2012 Answer New

Documents