The document discusses various software development life cycle (SDLC) models including waterfall, V-model, prototype, spiral, and incremental, detailing their strengths, weaknesses, and when to use them. Case studies of different product lines highlight their requirements and challenges, emphasizing the importance of early user feedback and the agile methodology. It also covers requirement engineering processes, stakeholder issues, and system modeling techniques like use case and data flow models.

1. System Development Life
Cycle (SDLC)
Day-2
Team Emertxe

2. Course span-out

3. SDLC models

4. Models
 Waterfall
 V Shape
 Prototype
 Spiral
 Incremental

5. Waterfall model

6. Waterfall model

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

10. V model

11. V model

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

15. Prototype model

16. Prototype model

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

20. Spiral model

21. Spiral model

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)

25. Incremental model

26. Incremental model

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

30. Case studies

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

36. Agile

37. What is Agile?

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

40. Agile principles

41. Agile Practices

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.

43. Requirement Engineering

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.

52. System modeling

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

54. Use case modeling

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

56. Data flow 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

58. THANK YOU