Post on 04-Apr-2018
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
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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]
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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]
7/30/2019 Mc0071 Augest 2012 Answer New
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.
The basic principles are:[2]
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.
7/30/2019 Mc0071 Augest 2012 Answer New
17/35
The basic principles are:[2]
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.
The basic principles are:[2]
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]
7/30/2019 Mc0071 Augest 2012 Answer New
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.
The basic principles are:[2]
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]
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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]
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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:
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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
7/30/2019 Mc0071 Augest 2012 Answer New
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.
7/30/2019 Mc0071 Augest 2012 Answer New
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