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 doesnt 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. Maximum Cost

at this level
Cost of Changing the Activities in SDLC 120 100 80 60 40 20 0 Cost to re-Wrok

Minimum of Cost at this level

m en t

de bu gi ng

de sig n

te st an ce in it i

re qu ire

nt eg ra t io n

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

un it te st i

Activity

pe rfo rm

co de

al o

pe ra tio n

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 dont express themselves properly and they use some terminology that might not be familiar with you in your business, but it has the same meaning. 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 Cant!!!. Different organizations treat this issue differently. 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 doesnt need to explain them in his/her technical spec.

b)

In organizations that dont 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.

c)

Development
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 dont have any further queries. At that point the technical spec is ready for developers to code.

QA
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 executeincluding 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 system). 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, lets first define QAs 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 clients 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: 121- DMAIC This is a methodology of six-sigma that applies within a simple performance improvement model known as Define-Measure-Analyze-Improve-Control, or DMAIC. DMAIC DMADV/DMADOV

DMAIC is also used when a product/process exists at the organization but doesnt meet customer specification or the process doesnt perform adequately 1.1Define

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 documents 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 tested/verified. 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.

N ew Pr P oc roj es ec s t/

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.3Analyze 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 systems 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.4Improve 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.5Control

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. 2- DMADV This is a methodology of six-sigma is known as Define-Measure-AnalyzeDesign-Verify or DMADV and is used when: 1) a product/process doesnt exist at the company and one needs to be developed 2) The existing product/process exists and has been optimized and still doesnt 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 organizations 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 customers 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 clients 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 Define-Measure-AnalyzeImprove-Optimize-Control.

The table below illustrates the DMADV and SDLC mapping.

Data Gathering & Business Requirement Technical Specification

Development

QA

Define

Measure

Analyze Design specification Capabilities design

Design Develop based on the design Architecture DB design

Verify Validate the system Test plans*

Project planning and project management Start up the project Date gathering Business Requirement

* Test plans can be written in the Data Gathering & Business Requirement, Development or QA stage. That depends on the organization policy

DMAIC vs DMADV
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:

10