Chapter - 2

Software Processes
 Software Process

• A software process is a coherent set of activities, procedures,

policies, organizational structures, constraints, technologies,
and artifacts that are needed to develop software products.
• The main goal of a software process is to produce quality
software with defined constraints.
• A software process is a set of ordered activities carried out
to produce a software product.
• An activity is a specified task performed to achieve the process
objectives.
• Each activity of software process involves tools and
technologies, procedures, and artifacts.

2
 Process, Project & Product

• A software process is a complex entity in which each activity is

executed with the supporting tools and techniques.
• A software project is an entity, with defined start and end, in which
a software process is being used.
• A successful project is the one that conforms with the project
constraints (cost, schedule, and quality criteria).
• A product is the outcome of a software project produced through
processes.
• A project can have more than one product called work products. A
work product is the intermediate outcome of processes.
• Software process, project, and products are interrelated to each
other for the development of software.

3
Process, Project & Product

Process

Used
Converted
into Produces
Project Product

Used in

Resources

Figure 2.1: Process, Project and Product

4
 Software Process Model

• A software process model is a generic representation of a

software process instantiated for each specific project.
• A process model is a set of activities that have to be
accomplished to achieve the process objectives.
• A process model can be made practical by executing the
concept, technologies, implementation environment, process
constraints, and so on.
• These models may be related to development, management,
improvement, and maintenance.
• Process models specify the activities, work products,
relationships, milestones, etc.

5
Generic representation of Process Model

Definition Phase

Umbrella
activities
Development Phase

Implementation Phase

Figure 2.2: Generic representation of Process Model

6
 Generic representation of process model
• Definition Phase: It concentrates on understanding the problem and
planning for the process model.
– The activities may include problem formulation, problem analysis, system
engineering, and project planning for the process.
• Development Phase: It focuses on determining the solution of the
problem with the help of the umbrella activities.
– The main activities of this phase are designing the architecture and algorithms
of the system, writing codes, and testing the software.
• Implementation Phase: Here, the deployment, change management,
defect removal, and maintenance activities are performed in this phase.
• The umbrella activities are responsible for ensuring the proper execution
of definition, development, and implementation phases.
– The umbrella activities are project management, quality assurance,
configuration management, risk management, work products preparation and
deployment, and process improvement.

7
 Elements of Software Process

• Artifacts are tangible work products (means ‘a physical object that

can be seen, felt, and touched’) produced during the development of
software.
• Activity specifies the tasks to be carried out implicitly (something
is understood but not directly stated) or explicitly (something is clear, direct,
and without ambiguity).
• Constraint refers to the criteria or condition that must be met
or possessed by a software product.
• People are persons or stakeholders who are directly or
indirectly involved in the process.
• Tools and Technology provide technical support to the methods
or techniques to be used for performing the activities.
8
 Elements of Software Process

• Methods or Techniques specifies the way to perform an

activity using tools and technology to accomplish the activity.
• Organizational Structure specifies the team of people that
should be coordinated and managed during software
development.
• There are various software processes involved in software
development, change management, project management,
quality management, process improvements, and so on.

9
 Characteristics of Software Process [Cont’d]

• Understandability,
• Effectiveness,
• Predictability,
• Maintainability,
• Reliability,
• Changeability,
• Improvement,
• Monitoring and Tracking,
• Rapidity, and
• Repeatability.

10
 Characteristics of Software Process [Cont’d]
 These terms describe various characteristics of a software process, which are essential for ensuring
that the software development lifecycle (SDLC) is effective, efficient, and produces high-quality
software. Let's break down each characteristic:
1. Understandability:
The software process should be easy to understand by all stakeholders, including developers,
project managers, and clients. Clear documentation and a well-defined process help ensure
that everyone involved knows what to do and when to do it.
2. Effectiveness:
The process should be effective in achieving its goals, such as delivering software that meets
user requirements, is on time, and within budget. An effective process ensures that the
software project fulfills its intended purpose.
3. Predictability:
The software process should allow for predictable outcomes, meaning that with the same
inputs and conditions, the results should be consistent. Predictability helps in planning and
managing resources effectively.
4. Maintainability:
Software should be easy to maintain, meaning that future modifications, bug fixes, and
updates can be made with minimal effort and risk. A process that emphasizes maintainability
ensures long-term sustainability and adaptability of the software.

11
 Characteristics of Software Process [Cont’d]
5. Reliability:
The process should produce reliable software, which operates correctly under specified conditions.
Reliability ensures that the software performs its intended functions consistently over time.
6. Changeability:
The software process should accommodate changes easily, whether due to evolving requirements,
technology updates, or user feedback. A changeable process ensures that the software can adapt
to new circumstances without significant disruption.
7. Improvement:
The process should include mechanisms for continuous improvement. This involves regularly
reviewing and refining the process to enhance its efficiency, effectiveness, and overall quality.
8. Monitoring and Tracking:
The process should involve continuous monitoring and tracking of progress, quality, and performance.
This helps in identifying potential issues early and ensures that the project stays on track.
9. Rapidity:
The process should be designed to deliver results quickly, reducing the time between the initial
idea and the final product. Rapidity is particularly important in fast-paced environments where
time-to-market is critical.
10. Repeatability:
The process should be repeatable, meaning that the same steps can be followed to achieve the
same results across different projects or iterations. Repeatability ensures consistency and
reliability in software development.
12
 [OR] Characteristics of Software Process
1. Predictability: The software process should provide predictable outcomes,
meaning that similar inputs should yield similar outputs across different
instances.
2. Repeatability: The process should be repeatable, allowing teams to achieve
the same results by following the same steps under similar conditions.
3. Efficiency: It should be efficient in terms of time, cost, and resource
utilization, minimizing waste and optimizing productivity.
4. Quality: The process should focus on delivering high-quality software that
meets the defined requirements and is free of defects.
5. Flexibility: It should be flexible enough to adapt to changes in requirements,
technology, or market conditions.
6. Manageability: The process should be manageable, meaning it can be easily
controlled, measured, and improved over time.
7. Visibility: There should be clear visibility into the progress and status of the
software project at any given time.
8. Consistency: The process should ensure that all stakeholders follow a
consistent approach, which helps in reducing variability and enhancing
communication.
13
 Process Classification

• Software processes may be classified as

– product development process,
– project management process,
– change management process,
– process improvements, &
– quality management process.

14
 Process Classification

• Product Development Process

– Product development processes focus mainly on producing software
products.
– These processes involve various techniques, tools, and technologies for
developing software.
– Such processes include various activities like conceptualization,
designing, coding, testing, and implementation of a new or existing
system.
– There are certain work products of these activities, such as software
requirements specifications (SRS), design models, source codes, test
reports, and documentation
– The most widely used software development process models are the
waterfall model, prototyping model, spiral model, agile model, RUP,
and so on. models.
15
 Process Classification

• Project Management Process

– Project management processes concentrate on planning and
managing projects in order to achieve the project objectives.
– The goal of these processes is to carry out the development
activities within time, budget, and resources.
– There are various project management processes, which are
scope, budget, schedule, quality, information, team, risk, and
contracts.
– Initiating, planning, coordinating, controlling, executing, and
terminating are the main activities of a general project
management process.

16
 Process Classification

• Process Improvement Process

– These processes are involved in improving the process itself.
– The ultimate goal of improvement in a process is to enable the
organization to produce more quality products.
– Process improvement is an incremental improvement of process, which
is used for software development.
– There exist various process improvement process models, such as
CMMI, QIP, continuous quality improvement (CQI), total quality
management (TQM), Six Sigma, and so on.
– All these process models provide improvement guidelines and
standards for improving software processes.

17
 Process Classification

• Configuration Management Process

– Changes may occur in projects, processes, and products as these
entities are evolutionary in nature.
– Changes may arise due to either change in the customer requirements
or discrepancies in the work products or procedures from developer’s
side.
– There is a need for a lot of efforts and systematic procedures for
performing these changes.
– Configuration management includes various activities for performing
changes, such as identification of configuration items, devising
mechanisms for performing changes, controlling changes, and tracking
the status of those changes.

18
 Process Classification

• Quality Management Process

– A quality management process provides metrics, feedback, and
guidelines for the assurance of product quality.
– Quality system ensures that a proper business system is working with
the help of various monitors and controls.
– Software quality organization gives information and expertise to
development and management process for quality production.
– The main activities of software quality groups are verification and
validation, acceptance testing, measurement and metrics, process
consulting, and so on.
– ISO 9000 is a framework that provides certain guidelines for the
quality system.

19
 Phased Development Life Cycle

• Product development process is carried out as a series of certain

activities for software production. Each activity in the process is
also referred to as a phase.
• General activities include feasibility study, analysis, design, coding,
testing, implementation, and maintenance.
• Collectively, these activities are called the software development life
cycle (SDLC) or simply software life cycle and each of these
activities are called life cycle phase.
• The SDLC provides a framework that encompasses the activities
performed to develop and maintain software.
• Some of these models are waterfall, prototyping, spiral, incremental,
agile process, RUP process model, and so on.

20
Phased Life Cycle Activities

Project initiation

Maintenance Analysis

SDLC

Deployment Design

Testing Coding

Figure 2.3: Software Development Life Cycle (SDLC) activities

21
 Phased Life Cycle Activities

• Project Initiation
– The aim of project initiation is to study the existing system;
determine the feasibility of a new system; and define the
scope, key elements, and a plan for the successful
completion of the project.
– Project initiation involves preliminary investigation,
feasibility study, and a project plan.
– Preliminary investigation (PI) is the initial step that gives a
clear picture of what actually the physical system is.
– PI goes through problem identification, background of the
physical system, and the system proposal for a candidate
system.
22
 Phased Life Cycle Activities

• Project Initiation
– The purpose of the feasibility study is to determine whether the
implementation of the proposed system will support the mission
and objectives of the organization.
– Feasibility study ensures that the candidate system is able to satisfy
the user needs; promotes operational, effective use of resources;
and is cost effective.
– There are various types of feasibility study performed, such as
technical, economical, operational, and so on
– Feasibility report is prepared and submitted to the top-level
management. A positive report leads to project initiation.
– A detailed project plan is actually prepared after knowing the
requirements.
23
 Phased Life Cycle Activities

• Requirements Analysis
– Requirement analysis is the process of collecting factual
data, understanding the processes involved, defining the
problem, and providing a document for further software
development.
– Requirement analysis is a systematic approach to elicit,
organize, and document the requirements of a system.
– The requirement analysis phase consists of three main
activities: requirements elicitation, requirements
specification, and requirements verification and validation.

24
 Phased Life Cycle Activities
• Software Design
– Software design focuses on the solution domain of the project on
the basis of the requirement document prepared during the
analysis phase.
– The goal of the design phase is to transform the collected
requirements into a structure that is suitable for implementation
in programming languages.
– The design phase has two aspects: physical design and logical
design.
– Physical design concentrates on identifying the different
modules or components in a system that interact with each other
to create the architecture of the system.
– In logical design, the internal logic of a module or component is
described in pseudo code or in an algorithmic manner.
25
 Phased Life Cycle Activities

• Coding
– The coding phase is concerned with the development of the
source code that will implement the design.
– This code is written in a formal language called a programming
language, such as assembly language, C++, Java, etc.
– Good coding efforts can reduce testing and maintenance tasks.
– Programs must be modular so that they can help in rapid
development, maintenance, and enhancements of the system.
– The programs written during the coding phase must be easy to
read and understand.

26
 Phased Life Cycle Activities

• Testing
– Before the deployment of the software, testing is performed to
remove the defects in the developed system
– Testing covers various errors at the requirements, design, and
coding phases.
– Testing is performed at different levels: unit testing, integration
testing, system testing, and acceptance testing.
– Various special tests are also performed to check the
functionality of the system, such as recovery testing,
performance testing, load testing, security testing, and so on.
– Testing is an important technique of software quality assurance.

27
 Phased Life Cycle Activities

• Deployment
– The purpose of software deployment is to make the software available
for operational use.
– It includes various activities to make a system available for assembly
and to transfer it to the customer site.
– Required resources are procured to operate at the customer site and
important information is collected for the deployment process.
– During deployment, all the programs files are loaded onto user’s
computer. After installation of all the modules of the system, training
of the user starts.
– Documentation is prepared in the form of a user manual or system
operation process which ensures thecontinuity of the system.

28
 Phased Life Cycle Activities

• Maintenance
– The maintenance phase comes after the software product is released
and put into operation through the deployment process.
– Software maintenance is performed to adapt to changes in a new
environment, correct bugs, and enhance the performance by adding
new features.
– The maintenance activities can be classified as adaptive (changes in
the software environment), perfective (new user requirements),
corrective (fixing errors), preventive (prevent problems in the future).
– The software will age in the near future and enter the retirement
stage.
– In extreme cases, the software will be reengineered onto a different
platform.

29
 Software Development Process Models

∙ Classical Waterfall Model,

∙ Incremental Process Models,
∙ The Incremental Model, &
∙ The RAD Model.

∙ Evolutionary Process Models, and

∙ Prototyping Model,

∙ Spiral Model, &

∙ Concurrent Models.

∙ RUP Process Model (Unified Process Model).

30
 Classical Waterfall Model

• The waterfall model is a classical development process model

proposed by R. W. Royce in 1970.
• In this model, software development proceeds through an
orderly sequence of transitions from one phase to the next in
order (like a waterfall).
• It is the simplest and the most widely used model in
development.
• This model produces standard outputs at the end of every
phase, which is called work products.
• This model was enhanced with a feedback process, which is
referred to as an iterative model.

31
 Classical Waterfall Model
Feasibility
study Feasibility report
Requirements
analysis Requirement document
Software
design Design document
Coding
Programs
Testing and
Integration Test reports
Deployment Release
reports
Operation and
Maintenance
Figure 2.4: Classical waterfall model
32
 Classical Waterfall Model

• Advantages
– The main advantage of the waterfall model is that it is easy to
understand and implement.
– It is a document-driven process that can help new people to transfer
knowledge.
– Milestones and deliverables at each stage can be used to monitor the
progress of the project.
– This model works well on large and mature products.
– Where the requirements are well understood and the developers are
confident, the waterfall model works well.

33
 Classical Waterfall Model

• Disadvantages
– The model assumes that the requirements will not change during the project.
Sometimes, it is unrealistic to expect accurate requirements early in a project.
– It is very difficult to estimate the time and cost in the waterfall model.
– The people mentally ready to work in a phase will have to wait until its
previous phase is completed.
– Due to so much emphasis on documentation, sometimes people may become
irritated.
– This model works well on large and mature products.

34
 Classical Waterfall Model
Top ‘5’ Real Time Examples In Our Today’s Day-To-Day Life

• The iterative waterfall model is an extended waterfall model

with backtracking at each phase to its preceding phases.
• The life cycle phases are organized similar to those in the
classical waterfall model. The only difference is backtracking
of phases on detection of errors at any stage.
• The errors can come at any stage of the development life
cycle.
• Once a defect is detected there is a need to go back to the
phase where it was introduced.
• On defect detection at the source, some of the work performed
during that phase and all the subsequent phases may be
revised.

35
 Iterative Waterfall Model

• The iterative waterfall model is an extended waterfall model

with backtracking at each phase to its preceding phases.
• The life cycle phases are organized similar to those in the
classical waterfall model. The only difference is backtracking
of phases on detection of errors at any stage.
• The errors can come at any stage of the development life
cycle.
• Once a defect is detected there is a need to go back to the
phase where it was introduced.
• On defect detection at the source, some of the work performed
during that phase and all the subsequent phases may be
revised.
36
 Iterative Waterfall Model
Feasibility
study Feasibility report
Requirements
analysis Requirement document
Software design
Design document
Coding
Programs
Testing and
integration Test reports
Deployment Release
reports
Operation and
Maintenance
Backtracking

Figure 2.5: Iterative waterfall model

37
 Iterative Waterfall Model

• On error detection at any phase, it may be required that the

preceding and succeeding phases be changed.
• Detecting and removing defects earlier in the process of
software development is called phase containment of errors.
• Removing defects in early phases of development reduces
testing and maintenance efforts.
• The iterative waterfall model is the most widely used model
and it is simple to apply it in projects.
• Still it is a document-driven model.

38
 Iterative Waterfall Model

• It is very difficult to manage changes between the phases.

• There is a possibility of blocking states, which can slow down
the productivity and efficiency of the process.
• Risks are not addressed in this model.
• This model is most suitable for simple projects where the
work products are well defined and their functioning is
understood.

39
 Incremental Model

• The incremental model is an intuitive approach to the waterfall

model with fewer restrictions.
• The activities are performed in the same order as in the
waterfall model, but they are conducted in several iterations.
• Each iteration releases a fully functional work product by
providing additional functionalities in successive releases.
• The final iteration releases the complete product .

40
 Incremental Model

Iteration 1 Release 1
Design Coding Testing Deployment

Iteration 2 Release 2
Requirement Design Coding Testing Deployment Operation
analysis and
maintenance
… …
Iteration N Release N
Design Coding Testing Deployment

Figure 2.7: Incremental Model

41
 Incremental Model

• The requirements are functionally divided and prioritized according to the needs of
the customers.
• A blueprint of the product based on the prioritized requirements is also designed,
which describes dependency of tasks on each other.
• A project control list is prepared, describing the order of the tasks to be performed
and outcomes of the task to be released.
• Each task in the project control list is treated as a mini project. Each item in the list
is a module, which is to be developed in increments.
• Each task is removed from the project control list and developed using the waterfall
model in a sequential manner.
• Each new release is integrated with the existing increments to provide enhanced
functionality with each delivered increment.
• The length of iterations is generally kept very short and fine. For example, an
iteration can be a duration of 6 weeks, 10 weeks, etc.

42
 Incremental Model

• The main advantage of the incremental model is the early

production of working software during the software life cycle.
• Because each module is tested thoroughly, there is little possibility
to change scope and requirements in the final software.
• Due to incremental development, testing and debugging of each
module become easier.
• This model is also helpful in handling risks (technical, requirements,
usability, etc.) because risky modules are identified and handled in a
separate iteration.
• This model is suitable for larger projects where requirements are
somewhat clear and which need phase-wise implementation.

43
 Incremental Model

• Mostly this model is used in web applications, object-oriented

development projects, and product-based companies.
• Also, it is widely used by many commercial software
companies and system vendors.
• Each phase of an iteration is rigid and does not overlap
another. Therefore, coordination between iterations is required
for better quality products.

44
 Rapid Application Development (RAD) Model

• It is an incremental software development process model that

emphasizes an extremely short development cycle. [OR]

• It is an incremental software development process model that

emphasizes an extremely short development cycle with rapid
prototyping, quick feedback from users, & iterative delivery
over traditional long planning process models.

• It is a high – speed adaptation of the linear sequential model

like the classical waterfall model.

• It enables a development team to create a fully functional system

within very short time periods (e.g. 60 to 90 days).
45
Rapid Application Development (RAD) Model

 RAD Model typically consists of ‘4’ key phases:

1. Business modeling: Information flow among business
functions,
2. Data modeling: data objects, & relationship between objects.
3. Process modeling: information flow, adding, modifying,
deleting, and retrieving the data objects.
4. Application generation: Generation with various programming
languages.
5. Testing and turnover: reduces overall testing time, & reuses.
[OR]

46
Rapid Application Development (RAD) Model
 RAD Model typically consists of ‘4’ key phases:

47
Rapid Application Development (RAD) Model Diagram

48
Rapid Application Development (RAD) Model
 RAD Model: Real-Time Example [Banking Application Development]:

49
Rapid Application Development (RAD) Model
 RAD Model: Real-Time Example [Banking Application Development]:

50
Rapid Application Development (RAD) Model
 RAD Model: When to Use RAD? & Avoid RAD if:

51
Rapid Application Development (RAD) Model
 RAD Model: Comparison with Traditional Waterfall Model:

52
Rapid Application Development (RAD) Model – Pro’s & Con’s

• Multiple software teams work in parallel on different functions.

• Modeling encompasses three major phases: Business
modeling, Data modeling, and process modeling.
• Construction uses reusable components, automatic code
generation, and testing.

Problems in RAD:
• Requires a number of RAD teams.
• Requires commitment from both developer and customer for
rapid-fire completion of activities.
Rapid Application Development (RAD) Model – Pro’s & Con’s
 Prototyping Model
• Prototyping is an alternative in which partial working software (i.e.
a prototype) is initially developed instead of developing the final
product.
• IEEE defines prototyping as “a type of development in which
emphasis is placed on developing prototypes early in the
development process to permit early feedback and analysis in
support of the development process” .
• Prototype development is a toy implementation, which provides a
chance to the customer to give feedback for final product
development.
• A prototype provides limited functionalities, low reliability, and
insufficient performance as compared to the actual software.
• A prototype helps customer to understand the requirements that can
further reduce the possibility of requirement changes.

55
 Prototyping Model
Information
gathering

Quick
design

Refine Build prototype

requirements

Incorporate customer Customer

suggestions evaluation
Customer satisfied
Design

Coding

Testing

Deployment

Maintenance

Figure 2.6: Prototyping model

56
 Prototyping Model
 Prototyping Model: Real-Time Example [Hotel Reservation System]:

57
 Prototyping Model
 When to Use Prototyping? & Avoid Prototyping if:

58
 Prototyping Model Pro’s & Con’s
• The prototype model is well suited for projects where
requirements are difficult to understand and the customer is
not confident in illustrating and clarifying the requirements.
• It fits best where the customer risks are related to the changing
requirements (software and hardware requirements) of the
projects.
• But this model requires exclusive involvement of the
customer, which is not always possible.
[OR]

59
Prototyping Model Pro’s & Con’s

60
 Spiral Model

• The spiral model is an iterative software development

approach, which was proposed by Boehm in 1988.
• In this model, activities are organized as a spiral with many
loops.
• Each loop in the spiral represents a phase of software
development.
• The exact number of loops in the spiral is not fixed.
• The main focus of this model is identification and resolution
of potential risks (product risks, project risks, and process
risks).

61
Spiral Model

62
 Spiral Model

• Each loop in the spiral is split into four quadrants. Each of

these four quadrants is used for the development of each
phase.
– Determine objectives, alternatives, and constraints.
– Evaluate alternatives; identify and resolve risks.
– Develop, verify the next level product.
– Plan for the next phase.

63
 Spiral Model

• The radial dimension represents the cumulative cost incurred

so far for the development of phases in a project.
• The angular dimension indicates the progress made so far in
completing each cycle.
• It is considered a meta model because it incorporates the
features of all other models, which are the waterfall,
prototyping, incremental, simulation, and performance
models.
• The performance of prototype development is evaluated using
benchmarking tools, simulation models, and customer
feedback.

64
 Spiral Model

• The iterative and risk-driven approach of the spiral model is

widely used in software development.
• This model is most suitable for projects having high risks and
also for large, complex projects.
• The estimates (i.e. budget, schedule, etc.) get more realistic as
work progresses because important issues are discovered
earlier.

65
 RUP Process Model

• The Rational Unified Process (RUP) is a use-case driven (it is a software

development methodology that focuses on the user experience and uses use
cases to guide the development process), architecture-centric (the Unified
Process specifies that the. architecture of the system being built, as the.
fundamental foundation on which that system will rest, must sit at the heart of the
project), iterative, and incremental process model.
• The RUP focuses on creating and maintaining models rather than
documentation.
• It is derived from Unified Modeling Language (UML), which is an
industry-standard language that helps to clearly communicate
requirements, architectures, and designs.
• The RUP is supported by tools which automate most of the activities of the
process.
• The RUP divides the development cycle into four consecutive phases;
namely, inception, elaboration, construction, and transition.
66
RUP Process Model

67
 RUP Process Model

• Inception phase:
– It establish the business case (it is a document that justifies a project or
initiative in software engineering by evaluating the potential benefits, costs, and risks. It
helps decision-makers determine if a proposed strategy is feasible and worth the
investment)
for the system and delimit the project scope.
– The business case includes success criteria, risk
assessment, and estimate of the resources needed; and a
phase plan showing dates of major milestones.
– This phase produces vision document of the project, initial
use-case model, initial risk assessment, business model,
and a project plan showing the phases and iterations.
– At this stage, customers will be clear with their
requirement and life cycle objectives milestone will be
produced. 68
 RUP Process Model

• Elaboration phase:
– It analyzes the problem domain, establish an architectural
framework, develop the project plan, and eliminate the highest
risk elements of the project.
– The architectural decisions have to be made with an
understanding of the whole system: its scope, major functional
and nonfunctional requirements.
– In the elaboration phase, an executable architecture prototype is
built in one or more iterations, depending on the scope, size,
risk, and novelty of the project.
– At the end of the elaboration phase, the second important project
milestone will be the life cycle architecture milestone.

69
 RUP Process Model

• Construction phase:
– During the construction phase, all application features are
developed, integrated, and thoroughly tested.
– This phase also focuses on the user manuals and the current
release details.
– At the end of this phase, a beta release becomes operational
for the customers.

70
 RUP Process Model

• Transition phase:
– The purpose of the transition phase is to move the software
product to the user community for working.
– This phase includes several iterations, including beta
releases, general availability releases, as well as bug-fix
and enhancement releases.
– Effort is made in developing user-oriented documentation,
training users, supporting users in their initial product use,
and reacting to user feedback.

71
 RUP Process Model
• Each phase in the RUP can be further broken down into iterations.
• Each iteration in the RUP mitigates risks, manage changes, provide reuse,
and produces better quality products as compared to the traditional
waterfall process.
• The RUP is suitable for small development teams as well as large
development organizations.
• It can be found in a simple and clear process architecture that provides
commonality across a family of processes.
• Workflow represents the sequence of activities that produces a result of the
observable value.
• Workflows are divided into six core workflows (business modeling
workflow, requirements workflow, analysis and design workflow,
implementation workflow, test workflow, deployment workflow) and three
supporting workflows (project management workflow, configuration and
change management workflow, and environment workflow).

72
 RUP Process Model

• The RUP is a complete methodology in itself that emphasizes

documentation.
• It helps to proactively resolve project risks related with changing
requirements.
• The RUP process is openly published, distributed, and supported for
operation.
• It requires less time for integration of reusable components as the
process of integration goes on throughout the software development
life cycle.
• However, some expertise is required to develop software using this
methodology.
• The development process is very complex and not well organized.

73
 Concurrent Process Model (CPM)

• The concurrent development model (CDM) / concurrent process model

(CPM) is called as concurrent model or concurrent engineering.
• The communication activity has completed in the first iteration and
exits in the awaiting changes state.
• The modeling activity completed its initial communication and then go
to the under development state.
• If the customer specifies the change in the requirement, then the
modeling activity moves from the under development state into the
awaiting change state.

[OR]
74
Concurrent Process Model (CPM)

75
Concurrent Process Model (CPM)

76
Concurrent Process Model (CPM)

77
Concurrent Process Model (CPM)

78
 Concurrent Process Model (CPM)
 Concurrent Model: Real-Time Example [Mobile-Banking App
Development System]:

79
 Concurrent Process Model (CPM)

Advantages of the concurrent development model

• This model is applicable to all types of software development
processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
Disadvantages of the concurrent development model
• It needs better communication between the team members. This may
not be achieved all the time.
• It requires to remember the status of the different activities.
[OR]
80
Concurrent Process Model (CPM)

81
Concurrent Process Model (CPM)

82
 Agile Process Model
• The agile process model is a group of software development methodologies
based on iterative and incremental development.
• In February 2001, ‘17’ software developers published the manifesto of agile
software development to define the approach.
• Some of the manifesto's authors formed the agile alliance. The manifesto of
agile software development is as follows:
 “We are uncovering better ways of developing software by doing it and helping
others to do it” .
• The Agile manifesto consists of four key values:
– Individuals and interactions over processes and tools (collaborate and solve),
– Working software over comprehensive documentation,
– Customer collaboration over contract negotiation (feedback loop), and
– Responding to change over following a plan (dynamic roadmap).
• Agile ≠ Change.
• Agile = Ability to Embrace, Manage, and Respond to Change Effectively.
• Hence, Agile is "changing in nature" — but in a controlled, customer-
focused, and iterative way. [OR] 83
Agile Process Model

84
Agile Process Model

85
Agile Process Model (Extreme Programming – XP)
Simple design CRC
cards
Spike solutions prototype

User stories, acceptance

criteria, iteration plan Design

Coding
Planning
Refactoring

Pair programming
Test

Release Unit test and

Acceptance testing continuous
integration

Figure 2.9: Extreme Programming Process (XP)

86
Agile Process Model (Extreme Programming – XP)

87
Agile Process Model (SCRUM)

88
Agile Process Model (SCRUM)

89
Agile Process Model (KANBAN)

90
Agile Process Model (KANBAN BOARD)

91
Agile Process Model (KANBAN BOARD)

92
Agile Process Model (KANBAN Example)

93
Agile Process Model (‘12’ Principles)

94
Agile Process Model (‘12’ Principles)

95
Agile Process Model (‘12’ Principles)

96
Agile Process Model (‘12’ Principles)

97
Agile Process Model

98
Agile Process Model

99
 Agile Process Model
• Agile software development methods
– extreme programming (XP) (Ford, IBM)
– Scrum (Financial, legal & consultancy, Construction, data
analytics, pharma, engineering services)
– dynamic systems development method (DSDM),
– adaptive software development (ASD),
– Crystal, feature-driven development (FDD),
– test-driven development (TDD),
– pair programming,
– refactoring,
– agile modeling,
– Internet speed development, and so on

100
 Agile Process Model

• Extreme Programming (XP) (initiated by Kent Beck)

– XP is a system of practices that is being evolved by a community of
software developers to address the problems of quickly delivering
quality software.
– Extreme programming process is an iterative development process
which consists of planning, design, coding, and test phases.
– The XP process is the most suitable practice for dynamically changing
requirements, projects having risks, small developer groups, and non-
fixed scope or price contract.
– However , XP is difficult to get representative of customers, who can
sit with the team and work with them daily.
– Also, there is a problem of architectural design because the incremental
style of development means that inappropriate architectural decisions
are made at an early stage of the process.
101
 Agile Process Model

• Scrum
– Scrum is another popular agile framework with a set of roles and
practices.
– It is also an iterative process with the idea of timeboxing, which
is known as sprint.
– Scrum relies on a self-organizing, cross-functional team.
– There are two roles in the Scrum process: pigs and chickens.
– Pigs group includes product owner, Scrum master, and a Scrum
team.
– The group “chickens” involves users, stakeholders, and
managers
– In the Scrum process, product backlog describes "what" will be
built, which is managed by the product owner.
102
 Scrum

• Benefits and drawbacks to Scrum Process

– It is a completely developed and tested feature in short
iterations.
– It is a simple process with clearly defined rules. It increases
productivity and the self-organizing team member carries a
lot of responsibility.
– It improves communication and combination with extreme
programming.
– It has no written documentation and sometimes violation of
responsibilities.

103
 REQUIREMENTS

 Types of Requirements: The requirements are mainly

categorized into ‘5’ types:
1. Functional Requirements (FR),
2. Non – Functional Requirements (NFR),
3. User Requirements (UR),
4. System Requirements (SR), and
5. Interface Requirements / Specifications.

104
REQUIREMENTS

105
REQUIREMENTS

106
REQUIREMENTS

107
REQUIREMENTS

108
REQUIREMENTS

109
Software Requirements Specification / Document [SRS / SRD]

110
Software Requirements Specification / Document [SRS / SRD]

111
Software Requirements Specification / Document [SRS / SRD]

112
Software Requirements Specification / Document [SRS / SRD]

113
Software Requirements Specification / Document [SRS / SRD]

114
Software Requirements Specification / Document [SRS / SRD]

115
Software Requirements Specification / Document [SRS / SRD]

116
Software Requirements Specification / Document [SRS / SRD]

117
SUMMARY TABLE

118