A brief introduction on why and what is SDLC

1. Software
Development
Life Cycle
Models
Soumen Sarkar,
co-Founder, Idean system,
soumen@idean.in
Prepared for ICST- Engineering Group

2. What is Engineering?
“Engineering is the discipline, art, skill and
profession of acquiring and applying scientific,
mathematical, economic, social, and practical
knowledge, in order to design and build
structures, machines, devices, systems” –
wikipedia
2

3. Bailong Elevator – a fine produce of
Engineering
The Bailong Elevator at Zhangjiajie, China is the world’s largest exterior elevator. At over
1,000 feet tall, this elevator looms high midway up a cliff overlooking a valley far below.
Moreover, the elevator is mostly glass, affording passengers a dizzying view to the depths
below. 3

4. Quality of Engineering Execution
• Trade-specific sophistication for Quality
Measurement of final product
– Civil construction, mechanical, Electrical, electronics,
software
• However there are few common parameters used
across different engineering streams for monitoring
Engineering Execution
– Schedule Overrun
– Cost Overrun
4

5. Schedule Overrun Trend in
Infrastructure Projects in India
Source: report from Ministry of Statistics and Programme Implementation
5

6. Cost-overrun Trend in
Infrastructure Projects in India
Source: report from Ministry of Statistics and Programme Implementation
6

7. WHAT ABOUT SOFTWARE
PROJECTS?
7

8. Software Project :
A recent example [May, 2011]
Montclair State University is suing Oracle over an ERP system
implementation intended to enable a greater degree of student and
faculty self service for many academic and business processes via a
university portal.
Oracle was chosen in 2009 to implement PeopleSoft in support of the
project, named the Bell Tower Initiative for the school's landmark tower.
The university contracted for $4.3 million in software and technical
support along with a $15.75 million fixed fee implementation agreement
Suit claims that they will incur $20 million in expenses beyond the
planned cost of the project.
A recent report from Europe shows that in average 60% contract
experience cost-overrun with 30% failure rate
8

9. NASA Project – SafeGuard
Ballistic Missile Defense System
• 1969 – 1975
• 5407 person years
• Software Specs written at the same time as Hardware was
designed – tightly defined requirement
• Project delivered as per specs with a cost of $25 billion
• System Operational for 133 days: terminated in 1978
An example where the delivered product expired by the time
of completion
9

10. Software Project – Failure Statistics
• Standish Chaos Report – 2009
1994 1996 1998 2000 2002 2004 2009
Succeeded 16% 27% 26% 28% 34% 29% 32%
Failed 31% 40% 28% 23% 15% 18% 24%
Challenged 53% 33% 46% 49% 51% 53% 44%
• Dynamic Markets Ltd Study – 2007
62% of organizations experienced IT projects that failed to meet their schedules
49% suffered from budget overruns
47% had higher-than-expected maintenance costs
41% failed to deliver the expected business value and ROI
33% file to perform against expectations
Poorly defined applications (miscommunication between business and IT) contribute to a
66% project failure rate, costing U.S. businesses at least $30 billion every year (Forrester
Research)
10

11. Blind Men and Elephant
11

12. Waterfall Model
Requirements
Analysis
Design
Coding
Testing
Acceptance
Deployment
Maintenance
12

13. Pros and Cons of the Model
• Pros • Cons
– Structured, well-defined – Rigid
phases with clear – No feedback Loop
demarcation – Long Development Cycle
– Sequential – Not suitable for
– Emphasis on situations where
Documentation requirements evolve or
– Traceability changes too often
– Scope changes tightly
controlled
– Suited to Plan, Execute,
Measure model
13

14. Cost of major Software Defects*
increases as we move downstream
*Collard, Ross, Software Testing and Quality Assurance, working paper (1997).
14

15. We can try strengthening upstream phase to catch all the major defects
or find a model that changes the approach

16. Welcome to
Agile Development Model
• Instead of controlling the changes, accept that
Changes are inevitable and build model that
Accepts Requirement change as often as
asked for
• Test as development happens
• Baseline as often as possible
• Iteration matures product faster
16

17. Iterative Development Model
17

18. Iteration Illustrated
Waterfall Requirement Design Build Test
Model
Complete
Software
Delivered
Requirement
Itera Design Build Test
tive
Mod Partial
Software
el Delivered
Requirement Design Build Test
Complete
Software
Delivered
18

19. Agile Manifesto
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
19

20. Aspects of Agile Methodology
• Focus on ‘use’ rather than meeting requirements
• Bring changes in small batches
• Urgency-driven as opposed to Control-driven
• Deliver as fast as possible
• Regularly refactor Code
• Iterate
• COMMUNICATE
– amplify learning
– reduce ‘waste’
– Knowledge empowers
20

21. What do we get?
• Shorter Response Time to Customer
• Higher Utilization of Engineering bandwidth
Source: http://www.leanessays.com/2010/11/managing-pipeline.html 21

22. Pitfalls to watch for
• Large skill gap between seniors and juniors in
the team
• Lack of in-built traceability
• No test automation
• Poor Team communication
• Staying further to your customer
• Lack of enthusiasm to try out
22

23. Stay Hungry, Stay Foolish!
-Steve Jobs
23