Evolving role of Software,Legacy software,CASE tools,Process Models,CMMI

1
Module I
The Evolving role of Software – Software – The changing Nature of Software – Legacy
software, Introduction to CASE tools, A generic view of process– A layered Technology – A
Process Framework – The Capability Maturity Model Integration (CMMI) – Process Assessment
– Personal and Team Process Models. Product and Process. Process Models – The Waterfall
Model – Incremental Process Models – Incremental Model – The RAD Model – Evolutionary
Process Models – Prototyping – The Spiral Model – The Concurrent Development Model –
Specialized Process Models – the Unified Process.
1 The Evolving role of Software:
Software takes on a dual role.
1. It is a product, and
2. The vehicle for delivering a product.
As a product,
1) It delivers the computing potential embodied by computer hardware or more broadly
Eg: A network of computers that are accessible by local hardware. whether it resides
in a mobile phone or in a mainframe computer.
2) Software is information transformer— producing, managing, acquiring, modifying,
displaying, or transmitting information that can be as simple as a single bit or as
complex as a multimedia presentation derived from data acquired from dozens of
independent sources.
As the vehicle used to deliver the product, Software delivers most important product of our life
time - information
1) Software acts as the basis for the control of the computer (operating systems),
2) The communication of information, eg: internet and
3) The creation and control of other programs (software tools and environments).
The role of computer software has undergone significant change over a time span of little more
than 50 years. Dramatic improvements in hardware performance, profound changes in
computing architectures, vast increases in memory and storage capacity, and a wide variety of
exotic input and output options have all precipitated more sophisticated and complex computer-
based systems. Sophistication and complexity can produce dazzling results when a system
succeeds, but they can also pose huge problems for those who must build complex systems.
• Before 1970s
– Single processors: mainframes
– Designed in one of two ways
• as a transformation: input was converted to output
• as a transaction: input determined which function should be performed
• After 1970s
– Run on multiple systems
– Perform multi-functions
• During the later 1990s,

2
– Yourdon [YOU96] re-evaluated the prospects for the software
professional and suggested the “the rise and resurrection” of the
American programmer.
– Y2K “time bomb”.
Software’s role continues to expand. When modern computer-based systems are built the
following questions are asked
1. Why does it take so long to get software finished?
2. Why are development costs so high?
3. Why can't we find all the errors before we give the software to customers?
4. Why do we continue to have difficulty in measuring progress as software is being
developed?
2 Software
Definition:
Software is:
1) Instructions (computer programs): that when executed provide desired features,
function, and performance;
2) Data structures: that enable the programs to adequately manipulate information, and
Program logic and design
3) Documentation: Descriptive information in both hard copy and virtual forms that
describes the operation and use of the programs.
Eg: user manual, Design manual
3 Characteristics of software as a product/ Characteristics of software in comparison with
hardware
1 Software is developed or engineered; it is not manufactured in the classical sense.
2 Software doesn’t “wear out.”
Figure 1: failour rate of
hardware( bathtub curve)
Figure depicts failure rate as a function of time for hardware. The relationship, often called the
“bathtub curve,” indicates that hardware exhibits relatively high failure rates early in its life
(these failures are often attributable to design or manufacturing defects); defects are corrected
and the failure rate drops to a steady-state level,for some period of time. As time passes,
however, the failure rate rises again as hardware components suffer from the cumulative effects

3
of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated
simply, the hardware begins to wear out.
Software is not susceptible to the environmental maladies that cause hardware to wear out. In
theory, therefore, the failure rate curve for software should take the form of the “idealized curve”
shown in Figure 2. Undiscovered defects will cause high failure rates early in the life of a
program. However, these are corrected and the curve flattens as shown. The idealized curve is a
gross oversimplification of actual failure models for software
Figure 2. failour rate of Software
However, the implication is clear—software doesn’t wear out. But it doesdeteriorate!.actual
During its life,2 software will undergo change. As changes are made, it is likely that errors will
be introduced, causing the failure rate curve to spike as shown in the “actual curve” (Figure .2).
Before the curve can return to the original steady-state failure rate, another change is requested,
causing the curve to spike again. Slowly, the minimum failure rate level begins to rise—the
software is deteriorating due to change.
3 Although the industry is moving toward component-based construction, most software
continues to be custom built.
4 CHARACTERESTICS OF GOOD SOFTWARE/ATTRIUTE OF GOOD SOFTWARE
A software product can be judged by what it offers and how well it can be used. This software
must satisfy on the following grounds:
1. Operational
2. Transitional
3. Maintenance
Well-engineered and crafted software is expected to have the following characteristics:
1 Operational: This tells us how well software works in operations.
It can be measured on:
a. Budget
b. Usability Efficiency
c. Correctness Functionality
d. Dependability Security
e. Safety

4
2 Transitional: This aspect is important when the software is moved from one platform to
another:
a. Portability: Refers to the ease with which the software develepor can transfer software
from one platform to another
b. Interoperability Reusability
c. Adaptability
3 Maintenance: Evolve to meet the changing needs of customers.Software change is inevitable
(see changing business environment).This aspect briefs about how well a software has the
capabilities to maintain itself in the ever-changing environment:
a. Modularity
b. Maintainability
c. Flexibility
d. Scalability
e. Reliability:Refers to the ability of the software to perform a required function under a
given condition
In short, Software engineering is a branch of computer science, which uses well-defined
engineering concepts required to produce efficient, durable, scalable, in-budget and on-time
software products
5 THE CHANGING NATURE OF SOFTWARE/ CLASSIFICATION OF SOFTWARE
/SOFTWARE APPLICATION DOMAIN
Today, seven broad categories of computer software present continuing challenges for software
engineers:
1 System software— a collection of programs written to service other programs.
(e.g., compilers, editors, and file management Utilities,operating system components, drivers,
networking software, telecommunications processors)
Systems software area is characterized by
1) heavy interaction with computer hardware;
2) heavy usage by multiple users;
3) concurrent operation
4) that requires scheduling,
5) resource sharing, and
6) sophisticated process management;
7) complex data structures; and
8) Multiple external interfaces.
2 Application software—stand-alone programs that solve a specific business need.
Applications in this area process business or technical data in a way that facilitates business
operations or management/technical decision making, used to control business functions in real
time (e.g., point-of-sale transaction processing, real-time manufacturing process control).

5
3 Real-time software. Software that monitors/analyzes/controls real-world events as they occur
is called real time.
Elements of real-time software include
1. data gathering component that collects and formats information from an external
environment,
2. analysis component that transforms information as required by the application,
3. control/output component that responds to the external environment, and
4. monitoring component that coordinates all other components
so that real-time response (typically ranging from 1 millisecond to 1 second) can be maintained.
4 Business software. Business information processing is the largest single software application
area.
Applications in this area restructure existing data in a way that facilitates business operations or
management decision making.
In addition to conventional data processing application, business software applications also
encompass interactive computing (e.g., pointof- sale transaction processing).
5 Engineering and scientific software. Engineering and scientific software havebeen
characterized by "number crunching" algorithms.
Applications range from
1. astronomy to volcanology,
2. automotive stress analysis to space shuttle orbital dynamics, and
3. molecular biology to automated manufacturing.
4. Computer-aided design, system simulation, and other interactive applications have begun
to take on real-time and even system software characteristics.
6 Embedded software. Intelligent products have become commonplace in nearly every
consumer and industrial market.
Embedded software resides in read-only memory and is used to control products and systems for
the consumer and industrial markets.
a. Embedded software can perform very limited and esoteric functions (e.g., keypad control
for a microwave oven)
b. provide significant function and control capability(e.g., digital functions in an automobile
such as fuel control, dashboard displays, and braking systems).
7 Web-based software. The Web pages retrieved by a browser are software that incorporates
executable instructions (e.g., CGI, HTML, Perl, or Java), and data hypertext and a variety of
visual and audio formats).
8 Product-line software—designed to provide a specific capability for use by many different
customers. Product-line software can focus on a limited and esoteric marketplace (e.g., inventory
control products) or address mass consumer markets (e.g., word processing, spreadsheets,
computer graphics, multimedia, entertainment, database management, and personal and
business financial applications).

6
9 Artificial intelligence software—makes use of non numerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis. Applications within
this area include robotics, expert systems, pattern recognition (image and voice), artificial neural
networks, theorem proving, and game playing.
10 Net sourcing—the World Wide Web is rapidly becoming a computing engine as well as a
content provider. The challenge for software engineers is to architect simple (e.g., personal
financial planning) and sophisticated applications that provide a benefit to targeted end-user
markets worldwide.
11 Open source—a growing trend that results in distribution of source code for systems
applications (e.g., operating systems, database, and development environments) so that many
people can contribute to its development. The challenge for software engineers is to build source
code that is self-descriptive, but more importantly, to develop techniques that will enable both
customers and developers to know what changes have been made and how those
Changes manifest themselves within the software
6 Legacy Software
Legacy software systems were developed decades ago and have been continually modified to
meet changes in business requirements and computing platforms.
legacy software quality: poor quality.
1. Legacy systems sometimes have inextensible designs,
2. convoluted code,
3. poor or nonexistent documentation,
4. test cases and results that were never archived,
5. a poorly managed change history—the list can be quite long.
Legacy systems often evolve for one or more of the following reasons:
1. The software must be adapted to meet the needs of new computing environments or
technology.
2. The software must be enhanced to implement new business requirements.
3. The software must be extended to make it interoperable with other more modern systems
or databases.
4. The software must be re-architected to make it viable within a network environment.
8 Laws of unified theory
 The Law of Continuing Change.
 The Law of Increasing Complexity.
 The Law of Self-Regulation
 The Law of Conservation of Organizational Stability.
 The Law of Conservation of Familiarity
 The Law of Continuing Growth
 The Law of Declining Quality
 The Feedback System Law

7
Figure 3: SOFTWARE ENGINEERING

8
7 NEED OF SOFTWARE ENGINEERING
The need of software engineering arises because of higher rate of change in user requirements
and environment on which the software is working
1. Large software - It is easier to build a wall than to a house or building, likewise, as the
size of software become large engineering has to step to give it a scientific process.
2. Scalability- If the software process were not based on scientific and engineering
concepts, it would be easier to re-create new software than to scale an existing one.
3. Cost- As hardware industry has shown its skills and huge manufacturing has lower down
the price of computer and electronic hardware. But the cost of software remains high if
proper process is not adapted
4. Dynamic Nature- The always growing and adapting nature of software hugely depends
upon the environment in which the user works. If the nature of software is always
changing, new enhancements need to be done in the existing one. This is where software
engineering plays a good role.
5. Quality Management- Better process of software development provides better and
quality software product.
8 Software Engineering Goals
Figure 4: Software engineering goal
9 Software Engineer
“A Software Engineer is a person who applies Software Engineering principles to the process of
software development.”

9
Software engineers should /role of Software engineers
1. adopt a systematic and organised approach to their work
2. use appropriate tools and techniques depending on
3. the problem to be solved,
4. the development constraints and
5. the resources available
6. Be familiar with various design approaches
7. Be able to translate user requirements into specifications
8. Be able to interact with the users on various areas of an application
9. Possesses good managerial skill
Qualities / Skills possessedby a good software engineer:
1. General Skill (Analytical skill, Problem solving skill, Group work skill)
2. Programming Skill (Programming language , Data structure , Algorithm ,
Tools(Compiler, Debugger))
3. Communication skill (Verbal , Written, Presentation)
4. DesignSkill (s/w engineer must be familiar with several application domain)
10 PROCESS GENERIC VIEW
A series of predictable steps that helps to create a timely ,high quality result.
A process is a collection of activities, actions and tasks that are performed when some work
product is to be created. It is an adaptable approach that enables the people doing the work (the
software team) to pick and choose the appropriate set of work actions and tasks.
1. An activity strives to achieve a broad objective(e.g., communication with
stakeholders) and is applied regardless of the application domain, size of the
project, complexity of the effort,or degree of rigor with which software engineering
is to be applied.
2. An action (e.g., architectural design) encompasses a set of tasks that produce a major
work product (e.g., an architectural design model).
3. A task focuses on a small, but well-defined objective (e.g., conducting a unit test)
that produces a tangible outcome
Process that is adopted is depends upon the software that you are building
Characteristic of a software process:
1. Understandability
2. Visibility
3. Reliability
4. Robustness
5. Adaptability
6. Rapidity
7. Maintainability
8. Supportability

10
11 SOFTWARE ENGINEERING IS A LAYERED TECHNOLOGY.
Software engineering encompasses a process, the management of activities, technical methods,
and use of tools to develop software products
Figure 5: Software engineering layered technology
1) QUALITY FOCUS
Quality focus is this culture that ultimately leads to the development of increasingly more
effective approaches to software engineering. The bedrock that supports software engineering
is a quality focus.
Eg:Total quality management, Six Sigma
2) PROCESS
The foundation for software engineering is the process layer.
The software engineering process is the glue that holds the technology layers together and
enables rational and timely development of computer software.
Process defines a framework that must be established for effective delivery of software
engineering technology.
The software process forms the basis for management control of software projects and
1. establishes the context in which technical methods are applied,
2. work products(models, documents, data, reports, forms, etc.) are produced,
3. milestones are established,
4. quality is ensured, and
5. change is properly managed.
3) METHODS
Software engineering methods provide the technical how-to’s for building software.
Methods encompass a broad array of tasks that include communication,
1. requirements analysis,
2. design modeling,
3. program construction,
4. testing, and
5. support.
4 )TOOLS
Software engineering tools provide automated or semi automated support for the process and
the methods. Eg(c,c#,linux,cad etc)

11
When tools are integrated so that information created by one tool can be used by another, a
system for the support of software development, called computer-aided software engineering, is
established
12 A GENERIC VIEW OF SOFTWARE ENGINEERING
Engineering is the analysis, design, construction, verification, and management of technical (or
social) entities. Regardless of the entity to be engineered, the following questions must be asked
and answered:
1. What is the problem to be solved?
2. What characteristics of the entity are used to solve the problem?
3. How will the entity (and the solution) be realized?
4. How will the entity be constructed?
5. What approach will be used to uncover errors that were made in the design and
construction of the entity?
6. How will the entity be supported over the long term, when corrections, adaptations, and
enhancements are requested by users of the entity
The intent is always to deliver software in a timely manner and with sufficient quality to satisfy
those who have sponsored its creation and those who will use it.
PROCESS FRAMEWORK
A process framework establishes the foundation for a complete software engineering process by
identifying a small number of framework activities that are applicable to all software projects,
regardless of their size or complexity.
In addition, the process framework encompasses a set of umbrella activities that are applicable
across the entire software process.
What is the work product?
From the point of view of a software engineer, the work products are the programs, documents,
and data produced as a consequence of the software engineering activities defined by the
process.
What is the task set?
Actual work done to accomplish the software engineering action
Eg requirement gathering that occurs during communication
Task set for requirement gathering
1. make list of stake holders for the project
2. invite all the stake holders for an informal meeting
3. ask the stake holders to make a list of features and functions required
4. discuss the requirement and build final list
5. prioritize the requirement
6. note the area of uncertainty

12
_____________________________________________________________________
Figure 6: A Generic View of Software Engineering
A generic process framework for software engineering encompasses five activities:
1. Communication. Before any technical work can commence, it is critically important to
communicate and collaborate with the customer (and other stakeholders) The intent is to
understand stakeholders’ objectives for the project and to gather requirements that help
define software features and functions.
2. Planning. Any complicated journey can be simplified if a map exists. A software project
is a complicated journey, and the planning activity creates a “map” that helps guide the
team as it makes the journey. The map—called a software project plan—defines the
software engineering work by describing the technical tasks to be conducted, the risks

13
that are likely, the resources that will be required, the work products to be produced, and
a work schedule.
3. Modeling. A software engineer creates models to better understand software
requirements and the design that will achieve those requirements.
4. Construction. This activity combines code generation (either manual or automated) and
the testing that is required to uncover errors in the code.
5. Deployment. The software (as a complete entity or as a partially completed increment) is
delivered to the customer who evaluates the delivered product and provides feedback
based on the evaluation
.
Process flow
Describes how the framework activities and the actions and tasks that occur within each
framework activity are organized with respect to sequence and time
1. A linear process flow executes each of the five framework activities in sequence,
beginning with communication and culminating with deployment
2. An iterative process flow repeats one or more of the activities before proceeding to the
next
3. An evolutionary process flow executes the activities in a “circular”manner.
• Each circuit through the five activities leads to a more complete version of the software

14
4. A parallel process flow executes one or more activities in parallel with other activities
(e.g., modeling for one aspect of the software might be executed in parallel with
construction of another aspect of the software).
UMBRELLA ACTIVITIES.
Software engineering process framework activities are complemented by a number of umbrella
activities. In general, umbrella activities are applied throughout a software project and help a
software team manage and control progress, quality, change, and risk.
The phases and related steps described in our generic view of software engineering
are complemented by a number of umbrella activities. Typical activities in this category
include:
1. Software project tracking and control
2. Formal technical reviews
3. Software quality assurance
4. Software configuration management
5. Document preparation and production
6. Reusability management
7. Measurement
8. Risk management
1 Software project tracking and control—allows the software team to assess progress against
the project plan and take any necessary action to maintain the schedule.

15
2 Risk management—assesses risks that may affect the outcome of the project or the
quality of the product.
• Steps
– Risk identification
– Risk prioritization
– Risk treatment
3 Software quality assurance—defines and conducts the activities required to ensure software
quality.
4 Technical reviews—assesses software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity.
5 Measurement—defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders’ needs; can be used in conjunction with
all other framework and umbrella activities.
6 Software configuration management—manages the effects of change throughout the
software process.
7 Reusability management—defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
8 Work product preparation and production—encompasses the activities required to create
work products such as models, documents, logs, forms,and lists.
Software quality
software quality comprises six main attributes, as shown in Figure These attributes
can be defined as follows:
1. Functionality. The capability to provide functions which meet stated and
implied needs when the software is used.
2. Reliability. The capability to provide failure-free service.
3. Usability. The capability to be understood, learned, and used.
4. Eﬃciency. The capability to provide appropriate performance relative
to the amount of resources used.
5. Maintainability. The capability to be modified for purposes of making
corrections, improvements, oradaptation.

16
6. Portability. The capability to be adapted for diﬀerent specified
environments without applying actions or means other than those provided
for this purpose in the product.
Life cycle model
A software life cycle model (also called process model) is a descriptive and diagrammatic
representation of the software life cycle. A life cycle model represents all the activities required
to make a software product transit through its life cycle phases. It also captures the order in
which these activities are to be undertaken. In other words, a life cycle model maps the different
activities performed on a software product from its inception to retirement. Different life cycle
models may map the basic development activities to phases in different ways. Thus, no matter
which life cycle model is followed, the basic activities are included in all life cycle models
though the activities may be carried out in different orders in different life cycle models. During
any life cycle phase, more than one activity may also be carried out. For example, the design
phase might consist of the structured analysis activity followed by the structured design activity.
The need for a software life cycle model /process model
• The development team must identify a suitable life cycle model for the particular
Project and then adhere to it.
• Without using of a particular life cycle model the development of a software product
Would not be in a systematic and disciplined manner. So when a software product is being
developed by a team there must be a clear understanding among team members about when
and what to do, Otherwise it would lead to chaos and project failure. Otherwise it would lead
to chaos and project failure. This problem can be illustrated by using an example. Suppose a
software development problem is divided into several parts and the parts are assigned to the
team members. From then on, suppose the team members are allowed the freedom to develop
the parts assigned to them in whatever way they like. It is possible that one member might
start writing the code for his part, another might decide to prepare the test documents first,
and some other engineer might begin with the design phase of the parts assigned to him. This
would be one of the perfect recipes for project failure.
• A software life cycle model defines entry and exit criteria for every phase. A phase can
start only if its phase-entry criteria have been satisfied. So without software life cycle
model the entry and exit criteria for a phase cannot be recognized. Without software life
cycle models it becomes difficult for software project managers to monitor the progress
of the project.
SOFTWARE DEVELOPMENT LIFE CYCLE(SDLC)
The work associated with software engineering can be categorized into 5 generic phases,
regardless of application area, project size, or complexity. Each phase addresses one or more of
the questions noted previously.
Activities in each phase of the life cycle

17
1 Activities undertaken during feasibility study: -
• At first project managers or team leaders try to have a rough understanding of what is
required to be done by visiting the client side. They study different input data to the
system and output data to be produced by the system. They study what kind of processing
is needed to be done on these data and they look at the various constraints on the
behavior of the system.
• After they have an overall understanding of the problem they investigate the different
solutions that are possible. Then they examine each of the solutions in terms of what kind
of resources required, what would be the cost of development and what would be the
development time for each solution.
• Based on this analysis they pick the best solution and determine whether the solution is
feasible financially and technically. They check whether the customer budget would meet
the cost of the product and whether they have sufficient technical expertise in the area of
development.
FIGURE : phases of the life cycle:
2 . Activities undertaken during requirements analysis and specification: -
The aim of the requirements analysis and specification phase is to understand the exact
requirements of the customer and to document them properly. This phase consists of
two distinct activities, namely
1. Requirements gathering and analysis, and
2. Requirements specification

18
The goal of the requirements gathering activity is to collect all relevant information from the
customer regarding the product to be developed. This is done to clearly understand the customer
requirements so that incompleteness and inconsistencies are removed.
-After all ambiguities, inconsistencies, and incompleteness have been resolved and all the
requirements properly understood, the requirements specification activity can start.
-During this activity, the user requirements are systematically organized into a Software
Requirements Specification (SRS) document.
3 Activities undertaken during design: -
The goal of the design phase is to transform the requirements specified in the SRS document into
a structure that is suitable for implementation in some programming language. During the design
phase the software architecture is derived from the SRS document.
Two distinctly different approaches are available:
1. traditional design approach and
2. object-oriented design approach.
Traditional design approach
Traditional design consists of two different activities; first a structured analysis of the
requirements specification is carried out where the detailed structure of the problem is
examined. This is followed by a structured design activity. During structured design, the
results of structured analysis are transformed into the software design.
Object-oriented design approach
In this technique, various objects that occur in the problem domain and the solution domain
are first identified, and the different relationships that exist among these objects are
identified. The object structure is further refined to obtain the detailed design.
4 Activities undertaken during coding and unit testing:-
The purpose of the coding and unit testing phase (sometimes called the implementation
phase) of software development is to translate the software design into source code. Each
component of the design is implemented as a program module. The end-product of this phase is a
set of program modules that have been individually tested then proceeds for next stage. During
this phase, each module is unit tested to determine the correct working of all the individual
modules. It involves testing each module in isolation way as this is the most efficient way to
debug the errors identified at this stage.
5 Activities undertaken during integration and systemtesting: -
Integration of different modules is undertaken once they have been coded and unit tested.
During the integration and system testing phase, the modules are integrated in a planned manner.
Integration is normally carried out incrementally over a number of steps. During each integration
step, the partially integrated system is tested and a set of previously planned modules are added
to it. Finally, when all the modules have been successfully integrated and tested, system testing is
carried out. The goal of system testing is to ensure that the developed system conforms to its
requirements laid out in the SRS document. System testing usually consists of three different
kinds of testing activities:

19
1. α – testing: It is the system testing performed by the development team.
2. β – testing: It is the system testing performed by a friendly set of customers.
3. acceptance testing: It is the system testing performed by the customer himself after the
product delivery to decide whether to accept or reject the delivered product.
6 Activities undertaken during maintenance/deployment/ support phase:: -
Maintenance of a typical software product requires much more effort than the effort necessary to
develop the product itself.
Four types of change are encountered during the support phase:
1. Correction. Even with the best quality assurance activities, it is likely that the
customer will uncover defects in the software. Corrective maintenance changes the
software to correct defects.
2. Adaptation. Over time, the original environment (e.g., CPU, operating system,
business rules, external product characteristics) for which the software was developed
is likely to change. Adaptive maintenance results in modification to the software to
accommodate changes to its external environment. Porting the software to work in a
new environment
3. Enhancement. As software is used, the customer/user will recognize additional
functions that will provide benefit. Perfective maintenance extends the software
beyond its original functional requirements.
4. Prevention. Computer software deteriorates due to change, and because of this,
preventive maintenance, often called software reengineering, must be conducted to
enable the software to serve the needs of its end users. In essence,preventive
maintenance makes changes to computer programs so that they can be more easily
corrected, adapted, and enhanced

20
DIFFERENT PROCESS MODELS
.
1 CLASSICAL WATERFALL MODEL
In 1970 Royce proposed what is now popularly referred to as the waterfall model as an initial
concept The classical waterfall model is intuitively the most obvious way to develop software.
Though the classical waterfall model is elegant and intuitively obvious, it is not a practical model
in the sense that it cannot be used in actual software development projects. Thus, this model can
be considered to be a theoretical way of developing software. But all other life cycle models are
essentially derived from the classical waterfall model. Classical waterfall model divides the life
cycle into the following phases as shown in fig.2.1:
Fig 2.1: Classical Waterfall Model
When to use the waterfall model:
 Requirements are very well known, clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.
Communicat ion
Planning
Modeling
Const ruct ion
Deployment
analysis
design
code
t est
project init iat ion
requirement gat hering estimating
scheduling
tracking
delivery
support
f eedback

21
64
Sl
no
advantages disadvantages When to use
1 It allows for
departmentalization and
managerial control.
it assumes that no development error is ever
committed by the engineers during any of the life
cycle phases. However, in practical development
environments, the engineers do commit a large
number of errors in almost every phase of the life
cycle
Requirements are
well understood
2 Simple and easy to
understand and use
It is difficult for customer to state all requirements
explicitly(without any change)
Automation of
existing manual
system
3 Phases are processed and
completed one at a time.
Working version of software will not be available
until late in project span
Short duration
project
4 Works well for smaller
projects where requirements
are very well understood.
User feedback not encouraged
Not a good model for complex and object-oriented
projects.
5 A schedule can be set with
deadlines for each stage of
development and a product
can proceed through the
development process like a
car in a car-wash, and
theoretically, be delivered
on time.
. Once a defect is detected, the engineers need to go
back to the phase where the defect had occurred
and redo some of the work done during that phase
and the subsequent phases to correct the defect and
its effect on the later phases
2 INCREMENTAL PROCESS MODELS
The process models in this category tend to be among the most widely used (and effective) in the
industry.
a) The Incremental Model
Incremental Model is combination of one or more Waterfall Models. In Incremental Model,
Project requirements are divided into multiple modules and each module is developed separately.
Finally developed modules are integrated with other modules. During development of each
module, waterfall model is followed for each module development separately. Each developed
module in Incremental Model is standalone feature and could be delivered to the end users to use
it. On incremental basis other modules are integrated as additional features one after another and
finally delivered to the client. In Incremental Model no need to wait for all the modules to be
developed and integrated. As each module is standalone application and there is no dependencies
on other modules so we can deliver the project with initial developed feature and other features
could be added on incremental basis with new releases. Incremental process goes until all the
requirements fulfilled and whole system gets developed.

22
Each linear sequence produces deliverable “increments” of the software. (Ex: a Word Processor
delivers basic file mgmt., editing, in the first increment; more sophisticated editing, document
production capabilities in the 2nd increment; spelling and grammar checking in the 3rd increment.
When an increment model is used, the 1st increment is often a core product. The core product is
used by the customer.As a result of use and / or evaluation, a plan is developed for the next
increment.The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality.The process is repeated
following the delivery of each increment, until the complete product is produced.If the customer
demands delivery by a date that is impossible to meet, suggest delivering one or more increments
by that date and the rest of the Software later.
67
5
Sl no advantages disadvantages When to use
1 Generates working
software quickly and
early during the software
life cycle.
Needsgood planning and
design.
when the requirements of the
complete system are clearly
defined and understood.
2 Lowers initial delivery
cost.
Total cost is higher
than waterfall.
Anew technology is being used
3 Easier to manage risk
because risky pieces are
identified and handled
during individual
iteration.
Needsa clear and complete
definition of the whole system
before it can be broken down
andbuilt incrementally.
Staffing is not available for
complete implementation of
project
4 It is easier to test and
debug during a smaller
iteration.
In this model customer
canrespond to eachbuilt.
There are some high risk features
and goals.
5 This model is more
flexible – less costly to
change scope and
requirements.

23
B)The RAD Model
Rapid Application Development (RAD) is an incremental software process model that
emphasizes a short development cycle.
RAD is a “high-speed” adaptation of the waterfall model, in which rapid development is
achieved by using a component based construction approach.
If requirements are well understood and project scope is constrained, the RAD process enables a
development team to create a fully functional system within a short period of time.
Since there is no detailed preplanning, it makes it easier to incorporate the changes within the
development process. RAD projects follow iterative and incremental model and have small
teams comprising of developers, domain experts, customer representatives and other IT
resources working progressively on their component or prototype.
The most important aspect for this model to be successful is to make sure that the prototypes
developed are reusable.
RAD Model Design
RAD model distributes the analysis, design, build, and test phases into a series of short, iterative
development cycles. Following are the phases of RAD Model:
 Business Modeling: The business model for the product under development is designed
in terms of flow of information and the distribution of information between various
business channels. A complete business analysis is performed to find the vital
information for business, how it can be obtained, how and when is the information
processed and what are the factors driving successful flow of information.
 Data Modeling: The information gathered in the Business Modeling phase is reviewed
and analyzed to form sets of data objects vital for the business. The attributes of all data
sets is identified and defined. The relation between these data objects are established and
defined in detail in relevance to the business model.
 Process Modeling: The data object sets defined in the Data Modeling phase are
converted to establish the business information flow needed to achieve specific business
objectives as per the business model. The process model for any changes or
enhancements to the data object sets is defined in this phase. Process descriptions for
adding , deleting, retrieving or modifying a data object are given.
 Application Generation: The actual system is built and coding is done by using
automation tools to convert process and data models into actual prototypes.

24
 Testing and Turnover:The overall testing time is reduced in RAD model as the
prototypes are independently tested during every iteration. However the data flow and
the interfaces between all the components need to be thoroughly tested with complete
test coverage. Since most of the programming components have already been tested, it
reduces the risk of any major issues.
advantages disadvantages When to use
1 Progress can be
measured.
Iteration time can be
short with use of
powerful RAD tools.
Dependency on technically strong
team members for identifying
business requirements.
Sufficient human recourse is
needed to create right no of RAD
team
Suitable for project
requiring shorter
development times.
2 Integration from very
beginning solves a lot
of integration issues.
Only system that can be
modularized can be built using
RAD.
Sufficient human recourse is
needed to create right no of RAD
team
Requirements are
understood and project
scope is constrained
3 Encourages customer
feedback, Changing
requirements can be
accommodated.
Requires highly skilled
developers/designers.High
dependency on modeling
skills.Performances issue
Fully functional system is
to be delivered in short
span of time
4 Reduced development
time.
Increases reusability of
components
Management complexity is more.
Suitable for systems that are
component based and scalable
For large, but scalable
projects, RAD requires
sufficient human
resources to create the
right number of RAD
teams.
5 Productivity with fewer
people in short time.
Requires user involvement
throughout the life cycle.
Inapplicable to cheaper projects as
cost of modeling and automated
code generation is very high

25
Communication
Planning
Modeling
business modeling
data modeling
process modeling
Construction
component reuse
automatic code
generation
testing
Deployment
60 - 90 days
Team # 1
Modeling
business modeling
data modeling
process modeling
Construction
component reuse
automatic code
generation
testing
Mode ling
business modeling
data modeling
process modeling
Const ruct ion
component reuse
automatic code
generation
testing
Team # 2
Team # n
integration
delivery
feedback

26
3 EVOLUTIONARY PROCESS MODEL
Software evolves over a period of time; business and product requirements often change as
development proceeds, making a straight-line path to an end product unrealistic.
Software Engineering needs a process model that has been explicitly designed to accommodate a
product that evolves over time.
Evolutionary process models are iterative. They produce increasingly more complete versions of
the Software with each iteration.
A)Prototype
A prototype is a toy implementation of the system. A prototype usually exhibits limited
functional capabilities, low reliability, and inefficient performance compared to the actual
software. A prototype is usually built using several shortcuts. The shortcuts might involve using
inefficient, inaccurate, or dummy functions. The prototyping model is applied when detailed
information related to input and output requirements of the system is not available. In this model,
it is assumed that all the requirements may not be known at the start of the development of the
system.This model allows the users to interact and experiment with a working model of the
system known as prototype. The prototype gives the user an actual feel of the system.At any
stage, if the user is not satisfied with the prototype, it can be discarded and an entirely new
system can be developed. Generally, prototype can be prepared by the approaches listed below.
Needfor a prototype in software development
An important purpose of prototype is to illustrate the input data formats, messages, reports, and
the interactive dialogues to the customer. This is a valuable mechanism for gaining better
understanding of the customer’s needs:
1. how the screens might look like
2. how the user interface would behave
3. how the system would produce outputs
Prototype can be prepared by the approaches listed below.
1.By creating main user interfaces without any substantial coding so that users can get a
feel of how the actual system will appear
2.By abbreviating a version of the system that will perform limited subsets of functions
3.By using system components to illustrate the functions that will be included in the
system to be developed
This is something similar to what the architectural designers of a building do; they show a
prototype of the building to their customer. The customer can evaluate whether he likes it or not

27
and the changes that he would need in the actual product. A similar thing happens in the case of a
software product and its prototyping model.
Another reason for developing a prototype is that it is impossible to get the perfect product in the
first attempt. Many researchers and engineers advocate that if you want to develop a good
product you must plan to throw away the first version. The experience gained in developing the
prototype can be used to develop the final product.
WHEN TO BUILD PROTOTYPE
A prototype of the actual product is
preferred in situations such as:
1. User requirements are not
complete
2. Technical issues are not clear
Communicat ion
Quick plan
Const ruct ion
of
prot ot ype
Mode ling
Quick de sign
Delivery
& Feedback
Deployment

28
1. The prototyping paradigm begins with communication where requirements and
goals of Software are defined.
2. Prototyping iteration is planned quickly and modeling in the form of quick design
occurs.
3. The quick design focuses on a representation of those aspects of the Software that
will be visible to the customer “Human interface”.
4. The quick design leads to the Construction of the Prototype.
5. The prototype is deployed and then evaluated by the customer.
6. Feedback is used to refine requirements for the Software.
Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while enabling the
developer to better understand what needs to be done.
Example for each of the above category.
Example 1: User requirements are not complete
In any application software like billing in a retail shop, accounting in a firm, etc the users of the
software are not clear about the different functionalities required. Once they are provided with
the prototype implementation, they can try to use it and find out the missing functionalities.
Example 2: Technical issues are not clear
Suppose a project involves writing a compiler and the development team has never written a
compiler.
In such a case, the team can consider a simple language, try to build a compiler in order to check
the issues that arise in the process and resolve them. After successfully building a small compiler
(prototype), they would extend it to one that supports a complete language.
Prototyping can be problematic:
1. The customer sees what appears to be a working version of the Software, unaware that
the prototype is held together “with chewing gum. “Quality, long-term maintainability.”
When informed that the product is a prototype, the customer cries foul and demands that
few fixes be applied to make it a working product. Too often, Software development
management relents.
2. The developer makes implementation compromises in order to get a prototype working
quickly. An inappropriate O/S or programming language used simply b/c it’s available
and known. After a time, the developer may become comfortable with these choices and
forget all the reasons why they were inappropriate.

29
B)Spiral model
Invented by Dr. Barry Boehm in 1988.The spiral model is an evolutionary Software process
model that couples the iterative nature of prototyping with the controlled and systematic aspects
of the waterfall model.
It has two distinguishing features:
1. A cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk.
2. A set of anchor point milestones for ensuring stakeholder commitment to feasible and
mutually satisfactory solutions.
When to use spiral model
The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However, this
model is much more complex than the other models – this is probably a factor deterring its use in
ordinary projects
Using the spiral model, Software is developed in a series of evolutionary releases.
During early stages, the release might be a paper model or prototype.

30
During later iterations, increasingly more complete versions of the engineered system are
produced.
A spiral model is divided into a set of framework activities divided by the Software engineering
team.
As this evolutionary process begins, the Software team performs activities that are implied by a
circuit around the spiral in a clockwise direction, beginning at the center.
Risk is considered as each revolution is made.
Anchor-point milestones – a combination of work products and conditions that are attained along
the path of the spiral- are noted for each evolutionary pass.
The first circuit around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop a prototype and then progressively
more sophisticated versions of the Software.
Each pass through the planning region results in adjustments to the project plan. Cost and
schedule are adjusted based on feedback derived from the customer after delivery.
Unlike other process models that end when Software is delivered, the spiral model can be
adapted to apply throughout the life of the Software.
A spiral model is divided into a number of framework activities, also called task regions
six task regions:
1. Customer communication—tasks required to establish effective communication
between developer and customer.
2. Planning & Risk analysis —tasks required to define resources, timelines, and
other project related information. tasks required to assess both technical and
management risks.
3. Modeling—tasks required to build one or more representations of the application.
4. Construction —tasks required to construct, test, install, and provide user support
(e.g., documentation and training).
5. Deployment &Customer evaluation—tasks required to obtain customer
feedback based on evaluation of the software representations created during the
engineering stage and implemented during the installation stage.

31
The spiral model is also similar to the prototyping model as one of the key features of
prototyping is to develop a prototype until the user requirements are accomplished. The second
step of the spiral model functions similarly. The prototype is developed to clearly understand and
achieve the user requirements. If the user is not satisfied with the prototype, a new prototype
known as operational prototype is developed.
Table Advantages and Disadvantages of Spiral Model
Sl advantages disadvantages When to use
1 Avoids the problems resulting
in risk-driven approach in the
software
Re-evaluation after each step
Assessment of project risks
and its resolution is not an
easy task.
suitable for development of
technically challenging software
products that are prone to several
kinds of risks
communication
planning
modeling
construction
deployment
delivery
feedback
start
analysis
design
code
test
estimation
scheduling
risk analysis

32
allows changes in user
perspectives, technology
advances, or financial
perspectives.
Spiral may go indefinitely
End of project may not be
known early
2 Specifies a mechanism for
software quality assurance
activities
Difficult to estimate budget
and schedule in the
beginning as some of the
analysis is not done until
the design of the software
is developed.
Projects build on untested
assumptions
3 Development can be divided
into smaller parts and more
risky parts can be developed
earlier which helps better risk
management
It demands considerable
risk assessment expertise
and relies on this expertise
for success
Is utilized by complex and
dynamic projects
4 Allows for extensive use of
prototypes
If risks is not uncovered
and managed problems will
surely occur
5 Estimation of budget and
schedule gets realistic as the
work progresses.
Large number of
intermediate stages requires
excessive documentation.
The spiral model is similar to the waterfall model as software requirements are understood at the
early stages in both the models. However, the major risks involved with developing the final
software are resolved in the spiral model. When these issues are resolved, a detailed design of the
software is developed.
Note that processes in the waterfall model are followed by different cycles in the spiral model as
shown in Figure.

33
Spiral and Waterfall Models
3 The concurrent Development Model
The concurrent development model, sometimes called concurrent engineering, can be
represented schematically as a series of framework activities, Software engineering actions of
tasks, and their associated states.
The concurrent model is often more appropriate for system engineering projects where
different engineering teams are involved.
All activities exist concurrently but reside in different states.
For example, early in the project the communication activity has completed its first iteration and
exists in the awaiting changes state. The modeling activity which existed in the none state
while initial communication was completed now makes a transition into underdevelopment
state.

34
If, however, the customer indicates the changes in requirements must be made, the modeling
activity moves from the under development state into the awaiting changes state.
The concurrent process model defines a series of events that will trigger transitions from
state to state for each of the Software engineering activities, actions, or tasks
Figure above provides a schematic representation of one Software engineering task within the
modeling activity for the concurrent process model. The activity – modeling- may be in any one
of the states noted at any given time.
Specialized Process Models
1 Component BasedDevelopment
Under review
Baselined
Done
Under
revision
Await ing
changes
Under
development
none
Modeling act ivit y
represents the state
of a software engineering
activity or task

35
Commercial off-the-shelf (COTS) Software components, developed by vendors who offer them
as products, can be used when Software is to be built. These components provide targeted
functionality with well-defined interfaces that enable the component to be integrated into the
Software.
The component-based development model incorporates many of the characteristics of the spiral
model.
The component-based development model incorporates the following steps:
 Available component-based products are researched and evaluated for the application
domain in question.
 Component integration issues are considered.
 Software architecture is designed to accommodate the components.
 Components are integrated into the architecture.
 Comprehensive testing is conducted to ensure proper functionality.
The component-based development model leads to Software reuse, and reusability provides
Software engineers with a number of measurable benefits.
2 The Formal Methods Model
The Formal Methods Model encompasses a set of activities that leads to formal mathematical
specifications of Software.
Formal methods enable a Software engineer to specify, develop, and verify a computer-based
system by applying a rigorous, mathematical notation.
A variation of this approach, called clean-room Software engineering is currently applied by
some software development organizations.
Although not a mainstream approach, the formal methods model offers the promise of defect-
free Software. Yet, concern about its applicability in a business environment has been voiced:
 The development of formal models is currently quite time-consuming and expensive.
 B/C few software developers have the necessary background to apply formal methods,
extensive training is required.
 It is difficult to use the methods as a communication mechanism for technically
unsophisticated customers.

36
3 Aspect-Oriented Software Development
Regardless of the software process that is chosen, the builders of complex software invariably
implement a set of localized features, functions, and information content. For further information
read book page 61.
The Unified Process
A “use-case driven, architecture-centric, iterative and incremental” software process closely
aligned with the Unified Modeling Language (UML).
The UP is an attempt to draw on the best features and characteristics of conventional software
process models, but characterize them in a way that implements many of the best principles of
agile software development.
The UP recognizes the importance of customer communication and streamlined methods for
describing the customer’s view of a system.
It emphasizes the important role of software architecture and “helps the architect focus on the
right goals, such as understandability, reliance to future changes, and reuse.”
UML provides the necessary technology to support Object Oriented Software Engineering
practice, but it doesn’t provide the process framework to guide project teams in their application
of the technology.

37
soft ware increment
Release
Incept ion
Elabor at ion
const r uct ion
t r ansit ion
pr oduct ion
The UML developers developed the Unified Process, a framework Object Oriented Software
Engineering using UML.
3.6.2 Phases of the Unified Process
The figure below depicts the phases of the UP and relates them to the generic activities.
The Inception phase of the UP encompasses both customer communication and planning
activities.
By collaborating with the customer and end-users, business requirements for the software are
identified, a rough architecture for the system is proposed, and a plan for the iterative,
incremental nature of the ensuing project is developed.

38
Inception Elaboration Construction Transition Production
UP Phases
Workflows
Requirements
Analysis
Design
Implementation
Test
Iterations #1 #2 #n-1 #n
Support
A use-case describes a sequence of actions that are performed by an actor (person, machine,
another system) as the actor interacts with the Software.
The elaboration phase encompasses the customer communication and modeling activities of the
generic process model. Elaboration refines and expands the preliminary use-cases that were
developed as part of the inception phase and expands the architectural representation to include
five different views of the software - the use-case model, the analysis model, the design model,
the implementation model, and the deployment model.
The construction phase of the UP is identical to the construction activity defined for the generic
software process.
Using the architectural model as input, the construction phase develops or acquires the software
components that will make each use-case operational for end-users.
The transition phase of the UP encompasses the latter stages of the generic construction activity
and the first part of the generic deployment activity.
Software is given to end-users for beta testing, and user feedback reports both defects and
necessary changes.
At the conclusion of the transition phase, the software increment becomes a usable software
release “user manuals, trouble-shooting guides, and installation procedures.)
The production phase of the UP coincides with the development activity of the generic process.
The on-going use of the software is monitored, support for the operating environment is provided
and defect reports and requests for changes are submitted and evaluated.

39
A Software Engineering workflow is distributed across all UP phases.
CMMI (Capability Maturity Model Integration)
 Capability Maturity Model Integration (CMMI) is a process improvement training and
appraisal program.
 CMMI can be used to guide process improvement across a project, division, or an entire
organization.
 Under the CMMI methodology, processes are rated according to their maturity levels,
which are defined as: Incomplete (Initial), Performed, Managed, Defined, Quantitatively
Managed, Optimized.
 Currently supported is CMMI Version 1.3.
 CMMI was developed by a group of experts from industry, government, and the Software
Engineering Institute (SEI) .
 CMMI models provide guidance for developing or improving processes that meet the
business goals of an organization.
 A CMMI model may also be used as a framework for appraising the process maturity of
the organization.
 CMMI exists in two representations:
1) continuous and
2) staged.
Continuous:
The continuous representation is designed to allow the user to focus on the specific processes
that are considered important for the organization's immediate business objectives, or those to
which the organization assigns a high degree of risks.
• Lets organization select specific improvement that best meet its business objectives and
minimize risk
• Levels are called capability levels.
• Describes a process in 2 dimensions
• Each process area is assessed against specific goals and practices and is rated according
to the following capability levels.
• Allows you to select the order of improvement that best meets your organization’s
business objectives and mitigates your organization’s areas of risk
• Enables comparisons across and among organizations on a process-area-by-process-area
basis
• Provides an easy migration from other models with a continuous representation to CMMI

40
• Indicates improvement within a single process area -- to answer,
• “What is a good order for approaching improvement of this process area?”
CAPABILITY LEVELS :
Each process area (e.g., project planning or requirements management) is formally assessed
against specific goals and practices and is rated according to the following capability levels:
Level 0: Incomplete—the process area (e.g., requirements management) is either not performed
or does not achieve all goals and objectives defined by the CMMI for level 1 capability for the
process area.
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 capability 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; stakeholders are actively
involved in the process area as required; all work tasks and work products are “monitored,
controlled, and reviewed; and are evaluated for adherence to the process description” [CMM07].
Level 3: Defined—all capability level 2 criteria have been achieved. In addition, the process is
“tailored from the organization’s set of standard processes according to the organization’s
tailoring guidelines, and contributes work products, measures, and other process-improvement
information to the organizational process assets” [CMM07].
Level 4: Quantitatively managed—all capability level 3 criteria have been achieved. In addition,
the process area is controlled and improved using measurement and quantitative assessment.
“Quantitative objectives for quality and process performance are established and used as criteria
in managing the process” [CMM07].
Level 5: Optimized—all capability level 4 criteria have been achieved. In addition, the process
area is adapted and optimized using quantitative (statistical) means to meet changing customer
needs and to continually improve the efficacy of the process area under consideration.

41
Continuous process improvement based on quantitative feed back from the user ,Use of
innovative ideas and techniques, statistical quality control and other methods for process
improvement
The CMMI defines each process area in terms of “specific goals” and the “specific practices”
required to achieve these goals. Specific goals establish the characteristics that must exist if the
activities implied by a process area are to be effective. Specific practices refine a goal into a set
of process-related activities
2 STAGED REPRESENTATION
 The staged representation is designed to provide a standard sequence of improvements,
and can serve as a basis for comparing the maturity of different projects and
organizations
 Provides a proven sequence of improvements, each serving as a foundation for the next
 Permits comparisons across and among organizations by the use of maturity levels

 Indicates maturity of an organization’s standard process -- to answer
 “What is a good order for approaching improvement across the organization?”

42
 The CMMI principal is that “the quality of a system or product is highly influenced by
the process used to develop and maintain it”.
Maturity levels
LEVEL FOCUS PROCESS AREA
Optimizing Continuous process
Improvement
-Organizational Innovation and
Deployment
-Causal Analysis and Resolution
Quantitatively
managed
Quantitative
management
-Organizational process performance
-Quantitative project management
Defined Process
standardized
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Risk Management
− Integrated Teaming
− Integrated Supplier Management
− Decision Analysis and Resolution
− Organizational Environment for Integration

43
Managed Basic project
management
Requirements Management
Project Planning
Project Monitoring and Control
Supplier Agreement
Measurement and Analysis
Process and Product
Quality Assurance
Configuration Management
Performed
There are five CMMI maturity levels (five point grading scheme.)However, maturity level
ratings are only awarded for levels 2 through 5.
The SEI has associated key process areas (KPAs) with each of the maturity levels.
The KPAs describe those software engineering functions (e.g., software project planning,
requirements management) that must be present to satisfy good practice at a
particular level.
Each KPA is described by identifying the following characteristics:
• Goals—the overall objectives that the KPA must achieve.
• Commitments—requirements (imposed on the organization) that must be met to achieve the
goals or provide proof of intent to comply with the goals.
• Abilities—those things that must be in place (organizationally and technically) to enable the
organization to meet the commitments.
• Activities—the specific tasks required to achieve the KPA function.
• Methods for monitoring implementation—the manner in which the activities are monitored as
they are put into place.
• Methods for verifying implementation—the manner in which proper practice for the KPA can
be verified.
Eighteen KPAs (each described using these characteristics) are defined across the maturity
model and mapped into different levels of process maturity
Process Assessment
The intent of assessment is to uncover both strengths and weaknesses in the way your
organization applies the existing software process and the software engineering practices that
populate the process. Assessment examines a wide range of actions and tasks that will lead to a
high quality process

44
Each is considered within the context of the framework and umbrella activities that have been
established and is assessed to determine whether each of the following questions has been
addressed:
• Is the objective of the action clearly defined?
• Are work products required as input and produced as output identified and described?
• Are the work tasks to be performed clearly described?
• Are the people who must perform the action identified by role?
• Have entry and exit criteria been established?
• Have metrics for the action been established?
• Are tools available to support the action?
• Is there an explicit training program that addresses the action?
• Is the action performed uniformly for all projects?
Although the questions noted imply a yes or no answer, the role of assessment is to look behind
the answer to determine whether the action in question is being performed in a manner that
would conform to best practice.
As the process assessment is conducted, you (or those who have been hired to perform the
assessment) should also focus on the following attributes:
Consistency. Are important activities, actions, and tasks applied consistently across all software
projects and by all software teams?
Sophistication. Are management and technical actions performed with a level of sophistication
that implies a thorough understanding of best practice?
Acceptance. Is the software process and software engineering practice widely accepted by
management and technical staff?
Commitment. Has management committed the resources required to achieve consistency,
sophistication, and acceptance?
refer ppt of software process assessment

45
Standard CMMI Assessment Method for Process Improvement (SCAMPI)—provides a
five-step process assessment model that incorporates five phases: initiating, diagnosing,
establishing, acting, and learning. The SCAMPI method uses the SEI CMMI as the basis for
assessment
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)— provides a
diagnostic technique for assessing the relative maturity of a software organization; uses the SEI
CMM as the basis for the assessment
SPICE (ISO/IEC15504)—a standard that defines a set of requirements for software process
assessment. The intent of the standard is to assist organizations in developing an objective
evaluation of the efficacy of any defined software process
SPICE. The SPICE (Software Process Improvement and Capability dEtermination) model
provides an SPI assessment framework that is compliant with ISO 15504:2003 and ISO 12207.
The SPICE document suite [SDS08] presents a complete SPI framework including a model for
process management, guidelines for conducting an assessment and rating the process under
consideration, construction, selection, and use of assessment instruments and tools, and training
for assessors.
Bootstrap. The Bootstrap SPI framework “has been developed to ensure conformance with the
emerging ISO standard for software process assessment and improvement (SPICE) and to align
the methodology with ISO 12207” [Boo06]. The objective of Bootstrap is to evaluate a software
process using a set of software engineering best practices as a basis for assessment. Like the
CMMI, Bootstrap provides a process maturity level using the results of questionnaires that gather

46
information about the “as is” software process and software projects. SPI guidelines are based on
maturity level and organizational goals.
PSP and TSP. Although SPI is generally characterized as an organizational activity, there is no
reason why process improvement cannot be conducted at an individual or team level. Both PSP
and TSP (Chapter 2) emphasize the need to continuously collect data about the work that is being
performed and to use that data to develop strategies for improvement. Watts Humphrey
[Hum97], the developer of
both methods, comments: The PSP [and TSP] will show you how to plan and track your work
and how to consistently produce high quality software. Using PSP [and TSP] will give you the
data that show the effectiveness of your work and identify your strengths and weaknesses. . . . To
have a successful and rewarding career, you need to know your skills and abilities, strive to
improve them, and capitalize on your unique talents in the work you do.
TickIT. The Ticket auditing method ensures compliance with ISO 9001:2000 for Software—a
generic standard that applies to any organization that wants to improve the overall quality of the
products, systems, or services that it provides. Therefore, the standard is directly applicable to
software organizations and companies.
ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to
improve the overall quality of the products, systems, or services that it provides. Therefore, the
standard is directly applicable to software organizations and companies
The underlying strategy suggested by ISO 9001:2000 is described in the following manner
ISO 9001:2000 stresses the importance for an organization to identify, implement, manage and
continually improve the effectiveness of the processes that are necessary for the quality
management system, and to manage the interactions of these processes in order to achieve the
organization’s objectives. Process effectiveness and efficiency can be assessed through internal
or external review processes and be evaluated on a maturity scale.
ISO 9001:2000 has adopted a “plan-do-check-act” cycle that is applied to the quality
management elements of a software project. Within a software context, “plan” establishes the
process objectives, activities, and tasks necessary to achieve highquality software and resultant
customer satisfaction. “Do” implements the software process (including both framework and
umbrella activities). “Check” monitors and measures the process to ensure that all requirements
established for quality management have been achieved. “Act” initiates software process
improvement activities that continually work to improve the process
The best software process is one that is close to the people who will be doing the work. If a
software process model has been developed at a corporate or organizational level, it can be
effective only if it is amenable to significant adaptation to meet the needs of the project team
that is actually doing software engineering work. In an ideal setting, you would create a process
that best fits your needs, and at the same time, meets the broader needs of the team and the
organization. Alternatively, the team itself can create its own process, and at the same time meet
the narrower needs of individuals and the broader needs of the organization. Watts Humphrey
and argues that it is possible to create a “personal software process” and/or a “team software
process.” Both require hard work, training, and coordination,
but both are achievable.

47
Personal Software Process (PSP)
The Personal Software Process (PSP) emphasizes personal measurement of both the work
product that is produced and the resultant quality of the work product. In addition PSP makes the
practitioner responsible for project planning (e.g., estimating and scheduling) and empowers the
practitioner to control the quality of all software work products that are developed.
The Personal Software Process (PSP) shows engineers how to
- manage the quality of their projects
- make commitments they can meet
- improve estimating and planning
- reduce defects in their products
The PSP model defines five framework activities:
Planning. This activity isolates requirements and develops both size and resource estimates. In
addition, a defect estimate (the number of defects projected for the work) is made. All metrics
are recorded on worksheets or templates. Finally, development tasks are identified and a project
schedule is created.
High-level design. External specifications for each component to be constructed are developed
and a component design is created. Prototypes are built when uncertainty exists. All issues are
recorded and tracked.
High-level design review. Formal verification methods are applied to uncover errors in the
design. Metrics are maintained for all important tasks and work results.
Development. The component-level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.
Postmortem. Using the measures and metrics collected (this is a substantial amount of data that
should be analyzed statistically), the effectiveness of the process is determined. Measures and
metrics should provide guidance for modifying the process to improve its effectiveness. PSP
stresses the need to identify errors early and, just as important, to understand the types of errors
that you are likely to make. This is accomplished through a rigorous assessment activity
performed on all work products you produce.
PSP emphasizes the need to record and analyze the types of errors you make, so you can develop
strategies eliminate them.
PSP represents a disciplined, metrics-based approach to software engineering that may lead to
culture shock for many practitioners. PSP result in improvement of software engineering
productivity and software quality are significant Based on practices found in the CMMI, the PSP
can be used by engineers as a guide to a disciplined and structured approach to developing
software. The PSP is a prerequisite for an organization planning to introduce the TSP.

48
The PSP can be applied to many parts of the software development process, including
- small-program development
- requirement definition
- document writing
- systems tests
- systems maintenance
- enhancement of large software systems
However, PSP has not been widely adopted throughout the industry. The reasons, sadly, have
more to do with human nature and organizational inertia than they do with the strengths and
weaknesses of the PSP approach. PSP is intellectually challenging and demands a level of
commitment (by practitioners and their managers) that is not always possible to obtain. Training
is relatively lengthy, and training costs are high.
2.6.2 Team Software Process (TSP)
Watts Humphrey extended the lessons learned from the introduction of PSP and proposed a
Team Software Process (TSP). The goal of TSP is to build a “selfdirected” project team that
organizes itself to produce high-quality software.
The Team Software Process (TSP), along with the Personal Software Process, helps the high-
performance engineer to
- ensure quality software products
- create secure software products
- improve process management in an organization
Humphrey [Hum98] defines the following objectives for TSP:
- Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams (IPTs)
of 3 to about 20 engineers.
- Show managers how to coach and motivate their teams and how to help them sustain
peak performance.
- Accelerate software process improvement by making CMM23 Level 5 behavior normal
and expected.
- Provide improvement guidance to high-maturity organizations.
- Facilitate university teaching of industrial-grade team skills.
self-directed teams
1. A self-directed team has a consistent understanding of its overall goals and objectives;
2. defines roles and responsibilities for each team member;
3. tracks quantitative project data (about productivity and quality);
4. identifies a team process that is appropriate for the project and a strategy for
implementing the process;
5. defines local standards that are applicable to the team’s software engineering work;
continually assesses risk and reacts to it; and
6. tracks, manages, and reports project status.

49
TSP defines the following framework activities:
1. project launch,
2. high-level design,
3. implementation,
4. integration and test, and
5. postmortem.
Like their counterparts in PSP (note that terminology is somewhat different), these activities
enable the team to plan, design, and construct software in a disciplined manner while at the same
time quantitatively measuring the process and the product. The postmortem sets the stage for
process improvements. TSP makes use of a wide variety of scripts, forms, and standards that
serve to guideteam members in their work. “Scripts” define specific process activities (i.e.,
project launch, design, implementation, integration and system testing, postmortem) and other
more detailed work functions (e.g., development planning, requirements development, software
configuration management, unit test) that are part of the team process.
TSP recognizes that the best software teams are self-directed.24 Team membersset project
objectives, adapt the process to meet their needs, control the project schedule, and through
measurement and analysis of the metrics collected, work continually to improve the team’s
approach to software engineering.
Like PSP, TSP is a rigorous approach to software engineering that provides distinct and
quantifiable benefits in productivity and quality. The team must make a full commitment to the
process and must undergo thorough training to ensure that the
approach is properly applied.
Engineering groups use the TSP to apply integrated team concepts to the development of
software-intensive systems. A launch process walks teams and their managers through
- establishing goals
- defining team roles

50
- assessing risks
- producing a team plan
Benefits of TSP
 The TSP provides a defined process framework for managing, tracking and reporting the
team's progress.
 Using TSP, an organization can build self-directed teams that plan and track their work,
establish goals, and own their processes and plans. These can be pure software teams or
integrated product teams of 3 to 20 engineers.
 TSP will help your organization establish a mature and disciplined engineering practice
that produces secure, reliable software.

Evolving role of Software,Legacy software,CASE tools,Process Models,CMMI

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Evolving role of Software,Legacy software,CASE tools,Process Models,CMMI

Ähnlich wie Evolving role of Software,Legacy software,CASE tools,Process Models,CMMI (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Evolving role of Software,Legacy software,CASE tools,Process Models,CMMI