The document discusses various software process models. It begins by defining a software process as a structured set of activities needed to develop software. It then describes key attributes of a software process like understandability, visibility, and supportability. The document outlines common software process activities like requirements engineering, design, implementation, testing, and maintenance. It also discusses different software process models like waterfall, prototyping, iterative waterfall, incremental, and spiral. The waterfall model involves sequential phases from requirements to maintenance while prototyping and incremental models involve iterative development of prototypes or increments to refine requirements.

1. Software Life Cycle
Models

2. Software Process
It is a structured set of activities required to develop a
software system. It is needed to transform a user’s
requirements into a software system.
Process Attributes
 Understandability - To what extent is the process
explicitly defined and how easy is it to understand?
 Visibility - Do the process activities culminate in
clear results so that the progress of the process is
externally visible?
 Supportability - To what extent can the process
activities be supported by CASE tools?

3. Software Process
 Acceptability - acceptable and usable by engineers?
 Reliability – Are process errors avoided or trapped
before they result in product errors?
 Robustness - Can the process continue in spite of
unexpected problems?
 Maintainability - Can the process evolve to reflect
changing organizational requirements or identified
process improvements?
 Rapidity - How fast can the process of delivering a
system from given specification be completed?

4. Software Process Activities
 Requirements Engineering (Specifications):
Finding out, understanding and documenting what
the client wants the software to do; the activities in
this phase include: Feasibility study, Requirements
Elicitation and Analysis, Requirements Validation,
Requirements Specification
 Design – Planning the software solution; modelling
data structures, software architecture, interface
representations, algorithmic details

5. Software Process Activities
 Implementation: Coding and user documentation.
 Testing: Activities for checking for bugs,
verification and validation, integration, and quality
assurance.
 Software Evolution/Maintenance: Adjusting or
changing the existing software product after
delivery.

6. Software Process model
 A software process model is a descriptive and
diagrammatic representation of the software
life cycle.
 It represents all the activities required to make a
software product from its inception to retirement.
 It specifies the process, tools and methods that
support the engineering process and it also
captures the order in which these activities are to
be undertaken.

7. Software Process model
 Different life cycle models may map the basic
development activities to phases in different ways
but the basic activities are included in all life cycle
models.
 More than one activity may also be carried out in a
life cycle phase.

8. Software Process model
 Process models for software engineering are
chosen depending on:
o nature of the project or application at hand;
large and complex, small, enterprise, custom
etc.;
o methods; technical how-to's for building
software; a broad array of tasks that include
requirements analysis, design, program
construction, testing, and support;
o and tools (automated and semi-automated) to
be used and the controls and deliverables
required.

9. The need for a software life cycle model
 The development team must identify a suitable life
cycle model for a particular project and then adhere
to it otherwise the development of a software
product would not be in a systematic and
disciplined manner.
 There must be a clear understanding among the
developing team members about when and what to
do.
 Without a software life cycle model the entry and
exit criteria for a phase cannot be recognized and it
becomes difficult for software project managers to
monitor the progress of the project.

10. Application of process models
 They organize software development and thus
increase the quality of a process
 Process models represent:
o Repeatability: can someone re-run through the
steps in this process?
o Manageability and measurability: are
milestones and timelines visible? Is the
development still within scope? What should be
done? Which sequence should be followed?

11. Application of process models
 They more clearly define and justify interim work
products; since there are well and pre-defined
deliverables, it enables easy tracking of progress.
 Using process models doubles as an activity
inventory/reminder and therefore one is ‘less likely
to forget activities’.

12. Different software life cycle models
 The most commonly used life cycle models
are :
1. Build and Fix Model
2. Classical Waterfall Model
3. Prototyping Model
4. Iterative Waterfall Model
5. The Incremental Model
6. Reuse-oriented software engineering
7. RAD
8. Spiral Model

13. The Build and Fix Model
 Product is constructed without specifications or an
attempt at design
 Adhoc approach and not well Defined
 Simple two phase model
13
Build
code
Fix

14. The Build and Fix Model
 Suitable for small programming exercises of 100 or
200 lines. Unsatisfactory for software of any
reasonable size
 Code soon becomes unfixable & un enhanceable
 No room for structured design
 Maintenance is practically not possible
14

15. The Classical Waterfall Model
 It was first described in 1970s for aerospace and
defense projects. It is a very straightforward model;
finish one phase, then move on to the next. No going
back. Each stage relies on information from the
previous stage (“waterfalls” into the next).
 It suggests a systematic, sequential approach to
software development progressing through analysis,
design, implementation, testing and maintenance.
 The biggest drawback of this model is that small
details left incomplete can hold up the entire
process.
15

16. The Classical waterfall model
 In practice the stages might overlap, and feed
information to each other: during design, problems in
requirements are identified; during coding, design
problems are found and so on.
The phases of the Classical waterfall model are:
 Requirements Analysis and Specification
 Design
 Coding and Unit Testing
 Integration and System Testing
 Maintenance
16

17. The classical waterfall model

18. The Classical Waterfall Model
Waterfall model can be used when
 Requirements are not changing frequently
 Application is not complicated and big
 Project is short
 Requirements are clear
 Environment is stable
 Technology and tools used are not dynamic
and is stable
 Resources are available and trained
18

19. The Classical Waterfall Model
Advantages of the Waterfall Methodology
 This model provides discipline and gives a tangible
output at the end of each phase. Once the scope is
defined, establishing and managing a timeline is
straightforward.
Disadvantages of the Waterfall Methodology
1. This model doesn’t work well when flexibility is a
requirement or if the project is long term and
ongoing. There is little room for change once a
phase is deemed complete.
19

20. The Classical Waterfall Model
2. There is no room for revisions; once a stage is
completed problems can’t be fixed until you get to
the maintenance stage.
3. Early delays can throw off the entire project timeline.
4. Changes made in the scope can impact cost, time,
and quality of the software. Additionally, if tasks
aren’t carried out properly in each stage, or if new
tasks require attention at a later stage, the entire
project has a severe impact.
20

21. Shortcomings of the Classical Waterfall Model
 This model assumes that no development error is
ever committed by the engineers during any of the
life cycle phases (which is not true).
 The source of the defects which may be due to an
oversight, wrong assumption, use of inappropriate
technology, communication gap among the project
engineers, etc. usually get detected much later in the
life cycle.
 It is difficult to define all requirements at the
beginning of a project.
21

22. Shortcomings of the Classical Waterfall Model
 This model is not suitable for accommodating any
change.
 A working version of the system is not seen until late
in the project’s life
 It does not scale up well to large projects
 Real projects are rarely sequential.
22

23. THE PROTOTYPING MODEL
23

24. PROTOTYPING
 A prototype (an early approximation of a final
system or product) is built, tested, and then
reworked upon as necessary until an acceptable
prototype is finally achieved from which the
complete system or product can now be
developed.
 This model works best in scenarios where not all
of the project requirements are known in detail
ahead of time.
 It is an iterative, trial-and-error process that
takes place between the developers and the
users
24

25. PROTOTYPING
25

26. Prototype Model
 A system prototype may be used while the system is
being designed.
 Prototyping is also an essential part of the user interface
design process since end-user involvement is the only
sensible way to develop graphical user interfaces for
software systems.
 A prototype usually exhibits limited functional
capabilities, low reliability, and inefficient performance
compared to the actual software
 A prototype is usually built using several shortcuts. The
shortcuts might involve using inefficient, inaccurate, or
dummy functions 26

27. Prototype Model
 A prototype usually turns out to be a very crude
version of the actual system.
 A software prototype can be used to help anticipate
changes that may be required:
1. In the requirements engineering process: i.e. in
the elicitation and validation of system
requirements.
2. In the system design process: to explore
particular software solutions and to support user
interface design.
27

28. Prototype Model
 System prototypes allow users to see how well the
system supports their work. They may get new ideas
for requirements, and find areas of strength and
weakness in the software to enable them propose
new system requirements.
 As the prototype is developed, more errors and
omissions are revealed in the requirements that
have been proposed.
28

29. PROTOTYPING
The basic steps are:
1. Identify the user’s information and operating
requirements.
2. Develop a working prototype that focuses on only the
most important functions, using a basic data base.
3. Allow the user to use the prototype, discuss
requested changes and implement the most
important changes.
4. Repeat the next version of prototype with further
changes incorporated until the system fully meets
user requirements.
29

30. PROTOTYPING
 A process model for prototype development is shown
here.
 The objectives of prototyping should be made explicit from
the start of the process. If the objectives are not stated
properly management or end-users may misunderstand
the function of the prototype and they may not get the
benefits that they expected from the prototype
development. 30

31. PROTOTYPING
 The next stage is to decide what to put into and
what to leave out of the prototype system.
 To reduce prototyping costs and accelerate the
delivery schedule, some functionalities of the
prototype may be left out e.g. some non-functional
requirements, error handling and management,
standards of reliability and program quality may be
reduced.
 The final stage is prototype evaluation. Provision
must be made at this stage for user training and
the prototype objectives are used to derive a plan
for evaluation. 31

32. PROTOTYPING
 A general problem with prototyping is that the
prototype may not necessarily be used in the same
way as the final system. The tester of the prototype
may not be the typical system user.
 The training time during prototype evaluation may be
insufficient. If the prototype is slow, the evaluators
may adjust their way of working and avoid those
system features that have slow response times.
 Developers are sometimes pressured by managers
to deliver throwaway prototypes, particularly when
there are delays in delivering the final version of the
software.
32

33. PROTOTYPING
This is however unwise:
1. It may be impossible to tune the prototype to meet
non-functional requirements, such as performance,
security, robustness, and reliability requirements,
which were ignored during prototype development.
2. Rapid change during development inevitably
means that the prototype is undocumented. The
only design specification is the prototype code
which is not good enough for long-term
maintenance.
33

34. PROTOTYPING
3. The changes made during prototype development
will probably have degraded the system structure.
The system will be difficult and expensive to
maintain.
4. Organizational quality standards are normally
relaxed for prototype development.
34

35. TYPES OF PROTOTYPES
Throwaway or Rapid Prototyping
Evolutionary prototyping
35

36. Throwaway or Rapid Prototyping
 Also called close ended prototyping.
 It refers to the creation of a model that will
eventually be discarded rather than becoming part
of the final delivered software.
 It is meant to show the users what their
requirements may look like when they are
implemented into a finished system.
 Strength of Throwaway Prototyping is its ability to
construct interfaces that the users can test. The
users can easily grasp how the system will work.
36

37. Evolutionary Prototyping
 Also known as breadboard prototyping.
 It is a very robust prototype which forms the heart
of the new system upon which subsequent
improvements and further requirements will be
built.
 This technique allows developers to add features,
or make changes that couldn't be conceived
during the requirements and design phase.
37

38. Evolutionary Prototyping
 In Evolutionary Prototyping, developers can focus
themselves to develop parts of the system that
they understand clearly first. They do not
implement poorly understood features.
 The partial system is sent to the users and as the
users work with the system, they detect
opportunities for new features and give requests
for these features to developers.
 Developers then take these enhancement
requests to change the software-requirements
specification, update the design, recode and
retest. 38

39. Need for a prototype in software development
 A prototype illustrates the input data formats,
messages, reports, and the interactive dialogues
to the customer.
 The customer understands:
1) how the screens might look like
2) how the user interface would behave
3) how the system would produce outputs
 It is always impossible to get the perfect product
in the first attempt. A good product is always
obtained if you throw away the first version.
39

40. Need for a prototype in software development
 The experience gained in developing the prototype
can be used to develop the final product.
 A prototyping model can be used when technical
solutions are unclear to the development team. A
developed prototype can help engineers to critically
examine the technical issues associated with the
product development.
40

41. Need for a prototype in software development
 A prototype is often preferred in situations such as
when:
1. User requirements are not complete
e.g. when users of the software are not clear
about the different functionalities required. Once
they are provided with the prototype
implementation, they can try to use it and find out
the missing functionalities.
2. Technical issues are not clear
The software development team can start a
project using a simple language. After
successfully building a small prototype they can
extend it to one that works best. 41

42. Advantages of Prototyping
 Prototype reduces the development time.
 It reduce the development cost.
 It requires the users involvement.
 It results in higher user satisfaction.
 Prototypes are an active, not passive, model that
end users can see, touch & feel.
 Prototyping can increase creativity because it
allows for quicker user feedback which can lead to
better solutions. 42

43. Disadvantages of Prototyping
 Prototyping often leads to premature commitment
to a design.
 Prototyping can reduce creativity in designs.
 Not suitable for large applications.
 Structure of system can be damaged since many
changes could be made.
 Developer misunderstanding of user objectives.
43

44. The Incremental Model
44

45. The Incremental Model
 An initial implementation is developed, exposed
to user comment and it evolves through several
versions until an adequate system has been
developed.
 Specification, development, and validation
activities are interleaved rather than separate,
with rapid feedback across activities.
 Developing the software incrementally is
cheaper and it is easier to make changes in the
software as it is being developed.
45

46. The Incremental Model

46

47. The Incremental Model
 Each increment or version of the system incorporates
some of the functionality that is needed by the
customer.
 Generally, the early versions of the system include the
most important or most urgently required functionalities.
This means that the customer can evaluate the system
at a relatively early stage in the development.
 The first version / increment is often a core product.
 Basic requirements are addressed first, but many
supplementary features (some known, others unknown)
remain undelivered. The core product is used by the
customer (or undergoes detailed review). 47

48. The Incremental Model
 Basic requirements are addressed first, but many
supplementary features (some known, others
unknown) remain undelivered. The core product is
used by the customer (or undergoes detailed
review).
 Incremental development is particularly useful
when staffing is unavailable for a complete
implementation by the business deadline that has
been established for the project. Early increments
can be implemented with fewer people.
48

49. The Incremental Model
Example
 A word-processing software developed using the
incremental model might deliver basic file
management, editing, and document production
functions in the first increment;
 The second increment may have more sophisticated
editing and document production capabilities.
 spelling and grammar checking may be incorporated
in the third increment;
 Advanced page layout capability may be in the
fourth increment.
49

50. Problems of the Incremental Model
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. Unless time and money is
spent on refactoring to improve the software,
regular change tends to corrupt its structure.
Incorporating further software changes becomes
increasingly difficult and costly.
50

51. Benefits of the Incremental Model
Incremental development has three important
benefits, compared to the waterfall model:
1. The cost of accommodating changing
customer requirements is reduced. The
amount of analysis and documentation that has
to be redone is much 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. 51

52. The Incremental Model
3. More rapid 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.
52

53. The Incremental Model
 The problems of incremental development become
particularly acute for large, complex, long-lifetime
systems, where different teams develop different
parts of the system. The responsibilities of the
different teams working on parts of the system need
to be clearly defined with respect to that architecture.
This has to be planned in advance rather than
developed incrementally.
 Incremental delivery and deployment means that the
software is used in real, operational processes and
this may disrupt normal business processes.
53

54. Incremental Model Strengths
 Develop high-risk or major functions first
 Each release delivers an operational
product
 Customer can respond to each build
 Uses “divide and conquer” breakdown of
tasks
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality
early
 Risk of changing requirements is reduced

55. Incremental Model Weaknesses
 Requires good planning and design
 Requires early definition of a complete and
fully functional system to allow for the
definition of increments
 Well-defined module interfaces are required
(some will be developed long before others)
 Total cost of the complete system is not
lower

56. When to use the Incremental Model
 Risk, funding, schedule, program complexity, or
need for early realization of benefits.
 Most of the requirements are known up-front
but are expected to evolve over time
 A need to get basic functionality to the market
early
 On projects which have lengthy development
schedules
 On a project with new technology

57. Reuse-oriented Software
Engineering

58. Reuse-oriented software engineering
 In many software projects, there is some software
reuse in case the developers know of designs or
code that are similar to what is required. They
modify them as needed, and incorporate them into
their system.

59. Reuse-oriented software engineering
The initial requirements specification stage and the
validation stage are comparable with other software
processes but the intermediate stages in a reuse-
oriented process are different. These stages are:
1. Component analysis:
Given the requirements specification, a search is
made for components to implement that specification.
2. Requirements modification
The requirements are analyzed using information
about the components that have been discovered.
They are then modified to reflect the available
components.

60. Reuse-oriented software engineering
3. System design with reuse:
The framework of the system is designed or an
existing framework is reused. Some new software
may have to be designed if reusable components
are not available.
4. Development and integration
Software that cannot be externally procured is
developed, and the components are integrated to
create the new system.

61. Advantages of Reuse-oriented software engineering
1. The amount of software to be developed is
reduced
2. Cost and risks are reduced.
3. It leads to faster delivery of the software.
N.B: Requirements compromises are inevitable and
this may lead to a system that does not meet the real
needs of users.
Some control over the system evolution may be lost
as new versions of the reusable components are not
under the control of the organization using them.

62. Rapid Application Development
(RAD)

63. Rapid Application Development (RAD)
 It is an incremental software development process
model that emphasizes a short development cycle
(e.g., 60 to 90 days).
 It is a “high-speed” adaptation of the linear
sequential model in which rapid development is
achieved by using component-based construction
 If requirements are well understood and project
scope is constrained, the RAD process enables a
development team to create a “fully functional
system” within very short time periods.

64. Rapid Application Development (RAD)
Fundamentals of the RAD methodology include:
 Combining the best available techniques and
specifying the sequence of tasks that will make those
techniques most effective.
 Using evolutionary prototypes that are eventually
transformed into the final product.
 Using workshops, instead of interviews, to gather
requirements and review design.
 Selecting a set of CASE tools to support modelling,
prototyping, and code re-usability, as well as
automating many of the combinations of techniques.

65. Rapid Application Development (RAD)
 Implementing time-boxed development that allows
development teams to quickly build the core of the
system and implement refinements in subsequent
releases.
 Providing guidelines for success and describing
pitfalls to avoid.

66. Rapid Application Development (RAD)
The RAD approach has the following phases
 Business Modeling. The information flow among
business functions is modeled in a way that
answers the following questions:
 What information drives the business process?
 What information is generated?
 Who generates it?
 Where does the information go?
 Who processes it?

67. Rapid Application Development (RAD)
 Data Modeling. The information flow defined as
part of the business modeling phase is refined into
a set of data objects that are needed to support
the business.
 The characteristics (attributes) of each object are
identified and the relationships between these
objects defined.

68. Rapid Application Development (RAD)
 Process Modeling. The data objects defined in
the data modeling phase are transformed to
achieve the information flow necessary to
implement a business function.
 Processing descriptions are created for adding,
modifying, deleting, or retrieving a data object.

69. Rapid Application Development (RAD)
 Application Generation. RAD assumes the use
of fourth generation techniques and tools like
Visual Basic, Visual C++, Delphi etc. rather than
creating software using conventional third
generation programming languages. The RAD
process works to reuse existing program
components (when possible) or create reusable
components (when necessary). In all cases,
automated tools are used to facilitate construction
of the software.

70. Rapid Application Development (RAD)
 Testing and turnover. Since the RAD process
emphasizes reuse, many of the program
components have already been tested. This
reduces overall testing time.
 New components must be tested and all interfaces
must be fully exercised.

71. Rapid Application Development (RAD)


72. When to use RAD
 Primarily for information systems applications.
 Where requirements are well understood.
 If a business application can be modularized so
that each major function can be completed within
the development cycle

73. RAD Advantages
 A system can be developed in a short time.
 There is early visibility due to prototyping.
 The methodology provides greater flexibility
because the developers can redesign almost at will.
 Reduced manual coding since automation tools,
code generators and code reuse are involved. This
also means less defects possible
 Increased user involvement because they are
represented on the team at all times.

74. RAD Disadvantages
 Requires sufficient human resources to create the right
number of RAD teams, for large but scalable projects.
 Requires committed developers and customers to get a
system complete in a short time frame otherwise RAD
fails.
 If a system cannot be properly modularized, building
components for RAD will be problematic.
 It is not appropriate when technical risks are high, e.g.
when a new application makes heavy use of new
technology or when the new software requires a high
degree of interoperability with existing computer
programs

75. V-Model

76. V-Model
 It is an extension of the waterfall model. Instead of
moving down in a linear way, the process steps are
bent upwards after the coding phase
(implementation), to form the typical V shape.
 It emphasizes the verification and validation of the
product - demonstrating the relationships between
each phase of the development life cycle and its
associated phase of testing. Thus testing of the
product is planned in parallel with a corresponding
phase of development.

77. V-Model

78. Advantages of the V-Model
 It is simple and easy to use.
 Each phase has specific deliverables.
 Higher chance of success over the waterfall model
due to the development of test plans early on during
the life cycle.
 Works well for small projects where requirements
are easily understood.

79. Disadvantages of the V-Model
 Very rigid, like the waterfall model.
 Adjusting scope is difficult and expensive.
 Software is developed during the implementation
phase, so no early prototypes of the software are
produced
 This model doesn’t provide a clear path for
problems found during testing phases.
 It does not easily handle concurrent events.
 It does not contain risk analysis activities.

80. Spiral Model

81. Spiral Model
 The diagrammatic representation of this model
appears like a spiral with many loops where the
exact number of loops in the spiral is not fixed.
Each loop of the spiral represents a phase of the
software process.
 For example, the innermost loop might be
concerned with feasibility study. The next loop with
requirements specification, the next one with
design, and so on.

82. Spiral Model
 The spiral model combines change avoidance with
change tolerance. It assumes that changes are a
result of project risks and includes risk
management activities to reduce these risks.
 Each phase in this model is split into four sectors
(or quadrants).

83. Spiral Model

84. Spiral Model
The following activities are carried out during each phase of
a spiral model.
First quadrant (Objective Setting)
 Specific objectives for the phase are defined, constraints
on the process and product are identified and a
management plan drawn up. Project risks are identified
and alternative strategies planned
Second Quadrant (Risk Assessment and Reduction)
 A detailed analysis is carried out for each identified
project risk and steps are taken to reduce the risks.
 For example, if there is a risk that the requirements are
inappropriate, a prototype system may be developed.

85. Spiral Model
Third Quadrant (Development and Validation)
After risk evaluation, a development model is chosen.
E.g. If user interface risks are dominant, an
appropriate development model might be evolutionary
prototyping, if the main identified risk is sub-system
integration, the most appropriate model would be
waterfall model.
Fourth Quadrant (Review and Planning)
Review the results achieved so far with the customer
and plan the next iteration around the spiral.

86. Advantages of the Spiral Model
• Delivers initial value early thus;
o Mitigating the risk of failure
o Allowing focus on high-priority functionality
• Frequent requirements refinement enables use of
feedback from one iteration to refine requirements
for the next.
• Mitigates impact of change.

87. Disadvantages of the Spiral Model
• Requires considerable risk-assessment expertise in
order to work well.
• It has not been employed as much proven models
(e.g. the Waterfall Model) and hence may prove
difficult to ‘sell’ to the client.

88. Circumstances to use spiral model
 It is called a meta model since it encompasses all
other life cycle models. Risk handling is inherently
built into this model.
 It is suitable for development of technically
challenging software products that are prone to
several kinds of risks.
 It is however much more complex than the other
models; this is why it is not often used in ordinary
projects.

89. Agile Development Model

90. Agile Development Model
 Agile SDLC model is a combination of iterative and
incremental process models with focus on process
adaptability and customer satisfaction by rapid
delivery of a working software product.
 Software is developed in incremental, rapid cycles.
This results in small incremental releases (builds)
with each release building on previous functionality.
 Each iteration typically lasts from about one to
three weeks.
 Each release is thoroughly tested to ensure
software quality is maintained.

91. Agile Development Model
 It reduces risk by breaking projects into small, time-
limited modules ("iterations"), each of which is
approached like a small, self-contained mini-
project, lasting only a few weeks. At the end of
each iteration, the project's priorities, direction and
progress are re-evaluated.
 Agile methods emphasize real-time communication,
preferably face-to-face, over written documents and
thus produce very little documentation compared to
other methods. They also emphasize working
software as the primary measure of progress

92. Agile Development Model
 Every iteration involves cross functional teams
working simultaneously on various areas like:
o Planning
o Requirements Analysis
o Design
o Coding
o Unit Testing and
o Acceptance Testing.
 Agile is mostly applicable to projects involving:
o Unpredictable or dynamic requirements
o Responsible and motivated developers
o Customers who understand the process and will
get involved.

93. Agile Development Model


94. Advantages of Agile model
 Customer satisfaction by rapid, continuous
delivery of useful software.
 People and interactions are emphasized rather
than process and tools. Customers, developers
and testers constantly interact with each other; i.e.
it promotes teamwork and cross training.
 Working software is delivered frequently (weeks
rather than months).
 Enables concurrent development and delivery
within an overall planned context.

95. Advantages of Agile model
 Little or no planning required.
 Easy to manage.
 Gives flexibility to developers
 Face-to-face conversation is the best form of
communication.
 Close, daily cooperation between business people
and developers.
 Continuous attention to technical excellence and
good design.

96. Advantages of Agile model
 Minimal rules, documentation easily employed.
 Resource requirements are minimum.
 Regular adaptation to changing circumstances
(Suitable for fixed or changing requirements)
 Even late changes in requirements are welcomed

97. Disadvantages of Agile model
 Not suitable for handling complex dependencies.
 More risk of sustainability, maintainability and
extensibility
 In case of some software deliverables, especially
the large ones, it is difficult to assess the effort
required at the beginning of the software
development life cycle.
 There is lack of emphasis on necessary designing
and documentation.

98. Disadvantages of Agile model
 There is a very high individual dependency, since
there is minimum documentation generated
 Transfer of technology to new team members may
be quite challenging due to lack of documentation
 The project can easily get taken off track if the
customer representative is not clear of the final
wanted.
 An overall plan, an agile leader and agile PM
practice is a must without which it will not work

99. Disadvantages of Agile model
 Strict delivery management dictates the scope,
functionality to be delivered, and adjustments to
meet the deadlines.
 Only senior programmers are capable of taking the
kind of decisions required during the development
process. Hence it has no place for new
programmers.

100. When to use Agile Model
 When new changes are needed to be
implemented. New changes can be implemented at
very little cost because of the frequency of new
increments that are produced.
 To implement a new feature the developers need to
lose only the work of a few days, or even only
hours, to roll back and implement it.
 Unlike the Waterfall Model, very limited planning is
required in the Agile Model to get started with the
project

101. When to use Agile Model
 Agile assumes that the end users’ needs are ever
changing in a dynamic business and IT world.
 Changes can be discussed and features can be
newly effected or removed based on feedback.
This effectively gives the customer the finished
system they want or need.
 Both system developers and stakeholders get
more freedom of time and options than if the
software was developed in a more rigid sequential
way.

102. When to use Agile Model
 Having options gives them the ability to leave
important decisions until more or better data or
even entire hosting programs are available; i.e. the
project can continue to move forward without fear
of reaching a sudden standstill.

103. Agile Vs Traditional SDLC Models
 Agile is based on the adaptive software
development methods, whereas the traditional
SDLC models like the waterfall model are based on
a predictive approach.
 Predictive teams in the traditional SDLC models
usually work with detailed planning and have a
complete forecast of the exact tasks and features
to be delivered in the next few months or during the
product life cycle.

104. Agile Vs Traditional SDLC Models
 Predictive methods entirely depend on the
requirement analysis and planning done in the
beginning of the cycle. Any changes to be
incorporated go through a strict change control
management and prioritization.
 Agile uses an adaptive approach where there is
no detailed planning and there is clarity on future
tasks only in respect of what features need to be
developed.

105. Agile Vs Traditional SDLC Models
 There is feature driven development and the team
adapts to the changing product requirements
dynamically. The product is tested very frequently,
through the release iterations, minimizing the risk
of any major failures in future.
 Customer Interaction and open communication
and minimum documentation are the backbone of
the Agile methodology. The agile teams work in
close collaboration with each other and are most
often located in the same geographical location.

106. Agile Development Model
 The most popular Agile methods include:
o Rational Unified Process (1994)
o Scrum (1995)
o Crystal Clear
o Extreme Programming (1996)
o Adaptive Software Development
o Feature Driven Development
o Dynamic Systems Development Method
(DSDM) (1995).
 These methods are now collectively referred to as
Agile Methodologies, after the Agile Manifesto
was published in 2001.

107. Agile Manifesto Principles
Individuals and interactions
In Agile development, self-organization, motivation,
interactions like co-location and pair programming are
important.
Working software
Demo working software is considered the best means
of communication with the customers to understand
their requirements.
Customer collaboration
Continuous customer interaction is very important to
get proper product requirements.

108. Agile Manifesto Principles
Responding to change
Agile Development is focused on quick responses to
change and continuous development.

109. Comparison of different life-cycle models
 The classical waterfall model is the basic model
and all other life cycle models are modifications of
this model.
 However, the classical waterfall model can not be
used in practical development projects, since it
does not support mechanisms to handle the
errors committed during any of the phases.
 This problem is overcome in the iterative waterfall
model since it is simple to understand and use.

110. Comparison of different life-cycle models
 The iterative model is however suitable only for
well-understood problems; it is not suitable for very
large projects and for projects that are subject to
many risks.
 The prototyping model is suitable for projects
where the user requirements or the underlying
technical aspects are not well understood.
 It is most popular for development of the user-
interface part of the projects.

111. Comparison of different life-cycle models
 The spiral model, also called a meta model
encompasses all other life cycle models. Risk
handling is inherently built into this model.
 It is suitable for development of technically
challenging software products that are prone to
several kinds of risks.
 It is however much more complex than the other
models.

112. Comparison of different life-cycle models
 The different software life cycle models can be
compared from the viewpoint of the customer.
 Initially, customer confidence in the development
team is usually high irrespective of the development
model followed but during the lengthy development
process, customer confidence normally drops off, as
no working product is immediately visible.
 An evolutionary approach lets the customer
experiment with a working product much earlier than
the monolithic approaches.

113. Comparison of different life-cycle models
 The incremental model also reduces the customer’s
trauma of getting used to an entirely new system.
 The gradual introduction of the product via
incremental phases provides time to the customer to
adjust to the new product.
 Also, from the customer’s financial viewpoint,
incremental development does not require a large
upfront capital outlay. The customer can order the
incremental versions as and when he can afford
them.

114. Common Features of All Models of Software Development
 Many organizations have their own written variants of
these software development models and they may
have their own set of procedures to be followed during
software development .
 The various life cycle models are, at best, stylized
descriptions of a process.
 Most of the activities in each of these life cycle models
are similar. The primary differences are in the timing of
activities and the expectation that some portions of the
initial prototypes will be discarded if iterative
approaches, such as the rapid prototyping or spiral
development models, are used.

115. Rational Unified Process
(RUP)

116. Rational Unified Process (RUP)
 The Rational Unified Process (RUP) is an example of
a modern process model. It embeds object-oriented
techniques and uses UML (The Unified Modeling
Language) as its principle notation.
 RUP recognizes that the traditional waterfall approach
can be inefficient because it idles key team members for
extended periods of time and it also introduces a lot of
risk since it defers testing and integration until the end of
the project lifecycle.
 RUP is highly flexible, any stage can be updated at any
time. It uses an iterative, incremental approach for object
-oriented development.

117. Rational Unified Process (RUP)
Different perspectives into a RUP based
process:
o A dynamic perspective.
o A static perspective.
o A practice perspective.

118. Rational Unified Process (RUP)
Dynamic perspective
It is four phased:
 Inception
This phase centres on assessing needs,
requirements, viability and feasibility of the program
or project as the developers define the scope of the
project and its business case.
 Elaboration
The developers analyse the project's needs in
greater detail and define its architectural foundation.
They measure the architecture of the system's
appropriateness based on the project needs.

119. Rational Unified Process (RUP)
 Construction
In this phase, the actual software system is made by
developing components and features. It also includes
the first release of the developed software.
 Transition
This stage marks the end of the development cycle, if
all objectives are met. It includes training of the end
users, beta testing and the final implementation of the
system.
Each phase is organised into a number of separate
iterations which must satisfy certain criteria. At the end of
each iteration, RUP provides a prototype.

120. Rational Unified Process (RUP)


121. Rational Unified Process (RUP)
A static perspective
 This perspective shows the process activities
(workflows) that are enacted within the phases.
 Sample core workflows include:
o Business modelling – Requirements capture
o Requirements – Use case model
o Analysis – Analysis model (i.e. conceptual object
model)
o Design – Design model (e.g. classes, use case
realizations)
o Implementation – Implementation model
(components)
o Test – Test model (test cases)

122. Rational Unified Process (RUP)
A Practice perspective
This suggests good practices to be used during the
process:
o Develop software iteratively
o Manage requirements
o Use component-based architectures
o Visually model software
o Verify software quality
o Control changes to software

123. Benefits of the RUP iterative approach
 Risks are mitigated earlier
 Change is more manageable
 Higher level of reuse
 The project team can learn along the way
 Better overall quality