Artistan Designs and stuff.....

Vision and Scope Document - ensures the project is launched effectively and that ALL parties have a common understanding of the project

Project Plan - Used to communicate the status of the project and plan activities in the Development Cycle

Scope of Work, This describes the work to be done in detail and specifies the hardware and software involved and the exact nature of the work to be done.
Location of Work, This describes where the work is to be performed. This also specifies the location of hardware and software and where people will meet to perform the work.
Period of Performance, This specifies the allowable time for projects, such as start and finish time, number of hours that can be billed per week or month, where work is to be performed and anything else that relates to scheduling.
Deliverables Schedule, This part lists the specific deliverables, describing what is due and when.
Applicable Standards, This describes any industry specific standards that need to be adhered to in fulfilling the contract.
Acceptance Criteria, This specifies how the buyer or receiver of goods will determine if the product or service is acceptable, what criteria will be used to state the work is acceptable.
Special Requirements. This specifies any special hardware or software, specialized workforce requirements, such as degrees or certifications for personnel, travel requirements, and anything else not covered in the contract specifics.
This would be something that all projects should be required to provide before starting development.

This is a fine detail of the software requirements in order to have a more defined time-line and expectations

Use Cases for documenting potential requirements of a new system or software change

Requirement Workshops - brainstorming with users of the new software before development to get requirements.

Change Control - Identifying and Implementing only the changes deemed as worth pursuing

Launching

Brainstorm potential risks. The project manager leads a brainstorming session to identify risks. Team members suggest every risk they can think of; the project manager writes the risks on a whiteboard as they come up. Brainstorming should be reminiscent of microwave popcorn: a few ideas should “pop” at first, followed by a large number being fired rapidly, slowing down to a final few “pops”. The team will generally be able to judge when the risk identification is over.
Estimate the impact of each risk. The team assigns a number from 1 (highly unlikely) to 5 (very likely to occur) to represent the estimated probability of each risk. Similarly, impact should be estimated by assigning a number from 1 (for a risk with low impact) to 5 (for a risk which, if it occurs, will require an enormous effort to clean up).
Build the risk plan. The team identifies actions to be taken to mitigate high-priority risks and creates a risk plan that documents these actions.

Problem Areas - Using the following standards/ ideas will improve the Areas Concerned.

Requirement Analysis - more defined expectations
Time Estimation - more defined expectations
Test Driven Development - Tests can then be executed after each update to the code to verify all functionality still exists
Risk Planning - Identify, Reduce, and Plan for failures in development and software.

Requirement Analysis - more defined expectations
Project Planning - more defined expectations
SOW - more defined expectations
Project Management - more defined expectations
Test Driven Development - Tests can then be executed after each update to the code to verify all functionality still exists

Saturday, January 27, 2007