Lifecycle of Project Development.

Here are common steps in the process, which may vary according to the size of th
e project.
Definition
Requirements
Client supplies a project requirements document, which states:
* The purpose
* Goals
* Major features
* Compatibility issues
* Human interface issues
* Maintenance and support
* Documentation and training
* Terms and conditions for the project
Depending on the completeness of this document, vendor(s) involved in the propos
al process may need to make inquiries and revisions to it before it becomes an a
dequate basis for a bid.
Analysis Proposal
If required, the out-sourcing vendor supplies this. It should include:
* The scope of the project
* Cost and time estimates
* A basic project plan
* A definition of deliverables
* Acceptance criteria
* Any terms and conditions required
* Any assumptions used to make the proposal
This document may not be required if the project is fairly small or if the clien
t has already created a technical specification that is adequate to make a Devel
opment proposal on.
Executed contract
Frequently, the client requests revisions to the proposal. Once those are agreed
upon and the proposal is accepted, the contract is drawn up and executed. This
document should include:
* Delivery date
* Deliverables
* Terms and conditions concerning non-disclosure
* Intellectual Property Rights
* A clear description of each party's responsibilities
* Functional specification provided by client
* The price
* Payment terms
Pricing is usually on either a fixed-price or time-and-materials basis. The vend
or meets milestones upon final acceptance by the client.
Payment terms for time-and-materials contracts are variable with weekly to month
ly invoicing and terms of net 10 to net 30.
Preliminary Project Plan
The project plan is created by whoever is managing the project. It should includ
e:
* A work breakdown
* The sequence of events (usually a PERT chart)
* A project schedule
Both the client and the vendor should sign off this document.
Analysis
Functional Specification
Through interaction with the client, the vendor creates this document. It should
contain:
* An overview of the system/application
* Major objectives and any special system requirements
* A description of all components and deliverables
* A method for negotiating specification changes
* Acceptance criteria
* Client-vendor communications interfaces
* Responsibilities of both parties, and any terms, conditions and assumpti
ons
Both parties should sign off the Functional Specification.
Preliminary Design
The Preliminary Design should include:
* A high-level design of the system/application as a whole
* A description of user-interaction, data-flow, and data storage
Project Plan revised
Update project plan to reflect the information in the functional specification a
nd changes in available resources and technology.
Development Proposal
Final versions of analysis proposal
Executed contract
See Executed contract, above.
Design
Design Specification
Once the vendors devise a set of alternate top-level designs, the vendors should
take the clients through a walk-through. Once this walk-through is complete, th
e vendor should complete the design process and create a Design specification.
This specification should include:
* An overview
* System requirements
* Design priorities
* Diagrams and naming conventions
* Parameter passing and database conventions
* Error handling
* Programming tools
* Descriptions of data records and storage
The specification should include all of the functionality stated in the Function
al Specification.
Quality Assurance Test Plan
This test plan should include:
* Alpha entry criteria
* Beta entry criteria
* Final Code Submission criteria
* Acceptance criteria.
It can include more than one Alpha or Beta cycle and other intermediate cycles s
uch as Gamma.
Project Plan revised
Update project plan to reflect the information in the design specification and a
cceptance plan.
Development
Alpha entry
Criteria for alpha entry should be agreed upon by client and vendor.
Quality Assurance for Alpha submission
* QA is usually supplied by the vendor
* Quality Assurance engineers follow the Acceptance test plan and report b
ugs to the development engineers
Bug fixes and minor feature enhancements
Development engineers fix bugs reported by QA and by the client. Minor feature e
nhancements, as agreed upon by client and vendor are incorporated.
Beta entry
Criteria for beta entry should be agreed upon by client and vendor.
Quality Assurance and Beta site testing
* QA is usually supplied by the vendor
* Quality Assurance engineers follow the Acceptance test plan and report b
ugs to the development engineers
* QA engineers also do regression testing to insure previously reported bu
gs are fixed
Bug fixes and minor feature enhancements
Development engineers fix bugs reported by QA and by the client. Minor feature e
nhancements, as agreed upon by client and vendor are incorporated.
Final code submission
Criteria for final code submission should be agreed upon by client and vendor.
Acceptance
Acceptance testing
Acceptance testing as specified in the QA test plan is performed by the client,
possibly with the vendor present.
Operation
Warranty-period technical support
Vendors should offer to fix problems caused by vendor free of charge for a certa
in period of time. The warranty period depends on the size of the project; howev
er, 90 days is common.
Maintenance
This is usually a separate contract, detailing any maintenance requirements incl
uding:
* Adding features
* Fixing bugs
* Giving technical support to the client
Project post-mortem
Client and vendor should get together to discuss the project. Topics usually inc
lude:
* A statement of original objectives and proposed solutions
* Project method and organization
* A comparison of estimates with actual results
* Successful aspects of the project
* Problems encountered and how to avoid them in the future
Development Plan.
In the planning stage, four documents are written, based on the specification do
cument; the data plan, the architecture plan, the interface plan and the module
plan. Each planning result is written into its respective planning document.
o The data plan
o Data structures
o Structure interfaces
o Global data
o Reference methods
o The architecture plan
o A general overview of the system
o A description of data and control flows
o Levels of abstraction
o Software architecture
o Module hierarchy
o Reference methods
o The interface plan
o Specification and planning principles for the user interface
o Specification of external interfaces (external data and equipment)
o Specification of internal interfaces according to module
o The module plan. On each module:
o The task
o The interface
o A description in pseudo language
o Reference modules
o Internal data structures
The End