Introduction

n  The Software Development Life Cycle is the process of developing information systems through investigation, analysis, design, implementation, and maintenance.

n  An SDLC includes:

1. Planning
2. Problem solving
3. Co-ordination
4. Control
5. Division of labour.

Objectives of SDLC

n  Ensure the delivery of high quality Softwares;

n  Provide strong management controls;

n  Maximize productivity

Phases of SDLC

1. Problem Initiation
2. Feasibility Study
3. Analysis
4. Design
5. Development (Coding)
6. Testing
7. Implementation
8. Maintenance & Support

1. Problem Initiation

Problem Initiation includes define necessary input, output, storage etc. Define what the problem really is. State a goal to be achieved
A problem initiation will describe:

• required input (what data has to be acquired to produce the output?)
• required output (i.e. what information is the system supposed to produce?)

Problem analysis breaks the problem down into its parts and describes them. Note that this step does not care what solution will be used to solve the problem. The analysis lays down the basic requirements that the eventual solution must achieve (a logical design).
During problem initiation, one of the first things to do is to define the problem correctly. If you get this wrong (or skip it completely) everything you do afterwards could be a complete waste of time and money.

The most important task in creating a software product is extracting the requirements. Customers typically know what they want, but not what software should do, while incomplete, ambiguous or contradictory requirements are recognized by skilled and experienced software engineers. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.

Problem Initiation is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.

2. Feasibility Study

Determining whether a problem is worth fixing involves a feasibility study. The aim of the feasibility study is to understand the problem and to determine whether it is worth proceeding. There are five main factors to be considered:

• Technical feasibility - investigating whether the technology exists to implement the proposed system, or whether this is a practical proposition.
• Economic feasibility - has to do with establishing the cost-effectiveness of the proposed system - if the benefits do not outweigh the costs, then it is not worth going ahead.
• Legal feasibility - determines whether there is any conflict between the proposed system and legal requirements - for example, will the system contravene the Information Privacy Act?
• Operational feasibility - Operational feasibility is concerned with whether the current work practices and procedures are adequate to support the new system. It is also concerned with social factors - how the organisational change will affect the working lives of those affected by the system.
• Schedule feasibility - looks at how long the system will take to develop, or whether it can be done in a desired time-frame.

3. Analysis

Consider the Analysis phase like a visit to the doctor. You would be pretty worried if you told the doctor you had a headache and the doctor immediately started merrily injecting you with various things before even looking at you or asking you any questions. Such behaviour is likely to cause more problems than it solves, so doctors always analyse their patients - observing, questioning, testing - before beginning any treatment.
So also do problem solvers study the system they intend to change, and the organisation it's in, before they decide what needs to be done. By thoroughly understanding a system, its operation, its context, its strengths and weaknesses, one can better decide how to start improving it.
There's not much good getting heavily into a project if the whole thing is a silly idea to start with. The preliminary investigation is an early test of whether the project should even be started.

4. Design

The finished design of a solution should contain:

• data structure (e.g. field names, data types and lengths, filenaming, folder structure schemes etc).
• how the data is to be acquired (what procedures and equipment will be needed?)
• data input procedures and equipment (e.g. keyboard? barcode reader? ICR/OMR?)
• interfaces (e.g. what will a data entry screen look like? Will people need to leave the main screen to access functions? How will menus be organised into commands and submenus? What shortcut keys will be used? Will you use a text box, listbox, combo box, tickbox for a particular item of data entry? What colour scheme will be used? What navigation scheme will be used? What icons represent what meaning? Will the layout of the data entry form help users enter data in the required order and the required format?
• control procedures - What validation rules will be used on what fields to check for data reasonableness, existence or format?) What will different error messages say? How can output be checked for accuracy (e.g. an average can be compared with the data items from which it was calculated). How can procedural errors or problems be detected? (e.g. an order may be cross-checked against the stock database to ensure the ordered item is in stock, or whether it needs to be backordered and the potential customer notified of the delay)
• what workloads and capacities the system must be capable of - e.g. storage capacities, number of transactions per hour, disaster-recovery abilities
• documentation and training requirements for different types of users
• validation and storage methods to be used
• how to produce the output (i.e. processing actions)
• procedures to be followed to use the solution
• backup requirements and procedures - what needs to be backed up, how often, how backups are stored, what backup scheme will be used?
• how the solution is to be tested to ensure it works properly - what needs to be tested? Functionality, presentation, usability, accessibility, communication of message. How will you test?

A  data flow diagram, is used to describe the flow of data through a complete data-processing system. Different graphic symbols represent the clerical operations involved and the different input, storage, and output equipment required. Although the flow chart may indicate the specific programs used, no details are given of how the programs process the data.
Gantt Charts is detailed timeline of events in a project laid out. In short it is a schedule of  Software Development Life Cycle.

Structure chart consist of a top-down description of a process and its sub-processes.

Data Dictionary - describes (for example) a database's fields, types, lengths, validation rules, formulae.