PROCESS FRAMEWORK MODEL AND

PHASES IN SOFTWARE DEVELOPMENT

MODULE 2

2.1 PROCESS FRAMEWORK

 Software process models can be prescriptive or agile, complex or

simple, all-encompassing or targeted, but in every case, five key
activities must occur.

 The framework activities are applicable to all projects and all

application domains, and they are a template for every process model.

 Each framework activity is populated by a set of software engineering

actions – a collection of related tasks that produces a major software
engineering work product.

 Each action is populated with individual work tasks that accomplish

some part of the work implied by the action.

 The following generic process framework is applicable to the vast

majority of software projects.

a) Communication: involves heavy communication with the customer

(and other stakeholders) and encompasses requirements gathering.

b) Planning: Describes the technical tasks to be conducted, the risks that

are likely, resources that will be required, the work products to be
produced and a work schedule.

c) Modeling: encompasses the creation of models that allow the

developer and customer to better understand software requirement and
the design that will achieve those requirement.

1
 d) Construction: combines code generation and the testing required
uncovering errors in the code.
e) Deployment: deliver the product to the customer who evaluates the
delivered product and provides feedback.

 Each software engineering action is represented by a number of different

task sets – each a collection of software engineering work tasks, related
work products, quality assurance points, and project milestones.

 The task set that best accommodates the needs of the project and the
characteristics of the team is chosen.

Common process framework

Framework activities

Task sets

Task

Milestone, work product

SQA points

Umbrella Activities

Fig: Process Framework

 The framework described in the generic view of software engineering is

complemented by a number of umbrella activities. Typical activities
include:

2
 a) Software project tracking and control: allows the team to assess progress
against the project plan and take necessary action to maintain schedule.

b) Risk Management: Assesses the risks that may affect the outcome of the
project or the quality.

c) Software quality assurance: defines and conducts the activities required to

ensure software quality.

d) Formal Technical Review: uncover and remove errors before they

propagate to the next action.

e) Measurement: defines and collects process, project, and product measures

that assist the team in delivering software that meets customers’ needs.

f) Software configuration management: Manages the effect of change

throughout the software process.

g) Reusability management: defines criteria for work product reuse.

h) Work product preparation and production: encompasses the activities

required to create work products such as models, documents, etc.

2.1.1 Capability Maturity Model (CMM):

 SEI Capability Maturity Model (SEI CMM) helped organizations to improve

the quality of the software they develop and therefore adoption of SEI CMM
model has significant business benefits.

 SEI CMM can be used two ways: capability evaluation and software process
assessment.

 Capability evaluation and software process assessment differ in motivation,

objective, and the final use of the result. Capability evaluation provides a
way to assess the software process capability of an organization.

3
 The results of capability evaluation indicates the likely contractor
performance if the contractor is awarded a work. Therefore, the results of
software process capability assessment can be used to select a contractor.

 On the other hand, software process assessment is used by an organization

with the objective to improve its process capability. Thus, this type of
assessment is for purely internal use.

 SEI CMM classifies software development industries into the following five
maturity levels.

 The different levels of SEI CMM have been designed so that it is easy for an
organization to slowly build its quality system starting from scratch.

a) Level 1: Initial. A software development organization at this level

is characterized by ad hoc activities. Very few or no processes are
defined and followed. Since software production processes are not
defined, different engineers follow their own process and as a
result development efforts become chaotic. Therefore, it is also
called chaotic level. The success of projects depends on individual
efforts and heroics.

b) Level 2: Repeatable. At this level, the basic project management

practices such as tracking cost and schedule are established. Size
and cost estimation techniques like function point analysis,
COCOMO, etc. are used. The necessary process discipline is in
place to repeat earlier success on projects with similar applications.

c) Level 3: Defined. At this level the processes for both management

and development activities are defined and documented. There is a
common organization-wide understanding of activities, roles, and

4
 responsibilities. The processes though defined, the process and
product qualities are not measured.

d) Level 4: Managed. At this level, the focus is on software metrics.

Two types of metrics are collected. Product metrics measure the
characteristics of the product being developed, such as its size,
reliability, time complexity, understandability, etc. Process metrics
reflect the effectiveness of the process being used, such as average
defect correction time, productivity, average number of defects
found per hour inspection, average number of failures detected
during testing per LOC, etc. Quantitative quality goals are set for
the products. The software process and product quality are
measured and quantitative quality requirements for the product are
met.

e) Level 5: Optimizing. At this stage, process and product metrics

are collected. Process and product measurement data are analyzed
for continuous process improvement.

Applicability of SEI CMM to organizations

 Highly systematic and measured approach to software development suits

large organizations dealing with negotiated software, safety-critical
software, etc. For those large organizations, SEI CMM model is perfectly
applicable.

 But small organizations typically handle applications such as Internet, e-

commerce, and are without an established product range, revenue base, and
experience on past projects, etc. For such organizations, a CMM-based
appraisal is probably excessive.

5
  These organizations need to operate more efficiently at the lower levels of
maturity. For example, they need to practice effective project management,
reviews, configuration management, etc.

2.1.2 ISO 9000:

 ISO (International Standards Organization) is a consortium of 63 countries

established to formulate and foster standardization. ISO published its 9000
series of standards in 1987.

 ISO certification serves as a reference for contract between independent

parties. The ISO 9000 standard specifies the guidelines for maintaining a
quality system.

 The ISO standard mainly addresses operational aspects and organizational

aspects such as responsibilities, reporting, etc.

Types of ISO 9000 quality standards

 ISO 9000 is a series of three standards: ISO 9001, ISO 9002, and ISO 9003.

 The ISO 9000 series of standards is based on the premise that if a proper
process is followed for production, then good quality products are bound to
follow automatically.

 The types of industries to which the different ISO standards apply are as
follows:

a) ISO 9001 applies to the organizations engaged in design,

development, production, and servicing of goods. This is the
standard that is applicable to most software development
organizations.
6
 b) ISO 9002 applies to those organizations which do not design
products but are only involved in production. Examples of these
category industries include steel and car manufacturing industries
that buy the product and plant designs from external sources and are
involved in only manufacturing those products. Therefore, ISO 9002
is not applicable to software development organizations.

c) ISO 9003 applies to organizations that are involved only in

installation and testing of the products.

Need for obtaining ISO 9000 certification

a) Confidence of customers in an organization increases when organization

qualifies for ISO certification.

b) ISO 9000 requires a well-documented software production process to be in

place. A well-documented software production process contributes to
repeatable and higher quality of the developed software.

c) ISO 9000 makes the development process focused, efficient, and

costeffective.

d) ISO 9000 certification points out the weak points of an organization and
recommends remedial action.

e) ISO 9000 sets the basic framework for the development of an optimal
process and Total Quality Management (TQM).

Salient features of ISO 9001 certification

a) All documents concerned with the development of a software product

should be properly managed, authorized, and controlled. This requires a
configuration management system to be in place.

7
 b) Proper plans should be prepared and then progress against these plans
should be monitored.

c) Important documents should be independently checked and reviewed for

effectiveness and correctness.

d) The product should be tested against specification.

e) Several organizational aspects should be addressed e.g., management

reporting of the quality team.

2.2 PHASES OF SOFTWARE DEVELOPMENT LIFECYCLE

 Software life cycle models describe phases of the software cycle and the
order in which those phases are executed.

 Each phase produces deliverables required by the next phase in the life
cycle.

 Requirements are translated into design. Code is produced according to the

design which is called development phase. After coding and development
the testing verifies the deliverable of the implementation phase against
requirements.

 The testing team follows Software Testing Life Cycle (STLC) which is
similar to the development cycle followed by the development team.

8
 There are following six phases in every Software development life cycle
model:

1) Requirement gathering and analysis:

 Business requirements are gathered in this phase. This phase is

the main focus of the project managers and stake holders.

 Meetings with managers, stake holders and users are held in

order to determine the requirements are done at this stage.

 After requirement gathering these requirements are analyzed

for their validity and the possibility of incorporating the
requirements in the system to be development is also studied.

 Finally, a Requirement Specification document is created

which serves the purpose of guideline for the next phase of the
model.

 The testing team follows the Software Testing Life Cycle and
starts the Test Planning phase after the requirements analysis is
completed.

2) Design: 

9
  In this phase the system and software design is prepared from
the requirement specifications which were studied in the first
phase.

 System Design helps in specifying hardware and system

requirements and also helps in defining overall system
architecture.

 The system design specifications serve as input for the next

phase of the model.

 In this phase the testers comes up with the Test strategy, where
they mention what to test, how to test.

3) Implementation / Coding:

 On receiving system design documents, the work is divided

in modules/units and actual coding is started.

 Since, in this phase the code is produced so it is the main

focus for the developer.

 This is the longest phase of the software development life

cycle.

4) Testing: 

10
  After the code is developed it is tested against the
requirements to make sure that the product is actually
solving the needs addressed and gathered during the
requirements phase.

 During this phase all types of functional testing like unit

testing, integration testing, system testing, acceptance testing
are done as well as non-functional testing are also done.

5) Deployment:

 After successful testing the product is delivered /

deployed to the customer for their use.

 As soon as the product is given to the customers they will

first do the beta testing.

 If any changes are required or if any bugs are caught,

then they will report it to the engineering team.

 Once those changes are made or the bugs are fixed then
the final deployment will happen.

6) Maintenance:

11
  Once when the customers starts using the developed
system then the actual problems comes up and needs
to be solved from time to time.

 This process where the care is taken for the developed

product is known as maintenance.

2.6 REQUIREMENT ANALYSIS: REQUIREMENTS ELICITATION AND

ANALYSIS

 After an initial feasibility study, the next stage of the requirements

engineering process is requirements elicitation and analysis.
 In this activity, software engineers work with customers and system end-
users to find out about the application domain, what services the system
should provide, the required performance of the system, hardware
constraints, and so on.
 Requirements elicitation and analysis may involve a variety of different
kinds of people in an organization.
 Each organization will have its own version or instantiation of this general
model depending on local factors such as the expertise of the staff, the type
of system being developed, the standards used, etc.

REQUIREMENTS
DISCOVERY

12
 REQUIREMENTS
REQUIREMENTS
CLASSIFICATION AND
SPECIFICATION
ORGANIZATION

REQUIREMENTS
PRIORTIZATION AND
NEGOTIATION

Fig: Requirement elicitation and analysis process

 The process activities are:

1. Requirements discovery:

 This is the process of interacting with stakeholders of the system to

discover their requirements.
 Domain requirements from stakeholders and documentation are also
discovered during this activity.

2. Requirements classification and organization

 This activity takes the unstructured collection of requirements, groups

related requirements, and organizes them into coherent clusters.
 The most common way of grouping requirements is to use a model of
the system architecture to identify sub-systems and to associate
requirements with each sub-system.

13
 3. Requirements prioritization and negotiation

 This activity is concerned with prioritizing requirements and

finding and resolving requirements conflicts through negotiation.

4. Requirements specification

 The requirements are documented and input into the next round of
the spiral.

Eliciting and understanding requirements from system stakeholders is a difficult

process for several reasons:

1. Stakeholders often don’t know what they want from a computer system
except in the most general terms.

2. Stakeholders in a system naturally express requirements in their own

terms and with implicit knowledge of their own work. Requirements engineers,
without experience in the customer’s domain, may not understand these
requirements.

3. Different stakeholders have different requirements and they may express

these in different ways.

4. Political factors may influence the requirements of a system. Managers

may demand specific system requirements because these will allow them to
increase their influence in the organization.

14
 5. The economic and business environment in which the analysis takes place
is dynamic. It inevitably changes during the analysis process.

2.6.1 Requirements Discovery

 Requirements discovery (sometime called requirements elicitation) is the

process of gathering information about the required system and existing
systems, and distilling the user and system requirements from this
information.
 Sources of information during the requirements discovery phase include
documentation, system stakeholders, and specifications of similar systems.
You interact with stakeholders through interviews and observation and you
may use scenarios and prototypes to help stakeholders understand what the
system will be like.
 Stakeholders range from end-users of a system through managers to external
stakeholders such as regulators, who certify the acceptability of the system.

2.6.2 Interviews

 Formal or informal interviews with system stakeholders are part of most

requirements engineering processes.
 In these interviews, the requirements engineering team puts questions to
stakeholders about the system that they currently use and the system to be
developed.
 Requirements are derived from the answers to these questions and
interviews may be of two types:

15
 o Closed interviews, where the stakeholder answers a pre-defined set of
questions.
o Open interviews, in which there is no pre-defined agenda.
 It can be difficult to elicit domain knowledge through interviews for two
reasons:
o All application specialists use terminology and jargon that are specific
to a domain.
o Some domain knowledge is so familiar to stakeholders that they either
find it difficult to explain or they think it is so fundamental that it isn’t
worth mentioning.
 Effective interviewers have two characteristics:
o They are open-minded, avoid pre-conceived ideas about the
requirements, and are willing to listen to stakeholders.
o They prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by working together
on a prototype system.

2.6.3 Scenarios

 People usually find it easier to relate to real-life examples rather than

abstract descriptions.
 They can understand and criticize a scenario of how they might interact with
a software system.
 Requirements engineers can use the information gained from this discussion
to formulate the actual system requirements.

16
  Scenarios can be particularly useful for adding detail to an outline
requirements description.
 They are descriptions of example interaction sessions. Each scenario usually
covers one or a small number of possible interactions.
 Different forms of scenarios are developed and they provide different types
of information at different levels of detail about the system.
 Scenario-based elicitation involves working with stakeholders to identify
scenarios and to capture details to be included in these scenarios.
 Scenarios may be written as text, supplemented by diagrams, screen shots,
etc.
 Alternatively, a more structured approach such as event scenarios or use
cases may be used.
2.6.4 Use cases

 Use cases are a requirements discovery technique that were first introduced
in the objectory method and they have now become a fundamental feature of
the unified modeling language.
 In their simplest form, a use case identifies the actors involved in an
interaction and names the type of interaction.
 This is then supplemented by additional information describing the
interaction with the system.
 The additional information may be a textual description or one or more
graphical models such as UML sequence or state charts.
 Use cases are documented using a high-level use case diagram. The set of
use cases represents all of the possible interactions that will be described in
the system requirements.

17
  Actors in the process, who may be human or other systems, are represented
as stick figures. Each class of interaction is represented as a named ellipse.
 Lines link the actors with the interaction.
 Use cases identify the individual interactions between the system and its
users or other systems.
 Scenarios and use cases are effective techniques for eliciting requirements
from stakeholders who interact directly with the system.
 Each type of interaction can be represented as a use case.
 However, because they focus on interactions with the system, they are not as
effective for eliciting constraints or high-level business and nonfunctional
requirements or for discovering domain requirements.

2.6.5 Ethnography

 Ethnography is an observational technique that can be used to understand

operational processes and help derive support requirements for these
processes.
 The value of ethnography is that it helps discover implicit system
requirements that reflect the actual ways that people work, rather than the
formal processes defined by the organization.
 Ethnography is particularly effective for discovering two types of
requirements:
1. Requirements that are derived from the way in which people actually
work, rather than the way in which process definitions say they ought
to work.

18
 2. Requirements that are derived from cooperation and awareness of
other people’s activities
 Ethnographic studies can reveal critical process details that are often missed
by other requirements elicitation techniques.
 However, because of its focus on the end-user, this approach is not always
appropriate for discovering organizational or domain requirements.
 They cannot always identify new features that should be added to a system.
 Ethnography is not, therefore, a complete approach to elicitation on its own
and it should be used to complement other approaches, such as use case
analysis.

2.7 ANALYSIS PRINCIPLES

 Over the past two decades, a large number of analysis modeling methods
have been developed.
 Investigators have identified analysis problems and their causes and have
developed a variety of notations and corresponding sets of heuristics to
overcome them.
 Each analysis method has a unique point of view.
i. The information domain of a problem must be represented and
understood.
ii. The functions that the software is to perform must be defined.
iii. The behavior of the software must be represented.

19
 iv. The models that depict information function and behavior must be
partitioned in a manner that uncovers details in a layered fashion.
v. The analysis process should move from essential information
toward implementation detail.

 In addition to these operational analysis principles for requirements

engineering:
a) Understand the problem before you begin to create the analysis
model.
b) Develop prototype that enable a user to understand how
human/machine interaction will occur.
c) Record the origin of and the reason for every requirement.
d) Use multiple views of requirements.
e) Rank requirements.
f) Work to eliminate ambiguity

2.8 SOFTWARE PROTOTYPING

 The Software Prototyping refers to building software application prototypes

which displays the functionality of the product under development, but may
not actually hold the exact logic of the original software.
 Software prototyping is becoming very popular as a software development
model, as it enables to understand customer requirements at an early stage
of development.

20
 It helps get valuable feedback from the customer and helps software
designers and developers understand about what exactly is expected from
the product under development.
 Prototype is a working model of software with some limited functionality.
 The prototype does not always hold the exact logic used in the actual
software application and is an extra effort to be considered under effort
estimation.
 Prototyping is used to allow the users evaluate developer proposals and try
them out before implementation. It also helps understand the requirements
which are user specific and may not have been considered by the developer
during product design.
 Following is a stepwise approach explained to design a software prototype.

i. Basic Requirement Identification

 This step involves understanding the very basics product

requirements especially in terms of user interface.
 The more intricate details of the internal design and
external aspects like performance and security can be
ignored at this stage.

ii. Developing the initial Prototype

 The initial Prototype is developed in this stage, where

the very basic requirements are showcased and user
interfaces are provided.

 These features may not exactly work in the same

manner internally in the actual software developed.

21
  While, the workarounds are used to give the same
look and feel to the customer in the prototype
developed.

iii. Review of the Prototype

 The prototype developed is then presented to the customer

and the other important stakeholders in the project.
 The feedback is collected in an organized manner and used
for further enhancements in the product under development.

iv. Revise and Enhance the Prototype

 The feedback and the review comments are discussed during

this stage and some negotiations happen with the customer
based on factors like – time and budget constraints and
technical feasibility of the actual implementation.
 The changes accepted are again incorporated in the new
Prototype developed and the cycle repeats until the customer
expectations are met.

 Prototypes can have horizontal or vertical dimensions. A Horizontal

prototype displays the user interface for the product and gives a broader
view of the entire system, without concentrating on internal functions.
 A Vertical prototype on the other side is a detailed elaboration of a specific
function or a sub system in the product.

22
  Horizontal prototypes are used to get more information on the user interface
level and the business requirements. It can even be presented in the sales
demos to get business in the market.
 Vertical prototypes are technical in nature and are used to get details of the
exact functioning of the sub systems. For example, database requirements,
interaction and data processing loads in a given sub system.

2.8.1 Software Prototyping - Types

 Throwaway/Rapid Prototyping

o Throwaway prototyping is also called as rapid or close

ended prototyping.
o This type of prototyping uses very little efforts with
minimum requirement analysis to build a prototype.
o Once the actual requirements are understood, the
prototype is discarded and the actual system is developed
with a much clear understanding of user requirements.

 Evolutionary Prototyping

o Evolutionary prototyping also called as breadboard

prototyping is based on building actual functional
prototypes with minimal functionality in the beginning.

23
 o The prototype developed forms the heart of the future
prototypes on top of which the entire system is built.

o By using evolutionary prototyping, the well-understood

requirements are included in the prototype and the
requirements are added as and when they are understood.

 Incremental Prototyping

o Incremental prototyping refers to building multiple

functional prototypes of the various sub-systems and
then integrating all the available prototypes to form a
complete system.

 Extreme Prototyping

o Extreme prototyping is used in the web development

domain. It consists of three sequential phases.

o First, a basic prototype with all the existing pages is

presented in the HTML format.

o Then the data processing is simulated using a prototype

services layer.
24
 o Finally, the services are implemented and integrated to
the final prototype.

o This process is called Extreme Prototyping used to draw

attention to the second phase of the process, where a
fully functional UI is developed with very little regard to
the actual services.

 The advantages of the Prototyping Model are as follows :

a) Increased user involvement in the product even before its
implementation.
b) Since a working model of the system is displayed, the users get a
better understanding of the system being developed.
c) Reduces time and cost as the defects can be detected much earlier.
d) Quicker user feedback is available leading to better solutions.
e) Missing functionality can be identified easily.
f) Confusing or difficult functions can be identified.

 The Disadvantages of the Prototyping Model are as follows:

a) Risk of insufficient requirement analysis owing to too much

dependency on the prototype.
b) Users may get confused in the prototypes and actual systems.
c) Practically, this methodology may increase the complexity of the
system as scope of the system may expand beyond original plans.

25
d) Developers may try to reuse the existing prototypes to build the
actual system, even when it is not technically feasible.
e) The effort invested in building prototypes may be too much if it is
not monitored properly.

26