Introduction
Software development process starts from the time the client's specifications are received by the Company. The process ends with the software package delivered to the client's satisfaction, including but not limited to source code documentation, user manual and project summary report.

Software development is a complex process. It happens as a result of contributions from the client, the company's management, system analysts, domain experts, designers and developers and document writers. It also happens because of the resources that help make it possible; hardware resources and software resources like modeling and building tools all play a significant role in the software development process.

This process combines the best of breed software processes and methodologies, which have a proven track record in the annals of software development. The Rational Unified Process has received considerable attention from the bigwigs in the software industry. But the developer community has received it with skepticism, and extends less than enthusiastic support for it. The reason is that RUP addresses the software process in a rather prescriptive way, and tends to be theoretical and ideal. There is a move from the developer community at large to have a development process that addresses developers' needs without sacrificing the stake holder's interests. The new development process paradigm envisages development in the small, iteratively increasing and refining the development model, and testing the whole process at each stage of iteration. This process is not well suited to the RUP where the modeling is done in the large, and testing is relegated to the end of the process as a single large-scale testing process by itself.

This process adopts the new technique of iterative development and testing, and so its development process is largely based on the Agile Modeling Techniques and Extreme Programming, pioneers and proponents of the new software development process.

Extreme Programming defines only four parameters to Software Process, namely, Planning, Coding, Designing and Testing.

This software development process is biased in favor of object-oriented programming, but the general methodologies are applicable to non-object-oriented systems as well.

1.0 Objective
To provide procedures and formats so that software is developed according to the process specified here.

2.0 Scope
This document describes procedures for the entire software development life cycle.

3.0 Abbreviations

Project Leader PL
Chief Technology Officer CTO
Unit Test UT
Pair Programming PP
Release Plan RP
Technical Lead TL

4.0 Software Project Requirement Specifications

4.1 Introduction
The software requirements from the client do not always come as a neatly packaged set of requirements. The requirements may begin with e-mail missives and followed up by early working drafts. The requirements are therefore likely to be incomplete, insufficient and do not address the needs in a formal manner.

The requirements may change over time and existing requirements may undergo modifications. A constant interaction with the client is necessary at this stage until the requirements are frozen and formalized. The purpose of this activity is to prepare a formal specification document for user requirements.

The specification is the base document upon which all arbitrations between the client and customer will be resolved. This specification shall be made available at the earliest, since all subsequent processes are dependent on this document. The requirements specification document will form the basis of:

a) Software analysis and design
b) The acceptance criteria
c) The Test Cases

After the requirements are formalized into a specification, the client shall ratify it, and then the specification becomes the basis for translating the requirements into software. If any changes are made to the specification after it is finalized, the changes shall be made through a change management procedure. No ad hoc changes to the document are acceptable. The change management procedure is described separately.

4.2 Procedure
· Keep a list of all the requirements in text format
All requirements must be named and numbered: Requirement #1, Requirement #2 etc. The numbers must be unique. This enables traceability throughout the process.
Use cross-references to highlight impact of one requirement on another. See format-1 below.

Maintain a list of requirement types. Requirements classified under types help avoid duplications, and similar ones easily identifiable.

The following example illustrates the point: (This example and the accompanying discussion is taken from Volere)
A functional requirement is section 9, and the next unique number is 128.
Requirement #: 128 Requirement Type: 9
We shall record the time when we are notified of a truck breakdown

A performance requirement comes from section 12, and the next unique number is 129.
Requirement #: 129 Requirement Type: 12
Truck drivers shall be informed of their schedule 30 minutes before leaving the depot.

It is necessary to associate a use case (or user story) with a particular requirement number. This will in turn identify which solution applies to which use case.

FORMAT - 1
Requirement # Requirement Type Requirement cross-references Use Case # Comment
129 12 5 3 Transport

· Maintain a data dictionary for domain-specific terms and ordinary meaning
Data dictionary must be prepared to address the needs of conventions and specialized vocabulary of the domain. It also helps resolve requirements dependency because two or more requirements use the same naming conventions and definitions.

· Provide use case diagrams where possible
Use case diagrams must be developed and recorded to accurately reflect the client's users requirements. Each use case may address several requirements. See format above.

· Keep the requirements in the client's own words
Requirements must be recorded in the client's own words as much as possible, especially the terms related to the domain. Conflicting requirements shall be notified at the earliest and clarifications taken.

· Re-write all the requirements in a running text document
· The document must contain figures and diagrams to help clarify critical issues
· The document must be annotated with references from the requirements list where appropriate
· The working specifications draft document shall be sent to the client for review
· Finally, the document will be circulated among TLs after approval from the client
· This part of the activity shall be initiated by the CTO and completed with the client representative and the PL
· Keep a history of all requirements. All requirements changes must be recorded. A deleted requirement must be dated and the reason for deletion recorded.

See FORMAT-2 below.

FORMAT - 2
Requirement # Requirement change date Requirement change Requirement cross-references Use Case # Comment
129 12/3/2001 Modified 5, 34 3 Change has cascading effect on dependent requirements
23 3/22/2002 Deleted 3 5 Minor

Here is list of terms and definitions from Volere that are part of requirements specifications. Feel free to add to a particular specification document.

Client
The person or organization for which the product is being built, usually responsible for paying for the development of the product.
Customer
The person or organization who will buy the product (note that the same person/organization might play both the client, customer and sometimes user roles)
Design or Systems Design
Crafting a solution to fit the requirements.
Developers
The people who specify and build the product.
Non-Functional Requirement
A property that the eventual product must have.
Functional Requirement
An action that the product must be able to take, something that the product must do.
Global Constraint
Constraints that apply to the system as a whole.
Product
This is what we are attempting to deliver. This could be a piece of software, the installation of a package, a set of procedures, a piece of hardware, a piece of machinery, a new organization, or almost anything.
Requirement
A measurable statement of intent about something that the product must do, or a property that the product must have, or a constraint on the system.
Stakeholder
A stakeholder is a person who can affect the outcome/success of the project and/or is affected by its outcome/success.
System
The business system whose requirements are being studied.
Systems Analysis
Detailed study of the requirements, intended to prove their workability as input to systems design.
Use case
We use the term event-driven use case (or product use case) to mean a user-defined (or actor defined) piece of activity within the context of the product.
User or End User
Someone who has some kind of direct interface with the product.

5.0 Software Project Requirements Analysis

5.1 Introduction
The requirements analysis phase consists of what the software system must accomplish, not how. This is the basis for design. The requirements may be in the form of plain text, but usually an artifact called a use case or a user story is developed and documented as diagrams. The user stories typically specify how the user views the system. It is the first step in the GUI design.

A user story is therefore the user's perspective of the software system. The user's requirements are captured as user stories or use cases. The first step in analysis is the identification of user stories and factoring out user abstractions from a high level of system design.

5.2 Procedure
· Prepare use cases or user stories.
Use cases provide the user perspective of the system. A use case typically is the basis for the user interface design. The use case tells the designer what he wants to see on the screen and what input and output the user expects from the system. Use cases may be developed using UML, the industry standard notation for developing the use case scenarios. One may also work with user stories from the Extreme Programming methodology. But all such user stories shall be eventually converted to UML notation.
· Use RAD tools, if necessary, to develop a prototype
Use a rapid application development tool like Visual Basic to capture the user interface designs expected by the user as described in the use cases. The prototypes shall be forwarded to the client for review. Send screen shots to client for user interface confirmation.
· Identify resource and manpower requirements
Resource identification is the next step in the process. List the tools and re-usable software necessary for the project. The tools and the software may be developed in-house or from a third-party. Analyze the system requirements and the number of persons to be deployed for the job. Keep the system to person ration as close to one as possible. Where necessary, you may resort to pair programming.
· Develop a resource plan
A resource plan consists of the number of systems identified for the project. All system must be of the right configuration and with all the needed software installed for the project. The planning involves the time estimated to keep the systems busy for the duration of the project.

Use the following format to plan the resources.

FORMAT - 3
System Configuration Software & tools needed Number of persons (1 or 2) with names Module name to be developed Duration required ) in days or months) Remarks

6.0 Software Project Risk Analysis

6.1 Introduction
Risk assessment is important in many respects. The stakeholder must be informed of the attendant risks the use of the software is likely to entail. The risk also involves the lack of availability of resources during the development phase of software. The resources may be hardware elements like systems and network, software units like dependent off-the-shelf-components or manpower.

It is possible that any one or all of these may fail at a time when the development plan can least afford it. Due care is taken with fallback arrangements.

6.2 Procedure
· List resources needed
· Plan manpower requirement
· Make alternative arrangement plan
· Provide flexibility in plan so that people can be moved without difficulty
· Plan for manpower absenteeism and resignations

XP advocates a spike solution:
Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate.
When a technical difficulty threatens to hold up the system's development put a pair of developers on the problem for a week or two and reduce the potential risk.

7.0 Software Project Design

7.1 Introduction
High-level system architecture is developed to depict the various modules that comprise the system. This architecture is decomposed into fine-grain modules until atomic objects are identified. The objects are arranged so that interactions, collaborations and object containments are shown diagrammatically. This represents the object diagram, and the activity is known as Object Modeling.

A technique to identify the classes that make up the system is using the CRC cards. It stands for Class-Responsibility-Collaboration. Each class is noted in a card along with other classes that associate with it and the responsibilities assigned to it.

Here's a tip from XP:
Use Class, Responsibilities, and Collaboration (CRC) Cards to design the system as a team. The biggest value of CRC cards is to allow people to break away from the procedural mode of thought and more fully appreciate object technology. CRC Cards allow entire project teams to contribute to the design.

Data Modeling refers to the database design document comprising the Entity-Relationship (E-R) diagrams. The database design is done independently of the object model, but a fair amount of overlapping is inevitable, even necessary to provide some kind of mapping between the objects and database entities.

7.2 Procedure
· Develop a high level architectural view of the system
Partition the requirements into business logic modules that form the coarse-grained components of the system. Separate the elements that are constant from the elements that change. Take a rough cut at factoring out the system so that user interface modules are separate from the business processing modules. Show how the system is likely to interact with the Operating System and hardware on the one hand and the outside world on the other.

Use standard architectural design patterns for depicting the system data flow and processing components at a high level.

Use the appropriate model from the following, but not limited to it.
o Pipeline
o Whiteboard
o MVC
· Model the entities using the class diagrams with UML notation
Break up the high level structure into more manageable modules to reflect the functional requirements of the system. It is time to prepare the object graph. Use the UML notation. Show the sequence diagrams for object interactions. The objects themselves need not yet be fine-grained. As the first step after the architectural view, this decomposition aims to group requirements into functional modules.
· Draw the sequence diagrams
The sequence diagrams of UML present the sequence of operations of use cases. Take each use case and draw the sequence diagram for it. Gaps in the sequences highlight the need to get some more information on the subject.

A diagram fully explains to the program coder the algorithm to develop in order to achieve functionality.

· Complete the object model showing the object relations (cardinality), object containment (dependency) and object grouping (package)
· Check that all the classes adequately represent the requirements in the abstract level
· Design the database with E-R diagrams
· Provide object-relational mapping where possible

8.0 Software Project Plan

8.1 Introduction
According to the principles of Extreme Programming, the project development plan involves scheduling periodic releases of software. It is known as Release Plan. This has the benefit of incremental development; at the same time, the client is kept informed about the progress and the outcome of the software as it evolves over time.

Iterations are the mechanisms that enable incremental development. At each iteration, the system is run, tested and staged at the development location.

The progress charts are displayed as GANTT charts that indicate project milestones including the release plans.

8.2 Procedure
· Break the whole system into three parts - the user interface, the server side and the database persistent store
· List activities in each part
· Prioritize the activities
· Schedule the activities in a bar chart
· Schedule the incremental releases
· Assign manpower
· Commit resources
· Make sure all the procedures, formats, design diagrams and developmental tools are available before start of the project

9.0 Software Construction

9.1 Introduction
The construction phase of software typically begins with the object and data model diagrams. The tasks are allocated to the programmers. Each programmer is expected to develop a flow chart for the algorithms used in the program logic. A software versioning system is used to track the incremental changes to the software. The quality of software under construction is checked from time to time and at each iteration and before the planned release.

9.2 Procedure
· Allocate work to developers by assigning tasks. Follow the object model for task assignment.
· Get the utilities and related components developed first.
· Prepare test cases before the component is actually developed. Follow the test procedures outline under the software testing section below.
· All software developed must follow the coding conventions described in this document
· Every developer shall draw a flow chart of the algorithm he or she is going to use before actually writing the code.
· PL shall check each flow chart and approve for code development.
· Follow the code versioning system as described in this document.

9.3 Code Versioning System
This is the most important activity from a developer perspective. Follow any system as long as it achieves the purpose in an efficient way.

A suggested versioning system is the CVS, but it is designed especially for developers who are geographically distanced from each other, and who often have to modify the code independent of each other. But a simpler solution is possible, one that can evolve over time and scale to accommodate simultaneous updates to code.

A single computer dedicated to sequential releases works really well if the development team is co-located. This computer acts as a physical token to control releasing. There is also a place for developers to go to see the final word on what system configuration is current. Developers have a source for final arbitration on integration problems. The computer allows developers to see who is releasing and when. When the release computer is occupied no other changes can be released, stability is ensured.
The latest combined unit test suite can be run before releasing. Because a single computer is used the test suite is always up to date. If the unit tests run at 100% the changes are released, if they fail the changes are debugged or backed out and debugged at the developers workstation.

10.0 Software Project Monitoring

10.1 Introduction
Project is monitored via the project's stated goals. The goals are the planned releases as per the project plan. The release plan schedules the periodic small releases of the software. The Microsoft Project Management tool does project monitoring.

10.2 Procedure
· List Milestones
· List assigned tech leads (TLs) against each milestone
· Check ETDs (Earliest Time of Delivery)
· Prepare progress charts
· Take out Management Information Report every week
· Monitor progress and track changes as a bar chart

11.0 Software Project Change Management

11.1 Introduction
Changes to the requirements are normal and happen almost always. Such changes are recorded in a pre-defined format. The document passes through all concerned and is finally approved by the approving authority.

The changes may be in user interface design, or they may be such that far reaching effects may be produced on the core application design. No matter what impact a change may have on the system, all changes are tracked, recorded and assessed for cost and time overruns.

11.2 Procedure
· Prepare a change request
· Validate that the requester is authorized to make changes to the system
· Apprise the CTO and debate the implications with the PL
· Bring out an assessment sheet on the impact that change is likely to have on the project
· Schedule change implementation
· Monitor change progress
· Prepare a change closure report after the change has been satisfactorily implemented

12.0 Software Implementation

12.1 Introduction
Implementing the software in a particular language is usually part of the requirements specification. Sometimes, though, the client leaves the implementation specifics to the developer, but gives a few guidelines on which the developer may base his/her decisions.

If an application that must run on all platforms, irrespective of the underlying OS, then Java is the natural choice. But one may consider the .NET platform also and code in C#, if the client wants to run the software in Windows only environment. A standalone system for a Windows platform might call for Visual Basic, but one can leverage the power of C++ on Windows from Microsoft VC++. As stated earlier, the choice is usually dictated by the application use, and the kind of platforms in question.

Once the implementing language is decided, check out if there are any tools to automate much of the plumbing code necessary in most applications. Follow the coding standards, and document the code as you write it.

12.2 Procedure
· Check requirements if a language is specified
· Where is the application going to run? In a PC? On a network?
· How is the application going to run? As a standalone system? As a web application? As a networked application?
· Use OOAD, for C++ and Java
· Use traditional programming paradigms for VB and C.
· Develop flow chart for the algorithm to be used in the programs
· Check out dependency code
· Document the code
· Factor out commonality into methods and classes, if necessary
· Clock the code and list LOC against each program.

13.0 Software Coding Standards

13.1 Introduction
Coding standards are meant primarily for two reasons:
· Code readability
· Code maintainability

The standards presented here are adapted from the Java coding standards, but applicable to a wide variety of programming languages.

13.2 Terminology
The terms used to explain a feature or specify a rule are generally biased towards object-oriented programming, but the following will help clarify the situation.

OO Term Procedure-oriented Term
Method Procedure, Function, Sub routine
Identifier Variable (scalar, or complex)
Package Module
Class <No procedural equivalent>

13.3 Procedure
13.3.1Naming Conventions

Names of variables, methods and classes must reflect the use of the variable, method or class in the context and the domain of the problem space. If we are developing an accounting software, we may declare and use the following:

· Variables
o amount, balance and so on.
· Methods
o displayAmount(), checkBalance(),isCheckingAccount() etc.
· Classes
o Account, SavingsAccount, CheckingsAccount

Note the use of uppercase letters to indicate beginning of a new word. Variables and method names begin with a lowercase letter, while a class name always begins with an uppercase letter.

The names here are taken from the problem space, that is, from the system we are going to develop. Software artifacts like data structures must also follow similar conventions. For instance, a specialized collection of accounts class may be named: AccountsCollection or AccountStore etc.

13.3.2 Documentation
Every variable, method and class must be accompanied by text indicating the purpose. Scratch variables whose scope does not extend a method must be declared as such. All global identifiers must be preceded with adequate description of use and purpose. No program shall pass the test unless documented properly. The programmers may employ appropriate tools to generate document templates where necessary.

13.3.3 Indentation
There are tools available that indent code after it is written. There are tools for almost all modern languages. But it is the responsibility of the programmer to writer properly indented code from the beginning.

13.3.4 Providing access
No identifier, method or class shall be devoid of access specifier. All access is private by default, and public access is provided only where necessary.

14.0 Software Testing

14.1 Introduction
Software testing usually means testing the application against requirements. The requirements are not always clear, and some may be implied like for instance response time. By software testing we mean,

a) Functional Testing b) Performance Testing c) Validation Testing d) Acceptance Testing

Portions of this section are excerpted and adapted from the web site ExtremeProgramming.org where it is found to be relevant and immediately applicable to the developer environment.

According XP, unit tests are one of the corner stones of Extreme Programming (XP). First you should create or download a unit test framework to be able to create automated unit tests suites. Second you should test all classes in the system. Trivial getter and setter methods are usually omitted. And last you should try to create your tests first, before the code.

14.2 Procedure

1. Prepare a Test Plan
2. Prepare Test Cases
3. Build a Test Harness
4. Develop Test Units
5. Check out Test Tools

Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release. Acceptance tests are created from user stories. During an iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests. The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, what ever it takes to ensure the functionality works.

Unit Testing Framework can help you formalize requirements, clarify architecture, write code, debug code, integrate code, release, optimize, and of course test. It is worth the effort to create your own unit test framework because you will understand it better and be able to tailor it to your own needs. Most languages already have a unit testing framework available for download from XProgramming.com. Use this free version as a starting point. See how it works, then create your own. The team must claim ownership of the unit testing framework and be able to change any part of it. JUnit is quickly becoming the standard for unit testing in Java. At the very least refactor JUnit to make it your own and understand how to extend it.

/********************************************************************************
This is an evolving process. A great many inputs have gone into making it. It is the intent of the author to present a consistent cohesive adaptable and practical process model which can be readily applied to any software development process.
*******************************************************************************************/