Software project planning / Project planning Activities

After the project has been defined and the project team has been appointed, you are ready to enter the second phase in the project management life cycle: the detailed project planning phase.

Project planning is at the heart of the project life cycle, and tells everyone involved where you’re going and how you’re going to get there. The planning phase is when the project plans are documented, the project deliverables and requirements are defined, and the project schedule is created. It involves creating a set of plans to help guide your team through the implementation and closure phases of the project. The plans created during this phase will help you manage time, cost, quality, changes, risk, and related issues. They will also help you control staff and external suppliers to ensure that you deliver the project on time, within budget, and within schedule.

The project planning phase is often the most challenging phase for a project manager, as you need to make an educated guess about the staff, resources, and equipment needed to complete your project. You may also need to plan your communications and procurement activities, as well as contract any third-party suppliers.

The purpose of the project planning phase is to:

1. Establish business requirements
2. Establish cost, schedule, list of deliverables, and delivery dates
3. Establish resources plans
4. Obtain management approval and proceed to the next phase

Software project management begins with a set of activities that are collectively called project planning. The objective of software project planning is to provide a frame work that enables the project manager to make some reasonable estimates of resources, cost, and schedule. There are 3 steps in the software project planning.

 1. Software Scope

Software scope describes the functions and features that are to be delivered to end users; the data that are input and output; the “content” that is presented to users as a consequence of using the software; and the performance, constraints, interfaces, and reliability that bound the system. Scope is defined using one of two techniques:

1. A narrative description of software scope is developed after communication with all stakeholders.
2. A set of use cases3 is developed by end users.

2. Feasibility 

Once the scope of the software has been identified, you need to study whether the project is worthwhile to design within the determined scope.

3. Resources Estimation 

Once the scope and its feasibility study is completed, the next step in software project planning is estimation of resources that are required to develop the new project. The resources are represented as follows

Each resource is specified with four characteristics:

1. Description of the resource,
2. A statement of availability,
3. Time when the resource will be required, and
4. Duration of time that the resource will be applied.

a) Human Resources

The planner begins by evaluating software scope and selecting the skills required to complete development. Both organizational position (e.g., manager, senior software engineer) and specialty (e.g., telecommunications, database, client-server) are specified. For relatively small projects (a few person-months), a single individual may perform all software engineering tasks, consulting with specialists as required. For larger projects, the software team may be geographically dispersed across a number of different locations. Hence, the location of each human resource is specified.

The number of people required for a software project can be determined only after an estimate of development effort (e.g., person-months) is made.

b) Reusable software resources

Reusability of software resources is very important in the software project planning. The creation and use of software building blocks must be catalogued for easy reference, standardized for easy application and validation for easy integrity. There are four software resource categories should be considered 

Off-the-shelf components: Existing software that can be acquired from a third party or from a past project. COTS (commercial off-the-shelf) components are purchased from a third party, are ready for use on the current project, and have been fully validated.

Full-experience components: Existing specifications, designs, code, or test data developed for past projects that are similar to the software to be built for the current project. Members of the current software team have had full experience in the application area represented by these components. Therefore, modifications required for full-experience components will be relatively low risk.

Partial-experience components: Existing specifications, designs, code, or test data developed for past projects that are related to the software to be built for the current project but will require substantial modification. Members of the current software team have only limited experience in the application area represented by these components. Therefore, modifications required for partial-experience components have a fair degree of risk.

New components: Software components must be built by the software team specifically for the needs of the current project.

c) Environmental Resources

The environment that supports a software project, often called the software engineering environment (SEE), incorporates hardware and software. Hardware provides platform that supports the software.