Software Project Planning

Software Project Planning

The software project management process begins with a set of activities that are collectively called project Planning. The overall goal of project planning is to establish a estimation of resources , cost and schedule. The important activity is estimation. The estimation should also define the best and worst case scenarios.
2

Estimation
A good project manager should have the ability to know what will go wrong before it actually does. And the courage to estimate when the future is cloudy. Estimation of resources, cost and schedule for a software development effort requires
experience, access to good historical information courage to commit to quantitative measures when qualitative data are all that exist.

Factors effecting the estimation

Project complexity Project Size Degree of structural uncertainty Availability of historical information Risk (measured in degree of uncertainty in quantitative estimates for resources ,cost and schedule).

Project planning task set

Define software scope Determine feasibility Resources Analysis Analyze risks Project Scheduling Tracking cost estimation.

Project Scope
functions and performance allocated during the system engineering should be assessed to establish the project scope. Scope should be unambiguous and understandable to the at management and technical level
6

To Understand Scope ...

Understand the customers needs understand the business context understand the project boundaries understand the customer s motivation understand the likely paths for change Customer communication leads to a definition of the data, functions, and behavior that must be implemented.
7

What is Scope?
Software scope describes the functions and features that are to be delivered to endusers the data that are input and output the content that is presented to users as a consequence of using the software the performance, constraints, interfaces, and reliability that bound the system. Scope is defined using one of two techniques: A narrative description of software scope is developed after communication with all stakeholders. A set of use-cases is developed by end-users. 8

Resources
People Reusable Software Components The development environment

Resources
After defining the project scope estimation of resources are required. The foundation is made by development environment which includes the Hardware and software and provide support for the infrastructure. Reusable component reduce the development cost and accelerate the delivery. People is primary resource.

Characteristics of Resources
Each of the resources is specified with four characteristic  Description of resources  Statement of availability  Chronological time that the resource required  Duration of the time that the resources will be applied The last two characteristics can be viewed time window

number skills

software tools hardware

people
location

environment

network resources

project

OTS components

reusable software

new components

full-experience components

part.-experience components

12

Analysis Concepts and Principles

A complete understanding of software requirements is essential to the success of a software project. A requirement analysis task is the a process of discovery, refinement, modeling and specification. The scope of the project is defined , refined during the software project planning , is refined in detail in analysis.

Requirements Analysis
Analysis may be divided into five areas of effort
Problem recognition(By system specification and project plan) Evaluation and synthesis Modeling Specification review

Requirement Analysis
Requirement analysis is a software engineering task that bridge the gap between system-level software allocation and software design. Communication with the customer Techniques for communication FAST (facilitate application specification technique) technique can be used. QFD(Quality function management) After this constraints , performance criteria and list of services objects.

Quality Function Deployment

QFD is quality management techniques that translates the need of the customer on technical requirements for software. It concentrates on maximizing customer satisfaction. QFD defines three type of requirements
Normal requirements(graphical display, level of performance) Expected requirements(Overall operational correctness) Exciting requirements

Analysis Principles
Each analysis method has a unique point of view. The information domain of the problem must be represented and understand. The functions that the software is to perform must be defined. The behavior of the software must be represented. The models that depicts information, function and behavior must be partitioned in a manner that uncovers details in a layered fashion. The analysis process should move from essential information toward implementation detail.

Guiding principles for Requirement Engineering

Understand the problem before you begin to create the analysis model. Develop prototype that enable a user to understand how human-machine interaction will occur. Record the origin and the reason for every requirement. Use multiple view of requirements. Prioritize requirements Work to eliminate ambiguity.

The Information domain

All software application collectively called data processing. Software is built to process data ,to transform data from one form to another form and produce output. However some of the software projects also processes events. An event represent the aspect of the system control and it is nothing than Boolean data : it is on or off.

Information Domain
Therefore ,data (numbers , characters, images) and control (events) both reside with in the information domain of a problem. So the first principle required an examination of the information domain. The information domain contains the three different view of the data and control as each is processes be a computer program

Information Domain
1) information content and relationship. (individual data and events, attributes of data and their relationship) . 2) Information flow 3) information Structure(Internal organization of various data and control item like data item organized as an array or hierarchical tree structure)

Evaluating and synthesis

The analyst must define all externally observable data objects Evaluate the flow and content of information Define and elaborates all software functions Understand system interface characteristics Uncover additional design constraints Upon evaluating current problems and desired information ,the analyst being synthesize one or more solution. It defines only what and how .

Modeling
Create a model to gain better understanding of the actual entity to be built. Software should be modeled in different manner. The model must be capable of modeling the information that software transforms ,the function that enable the transformation to occur and the behavior of the system as transformation is taking place.

 In analysis we create models of the system to be built. The model focus on the what the system must do , not on how it does it. We can make model by graphical notation that depicts information, processing , system behavior , and other characteristic as distinct and recognizable symbols. The second and third operational analysis principles requires that be build models of function and behavioral model.

Roles of modeling
The model aids the analyst in understanding the information ,function and behavior of a system, thereby making the requirements analysis task easier and systematic. The model becomes the focal point for review and therefore the key to a determination of completeness, consistency and accuracy. The model becomes the foundation for design, providing the designer with an essential representation of software that can be translated into an implementation context.

Partitioning
Large and complex problem are difficult to understand as whole. By partitioning decomposes a problem in sub problem and establish interfaces between the parts so that overall function can be accomplished. The fourth operational analysis principle suggests that the information, functional and behavioral domain of the software can be partitioned.

Essential and implementation Views

An essential view of the software requirement presents the functions to be accomplished . information to be processed without regards to implementation details. An essential data model of the data item can be represented at this stage without regard to the underlying data structure used to implement the data item.

Implementation view
The implementation view of software requirements resents the real world manifestation of processing function and information structure. In some cases , a physical representation is developed as the first step in system design. In specification we deal with the only what not how. Implementation view does not means to how. Rather an implementation of the current system.

prototyping
In some cases it is possible to apply operational analysis and derives a model of software from which design can developed. In some other cases requirement gathering is conducted ,the analysis principle are applied, and a model of a software to be built.

Techniques for prototyping

Closed/throwaway prototyping: prototype is used only as a rough demonstration of requirements. Open/existing one/evolutionary prototyping: uses the prototype as the first part of an analysis activity that will be continued into design and construction.

Prototyping tools and methods.

Fourth generation tools
Database and query language Program and application generators Very high level nonprocedural language

Reusable component
Built prototype by using a set of existing software components.

Formal Specification and prototyping Environment

Natural language specification techniques

Specification
Software engineering have been forced to work with complete , consistent and unambiguous specifications for the project. Specification, regardless of the mode through which we accomplish it, may be viewed as a representation process. Requirements are presented in a manner that ultimately leads to successful software implementation.

Specification Principles
Separate functionality from Implementation. Develop a behavior model that encompasses data and functional. Establish the context in which software operates by specifying the manner in which other system components interact with software . Establish the content and structure of a specification in a way that will enable it to be amenable to change.

Specification Principles
Define environment in which system operates. Create a cognitive model rather than a design or implementation model. The cognitive model describes a system as perceived by its user community. Recognize that the specification must be tolerant of incompleteness and augmentable. An specification is always a model an abstract of some real situation that is normally quite complex. Hence it will be incomplete and will exist at many levels of details.

Guide line for representation of Specification

Representation format and content should be relevant to the problem. Information contained within the specification should be nested. Diagrams and other notational forms should be restricted in number and consistent in use. Representation should be revisable.

Review
Review of the software requirements specification is conducted by software developer and customer. Specification forms the foundation for design and subsequent software engineering activities, extreme care should be taken in conducting the review. The review is first conduct at a macroscopic level . At this level , the reviewer attempt to ensure that the specification is complete, consistent and accurate.