business analysis session 4 software development lifecycle
TRANSCRIPT
![Page 1: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/1.jpg)
Session 4.
Software Development LifecycleRAM N SANGWAN
WWW.RNSANGWAN.COM
YOUTUBE CHANNEL : HTTP://YOUTUBE.COM/USER/THESKILLPEDIA
TO LEARN OR TEACH JOIN WWW.THESKILLPEDIA.COM
1
![Page 2: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/2.jpg)
Agenda
• SDLC and SDLC Models
• Waterfall Model
• Incremental Model
• Agile SDLC Models
• Rational Unify Process (RUP)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Adaptive Software Development (ASD)
• Rapid Application Development (RAD)
• V-Shaped SDLC Model
2
![Page 3: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/3.jpg)
SDLC
The Software Development Life Cycle (SDLC),
“is the entire process of formal, logical steps taken to develop a
software product. The concept generally refers to computer or
information systems.”
3
![Page 4: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/4.jpg)
4
![Page 5: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/5.jpg)
SDLC Model (s)
A framework (s) that describes the activities performed at each
stage of a software development project.
5
![Page 6: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/6.jpg)
Waterfall Model
• Requirements – defines needed
information, function, behavior,
performance and interfaces.
• Design – data structures, software
architecture, interface representations,
algorithmic details.
• Implementation – source code,
database, user documentation, testing.
6
![Page 7: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/7.jpg)
Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost or
schedule
7
![Page 8: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/8.jpg)
Waterfall Deficiencies
• All requirements must be known upfront
• Deliverables created for each phase are considered frozen –inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of softwaredevelopment – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the system (until it maybe too late)
8
![Page 9: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/9.jpg)
When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.
9
![Page 10: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/10.jpg)
Incremental Model
• Construct a partialimplementation of a totalsystem
• Then slowly add increasedfunctionality
• The incremental modelprioritizes requirements of thesystem and then implementsthem in groups.
10
![Page 11: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/11.jpg)
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
11
![Page 12: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/12.jpg)
Incremental Model Weaknesses
• Requires good planning and design
• Requires early definition of a complete and fully functionalsystem to allow for the definition of increments
• Well-defined module interfaces are required (some will bedeveloped long before others)
• Total cost of the complete system is not lower
12
![Page 13: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/13.jpg)
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
13
![Page 14: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/14.jpg)
Iterative and incremental process ExampleSuppose a customer wants to develop a word processing package
• Incremental approach:
provide just Creation functions in Release 1, then both Creation andOrganization in Release 2, finally add Formatting in Release 3, …
• Iterative approach:
provide primitive forms of all three functions in Release 1, thenenhance them in subsequent releases
Many organizations combine iterative and incremental approaches
14
![Page 15: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/15.jpg)
Agile SDLC’s
• Speed up or bypass one or more life cycle phases
• Usually less formal and reduced scope
• Used for time-critical applications
• Used in organizations that employ disciplined methods
15
![Page 16: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/16.jpg)
Some of Agile Methods
• Rational Unify Process (RUP)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Adaptive Software Development (ASD)
• Rapid Application Development (RAD)
16
![Page 17: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/17.jpg)
Rational Unified Process (RUP)
• Developed by “three amigos” at Rational Software (IBM)
• Grady Booch, Ivar Jacobson, and Jim Rumbaugh
• Unified Modeling Language (UML) is a set of graphical and linguistic
notations for modeling systems, not a process or method
• The three amigos also developed Rational Unified Process (RUP)
• Interestingly different from the traditional waterfall model
• Highly iterative and incremental process
• Software product is not released in one big bang at end of project
• Instead, developed and released in pieces (prototypes, partial releases,beta, etc.)
17
![Page 18: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/18.jpg)
Extreme Programming - XP
For small-to-medium-sized teams developing software with vagueor rapidly changing requirements
Coding is the key activity throughout a software project
• Communication among teammates is done with code
• Life cycle and behavior of complex objects defined in testcases – again in code
18
![Page 19: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/19.jpg)
XP Practices
1. Planning game – determine scope of the next release bycombining business priorities and technical estimates
2. Small releases – put a simple system into production, then releasenew versions in very short cycle
3. Metaphor – all development is guided by a simple shared story ofhow the whole system works
4. Simple design – system is designed as simply as possible (extracomplexity removed as soon as found)
5. Testing – programmers continuously write unit tests; customers writetests for features
6. Refactoring – programmers continuously restructure the systemwithout changing its behavior to remove duplication and simplify
19
![Page 20: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/20.jpg)
XP Practices
7. Pair-programming -- all production code is written with twoprogrammers at one machine
8. Collective ownership – anyone can change any codeanywhere in the system at any time.
9. Continuous integration – integrate and build the system manytimes a day – every time a task is completed.
10. 40-hour week – work no more than 40 hours a week as a rule
11. On-site customer – a user is on the team and available full-timeto answer questions
12. Coding standards – programmers write all code in accordancewith rules emphasizing communication through the code
20
![Page 21: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/21.jpg)
XP is “extreme” because
Commonsense practices taken to extreme levels• If code reviews are good, review code all the time (pair
programming)
• If testing is good, everybody will test all the time
• If simplicity is good, keep the system in the simplest design thatsupports its current functionality. (simplest thing that works)
• If design is good, everybody will design daily (refactoring)
• If architecture is important, everybody will work at defining andrefining the architecture (metaphor)
• If integration testing is important, build and integrate test severaltimes a day (continuous integration)
• If short iterations are good, make iterations really, really short
21
![Page 22: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/22.jpg)
Feature Driven Design (FDD)
Five FDD process activities
1. Develop an overall model – Produce class and sequence diagrams from chiefarchitect meeting with domain experts and developers.
2. Build a features list – Identify all the features that support requirements.Features are functions that can be developed in two weeks and expressed inclient terms with the template: <action> <result> <object>
i.e. Calculate the total of a sale
3. Plan by feature -- the development staff plans the development sequence offeatures
4. Design by feature -- the team produces sequence diagrams for the selectedfeatures
5. Build by feature – the team writes and tests the code
22
![Page 23: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/23.jpg)
Prototyping model
• The prototyping model requires that before carrying out the
development of the actual software , a working prototype of the
system should be built.
A prototype is a toy implementation of the system.
• In many instances the client only has a general view of what is
expected from the software product. In such a scenario where
there is an absence of detailed information regarding the input to
the system, the processing needs and the output requirements, the
prototyping model may be employed.
23
![Page 24: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/24.jpg)
Iterative developmentDesign
Implement
Test
Maintain
Acceptance By customer
Prototype development
Requirements
gathering
Quick design
Build prototypeRefine requirements
incorporating
Customer suggestion
Customer evaluation
Of prototype
24
![Page 25: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/25.jpg)
Steps of Prototyping Model1. Requirements Gathering and Analysis: : The requirements of the system are
defined in detail. The user is interviewed in order to know the requirements of the
system.
2. Quick Design: A preliminary design or quick design for the system is created . It
includes the important aspects of the system, which gives an idea of the system to
the user.
3. Build Prototype : Information gathering from quick design is modified to form a
prototype .
4. Assessment or user evaluation: Next , the proposed system is presented to the userfor consideration as part of the development process.
5. Prototype Refinement: Once the user evaluates the prototype, it is refined
according to the requirements .
6. Engineer Product : The final system is thoroughly evaluated and tested followedby routine maintenance on a continuing basis to prevent large-scale failures and
to minimize downtime.
25
![Page 26: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/26.jpg)
Advantages of Prototyping Model
• Provides a working model to the user early in the process, enabling
early assessment and increasing user confidence.
• The developer gains experience and insight by developing a
prototype , thereby resulting in better implementation of
requirements.
• Helps in reducing risks associated with the project.
• The prototyping model serves to clarify requirements , which are not
clear , hence reducing ambiguity and improving communication
between the developer and the user.
• There is a great involvement of users in software development .
Hence, the requirement of the users are met to the greatest extent.
26
![Page 27: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/27.jpg)
Disadvantages of Prototyping Model
• If the user is not satisfied with the developed prototype, then a new
prototype is developed . Thus, time consuming and expensive.
• The developer loses focus of the real purpose of prototype and
compromises on the quality of the product.
• Prototyping can lead to false expectations. It often creates a
situation where the user believes that the development of the
system is finished when it is not.
• The primary goal of prototyping is rapid development. Thus , the
design of the system may suffer as it is built in a series of layers
without considering integration of all the other components.
27
![Page 28: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/28.jpg)
When to use Prototype Model
• Requirements are unstable or have to be clarified
• As the requirements clarification stage of a waterfall model
• Develop user interfaces
• Short-lived demonstrations
• New, original development
• With the analysis and design portions of object-oriented
development.
28
![Page 29: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/29.jpg)
V-Shaped SDLC Model
• A variant of the Waterfall
that emphasizes the
verification and validation of
the product.
• Testing of the product is
planned in parallel with a
corresponding phase of
development
29
![Page 30: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/30.jpg)
V-Shaped Steps
1. Project and Requirements Planning – allocate resources
2. Product Requirements and Specification Analysis – complete specification of thesoftware system
3. Architecture or High-Level Design – defines how software functions fulfill thedesign
4. Detailed Design – develop algorithms for each architectural component
5. Production, operation and maintenance – provide for enhancement andcorrections
6. System and acceptance testing – check the entire software system in itsenvironment
7. Integration and Testing – check that modules interconnect correctly
8. Unit testing – check that each module acts as expected
9. Coding – transform algorithms into software
30
![Page 31: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/31.jpg)
V-Shaped Strengths
• Emphasize planning for verification and validation of the
product in early stages of product development
• Each deliverable must be testable
• Project management can track progress by milestones
• Easy to use
31
![Page 32: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/32.jpg)
V-Shaped Weaknesses
• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes in requirements
• Does not contain risk analysis activities
32
![Page 33: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/33.jpg)
When to use the V-Shaped Model
• Excellent choice for systems requiring high reliability – hospitalpatient control applications
• All requirements are known up-front
• When it can be modified to handle changing requirementsbeyond analysis phase
• Solution and technology are known.
33
![Page 34: Business analysis session 4 software development lifecycle](https://reader031.vdocument.in/reader031/viewer/2022030306/58ce86401a28ab210a8b69c3/html5/thumbnails/34.jpg)
ThankyouWWW.RNSANGWAN.COM
34