Session 9

ITPM
11.10.2022
 Waterfall Model

Analysis/Requirements

Design

Construction

Implementation
Testing/Support
The image below shows how these activities align with the project schedule in
traditional software development
Waterfall Model of software dev
Wikipedia
Figure 13.9: The Traditional Systems Development Life
Cycle

"Copyright © 2018 Pearson India Education Services Pvt. Ltd".

Management Information System: Managing the Digital Firm
By: Kenneth C. Laudon & Jane P. Laudon
Compare with New Product Development
Life Cycle
 Waterfall Method
Advantages Disadvantages
Detailed: Meticulous planning undertaken from the Rigid: With a strict blueprint, departure from the
beginning results in detailed project plans. original plan is difficult. 
Expectations: The project scope, cost, Testing: Testing is done at the end of the Waterfall
and timeline are clearly outlined, so clients know
project, and the final QA phase takes significant time.
exactly what will be delivered.
Onboarding: With a clear outline, even if a team
No evolution: Change in requirements are difficult to
experiences turnover, a new member can step in and accommodate
contribute without derailing the timeline.
 When to use Waterfall Approach
• The Waterfall Approach is used in many large scale systems projects:
• When requirements are clear or can be ascertained in the beginning
of project
• When constraints (time, scope and cost) are inflexible
• Where complexity and cost are so high (When Risk is large)
• Where more rigid steps of the approach help to ensure careful
completion of all deliverables
• When teams are dispersed
Phases of Software Development
Phases of Project Life Cycle with Process
Groups
PMI.ORG
Other Predictive Models
Incremental, Iterative, Spiral and RAD models
 Incremental build life cycle model
• Incremental Model is a process of software development where
requirements divided into multiple standalone modules of the
software development cycle.
• In this model, each module goes through the requirements, design,
implementation and testing phases.
• Every subsequent release of the module adds function to the previous
release. The process continues until the complete system achieved.
 Incremental Approach

Note
requirements for
each build can be
taken separately
 Incremental Approach
(Another version)

After each
increment
the software
is deployed
Analysis refers
to
requirements
 Incremental build life cycle model

• Provides for progressive development of operational software with

each release providing added capabilities
• Used by Microsoft which issues specific release of a software package
while working on future revisions.
• This approach helps in staging the users priorities of package’s
features and functions with user’s priorities or the costs, time and
scope of the system
 Incremental build life cycle model
When we use the Incremental Model?
• When the requirements are large.
• A project has a lengthy development schedule.
• When Software team are not very well skilled or trained.
• When the customer demands a quick release of the product.
• You can develop prioritized requirements first.
Advantage of Incremental Model
• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.
Incremental build life cycle model
Disadvantage of Incremental Model
• Need for good planning
• Total Cost is high.
• Well defined module interfaces are needed.
Iterative (including
Prototyping)
Framework/Model
 Iterative Model
https://www.javatpoint.com/software-engineering-iterative-model

Note requirements are taken

Limited once at the beginning
features of all
modules are Final Iteration
developed
together in
iteration 1 and
then refined in
subsequent
iterations

Note: Unlike the incremental model there is no deployment in

iteration 1 and 2 only review
https://www.javatpoint.com/software-engineering-iterative-model

• In this Model, the development is started with the software requirement

specifications to develop the first version of the software. This may contain limited
versions of all modules together (unlike incremental). However there is no
deployment.
• After the first version if there is a need to change the software (based on review),
then a new version of the software is created with a new iteration (again no
deployment).
• Every release of the Iterative Model finishes in an exact and fixed period that is
called iteration.
• The Iterative Model allows the accessing earlier phases.
• The final output of the project is reviewed at the end of the Software Development
Life Cycle (SDLC) process and if found ok is deployed.
Prototyping
 Prototyping Model (a type of iterative)
• In this process model, the system is partially implemented before or during
the requirements phase thereby giving the customers an opportunity to see
the product early in the life cycle.
• The process starts by interviewing the customers and developing the
incomplete high-level paper model. This document is used to build the initial
prototype supporting only the basic functionality as desired by the
customer.
• Once the customer figures out the problems, the prototype is further
refined to eliminate them. The process continues until the user approves the
prototype and finds the working model to be satisfactory. 
• The design, construction, test and implement stages follow subsequently
Prototyping is done in the Requirements
Phase
 Prototyping Life Cycle
• It requires heavy user involvement and developers use a model to
generate functional requirements and physical design specifications
simultaneously
• This is used in systems that involve a great deal of user interface
design such as (a) website projects (b) in systems that automate
previously manual functions (c) or in systems that change the nature
of how something is done such as mobile applications
 Advantages of Prototyping

• Increased user involvement in the product even before its

implementation.
• Since a working model of the system is displayed, the users get a
better understanding of the system being developed.
• Reduces time and cost as the defects can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily.
• Confusing or difficult functions can be identified.
 Disadvantages of Prototyping

• Risk of insufficient requirement analysis owing to too much dependency

on the prototype.
• Users may get confused in the prototypes and actual systems.
• Practically, this methodology may increase the complexity of the system as
scope of the system may expand beyond original plans.
• Developers may try to reuse the existing prototypes to build the actual
system, even when it is not technically feasible.
• The effort invested in building prototypes may be too much if it is not
monitored properly
Hybrid Models
Spiral Model
 1. Spiral Model
• The spiral model, initially proposed by Boehm, is an evolutionary
software process model that couples the iterative feature of
prototyping with the controlled and systematic aspects of the linear
sequential model.
• Using the spiral model, the software is developed in a series of
incremental releases.
• During the early iterations, the additional release may be a paper
model or prototype.
• During later iterations, more and more complete versions of the
engineered system are produced.
Spiral Software Dev Model
Wikipedia
 Spiral
(combines iterations with prototypes)
• The spiral model has four phases. A software project repeatedly
passes through these phases in iterations called Spirals.
1. Identification (Objectives)
• This phase starts with gathering the business requirements in the baseline
spiral. This phase also includes understanding the system requirements by
continuous communication between the customer and the system analyst.
• In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in
this phase.
 Spiral (Risk Driven)

2. Evaluation and Risk Analysis

• Risk Analysis includes identifying, estimating and monitoring the technical
feasibility and management risks, such as schedule slippage and cost overrun.
3. Development and Test (incudes design, code, integration and test)
• Starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and the
final design in the subsequent spirals.
• In the baseline spiral, when the product is just thought of and the design is
being developed a POC (Proof of Concept) is developed in this phase to get
customer feedback.
 Spiral

Development and Test continued (sometimes also called construct)

• Then in the subsequent spirals with higher clarity on requirements and design
details a working model of the software is produced with a version number.
These models are sent to the customer for feedback.
4. Review
• After testing the build, at the end of first iteration, the customer evaluates the
software and provides feedback. The same is continued for further spirals as
more enhanced prototypes are produced
Spiral Software Dev Model
Wikipedia
Risk Analysis: IBM Websphere, Oracle app server, Enterprise Java Beans can be
Application Servers

Browser
 Spiral Model
When to use Spiral Model?
• When delivery is required to be frequent.
• When the project is large
• When requirements are unclear and complex
• When changes may be required at any time
• Large and high budget projects
Advantages
• High amount of risk analysis
• Useful for large and mission-critical projects.
Disadvantages
• Can be a costly model to use.
• Risk analysis needed highly particular expertise
• Doesn't work well for smaller projects.
 Joint Application
Development (JAD)
Joint Application Development (JAD)
From Wikipedia
• Arnie Lind, then a Senior Systems Engineer at IBM Canada in Regina,
Saskatchewan created and named joint application design, in 1974.
• This was an improvement on existing methods, which entailed application
developers spending months learning the specifics of a particular department or
job function, and then developing an application for the function or department.
• In addition to significant development backlog delays, this process resulted in
applications taking years to develop, and often not being fully accepted by the
application users.
• The JAD process was formalized by Tony Crawford and Chuck Morris of IBM in
the late 1970s. Tony Crawford later developed JAD-Plan and then JAR (joint
application requirements)
 Joint Application Development (JAD)
• JAD (Joint Application Development) is a methodology that involves the
client or end user in the design and development of an application,
through a succession of collaborative workshops called JAD sessions.
• The JAD approach, in comparison with the more traditional practice, is
thought to lead to faster development times and greater client
satisfaction, because the client is involved throughout the development
process.
• In comparison, in the traditional approach to systems development, the
developer investigates the system requirements and develops an
application, with client input consisting of a series of interviews.
Joint Requirement Planning (JRP) a feature of JAD

Joint Requirement Planning (JRP)

• JRP is a subset of a more comprehensive joint application development or JAD technique
exclusively focused on requirements
• Joint Requirements Planning (JRP) is a technique for drawing out user requirements
through joint (planning) sessions of software users and information technology personnel
• A process whereby sessions/workshops are conducted for the purpose of analyzing
problems and defining requirements. Provides an open environment for people to discuss
what they do, how they do it, and what critical information they need to support their job
responsibilities.
• Written documentation defining these requirements results from a JRP session. These
meetings are also sometimes called Joint Application Design (JAD) sessions.
• JRP participants
• Sponsor, Facilitator, Users and Managers, Scribes, IT Staff
Joint Requirements Planning (JRP)

JAD/JRP
How Application is developed jointly in JAD
• Besides requirement gathering, JAD involves the client or end-users in
designing and development process. 
• The involvement of clients is enabled by a series of sessions called JAD
sessions
• Features of JAD Sessions :
• The JAD sessions must have well-defined objectives and agenda items. It is to
be ensured that key persons are present from both technical and business
world and from the one who take notes.
• For driving the meeting, questions and items are the essence of the discussion,
and where we should not except fast answers. Also we should ask questions,
record important items and assign action items.
 JAD (contd..)
• Features of JAD sessions
• The aim of JAD sessions is to trigger creative thinking which leads to joint
discussion that requires expertise from various departments.
• Teams should help each other in making decisions.
• If the teams can’t arrive at a decision then we need to run scheduled JAD
sessions known as JAD workshops.
• We know that most of the JAD sessions are scheduled in developmental
phase, it may happen during the requirement of the project.
 Rapid Application
Development Life Cycle
Model
 RAD Life Cycle (Rapid Application development)

• Developers also work with evolving prototype with a view to rapid

development
• Requires heavy user involvement and helps produce systems quickly without
sacrificing quality (This is the main strength of RAD)
• Developers use RAD tools such as CASE (Computer aided software
engineering), JRP (joint requirement planning) and JAD (joint application
design) to facilitate rapid prototyping and code generation
• Programmers enter parameters in software to generate reports for approval.
When approved the same parameters will generate the production system
without further modification by the programmer
RAD Model
Broad Phases of RAD
 Requirement Planning Phase (RAD)
• Requirements planning phase – combines elements of the system
planning and systems analysis phases of the Systems Development
Life Cycle (SDLC).
• Users, managers, and IT staff members discuss and agree on business
needs, project scope, constraints, and system requirements.
• It ends when the team agrees on the key issues and obtains
management authorization to continue.
 User Design in RAD
• User design phase – during this phase, users interact with systems
analysts and develop models and prototypes that represent all
system processes, inputs, and outputs.
• User Design is a continuous interactive process that allows users to
understand, modify, and eventually approve a working model of the
system that meets their needs.
• The RAD groups or subgroups typically use a combination of Joint
Application Development (JAD) techniques and CASE tools to
translate user needs into working models.
 Construction and Cutover in RAD
• Construction phase – focuses on program and application development
task similar to the SDLC. In RAD, however, users continue to participate
and can still suggest changes or improvements as actual screens or
reports are developed. Its tasks are programming and application
development, coding, unit-integration and system testing.
• Cutover phase – resembles the final tasks in the SDLC implementation
phase, including data conversion, testing, changeover to the new system,
and user training.
Compared with traditional methods, the entire process is compressed. As
a result, the new system is built, delivered, and placed in operation much
sooner.
 RAD Model
The main features of RAD model are that it focuses on the reuse of templates, tools , processes, and code
 Detailed Phases of RAD (in each Prototype)
• RAD process is an adoption of the waterfall model; it targets at
developing software in a short span of time. SDLC RAD model has
following phases:
• Business Modeling
• Data Modeling
• Process Modeling
• Application Generation
• Testing and Cutover
Phases of RAD
 Phases of RAD

• Business Modelling
• A complete business analysis is performed to find the vital information for
business, how it can be obtained, how and when is the information
processed and what are the factors driving successful flow of information.
• Data Modelling
• The information gathered in the Business Modelling phase is reviewed and
analyzed to form sets of data objects vital for the business. The attributes of
all data sets is identified and defined. The relation between these data objects
are established and defined in detail in relevance to the business model.
 Phases of RAD
Process Modelling
• The data object sets defined in the Data Modelling phase are
converted to establish the business information flow needed to
achieve specific business objectives as per the business model. T
• he process model for any changes or enhancements to the data
object sets is defined in this phase. Process descriptions for adding,
deleting, retrieving or modifying a data object are given.
 Phases of RAD
Application Generation
• The actual system is built and coding is done by using automation
tools to convert process and data models into actual prototypes.
Testing and Cutover
• The overall testing time is reduced in the RAD model as the prototypes
are independently tested during every iteration.
• However, the data flow and the interfaces between all the components
need to be thoroughly tested with complete test coverage. Since most
of the programming components have already been tested, it reduces
the risk of any major issues
 CASE Tools can be used in RAD

Types of CASE Tools which may be used in RAD

Analysis and Design Tools
• These tools help in building model of the system
• The model depicts the data and process definitions, the data and process flow
• Control specifications
• The tools can be used for data flow diagrams (DFD), Entity- Relationship
Diagrams, flow charts and control flow (i.e. they provide diagramming
capabilities), data base design
• All these outputs are validated by the user before detailed design an
coding
 Types of Case Tools used in RAD

Interface Design Tools (Visual programming for GUI)

• Used to create menus, buttons, widows, icons, etc.
• These tools provide libraries which help in validating the inputs,
handle error conditions and control the execution process
Programming Tools
• Provide compilers, editors and debuggers
Application generation tools: Use central data base and application
specific process execution rules to create an executable code
 Advantages of RAD
• Changing requirements can be accommodated.
• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.
• Productivity with fewer people in a short time.
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.
 Disadvantages of the RAD Model

• Dependency on technically strong team members for identifying business

requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on Modelling skills.
• Inapplicable to cheaper projects as cost of Modelling and automated code generation
is very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.
 Adaptive Life Cycle
Framework/Model
This is in contrast to the Predictive Approach
(Agile is an implementation of Adaptive Life Cycle Model)
 History of Adaptive Software Development
• The Adaptive Software Development methodology was created in the
early 1990s by two project managers: Sam Bayer and Jim Highsmith—
who would later on be one of the signers of the 2001 Manifesto For
Agile Software Development, or simply the Agile Manifesto.
• ASD was created as a refinement of an earlier methodology, Rapid
Application Development, or RAD. RAD itself appeared in the early
90s, bringing shorter iterations and speed to organizations that were
failing with waterfall-like approaches.
• However, RAD quickly became associated with hacking, due to its lack
of focus on software engineering best practices.
Learn:
Reviews should be Adaptive Software Development
https://www.digite.com/agile/adaptive-software-development-asd/
done after each Speculate: In Adaptive
iteration. Both, the Software Development,
developers and the term plan is replaced
customers examine by the term speculate.
their assumptions While speculating, the
and use the results team does not abandon
of each development planning, but it
cycle to learn the acknowledges the reality
direction of the next. Iterations of uncertainty in complex
The team learns − problems.
About product Speculate encourages
changes Good software exploration and
More fundamental emerges through this experimentation. Iterations
changes in process with short cycles are
underlying encouraged.
assumptions about
how the products
are being developed
Collaborate: Team members should
work together
 Speculation

• The ASD framework rejects the term ‘plan’ for the first phase of its
lifecycle as too deterministic and confident of the final outcome. In its
place is the suitably open-ended ‘speculation’ phase, which leaves
space for the project to innovate.
• The speculation phase of the ASD lifecycle does not reject planning
and big picture planning and the setting of objectives, for the project
and iteration cycle due to start, takes place here. During the first
speculation phase, the project mission is defined, which sets an
approximate framework for the end product.
 Collaboration
• The collaboration phase is founded on the following principles:
• Complex applications are not built, they evolve.
• Complex applications require that a large volume of information be collected,
analyzed, and applied to the problem.
• Collecting, analysing and applying large volumes of information, or data,
requires diverse Knowledge requirements.
• Diverse Knowledge requirements can only be achieved through collaboration
• The collaboration phase is controlled through a balance of traditional
project management techniques and the kind of collaborative
environment that leaves space for emergence.
 Learn
• An Agile software development team working to the ASD framework is
expected to continually improve its level of Knowledge. This is done in the
learning phase that follows each iteration through practices including:
• Technical Reviews
• Project Retrospectives
• User feedback via focus groups and other mechanisms
• Iterations should be short so the team learns from small, not big, mistakes.
The development team and users contributing their user experience to the
process should assess their assumptions during each learning phase.
• The results of this assessment, such as changers to underlying assumptions,
then inform the direction of the next iteration cycle.
 Adaptive Life Cycle Model
• This is in contrast to the predictive model
• Software development follows an adaptive approach because the requirements
cannot be expressed early in the life cycle
• An adaptive approach is used to provide more freedom than predictive approaches
• Development is risk driven and change-tolerant to address and incorporate risks
rather than mitigate them
• It allows development using a free form approach to create components that
provide functionality specified by the business group
• Requirements are developed using iterative approach
• More recently the agile approach has become popular which is an off-shoot of this
model
 Adaptive Life Cycle
• Being risk-driven can be understood as a willingness to fail fast., by placing
higher-risk items in the earlier cycles. If you identify a risk in your project,
you should try to reduce the likelihood of the failure (mitigation). However,
if reducing the probability isn’t possible, ASD says you should accelerate the
happening of the failure. The rationale is simple: if a given decision is
doomed to fail, it’s better and cheaper to find out earlier rather than later.
• Change-tolerant: means that, instead of assuming most activities will
happen as planned, you start with the premise that everything will change,
and often. In ASD, teams create change-tolerant environments so change
can be better managed. One of the ways in which this is accomplished is
through the adoption of shorter time-frames.
 Adaptive
• This approach to Project Management is a combination of both the Iterative
and Incremental models.
• The iterations are very rapid and time bound. In the Adaptive Life Cycle,
Customer Involvement is the key to successful Projects. The customer and
the sponsor form a part of the Delivery Team.
• Sometimes in Adaptive approaches, the phases may not be clearly defined.
It relies heavily on customer feedback and the ability of the team to quickly
work on the feedback and incorporate the same into the Project. 
• Communication and Collaboration are of paramount importance in
implementing Projects using the Adaptive methodologies.
When to Use Agile
Approach
 Advantages of Agile Methodology

• In Agile methodology the delivery of software is regular and continuing

• The customers are satisfied because after every Sprint working feature of the
software is delivered to them.
• Customers can have a look of the working feature which fulfilled their expectations.
• If the customers has any feedback or any change in the feature then it can be
accommodated in the current release of the product.
• In Agile methodology the daily interactions are required between the business
people and the developers.
• In this methodology attention is paid to the good design of the product.
• Changes in the requirements are accepted even in the later stages of the
development.
 Summary of Advantages and Disadvantages
of Agile
Advantages of Agile Disadvantages of Agile

Accommodates changes : Revisits and rewrites of Scheduling: Agile does not give importance to a strict
steps are encouraged to achieve the desired results. schedule. This may create difficulties under a tight
Frequent delivery allows for quick changes in project deadline scenario.
direction while maintaining project scope.

Repeated Testing: Agile projects tasks are tested in Integration : Changing project requirements may

flight, allowing for faster delivery and a better project. cause problems in other areas of the organization. 
Customer satisfaction: Customers who are not sure of Team Criticality : Agile requires a consistent team. A
weak link in the Agile team or management could
their initial requirements are likely to be more
result in wasted time and money.
satisfied Also there are scaling up issues
 Disadvantages of the Agile Methodology

• In Agile methodology the documentation is less.

• Sometimes in Agile methodology the requirement is not very clear hence it’s difficult
to predict the expected result.
• In few of the projects at the starting of the software development life cycle it’s
difficult to estimate the actual effort required.
• The projects following the Agile methodology may have to face some unknown risks
which can affect the development of the project.
• Agile methods do not provide detailed time and cost estimates that management
likes
• Agile methods face a scaling challenge; when teams become very large face to face
interaction becomes problematic. Also when teams are spread between locations,
there are problems of integration of the modules which may be worked upon by
different teams ( a separate integration team with part time members may be
required)
 When to Use Agile Approach
• An Agile approach is suitable for complex projects where the
requirements are absolutely unclear, but it is possible to define
incremental requirements.
• Some of the major challenges in adopting the Agile approach are
required high levels of customer Involvement (which may not always
be possible or practical).
• Also, having a Virtual Team may work against the required enhanced
collaborative approach.
 When to use Agile Approach
• Agile methodologies may appeal to an organization if:
• The requirements of the project are evolving or unclear in the beginning
• The organization easily adapts to change
• The team and is co-located
• The timeline/schedule constraint is flexible
• Risks are not large
• The organization represents an industry that is rapidly changing
• There is an experienced project manager
http://agilemodeling.com/essays/agileDesign.
htm
http://agilemodeling.com/essays/agileDesign.htm
 PLC AND AGILE
High level scope
definition and ball park
cost and time estimates

Concept

Iteration -1 Iteration 0
Process Groups in Agile
(Scrum)
 Process Groups in Agile
Process Agile Activities
Groups
Initiating Survey of user requirements for creating a product backlog by product owner (project level)
Determination of number of sprints and release plan (project level)
High level schedule and cost estimates (project level)
High level architectural envisioning (project level)
Stake holder identification (project level)
Project Charter (as per ITPM Book page 124) (project level)
Kick off meeting (ITPM page 124)

Planning Create product backlog (project level )

Create sprint backlog (sprint level)
Plan work each day (daily scrum)

(Continued on next slide)

Process Group Agile activities
Executing Resolve stumbling blocks
Completing tasks each day during sprints,
Completing a shippable product at the end of each
sprint
Monitoring and Controlling Updating Scrum Board
Updating Burn down chart (for project and sprint)
Closing Sprint Review (sprint level)
Sprint Retrospective (sprint level)
Last sprint Review which closes the project (sprint and
project level)
 Mapping between PLC and Agile
older version 1/2
Predictive Agile (Project Level)
Pre-Initiation Concept (Also called iteration -1)

Develop business use case (Determine scope, time Develop business case
and cost) . Identify project sponsor. appoint project Determine who will act as product owner, scrum
manager master, who will be part of the scrum teams,

Initiation Inception/Iteration 0 (combines the initiation and

planning phase) of Predictive)

project charter Stake holder identification and participation

Identify stake-holders,, kick off meeting, (Project charter and kick off meeting - ITPM Book page
124)
Planning
Prepare scope statement, prepare WBS, prepare Survey of user requirements and Product backlog,
schedule and cost baseline Determination of number of sprints and release plan
High level schedule and cost estimates
High level architectural envisioning
 Comparison between PLC and Agile Phase
Wise older version) 2/2
Predictive Agile (Sprint Wise)
Executing Construction and Release (iterations 1 to N)

Design, construction and testing Sprint wise development of a shippable product; note
some sprint level planning takes place here also
Closing Sprint Review(clients)/Retrospective(with team)
Gaining stakeholder and customer acceptance for final Sprint Retrospective (last Sprint retrospective will
products close the project)
Ensuring all deliverables are completed