The second part of SDLC talks about various types of life cycles - Waterfall, Prototype, Spiral, V Model and Incremental. Special focus provided for Agile. Good number of case studies are provided to understand which life cycle to choose during what type of project. The slide deck concludes with detailed description of Requirement Engineering and Sytem modelling.
7. 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
8. Weakness
All requirements must be known upfront
Inhibits flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of software
development
Integration is one big bang at the end
Little opportunity for customer to preview
9. When to use?
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
12. Strengths
Emphasize planning for verification and validation
Each deliverable must be testable
Project management can track progress by milestones
Easy to use
13. Weakness
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
14. When to use?
Excellent choice for systems requiring high reliability
All requirements are known up-front
Solution and technology are known
17. Strengths
Customers can “see” the system requirements
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulates awareness of
additional needed functionality
18. Weakness
Tendency to abandon structured program development
for “code-and-fix” development
Bad reputation for “quick-and-dirty” methods
Overall maintainability may be overlooked
The customer may want the prototype delivered.
Process may continue forever (scope creep)
19. When to use?
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
22. Strengths
Provides early indication of risks
Users see the system early because of rapid prototyping
tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently
23. Weakness
Time spent for evaluating risks too large
Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned
24. When to use?
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because
of potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and
exploration)
27. 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
28. Weakness
Requires good planning and design
Requires early definition of a complete system
Well-defined module interfaces are required
Total cost of the complete system is not lower
29. When to use?
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
31. Product line p40
Product line p40 is already existing in the market,
successfully used by customers
In order to enhance performance requirements a new
ASIC got taped out
p40 firmware to be ported to new ASIC, with enhanced
performance requirements
Other functionality should work as expected
Customers have given go ahead for upgraded version
• Life cycle
• Main list of activities
• Specific focus areas
• Risks
• Dependencies
32. Product line a400
A400 is a high-availability telecom platform with
99.999% requirement
There are certain new features addition to meet
network requirements as a401
Security patches application to address latest
vulnerabilities
Live upgrade in the network with 3 million users
• Life cycle
• Main list of activities
• Specific focus areas
• Risks
• Dependencies
33. Product PL v1.0
PL v1.0 is a warehouse automation product priced at
40$ by ABC corporation
ABC want to bring down cost to 30$ with new design
R & D team is not sure about achieving this price-point
ABC is not ready to compromise on established PL v1.0
functionality
• Life cycle
• Main list of activities
• Specific focus areas
• Risks
• Dependencies
34. Cloud enabling
Product line 6500 series is a standalone consumer electronic device
First time upgrade functionality is planned to be introduced for
connecting it with cloud services
This has high risk as small failure might make the device unusable
User experience should be smooth during upgrade, which involves
user testing
Cost & risk to be assessed now
• Life cycle
• Main list of activities
• Specific focus areas
• Risks
• Dependencies
35. Online services
KKT organization wants to launch a new online services to
customers
They have decent understanding of the market but not sure how
they will receive the product
To test waters first they would like to release the product to
market with Minimal Viable Product (MVP) with one complete user
flow working
They would subsequently do a alpha testing with enthusiasts and
subsequently improve the product
• Life cycle
• Main list of activities
• Specific focus areas
• Risks
• Dependencies
38. Agile - A mindset
• Learn through Discovery
• Collaboration
• Failing Early
• Seeking Feedback for
learning
• Strive for Continuous
Delivery
• Focus on Value
A mindset is the established set of attitudes held by someone
39. Defined by 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
• Agile manifesto
• Formed by experts
42. Flavors
Flavor Characteristics
Scrum “Reference Implementation”
of Agile. Time boxed.
Kanban Focus of understanding how
work flows, visualizing the
work. Limit WIP.
SAFe: Agile @
Scale
Handles integrating multiples
teams with program and
portfolio layers
Extreme
Programming
(XP)
Technical focus on development
practices. Prescribes practices
that are commonly needed to
make Scrum deliver high
quality. Time Boxed.
44. Engineering Requirements
The process of establishing the services that the
customer requires from a system
Understanding constraints
Requirements themselves are generated by engineering
the whole process
Singular documented physical and functional need that
a particular product or service must be or perform
Statement that identifies a necessary
attribute, capability, characteristic, or quality of a
system for it to have value and utility to a user
Having Requirement Analysis (RA) document captures customer‟s needs by
following a Engineering process
45. Types
User requirements
• Statements in natural language plus diagrams of the services
the system provides and its operational constraints. Written for
customers
System requirements
• A structured document setting out detailed descriptions of the
system‟s functions, services and operational constraints
Functional requirements
• Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
Non Functional requirements
• Security, Scalability, Environment, Organizational, Compliance
46. Expectations
Complete
• They should include description of all facilities required
Consistent
• There should be no conflicts or uncertainties in the descriptions
of the system facilities
In practice, it is very difficult to produce a complete and consistent
requirement document
47. Elicitation process
Interviewing and questionnaires
Requirements workshops (Brain storming)
Storyboards
Prototyping
Voice of Customer
48. Why challenging?
Ideal system vs. possibility building it good
Expectations
Scope/boundary of the system
Old, rusted demands and wishes
Resistance to change
Aiming at a moving target
„Wicked problems‟ – More than one good solution
Functional vs. Technical solutions
Completeness
Nice-to-have vs. critical functionality
49. Stakeholder issues
Users don't have a clear idea of their requirements
Will not commit to a set of written requirements
Scope creep after cost and schedule have been fixed
Communication gaps
Users often do not participate in reviews
Technically unsophisticated
Don‟t understand the development process
Don‟t know about present technology
50. Engineer issues
Technical personnel and end users may have different
vocabularies
Engineers and developers may try to make the
requirements fit an existing system
Taking technical view of people's needs
51. Requirement spec
A complete description of the behavior of a system to be
developed and may include a set of use cases that describe
interactions the users will have with the software
In addition to a description of the software functions, the SRS also
contains non-functional requirements
Process of checking that a software system meets specifications
and that it fulfils its intended purpose
Validation: “Am I building the right product?”
Verification: “Am I building the product right?”
Both development and test engineers will have Requirement Spec as the
common point of building product. But their views are different to ensure
customer requirements are met or exceeded.
53. Use case model
A use case diagram depicts the interactions various external
entities in the customer's environment will have with they system
being modeled
A use case identifies an interaction that must be supported
between a given external entity, known as an actor, and the system
A use case is typically labeled as a verb since it is identifying
system behavior
An actor is labeled as a noun and is the entity that is requesting
some service from the system
Example: Microwave oven and its functionality
55. Data flow model
A Data Flow Mode describes how data is processed by the system
under development.
The Flow of Data from one stage of processing to the next is shown
in this model
57. Stay connected
About us: Emertxe is India‟s one of the top IT finishing schools & self learning kits
provider. Our primary focus is on Embedded with diversification focus on Java,
Oracle and Android areas
Emertxe Information Technologies,
No-1, 9th Cross, 5th Main,
Jayamahal Extension,
Bangalore, Karnataka 560046
T: +91 80 6562 9666
E: training@emertxe.com
https://www.facebook.com/Emertxe https://twitter.com/EmertxeTweet https://www.slideshare.net/EmertxeSlides