SDLC

SDLC Methodologies:
SDLC stands for software development Life Cycle. It is the complete process of conception of a software
functionality (be it a website or a back-end management tool) to the development and productionalization
and deployment of the software in a working environment. Most commonly used SDLC models are:
1. Waterfall
2. Agile Scrum
3. RAD- Rapid Application Development
4. Rational Unified Process (RUP)

1. Waterfall:
This is the most commonly used SDLC model implemented today.
All phases of this model are separated into process phases, and CASCADE into each other.

Project Planning:
This is the Initial Assessment Phase, also known sometimes as Project Kick-off. In this Phase, the project
goals, description, estimated cost and VERY high level requirements are defined.
The purpose of this document is to present to the CORE committee as a feasible project, and to obtain
funding and permission to go ahead with the project.
The document created is in SOME COMPANIES known as the Project Initiation Assessment Document (PIAD),
SOW, Project Charter, Project Proposal etc. The Project Manager, Business Owner, Business Analyst and
Tech lead are involved in the creation of the PIAD.
Description:
the description includes the business need, the problem statement and the PROPOSED solution for
the problem, as well as a description of the criticality of the proposed solution.
SDLC

Note: This is a proposed solution and may change drastically over the remainder of the Waterfall
process
Goals:
Project goals include the proposed solution and estimated revenue generation by the
deployment of that project over a set period of time.

High level Requirements:

The PIAD will also contain a set of high level requirements that were identified as part of the
solution during the initial assessment by the BA, PM, Business Owner and Tech Lead.
These will be VERY high level, and once the project is given the go-ahead, these same
requirements will be used
Technical Assessment:
Once the high level requirements are done, the tech lead will do an estimate of the cost of the
project. This will be just a ball-park figure and will take into account number of hours for BA, QA,
Devs, support guys etc.
this cost and the estimated revenue generation will be one of the key deciding factors about the
criticality of the project.
Once the PIAD is finalized, it is taken for approval to the Core committee or the Approval committee. They
are given a presentation by the Project Manager and they will then decide about the criticality and priority
of this project, they will also decide the funding for the project.

Requirements Definition:
This is one of the key aspects of SDLC. This is where the Business Analyst uses requirements gathering
techniques to gather stake-holder requirements for detailed documentation. The business analyst expands
on the HIGH LEVEL REQUIREMENTS that were documented on the PIAD/PC and holds sessions with the
business owners, system architects and the developers in order to determine the “AS IS” and “TO BE”
systems and determine the in-scope and out of scope items.
The key concept here is:
The Business Analyst MUST only focus on the “WHAT”. . . WHAT needs to be built.
The Business MUST NOT focus on how or why. . . the WHY is the headache of the business owners and the
HOW is the headache of the developers, the dev lead, the tech lead and the solutions architect.

Design, Develop and Implement:

Once the requirements are signed off by all stakeholders, the tech lead, solutions architect and the dev lead
will sit together to create a Technical Design Document (TDD) or a Technical Solution Document (TSD). This
is the document used as a repository to add all technical specs and changes required in the identified
systems in order to build the new functionality/system.
The functionality/system is then built in the development environment. For development purposes, a virtual
environment is created where all developers can independently work and save their progress.
Integration & Implementation:
Once the different pieces of the functionality have been built, they have to be rigorously tested (UNIT
TESTING) individually. This is primarily done by the developers themselves in the development environment
and then the different pieces are integrated together.
There might also be the case that the system being built is to be integrated with third-party software
products (like Paypal, Facebook sharing buttons etc ), therefore the new system is integrated with all such
3rd party tools.
SDLC

Testing:
the next stage of the process is Software testing. The software is rigorously tested by the Quality Analyst
(QA) for bugs and defects.
When the requirements are being finalized, the QA will start formulating the TEST CASES in the preferred
format used by the company. The QA will then hold meetings and give a read-out to the dev, PM, BA and
tech lead to obtain sign off on the test cases that he/she has prepared. Numbers of different testing
techniques are used in order to test the application (mentioned in detail in the QA sections). Depending on
the criticality of the application, success criteria are defined by the team for QA: if the test cases are passed
to those criteria (ie 85% pass with NO priority 1 or 2 bugs), then the QA process is over and the application
can be presented to the business owners for sign-off/UAT.

Install, Productionalize and Maintain:

Once the UAT is conducted by the BA and sign-off has been received, the dev team will push to deploy the
code in the production environment. This happens in designated code release dates that are determined for
each individual company. Release dates and deadlines are critical and product must be delivered on its
designated release date, and the RELEASE MANAGER of each release will be responsible for facilitating all
teams that are pushing code to production on the same release date. Once the code has been pushed to
production, the QAs will do full regression testing across all platforms to ensure no other system was
impacted by the new code push. The Dev team will be on stand-by in order to address any integration issues
that may come

If the software application was being built for another company (client), then the devs will install and
handover the software application to the client and help to integrate the software application with the
internal systems of the client.
Note: if the project is a small effort and doesnot require major code change (for example updating the
Facebook share button), then the common practice is to follow RAD model, and once the code is ready to go
live, the Project Manager will NOT wait for a release. The code will be pushed to live immediately.

Advantages of waterfall model:

 Simple and easy to understand and use.
 Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review
process.
 Phases are processed and completed one at a time.
 Works well for certain projects where requirements are very well understood.
SDLC

Disadvantages of waterfall model:

 Once an application is in the testing stage, it is very difficult to go back and change something that was
not well-thought out in the concept stage.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of changing.

When to use the waterfall model:

 Requirements are very well known, clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.
SDLC

2. Agile Scrum
Scrum is an iterative and incremental Agile software development framework for managing software
projects and product or application development. A key principle of Scrum is its recognition that during a
project the customers can change their minds about what they want and need (often called requirements
churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned
manner. Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or
defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging
requirements.

Scrum Team
Product Owner, Scrum Master and Development Team
Product Owner
The person responsible for maintaining the Product Backlog by representing the interests of the
stakeholders, and ensuring the value of the work the Development Team does.
Scrum Master
The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.

Development Team
A cross-functional group of people responsible for delivering potentially shippable increments of Product at
the end of every Sprint. These include the Tech lead, the BA, the QA(s) and the developers. The BA analyses
and documents the requirements for each product backlog, the tech lead does the assessment and the
technical design, the developers create the product and the QAs perform testing on the product.
SDLC

Scrum burn down chart

Daily progress for Sprints over the scrum's length.

Release burn down chart

Sprint level progress of completed product backlog items in the Product Backlog.
SDLC

Product backlog (PBL)

This is a prioritized list of high-level requirements.
The product backlog is an ordered list of "requirements" that is maintained for a product. It consists of
features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully
deliver a working software system. The items are ordered by the Product Owner based on considerations
like risk, business value, dependencies, date needed, etc.
The features added to the backlog are commonly written in story format. The product backlog is the "What"
that will be built, sorted in the relative order in which it should be built. It is open and editable by anyone,
but the Product Owner is ultimately responsible for ordering the stories on the backlog for the Development
Team to choose.
The product backlog contains rough estimates of both business value and development effort, which are
often, but not always, stated in story points using a rounded Fibonacci sequence. Those estimates help the
Product Owner to gauge the timeline and may influence ordering of backlog items. For example, if the "add
spellcheck" and "add table support" features have the same business value, the one with the smallest
development effort will probably have higher priority, because the ROI (Return on Investment) is higher.
The product backlog and business value of each listed item is the responsibility of the Product Owner. The
estimated effort to complete each backlog item is, however, determined by the Development Team, who
contributes by estimating items and user stories, either in story points or in estimated hours.

Sprint backlog (SBL)

A prioritized list of tasks to be completed during the sprint.
The sprint backlog is the list of work the Development Team must address during the next sprint. The list is
derived by selecting product backlog items from the top of the product backlog until the Development Team
feels it has enough work to fill the sprint. This is done by the Development Team asking "Can we also do
this?" and adding product backlog items to the sprint backlog. The Development Team should keep in mind
its past performance assessing its capacity for the new sprint, and use this as a guide line of how much
"effort" they can complete.
The product backlog items are broken down into tasks by the Development Team. Tasks on the sprint
backlog are never assigned; rather, tasks are signed up for by the team members as needed according to the
set priority and the Development Team member skills. This promotes self-organization of the Development
Team, and developer buy-in.
Once a Sprint Backlog is committed, no additional functionality can be added to the Sprint backlog except by
the team. Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized if necessary,
and the next set of functionality is selected for the next Sprint.
SDLC

Kanban Chart
The Kanban chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every
day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.

Sprint
A time period (typically 1–4 weeks) in which development occurs on a set of backlog items that the team has
committed to. Also commonly referred to as a Time-box or iteration.

Increment
The increment is the sum of all the Product Backlog Items completed during a sprint and all previous sprints.
At the end of a sprint, the Increment must be done according to the Scrum Team's definition of done. The
increment must be in usable condition regardless of whether the Product Owner decides to actually release
it.

Spike
A time boxed period used to research a concept and/or create a simple prototype. Spikes can either be
planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many
sprint delivery objectives. Spikes are often introduced before the delivery of large or complex product
backlog items in order to secure budget, expand knowledge, and/or produce a proof of concept. The
duration and objective(s) of a spike will be agreed between the Product Owner and Delivery Team before
the start. Unlike sprint commitments, spikes may or may not deliver tangible, shippable, valuable
SDLC

functionality. For example, the objective of a spike might be to successfully reach a decision on a course of
action. The spike is over when the time is up, not necessarily when the objective has been delivered.

Tasks
Work items added to the sprint backlog at the beginning of a sprint and broken down into hours. Each task
should not exceed 12 hours (or two days), but it's common for teams to insist that a task take no more than
a day to finish.

Definition of Done (DoD)

The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires
that all regression tests should be successful.

Velocity
The total effort a team is capable of in a sprint. The number is derived by evaluating the work (typically in
user story points) completed from the last sprint's backlog items. The collection of historical velocity data is
a guideline for assisting the team in understanding how much work they can do in a future sprint.

Impediment
Anything that prevents a team member from performing work as efficiently as possible.

Abnormal Termination
The Product Owner can cancel a Sprint if necessary.The Product Owner may do so with input from the team,
Scrum Master or management. For instance, management may wish to cancel a sprint if external
circumstances negate the value of the sprint goal. If a sprint is abnormally terminated, the next step is to
conduct a new Sprint planning meeting, where the reason for the termination is reviewed.

Advantages of Agile model:

 Customer satisfaction by rapid, continuous delivery of useful software.
 People and interactions are emphasized rather than process and tools. Customers, developers and
testers constantly interact with each other.
 Working software is delivered frequently (weeks rather than months).
 Face-to-face conversation is the best form of communication.
 Daily cooperation between business people and developers.
 Continuous attention to technical excellence and good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed

Disadvantages of Agile model:

 In case of some software deliverables, especially the large ones, it is difficult to assess the effort
required at the beginning of the software development life cycle.
 There is lack of emphasis on necessary designing and documentation.
 The project can easily get taken off track if the customer representative is not clear what final outcome
that they want. (SCOPE CREEP)
 Only senior programmers are capable of taking the kind of decisions required during the development
process. Hence it has no place for newbie programmers, unless combined with experienced resources.
SDLC

When to use Agile model:

 When new changes are needed to be implemented. The freedom agile gives to change is very
important. New changes can be implemented at very little cost because of the frequency of new
increments that are produced.
 To implement a new feature the developers need to lose only the work of a few days, or even only
hours, to roll back and implement it.
 Unlike the waterfall model in agile model very limited planning is required to get started with the
project. Agile assumes that the end users’ needs are ever changing in a dynamic business and IT world.
Changes can be discussed and features can be newly effected or removed based on feedback. This
effectively gives the customer the finished system they want or need.
 Both system developers and stakeholders alike, find they also get more freedom of time and options
than if the software was developed in a more rigid sequential way. Having options gives them the ability
to leave important decisions until more or better data or even entire hosting programs are available;
meaning the project can continue to move forward without fear of reaching a sudden standstill.
SDLC

3. Rapid Application Development- RAD

RAD model is Rapid Application Development model. It is a type of incremental model. In RAD model the
components or functions are developed in parallel as if they were mini projects. The developments are
time boxed, delivered and then assembled into a working prototype. This can quickly give the customer
something to see and use and to provide feedback regarding the delivery and their requirements.

The phases in the rapid application development (RAD) model are:

Business modeling:
The information flow is identified between various business functions.

Data modeling:
Information gathered from business modeling is used to define data objects that are needed for the
business.

Process modeling:
Data objects defined in data modeling are converted to achieve the business information flow to
achieve some specific business objective. Description are identified and created for CRUD of data
objects.

Application generation:
Automated tools are used to convert process models into code and the actual system.

Testing and turnover:

Test new components and all the interfaces.
SDLC

Advantages of the RAD model:

 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.
SDLC

Disadvantages of RAD model:

 Depends on strong team and individual performances for identifying business requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills

When to use RAD model:

 RAD should be used when there is a need to create a system that can be modularized in 2-3
months of time.
 It should be used if there’s high availability of designers for modeling and the budget is high
enough to afford their cost along with the cost of automated code generating tools.
 RAD SDLC model should be chosen only if resources with high business knowledge are available
and there is a need to produce the system in a short span of time (2-3 months).
SDLC

IBM’s Rational Unified Process (RUP)

The Rational Unified Process describes how to effectively deploy commercially proven approaches
to software development for software development teams. These are called “best practices” not so
much because you can precisely quantify their value, but rather, because they are observed to be
commonly used in industry by successful organizations. The Rational Unified Process provides each
team member with the guidelines, templates and tool mentors necessary for the entire team to take
full advantage of among others the following best practices:

1. Develop software iteratively

2. Manage requirements
3. Use component-based architectures
4. Visually model software
5. Verify software quality
6. Control changes to software

Two Dimensions
The process can be described in two dimensions, or along two axes:
 The horizontal axis represents time and shows the dynamic aspect of the process as it is
enacted, and it is expressed in terms of cycles, phases, iterations, and milestones.
 The vertical axis represents the static aspect of the process: how it is described in terms of
activities, artifacts, workers and workflows.
SDLC

The software lifecycle is broken into cycles, each cycle working on a new generation of the product.
The Rational Unified Process divides one development cycle in four consecutive phases:

 Inception phase
 Elaboration phase
 Construction phase
 Transition phase

Each phase is concluded with a well-defined milestone—a point in time at which certain critical
decisions must be made and therefore key goals must have been achieved

Inception Phase
During the inception phase, you establish the business case for the system and delimit the project
scope. To accomplish this you must identify all external entities with which the system will interact
(actors) and define the nature of this interaction at a high-level. This involves identifying all use
cases and describing a few significant ones. The business case includes success criteria, risk
assessment, and estimate of the resources needed, and a phase plan showing dates of major
milestones.
The outcome of the inception phase is:

A vision document: a general vision of the core project's requirements, key features, and main
constraints.
 An initial use-case model (10% -20% complete).
 An initial project glossary (may optionally be partially expressed as a domain model).
 An initial business case, which includes business context, success criteria (revenue
projection, market recognition, and so on), and financial forecast.
 An initial risk assessment.
 A project plan, showing phases and iterations.
 A business model, if necessary.
 One or several prototypes.
 Milestone : Lifecycle Objectives

At the end of the inception phase is the first major project milestone: the Lifecycle Objectives
Milestone. The evaluation criteria for the inception phase are:

 Stakeholder concurrence on scope definition and cost/schedule estimates.

 Requirements understanding as evidenced by the fidelity of the primary use cases.
 Credibility of the cost/schedule estimates, priorities, risks, and development process.
 Depth and breadth of any architectural prototype that was developed.
 Actual expenditures versus planned expenditures.

The project may be cancelled or considerably re-thought if it fails to pass this milestone
SDLC

Elaboration Phase

The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural
foundation, develop the project plan, and eliminate the highest risk elements of the project. To accomplish
these objectives, you must have the “mile wide and inch deep” view of the system.
Architectural decisions have to be made with an understanding of the whole system:
 its scope
 major functionality
 Nonfunctional requirements such as performance requirements.

It is easy to argue that the elaboration phase is the most critical of the four phases. At the end of this phase,
the hard “engineering” is considered complete and the project undergoes its most important day of
reckoning: the decision on whether or not to commit to the construction and transition phases. For most
projects, this also corresponds to the transition from a mobile, light and nimble, low-risk operation to a high-
cost, high-risk operation with substantial inertia. While the process must always accommodate changes, the
elaboration phase activities ensure that the architecture, requirements and plans are stable enough, and the
risks are sufficiently mitigated, so you can predictably determine the cost and schedule for the completion
of the development. Conceptually, this level of fidelity would correspond to the level necessary for an
organization to commit to a fixed-price construction phase.

The outcome of the elaboration phase is:

 A use-case model (at least 80% complete) — all use cases and actors have been identified, and
most use case descriptions have been developed.
 Supplementary requirements capturing the non-functional requirements and any requirements
that are not associated with a specific use case.
 A Software Architecture Description.
 An executable architectural prototype.
 A revised risk list and a revised business case.
 A development plan for the overall project, including the coarse-grained project plan, showing
iterations” and evaluation criteria for each iteration.
 An updated development case specifying the process to be used.
 A preliminary user manual (optional).

The main evaluation criteria for the elaboration phase involve the answers to these questions:
 Is the vision of the product stable?
 Is the architecture stable?
 Does the executable demonstration show that the major risk elements have been addressed
and credibly resolved?
 Is the plan for the construction phase sufficiently detailed and accurate? Is it backed up with a
credible basis of estimates?
 Do all stakeholders agree that the current vision can be achieved if the current plan is executed
to develop the complete system, in the context of the current architecture?
 Is the actual resource expenditure versus planned expenditure acceptable?

The project may be aborted or considerably re-thought if it fails to pass this milestone.
Milestone name: Lifecycle architecture
SDLC

Construction Phase
During the construction phase, all remaining components and application features are developed and
integrated into the product, and all features are thoroughly tested. The construction phase is, in one sense,
a manufacturing process where emphasis is placed on managing resources and controlling operations to
optimize costs, schedules, and quality. In this sense, the management mindset undergoes a transition from
the development of intellectual property during inception and elaboration, to the development of
deployable products during construction and transition.

The outcome of the construction phase is a product ready to put in hands of its end-users. At minimum, it
consists of:

 The software product integrated on the adequate platforms.

 The user manuals.
 A description of the current release.
 Milestone : Initial Operational Capability

At the end of the construction phase is the third major project milestone (Initial Operational Capability
Milestone).

At this point, you decide if the software, the sites, and the users are ready to go operational, without
exposing the project to high risks. This release is often called a “beta” release.

The evaluation criteria for the construction phase involve answering these questions:
 Is this product release stable and mature enough to be deployed in the user community?
 Are all stakeholders ready for the transition into the user community?
 Are the actual resource expenditures versus planned expenditures still acceptable?

Transition may have to be postponed by one release if the project fails to reach this milestone.

Transition Phase
The purpose of the transition phase is to transition the software product to the user community. Once the
product has been given to the end user, issues usually arise that require you to develop new releases,
correct some problems, or finish the features that were postponed.
The transition phase is entered when a baseline is mature enough to be deployed in the end-user domain.
This typically requires that some usable subset of the system has been completed to an acceptable level of
quality and that user documentation is available so that the transition to the user will provide positive
results for all parties.
This includes:
 “beta testing” to validate the new system against user expectations
 parallel operation with a legacy system that it is replacing
 conversion of operational databases
 training of users and maintainers
 roll-out the product to the marketing, distribution, and sales teams

The transition phase focuses on the activities required to place the software into the hands of the users.
Typically, this phase includes several iterations, including beta releases, general availability releases, as well
SDLC

as bug-fix and enhancement releases. Considerable effort is expended in developing user-oriented

documentation, training users, supporting users in their initial product use, and reacting to user feedback. At
this point in the lifecycle, however, user feedback should be confined primarily to product tuning,
configuring, installation, and usability issues.

The primary objectives of the transition phase include:

 Achieving user self-supportability
 Achieving stakeholder concurrence that deployment baselines are complete and consistent with the
evaluation criteria of the vision
 Achieving final product baseline as rapidly and cost effectively as practical
 Milestone: Product Release

The primary evaluation criteria for the transition phase involve the answers to these questions:
 Is the user satisfied?
 Are the actual resources expenditures versus planned expenditures still acceptable?

Iterations
Each phase in the Rational Unified Process can be further broken down into iterations. An iteration is a
complete development loop resulting in a release (internal or external) of an executable product, a subset of
the final product under development, which grows incrementally from iteration to iteration to become the
final system.

Benefits of an iterative approach

Compared to the traditional waterfall process, the iterative process has the following advantages:
 Risks are mitigated earlier
 Change is more manageable
 Higher level of reuse
 The project team can learn along the way
 Better overall quality