Course Contents

Unit 2: Software Process Model

Software Process;
Software Process Models (Waterfall Model; Incremental Development; Integration
and Configuration);
Software Process Activities (Software Specification, Software Design and
Implementation; Software Validation; Software Evolution);
Coping with Change (Prototyping, Incremental Delivery);
Process Improvement

Unit 2: Software Process Model

1. Introduction
2. Software process
2.1 Software process models
2.1.1 The waterfall model
2.1.2 Incremental development
2.1.3 Integration and configuration
2.2 Process activities
2.2.1 Software specification
2.2.2 Software design and implementation
2.2.3 Software validation
2.2.4 Software evolution
2.3 Coping with change
2.3.1 Prototyping
2.3.2 Incremental delivery
2.4 Process improvement. (how to deal for cheaper, better software and tighter deadlines)
 Unit 2: Software Process Model

Software process
Vs
Software Process Model

Software Process Vs Model

Process Vs Model:
 Unit 2: Software Process Model
Software process
 A software process is a set of related activities that leads to the production of a software
system.
 There are many different types of software systems, and there is no universal software
engineering method that is applicable to all of them. The process used in different
companies depends on the type of software being developed, the requirements of the
software customer, and the skills of the people writing the software.
However, although there are many different software processes, they all must include, in some
form, the four fundamental software engineering activities.
1. Software specification: The functionality of the software and constraints on its operation
must be defined.
2. Software development: The software to meet the specification must be produced.
3. Software validation: The software must be validated to ensure that it does what the
customer wants.
4. Software evolution: The software must evolve to meet changing customer needs.
Note: Constraints can come from various external standards, legal or regulatory requirements, contractual obligations or
requirements, or project limitations (time, money, resources, skills and knowledge). These are things that must be considered
when designing and deploying software that will limit the options that are available to the development team.

Unit 2: Software Process Model

Software process:
These activities are complex activities in themselves, and they include sub-activities such as
requirements validation, architectural design, and unit testing. Processes also include other
activities, such as software configuration management and project planning that support
production activities.

When describing processes, it is also important to describe who is involved, what is produced,
and conditions that influence the sequence of activities:
1. Products or deliverables are the outcomes of a process activity. For example, the outcome
of the activity of architectural design may be a model of the software architecture.
2. Roles reflect the responsibilities of the people involved in the process. Examples of roles
are project manager, configuration manager, and programmer.
3. Pre- and post conditions are conditions that must hold before and after a process activity
has been enacted or a product produced. For example, before architectural design begins, a
precondition may be that the consumer has approved all requirements; after this activity is
finished, a post condition might be that the UML models describing the architecture have
been reviewed.
 Unit 2: Software Process Model
Software process:
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
that are likely, the resources that will be required, the work products to be produced, and
a work schedule.

Unit 2: Software Process Model

Software process:
A generic process framework for software engineering encompasses five activities:
3. Modeling. Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a
carpenter, or an architect, you work with models every day. You create a “sketch” of the
thing so that you’ll understand the big picture—what it will look like architecturally, how
the constituent parts fit together, and many other characteristics. If required, you refine
the sketch into greater and greater detail in an effort to better understand the problem
and how you’re going to solve it. A software engineer does the same thing by creating
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.
 Unit 2: Software Process Model
2.1 Software process models
2.1.1 The waterfall model
2.1.2 Incremental development
2.1.3 Integration and configuration

Unit 2: Software Process Model

Software process models:

 A software process model is an abstraction of the software development

process. The models specify the stages and order of a process.

 So, software process model as a representation of the order of activities of

the process and the sequence in which they are performed.
 Unit 2: Software Process Model
Software process models:
Some general process models are
1. The waterfall model: This takes the fundamental process activities of
specification, development, validation, and evolution and represents them
as separate process phases such as requirements specification, software
design, implementation, and testing.
2. Incremental development: This approach interleaves the activities of
specification, development, and validation. The system is developed as a
series of versions (increments), with each version adding functionality to
the previous version.
3. Integration and configuration: This approach relies on the availability of
reusable components or systems. The system development process focuses
on configuring these components for use in a new setting and integrating
them into a system.

Unit 2: Software Process Model

Software process models:
 There is no universal process model that is right for all kinds of software
development. The right process depends on the customer and regulatory
requirements, the environment where the software will be used, and the type of
software being developed.
 For example, safety-critical software is usually developed using a waterfall
process as lots of analysis and documentation is required before implementation
begins. Software products are now always developed using an incremental
process model. Business systems are increasingly being developed by
configuring existing systems (off-the-shelf systems) and integrating these to
create a new system with the functionality that is required.
 Parts of the system that are well understood can be specified and developed
using a waterfall-based process or may be bought in as off-the-shelf systems for
configuration. Other parts of the system, which are difficult to specify in
advance, should always be developed using an incremental approach. In both
cases, software components are likely to be reused.
 Unit 2: Software Process Model
Software process models:
 Various attempts have been made to develop “universal” process models that
draw on all of these general models. One of the best known of these universal
models is the Rational Unified Process (RUP) (Krutchen 2003), which was
developed by Rational, a U.S. software engineering company. The RUP is a
flexible model that can be instantiated in different ways to create processes that
resemble any of the general process models discussed here. The RUP has been
adopted by some large software companies (notably IBM), but it has not gained
widespread acceptance.

Unit 2: Software Process Model

Software process models:

Details of

2.1.1 The waterfall model

2.1.2 Incremental development
2.1.3 Integration and configuration
 Unit 2: Software Process Model
The waterfall model
 The waterfall model is an example of a plan-driven process. In principle at
least, you plan and schedule all of the process activities before starting
software development.
 It presents the software development process as a number of stages.
Because of the cascade from one phase to another, this model is known as
the waterfall model or software life cycle.

1. Software specification:
2. Software development:
3. Software validation:
4. Software evolution:

Unit 2: Software Process Model

The waterfall model
The stages of the waterfall model directly reflect the fundamental software
development activities:
1. Requirements analysis and definition: The system’s services, constraints,
and goals are established by consultation with system users. They are then
defined in detail and serve as a system specification.
2. System and software design: The systems design process allocates the
requirements to either hardware or software systems. It establishes an
overall system architecture. Software design involves identifying and
describing the fundamental software system abstractions and their
relationships.
3. Implementation/coding and unit testing: During this stage, the software
design is realized as a set of programs or program units. Unit testing
involves verifying that each unit meets its specification.
Note: Constraints can come from various external standards, legal or regulatory requirements, contractual obligations or
requirements, or project limitations (time, money, resources, skills and knowledge). These are things that must be considered
when designing and deploying software that will limit the options that are available to the development team.
 Unit 2: Software Process Model
The waterfall model
4. Integration and system testing: The individual program units or programs
are integrated and tested as a complete system to ensure that the software
requirements have been met. After testing, the software system is
delivered to the customer.
5. Operation and maintenance: Normally, this is the longest life-cycle phase.
The system is installed and put into practical use. Maintenance involves
correcting errors that were not discovered in earlier stages of the life cycle,
improving the implementation of system units, and enhancing the system’s
services as new requirements are discovered.

In principle, the result of each phase in the waterfall model is one or more
documents that are approved (“signed off”). The following phase should not
start until the previous phase has finished. The software process, in practice, is
never a simple linear model but involves feedback from one phase to another.

Unit 2: Software Process Model

The waterfall model
In reality, software has to be flexible and accommodate change as it is being
developed. The waterfall model is only appropriate for some types of system:
1. Embedded systems where the software has to interface with hardware systems.
Because of the inflexibility of hardware, it is not usually possible to delay decisions
on the software’s functionality until it is being implemented.
2. Critical systems where there is a need for extensive safety and security analysis of
the software specification and design. In these systems, the specification and design
documents must be complete so that this analysis is possible. Safety related problems
in the specification and design are usually very expensive to correct at the
implementation stage.
3. Large software systems that are part of broader engineering systems developed by
several partner companies. The hardware in the systems may be developed using a
similar model, and companies find it easier to use a common model for hardware and
software. I.e. Hardware use waterfall and so can use in software also. Furthermore,
where several companies are involved, complete specifications may be needed to
allow for the independent development of different subsystems.
 Unit 2: Software Process Model
The waterfall model
 The waterfall model is not the right process model in situations where
informal team communication is possible and software requirements
change quickly. Iterative development and agile methods are better for
these systems.
 Because of the high costs of developing a formal specification, this
development model is rarely used except for critical systems engineering.

Unit 2: Software Process Model

Incremental development:
 Incremental development is based on the idea of developing an initial
implementation, getting feedback from users and others, and evolving the
software through several versions until the required system has been
developed.
 Specification, development, and validation activities are interleaved rather
than separate, with rapid feedback across activities.
 Unit 2: Software Process Model
Incremental development:
 Incremental development in some form is now the most common approach
for the development of application systems and software products. This
approach can be either plan-driven, agile or, more usually, a mixture of
these approaches.
 In a plan-driven approach, the system increments are identified in advance;
if an agile approach is adopted, the early increments are identified, but the
development of later increments depends on progress and customer
priorities.
 Incremental software development, which is a fundamental part of agile
development methods, is better than a waterfall approach for systems
whose requirements are likely to change during the development process.
 By developing the software incrementally, it is cheaper and easier to make
changes in the software as it is being developed.

Unit 2: Software Process Model

Incremental development:
 Each increment or version of the system incorporates some of
the functionality that is needed by the customer.
 Generally, the early increments of the system include the most
important or most urgently required functionality. This means
that the customer or user can evaluate the system at a relatively
early stage in the development to see if it delivers what is
required. If not, then only the current increment has to be
changed and, possibly, new functionality defined for later
increments.
 Unit 2: Software Process Model
Incremental development:
Incremental development has three major advantages over the waterfall model:
1. The cost of “implementing requirements changes” is reduced. The amount
of analysis and documentation that has to be redone is significantly less
than is required with the waterfall model.
2. It is easier to get customer feedback on the development work that has been
done. Customers can comment on demonstrations of the software and see
how much has been implemented. Customers find it difficult to judge
progress from software design documents.
3. Early delivery and deployment of useful software to the customer is
possible, even if all of the functionality has not been included. Customers
are able to use and gain value from the software earlier than is possible
with a waterfall process.

Unit 2: Software Process Model

Incremental development:
From a management perspective, the incremental approach has two problems:
1. The process is not visible. Managers need regular deliverables to measure
progress. If systems are developed quickly, it is not cost effective to
produce documents that reflect every version of the system.
2. System structure tends to degrade as new increments are added. Regular
change leads to messy code as new functionality is added in whatever way
is possible. It becomes increasingly difficult and costly to add new features
to a system. To reduce structural degradation and general code messiness,
agile methods suggest that you should regularly refactor (improve and
restructure) the software.
 Unit 2: Software Process Model

Integration and configuration

and

Software Reuse?

Unit 2: Software Process Model

Integration and configuration:
 In the majority of software projects, there is some software reuse. This
often happens informally when people working on the project know of or
search for code that is similar to what is required. They look for these,
modify them as needed, and integrate them with the new code that they
have developed.
 This informal reuse takes place regardless of the development process that
is used. However, since 2000, software development processes that focus
on the reuse of existing software have become widely used.
 Unit 2: Software Process Model
Integration and configuration:
Figure shows a general process model for reuse-based development, based on
integration and configuration.

Unit 2: Software Process Model

Integration and configuration:
The stages in this process are:
1. Requirements specification: The initial requirements for the system are
proposed. These do not have to be elaborated in detail but should include brief
descriptions of essential requirements and desirable system features.
2. Software discovery and evaluation: Given an outline of the software
requirements, a search is made for components and systems that provide the
functionality required. Candidate components and systems are evaluated to see
if they meet the essential requirements and if they are generally suitable for use
in the system.
 Unit 2: Software Process Model
Integration and configuration:
3. Requirements refinement: During this stage, the requirements are refined
using information about the reusable components and applications that have
been discovered. The requirements are modified to reflect the available
components, and the system specification is re-defined. Where modifications
are impossible, the component analysis activity may be reentered to search for
alternative solutions.
4. Application system configuration: If an off-the-shelf application system that
meets the requirements is available, it may then be configured for use to create
the new system.
5. Component adaptation and integration: If there is no off-the-shelf system,
individual reusable components may be modified and new components
developed. These are then integrated to create the system.

Unit 2: Software Process Model

Integration and configuration:
Advantages:
 Reuse-oriented software engineering, based around configuration and
integration, has the obvious advantage of reducing the amount of software
to be developed and so reducing cost and risks.
 It usually also leads to faster delivery of the software. However,
requirements compromises are inevitable, and this may lead to a system
that does not meet the real needs of users.
Disadvantage:
 Furthermore, some control over the system evolution is lost as new
versions of the reusable components are not under the control of the
organization using them.
 Unit 2: Software Process Model
1. Introduction
2. Software process
2.1 Software process models
2.1.1 The waterfall model
2.1.2 Incremental development
2.1.3 Integration and configuration
2.2 Process activities
2.2.1 Software specification
2.2.2 Software design and implementation
2.2.3 Software validation
2.2.4 Software evolution
2.3 Coping with change
2.3.1 Prototyping
2.3.2 Incremental delivery
2.4 Process improvement

Unit 2: Software Process Model

2.2 Process activities
2.2.1 Software specification
2.2.2 Software design and implementation
2.2.3 Software validation
2.2.4 Software evolution

Software processes are the activities involved in producing a software system.

Software process models are abstract representations of these processes.
 Unit 2: Software Process Model
Process activities:
 The four basic process activities of specification, development, validation,
and evolution are organized differently in different development processes.
In the waterfall model, they are organized in sequence, whereas in
incremental development they are interleaved.
 How these activities are carried out depends on the type of software being
developed, the experience and competence of the developers, and the type
of organization developing the software.
 Real software processes are interleaved sequences of technical,
collaborative, and managerial activities with the overall goal of specifying,
designing, implementing, and testing a software system. Generally,
processes are now tool-supported. This means that software developers
may use a range of software tools to help them, such as requirements
management systems, design model editors, program editors, automated
testing tools, and debuggers.

Unit 2: Software Process Model

Process activities:
The four basic process activities are

1. Software specification
2. Software design and implementation
3. Software validation
4. Software evolution
 Unit 2: Software Process Model
1. Software specification:
There are three main activities in the Requirements Engineering(RE) process:
1. Requirements elicitation and analysis: This is the process of deriving the system
requirements through observation of existing systems, discussions with potential users
and procurers, task analysis, and so on. This may involve the development of one or
more system models and prototypes. These help you understand the system to be
specified.
2. Requirements specification: Requirements specification is the activity of translating
the information gathered during requirements analysis into a document that defines a
set of requirements. Two types of requirements may be included in this document.
User requirements are abstract statements of the system requirements for the customer
and end-user of the system; system requirements are a more detailed description of the
functionality to be provided.
3. Requirements validation: This activity checks the requirements for realism,
consistency, and completeness. During this process, errors in the requirements
document are inevitably discovered. It must then be modified to correct these
problems.

Unit 2: Software Process Model

2. Software design and implementation:
Four activities that may be part of the design process for information systems are:
1. Architectural design, where you identify the overall structure of the system, the principal
components (sometimes called subsystems or modules), their relationships, and how they are
distributed.
2. Database design, where you design the system data structures and how these are to be
represented in a database. Again, the work here depends on whether an existing database is to be
reused or a new database is to be created.
3. Interface design, where you define the interfaces between system components. This interface
specification must be unambiguous. With a precise interface, a component may be used by other
components without them having to know how it is implemented. Once interface specifications
are agreed, the components can be separately designed and developed.
4. Component selection and design, where you search for reusable components and, if no suitable
components are available, design new software components. The design at this stage may be a
simple component description with the implementation details left to the programmer.
Alternatively, it may be a list of changes to be made to a reusable component or a detailed design
model expressed in the UML. The design model may then be used to automatically generate an
implementation.
 Unit 2: Software Process Model
2. Software design and implementation:
The activities in the design process vary, depending on the type of system being
developed. For example, real-time systems require an additional stage of timing design but
may not include a database, so there is no database design involved.

Figure: A general descriptions model of the design process

Unit 2: Software Process Model

3. Software validation:
Software validation or, more generally, verification and validation (V & V) is
intended to show that a system both conforms to its specification and meets the
expectations of the system customer.
The stages in the testing process are:
Component testing: The components making up the system are tested by the
people developing the system. Each component is tested independently,
without other system components. Components may be simple entities such as
functions or object classes or may be coherent groupings of these entities.
System testing: System components are integrated to create a complete
system. This process is concerned with finding errors that result from
unanticipated interactions between components and component interface
problems. It is also concerned with showing that the system meets its
functional and non-functional requirements, and testing the emergent system
properties.
 Unit 2: Software Process Model
3. Software validation:
Customer testing: This is the final stage in the testing process before the
system is accepted for operational use. The system is tested by the system
customer (or potential customer) rather than with simulated test data. Customer
testing may also reveal requirements problems where the system’s facilities do
not really meet the users’ needs or the system performance is unacceptable. For
products, customer testing shows how well the software product meets the
customer’s needs.
Delivering a system to several prospective users who consent to use it as part
of beta testing. They inform the system designers of any issues. This puts the
product in actual use and identifies faults that the product creators might not
have foreseen. The software product may then be changed and released for
additional beta testing or for general sale following this feedback.

Unit 2: Software Process Model

3. Software validation:
Testing phases in a plan-driven software process:

Figure illustrates how test plans are the link between testing and development
activities. This is sometimes called the V-model of development (turn it on its
side to see the V). The V-model shows the software validation activities that
corre spond to each stage of the waterfall process model.
 Unit 2: Software Process Model
3. Software validation:Testing phases in a plan-driven software process:

Figure illustrates how test plans are the link between testing and development
activities. This is sometimes called the V-model of development (turn it on its
side to see the V). The V-model shows the software validation activities that
correspond to each stage of the waterfall process model.

Unit 2: Software Process Model

4. Software evolution:
Software engineering as an evolutionary process (Figure below) where
software is continually changed over its lifetime in response to changing
requirements and customer needs.

The flexibility of software is one of the main reasons why more and more
software is being incorporated into large, complex systems while , it is very
expensive to make changes to the hardware design.
 Unit 2: Software Process Model
2.3 Coping with change
2.3.1 Prototyping
2.3.2 Incremental delivery
2.4 Process improvement

Unit 2: Software Process Model

Coping with change:
Change is inevitable in all large software projects. The system requirements
change as businesses respond to external pressures, competition, and changed
management priorities. As new technologies become available, new approaches
to design and implementation become possible. Therefore whatever software
process model is used, it is essential that it can accommodate changes to the
software being developed.

Change adds to the costs of software development because it usually means

that work that has been completed has to be redone. This is called rework. It
may then be necessary to redesign the system to deliver the new requirements,
change any programs that have been developed, and retest the system.
 Unit 2: Software Process Model
Coping with change:
Two related approaches may be used to reduce the costs of rework:
1. Change anticipation: where the software process includes activities that
can anticipate or predict possible changes before significant rework is required.
For example, a prototype system may be developed to show some key features
of the system to customers. They can experiment with the prototype and refine
their requirements before committing to high software production costs.
2. Change tolerance: where the process and software are designed so that
changes can be easily made to the system. This normally involves some form
of incremental development. Proposed changes may be implemented in
increments that have not yet been developed.

Refactoring (improving the structure and organization of a program) is also an

important mechanism that supports change tolerance and discuss in Agile
methods.

Unit 2: Software Process Model

Coping with change:
So, two ways of coping with change and changing system requirements:
1. System prototyping: where a version of the system or part of the system is
developed quickly to check the customer’s requirements and the feasibility of
design decisions. This is a method of change anticipation as it allows users to
experiment with the system before delivery and so refine their requirements.
The number of requirements change proposals made after delivery is therefore
likely to be reduced.
2. Incremental delivery: where system increments are delivered to the
customer for comment and experimentation. This supports both change
avoidance and change tolerance. It avoids the premature commitment to
requirements for the whole system and allows changes to be incorporated into
later increments at relatively low cost.
 Unit 2: Software Process Model
Prototyping:
A prototype is an early version of a software system that is used to demonstrate
concepts, try out design options, and find out more about the problem and its
possible solutions. Rapid, iterative development of the prototype is essential so
that costs are controlled and system stakeholders can experiment with the
prototype early in the software process.

A software prototype can be used in a software development process to help

anticipate changes that may be required:
1. In the requirements engineering process, a prototype can help with the
elicitation and validation of system requirements.
2. In the system design process, a prototype can be used to explore software
solutions and in the development of a user interface for the system

Unit 2: Software Process Model

Prototyping:
A process model for prototype development is shown in Figure. The objectives
of prototyping should be made explicit from the start of the process. These may
be to develop the user interface, to develop a system to validate functional
system requirements, or to develop a system to demonstrate the application to
managers. The same prototype usually cannot meet all objectives.
 Unit 2: Software Process Model
Incremental delivery:
Incremental delivery is an approach to software development where some of
the developed increments are delivered to the customer and deployed for use in
their working environment. In an incremental delivery process, customers
define which of the services are most important and which are least important
to them. A number of delivery increments are then defined, with each
increment providing a subset of the system functionality. The allocation of
services to increments depends on the service priority, with the highest priority
services implemented and delivered first.

Unit 2: Software Process Model

Incremental delivery:
Incremental delivery has a number of advantages:
1. Customers can use the early increments as prototypes and gain experience
that informs their requirements for later system increments.
2. Customers do not have to wait until the entire system is delivered before
they can gain value from it.
3. The process maintains the benefits of incremental development in that it
should be relatively easy to incorporate changes into the system.
4. As the highest priority services are delivered first and later increments then
integrated, the most important system services receive the most testing.
This means that customers are less likely to encounter software failures in
the most important parts of the system
 Unit 2: Software Process Model
Incremental delivery:
Incremental delivery has a number of advantages:
1. Customers can use the early increments as prototypes and gain experience
that informs their requirements for later system increments.
2. Customers do not have to wait until the entire system is delivered before
they can gain value from it.
3. The process maintains the benefits of incremental development in that it
should be relatively easy to incorporate changes into the system.
4. As the highest priority services are delivered first and later increments then
integrated, the most important system services receive the most testing.
This means that customers are less likely to encounter software failures in
the most important parts of the system

Unit 2: Software Process Model

Incremental delivery:
However, there are problems with incremental delivery. In practice, it only
works in situations where a brand-new system is being introduced and the
system evaluators are given time to experiment with the new system. Key
problems with this approach are:
1. Iterative delivery is problematic when the new system is intended to replace
an existing system. Users need all of the functionality of the old system and
are usually unwilling to experiment with an incomplete new system.
2. Most systems require a set of basic facilities that are used by different parts
of the system and can be hard to identify common facilities that are needed
by all increments.
3. Specification is developed in conjunction with the software. However, this
conflicts with the procurement model of many organizations, where the
complete system specification is part of the system development contract.
 Unit 2: Software Process Model
Process improvement:
Nowadays, there is a constant demand from industry for cheaper, better
software, which has to be delivered to ever-tighter deadlines. Consequently,
many software companies have turned to software process improvement as a
way of enhancing the quality of their software, reducing costs, or accelerating
their development processes.
Two quite different approaches to process improvement and change are used:
1. The process maturity approach, which has focused on improving process
and project management and introducing good software engineering
practice into an organization.
2. The agile approach, which has focused on iterative development and the
reduction of overheads in the software process. The primary characteristics
of agile methods are rapid delivery of functionality and responsiveness to
changing customer requirements. Agile approaches focus on the code being
developed and deliberately minimize formality and documentation.

Unit 2: Software Process Model

Key points:
 Software processes are the activities involved in producing a software
system. Software process models are abstract representations of these
processes.
 General process models describe the organization of software processes.
Examples of these general models include the waterfall model, incremental
development, and reusable component configuration and integration.
 Requirements engineering is the process of developing a software
specification. Specifications are intended to communicate the system needs
of the customer to the system developers.
 Design and implementation processes are concerned with transforming a
requirements specification into an executable software system.
 Software validation is the process of checking that the system conforms to
its specification and that it meets the real needs of the users of the system.
 Unit 02: Software Process Model
Key points:
 Software evolution takes place when you change existing software systems
to meet new requirements. Changes are continuous, and the software must
evolve to remain useful.
 Processes should include activities to cope with change. This may involve
a prototyping phase that helps avoid poor decisions on requirements and
design. Processes may be structured for iterative development and delivery
so that changes may be made without disrupting the system as a whole.
 Process improvement is the process of improving existing software
processes to improve software quality, lower development costs, or reduce
development time. It is a cyclic process involving process measurement,
analysis, and change.

Unit-1: Introduction – Q&A

1. Four fundamental software engineering activities
a. Software specification
b. Software development
c. Software validation
d. Software evolution
2. Five fundamental activities of software engineering.
a. Communication
b. Planning
c. Modeling
d. Construction
e. Deployment
3. Software process models: (Some general process models are)
a. The waterfall model
b. Incremental development
c. Integration and configuration
4. Waterfall model -Fundamental software development activities of Waterfall model.
a. Requirements analysis and definition
b. System and software design
c. Implementation and unit testing
d. Integration and system testing
e. Operation and maintenance
 Unit-1: Introduction – Q&A
5. The waterfall model is suitable for what types of system types?
a. Embedded systems
b. Critical systems
c. Large software systems
6. What is Incremental development?
 Incremental development is based on the idea of developing an initial implementation, getting feedback from
users and others, and evolving the software through several versions until the required system has been
developed.
5. Three major advantages of Incremental development over the waterfall model.
a. cost of implementing requirements changes is reduced
b. easier to get customer feedback on the development work
c. Early delivery and deployment of useful software to the customer is possible
6. The incremental approach has two problems
a. The process is not visible. Managers need regular deliverables to measure progress. it is not cost effective
to produce documents
b. System structure tends to degrade as new increments are added
7. The stages in the process of Integration and configuration are
a. Requirements specification:
b. Software discovery and evaluation
c. Requirements refinement
d. Application system configuration
e. Component adaptation and integration

Unit-1: Introduction – Q&A

5. Software requirement specification: What are three main activities in the requirements engineering process?
a. Requirements elicitation and analysis
b. Requirements specification
c. Requirements validation
6. Software design and implementation: Four activities that may be part of the design process for information
systems are:
a. Architectural design
b. Database design
c. Interface design
d. Component selection and design
5. Software validation: The stages in the testing process are:
a. Component testing
b. System testing
c. Customer testing
7. Coping with change: Two related approaches may be used to reduce the costs of rework:
a. Change anticipation:
b. Change tolerance
8. Coping with change: So, two ways of coping with change and changing system requirements:
a. System prototyping
b. Incremental delivery
 Unit-1: Introduction – Q&A
5. Process improvement: Two quite different approaches to process improvement and change are used:
a. The process maturity approach
b. The agile approach

6. Agile Software Development: All of the agile methods that have been proposed share a number of common
characteristics:
a. Program specification, design, and implementation are interleaved
b. The system is developed as a series of frequent versions or increments
c. Stakeholders involved in version specification and evaluation
d. Extensive tool support (e.g. automated testing tools) used to support development
e. Minimal documentation - focus on working code
7. The Agile Manifesto consists of four key values:
a. Individuals and interactions over processes and tools
b. Working software over comprehensive documentation
c. Customer collaboration over contract negotiation
d. Responding to change over following a plan