Professional Documents
Culture Documents
Software Processes
1
• We have seen
• Software engineering focuses on process
• Proper processes will help achieve project
objectives of high Q&P
2
Software Process
• Process: A particular method, generally
involving a number of steps
4
• A process is a means to reach the goals of
high quality, low cost, and low cycle time,
and a process model provides generic
guidelines for developing a suitable process
for a project.
5
• A process model specifies a general
process, usually as a set of stages in which a
project should be divided, the order in
which the stages should be executed, and
any other constraints and conditions on the
execution of stages.
6
Component Software Processes
7
Development process
• Development process is the heart of software
process; other processes revolve around it
8
• Other processes
• Configuration management process: manages the
evolution of artifacts
• Change management process: how changes are
incorporated
• Process management process: management of processes
themselves
• Inspection process: How inspections are conducted on
artifacts
9
ETVX Approach for Process
Specification
• Process is generally a set of phases
• Each phase performs a well defined task and generally
produces an output
verified
of a few steps
15
• Predictable process is said to be under
statistical control
• Repeatedly using the process produces similar
results
16
• Support Change
• Software changes for various reasons
• Objective of development
• to produce software that is easy to maintain. And the process
used should ensure this maintainability
18
• Early Defect Removal
• Errors can occur at any stage during
development.
21
Software life cycle and process
models
• Due to the importance of the development
process, various models have been
proposed.
• Waterfall Model
• Prototyping
• Iterative Development
• Timeboxing Model
• Spiral model
• Agile model 22
Waterfall Model
• In this model,
• Feasibility analysis requirements analysis
and project planning system design
coding testing system installation
• After system installation, the regular operation
and maintenance of the system takes place.
23
24
• advantages of this model is:
• its simplicity.
• divides the large task of building a software
system into a series of cleanly divided phases,
each phase dealing with a separate logical
concern.
25
• It is also easy to administer
• Limitations
• It assumes that the requirements of a system can be
frozen (i.e., base lined) before the design begins.
27
• The entire software is delivered in one shot at
the end. This entails heavy risks, as the user
does not know until the very end what they are
getting.
28
Prototyping
• Instead of freezing the requirements before
any design or coding can proceed
• a throw-away prototype is built to help
understand the requirements.
29
• Based on known requirement design,
coding, and testing of the prototype is done.
• Basic idea
• Software developed in increments, each
increment adding some functional capability to
the system until the full system is implemented
• steps
• First create initial implementation & project control list
(tasks that must be performed to obtain the final
implementation.)
38
• Barry Boehm recognized this and tired to
incorporate the “project risk” factor into a
life cycle model.
39
40
Agile model
• Agile SDLC model is a combination of iterative
incremental process models with focus on process
adaptability and customer satisfaction by rapid
delivery of working software product.
• Agile model believes that every project needs to be
handled differently and the existing methods need to
be tailored to best suit the project requirements.
• In Agile, the tasks are divided to time boxes (small
time frames) to deliver specific features for a
release.
41
• Iterative approach is taken and working software
build is delivered after each iteration.
• Each build is incremental in terms of features; the
final build holds all the features required by the
customer.
• Every iteration involves cross functional teams
working simultaneously on various areas like −
• Planning
• Requirements Analysis
• Design
• Coding
• Unit Testing and
• Acceptance Testing.
• At the end of the iteration, a working product is
displayed to the customer and important 42
stakeholders.
43
• The advantages of the Agile Model are as follows −
• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and
demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within
an overall planned context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.
44
• The disadvantages of the Agile Model are as follows −
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and
extensibility.
• An overall plan, an agile leader and agile PM practice
is a must without which it will not work.
• Strict delivery management dictates the scope,
functionality to be delivered, and adjustments to meet
the deadlines.
• Depends heavily on customer interaction, so if
customer is not clear, team can be driven in the wrong
direction.
• There is a very high individual dependency, since
there is minimum documentation generated.
• Transfer of technology to new team members may45 be
quite challenging due to lack of documentation.
Timeboxing Model
• Uses parallelism between the different
iterations
• T is 9 weeks
• first delivery is made on 9th week, then 12th , 15th week 44
• Linear execution of iterations,
• The first delivery will be made after 9 weeks,
45
• Man-power
• Suppose ;
• If this project is executed using the timeboxing process model separate team is
• Hence, the timeboxing provides an approach for utilizing additional man-power to reduce
the delivery time. 46
• Timeboxing is well suited for projects that
require a large number of features to be
developed in a short time
47
• Timeboxing is not suitable for
• Projects where it is difficult to partition the overall
development into multiple iterations of approximately
equal duration.