View
611
Download
4
Embed Size (px)
DESCRIPTION
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.
Citation preview
System Development Life Cycle (SDLC)Day-2Team Emertxe
Course span-out
SDLC models
Models
Waterfall V Shape Prototype Spiral Incremental
Waterfall model
Waterfall model
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
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
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
V model
V model
Strengths Emphasize planning for verification and validation Each deliverable must be testable Project management can track progress by
milestones Easy to use
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
When to use?
Excellent choice for systems requiring high reliability
All requirements are known up-front Solution and technology are known
Prototype model
Prototype model
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
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)
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
Spiral model
Spiral model
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
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
When to use?When creation of a prototype is appropriateWhen costs and risk evaluation is importantFor medium to high-risk projectsLong-term project commitment unwise because
of potential changes to economic prioritiesUsers are unsure of their needsRequirements are complexNew product line Significant changes are expected (research and
exploration)
Incremental model
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
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
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
Case studies
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
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
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
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
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
Agile
What is Agile?
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
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
Agile principles
Agile Practices
FlavorsFlavor 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.
Requirement Engineering
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
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
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
Elicitation process Interviewing and questionnaires Requirements workshops (Brain storming) Storyboards Prototyping Voice of Customer
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
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
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
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.
System modeling
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
Use case modeling
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
Data flow model
Stay connectedAbout 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 9666E: [email protected]
https://www.facebook.com/Emertxe
https://twitter.com/EmertxeTweet
https://www.slideshare.net/EmertxeSlides
THANK YOU