System Development Life Cycle (SDLC) is a systematic frameworks that helps to deliver products on time with high quality. This presentation gives some real time case studies and establishes case for having a standard framework. It also covers major phases involved in product development.

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

2. Course span-out

3. Some fundamentals

4. Get the basics right
 SDLC and related areas are very critical for engineers
 Technical success v/s business success
• Building technically great product is nice
• Making them commercially successful is the key
 Standard frameworks like SDLC helps to do that
 Evolved over three decades
 Let us get our basics right!

5. What customer wants?
 A small game
 Need 6 volunteers

6. Customer need
 I want an Embedded device with 40$ price with device
performance as the key priority.
 I would like to have a NOR flash with 20 MB space with
1 MB RAM.
 User experience should be really excellent.
 I can compromise on price for performance and user
experience. Quality is a non-negotiable item

7. What actually happens?
Challenge 1: How to understand customer’s exact needs?

8. How do I deliver?
 Assuming customer challenges are understood, how to
deliver the product?
 How do I ensure:
• Quality of end product is very good
• Customer perceives quality
• Control quality in my product development
• Make it repeatable and scalable
 Often perceived as trust, brand, goodwill etc…
Challenge 2: How do I deliver a quality product?

9. Case studies

10. Outsourcing blues
 Ajay is an owner of small business, which has partnered with Arun’s
organization for re-branding
 This includes our logo, caption, digital identity, website, branding
artifacts, social media etc
 During vendor evaluation, Ajay was very happy with Arun’s
capability and awarded the project
 As time progressed Ajay observed the following:
• Consistently not keeping up with time commitments
• Delays in responding to emails, phone-calls, no-response
• Quality issues (Broken defect fixes, implementation flaws etc…)
• Behavioral problems (“you didn’t tell this before!”, “It’s your
problem”, “Why should I fix this?”, “you check this first!”)
 Ponder upon:
• What are the possibilities of problems with Arun?
• What experience Ajay is getting out of this activity?
• Would Ajay recommend Arun to his other business associates?
Key observations: Planning, Estimation, Team capability and skills

11. eCommerce project
 One of the newly formed company came up with idea of selling niche
products online
 They came up with an online portal which has excellent UI, e-commerce
and product listings
 During product development and testing everything worked fine
 Product was successfully launched on-time, initial customer reviews were
very positive
 Traffic to the website suddenly stared picking up for which the site
couldn’t handle. This resulted in multiple transaction failures, delays and
incorrect shipments
 This created a crisis in the organization
 Ponder upon:
• What did the company do right?
• Where did they go wrong?
• What element did they miss during product requirement gathering?
Key observations: Non-functional requirement handling (scalability, security,
regulation compliance, high-availability etc..)

12. Bad news
 Subbu was project manager, heading a complex system integration
project by combining many modules
 He understood the importance of making all modules working
together and created a system integration plan
 During initial days none of the modules worked well with each
other created a lot of issues
 In senior management meetings he raised it as a ‘RISK’ item and
consistently raised alarm, which initially created some confusion
 To address these issues an expert team was formed who figured
out all issues and solved the integration problem
 Product was released on time, customer was happy
 Ponder upon:
• What did Subbu do right?
• Confusion caused by Subbu initially was correct or wrong?
• What would be the side effects if Subbu didn’t raise issues on time?
Key observations: Risk raising and mitigation, Early handling, Being paranoid

13. Estimation challenges
 Ram was team leader of device driver team. For a new project he
was asked to estimate the time required to complete it.
 In the recent department change, Ram ended up getting
experienced engineers who were completely new to the device
driver domain.
 Ram went with his initial estimation and started the project
 Team members started feeling the heat when they actually started
implementing the project. With lesser or no previous knowledge
about device drivers, team was struggling
 Customer reported quality issues in the deliverable. Both Ram and
team were frustrated for letting each other down
 Ponder upon:
• What did Ram do incorrectly?
• How the team would have felt in the situation?
• If you were asked to take charge of project, what would you do?
Key observations: Team competency in estimation, Importance of estimation,
Team training and development, Customer expectations

14. Process for Process
 Chaithra was a highly quality conscious project manager who strongly
believes in establishing strong processes. Starting from the scratch she
built quality system of her team, which delivered quality products
consistently to customers. Chaithra and her team was highly regarded as
‘champions-of-quality’.
 However over a period of time, team started introducing too many new
processes and created a “checklist-and-approval” culture. For anything
and everything it became a world of excel sheets, check-lists, and
introducing new templates.
 Senior technical and management members started enjoying this
“approval” based culture as they started enjoying the “pseudo power”
that came along with
 Over a period of time customers started observing that Chaithra’s team is
slow in delivering products
 Ponder upon:
• What was the problem with Chaithra?
• Process based approach followed by the team is correct or incorrect?
• Why the customer is feeling delay in product releases?
Key observations: Process should help team and customer, Keeping it simple,
Impact of process in team culture

15. Challenges in Product development

16. Two challenges
 How to understand customer
requirements?
 How to deliver on-time with
high quality?

17. Requirements

18. Quality & Time

19. Processes
Parameter Aravind Benchmark
Number of operation 400 / month 25 / month
Post infection cases 4 / 10000 patients 6 / 10000 patients
Time taken for operation 10 minutes 30 minutes
Key point: Make it as a standard, Make it repeatable and scalable

20. SDLC - Introduction

21. What is SDLC?
 System Development Life Cycle
 A conceptual model used in project management
 Describes the stages involved, from an initial
feasibility study through maintenance

22. Why SDLC?
 To have a successful system
 To execute large projects
 To understand customer requirements
 To deliver on-time with high quality
 Process framework

23. Failures
 Schedule slippage
• No planning of development work (e.g. no milestones
defined)
• No control or review
 Cost over-runs
• Poor understanding of cost and effort by both developer
and user
 Does not solve user’s problem
• Deliverables to user not identified
• Poor understanding of user requirements
 Poor quality of software
• Technical incompetence of developers
 Poor maintainability

24. Success
 Taking an “engineering” approach - To design,
develop (build, fabricate) an artefact that meets
specifications efficiently, cost-effectively and
ensuring quality
 That comes from:
• Attempt to estimate cost/effort
• Plan and schedule work
• Involve user in defining requirements
• Identify stages in development
• Define clear milestones so that progress can be measured
• Schedule reviews both for control and quality
• Define deliverables
• Plan extensive testing

25. Process
 Process consists of activities/steps to be carried out in
a particular order
 Software process deals with both technical and
management issues

26. Process Types
 Process - Manage the project
• Defines project planning and control
• Effort estimations made and schedule prepared
• Resources are provided
• Feedback taken for quality assurance
• Monitoring done.
 Process – Change & Configuration management
• Resolving requests for changes
• Defining versions, their compositions
• Release control
 Process - For managing processes
• Improving the processes based on new techniques, tools, etc.
• Standardizations and certifications (ISO, CMM)

27. Steps in process
 Each step has a well-defined objective
 Requires people with specific skills
 Takes specific inputs and produces well-defined outputs
 Step defines when it may begin (entry criteria) and
when it ends (exit criteria)
 Uses specific techniques, tools, guidelines,
conventions.

28. Characteristics
 Precisely defined
 Predictable
 Quality
 Statistically controlled
 Supports testing and maintainability
 Facilitates early detection of and removal of defects
 Facilitate monitoring and improvement

29. SDLC - Phases

30. Initiation
 Is this project worth doing?
 Defining the project scope
 Key deliverable is a
feasibility report

31. Concept Development
 Feasibility Study (will it
work?)
 Identify system interfaces.
 Identify basic functional and
data requirements to satisfy
the business need.
 Cost/Benefit Analysis (is the
cost really worth it?)
 System Boundary (how far
should the project go?)
 Risk Management (what will
happen if we don't do it?)

32. Planning
 During this phase, a plan is
developed that documents
the approach to be used
 It includes a discussion of
methods, tools, tasks,
resources, project
schedules, and user input.
 Personnel assignments,
costs, project schedule,
and target dates are
established.
 A Project Management
Plan is created

33. Feasibility study
 Economic
• Cost / Benefit Analysis
 Technical
• Hardware, Software,
People etc.
• Identify and estimate
to see if user needs
can be satisfied using
current techniques
and technologies.
 Legal
 Alternative
• More tan one way
would be possible

34. Requirement Analysis
 Define the client’s
requirements
 Further define and refine the
functional and data
requirements and document
them in the Requirements
Document.
 Develop detailed data and
process models including
system inputs and outputs.
 Develop the test and
evaluation requirements that
will be used to determine
acceptable system
performance.

35. Design
 Define how the system will be
implemented
 Generate a number of design
options based on technical,
operational, economic, scheduling
and tendering constraints
 The client selects the best option
for their needs (assess feasibility
again)
 Acquire the necessary hardware
and software
 Design interfaces, databases,
networks as required
 Specify integration requirements
and software requirements
(programs)

36. Implementation
 Build and deliver the system
 Build/modify databases and
networks as required
 Build and test programs
• Acceptance testing, user
documentation, user
training, maintenance
procedures
 Prepare users for new system
 Finalize system and technical
documentation
 Install the system

37. Integration & Testing
 Subsystem integration,
system, security, and user
acceptance testing is
conducted.
 The user, with those
responsible for quality
assurance, validates that
the functional
requirements, as defined
in the functional
requirements document,
are satisfied by the
developed or modified
system.

38. Deployment
 This phase is initiated after the
system has been tested and
accepted by the user.
 The system is installed to
support the intended business
functions.
 System performance is
compared to performance
objectives established during
the planning phase.
 Implementation includes user
notification, user training,
installation of hardware,
installation of software onto
production computers, and
integration of the system into
daily work processes.

39. Evaluation
 Evaluation measures how
well the original ambitions
of the new system (i.e. the
logical design laid down
during the analysis phase)
have been achieved.
 Evaluation doesn't really
serve to improve the
system that is being
evaluated; it serves to
improve the next system
you will work on

40. Evaluation
 Typical evaluation criteria include:
• Speed
• Accuracy
• Quality of output
• Reliability
• Cost of operation
• Attractiveness
• Ease of use
• Robustness
• Capacity
• Compatibility with other systems
• Functionality (does it have the features it needs?)
• Security
• Flexibility (can it be upgraded, modified, adapted, tweaked,
configured?)
• Size, portability

41. Support & Maintenance
 Corrective - fix errors
 Adaptive - satisfy
changing needs
 Perfective - enhance
performance
 Preventative - fix
potential problems

42. Templates overview

43. 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

44. THANK YOU