Software Development Life Cycle (SDLC)

cockeysvilleuterusΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 4 χρόνια και 7 μήνες)

106 εμφανίσεις

Software Development Life Cycle (SDLC)

This is a work flow for creating a new software/application. Usually, any
company that is in the software business follows the same route and
structure. In this document the main focus is on Business Requirement also
known as data gathering and QA. Some six-sigma methodology would also
be introduced in order to increase the quality of the application and to have a
smooth work flow, since a smooth work flow and a-good-quality software
have a direct relationship therefore increasing one will increase the other
accordingly. The SDLC steps are (Figure 1).
- Data gathering (Business Requirement)
- Technical specification
- Development
- QA
Data gathering (Business Requirement)

This stage is also referred to as Business Requirement stage. In this stage all
the information related to the new functionality would be put together with a
detailed explanation. This is the most important part of the SDLC, since from
now on everything would be built based on the gathered information.
Another reason that shows why this stage is very important is shown in the
graph below. As you can see in this graph, changing the requirements at this
stage doesn’t have any cost, or it is better to say that it has the minimum
cost for the organization, however the further we go towards the other
stages the cost of changing the requirements would increase.

Cost of Chan
the Activities in SDLC
ode deb
unit test
e test
l o
st to

Maximum Cost
at this level
Minimum of
Cost at this level

This stage is a tricky stage, since most of the time the party who would
provide the information is unattainable or otherwise occupied. There are
several ways of gathering information; I have my own personal methodology

when it comes to gathering the information from the parties who are
involved. Those parties are usually called customers. The methodologies are:

- Go and meet the clients
- Ask the clients to write what their requirements are
- Observe their work flow and take notes
Those are my ways of gathering information, however, some complex cases
you might require the use of all the above mentioned steps.
It is always a good idea to go and see the customers with one of the parties
in the company who knows the business and can talk to the customer in the
same language, instead of going to the customer with a lack of knowledge of
the business and asking them to teach you how the business works.

Asking the customer to write what they want is kind of signing off their
requirements, however, it is a big mistake if you think what they write is
always what they want, it sound strange but it is true. Since sometimes
people don’t express themselves properly and they use some terminology
that might not be familiar with you in your business, but it has the same

Observing their work flow and their process would help you understand the
way that they function. However, what they do things is not always the right
way of going about it and it might not be convertible to an automative
process. In this case, as well as observing their work flow, the business
analyst should be able to modify the customers work process (only when
he/she has a good understanding of the customers work flow) when it comes
to finalizing the business requirement with them, if their suggestions are
accepted by the client.
Technical Specification

Writing the technical specification is the step following the business
requirements. At this stage the system analyst would write a detailed
technical specification (there is always a debate how in depth the technical
specification should be). In small companies, at this stage, the system
analyst usually comes up with the data base structure and User Interface
design (UI). In the technical spec, the system analyst usually explains the
relation between the fields on the UI and their proper fields in the database,
how to retrieve the information (sometimes a pseudo code is needed to
explain how and from what table a field can be retrieved) and how the
functionality would be after triggering an action (for example what is going to
happen when “Save” button is pressed.)

In general, any piece of information that can help the developers to start
coding with less question should be in the technical spec. Having said that,
you might inquire as to “how can I put everything in the technical spec?” the

answer would be “You Can’t!!!”. Different organizations treat this issue
a) Some might have a standard document that explains some standard
functionalities that is used in most of their coding. In this case the
analyst doesn’t need to explain them in his/her technical spec.
In organizations that don’t have many products this can be easily
handled by trusting the knowledge and experience of the developers in
working with the application. In other word, developers will know how
to proceed because they have been working on this application for
long time.

In organizations that use neither of the options mentioned above, the
system analyst should explain everything in his/her technical spec in
detail and provide as much information/detail as he/she can.
Unfortunately this is the point where the analysts and developers have
a lot of discussion and blame the deficiency and mistakes on each
other, which usually materializes when QA reports a bug.


Once the system analyst has completed the technical spec, it is passed on
to the developers to start coding. At this stage, the parties that are
involved (i.e. developers, system analyst, etc) should get together and
review the spec.
This is a critical stage for both developers and analyst because the spec
should be fully understandable for the developers and the analyst should
be able to answer all the developers’ questions. If there are some piece of
information that are missing, the analyst would update the spec and
review it with the developers till the developers fully understand the
functionality and don’t have any further queries. At that point the
technical spec is ready for developers to code.

First I would like to define three methods of testing which most of the
organizations have been using.
1- Functional Testing

Functional testing covers how well the system executes the functions it is
supposed to execute—including user commands, data manipulation,
searches and business processes, user screens, and integrations.
Functional testing covers the obvious surface type of functions, as well as
the back-end operations (such as security and how upgrades affect the
2- Regression testing

The selective retesting of a software system that has been modified to
ensure that any bugs have been fixed and that no other previously
working functions have failed as a result of the reparations and that newly
added features have not created problems with previous versions of the
software. Also referred to as verification testing, regression testing is
initiated after a programmer has attempted to fix a recognized problem or
has added source code to a program that may have inadvertently
introduced errors. It is a quality control measure to ensure that the newly
modified codes still complies with its specified requirements and that
unmodified codes have not been affected by the maintenance activity
3- Automated testing

Automated testing is, when the steps to test a function gets recorded and
run again. There are different tools that record your testing steps and you
can run the test scenarios as many times as you want. This can be useful
for regression testing of a big application
When the developers finish coding, they send the finished product to QA
and ask QA people/person to start testing it. The question is “Do QA know
how and what to test?”
Before we answer this question, let’s first define QA’s responsibilities. The
QA is responsible to check the quality of the application and make sure a
bug-free application would be released. So, this means that the QA should
be able to come up with different scenarios and be able to run the
application with different data in those scenarios. To do this, the QA
person should have a good knowledge and understanding of the business
requirement, therefore, it is strongly recommended to involve the QA
from the first stage of SDLC, which is the data gathering stage. Some,
organizations do that and they call it QA Engineer or QA Analyst.
Now we go back to the question above and try to answer this question. As
I explained, the QA should test the application with different data in
different scenarios; therefore, a test plan with different cases/scenarios is
needed. The test plan can be written in different ways as follow:
- Write the test plans and create test scenarios right from the beginning
of the date gathering. In this case, the QA person is involved from the
beginning in gathering the information and can learn more about the
client’s needs.
- Write the test plan after finishing/finalizing the date gathering. In this
case the QA person is not involved in gathering the information and
meeting with the customers. Most of the organizations do this and
again it depends on the size of the organization.
- Write the test plans after finishing the Tech Spec. In this case both
Business Requirement and Tech Spec should be used to write the test

plans. Usually these kinds of test plans are used for the functionality
test of the new added feature to the application.
- Test the functionality after finishing the development and releasing to
QA server. In this case the test would only be to check if the system
crashes or not and would be a functional test not a regression test
Applying Six-Sigma to improve the quality

Defining the software quality is very difficult since, people have different
views and demand on software. To have a unique definition of software
quality, the definition below is used: good quality software is bug-free
software that works without crashing.
Improving the Software Development Life Cycle would help improving the
quality of the software. This means, few/no bugs therefore more satisfied
customers, thus, I will have more profitable organization. Having said
that, we should establish a methodology to improve our work flow and
our quality. The methodology that I have used and will explain in this
document is the Six-Sigma methodologies. The six-sigma methodologies
are as follow:

This is a methodology of six-sigma that applies within a simple performance
improvement model known as
ontrol, or


New Pr

DMAIC is also used when a product/process exists at the organization but
doesn’t meet customer specification or the process doesn’t perform
1.1- Define
At this stage we define the goals of the improvement activity or business.
Usually this happens at the stage of business requirement, data gathering
and where the most important goals are obtained from customers. Here we
can divide the goals in the organization into three categories:
a) Strategic Goal which is the strategic objectives of the organization (out
of this document’s scope) such as greater customer loyalty, greater
employee satisfaction.
b) Operations level, at this level the goal might be to increase the
amount of data that would be processed or the amount of code that
can be written, number of screens/functionality that can be
c) At the project level the goals might; be to reduce the number of bugs
and increase the amount of date that would be processed for a
particular process. Since, this is a project level and you are in direct
contact with the client, the goals can be obtained from direct
communication with customers, shareholders, and employees.

1.2- Measure
At this stage the current performance of the existing system would be
measured and evaluated. Also a valid and reliable factor for monitoring the
process toward the goals/business requirement would be established by
determining the current baseline.
1.3- Analyze
At this stage the system analyst would identify ways to eliminate the gap
between the current performance/quality of the system/process and the
desired goal in the business requirement. Since this stage can be a critical
part of the process using any tools, automated system, etc it is strongly
recommended. For instance, if there is a complaint about the system’s
slowness when retrieving the data from DB, the analyst job is to identify the
time to fetch the data from the database by using any tools for monitoring
the process, analyze them and report it to the parties that are involved.
Since this stage might need analysis in all the levels, it can be done in a
team of analysis from different departments.
1.4- Improve
In this stage the focus would be on improving the system based on the
business requirement, gathered information and the analysis that have been
done by the analyst by finding new ways to do things better, more efficient,
or faster. In order to implement the new approach, Using project
management and/or other planning and management tools and statistical
methods/Tools (SPS, ISO 900x, Reporting Tools) to validate the
improvement is recommended.
1.5- Control
At this stage we control the new system. Institutionalize the improved
system by modifying compensation, weaknesses and incentive systems,
policies, procedures, budgets, operating instructions and other management
systems. You may wish to utilize standardization such as ISO 900x to assure
that documentation is correct. Using the statistical tools to monitor stability
of the new systems would be a great help.

This is a methodology of six-sigma is known as
erify or DMADV and is used when:
1) a product/process doesn’t exist at the company and one needs to be
2) The existing product/process exists and has been optimized and still
doesn’t meet the level of client needs
2.1- Define

At this stage the goal of designing this project and project plan will be
defined and the following questions will be answered; why this project is
being designed? What is being designed? The process of understanding what
the customer wants, how important these benefits are, is also defined at this
level. Hence the reason why organizations put a lot of effort at this stage to
build/create a complete business requirement by using different way of
interviewing the customers (see Data gathering section)
2.2- Measure
At this stage the customers needs and specification will be determined.
Basically at this level we go one level deeper than defining the goals in the
previous stage and highlight the specific needs of the customer.
2.3- Analyze
At this stage, the available options of meeting the defined goals in the two
previous stages would be analyzed in order to provide a best-in-basket
design which would be matched with organization’s frame work (in case of
software companies)
2.4- Design
At this stage, the design and development of the new product would be
started based on the analysis that has been done before. If you are to build a
new software at this stage, it will depend on the work flow in your
organization the architecture works, data base design, prototyping, GUI
(Graphical User Interface) design and coding would get started.
2.5- Verify
At this stage, the product would be tested with real data to assure the
functionality meets customer’s needs which was defined in the previous
stages such as business requirement, technical spec, etc. Different
organizations have different test methodologies. A few of which have been
explained in QA section of this document.

In some cases there is another stage before verification and after Design,
which is optimization (DMADOV – Define, Measure, Analyze, Design,
Optimize, and Verify). At the Optimization level the designed product/process
needs to be optimized based on the requirements and the client’s work flow.

I, personally believe, optimization should be in DMAIC methodology since the
system exists and the weaknesses of the existing system are known and the
points that need to be optimized are more highlighted. If we use the
optimization in DMAIC methodology, it can be introduced either in the
Improve stage or right after that. In this case the DMAIC would become
DMAIOC and the model would be known as


The table below illustrates the DMADV and SDLC mapping.
Data Gathering & Business
Technical Specification
• Project planning and project
• Start up the project
• Date gathering
• Business Requirement
• Design
• Capabilities
• Develop based
on the design
• Architecture
• DB design
• Validate the
• Test plans*
* Test plans can be written in the Data Gathering & Business Requirement, Development or QA stage. That depends on the
organization policy


It often happens that a DMAIC turns to DMADV. This usually happens after
the defining stage. The following work flow shows the process.

Figure 1: