Chapter 1:Introduction to Software Engineering and Software Process Models

This chapter contains the following:

1.1 Introduction
1.2 CMM Levels
1.3 Engineering Goals
1.4 Software process Models
1.4.1 Classic life cycle model
1.4.2 Prototype model
1.4.3 Spiral model
1.4.4 Component assembly model
1.4.5 RAD model
1.4.6 Incremental model
1.4.7 Win- Win Spiral Model
1.4.8 Fourth generation techniques
University Questions

Software Engineering By. Dr. Sharmila Rathod

 1.1 Introduction

In all industrialized countries, and increasingly in developing countries, computer

systems are economically critical. More and more fields such as education, health care and
administration are dependant on computer systems. The software in these systems represents a
large proportion of the total system costs. The effective functioning of modern economic and
political systems is therefore dependant on our ability to produce software in a cost-effective way.
Software engineering is concerned with the theories, methods and tools that are needed to
develop the software for these systems. Software engineers model parts of the real world in
software. These models are large, abstract and complex and so must be documented well in
system designs, user manuals and so on. Documentation is as much a part of the software
engineering process as programming. Thus, software engineering is also concerned with evolving
these models to meet changing needs and requirements.
What is Software?
Software is 1. Instructions (Computer program) that when executed provide desired
features, functions, and performance, 2. data structure that enable the program to adequately
manipulate information and 3. documents that describes the operation and use of the programs.

Software is a logical rather than physical elements and has following characteristics
1. Software is developed or engineered; it is not manufactured.
Both Software development and hardware manufacturing dependent on people but the
relationship between people applied and work accomplished is entirely different.
2. Software does not wear out.

3. Most software are custom built.

Typical formal definitions of software engineering are

 Software engineering is the application of a systematic, disciplined, quantifiable

approach to the development, operation, and maintenance of software. It encompasses techniques
and procedures, often regulated by a software development process, with the purpose of
improving the reliability and maintainability of software systems. The effort is necessitated by the
potential complexity of those systems, which may contain millions of lines of code.

2
 "The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software".
 "An engineering discipline that is concerned with all aspects of software production"
 "The establishment and use of sound engineering principles in order to economically
obtain software that is reliable and works efficiently on real machines

The software process is the set of activities and associated results, which produce a
software product. Software engineers mostly carry out these activities. There are four
fundamental activities that are common to all software processes. They are:
Software specification: The functionality of the software and constraints on its operation must
be defined.
Software development: The software to meet the specifications must be developed.
Software validation: The software must be verified to ensure that it does what the specs
requested.
Software evolution: The software must adapt to the growing needs of the customer.
There is no such thing as a right or wrong process. Different software processes
decompose these activities in different ways. The timing and results of these activities vary.
However, some processes are more suited to a particular type of application. Use of the wrong
process may affect the quality of the final application. Software process models are still the
subject of research, but a number of general models exist. The following sections deal with a few
of the prevalent models of software development.

1.2 Capability Maturity Model:

The CMMI is a process meta-model developed by the Software Engineering Institute

(SEI). It defines the process characteristics that should exist if an organization wants to establish
a software process that is complete. The spirit of the CMMI should always be adopted. It argues
that software development.
(i) must be taken seriously
(ii) It must be thoroughly
(iii) It must be controlled uniformly
(iv) It must be tracked accurately.
(v) It must be conducted professionally.
(vi) It must focus on the needs of it’s customers

3
 The CMMI presents two types of meta models.
(i) As a Continuous model
(ii) As a Staged model

As a Continuous model :

It describes the process in two dimensions as shown in Fig. 2.4.1 each process are (e.g.
project planning, requirement management) are assessed against specific goals and practices and
is rated according to following capability levels.

Level 0 : Incomplete
The process area (e.g. requirements management) is either not performed or does not
achieve all goals and objective defined by the CMM for level 1 capability.

Level 1 : Performed
All of the specific goals of the process area ( as defined by the CMMI) have been
satisfied. Work tasks required to produce defined work products are being conducted.

Level 2 : Managed
All level 1 criteria have been satisfied. In addition, all work associated with the process
area conforms to an organizationally defined policy, all people doing the work have access to
adequate resources to get the job done.

Level 4 : Quantitatively managed

All level 3 criteria have been achieved. Also the process is controlled and improved
using measurements and quantitative assessment.

Level 5: Optimized.
All level 4 criteria have been achieved. Also the process area is adapted all standards to
meet changing customer’s needs.

Q. Write short notes on : CMMI [10 Marks][May2007]

4
 Section I.1 1.3 Engineering Goals

Programming has evolved over the years. Many modern software systems are much
larger and more complex than common applications of the past. Older programming techniques
have shown themselves to be grossly inadequate to implement these newer systems. From this
need for more sophisticated programming techniques the discipline called Software Engineering
was born. Software Engineering embodies many techniques that could arguably require volumes
to describe. Generally such practices as top-down design, structured programming and design,
pseudocode with iterative refinement, walk-throughs and OOP (Object Oriented Programming)
are considered to be part of this discipline. Many advanced constructs in modern programming
languages such as C++ were incorporated to meet the Software Engineering Goals given below.

1. All programming projects should begin with functional descriptions which

become the highest level pseudocode. Every module and every routine, high or low level,
should have a functional description approptiate to its level of abstraction.

2.Functional descriptions determine high level pseudocode should be iteratively

refined to low level pseudo code. The pseudocode becomes internal documentation.

3.Pseudo code should be organized into modules, thus ultimately organizing the
project into modules.

4.Computer code for all routines and main programs should be generated from low
level pseudo code. The pseudo code should become internal documentation.

5.Module interface specifications should be created so that modules may be created

independently.

6.Programs should be constructed from modules.

7.All support routines should reside in separately compiled modules.

8.Each module should only contain routines whose functions are related.

9.Inter-module communication should be accomplished solely through passing

parameters. No global variables should be used. Parameters should be passed "by value"
where required access is read-only.

5
 10. Communication between routines in the same module should also only
be accomplished through parameter passing.

11. Low level routines should have simple and explicit functions. For
example low level routines should not do any I/O (especially interaction with the user)
unless that is the sole function of that routine.

12. Support routines should be evaluated with respect to flexibility and

efficiency.

13. Include files should be used where required to effect inter-module

independence and consistency. For example data-type definitions should be included to
attain consistent definitions global to all modules.

14. Changes (such as changes to underlying data structures) in low level

routines should not require source code changes in high level routines. This is
accomplished by carefully constructing the calling interface to adhere to data abstraction
principles.

15. Changes (such as changes to the driving application) in high level

routines should not require source code changes in low level routines. This is accomplished
by carefully constructing the calling interface to adhere to data abstraction principles.

16. Changes to high level routines should not require low level routines to be
recompiled.

17. Changes to low level routines should not require high level routines to be
recompiled. (This is generally very difficult to achieve.)

18. Modules should be constructed so that private support routines are not
accessible outside the module. This may be accomplished using submodules or language-
dependent protection mechanisms.

6
 1.4 Software Process Model:

Before starting the different software process model let us first know what it mean by
Software process?
A software process model consists of a frame work activities and umbrella activity. There
are five generic process framework activities as follows.

Communication :
The software development process starts with communication between customer and
developer. According to waterfall model customer must state all requirements at the beginning of
project.

Planning:
It includes complete estimation (e.g. cost estimation of project) and scheduling (complete
timeline chart for project development) and tracking.

Modeling:
It includes detail requirement analysis and project design (algorithm, flowchart etc.)
flowchart shows complete pictorial flow of program whereas algorithm is step by step solution of
problem.

Construction :
It includes coding and testing steps.

(i) Coding :
(ii) Design details are implemented using appropriate programming language.
(iii) Testing : Testing is carried out:
(i) to check whether flow of coding is correct.
(ii) To check out the errors of program e.g. in C program just by pressing F7
key we check step by step execution of program or by using “Add-Watch” we add
the variables and watch the values of variables.
(iii) To check whether program is giving expected output as per input
specifications.

7
 Deployment:

It includes software delivery, support and feedback from customer. If customer suggest
some corrections, or demands additional capabilities then changes are required for such
corrections or enhancement.

These five generic framework activities can be used for:

(i) Development of small programs

(ii) Creation of large programs
(iii) Development of large system based programs.

Q What is software process? Also enumerate the activities common to all software
process. [5][Dec 2006]
The different Software Process Models are as follows

1.4.1 Classic life cycle model

This model is also known as the waterfall or linear sequential model. This model
demands a systematic and sequential approach to software development that begins at the system
level and progresses through analysis, design, coding testing and maintenance. Figure 1.1 shows a
diagrammatic representation of this model.

8
 The life-cycle paradigm incorporates the following activities:
System engineering and analysis: Work on software development begins by
establishing the requirements for all elements of the system. System engineering and analysis
involves gathering of requirements at the system level, as well as basic top-level design and
analysis. The requirement gathering focuses especially on the software. The analyst must
understand the information domain of the software as well as the required function, performance
and interfacing. Requirements are documented and reviewed with the client.
Design: Software design is a multi-step process that focuses on data structures, software
Architecture, procedural detail, and interface characterization. The design process
translates requirements into a representation of the software that can be assessed for quality
before coding begins. The design phase is also documented and becomes a part of the software
configuration.
Coding: The design must be translated into a machine-readable form. Coding performs
this task. If the design phase is dealt with in detail, the coding can be done mechanically.

9
 Testing: Once code is generated, it has to be tested. Testing focuses on the logic as well
as the function of the program to ensure that the code is error free and that o/p matches the
requirement specifications.
Maintenance: Software undergoes change with time. Changes may occur on account of
errors encountered, to adapt to changes in the external environment or to enhance the
functionality and / or performance. Software maintenance reapplies each of the preceding life
cycles to the existing program.
The classic life cycle is one of the oldest models in use. However, there are a few
associated problems. Some of the disadvantages are given below.
Disadvantages:
 Real projects rarely follow the sequential flow that the model proposes.
Iteration always occurs and creates problems in the application of the model.
 It is difficult for the client to state all requirements explicitly. The classic
life cycle requires this and it is thus difficult to accommodate the natural uncertainty that
occurs at the beginning of any new project.
 A working version of the program is not available until late in the project
time span. A major blunder may remain undetected until the working program is
reviewed which is potentially disastrous.
 In spite of these problems the life-cycle method has an important place in
software engineering work. Some of the reasons are given below.
Advantages:
 The model provides a template into which methods for analysis, design,
coding, testing and maintenance can be placed.
 The steps of this model are very similar to the generic steps that are
applicable to all software engineering models.
 It is significantly preferable to a haphazard approach to software
development.

1.4.2 Prototype model

Often a customer has defined a set of objectives for software, but not identified the
detailed input, processing or output requirements. In other cases, the developer may be unsure of
the efficiency of an algorithm, the adaptability of the operating system or the form that the

10
human-machine interaction should take. In these situations, a prototyping approach may be the
best approach.
Prototyping is a process that enables the developer to create a model of the software that
must be built. The sequence of events for the prototyping model is illustrated in figure 1.2.
Prototyping begins with requirements gathering. The developer and the client meet and define the
overall objectives for the software, identify the requirements, and outline areas where further
definition is required. In the next phase a quick design is created. This focuses on those aspects of
the software that are visible to the user (e.g. input approaches and output formats). The quick
design leads to the construction of the prototype. This prototype is evaluated by the client / user
and is used to refine requirements for the software to be developed. A process of iteration occurs
as the prototype is .tuned. to satisfy the needs of the client, while at the same time enabling the
developer to more clearly understand what needs to be done. The prototyping model has a few
associated problems. These are discussed below.

Figure 1.2: The prototype model

11
 Disadvantages:
 The client sees what is apparently a working version of the software
unaware that in the rush to develop a working model, software quality and long-term
maintainability is not considered. When informed that the system must be rebuilt, most
clients demand that the existing application be fixed and made a working product. Often
software developers are forced to relent.
 The developer often makes implementation compromises to develop a
working model quickly. An inappropriate operating system or language may be selected
simply because of availability. An inefficient algorithm may be used to demonstrate
capability. Eventually the developer may become familiar with these choices and
incorporate them as an integral part of the system. Although problems may occur
prototyping may be an effective model for software engineering. Some of the advantages
of this model are enumerated below.
Advantages:
 It is especially useful in situations where requirements are not clearly
defined at the beginning and are not understood both by the client and the developer.
 Prototyping is also helpful in situations where an application is built for
the first time with no precedents to be followed. In such circumstances, unforeseen
eventualities may occur which cannot be predicted and can only be dealt with when
encountered.

1.4.3 Spiral model

The spiral model in software engineering has been designed to incorporate the best
features of both the classic life cycle and the prototype models, while at the same time adding an
element of risk taking analysis that is missing in these models. The model, represented in figure
1.3, defines four major activities defined by the four quadrants of the figure:
Planning: Determination of objectives, alternatives and constraints.
Risk analysis: Analysis of alternatives and identification or resolution of risks.
Engineering: Development of the next level product.
Customer evaluation: Assessment of the results of engineering.

12
 An interesting aspect of the spiral model is the radial dimension as depicted in the figure.
With each successive iteration around the spiral, progressively more complete versions of the
software are built. During the first circuit around the spiral, objectives, alternatives and
constraints are defined and risks are identified and analyzed. If risk analysis indicates that there is
an uncertainty in the requirements, prototyping may be used in the engineering quadrant to assist
both the developer and the client.
The client now evaluates the engineering work and makes suggestions for improvement.
At each loop around the spiral, the risk analysis results in a .go / no . go. decision. If risks are too
great the project can be terminated.
In most cases however, the spiral flow continues outward toward a more complete model
of the system, and ultimately to the operational system itself. Every circuit around the spiral
requires engineering that can be accomplished using the life cycle or the prototype models. It
should be noted, that the number of development activities increase as activities move away from
the center of the spiral.

Figure 1.3: The Spiral model

Like all other models, the spiral model too has a few associated problems, which are
discussed below.
Disadvantages:

13
 It may be difficult to convince clients that the evolutionary approach is controllable.
 It demands considerable risk assessment expertise and relies on this for success.
 If major risk is not uncovered, problems will undoubtedly occur.
 The model is relatively new and has not been as widely used as the life cycle or the
prototype models. It will take a few more years to determine efficiency of this process with
certainty. This model however is one of the most realistic approaches available for software
engineering. It also has a few advantages, which are discussed below.

Advantages:
 The evolutionary approach enables developers and clients to understand and react to risks
at an evolutionary level.
 It uses prototyping as a risk reduction mechanism and allows the developer to use this
approach at any stage of the development.
 It uses the systematic approach suggested by the classic life cycle method but
incorporates it into an iterative framework that is more realistic.
 This model demands an evaluation of risks at all stages and should reduce risks before
they become problematic, if properly applied.

1.4.4 Component assembly model

Object oriented technologies provide the technical framework for a component based
process model for software engineering. This model emphasizes the creation of classes that
encapsulate both data and the algorithms used to manipulate the data.

The component-based development (CBD) model incorporates many characteristics of

the spiral model. It is evolutionary in nature, thus demanding an iterative approach to software
creation. However, the model composes applications from pre-packaged software components
called classes.

The engineering begins with the identification of candidate classes. This is done by
examining the data to be manipulated, and the algorithms that will be used to accomplish this
manipulation. Corresponding data and algorithms are packaged into a class. Classes created in
past applications are stored in a class library. Once candidate classes are identified the class

14
library is searched to see if a match exists. If it does, these classes are extracted from the library
and reused. If it does not exist, it is engineered using object-oriented techniques. The first
iteration of the application is then composed. Process flow moves to the spiral and will ultimately
re-enter the CBD during subsequent passes through the engineering activity.
Advantages:
 The CBD model leads to software reuse, and reusability provides software
engineers with a number of measurable benefits.
 This model leads to a 70% reduction in development cycle time and an 84%
reduction in projection cost.
Disadvantages:
 The results mentioned above are inherently dependent on the robustness of the
component library.

15
 

Figure 1.4: The Component-Based Development model

There is little question in general that the CBD model provides a significant advantage
for software engineers. Identify candidate components Look up components in library Extract
components if available Build components if unavailable Put new components in library
Construct nth iteration of system Spiral model.

16
 1.4.5 RAD model
Rapid Action Development is an incremental software development process model that
emphasizes an extremely short development cycle. The RAD model is a high-speed adaptation of
the linear sequential model in which rapid development is achieved by using component-based
construction.
If requirements are well understood and project scope is constrained, the RAD model
enables a development team to create a fully functional system within 60-90 days. Used primarily
for information system applications, the RAD approach encompasses the following phases:
Business modeling: The information flow among business functions is modeled so as to
understand the following:
i) The information that drives the business process
ii) The information generated
iii) The source and destination of the information generated
iv) The processes that affect this information

17
 Data modeling: The information flow defined, as a part of the business-modeling phase
is refined into a set of data objects that are needed to support the business. The attributes ofeach
object are identified and the relationships between these objects are defined.
Process modeling: The data objects defined in the previous phase are transformed to
achieve the information flow necessary to implement a business function. Processing descriptions
are created for data manipulation.
Application generation: RAD assumes the use of fourth generation techniques (See
section 1.8). Rather than using third generation languages, the RAD process works to reuse
existing programming components whenever possible or create reusable components. In all cases,
automated tools are used to facilitate construction.
Testing and turnover: Since RAD emphasizes reuse, most of the components have
already been tested. This reduces overall testing time. However, new components must be tested
and all interfaces must be fully exercised. In general, if a business function can be modularized in
a way that enables each function to be completed in less than three months, it is a candidate for

18
RAD. Each major function can be addressed by a separate RAD team and then integrated to form
a whole.
Advantages:
 Modularized approach to development
 Creation and use of reusable components
 Drastic reduction in development time
Disadvantages:
 For large projects, sufficient human resources are needed to create the right
number of RAD teams.
 Not all types of applications are appropriate for RAD. If a system cannot be
modularized, building the necessary components for RAD will be difficult.
 Not appropriate when the technical risks are high. For example, when an
application makes heavy use of new technology or when the software requires a high degree of
interoperability with existing programs.

1.4.6 Incremental model

This model combines elements of the linear sequential model with the iterative
philosophy of prototyping. The incremental model applies linear sequences in a staggered fashion
as time progresses. Each linear sequence produces a deliverable increment of the software. For
example, word processing software may deliver basic file management, editing and document
production functions in the first increment. More sophisticated editing and document production
in the second increment, spelling and grammar checking in the third increment, advanced page
layout in the fourth increment and so on. The process flow for any increment can incorporate the
prototyping model.
When an incremental model is used, the first increment is often a core product. Hence,
basic requirements are met, but supplementary features remain undelivered. The client uses the
core product. As a result of his evaluation, a plan is developed for the next increment. The plan
addresses improvement of the core features and addition of supplementary features. This process
is repeated following delivery of each increment, until the complete product is produced.

19
 As opposed to prototyping, incremental models focus on the delivery of an operational
product after every iteration.
Advantages:
 Particularly useful when staffing is inadequate for a complete implementation by
the business deadline.
 Early increments can be implemented with fewer people. If the core product is
well received, additional staff can be added to implement the next increment.
 Increments can be planned to manage technical risks. For example, the system
may require availability of some hardware that is under development. It may be possible to plan
early increments without the use of this hardware, thus enabling partial functionality and avoiding
unnecessary delay.

Section I.2 1.4.7 The WINWIN Spiral Model

20
 This is an adaptation of the spiral model which emphasis is explicitly placed on
the involvement of the client in a negotiation process at the genesis of the product
development. Ideally, the developer would simply ask the customer what is required and
the customer would provide sufficient detail to proceed. Unfortunately this rarely
happens and significant negotiations between both parties are required to balance
functionality, performance, etc… with cost and time-to-market considerations.

The model, shown in Fig. 1.8, derives its name from the objective of these
negotiations, i.e. “win-win”. The client gets the product that satisfies the majority of
his/her needs, and the developer wins by working to realistic and achievable budgets and
deadlines. To achieve this objective the model defines a set of negotiation activities at the
beginning of each pass around the spiral. Rather that a single customer communication
activity the following activities are defined:

 Identification of the system stakeholders. That is the people on the organisation

that have direct business interest in the product to be built and will be rewarded for a successful
outcome or criticised if the effort fails (e.g. user, customer, developer, maintainer, interface, etc.).
 Determination of the stake holder’s “win conditions”
 Negotiations of the stake holder’s win conditions to reconcile them into a set of
win-win conditions for all concerned (including the software project team).

21
 In addition to the early emphasis placed on the win-win condition, the model also
introduces three process milestones (anchor points), which help establish the completion of one
cycle around the spiral and provide the decision milestones before the software project proceeds.
These are,

1. Life Cycle Objectives (LCO) – Defines a set of objectives for each major software
activity (e.g. a set of objectives associated with the definition of top level product requirements)

2. Life Cycle Architecture (LCA) – Establishes the objectives that must be met as the
as the software architecture is defined.

3. Initial Operational Capability (IOC) – represents a set of objectives associated with

the preparation of the software for installation/distribution, site preparations prior to installations,
and assistance required by all parties that will use or support the software.

Advantages:

 Faster software production facilitated through collaborative involvement of the

relevant stake holders.

22
  Cheaper software via rework and maintenance reductions

1.4.8 Fourth generation techniques (4GT)

The term fourth generation techniques encompasses a broad array of software tools that
have one thing in common: each enables the s/ware engineer to specify some characteristic of the
software at a higher level. The tool then automatically generates source code based on the
developer’s specifications.
Currently, a software development environment that supports the 4GT model includes
some or all of the following tools: nonprocedural languages for database query, report generation,
data manipulation, screen interaction and definition, code generation, high-level graphics
capability, spreadsheet capability, automated generation of HTML, etc. initially many of these
tools were available only for very specific application domains, but today 4GT environments
have been extended to address most software application categories.
Like all other models, 4GT begins with a requirements gathering phase. Ideally, the
customer would describe the requirements, which are directly translated into an operational
prototype.
Practically, however, the client may be unsure of the requirements, may be ambiguous in
his specs or may be unable to specify information in a manner that a 4GT tool can use. Thus, the
client/developer dialog remains an essential part of the development process.

23
 Figure 1.7: Fourth Generation Techniques
For small applications, it may be possible to move directly from the requirements
gathering phase to the implementation phase using a nonprocedural fourth generation language.
However for larger projects a design strategy is necessary. Otherwise, the same difficulties are
likely to arise as with conventional approaches. As with all other models, the 4GT model has both
merits and demerits. These are enumerated below:
Advantages:
 Dramatic reduction in software development time.
 Improved productivity for software developers.
Disadvantages:
 Not much easier to use as compared to programming languages.
 Resultant source code produced by such tools is sometimes inefficient.
 The maintainability of large software systems built using 4GT is open to
question.

24
 University questions

1) Describe any two software process models from the following models and discuss the
Problems encountered and the appropriateness of the model.
i) Linear sequential model ii) Prototype model iii) Spiral model
2) Discuss in detail highlighting the advantages and disadvantages of any software
process model.
3) Discuss the major goals of software Engineering? [5 M] [JAN2006]
4) Contrast the following software process models with respect to the appropriateness of
the models: i) Waterfall model ii) Spiral model [10 M] [May 2007]
5) Discuss in detail any one of the following software process models stating their merits
and demerits: i) Spiral model ii) Waterfall model [10 M] [2004]
Ans.
Sr. No. Waterfall model Spiral model
1. Also called the classic life cycle or linear Spiral model is an evolutionary software
sequential model, suggests a systematic process model that couples the iterative nature
approach to software development of prototyping with the controlled and
systematic aspect of the linear sequential
model.
2. Mainly comprises of analysis, design, Mainly comprises of customer communication,
coding and testing phases. planning, risk analysis, engineering
construction and release and customer
evaluation phases.
3. Customer requirements are gathered at the Customer requirements are taken at each
initial phase. It is not possible for a interaction. Customer can specify all his
customer to specify all his requirements requirements.
explicitly.
4 Planning is not done. Planning is done for every iteration.
5. Technical risks are not directly considered. It demands the direct consideration of the
technical risks at all stages of project.
6. No entry point is specified. Entry point is specified for every iteration.
7. End product is delivered at the end of the After each iteration product is delivered to
entire process life cycle. customer.
8. Very tough to implement any new change. New changes can be easily added in the next

25
 iteration.
9. Blocking states are created because of No blocking state is generated.
dependencies among the phases.
10. Real project rarely follow the sequential Spiral model is the realistic approach to the
approach of waterfall model. development of large scale system and
software.

6) What is prototyping? How is the prototype model useful in software engineering?

Discuss its advantages and disadvantages.
7) What is the effect of designing a prototype on the overall cost of software product?
Explain .[5M][Dec 2006]

Ans : The Prototyping Model:

The prototyping paradigm offers best approach for human machine interaction. Ideally
prototype serves as a mechanism for identifying software requirements. If working prototype is
built, developer can use software tools if required (e.g. report generators). This produces working
program quickly. Thus prototype can be served as first system.

Different phases of prototyping model are:

Communication :
Prototyping paradigm begins with communication. The software engineer and customer
meet and define overall objectives of the software and identify the requirements.

Quick design:

Quick design focuses on those aspects of software those are visible to the customer. It
includes clear input, output formats and human machine interfaces.

Modeling quick design :

The model of software is now built that given clear idea of the software to be developed.
This enables the developer to better understand the exact requirements.

26
 Construction of prototype:
Modeling quick design leads to the construction of prototype. The prototype is deployed
and evaluated by the customer.

Deployment, Delivery, Feedback:

As picture of software to be built is clear, customer can give his suggestions as feedback.
If result is satisfactory, the model is now implemented otherwise process is repeated to satisfy
customers all requirements.

Advantage :

Thus prototype can serve as “first system”. Prototyping makes requirements more clear
and system more transparent

Disadvantage:

The developer often compromises in order to get working prototype quickly. Thus
inappropriate operating system or programming language may be used simply because its
available and known. Thus inefficient algorithm may be implemented

8) Discuss appropriateness of the waterfall model.

9) Discuss the following process models:
i) Prototyping
ii) Component assembly model
10) Describe the Rapid Application Development Model in brief [5 M] [May-2007]
11) List the impact of Software Engineering on developing software. [5 M] [Jan 2006]
12) Explain Feasibility Study in SDLC [5 M] [Jan 2007]

27