The document is a training session on business analysis focusing on the Software Development Life Cycle (SDLC) and various methodologies like Waterfall, Prototyping, and Spiral. It discusses the structure of IT projects, benefits of automated processes, and detailed descriptions of different development approaches, including their advantages and disadvantages. Key concepts include business process modeling and how different methodologies impact project management and execution.

1. Business Analysis
Training for Beginners
Session 02 - SDLC

2. Page 2Classification: Restricted
Agenda
• What is Business Process Modeling
• Benefits of Automated Business Process
• IT Project Structure
• SDLC
• Waterfall-Sequential
• Prototyping
• Spiral-Evolutionary

3. Page 3Classification: Restricted
3
What is a Business Process Modeling?
A business Process:
• Has a goal
• Has specific inputs
• Has specific outputs
• User Resources
• Has a number of activities that are performed in some order
• Creates value of some kind for the customer
• The customer may be internal or external

4. Page 4Classification: Restricted
4
Benefits of Automated Business Process
• Reduce costs/more efficient use of resources
• Improved communication
• Better accountability
• Smarter decision-making from more accurate data

5. Page 5Classification: Restricted
IT Project Structure
Business Stakeholders
Subject Matter Experts (SMEs)
Technology Head
Technical Architect Project Manager QA Manager Production
Support
Junior Technical
Architects/
Assistants
Technical Lead
Developer
QA Leads
QA Analysis
Business Analyst

6. Page 6Classification: Restricted
Software Development Life Cycle
• 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:

7. Page 7Classification: Restricted
SDLC Methodologies
• Waterfall Model - linear framework type
• Incremental Model - combination of linear and iterative framework type
• Iterative Model- Repetitious framework type
• Agile-Scrum

8. Page 8Classification: Restricted
About Waterfall Methodology
• Originally invented in 1970 by Winston W. Royce
• The waterfall model is a sequential design process, used in software
development processes, in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases of conception, initiation,
analysis, design, construction, testing, production/implementation and
maintenance.

9. Page 9Classification: Restricted
Waterfall Approach
• Waterfall Model:

10. Page 10Classification: Restricted
Waterfall Approach
• The waterfall model is documentation-intensive, with earlier phases
documenting what must be done and subsequent phases adding greater
detail and defining how it should be done.
• The output from one phase serves as the input to the next phase, with the
project flowing from one step to the next in a waterfall fashion.
• An important consideration for the Waterfall model is that fixes or
modifications are often put off until the maintenance phase.
• This can be very costly, as the cost to correct a problem gets higher with
each successive phase.

11. Page 11Classification: Restricted
Waterfall Approach - Advantages
• System is well documented.
• Phases correspond with project management phases.
• Cost and schedule estimates may be lower and more accurate.
• Details can be addressed with more engineering effort if software is large or
complex.

12. Page 12Classification: Restricted
Waterfall Approach - Disadvantages
• All risks must be dealt with in a single software development effort.
• Because the model is sequential, there is only local feedback at the
transition between phases.
• A working product is not available until late in the project.
• Progress and success are not observable until the later stages. If a mistake
or deficiency exists in the documentation of earlier phases, it may not be
discovered until the product is delivered.
• Corrections must often wait for the maintenance phase.
Application
• The Waterfall model can be successfully used when requirements are well
understood in the beginning and are not expected to change or evolve over
the life of the project. Project risks should be relatively low.

13. Page 13Classification: Restricted
Prototype Approach
What is Prototyping?
• Software prototyping, can be defined as incomplete versions of the
software program being developed.
• A prototype typically simulates only a few aspects of the features of the
eventual program, and may be completely different from the eventual
implementation.
Purpose of Prototyping?
• To allow users of the software to evaluate developers' proposals for the
design of the eventual product by actually trying them out, rather than
having to interpret and evaluate the design based on descriptions.
• The software designer and implementer can obtain feedback from the
users early in the project. They may be able to refine them early in the
development of the software.

14. Page 14Classification: Restricted
Prototyping
Throwaway prototyping:
• Creation of a model that will eventually be discarded rather than becoming
part of the final delivered software.
• After preliminary requirements gathering is accomplished, a simple
working model of the system is constructed to visually show the users
what their requirements may look like when they are implemented into a
finished system.
• Making changes early in the development lifecycle is extremely cost
effective since there is nothing at that point to redo.
• If a project is changed after a considerable work has been done then small
changes could require large efforts to implement since software systems
have many dependencies
• Another strength of Throwaway Prototyping is its ability to construct
interfaces that the users can test. The user interface is what the user sees
as the system, and by seeing it in front of them, it is much easier to grasp
how the system will work

15. Page 15Classification: Restricted
Type of Prototyping
One method of creating a Throwaway Prototype is Paper Prototyping. The
prototype is implemented using paper and pencil, and thus mimics the
function of the actual product, but does not look at all like it
Another method to easily build high fidelity Throwaway Prototypes is to use a
GUI Builder and create a click dummy, a prototype that looks like the goal
system, but does not provide any functionality

16. Page 16Classification: Restricted
Spiral Approach
• Spiral Model is an incremental model, with emphasis on risk analysis for
technical and managerial risks
• The spiral model was defined by Barry Boehm in his 1988 article "A Spiral
Model of Software Development and Enhancement." This model was not
the first model to discuss iterative development, but it was the first model
to explain why the iteration matters
• The spiral model promotes quality assurance through prototyping at each
stage in systems development

17. Page 17Classification: Restricted
Spiral Approach

18. Page 18Classification: Restricted
Spiral Approach Steps
The system requirements are defined in as much detail as possible. This usually involves
interviewing a number of users representing all the external or internal users and other aspects
of the existing system
A preliminary design is created for the new system. In this phase all possible (and available)
alternatives, which can help in developing a cost effective project are analyzed and strategies, are
decided to use them. This phase has been added specially in order to identify and resolve all the
possible risks in the project development.
If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with
the available data and find out possible solution in order to deal with the potential changes in the
requirements
A first prototype of the new system is constructed from the preliminary design. This is usually a
scaled-down system, and represents an approximation of the characteristics of the final product
A second prototype is evolved by a fourfold procedure:
• evaluating the first prototype in terms of its strengths, weaknesses, and risks;
• defining the requirements of the second prototype;
• planning and designing the second prototype;
• constructing and testing the second prototype

19. Page 19Classification: Restricted
Spiral Approach Steps
At the project sponsor's option, the entire project can be aborted if the risk is
deemed too great. Risk factors might involve development cost overruns,
operating-cost miscalculation, or any other factor that could result in a less-
than-satisfactory final product
The existing prototype is evaluated in the same manner as was the previous
prototype, and, if necessary, another prototype is developed from it
according to the fourfold procedure outlined above
The preceding steps are iterated until the customer is satisfied that the
refined prototype represents the final product desired
The final system is constructed, based on the refined prototype
The final system is thoroughly evaluated and tested. Routine maintenance is
carried out on a continuing basis to prevent large-scale failures and to
minimize downtime

20. Page 20Classification: Restricted
Thank you