We have been getting very good feedback from audience of this blog. Even experienced readers convey that they refer this to their team members, to learn complex things in simpler way. Thanks to all.

Software Development Life Cycle

The Various activities which are carried out when developing a software are commonly termed as a software Development Life Cycle (SDLC). The software development life cycle begins with the identification of a need for software and ends with the formal testing of the developed software against the requirements.

A software project is made up of a series of phases; most software projects comprise the following phases:

Inception Phases
Requirement Analysis Phase
Design Phase
Coding Phase
Testing Phase
Implementation Phase
Maintenance Phase

Inception phase

Request for proposal

The first initiative that happens for the development of a software product, is the need for someone to automate or computerize their system, e.g. a bank willing to automate its day to day activities. When the need is felt by the concerned unit, they will give a formal advertisement in the media that they need a software product for their automation. This may be in newspapers or on internet or private letters known software development people. This process is called Request for Proposal (RFP).

In the real world it is called as tender also, in many situations. When there is a need, the state highways department may want to lay road for 100 miles, at a particular stretch. In that case they will give a tender notice in newspapers inviting people to give their proposals. RFP is a similar one. The tender may contain minimal information about the need; and it may not be sufficient for the bidders. In those cases, the sales department of a software development company will approach people to identify the needs. The sales department will keep its eyes and ears open to see any open tenders, that can fit into their business.

Proposal

When the software development company finds that there is an RFP, they will prepare a formal proposal and sent it to the concerned unit that needs the software product. The proposal will contain: Time frame in which the project will be executed, Milestones of the projects activities and the respective start and finish dates, Cost involved in the project, Number of people likely to work in the project and their skill sets, Hardware and software requirements for the project, an overall architecture of the system, the technology that will be used to develop the software, Credentials of the software development company including annual turnover, manpower, past experience in executing similar kinds of projects etc. The cost and time will be estimated by project manager or any appropriate senior person, who possesses this kind of estimation experience. The success of the project greatly relies on the accuracy of these estimates.

These details will be provided in a single document and will be sent to the concerned unit. This is called Proposal. In colloquial terms, this is called a quotation. Many Software Development Units (SDUs) will send their formal proposal to the unit, which needs the software. Obviously each proposal will differ in terms of cost, time, people etc

Negotiation

When the company receives multiple proposals from various SDUs, they have to identify a suitable SDU, which can provide the required software product with minimal cost, in a minimal time frame, through an optimal technology. To identify a particular SDU among multiple SDUs, the company, which needs the software, may call all of them or a few of them based on the credentials and other parameters stated above for further clarifications. During this process, SDUs will be asked for a lot of technical and functional clarifications and also to reduce the cost and to shorten the time frame. This happens invariably in all projects and this process is called negotiation. After one or more rounds of such talks, the company may identify a suitable SDU as the unit that is going to develop the software. In this process, both the company that needs the software and the identified SDU are in agreement of the terms, in terms of cost, time, technology etc.

Usually the senior management team and sales team are involved in negotiation process.

Letter Of Intent (LOI)

Once an SDU is identified, they will be given a formal letter by the company, which needs the software, stating that they are willing to proceed further in the development process. This is a pre-cursor to signing a contract. This is only an informal assurance that the deal is closed. Also, LOI alone cannot stand as the final document to start work.

Feasibility Study

Once the Letter Of Intent is given to the SDU, the SDU may send some people to the client’s place to do a preliminary research to know the feasibility of the automation. Thismay be for a shorter period. This is called Feasibility Study. In this process, the SDU will come to know about the complexities and the difficulties in implementing a computerized solution.

This study may occur even before the proposal stage, in some cases. But there is a disadvantage for the client, i.e. inviting multiple SDUs to do the feasibility study. If this happens after the LOI is issued, then it will be one SDU, that does this work in a focused manner and this will help the client in passing on the project information in a quick and efficient manner.

Contract

After the negotiation is complete, LOI is issued and the feasibility study is furnished, there will be (may be) another round of re-estimation of the cost and time. But this may not vary in many cases from the original estimates and many clients do not want any further increase in the cost or time. Then the SDU and the client will formally sign a contract, which clearly specifies the timeframe within which the project must finish, the cost involved, the technology to be used, the hardware and software setup etc. This is the commitment document that serves as the basis, throughout the project. The contract will include many clauses regarding the legalities and any other penalty charges in case the SDU is not able to keep up its promise.

There are projects, in which the time is not fixed, but the work is measured in terms of person-days and the cost will be paid on an hourly or daily basis per person. Contract usually contains many legal phrases that describe about payment terms, warranty period, dispute handling and jurisdiction, any other specific terms as agreed in negotiation, protecting the intellectual property rights etc.

Requirement Analysis phase

After the contract is signed off between the SDU and the clients, this phase is the main focus of the project managers and stakeholders. Meetings with managers, stakeholders and the users are held in order to determine the requirements.

User Requirement Specification (URS)

The SDU must now know what the client wants in the software project. To ease the process, many clients (alternate terms for clients are customers or users), prepare formal documents, which describe their need. This document will describe in detail about what is expected out of the software product, from the users perspective. This is called User Requirements Specification. This will use the same terms and nomenclature that the customer uses in the day to day business.

This is the base document for the functionality of the product. This will be prepared and reviewed by the user community, mainly by experienced users. As an example, the URS of Railways reservation system will talk about how the reservation, cancellation etc. are carried out in an actual reservation counter. The very idea is that, these are the activities that are going to the computerized and if these are properly documented, then it will be easy to proceed in the actual product development. In some countries, a few clients write this document in their native language and not necessarily in English.

Software Requirements Specification (SRS)

After the URS is defined, a team of business analysts, who are having a very good domain or functional expertise, will go to the clients place and get to know the activities that are to be automated. This includes thoroughly understanding the URS, item by item. The URS may not be in an understandable language and format, for the developers and testers. So SRS is derived based on URS, to provide clarity to the development team. If the SDU does not know what is to be computerized, it cannot develop software that satisfies the customers. So, understanding the requirements is very essential in software in software development process. Most of the times, the business analysts, together with expert users, will frame a single document, which will serve as both URS and SRS. This way, there will be only one document which will serve as a functional commitment document between the customers and the SDU.

Requirements Collection

The role of a business analyst is very vital to this process. Before we start talking to clients on project features we must know the domain well. The SME (subject matter expert) meets various people who are in charge of the day to day business activities in customer’s core business. For example, if we develop a software for an insurance agent, we must know what he/she does with customer, we must know what detail he/she collects, how they fill up forms, how they arrive at premium amount, who approves it etc. if this can be clearly documented in plain English, the same can be used for development.

The SME must collect all fillable forms, receipts, reference numbers, approval papers, etc. Also the pain areas of customer must be documented so that the same can be computerized.

The SME must talk the same language, jargons, code words, acronyms with the customer, This will create trust with users and they will exchange more information to SME. The SME must make no assumptions. If there are any open or doubtful issues, that must also be documented along with the specs as annexure. Any sample forms must be scanned and attached to the specs. Specs can contain flowcharts as well. See the example flow for a car service centre.

Before going and meeting the client, the SME must do a lot of home work and prepare a clear list of questions. The time one spends with client is very precious and we must not waste client’s time. Simple questions like a checklist will answer complex issues. Eg.

1. How many levels of approval is required for a purchase order?

2. Do you apply service tax for your services or are you exempted?

Once the SME drafts the requirements as described by the customer and end users, the specs must undergo an internal review. The project manager must review the specs. Then the same must be sent to the client for review. The review will clearly bring out the understanding level by the SME on what the customer wants. There are chances that the SME missing some of the points told by customer, or the SME understood it in a different way or the SME added something that the customer did not want/tell. Hence customer must review the specs very carefully. Once customer raises questions on the specs, SME must correct those areas and resend for review. This may take a few back and forth emails, a few telephonic calls etc. Finally when the customer says, “Yes, this what I want in the software”, ask him to send an approval email or to sign off and printed version of specs.

Design Phase

High Level Design (HLD)

Based on the SRS, now the software systems analysts will take over to convert therequirements into a usable product. In order to achieve this, the systems analysts mustdesign the application, which will help the programmers in coding. In the designprocess, the product is to be broken down in independent modules and then taking eachmodule at a time and then further breaking them to arrive at micro levels.

There are 2 different approaches followed in designing,

1) top-down approach and

2) bottom-up approach.

In top-down approach, the product is broken continuously into smaller levels till it cannotbe broken to further levels. In bottom-up approach, the smaller levels and designed firstand the used as building blocks to go to next higher level till we reach the completeproduct level.

The HLD document will contain the following items at a macro level. In HLD, the systems analyst describes what is to be done in the product. It will not go in depth into each component of the product.

• List of modules and a brief description of each module.

• Brief functionality of each module.

• Interface relationships among modules

• Dependencies between modules (if exists, B exists etc.)

• Data elements that are used by customer

• Overall architecture diagrams along with technology details.

This document is one step ahead SRS, to convert the requirement into a product. Thisis mostly a single document, for small to medium size projects. But if the application is large, then there may be multiple documents, which form the whole HLD. Each document may describe a separate module.

Low Level Design (LLD)

HLD contains details at a macro level and so it cannot be given to programmers as adocument for coding. So, the systems analysts prepares micro level design document,called Low Level Design. This document describes each and every module in anelaborate manner, so that the programmer can directly code the program based on this.There will be at least one document for each module and there may be multiple LLDs fora module, depending upon the complexity of the module.

The LLD document will contain the following sections.

• Detailed functional logic of the module, in pseudo code.

• Database tables, with all elements, including their type and size

• All interface details with complete API references ( requests and responses)

• All dependency issues between modules

• Error message Listings

• Complete UI design of how each screen looks like

The HLD and LLD phases put together is called Design phase. Design must be doneonly by experienced people. Design itself has its own guidelines to be followed; most of the times, people use design patterns to find out what will be the best design for a product. Already there are many experts in the world, who have designed big products; they had published the way they designed. Instead of reinventing the wheel, we can try to reuse those already proven designs, if they fit our software.