Sunday, October 28, 2007

Software Development Life Cycle Process

This blog is a basic summary of the SDLC models and what goes inside them.

On 30,000 foot level they are typically two models which philosophically differentiate they are as follows-

1. Water Fall Model

2. Iterative Development - You can group (Agile Development, Xtreme Programming, Test Driven Development, Scrum) which are just variations of iterative development into this. We will provide the subtle differences in thew process as we move into those areas.

1.Water Fall Model
This is a model which teaches up front design. You are required to complete each phase before moving onto the next phase. Basic Phases of this model are as follows-

a. Requirements specification
You will have to do a detailed Requirements analysis like creating Vision and Scope Document, Use Case Document and Software Requirements Specification Document.

I have an entire blog which talks about RA process.

b. Design Phase

You will have an
  • Application Diagram (Diagramming each substem components like Windows DLL/WebService/Web Application),
  • Logical Data center Diagram(This goes into how the application components are going to be deployed).
  • Class Diagram (Create Visual Studio Solution, Create Sub Projects, Create Classes, Create tiers like Business Layer, Data Layer etc)
  • Database Design Document, Stored Procedures

c. Development

  • Create a Task List of all activities
  • Assign the task list to team members with the schedule of completion.
  • Unit Tests have to be created and Development has to begin.
There is a separate blog on Project managements.

d. Testing and debugging (AKA validation)
  • start the usability testing.
  • Smoke and mirrors testing

e. Installation

  • Istallation requirements document will have to be created and sent to the installation team.
  • Installation program will be created incase of a shrink wrapped application.
  • If not the IT will have to follow the installation document and install the solution.

f. Maintenance
  • Bug determined after release are fixed in this phase.
  • Additional requirements ofter overlooked are taken care here.

  • Works best for small projects.
  • Each Phase you have set of of deliverables which have to produced.

  • Excessively wastage of time in the Requirements Analysis Phase and Design Phase. 1/3rd of the project is done before we move out of this phase.
  • Changes might kill this project

2. Iterative Development

Iterative development is basically Waterfall model with faster cycles. You attack a problem in a piecemeal manner.

You have 4-6 week cycles you run through the cycles very fast. Then outcome is a production level code in the end of 6 weeks.

Xtreme Programming has the concept of Pair Programming which is great for medium sized development teams. For Small teams 3-6 it is better to have the Lead Engineer as the dedicated Pair Programmer,
Test Driven Development- Is a subset of XP with unit tests written before development.
SCRUM- Underlying concept is cycles- Teams are split into - 30 day cycle, Sub divided into 7day cycle and further divided into 1 day cycle.
Entire Team meets every 30 days and comes up with things to do for that month. Sub groups meet every week and comes up with things to do for that week. This extends to the day.

Saturday, October 27, 2007

Water Fall Model

Basic Tenets of Waterfall model are as follows-

1. Requirements specification
2. Design
3. Development
4. Integration
5. Testing and debugging (AKA validation)
6. Installation
7. Maintenance

This is the central idea behind Big Design Up Front (BDUF) and the waterfall model - time spent early on making sure that requirements and design are absolutely correct will save you much time and effort later. Thus, the thinking of those who follow the waterfall process goes, one should make sure that each phase is 100% complete and absolutely correct before proceeding to the next phase of program creation.

Program requirements should be set in stone before design is started (otherwise work put into a design based on "incorrect" requirements is wasted); the program's design should be perfect before people begin work on implementing the design (otherwise they are implementing the "wrong" design and their work is wasted), etc.

Requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time.") To take an extreme example, if a program design turns out to be impossible to implement, it is easier to fix the design at the design stage than to realize months later, when program components are being integrated, that all the work done so far has to be scrapped because of a broken design.