In this advanced business analysis training session, you will learn SDLC methodologies. Topics covered in this session are: • Agile methodology • Scrum methodology • Rational Unified Process • Rapid Prototyping For more information, click here: https://www.mindsmapped.com/courses/business-analysis/advanced-business-analyst-training/

1. Page 0Classification: Restricted
Advanced Business Analysis Training
SDLC Methodologies and Models

2. Page 1Classification: Restricted
Agenda
•Agile methodology
•Scrum methodology
•Rational Unified Process
•Rapid Prototyping

3. Page 2Classification: Restricted
SDLC (Software Development Life Cycle) & Models
The software development life cycle (SDLC) is a framework
defining tasks performed at each step in the software
development process.
SDLC is a structure followed by a
development team within the
software organization.
It consists of a detailed plan
describing how to develop,
maintain and replace specific
software.
SDLC consists of the following
activities:

4. Page 3Classification: Restricted
Software Life Cycle Models
A software lifecycle model is a standardised
format for
•planning
•organising, and
•running
a new development project.

5. Page 4Classification: Restricted
SDLC Continued…
Hundreds of different kinds of models are known and used.
Many are minor variations on just a small number of basic
models.

6. Page 5Classification: Restricted
Planning with Models
SE projects usually live with a fixed financial budget. (An
exception is maintenance?)
Additionally, time-to-market places a strong time constraint.
There will be other project constraints such as staff

7. Page 6Classification: Restricted
Project constraints
money
time
Computing
resources
staff
programmers managers
designers
Examples of Project Constraints

8. Page 7Classification: Restricted
Project planning is the art of scheduling the
necessary activities, in time, space and across
staff in order to optimise:
•project risk [low] (see later)
•profit [high]
•customer satisfaction [high]
•worker satisfaction [high]
•long-term company goals

9. Page 8Classification: Restricted
Questions:
1. What are these necessary activities?
(besides programming)
2. Are there good patterns of organisation
that we could copy?

10. Page 9Classification: Restricted
A project plan contains much information,
but must at least describe:
•resources needed
(people, money, equipment, etc)
•dependency & timing of work
(flow graph, work packages)
•rate of delivery (reports, code, etc)
It is impossible to measure rate of progress
except with reference to a plan.

11. Page 10Classification: Restricted
In addition to project members, the following
may need access to parts of the project plan:
•Management,
•Customers
•Subcontractors
•Suppliers
•Investors
•Banks

12. Page 11Classification: Restricted
Project Visibility
Unlike other engineers
(e.g. civil, electronic, chemical … etc.)
software engineers do not produce anything
physical.
It is inherently difficult to monitor an SE
project due to lack of visibility.

13. Page 12Classification: Restricted
This means that SE projects must produce
additional deliverables (artifacts)
which are visible, such as:
•Design documents/ prototypes
•Reports
•Project/status meetings
•Client surveys (e.g. satisfaction level)

14. Page 13Classification: Restricted
What is a Lifecycle Model?
Definition.
A (software/system) lifecycle model is a
description of the sequence of activities
carried out in an SE project, and the relative
order of these activities.

15. Page 14Classification: Restricted
It provides a fixed generic framework that
can be tailored to a specific project.
Project specific parameters will include:
•Size, (person-years)
•Budget,
•Duration.
project plan =
lifecycle model + project parameters

16. Page 15Classification: Restricted
There are hundreds of different lifecycle models
to choose from, e.g:
•waterfall,
•code-and-fix
•spiral
•rapid prototyping
•unified process (UP)
•agile methods, extreme programming (XP)
•COTS …
but many are minor variations on a smaller
number of basic models.

17. Page 16Classification: Restricted
By changing the lifecycle model, we can
improve and/or tradeoff:
•Development speed (time to market)
•Product quality
•Project visibility
•Administrative overhead
•Risk exposure
•Customer relations, etc, etc.

18. Page 17Classification: Restricted
Normally, a lifecycle model covers the entire
lifetime of a product.
From birth of a commercial idea
to final de-installation of last release
i.e. The three main phases:
• design,
• build,
• maintain.

19. Page 18Classification: Restricted
Note that we can sometimes combine
lifecycle models,
e.g. waterfall inside evolutionary – onboard shuttle software
We can also change lifecycle model between
releases as a product matures,
e.g. rapid prototyping  waterfall

20. Page 19Classification: Restricted
The topics which we be discussing further are:-
- Waterfall Model
- Rational Unified Process (RUP)
- RAD Methodology
- AGILE SCRUM Methodology
- Prototype Model
- Comparison between Waterfall and Agile Model
- Role of BA in Agile Scrum

21. Page 20Classification: Restricted
The waterfall model
• The waterfall model is the classic lifecycle
model – it is widely known, understood
and (commonly?) used.
• In some respect, waterfall is the ”common
sense” approach.
• Introduced by Royce 1970.

22. Page 21Classification: Restricted
User Requirements
Software Requirements
Architecture Design
Detailed design & Coding
Testing
Delivery
The Waterfall
Lifecycle Workflow
Time
User Requirements Document
Software Requirements
Document
Architectural Design
Document
Detailed
Design
& Code
phase
output
”Swimming
upstream”

23. Page 22Classification: Restricted
Advantages
1. Easy to understand and implement.
2. Widely used and known (in theory!)
3. Reinforces good habits: define-before- design, design-
before-code
4. Identifies deliverables and milestones
5. Document driven, URD, SRD, … etc. Published
documentation standards, e.g. PSS-05.
6. Works well on mature products and weak teams.

24. Page 23Classification: Restricted
Disadvantages
1. Idealised, doesn’t match reality well.
2. Doesn’t reflect iterative nature of exploratory
development.
3. Unrealistic to expect accurate requirements so early in
project
4. Software is delivered late in project, delays discovery of
serious errors.
5. Difficult to integrate risk management
6. Difficult and expensive to make changes to documents,
”swimming upstream”.
7. Significant administrative overhead, costly for small
teams and projects.

25. 24

26. www.mindsmapped.com
Agile Approach

27. www.mindsmapped.com
What is ‘Agile’?
 Processes and techniques for incremental and iterative
software development
 Agile Manifesto
 – “We are uncovering better ways of developing
software by doing it and helping others do it. Through this
work we have come to value”:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
Valuable
More
Valuable

28. www.mindsmapped.com
What does the Agile Manifesto Mean?

29. www.mindsmapped.com
12 Principles of Agile (1)

30. www.mindsmapped.com
12 Principles of Agile (2)

31. www.mindsmapped.com
Central: Incremental and Iterative Development

32. www.mindsmapped.com
Agile Methods

33. www.mindsmapped.com
Scrum Lifecycle
 Planning
–Vision, expectations, funding
 Staging
– Identify requirements, prioritize iteration
 Development
– Implement system ready for release in each sprint
 Release
–Operational deployment

34. 33
Scrum Framework

35. SCRUM team
34

36. 35

37. 36

38. 37

39. 38

40. 39

41. 40

42. 41

43. 42

44. www.mindsmapped.com
AGILE METHODS – SCRUM (1)

45. 1.SPRINT PLANNING
(DISCUSS TOP PBI SCOPE>ESTIMATE)
2. DAILY STAND UP MEETING
(<15 MINUTES, WHAT I DID TILL THIS MEETING, WHAT ILL DO TILL NEXT
MEETING , WHAT'S BLOCKING ME)
3. SPRINT REVIEW (LAST DAY)
(TO DEMONSTRATE WHAT IS READY TO SHIP TO PO, NO PPT, DEMO
ON PRODN ENV
4. SPRINT RETROSPECTIVE –
WHAT WENT RIGHT, WHAT WENT WRONG
SCRUM CEREMONIES
44

46. www.mindsmapped.com
AGILE METHODS – SCRUM (2)

47. PBIS ARE UNIQUELY RANKED ITEMS, PROGRESSIVE
USER STORIES ARE SHORT PLAIN LANGUAGE OF DESCRIPTION OF
FUNCTIONALITY IN TERMS OF CUSTOMER BENEFIT/NEED
Product backlog
46
Stories (=requirement) priority estimate
As a user I want to be able to easily install the
application so that I can access my bank account on
my mobile
1 5
As a user I want to be able to view my bank transaction
history so that I can track my transactions
2 3

48. www.mindsmapped.com

49. www.mindsmapped.com
Scrum Values
Commitment
– Team takes responsibility to complete the Sprint. To avoid
things that will stand in its way
Focus
– Team’s focus is maintained. Distractions, interruptions are
fielded
Openness
– Overall and individual status and commitments kept open.
Respect
– Team responsibility rather than scapegoat.
Courage
– Management and team have the courage to take
responsibility to do what is necessary

50. Agile & Waterfall Methodologies – A
Side by Side comparison
Waterfall Model
• Much like construction and manufacturing workflows,
waterfall methodology is a sequential design process. This
means that as each of the eight stages (conception,
initiation, analysis, design, construction, testing,
implementation, and maintenance) are completed, the
developers move on to the next step.
• As this process is sequential, once a step has been
completed, developers can’t go back to a previous step –
not without scratching the whole project and starting from
the beginning. There’s no room for change or error, so a
project outcome and an extensive plan must be set in the
beginning and then followed carefully.

51. Advantages of Waterfall
• The waterfall methodology stresses meticulous record
keeping. Having such records allows for the ability to
improve upon the existing program in the future.
• With the waterfall methodology, the client knows what
to expect. They’ll have an idea of the size, cost, and
timeline for the project. They’ll have a definite idea of
what their program will do in the end.
• In the case of employee turnover, waterfall’s strong
documentation allows for minimal project impact.
50

52. Disadvantage of Waterfall
• Once a step has been completed, developers can’t go back to a
previous stage and make changes.
• Waterfall methodology relies heavily on initial requirements.
However, if these requirements are faulty in any manner, the
project is doomed.
• If a requirement error is found, or a change needs to be made, the
project has to start from the beginning with all new code.
• The whole product is only tested at the end. If bugs are written
early, but discovered late, their existence may have affected how
other code was written.
• Additionally, the temptation to delay thorough testing is often very
high, as these delays allow short-term wins of staying on-schedule.
• The plan doesn’t take into account a client’s evolving needs. If the
client realizes that they need more than they initially thought, and
demand change, the project will come in late and impact budget.
51

53. When should you use waterfall
methodology
• When there is a clear picture of what the final
product should be.
• When clients won’t have the ability to change
the scope of the project once it has begun.
• When definition, not speed, is key to success.
52

54. What is Agile?
• Agile came about as a “solution” to the disadvantages of
the waterfall methodology. Instead of a sequential design
process, the Agile methodology follows an incremental
approach.
• Developers start off with a simplistic project design, and
then begin to work on small modules. The work on these
modules is done in weekly or monthly sprints, and at the
end of each sprint, project priorities are evaluated and tests
are run. These sprints allow for bugs to be discovered, and
customer feedback to be incorporated into the design
before the next sprint is run.
• The process, with its lack of initial design and steps, is often
criticized for its collaborative nature that focuses on
principles rather than process.
53

55. Advantage of Agile
• The Agile methodology allows for changes to be made after the
initial planning. Re-writes to the the program, as the client decides
to make changes, are expected.
• Because the Agile methodology allows you to make changes, it’s
easier to add features that will keep you up to date with the latest
developments in your industry.
• At the end of each sprint, project priorities are evaluated. This
allows clients to add their feedback so that they ultimately get the
product they desire.
• The testing at the end of each sprint ensures that the bugs are
caught and taken care of in the development cycle. They won’t be
found at the end.
• Because the products are tested so thoroughly with Agile, the
product could be launched at the end of any cycle. As a result, it’s
more likely to reach its launch date.
54

56. Disadvantage of Agile
• With a less successful project manager, the
project can become a series of code sprints. If
this happens, the project is likely to come in
late and over budget.
• As the initial project doesn’t have a definitive
plan, the final product can be grossly different
than what was initially intended.
55

57. When Should you use Agile?
• When rapid production is more important than
the quality of the product.
• When clients will be able to change the scope of
the project.
• When there isn’t a clear picture of what the final
product should look like.
• When you have skilled developers who are
adaptable and able to think independently.
• When the product is intended for an industry
with rapidly changing standards.
56

58. Conclusion
Both the Agile and waterfall methodologies have
their strengths and weaknesses. The key to deciding
which is right for you comes down to the context of
the project. Is it going to be changing rapidly? If so,
choose Agile. Do you know exactly what you need?
Good. Then maybe waterfall is the better option. Or
better yet? Consider taking aspects of both
methodologies and combining them in order to
make the best possible software development
process for your project.
57

60. Preface
Good Start - Unified Process (UP) is a de facto standard development process
within the object-oriented and component-based software communities
Product – Rational Unified Process
More Needed - Enterprise Unified Process (EUP) is a software process that
reflects the full lifecycle of software-based systems.

61. Reasons for UP (Unified Process)
• Software becomes more complex and is
updated fast
• Software developers used methods that are as
old as 25 years ago
• Development process is diverse

62. Precursor of UP (Unified Process)
Set of activities to transform a user’s requirements into a software
Software development
Process (diversity)
User’s
Requirement
Software
System
UP

63. What does UP do?
• Provides guidance to the order of team’s
activities
• Integrates team’s work and individual’s work
• Specifies artificats
• Offers criteria for monitoring and measuring

64. 3 key aspects of UP
• Use case driven
• Architecture centric
• Iterative and Incremental

65. Use Case driven
• Use Case driven means:
– Development process proceeds through a series of workflows that
derive from use cases.
• Terminologies:
– Users: someone or something that interact with system.
– Use Case: interaction between users and system,---what is the
system supposed to do for each user?
– Use Case Model: collection of use cases; description of complete
functionality
• Initiate and Bind
– Tools for specifying requirements
– Driving design
– Source for testing

66. Architecture - Centric
• Architecture is the view of the whole design with key Characteristics and
without too many details
– Only 5-10% use cases
– Growth with use case in parallel (structure and function)
• Simplified Process
– Rough outline (Use case independent)
– Subset of the identified use cases (5-10%)
• Use case & Architecture
Use case
System architecture
drive influence

67. Iterative and Incremental??
• Iteration: Steps in the workflow (mini-project)
– Create a design for relevant use cases
– Implement with components
– Required iteration in logical order for economy
• Increments: Growth in the product (might not be additive)
• Benefits to controlled iteration
– Reduce the cost risk to the expenditures on a single increment
– Reduce the risk of delayed product delivery (find the risks
earlier)
– Speed up the tempo of the whole development effort
– Easier to adapt to the requirement modification

68. Relationship of 3 concepts
Goals
drive
guide
USE CASE
ITERATION
ARCHITECTURE
drive
influence
define

69. Lifecycle of UP
• Each cycle concludes with a product release to customers.
• Each cycle consists of 4 phases:
– Inception
– Elaboration
– Construction
– Transition

70. End of the Cycle
• At the end, a software product is releasable
• Finished product includes
• requirements
• use cases
• nonfunctional requirements
• test cases
• artifacts modeled by the UML

71. For New Cycle
• For every new cycle, we need
– Use-case model
– Analysis model
– Design model
– Implementation Model
– Deployment model
– Test model
– Representation of the architecture

72. Phase 1 - Inception
-Establish goals
-Build business case
-Identify essential system requirement
-Initiate risk management(cost, time, political environment )
• Develop a good idea into a vision of the
end product
• Business case for the product is presented

73. Phase 2 – Elaboration
Here, architecture is expressed as a view of different models
- Develop architecture
- Capture functional requirements as use cases
- Identify non-functional requirements
- Plan the construction
- Continue risk management

74. Phase 3 - Construction
Muscle built : software added to the architecture
- Build the System
- Maintain architectural integrity
(Architecture is stable but might has minor changes)
- Iterative, Incremental
-However, is it sufficient to take early delivery?

75. Phase 4 - Transition
Products move to beta release.
Trial
Defects and deficiencies are reported.
Corrections and improvements
- Final testing( system, acceptance, beta )
- Training customer personnel
- Documentation, installation and consultation
- Perform postmortem review

76. RUP and UP
UP is more of a philosophy of how to
run development projects
RUP is Rational commercial product

77. RUP View

78. Build web solutions with RUP

79. RUP Strengths and weakness
• Strength of RUP:
– Based on sound SE principles
– Mechanisms that provide management visibility into the
development process
– HTML based description of the RUP
• Weaknesses of RUP:
– Only developing process, not the entire software process
– Not supporting multi-system infrastructure development
efforts
– Iterative nature seems alien to experienced developers
– Tool-driven approach, not sufficient for complex system

80. Extended RUP to EUP
• Add processes for operation, support and maintenance
• Add support for the management of a portfolio of projects

81. Augmented lifecycle for the EUP

82. Additional Phases
• Phase 5 – Production
– Replaced with a new version
– Retired and removed from the production (Note: No Iteration)
• Phase 6 – Retirement
– Remove system from production because
• No longer needed
• Being Replaced
– Activities
• Comprehensive Analysis
• Redesign and rework of other existing systems
• Transformation of existing legacy data
• Archival of data
• Configuration management of the removed software
• System integration testing of the remaining system

83. Conclusion
6 best practices
• Iterative software development
• Manage Requirements
• Component-based architecture
• Visually model software
• Quality Control
• Configuration Management

85. Rapid Prototyping
Key idea: Customers are non-technical and
usually don’t know what they want/can have.
Rapid prototyping emphasises requirements
analysis and validation, also called:
• customer oriented development,
• evolutionary prototyping

86. Requirements Capture
Quick Design
Build Prototype
Customer Evaluation of
Prototype
Engineer Final
Product
The Rapid
Prototype Workflow
Iterate

87. Advantages
1. Reduces risk of incorrect user
requirements
2. Good where requirements are
changing/uncommitted
3. Regular visible progress aids management
4. Supports early product marketing

88. Disadvantages
1. An unstable/badly implemented prototype
often becomes the final product.
2. Requires extensive customer collaboration
– Costs customers money
– Needs committed customers
– Difficult to finish if customer withdraws
– May be too customer specific, no broad market
3. Difficult to know how long project will last
4. Easy to fall back into code-and-fix without
proper requirements analysis, design,
customer evaluation and feedback.

89. BA Tasks : Waterfall
88
Technique Methodology BA Role
Analogous Waterfall BA starts from scratch on a very high level.
Parametric Waterfall BA draws from similar projects and
parameters of similar size, scale and
functionality. [Can also be done in Agile]
Bottom-up Waterfall BA defines the estimate by specific
requirement details.
Three Point Waterfall BA draws from Use Cases/Scenarios in Easy,
Medium, and Complex states.

90. BA Tasks : Agile
89
Technique Methodology BA Role
Rolling Wave Agile BA uses one iteration estimate to form the
next one.
Historic Agile BA draws a strong analogy to projects and
tasks of similar size, scale and functionality.
Expert Agile BA draws from the expertise of the
developers and their past experiences.
Delphi Agile BA draws from history and expertise.

91. Page 90Classification: Restricted
THANK YOU!