Module 1 Topics: 1. The Evolving Role of Software

Dept of Computer Science and Engineering
CML
Module 1 Topics
1. The Evolving role of Software

2. Software The changing Nature of Software -Legacy software
3. Software Engineering A layered Technology
4. A Process Framework
5. A generic view of process
6. Process Assessment
7. Personal and Team Process Models
8. Product and Process
9. The Capability Maturity Model Integration (CMMI)
10. Introduction to CASE tools
11. 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 Unified Process.
1. The Evolving role of Software

Software has a dual role. Software is a product and also the vehicle for delivering a product.
As a product, it delivers the computing potential embodied by computer hardware or, more
broadly, a network of computers that are accessible by local hardware. Sometimes software
resides within a cellular phone or operates inside a mainframe computer. Software is an
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. As the vehicle used to deliver the product, software acts as the basis for the control
of the computer (operating systems), the communication of information (networks), and the
creation and control of other programs (software tools and environments).
Software delivers the most important product of our timeinformation. Some of the
functions of Software are:-
1. It transforms personal data so that the data can be more useful in a local context;
2. It manages business information to enhance competitiveness;
3. It provides a gateway to worldwide information networks and provides the means for
acquiring information in all of its forms.
The role of computer software has undergone significant change over a time span of little
more than 50 years. Dramatic improvements in hardware performance, pro found 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-
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:1 Prepared By:
Merin Mary Philip
CML
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.
Popular books published during the 1970s and 1980s provide useful historical insight into
the changing perception of computers and software and their impact on our culture. Osborne
characterized a "new industrial revolution." Toffler called the advent of microelectronics part of
"the third wave of change" in human history, and Naisbitt predicted a transformation from an
industrial society to an "information society." Feigenbaum and McCorduck suggested that
information and knowledge (controlled by computers) would be the focal point for power in the
twenty-first century, and Stoll argued that the "electronic community" created by networks and
software was the key to knowledge interchange throughout the world.
As the 1990s began, Toffler described a "power shift" in which old power structures
disintegrate as computers and software lead to a "democratization of knowledge." Yourdon
worried that U.S. companies might loose their competitive edge in software related businesses
and predicted the decline and fall of the American programmer. Hammer and Champy argued
that information technologies were to play a pivotal role in the reengineering of the
corporation. During the mid-1990s, the pervasiveness of computers and software spawned a
rash of books by neo-Luddites. These authors demonized the computer, emphasizing legitimate
concerns but ignoring the profound benefits that have already been realized.
During the later 1990s, Yourdon re-evaluated the prospects for the software professional and
suggested the the rise and resurrection of the American programmer. As the Internet grew in
importance, his change of heart proved to be correct. As the twentieth century closed, the focus
shifted once more, this time to the impact of the Y2K time bomb . Although the predictions of
the Y2K doomsayers were incorrect, their popular writings drove home the pervasiveness of
software in our lives. Today, ubiquitous computing has spawned a generation of information
appliances that have broadband connectivity to the Web to provide a blanket of connectedness
over our homes, offices and motorways. Softwares role continues to expand.
The lone programmer of an earlier era has been replaced by a team of software specialists,
each focusing on one part of the technology required to deliver a complex application. And yet,
the same questions asked of the lone programmer are being asked when modern computer-based
systems are built:
Why does it take so long to get software finished?
Why are development costs so high?
Why can't we find all the errors before we give the software to customers?
Why do we continue to have difficulty in measuring progress as software is
being developed?
__________________________________________________________________________________________
Merin Mary Philip
CML
2. Software The changing Nature of Software

Software has a dual role. Software is a product and also the vehicle for delivering a product.
As a product, it delivers the computing potential embodied by computer hardware or, more
broadly, a network of computers that are accessible by local hardware. Sometimes software
resides within a cellular phone or operates inside a mainframe computer. Software is an
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. As the vehicle used to deliver the product, software acts as the basis for the control
of the computer (operating systems), the communication of information (networks), and the
creation and control of other programs (software tools and environments).
Software delivers the most important product of our timeinformation. Some of the
functions of Software are:-
1. It transforms personal data so that the data can be more useful in a local context;
2. It manages business information to enhance competitiveness;
3. It provides a gateway to worldwide information networks and provides the means for
acquiring information in all of its forms.
The role of computer software has undergone significant change over the last half-
century. Dramatic improvements in hardware performance, pro found 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.
Today . a huge software industry has become a dominant factor in the economics of the
industrialized world. Teams of software specialists , each focusing on one part of the technology
required to deliver a complex application, have replaced the lone programmer of an earlier era.
And yet, the same questions asked of the lone programmer are being asked when modern
computer-based systems are built:
Why does it take so long to get software finished?
Why are development costs so high?
Why can't we find all the errors before we give the software to customers?
Why do we continue to have difficulty in measuring progress as software is
being developed?
These, and many other questions, are a manifestation of the concern about software and the
manner in which it is developeda concern that has lead to the adoption
__________________________________________________________________________________________
Merin Mary Philip
CML
of software engineering practice.
The changing Nature of Software can be discussed under these three suptopics:-
2.1. Defining Software
2.2. Software Application Domains
2.3 Legacy Software
2.1. Defining Software
Software is (1) instructions (computer programs) that when executed provide desired function and
performance, (2) data structures that enable the programs to adequately manipulate information, and (3)
documents that describe the operation and use of the programs.
To gain an understanding of software , it is important to examine the characteristics of software
that make it different from other things that human beings build. When hardware is built, the human
creative process (analysis, design, construction, testing) is ultimately translated into a physical form.
Software is a logical rather than a physical system element. Therefore, software has characteristics that
are considerably different than those of hardware and they are:
I. Software is developed or engineered, it is not manufactured in the classical sense.
Although some similarities exist between software development and hardware manufacture, the
two activities are fundamentally different. In both activities, high quality is achieved through good
design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent
(or easily corrected) for software. Both activities are dependent on people, but the relationship between
people applied and work accomplished is entirely different. Both activities require the construction of a
"product" but the approaches are different. Software costs are concentrated in engineering. This means
that software projects cannot be managed as if they were manufacturing projects.
II. Software doesn't "wear out."
Figure 1.1 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;
defects are corrected and the failure rate drops to a steady-state level (ideally, quite low) for some
period of time. As time passes, however, the failure rate rises again as hardware components suffer
from the cumulative affects 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 1.2. Undiscovered defects will cause high failure rates early in the life of a program.
However, these are corrected (ideally, without introducing other errors) and the curve flattens as
shown. However, the implication is clearsoftware doesn't wear out. But it does deteriorate!
__________________________________________________________________________________________
Merin Mary Philip
CML
Figure 1.1 Failure curve for hardware

This seeming contradiction can best be explained by considering the actual curve shown in
Figure 1.2. During its life, software will undergo change (maintenance). As changes are made, it is
likely that some new defects will be introduced, causing the failure rate curve to spike as shown in
Figure 1.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 risethe
software is deteriorating due to change. Another aspect of wear illustrates the difference between
hardware and software. When a hardware component wears out, it is replaced by a spare part. There are
no software spare parts. Every software failure indicates an error in design or in the process through
which design was translated into machine executable code. Therefore, software maintenance involves
considerably more complexity than hardware maintenance.
Figure 1.2 Failure curves for Software
__________________________________________________________________________________________
Merin Mary Philip
CML
III . Although the industry is moving toward component-based assembly, most software continues
to be custom built.
As an engineering discipline evolves, a collection of standard design components is created.
Standard screws and off-the-shelf integrated circuits are only two of thousands of standard components
that are used by mechanical and electrical engineers as they design new systems. The reusable
components have been created so that the engineer can concentrate on the truly innovative elements of a
design, that is, the parts of the design that represent something new. In the hardware world, component
reuse is a natural part of the engineering process. In the software world, it is something that has only
begun to be achieved on a broad scale.
A software component should be designed and implemented so that it can be reused in many
different programs. Modern reusable components encapsulate both data and the processing applied to
the data, enabling the software engineer to create new applications from reusable parts. For example,
today's graphical user interfaces are built using reusable components that enable the creation of graphics
windows, pull-down menus, and a wide variety of interaction mechanisms. The data structure and
processing detail required to build the interface are contained with a library of reusable components for
interface construction.
2.2. Software Application Domains

Seven categories of computer software present continuing challenges for software engineers. Seven
Software application domains are:-
i. System software
ii. Application software
iii. Engineering/scientific software
iv. Embedded software
v. Product-line software
vi. Web applications
vii. Artificial intelligence software
i. System software
System software is a collection of programs written to service other programs. Some system
software (e.g., compilers, editors, and file management utilities) process complex , but determinate,
information structures. Other systems applications (e.g., operating system components, drivers,
telecommunications processors) process largely indeterminate data. The system software area is
characterized by:-
Heavy interaction with computer hardware
Heavy usage by multiple users
__________________________________________________________________________________________
Merin Mary Philip
CML
Concurrent operation that requires scheduling

Resource sharing
Sophisticated process management
Complex data structures
Multiple external interfaces.
ii. Application Software
They are stand alone programs that solve a specific business need. Application Software is used
to control business functions in real time.
iii. Engineering and scientific software
Engineering and scientific software have been characterized by "number crunching" algorithms.
Computer-aided design, system simulation, and other interactive applications have begun to
take on real-time and even system software characteristics.
iv. Embedded software
Embedded software resides within a product or system and is used to implement and control
features and functions for the end user and for the system itself. Embedded software can
perform very limited and esoteric functions (e.g., keypad control for a microwave oven) or
provide significant function and control capability (e.g., digital functions in an automobile such
as fuel control, dashboard displays, and braking systems).
v. Product-line software
Product-line software are designed to provide a specific capability for use by different
customers. Product-line software can focus on a limited marketplace or address mass consumer
markets. Examples of product-line software are Word-processing, spreadsheets, computer
graphics, multimedia, database management.
vi. Web applications
Web applications are called web-apps. Web apps are evolving into a sophisticated computing
environment which provides stand alone features, computing functions and content to the end
user. They are also integrated with corporate databases and business applications.
vii. Artificial intelligence software
Artificial intelligence (AI) software makes use of nonnumeric algorithms to solve complex
problems that are not amenable to computation or straightforward analysis. Expert systems, also
called knowledge based systems, pattern recognition (image and voice), artificial neural
networks, theorem proving, and game playing are representative of applications within this
category.
__________________________________________________________________________________________
Merin Mary Philip
CML
2.3 Legacy Software

Older Programs are referred to as legacy software. They were developed decades ago and have
been continually modified to meet the changes in business requirements and computing platforms.
They support core business functions. They have longevity and business criticality. Sometimes they
exhibit poor quality. Some of their characteristics are:-
Inextensible design
Convoluted code
Poor documentation
Poor testing
Poor change management
Legacy software evolves (changes are made) as time passes because 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.
3. Software Engineering A layered Technology

Inorder to develop software which will meet the challenges we must recognize a few simple
realities:-
Concentrated effort must be made to understand the problem before a software solution is
developed.
Design is a pivotal activity in software engineering process so it be done properly.
Software which is developed should exhibit high quality.
Software which is developed should be maintainable.
A definition of Software Engineering by Fritz Bauer states that
(i) Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines
IEEE has developed another definition for Software Engineering
(ii) The application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application of engineering to software
Software engineering is a layered technology. Figure (i) shows software engg. Layers. Different Layers
are:
1. Quality Focus
2. Process
3. Methods
__________________________________________________________________________________________
Merin Mary Philip
CML
4. Tools
Figure (i) Software Engineering Layers

1. Quality Focus
The bedrock that supports software engineering is a quality focus.
2. Process
The foundation for software engineering is the process layer. 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 for a set of key process areas that must be established for
effective delivery of software engineering technology. The key process areas form the basis for
management control of software projects and establish the context in which technical methods are
applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are
established, quality is ensured, and change is properly managed. Software engineering methods provide
the technical how-to's for building software.
3. Methods
Methods encompass a broad array of tasks that include requirements analysis, design, program
construction, testing, and support. Software engineering methods rely on a set of basic principles that
govern each area of the technology and include modeling activities and other descriptive techniques.
4. Tools
Software engineering tools provide automated or semi-automated support for the process and the
methods. 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 (CASE), is
established. CASE combines software, hardware, and a software engineering database (a repository
containing important information about analysis, design, program construction, and testing) to create a
software engineering environment analogous to CAD/CAE (computer-aided design/engineering) for
hardware.
__________________________________________________________________________________________
Merin Mary Philip
CML
4.A Process Framework

A software process can be characterized as shown in Figure 2.2. A process is a collection of
activities, actions, tasks that are performed when some work product is to be created.
An activity achieve a broad objective 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. Eg -Communication with stakeholders
An action encompasses a set of tasks that produce a major work product. Eg-Architectural
Design
A task focuses on a small, but well defined objective that produces a tangible outcome. Eg-
Conducting a unit test.
A common 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. The process framework also encompasses a set of umbrella
activities that are applicable across the entire software process. A generic process framework for
software engineering encompasses 5 activities:-
1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
1. Communication
Involves communication among the customer and other stake holders; encompasses
requirements gathering.
The purpose of communication is to understand stakeholders objectives for the project
and to gather requirements that help define software features and functions.
2. Planning
Planning activity creates a map that helps the software team as it makes journey.
This plan is called software project plan.
Software project plan defines the software engineering work by describing the technical
task to be conducted, the risks involved, resources that will be required, work products
to be produced , and a work schedule.
3. Modeling (Analyze, Design)
Encompasses the creation of models to better understand the requirements and the
design.
__________________________________________________________________________________________
Merin Mary Philip
CML
Software process
Process Framework
Umbrella activities
Framework activity # 1
Software engineering action #1.1
Work tasks
Task sets Work products
Quality assurance points
. Project milestones
.
Software engineering action #1.k
Work tasks
Work products
Task sets Quality assurance points
Project milestones
.
.
.
Framework activity # n
Software engineering action #n.1
Work tasks
.
Software engineering action #n.m
Work tasks
Project milestones
Figure 2.2 A software process Framework

4.Construction (Code, Test)
Combines code generation and testing to uncover errors.
5.Deployment
Involves delivery of software to the customer.
Customer evaluates the delivered product and provides feedback based on evaluation.
These 5 framework activities are used during the development of software. Sometimes these are
repeatedly applied through a number of project iterations. Each project iteration produces a software
__________________________________________________________________________________________
Merin Mary Philip
CML
increment that provides customers with a subset of overall software features and functionality. As each
increment is produced, the software becomes more and more complete.
Software engineering process framework activities are complemented by a number of Umbrella
activities. Typical umbrella activities are:-
1. Software project tracking and control
2. Risk management
3. Software quality assurance
4. Technical reviews
5. Measurement
6. Software configuration management
7. Reusability management
8. Work product preparation and production
1. Software project tracking and control

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.
2. Risk management
Risk management assesses risks that may affect the outcome of the project or the quality of the product.
3. Software quality assurance
Software quality assurance defines and conducts the activities required to ensure software quality.
4. Technical reviews
Technical reviews assess software engineering work products in an effort to uncover errors before they
are propagated to the next activity.
5. Measurement
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
Software configuration management manages the effects of change throughout the software process.
7. Reusability management
Reusability management defines criteria for work product reuse and establishes mechanisms to achieve
reusable components.
8. Work product preparation and production
It encompasses the activities required to create work products such as models, documents, logs, forms
and lists.
__________________________________________________________________________________________
Merin Mary Philip
CML
A process adopted for one project might be significantly different than a process adopted for another
project. Some of the differences are:-
1. Flow of activities, actions and tasks and interdependencies among them.
2. Degree to which actions and tasks are defined within each framework activity.
3. Degree to which work products are identified and required.
4. Degree to which customer and stakeholder are involved with the project.
5. Degree of detail and rigor with which process is described.
6. Degree to which team organization and roles are prescribed.
7. Manner in which quality assurance activities are applied.
8. Manner in which project tracking and control activities are applied.
9. Level of autonomy given to the software team.
5. A generic view of process ( A generic Process Model)

A process is a collection of activities, actions, tasks that are performed when some work product
is to be created. A generic process framework for software engineering defines five framework
activities-communication, planning, modeling, construction, and deployment. In addition, a set of
umbrella activities- project tracking and control, risk management, quality assurance, configuration
management, technical reviews, and others are applied throughout the process.. Figure 2.3 illustrates
software process framework.
__________________________________________________________________________________________
Merin Mary Philip
CML
Software process
Process Framework
Umbrella activities
Framework activity # 1
Software engineering action #1.1
Work tasks
.
Software engineering action #1.k
Work tasks
Work products
Task sets Quality assurance points
Project milestones
.
.
.
Framework activity # n
Software engineering action #n.1
Work tasks
.
Software engineering action #n.m
Work tasks
Project milestones
Figure 2.3 A software process Framework
The framework activities and the actions and tasks that occur within each activity are organized with
respect to sequence and time. This aspect is called process flow. Different kinds of Process flows are:
1. Linear process flow
2. iterative process flow
3. evolutionary process flow
4. parallel process flow
Linear process flow executes each of the five activities in sequence.
__________________________________________________________________________________________
Merin Mary Philip
CML
An iterative process flow repeats one or more of the activities before proceeding to the next.
An evolutionary process flow executes the activities in a circular manner. Each circuit leads to
a more complete version of the software.
A parallel process flow executes one or more activities in parallel with other activities
( modeling for one aspect of the software in parallel with construction of another aspect of the
software.
Figure (b) shows Different kinds of process flow
Figure (b) Different kinds of process flow
A software team would need significantly have to carry out these three steps as a part of software
process:-
5.1 Defining a framework Activity
5.2 Identifying a Task set
5.3 Process Patterns
__________________________________________________________________________________________
Merin Mary Philip
CML
5.1 Defining a framework Activity

Before defining a framework activity we have to consider these questions:-
o What actions are appropriate for a framework activity, given the nature of a problem
to be solved.
o What are the characteristics of the people doing the work?
o Who are the stakeholders sponsoring the project?
A small project requested by one person with simple , straightforward requirements , the
communication activity might encompass action phone conversation and work task (the task set)
that this action includes are:-
1. Make contact with stakeholder via telephone
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.
If the project was considerably more complex with many stakeholders, the communication activity
might have 6 distinct actions:- inception, elicitation, elaboration, negotiation, specification and
validation. The task sets for Requirements gathering action for a simple project may include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.
The task sets for Requirements gathering action for a big project may include:
7. Make a list of stakeholders for the project.
8. Interview each stakeholders separately to determine overall wants and needs.
9. Build a preliminary list of functions and features based on stakeholder input.
10. Schedule a series of facilitated application specification meetings.
11. Conduct meetings.
12. Produce informal user scenarios as part of each meeting.
13. Refine user scenarios based on stakeholder feedback.
14. Build a revised list of stakeholder requirements.
15. Use quality function deployment techniques to prioritize requirements.
16. Package requirements so that they can be delivered incrementally.
__________________________________________________________________________________________
Merin Mary Philip
CML
17. Note constraints and restrictions that will be placed on the system.
18. Discuss methods for validating the system.
5.2 Identifying a Task set
Refer figure 2.3 , each software engineering action can be represented by a number of different
tasks. Each task set consists of:-
A list of the software engineering work task to be accomplished .
A list of the work products to be produced.
A list of the quality assurance points to be applied.
Project milestones
5.3 Process Patterns

A process pattern
describes a process-related problem that is encountered during software engineering
work,
identifies the environment in which the problem has been encountered, and
suggests one or more proven solutions to the problem
A process pattern can be defined at different levels of abstraction
1. Sometimes it may be used to describe a problem and solutions associated with a
complete process model (e.g. prototyping).
2. Sometimes it may be used to describe a problem and solutions associated with a
framework activity (e.g. planning) or an action with a framework activity (e.g.
project estimating).
Process Pattern describes an effective mechanism for addressing problems associated with any
software process. Ambler has proposed a template for describing a process pattern:-
1. Pattern name
2. Forces
3. Type
a. Stage Pattern
b. Task Pattern
c. Phase Pattern
4. Initial context
5. Problem
6. Solution
7. Resulting context
__________________________________________________________________________________________
Merin Mary Philip
CML
8. Related patterns
9. Known Uses and Examples
1.Pattern name
Pattern is given a meaningful name describing it within the context of software process.
2.Forces
Forces describe the environment in which pattern was encountered.
3.Type
The pattern type can be of 3 types:-
a. Stage Pattern- It defines a problem associated with a framework activity for the
process. It includes multiple task patterns as well. For example,
EstablishingCommunication would incorporate the task pattern RequirementsGathering
and others.
b. Task Patterns- defines a problem associated with a software engineering action or work
task and relevant to successful software engineering practice.
c. Phase Pattern-define the sequence of framework activities that occur with the process,
even when the overall flow of activities is iterative in nature. Example includes Sprial
Model or Prototyping.
4.Initial context
Initial context describes the condition under which process pattern is applied. Before the
initiation of pattern ,
1. What activities have occurred?
2. What information already existed?
3. Entry state of the process.
5.Problem
Problem describes the problem to be solved by the pattern.
6.Solution
Solution describes how to implement pattern successfully. This section describes how the
initial state of the process is modified as result of initiation of the pattern.
7.Resulting Context
Resulting Context describes the state after application of process pattern,
1. What activities have occurred after application of pattern?
2. What information have been developed?
3. Exit state of the process.
8. Related patterns
__________________________________________________________________________________________
Merin Mary Philip
CML
Related patterns provide a list of all process patterns that are directly related to a particular
pattern.
9. Known Uses and Examples

This indicate specific instance in which pattern is applicable. If a particular problem occurs
already used pattern are applied.
6. Process Assessment
Software Process cannot guarantee that software will be delivered on time, meet the needs, or
has the desired technical characteristics. However, the process can be assessed to ensure that it
meets a set of basic process criteria that have been shown to be essential for a successful software
engineering. Few approaches for assessing a software process are:-
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.
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.
SPICEThe SPICE (ISO/IEC15504) standard 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.
ISO 9001:2000 for Softwarea 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
7. Personal and Team Process Models

(i) Personal Software Process (PSP)
Every developer uses some process to build a software. It may be effective, not effective,
efficient, not efficient, may or may not change on daily basis.
PSP emphasizes on personal measurement of both work product and resultant quality of
work product.
PSP has 5 framework activities:-
1. Planning
2. High-level design
3. High-level design review
__________________________________________________________________________________________
Merin Mary Philip
CML
4. Development
5. Postmortem
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
Advantages of PSP:-
1. Identify Errors early.
2. Disciplined metrices based approach.
3. Software quality and productivity is increased.
Disadvantages of PSP:-
1. A high level of commitment is required.
2. Training cost and time required both are high.
3. PSP is intellectually very challenging.
(ii) Team Software Process (TSP)
Goal of TSP is to build a self-directed project team that organizes itself to produce high-
quality team that organizes itself to produce high-quality software.
Characteristics of self-directed team are:-
__________________________________________________________________________________________
Merin Mary Philip
CML
1. Consistent understanding of the goals and objectives.

2. Defines roles and responsibilities for each team members.
3. Tracks quantitative project data.
4. Identifies process which is apt for the project and also makes a
strategy for implementing the process.
5. Define local standards that can be applied to teams software engg.
work.
6. Continually assesses risk and reacts to it.
7. Project status is tracked , managed and reported.
TSP defines 5 framework activities :-
1. Project Launch
2. High level design
3. Implementation
4. Integration & Test
5. Postmortem
1.Project Launch
Project Launch enable team to plan.
2.High level design
High level design enable team to design.
3.Implementation
Implementation activity constructs the software.
4.Integration & Test
This activity integrates different modules and test the software.
5.Postmortem
Postmortem sets stage for process improvement.
Different objectives of TSP are:-
i. 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 (IPT) of
three to about 20 engineers.
ii. Show managers how to coach and motivate their teams and how to help them sustain peak
performance.
iii. Accelerate software process improvement by making CMM Level 5 behavior normal and
expected. Provide improvement guidance to high-maturity organizations.
iv. Facilitate university teaching of industrial-grade team skills.
__________________________________________________________________________________________
Merin Mary Philip
CML
TSP makes use of wide variety of scripts, forms and standards that guides team members in their
work. Scripts define specific process activities. TSP identifies that the best software teams are self-
directed. TSP is a rigorous approach to software engineering and provides quantifiable benefits in
productivity and quality.
8. Product and Process
If the process is weak, the end product will undoubtedly suffer, but an obsessive overreliance on
process is also dangerous. A creative software professional should also derive as much satisfaction from
the process as the end-product. The work of software people will change in the years ahead. The duality
of product and process is one important element in keeping creative people engaged as the transition
from programming to software engineering is finalized. Product and process decomposition occur
simultaneously as the project plan evolves. Software quality encompasses many different product and
process factors and related metrics.
9. The Capability Maturity Model Integration (CMMI)
SEI developed a comprehensive process meta-model that is predicated on a set of system &
software engineering capabilities that should be present as organizations reach different levels
of process capability and maturity
To achieve these capabilities, the SEI contends that an organization should develop a process
model that conforms to the Capability Maturity Model Integration (CMMI).
CMMI represents a process meta-model in two different ways: (1) as a continuous model (2) as
a staged model.
(1) Continuous model of CMMI defines 5 capability levels.
The continuous CMMI meta-model describes a process in two dimensions as shown in
Figure 9.1 PP Project Planning
REQM Requirements management
MA Measurement & Analysis
CM Configuration management
PPQA Process and product QA
5
4
Capability level
3
2
1
0
PP REQM MA CM PPQA others
Process area
__________________________________________________________________________________________
Merin Mary Philip
CML
Figure 9.1:-CMMI process area capability profile

Each process area (e. g. project planning) is formally assessed against specific goals
and practices and is rated according to following capability levels:
Figure 9.2:- shows different capability levels:-
1. Level 0: Incomplete
The process area is either not performed or does not achieve all goals and objectives by
CMMI for level 1 capability.
2. Level 1: Performed
All specific goals of process area (as defined by CMMI) are satisfied. Work tasks
required to produce work products are being conducted
3. Level 2: Managed
Level 1 criteria satisfied. In addition, all work associated with process area conforms to
an organizationally defined policy
4. Level 3: Defined
Level 2 criteria achieved. In addition, process is tailored from organizations set of
standard processes according to organizations tailoring guidelines, and contributes work
products, measures, and other process-improvement information to the organizational
process assets.
5. Level 4: Quantitatively managed
Level 3 criteria achieved. In addition, process area is controlled and improved using
measurement and quantitative assessment
6. Level 5: Optimized
Level 4 criteria achieved. In addition, process area adapted and optimized using
quantitative (statistical) means to meet changing customer needs and to continually
improve the efficacy of the process area under consideration.
The CMMI defines each process area in terms of specific goals(SG) and the specific
practices(SP) required to achieve these goals.
a. Specific goals establish the characteristics that must exist if the activities implied by a
process area are to be effective.
b. Specific practices refine a goal into a set of process-related activities.
__________________________________________________________________________________________
Merin Mary Philip
CML
The CMMI also defines each process area in terms of generic goals(GG) and related generic
practices(GP) required to achieve these goals.
The Specific Goals (SG) and Specific Practices(SP) associate with Project Planning activity
are:-
SG 1 Establish Estimates
SP 1.1-1 Estimate the Scope of the Project
SP 1.2-1 Establish Estimates of Work Product and Task Attributes
SP 1.3-1 Define Project Lifecycle
SP 1.4-1 Determine Estimates of Effort and Cost
Figure9.2 :- CMMI Capability Levels

SG 2 Develop a Project Plan
__________________________________________________________________________________________
Merin Mary Philip
CML
SP 2.1-1 Establish the Budget and Schedule

SP 2.2-1 Identify Project Risks
SP 2.3-1 Plan for Data Management
SP 2.4-1 Plan for Project Resources
SP 2.5-1 Plan for Needed Knowledge and Skills
SP 2.6-1 Plan Stakeholder Involvement
SP 2.7-1 Establish the Project Plan
SG 3 Obtain Commitment to the Plan
SP 3.1-1 Review Plans That Affect the Project
SP 3.2-1 Reconcile Work and Resource Levels
SP 3.3-1 Obtain Plan Commitment
The Generic Goals (GG) and Generic Practices(GP) associate with Project Planning activity are:-
GG 1 Achieve Specific Goals
GP 1.1 Perform Base Practices
GG 2 Institutionalize a Managed Process
GP 2.1 Establish an Organizational Policy
GP 2.2 Plan the Process
GP 2.3 Provide Resources
GP 2.4 Assign Responsibility
GP 2.5 Train People
GP 2.6 Manage Configurations
GP 2.7 Identify and Involve Relevant Stakeholders
GP 2.8 Monitor and Control the Process
GP 2.9 Objectively Evaluate Adherence
GP 2.10 Review Status with Higher Level Management
GG 3 Institutionalize a Defined Process
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
GG 4 Institutionalize a Quantitatively Managed Process
GP 4.1 Establish Quantitative objectives for the process
GP 4.2 Stabilize Subprocess Performance
GG 5 Institutionalize an Optimizing Process
GP 5.1 Ensure Continuous Process Improvement
GP 5.2 Correct Root Causes of Problems
(2) Staged model of CMMI defines 5 maturity levels.
__________________________________________________________________________________________
Merin Mary Philip
CML
To achieve a maturity level, the specific goals and practices associated with a set of process
areas must be achieved. The relationship between maturity levels and process areas is shown in
Figure 9.3.
Figure 9.3 Process Areas required to achieve a maturity level
10. Introduction to CASE tools
__________________________________________________________________________________________
Merin Mary Philip
CML
(a) WHAT IS CASE?

Computer-aided software engineering (CASE) tools assist software engineering managers and
practitioners in every activity associated with the software process.
They automate project management activities, manage all work products produced throughout the
process, and assist engineers in their analysis, design, coding and test work.
CASE tools can be integrated within a sophisticated environment.
The workshop for software engineering has been called an integrated project support environment and
the tools that fill the workshop are collectively called computer-aided software engineering.
CASE provides the software engineer with the ability to automate manual activities and to improve
engineering insight. Like computer-aided engineering and design tools that are used by engineers in
other disciplines, CASE tools help to ensure that quality is designed in before the product is built.
(b) BUILDING BLOCKS FOR CASE
Computer aided software engineering can be as simple as a single tool that supports a specific software
engineering activity or as complex as a complete "environment" that encompasses tools, a database,
people, hardware, a network, operating systems, standards, and myriad other components.
The building blocks for CASE are illustrated in Figure 10.1. Each building block forms a foundation for
the next, with tools sitting at the top of the heap.
Successful environments for software engineering are built on an environment architecture that
encompasses appropriate hardware and systems software. In addition, the environment architecture
must consider the human work patterns that are applied during the software engineering process.
__________________________________________________________________________________________
Merin Mary Philip
CML
Figure 10.1:-The building blocks for CASE

The environment architecture composed of the hardware platform and operating system support
lays the ground work for CASE.
A set of portability services provides a bridge between CASE tools and their integration framework
and the environment architecture. Portability services allow CASE tools and their integration
framework to migrate across different hardware platforms and operating systems without significant
adaptive maintenance.
The integration framework is a collection of specialized programs that enables individual CASE tools
to communicate with one another, to create a project database, and to exhibit the same look and feel to
the end-user (the software engineer).
The relative levels of CASE integration are shown in Figure 10.2.
1 At the low end of the integration spectrum is the individual (point solution) tool. When
individual tools provide facilities for data exchange (most do), the integration level is improved
slightly. Such tools produce output in a standard format that should be compatible with other
tools that can read the format. In some cases, the builders of complementary CASE tools work
together to form a bridge between the tools (e.g., an analysis and design tool that is coupled with
a code generator). Using this approach, the synergy between the tools can produce end products
that would be difficult to create using either tool separately.
__________________________________________________________________________________________
Merin Mary Philip
CML
2 Single-source integration occurs when a single CASE tools vendor integrates a number of
different tools and sells them as a package. Although this approach is quite effective, the closed
architecture of most single-source environments precludes easy addition of tools from other
vendors.
Figure 10.2:- Integration levels
3 At the high end of the integration spectrum is the integrated project support environment (IPSE).
Standards for each of the building blocks described previously have been created. CASE tool vendors
use IPSE standards to build tools that will be compatible with the IPSE and therefore compatible with
one another.
(c) A TAXONOMY OF CASE TOOLS
CASE tools can be classified by function, by their role as instruments for managers or technical people,
by their use in the various steps of the software engineering process, by the environment architecture
(hardware and software) that supports them, or even by their origin or cost . The taxonomy presented here
uses function as a primary criterion.
1 Business process engineering tools
Business process engineering tools provide a "meta-model" from which specific information
systems are derived.
__________________________________________________________________________________________
Merin Mary Philip
CML
Business information is modeled as it moves between various organizational entities within a

company.
The primary objective for tools in this category is to represent business data objects, their
relationships, and how these data objects flow between different business areas within a
company.
2 Process modeling and management tools
Process modeling tools (also called process technology tools) are used to represent the key
elements of a process so that it can be better understood.
These tools can also provide links to process descriptions that help those involved in the process
to understand the work tasks that are required to perform it.
Process management tools provide links to other tools that provide support to defined process
activities.
3 Project planning tools
Tools in this category focus on two primary areas: software project effort and cost estimation
and project scheduling.
Estimation tools compute estimated effort, project duration, and recommended number of people
for a project.
Project scheduling tools enable the manager to define all project tasks, create a task network,
represent task interdependencies, and model the amount of parallelism possible for the project.
4 Risk analysis tools
Risk analysis tools enable a project manager to build a risk table by providing detailed guidance
in the identification and analysis of risks.
5 Project management tools

The project schedule and project plan must be tracked and monitored on a continuing basis. In
addition, a manager should use tools to collect metrics that will ultimately provide an indication
of software product quality.
Tools in the category are often extensions to project planning tools.
6 Requirements tracing tools
When large systems are developed, things "fall into the cracks." That is, the delivered system
does not fully meet customer specified requirements.
The objective of requirements tracing tools is to provide a systematic approach to the isolation
of requirements, beginning with the customer request for proposal or specification.
7 Metrics and management tools
__________________________________________________________________________________________
Merin Mary Philip
CML
Metrics or measurement tools focus on process and product characteristics. Management-

oriented tools capture project specific metrics (e.g., LOC/person-month, defects per function
point) that provide an overall indication of productivity or quality.
Technically oriented tools determine technical metrics that provide greater insight into the
quality of design or code.
8 Documentation tools
Document production and desktop publishing tools support nearly every aspect of software
engineering and represent a substantial "leverage" opportunity for all software developers.
Documentation tools provide an important opportunity to improve productivity.
9 System software tools
CASE is a workstation technology.
Therefore, the CASE environment must accommodate high-quality network system software,
object management services, distributed component support, electronic mail, bulletin boards,
and other communication capabilities.
10 Quality assurance tools
The majority of CASE tools that claim to focus on quality assurance are actually metrics tools
that audit source code to determine compliance with language standards. Other tools extract
technical metrics in an effort to project the quality of the software that is being built.
11 Database management tools
Database management software serves as a foundation for the establishment of a CASE database
(repository) that we have called the project database.
Database management tools for CASE are evolving from relational database management
systems to object oriented database management systems.
12 Software configuration management tools

Software configuration management lies at the kernel of every CASE environment.
Tools can assist in all five major SCM (Software Configuration Management) tasks
identification, version control, change control, auditing, and status accounting.
13 Analysis and design tools
Analysis and design tools enable a software engineer to create models of the system to be built.
The models contain a representation of data, function, and behavior (at the analysis level) and
characterizations of data, architectural, component-level, and interface design.
14 PRO/SIM tools
__________________________________________________________________________________________
Merin Mary Philip
CML
PRO/SIM (prototyping and simulation) tools provide the software engineer with the ability to
predict the behavior of a real-time system prior to the time that it is built.
In addition, these tools enable the software engineer to develop mock-ups of the real-time
system, allowing the customer to gain insight into the function, operation and response prior to
actual implementation.
15 Interface design and development tools
Interface design and development tools are actually a tool kit of software components (classes)
such as menus, buttons, window structures, icons, scrolling mechanisms, device drivers, and so
forth.
16 Prototyping tools
A variety of different prototyping tools can be used.
Screen painters enable a software engineer to define screen layout rapidly for interactive
applications.
A variety of fourth generation tools have prototyping features.
17 Programming tools
The programming tools category encompasses the compilers, editors, and debuggers that are
available to support most conventional programming languages.
18 Web development tools
The activities associated with Web engineering are supported by a variety of tools for WebApp
development.
These include tools that assist in the generation of text, graphics, forms, scripts, applets, and
other elements of a Web page.
19 Integration and testing tools

In their directory of software testing tools, Software Quality Engineering defines the following testing
tools categories:-
a) Data acquisitiontools that acquire data to be used during testing.
b) Static measurementtools that analyze source code without executing test cases.
c) Dynamic measurementtools that analyze source code during execution.
d) Simulationtools that simulate function of hardware or other externals.
e) Test managementtools that assist in the planning, development, and control of testing.
f) Cross-functional toolstools that cross the bounds of the preceding categories.
20 Static analysis tools
Static testing tools assist the software engineer in deriving test cases.
__________________________________________________________________________________________
Merin Mary Philip
CML
Three different types of static testing tools are used in the industry: code based testing tools, specialized
testing languages, and requirements-based testing tools.
a) Code-based testing tools accept source code (or PDL) as input and perform a number of
analyses that result in the generation of test cases.
b) Specialized testing languages (e.g., ATLAS) enable a software engineer to write detailed
test specifications that describe each test case and the logistics for its execution.
c) Requirements-based testing tools isolate specific user requirements and suggest test
cases (or classes of tests) that will exercise the requirements.
21 Dynamic analysis tools
Dynamic testing tools interact with an executing program, checking path coverage, testing assertions
about the value of specific variables, and otherwise instrumenting the execution flow of the program.
Dynamic tools can be either intrusive or nonintrusive.
22 Test management tools
Test management tools are used to control and coordinate software testing for each of the major
testing steps.
Tools in this category manage and coordinate regression testing, perform comparisons that
ascertain differences between actual and expected output, and conduct batch testing of programs
with interactive human/computer interfaces.
23 Client/server testing tools
The c/s environment demands specialized testing tools that exercise the graphical user interface
and the network communications requirements for client and server.
24 Reengineering tools
The reengineering tools category can be subdivided into the following functions:
o Reverse engineering to specification tools take source code as input and generate
graphical structured analysis and design models, where-used lists, and other design
information.
o Code restructuring and analysis tools analyze program syntax, generate a control flow
graph, and automatically generate a structured program.
o On-line system reengineering tools are used to modify on-line database systems.
11. Process Models

A process model for software engineering is chosen based on the nature of the project and application,
the methods and tools to be used, and the controls and deliverables that are required.
Process Models can be broadly classified as follows:-
__________________________________________________________________________________________
Merin Mary Philip
CML
PROCESS MODELS
PERSCRIPTIVE SPECIALIZED UNIFIED PROCESS

PROCESS MODELS PROCESS MODELS MODEL
A. PERSCRIPTIVE PROCESS MODELS
Prescriptive Process Models defines a distinct set of activities, actions, tasks, milestones, and work
products that are required to engineer high-quality software.
Prescriptive Process Models are traditional process models and they provide structure to
software engineering work and provide an effective road map for software teams.
The dominant issues in these models are order and project consistency.
These models are collectively named Prescriptive Process Models because they prescribe a
set of process elements for each project, some of the process elements are:-
Framework activities
Software engineering actions
Tasks
Work Products
Quality Assurance
Change Control Mechanism
Each process model prescribes a process flow.
In the following sections some of the prescriptive process models are described namely:-
1) Waterfall Model
2) Incremental Process Model
3) Evolutionary Process Model
4) Concurrent Development Model
__________________________________________________________________________________________
Merin Mary Philip
CML
Prescriptive Process
Models
Concurrent
Incremental Process Evolutionary Process
Waterfall Model Development Model
Model Model
Rapid Application
Prototyping Spiral Model
Development (RAD)
Figure 11.1 Prescriptive Process Models
11.1 Waterfall Model

i. Waterfall Model also called classic life cycle or the linear sequential model suggests a
systematic, sequential approach to software development.
ii. Its a systematic, sequential, approach to software development that begins with
customer communication, and moves forward with planning, modeling, construction and
ends with deployment as shown in Figure 11.1.
iii. Oldest software lifecycle model.
Figure 11.1 Waterfall Mode
iv. Waterfall Model works best when:-

a. Requirements of a problem are reasonably well understood
b. Well-defined adaptations or enhancements to an existing system must be made
__________________________________________________________________________________________
Merin Mary Philip
CML
c. Requirements are well-defined and reasonably stable.

v. Drawbacks of Waterfall Model:-
a. Real projects rarely follow the sequential flow
i. Accommodates iteration indirectly
ii. Changes can cause confusion
b. It is often difficult for the customer to state all requirements explicitly
i. Has difficulty accommodating the natural uncertainty that exists at the
beginning of many projects.
c. The customer must have patience
i. A working version of the program(s) will not be available until late in the
project time-span.
ii. A major blunder, if undetected until the working program is reviewed, can
be disastrous
d. Leads to blocking states sometimes because every activity is dependent on each
other and if some activity in between becomes late then it leads to blocking state
of other activities ahead.
V-model
i. A variation of waterfall model depicts the relationship of quality assurance actions to the
actions associated with communication, modeling and early code construction activates.
ii. Team first moves down the left side of the V to refine the problem requirements. Once
code is generated, the team moves up the right side of the V, performing a series of tests
that validate each of the models created as the team moved down the left side as shown
in Figure 11.1(a).
iii. Every phase in the software development cycle has got a corresponding phase in the
testing phase.
iv. Its also known as Verification & Validation model.
v. Verification side is development side and Validation consists of testing activities.
__________________________________________________________________________________________
Merin Mary Philip
CML
Figure 11.1(a) V-model

11.2 Incremental Process Model
i. Incremental Process Model combines elements of the waterfall model applied in an
iterative fashion.
ii. Each linear sequence produces deliverable increments of the software as shown in
Figure 11.2.
iii. The first increment is often a core product.
iv. In core product
Basic requirements are addressed.
Many supplementary features remain undelivered.
v. The core product is used by the customer (or undergoes detailed evaluation).
vi. Based on evaluation results, a plan is developed for the next increment.
Plan addresses modification of core product.
Delivery of additional features and functionality.
vii. This kind of development of plan is repeated after every increment.
viii. Earlier increments are stripped down versions of final product.
__________________________________________________________________________________________
Merin Mary Philip
CML
ix. Final product is the software developments after a series of increments.

x. Incremental Process Model is applied under following conditions :-
When we have to provide a limited set of functionality to users quickly and we
need to refine and expand on that functionality in later software releases.
When sufficient staffing is unavailable for complete implementation of software.
11.2(i) RAD Model

i. RAD refers Rapid Application Development.
ii. It is an incremental software development process model that emphasizes an extremely
short development cycle.
iii. RAD emphasizes on a short development cycle as shown in Figure 11.2(i).
iv. A high speed adaptation of the waterfall model.
v. Uses a component-based construction approach.
vi. May deliver software within a very short time period (e.g. 60 to 90 days) if requirements
are well understood and project scope is constrained.
vii. Phases of RAD model are:-
1. Business Modeling
2. Data Modeling
3. Process Modeling
__________________________________________________________________________________________
Merin Mary Philip
CML
4. Application Generation
5. Testing & turnover
Figure 11.2(i) RAD model

1.Business modeling
The information flow among business functions is modeled in a way that answers the
following questions: What information drives the business process? What information is
generated? Who generates it? Where does the information go? Who processes it?
2.Data modeling
The information flow defined as part of the business modeling phase is refined into a set
of data objects that are needed to support the business. The characteristics (called attributes) of
each object are identified and the relationships between these objects defined.
3.Process modeling
__________________________________________________________________________________________
Merin Mary Philip
CML
The data objects defined in the data modeling phase are transformed to achieve the
information flow necessary to implement a business function. Processing descriptions are
created for adding, modifying, deleting, or retrieving a data object.
4.Application generation
RAD assumes the use of fourth generation techniques. Rather than creating software
using conventional third generation programming languages the RAD process works to reuse
existing program components (when possible) or create reusable components (when necessary).
In all cases, automated tools are used to facilitate construction of the software.
5.Testing and turnover
Since the RAD process emphasizes reuse, many of the program components have
already been tested. This reduces overall testing time. However, new components must be tested
and all interfaces must be fully exercised.
viii. Drawbacks of RAD:-
a. For large, but scalable projects, RAD requires sufficient human resources.
b. RAD projects will fail if developers and customers are not committed to the rapid-
fire activities.
c. If a system cannot be properly modularized, building the components necessary
for RAD will be problematic.
d. If high performance is an issue, and performance is to be achieved through tuning
the interfaces to system components, the RAD approach may not work.
e. RAD may not be appropriate when technical risks are high.
11.3 Evolutionary Process Models
i. Evolutionary models are iterative in nature.
ii. Iterative nature of this model enables us to develop increasingly more complete version
of the software.
iii. Two types are introduced, namely Prototyping and Spiral.
11.3(i) Prototyping Model
Prototyping model is used when : -
Customer defines a set of general objectives but does not identify detailed
requirements for functions and features or Developer may be unsure of the
efficiency of an algorithm, the form that human computer interaction should
take.
What are the steps involved:-
__________________________________________________________________________________________
Merin Mary Philip
CML
As shown in Figure 11.3(i) Prototyping begins with communication by meeting

with stakeholders to define the objective, identify whatever requirements are
known, and outline areas where further definition is mandatory. A quick plan for
prototyping and modeling (quick design) occur. Quick design focuses on a
representation of those aspects the software that will be visible to end users
( interface and output). Design leads to the construction of a prototype which
will be deployed and evaluated. Stakeholders comments will be used to refine
requirements.
Both stakeholders and software engineers like the prototyping paradigm.

Users get a feel for the actual system, and developers get to build something immediately.
Drawbacks of Prototyping Model:-
Customers may press for immediate delivery of working but inefficient products.
The developer often makes implementation compromises in order to get a prototype
working quickly.
11.3(ii) Spiral Model
i. Spiral Model couples the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model as shown in Figure 11.3(ii).
ii. Spiral Model was proposed by Barry Boehm.
__________________________________________________________________________________________
Merin Mary Philip
CML
iii. It provides the potential for rapid development of increasingly more complete versions of
the software.
iv. It is a risk-driven process model generator.
v. It has two main distinguishing features

i. Cyclic approach- Incrementally growing a systems degree of definition and
implementation while decreasing its degree of risk.
ii. A set of anchor point milestones- A combination of work products and
conditions that are attained along the path of the spiral.
Figure 11.3 (ii) Spiral Model

vi. A series of evolutionary releases are delivered. During the early iterations, the release might
be a model or prototype. During later iterations, increasingly more complete version of the
engineered system is produced.
vii. The first circuit in the clockwise direction might result in the 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 results in adjustments
to the project plan. Cost and schedule are adjusted based on feedback. Also, the number of
iterations will be adjusted by project manager.
viii. Unlike other process models that end when software is delivered, the spiral model can be
adapted to apply throughout the life of the computer s/w.
ix. The circuits around the spiral might represent
__________________________________________________________________________________________
Merin Mary Philip
CML
Concept development project

New Product development project
Product enhancement project
x. The spiral model demands a direct consideration of technical risks at all stages of the
project.
xi. Each of the circuit consists of following activities:-
1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
1. Communication
Involves communication among the customer and other stake holders; encompasses
requirements gathering.
The purpose of communication is to understand stakeholders objectives for the project
and to gather requirements that help define software features and functions.
2. Planning
Planning activity creates a map that helps the software team as it makes journey.
This plan is called software project plan.
Software project plan defines the software engineering work by describing the technical
task to be conducted, the risks involved, resources that will be required, work products
to be produced , and a work schedule.
3. Modeling (Analyze, Design)
Encompasses the creation of models to better understand the requirements and the
design.
4.Construction (Code, Test)
Combines code generation and testing to uncover errors.
5.Deployment
Involves delivery of software to the customer.
Customer evaluates the delivered product and provides feedback based on evaluation.
xii. Benefits of using Spiral Model:-
1. The spiral model is a realistic approach to the development of large-scale systems and
software.
2. Because software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level.
__________________________________________________________________________________________
Merin Mary Philip
CML
3. The spiral model uses prototyping as a risk reduction mechanism but, more important,
enables the developer to apply the prototyping approach at any stage in the evolution of
the product.
4. It maintains the systematic stepwise approach suggested by the classic life cycle but
incorporates it into an iterative framework that more realistically reflects the real world.
5. Direct consideration of technical risks at all stages of the project and, if properly applied,
should reduce risks before they become problematic.
xiii. Dangers of using Spiral Model:-
1. It may be difficult to convince customers (particularly in contract situations) that the
evolutionary approach is controllable.
2. It demands considerable risk assessment expertise and relies on this expertise for success.
3. If a major risk is not uncovered and managed, problems will undoubtedly occur.
4. Finally, the model has not been used as widely as the linear sequential or prototyping
paradigms. It will take a number of years before efficacy of this important paradigm can be
determined with absolute certainty.
11.4 Concurrent Development Model
1. In Concurrent Development Model each of the activities involved in software engineering
process are represented using different states.
2. The concurrent development model is sometimes called concurrent engineering.
3. All activities exist concurrently but reside in different states.
4. It defines a series of events that will trigger transitions from state to states.
5. Applicable to all types of s/w development
6. Defines a network of activities.
7. Events generated at one point in the process network trigger transitions among the states.
__________________________________________________________________________________________
Merin Mary Philip
CML
Figure 11.4 One element of the concurrent process model

8. Figure11.4 provides a schematic representation of one software engineering activity
(modeling) using a concurrent modeling approach. The activity modeling may be in one of
the states.
9. For example, early in a project the customer communication activity has completed its first
iteration and exists in the awaiting changes state. If, however, the customer indicates that
changes in requirements must be made, the analysis activity moves from the under
development state into the awaiting changes state.
11.4 (iii) Three Concerns on Evolutionary Process Models
1. First concern is that prototyping poses a problem to project planning because of the
uncertain number of cycles required to construct the product.
2. Second, it does not establish the maximum speed of the evolution. If the evolution occur too
fast, without a period of relaxation, it is certain that the process will fall into chaos. On the
other hand if the speed is too slow then productivity could be affected.
3. Third, software processes should be focused on flexibility and extensibility rather than on
high quality. We should prioritize the speed of the development over zero defects. Extending
the development in order to reach high quality could result in a late delivery of the product
when the opportunity niche has disappeared.
B. SPECIALIZED PROCESS MODELS
__________________________________________________________________________________________
Merin Mary Philip
CML
1. Specialized Process Models take on many of the characteristics of one or more of the
conventional models
2. These models are tend to be applied when a narrowly defined software engineering
approach is chosen
3. Three kinds of Specialized Process Models are:-
a. Component-Based Development
b. The Formal Methods Model
c. Aspect-Oriented Software Development
a. Component-Based Development
Commercial off-the-shelf (COTS) software components can be used.
Components should have well-defined interfaces.
Incorporates many of the characteristics of the spiral model.
Evolutionary in nature.
Candidate components should be identified first.
Components can be designed as either conventional software modules or object-oriented
classes or packages of classes
b.The Formal Methods Model
Encompasses a set of activities that leads to formal mathematical specification of
computer software
Have provision to apply a rigorous, mathematical notation.
Ambiguity, incompleteness, and inconsistency can be discovered and corrected more
easily not through ad hoc review, but through the application of mathematical analysis
Offers the promise of defect-free software
Cleanroom Software Engineering is a variation of the Formal Methods Model.
Drawbacks of Formal Methods Model:-
The development of formal models is currently quite time-consuming and
expensive.
Extensive training is required.
It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
c. Aspect-Oriented Software Development
__________________________________________________________________________________________
Merin Mary Philip
CML
Aspect Oriented software development (AOSD)provides a process and methodological

approach for defining, specifying, designing, and constructing aspects.
It is likely that AOSD will adopt characteristics of both the spiral and concurrent process
models.
C. UNIFIED PROCESS MODEL
1. UNIFIED PROCESS MODEL is a use-case driven, architecture-centric, iterative and
incremental software process closely aligned with the Unified Modeling Language (UML)
to model and develop object-oriented system iteratively and incrementally.
2. UP is an attempt to draw on the best features and characteristics of conventional s/w process
models.
3. Also implements many of the best principles of agile software development.
4. UP is a framework for object-oriented software engineering using UML (Unified Modeling
Language).
5. Figure (i) shows different Phases of Unified Process :-
1. Inception
2. Elaboration
3. Construction
4. Transition
5. Production
__________________________________________________________________________________________
Merin Mary Philip
CML
Figure (i) Phases of Unified Process

1. Inception
Encompasses both customer communication and planning activities.
Fundamental business requirements are described through a set of preliminary use-cases
A use-case describes a sequence of actions that are performed by an actor (e.g., a
person, a machine, another system) as the actor interacts with the software
A rough architecture for the system is also proposed.
2. Elaboration
Encompasses customer communication and modeling activities.
Refines and expands the preliminary use-cases
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
__________________________________________________________________________________________
Merin Mary Philip
CML
The deployment model

In some cases, elaboration creates an executable architectural baseline that represents a
first cut executable system.
3. Construction
Makes each use-case operational for end-users
As components are being implemented, unit tests are designed and executed for each
Integration activities (component assembly and integration testing) are conducted
Use-cases are used to derive a suite of acceptance tests
4. Transition
Software is given to end-users for beta testing
The software team creates the necessary support information such as
User manuals
Trouble-shooting guides
Installation procedures
At the conclusion of the transition phase, the software increment becomes a usable
software release
5. Production
Coincides with the deployment activity of the generic process
The on-going use of the software is monitored
Support for the operating environment (infrastructure) is provided
Defect reports and requests for changes are submitted and evaluated.
Unified Process Work Products are:-
Inception
Vision document
Initial use-case model
Elaboration
Analysis model
design model
Construction
Implementation model,
__________________________________________________________________________________________
Merin Mary Philip
CML
deployment model
test model
Transition
Delivered software
beta test reports
general user feedback
__________________________________________________________________________________________
Merin Mary Philip
CML
__________________________________________________________________________________________
Merin Mary Philip

Module 1 Topics: 1. The Evolving Role of Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Module 1 Topics: 1. The Evolving Role of Software

Uploaded by

Copyright:

Available Formats

Dept of Computer Science and Engineering

1. The Evolving role of Software

1. The Evolving role of Software

2. Software The changing Nature of Software

of software engineering practice.

Figure 1.1 Failure curve for hardware

Figure 1.2 Failure curves for Software

2.2. Software Application Domains

Concurrent operation that requires scheduling

2.3 Legacy Software

3. Software Engineering A layered Technology

Figure (i) Software Engineering Layers

4.A Process Framework

Figure 2.2 A software process Framework

1. Software project tracking and control

5. A generic view of process ( A generic Process Model)

Figure 2.3 A software process Framework

Figure (b) Different kinds of process flow

5.1 Defining a framework Activity

5.3 Process Patterns

9. Known Uses and Examples

7. Personal and Team Process Models

1. Consistent understanding of the goals and objectives.

Figure 9.1:-CMMI process area capability profile

Figure9.2 :- CMMI Capability Levels

SP 2.1-1 Establish the Budget and Schedule

Figure 9.3 Process Areas required to achieve a maturity level

10. Introduction to CASE tools

(a) WHAT IS CASE?

Figure 10.1:-The building blocks for CASE

Figure 10.2:- Integration levels

Business information is modeled as it moves between various organizational entities within a

5 Project management tools

Metrics or measurement tools focus on process and product characteristics. Management-

12 Software configuration management tools

19 Integration and testing tools

11. Process Models

PERSCRIPTIVE SPECIALIZED UNIFIED PROCESS

A. PERSCRIPTIVE PROCESS MODELS

Figure 11.1 Prescriptive Process Models

11.1 Waterfall Model

Figure 11.1 Waterfall Mode

iv. Waterfall Model works best when:-

c. Requirements are well-defined and reasonably stable.

Figure 11.1(a) V-model

ix. Final product is the software developments after a series of increments.

11.2(i) RAD Model

Figure 11.2(i) RAD model

As shown in Figure 11.3(i) Prototyping begins with communication by meeting

Both stakeholders and software engineers like the prototyping paradigm.

v. It has two main distinguishing features

Figure 11.3 (ii) Spiral Model

Concept development project

Figure 11.4 One element of the concurrent process model

Aspect Oriented software development (AOSD)provides a process and methodological

Figure (i) Phases of Unified Process

The deployment model

You might also like