Course Hand Out

Subject Name: Software Process and Project Management

Prepared by: V. Chandrasekhar, Associate Professor, CSE

Year, Semester, Branch, Regulation: IV Year B.Tech., I-Sem, CSE, R-16

UNIT -I

KEY POINTS:

• Introduction

• Characteristic of Ideal Software Process Predictability

statistical control

Measurement

• Development-process improvement

1- understanding the current status of development process

2- developing a vision of the desired process.

3- establishing a list of prioritized required actions.

4- producing a plan to accomplish these actions

5- commit the resources to execute the plan.

SAMSKRUTI COLLEGE OF ENGINEERING & TECHNOLOGY

(Approved by AICTE, New Delhi & Affiliated to JNTUH.)

Kondapur(V), Ghatkesar(M), Medchal(Dist)

Characteristic of Ideal Software Process :

Predictable: Cost estimates and schedule commitments are met with

reasonable consistency and the quality of the resulting products generally meet

user needs.

Statistical Control : To achieve better result, the development process must

be under statistical control. when a process is under statistical control, repeating

the work in roughly the same way will produce roughly the same result.

While there are some important differences, the concepts of statistical control

applied to industry are applicable to software as well.

Development-process improvement :

• First important step in addressing software problems is to treat the entire

development task as a process that can be controlled, measured, and

improved.

• To improve their software capabilities, organizations must take five steps:

• 1- understand the current status of their development process

• 2- develop a vision of the desired process.

• 3- establish a list of required process improvement actions in order of

priority.

• 4- produce a plan to accomplish these actions

• 5- commit the resources to execute the plan.

A Maturity Framework :

• The maturity framework, developed at the SEI, addresses these five steps by

characterizing a software process into one of the five maturity levels.

• By establishing their organization’s position in this maturity structure,

software professionals and management can more readily identify those

areas where improvement actions are most likely to produce results.

Initial process :

• Quality assurance. A quality assurance group is charged with assuring

management that the software development work is actually done the way it

is supposed to be done. To be effective, the assurance organization must

have an independent reporting line to senior management and sufficient

resources to monitor performance of all key planning, implementation, and

verification activities.

• Change control. To develop quality software on a predictable schedule, the

requirements must be maintained with reasonable stability throughout the

development cycle. Changes will have to be made, but must be managed and

introduced in an orderly way.

Repeatable Process :

• When the organization must develop a new kind of product, it is entering

new territory. For example, a software group that has experience developing

compilers will likely have design, scheduling, and estimating problems if

assigned to write a control program. Similarly, a group that has developed

small, self-contained programs will not understand the interface and

integration issues involved in large scale projects. These changes can be

disruptive.

• In this level, a new manager has no orderly basis for understanding what is

going on and new team members must learn the ropes through word of

mouth.

• The key actions required to advance from the Repeatable Process to the

Defined Process are:

Defined Process :

• This uncertainty stems from a lack of process definition and the consequent

confusion about the specific items to be measured.With a defined process,

we can focus the measurements on specific tasks.

• The key steps to advance to the Managed Process are:

Establish a minimum, basic set of process measurements to identify the

quality and cost parameters of each process step. The objective is to quantify

the relative costs and benefits of each major process activity, such as the cost

and yield of error detection and correction methods.

Establish a process database with the resources to manage and maintain it.

Cost and yield data should be maintained centrally to guard against loss, to

make it available for all projects, and to facilitate process quality and

productivity analysis.

Managed Process :

• The followings are two fundamental requirements to advance from the

Managed Process to the Optimizing Process:

• Support automatic gathering of process data. Some data cannot be gathered

by hand, and all manually gathered data is subject to error and omission.

• Analyzing and modifying the process by using this data to prevent problems

and improve efficiency.

Optimizing Process :

• Optimizing Process: In varying degrees, Process Optimization goes on at all

levels of process maturity. However, with the step from the Managed to the

Optimizing Process there is a paradigm. Up to this point, software

development managers have largely focused on their products and will

typically only gather and analyze data that directly relates to product

improvement. In the Optimizing Process, the data is available to actually

tune the process itself.

• With a little experience, management will see that process optimization can

produce major quality and productivity improvements.

The job pattern of an IT company engaged in software development can be seen

split in two parts:

Software Creation

Software Project Management

A project is well-defined task, which is a collection of several operations done in

order to achieve a goal (for example, software development and delivery). A

Project can be characterized as:

Every project may has a unique and distinct goal.

Project is not routine activity or day-to-day operations.

Project comes with a start time and end time.

Project ends when its goal is achieved hence it is a temporary phase in the

lifetime of an organization.

Project needs adequate resources in terms of time, manpower, finance,

material and knowledge-bank.

Software Project

A Software Project is the complete procedure of software development from

requirement gathering to testing and maintenance, carried out according to the

execution methodologies, in a specified period of time to achieve intended

software product.

Need of software project management

Software is said to be an intangible product. Software development is a kind of all

new stream in world business and there’s very little experience in building

software products. Most software products are tailor made to fit client’s

requirements. The most important is that the underlying technology changes and

advances so frequently and rapidly that experience of one product may not be

applied to the other one. All such business and environmental constraints bring

risk in software development hence it is essential to manage software projects

efficiently.

The image above shows triple constraints for software projects. It is an essential

part of software organization to deliver quality product, keeping the cost within

client’s budget constrain and deliver the project as per scheduled. There are

several factors, both internal and external, which may impact this triple constrain

triangle. Any of three factor can severely impact the other two.

Therefore, software project management is essential to incorporate user

requirements along with budget and time constraints.

Software Project Manager

A software project manager is a person who undertakes the responsibility of

executing the software project. Software project manager is thoroughly aware of

all the phases of SDLC that the software would go through. Project manager may

never directly involve in producing the end product but he controls and manages

the activities involved in production.

A project manager closely monitors the development process, prepares and

executes various plans, arranges necessary and adequate resources, maintains

communication among all team members in order to address issues of cost,

budget, resources, time, quality and customer satisfaction.

Let us see few responsibilities that a project manager shoulders -

Managing People

Act as project leader

Liaison with stakeholders

Managing human resources

Setting up reporting hierarchy etc.

Managing Project

Defining and setting up project scope

Managing project management activities

Monitoring progress and performance

Risk analysis at every phase

Take necessary step to avoid or come out of problems

Act as project spokesperson

Software Management Activities

Software project management comprises of a number of activities, which contains

planning of project, deciding scope of software product, estimation of cost in

various terms, scheduling of tasks and events, and resource management. Project

management activities may include:

Project Planning

Scope Management

Project Estimation

Project Planning

Software project planning is task, which is performed before the production of

software actually starts. It is there for the software production but involves no

concrete activity that has any direction connection with software production;

rather it is a set of multiple processes, which facilitates software production.

Project planning may include the following:

Scope Management

It defines the scope of project; this includes all the activities, process need to be

done in order to make a deliverable software product. Scope management is

essential because it creates boundaries of the project by clearly defining what

would be done in the project and what would not be done. This makes project to

contain limited and quantifiable tasks, which can easily be documented and in turn

avoids cost and time overrun.

During Project Scope management, it is necessary to -

Define the scope

Decide its verification and control

Divide the project into various smaller parts for ease of management.

Verify the scope

Control the scope by incorporating changes to the scope

Project Estimation

For an effective management accurate estimation of various measures is a must.

With correct estimation managers can manage and control the project more

efficiently and effectively.

Project estimation may involve the following:

Software size estimation

Software size may be estimated either in terms of KLOC (Kilo Line of

Code) or by calculating number of function points in the software. Lines of

code depend upon coding practices and Function points vary according to

the user or software requirement.

Effort estimation

The managers estimate efforts in terms of personnel requirement and man-

hour required to produce the software. For effort estimation software size

should be known. This can either be derived by managers’ experience,

organization’s historical data or software size can be converted into efforts

by using some standard formulae.

Time estimation

Once size and efforts are estimated, the time required to produce the

software can be estimated. Efforts required is segregated into sub categories

as per the requirement specifications and interdependency of various

components of software. Software tasks are divided into smaller tasks,

activities or events by Work Breakthrough Structure (WBS). The tasks are

scheduled on day-to-day basis or in calendar months.

The sum of time required to complete all tasks in hours or days is the total

time invested to complete the project.

Cost estimation

This might be considered as the most difficult of all because it depends on

more elements than any of the previous ones. For estimating project cost, it

is required to consider -

o Size of software

o Software quality

o Hardware

o Additional software or tools, licenses etc.

o Skilled personnel with task-specific skills

o Travel involved

o Communication

o Training and support

Project Estimation Techniques

We discussed various parameters involving project estimation such as size, effort,

time and cost.

Project manager can estimate the listed factors using two broadly recognized

techniques –

Decomposition Technique

This technique assumes the software as a product of various compositions.

There are two main models -

Line of Code Estimation is done on behalf of number of line of codes in the

software product.

Function Points Estimation is done on behalf of number of function points

in the software product.

Empirical Estimation Technique

This technique uses empirically derived formulae to make estimation.These

formulae are based on LOC or FPs.

Putnam Model

This model is made by Lawrence H. Putnam, which is based on Norden’s

frequency distribution (Rayleigh curve). Putnam model maps time and

efforts required with software size.

COCOMO

COCOMO stands for COnstructive COst MOdel, developed by Barry W.

Boehm. It divides the software product into three categories of software:

organic, semi-detached and embedded.

Project Scheduling

Project Scheduling in a project refers to roadmap of all activities to be done with

specified order and within time slot allotted to each activity. Project managers

tend to define various tasks, and project milestones and them arrange them

keeping various factors in mind. They look for tasks lie in critical path in the

schedule, which are necessary to complete in specific manner (because of task

interdependency) and strictly within the time allocated. Arrangement of tasks

which lies out of critical path are less likely to impact over all schedule of the

project.

For scheduling a project, it is necessary to -

Break down the project tasks into smaller, manageable form

Find out various tasks and correlate them

Estimate time frame required for each task

Divide time into work-units

Assign adequate number of work-units for each task

Calculate total time required for the project from start to finish

Resource management

All elements used to develop a software product may be assumed as resource for

that project. This may include human resource, productive tools and software

libraries.

The resources are available in limited quantity and stay in the organization as a

pool of assets. The shortage of resources hampers the development of project and

it can lag behind the schedule. Allocating extra resources increases development

cost in the end. It is therefore necessary to estimate and allocate adequate

resources for the project.

Resource management includes -

Defining proper organization project by creating a project team and

allocating responsibilities to each team member

Determining resources required at a particular stage and their availability

Manage Resources by generating resource request when they are required

and de-allocating them when they are no more needed.

Project Risk Management

Risk management involves all activities pertaining to identification, analyzing and

making provision for predictable and non-predictable risks in the project. Risk

may include the following:

Experienced staff leaving the project and new staff coming in.

Change in organizational management.

Requirement change or misinterpreting requirement.

Under-estimation of required time and resources.

Technological changes, environmental changes, business competition.

Risk Management Process

There are following activities involved in risk management process:

Identification - Make note of all possible risks, which may occur in the

project.

Categorize - Categorize known risks into high, medium and low risk

intensity as per their possible impact on the project.

Manage - Analyze the probability of occurrence of risks at various phases.

Make plan to avoid or face risks. Attempt to minimize their side-effects.

Monitor - Closely monitor the potential risks and their early symptoms.

Also monitor the effects of steps taken to mitigate or avoid them.

Project Execution & Monitoring

In this phase, the tasks described in project plans are executed according to their

schedules.

Execution needs monitoring in order to check whether everything is going

according to the plan. Monitoring is observing to check the probability of risk and

taking measures to address the risk or report the status of various tasks.

These measures include -

Activity Monitoring - All activities scheduled within some task can be

monitored on day-to-day basis. When all activities in a task are completed, it

is considered as complete.

Status Reports - The reports contain status of activities and tasks completed

within a given time frame, generally a week. Status can be marked as

finished, pending or work-in-progress etc.

Milestones Checklist - Every project is divided into multiple phases where

major tasks are performed (milestones) based on the phases of SDLC. This

milestone checklist is prepared once every few weeks and reports the status

of milestones.

Project Communication Management

Effective communication plays vital role in the success of a project. It bridges

gaps between client and the organization, among the team members as well as

other stake holders in the project such as hardware suppliers.

Communication can be oral or written. Communication management process may

have the following steps:

Planning - This step includes the identifications of all the stakeholders in

the project and the mode of communication among them. It also considers if

any additional communication facilities are required.

Sharing - After determining various aspects of planning, manager focuses

on sharing correct information with the correct person on correct time. This

keeps everyone involved the project up to date with project progress and its

status.

Feedback - Project managers use various measures and feedback

mechanism and create status and performance reports. This mechanism

ensures that input from various stakeholders is coming to the project

manager as their feedback.

Closure - At the end of each major event, end of a phase of SDLC or end of

the project itself, administrative closure is formally announced to update

every stakeholder by sending email, by distributing a hardcopy of document

or by other mean of effective communication.

After closure, the team moves to next phase or project.

Configuration Management

Configuration management is a process of tracking and controlling the changes in

software in terms of the requirements, design, functions and development of the

product.

IEEE defines it as “the process of identifying and defining the items in the system,

controlling the change of these items throughout their life cycle, recording and

reporting the status of items and change requests, and verifying the completeness

and correctness of items”.

Generally, once the SRS is finalized there is less chance of requirement of

changes from user. If they occur, the changes are addressed only with prior

approval of higher management, as there is a possibility of cost and time overrun.

Baseline

A phase of SDLC is assumed over if it baselined, i.e. baseline is a measurement

that defines completeness of a phase. A phase is baselined when all activities

pertaining to it are finished and well documented. If it was not the final phase, its

output would be used in next immediate phase.

Configuration management is a discipline of organization administration, which

takes care of occurrence of any change (process, requirement, technological,

strategical etc.) after a phase is baselined. CM keeps check on any changes done

in software.

Change Control

Change control is function of configuration management, which ensures that all

changes made to software system are consistent and made as per organizational

rules and regulations.

A change in the configuration of product goes through following steps -

Identification - A change request arrives from either internal or external

source. When change request is identified formally, it is properly

documented.

Validation - Validity of the change request is checked and its handling

procedure is confirmed.

Analysis - The impact of change request is analyzed in terms of schedule,

cost and required efforts. Overall impact of the prospective change on

system is analyzed.

Control - If the prospective change either impacts too many entities in the

system or it is unavoidable, it is mandatory to take approval of high

authorities before change is incorporated into the system. It is decided if the

change is worth incorporation or not. If it is not, change request is refused

formally.

Execution - If the previous phase determines to execute the change request,

this phase take appropriate actions to execute the change, does a thorough

revision if necessary.

Close request - The change is verified for correct implementation and

merging with the rest of the system. This newly incorporated change in the

software is documented properly and the request is formally is closed.

Project Management Tools

The risk and uncertainty rises multifold with respect to the size of the project,

even when the project is developed according to set methodologies.

There are tools available, which aid for effective project management. A few are

described -

Gantt Chart

Gantt charts were devised by Henry Gantt (1917). It represents project schedule

with respect to time periods. It is a horizontal bar chart with bars representing

activities and time scheduled for the project activities.

PERT Chart

PERT (Program Evaluation & Review Technique) chart is a tool that depicts

project as network diagram. It is capable of graphically representing main events

of project in both parallel and consecutive way. Events, which occur one after

another, show dependency of the later event over the previous one.

Events are shown as numbered nodes. They are connected by labeled arrows

depicting sequence of tasks in the project.

Resource Histogram

This is a graphical tool that contains bar or chart representing number of resources

(usually skilled staff) required over time for a project event (or phase). Resource

Histogram is an effective tool for staff planning and coordination.

Critical Path Analysis

This tools is useful in recognizing interdependent tasks in the project. It also helps

to find out the shortest path or critical path to complete the project successfully.

Like PERT diagram, each event is allotted a specific time frame. This tool shows

dependency of event assuming an event can proceed to next only if the previous

one is completed.

The events are arranged according to their earliest possible start time. Path

between start and end node is critical path which cannot be further reduced and all

events require to be executed in same order.

What is Capability Maturity Model?

The Software Engineering Institute (SEI) Capability Maturity Model (CMM)

specifies an increasing series of levels of a software development organization.

The higher the level, the better the software development process, hence reaching

each level is an expensive and time-consuming process.

Levels of CMM

Level One : Initial - The software process is characterized as inconsistent,

and occasionally even chaotic. Defined processes and standard practices

that exist are abandoned during a crisis. Success of the organization majorly

depends on an individual effort, talent, and heroics. The heroes eventually

move on to other organizations taking their wealth of knowledge or lessons

learnt with them.

Level Two: Repeatable - This level of Software Development

Organization has a basic and consistent project management processes to

track cost, schedule, and functionality. The process is in place to repeat the

earlier successes on projects with similar applications. Program

management is a key characteristic of a level two organization.

Level Three: Defined - The software process for both management and

engineering activities are documented, standardized, and integrated into a

standard software process for the entire organization and all projects across

the organization use an approved, tailored version of the organization's

standard software process for developing, testing and maintaining the

application.

Level Four: Managed - Management can effectively control the software

development effort using precise measurements. At this level, organization

set a quantitative quality goal for both software process and software

maintenance. At this maturity level, the performance of processes is

controlled using statistical and other quantitative techniques, and is

quantitatively predictable.

Level Five: Optimizing - The Key characteristic of this level is focusing on

continually improving process performance through both incremental and

innovative technological improvements. At this level, changes to the

process are to improve the process performance and at the same time

maintaining statistical probability to achieve the established quantitative

process-improvement objectives.

Software Quality Assurance- It guarantees a good quality software product

by following certain rules and quality standard guidelines while development.

Level-3: Defined –

At this level, documentation of the standard guidelines and procedures takes

place.

It is a well defined integrated set of project specific software engineering and

management processes.

Peer Reviews- In this method, defects are removed by using a number of

review methods like walkthroughs, inspections, buddy checks, etc.

Intergroup Coordination- It consists of planned interactions between

different development teams to ensure efficient and proper fulfillment of

customer needs.

Organization Process Definition- It’s key focus is on the development and

maintenance of the standard development processes.

Organization Process Focus- It includes activities and practices that should be

followed to improve the process capabilities of an organization.

Training Programs- It focuses on the enhancement of knowledge and skills

of the team members including the developers and ensuring an increase in

work efficiency.

Level-4: Managed –

At this stage, quantitative quality goals are set for the organization for

software products as well as software processes.

The measurements made help the organization to predict the product and

process quality within some limits defined quantitatively.

Software Quality Management- It includes the establishment of plans and

strategies to develop a quantitative analysis and understanding of the

product’s quality.

Quantitative Management- It focuses on controlling the project performance

in a quantitative manner.

Level-5: Optimizing –

This is the highest level of process maturity in CMM and focuses on

continuous process improvement in the organization using quantitative

feedback.

Use of new tools, techniques and evaluation of software processes is done to

prevent recurrence of known defects.

Process Change Management- Its focus is on the continuous improvement

of organization’s software processes to improve productivity, quality and

cycle time for the software product.

Technology Change Management- It consists of identification and use of

new technologies to improve product quality and decrease the product

development time.

Defect Prevention- It focuses on identification of causes of defects and to

prevent them from recurring in future projects by improving project defined

process

Short Type

1. What is software project management?

2. What is a project?

3. Define process.

4. List the characteristics of software projects.

5. What is contract management?

6. Difference between contract management and technical project management.

7. What is the difference between feasibility study and planning?

8. How plans, methods and methodologies differ from each other?

9. What are the types of designs in software project?

10. What are the three successive process of software project management?

11. What are the categories of software projects?

12. What are the activities of project management?

13. What is activity plan?

14. What are the elements of product descriptions?

15. What do you mean by project breakdown structure?

16. What are the steps involved in identification of project scope and objectives?

ESSAY TYPE

1. Explain the various activities covered by software project management.

2. Give an outline of step wise planning activities for a project with neat diagram.

3. Diagrammatically explain the ISO 12207 SDLC activities.

4. List the Outline of stepwise project planning.

5. For each stage of a typical IS development project list the type of personnel who

are likely to be involved.

6. Identify the data that you would collect to ensure that during execution of

project things are going according to plan.

UNIT -II

Software Management Renaissance Walker Royce The waterfall model of

conventional software management, which is still prevalent in many mature

software organizations, has served its purpose. The ever-increasing market

demands on software development performance continue. The increasing breadth

of Internet applications has further accelerated the transition to a more modern

management process known as spiral, incremental, evolutionary, or iterative

development.

A comparison of conventional and modern software development models

illustrates some of the critical discriminators in this transition. Top 10 Principles of

Conventional Software Management Most software engineering texts present the

waterfall model as the source of the conventional software management process.

Conventional software management techniques work well for custom-developed

software where the requirements are fixed when development begins.

The life cycle typically follows a sequential transition from requirements to

design to code to testing, with ad hoc documentation that attempts to capture

complete intermediate representations at every stage. After coding and unit testing

of individual components, the components are compiled and linked together

(integrated) into a complete system. The top 10 principles of conventional

software management are:

Freeze requirements before design,

Forbid coding before detailed design review,

Use a higher-order programming language,

Complete unit testing before integration,

Maintain detailed traceability among all artifacts,

Thoroughly document each stage of the design,

Assess quality with an independent team,

Inspect everything,

Plan everything early with high fidelity, and

Rigorously control source-code baselines.

Significant inconsistencies among component interfaces and behavior,

which can be extremely difficult to resolve, cannot be identified until integration,

which almost always takes much longer than planned. Budget and schedule

pressures drive teams to shoehorn in the quickest fixes. Redesign usually is out of

the question.

Testing of system threads, operational usefulness, and requirements

compliance is performed through a series of releases until the software is judged

adequate for the user. About 90% of the time, the process results in a late, over-

budget, fragile, and expensive-to-maintain software system.

A typical result of following the waterfall model is that integration and

testing consume too much time and effort in major software development

workflows. For successful projects, about 40% of resources go to integration and

testing. The percentage is even higher for unsuccessful projects. With such a low

success rate, better risk management is imperative.

Top 10 Principles of Modern Software Management While the software

industry has been evolving the management process for many years, the Internet

has accelerated the transition from the waterfall model to iterative development.

First, the Internet offers a powerful set of mechanisms for multi-site collaboration

and electronic information exchange that support iterative processes. Second,

distributed infrastructures for common architectural patterns support executable

architectures of Internet-based applications.

Web-based applications consist of many moving parts that are constantly

updated, making iterative development the process of choice.

Finally, by introducing a new set of business models, projects, and

organizations, the Internet has created a demand for incredibly rapid development

of quality applications. Iterative development processes are necessary to meet

challenging project performance goals.

Modern software development produces the architecture first, followed by

usable increments of partial capability, and then completeness. Requirements and

design flaws are detected and resolved earlier in the life cycle, avoiding the big-

bang integration at the end of a project.

Quality control improves because system characteristics inherent in the

architecture (such as performance, fault tolerance, interoperability, and

maintainability) are identifiable earlier in the process where problems can be

corrected without jeopardizing target costs and schedules.

Top 10 principles of modern software management are:

Base the process on an architecture-first approach,

Establish an iterative life-cycle process that confronts risk early,

Transition design methods to emphasize component-based development,

Establish a change-management environment,

Enhance change freedom through tools that support round-trip engineering,

Capture design artifacts in rigorous, model-based notation,

Instrument the process for objective quality control and progress

assessment,

Use a demonstration-based approach to assess intermediate artifacts,

Plan intermediate releases in groups of usage scenarios with evolving levels

of detail, and

Establish an economically-scalable, configurable process.

Where conventional approaches mire software development in integration

activities, these modern principles should result in less scrap and rework through a

greater emphasis on early life-cycle engineering and a more balanced expenditure

of resources across the core workflows of a modern process.

Demonstrations, enabled by the architecture-first approach, force integration

into the design phase. They do not eliminate design breakage, but they make it

happen when it can be addressed effectively. By avoiding the downstream

integration nightmare (along with late patches and suboptimal software fixes), a

more robust and maintainable design results. Interim milestones provide tangible

results.

The project does not move forward until it meets the demonstration

objectives. This process does not preclude the renegotiation of objectives once the

interim findings permit further understanding of the trade-offs inherent in the

requirements, design, and plans.

The Rational Unified Process, a well-accepted benchmark of a modern

iterative development process, embodies my top 10 principles.

Its life cycle has four phases:

Inception: definition and assessment of the vision and business case

Elaboration: synthesis, demonstration, and assessment of an architecture baseline

Construction: development, demonstration, and assessment of useful increments

Transition: usability assessment, productization, and deployment Each phase of

development produces a certain amount of precision in the product/system

description called software artifacts.

Life-cycle software artifacts are organized into five sets that are roughly

partitioned by the underlying language of: requirements (organized text and

UML models of the problem space); design (UML models of the solution space);

implementation (human-readable programming language and associated source

files); deployment (machine-processable languages and associated files); and

management (ad hoc textual formats such as plans, schedules, and spreadsheets).

At any point in the life cycle, the different artifact sets should be in

balance, at compatible detail levels, and traceable to each other. As development

proceeds, each part evolves in more detail. When the system is complete, all five

sets are fully elaborated and consistent with each other.

Unlike the conventional practice, the modern process does not specify the

requirements, then develop the design, then write code, then execute. Instead, the

entire system evolves throughout the process. Principles That Didn't Make the Cut

A comparison of my top 10 principles with other lists, such as the Software Project

Management Network's Best Practice Initiative or the SEI Capability Maturity

Model's key process areas, reveals several notable omissions. Requirements-first

emphasis. The most obvious difference is my apparent underemphasis on

requirements. Requirements are a means, not an end. Conventional wisdom has

over-prescribed "better requirements" as the cure for recurring project woes.

Requirements, designs, and plans should evolve together.

Detailed planning and "inch-stones." Overplanning, another misapplied

practice, is different from evolutionary planning. Early, false precision is a

recurring source of downstream scrap and rework. Inspections. Inspections are

overhyped and overused. While properly focused inspections help to resolve

known issues, inspections too often are used to identify issues and provide quality

coverage. Human inspections are inefficient, labor-intensive, and expensive.

Inspections can uncover many cosmetic errors, but they rarely uncover

architecturally-significant defects. Separate testing.

Testing is not covered by a separate principle; it is covered by all of them. A

modern process integrates testing activities throughout the life cycle with

homogeneous methods, tools, and notations. The integration of interfaces,

behaviors, and structures should be emphasized before concentrating on

completeness testing and requirements compliance.

Separate quality assurance. The much-touted concept of a separate quality-

assurance reporting chain has resulted in projects that isolate "quality police." A

better approach is to work quality assessment into every activity through the

checks and balances of organizational teams focused on architecture, components,

and usability. Quality is every team's job, not one team's job.

Requirements traceability to design. Demanding rigorous problem-to-

solution traceability is frequently counterproductive, forcing the design to be

structured in the same manner as the requirements. Good component-based

architectures have chaotic traceability to their requirements. Tight problem-to-

solution traceability might have been productive when 100% custom software was

the norm; those days are gone.

Predicting the Future Planning and expenditure allocations will continue to

shift as modern project management methods, architectural infrastructures (such as

Java 2 Enterprise Edition and Microsoft Windows DNA), and software

development processes and technology mature. Resource expenditure trends will

lead to more balance across the primary workflows as a result of increased

exploitation of standard architectural patterns and infrastructure components (less

human-generated stuff), more efficient processes (less scrap and rework), more

proficient people (in smaller teams), and more automation.

The resource allocations in Table reflect my experience in waterfall process

projects and several successful iterative process projects. These values are

deliberately imprecise; their purpose is to relate the relative trends over time. Table

"future" column provides my view on major trends that will surface in the coming

years.

Table . Expenditure allocations.

Life-cycle activity Conventional Modern Future

Management 5% 10% 12%

Requirements 5% 10% 12%

Design 10% 15% 20%

Implementation 30% 25% 14%

Test and assessment 40% 25% 18%

Deployment 5% 5% 12%

Environment 5% 10% 12%

Totals 100% 100% 100%

Several major trends will surface in the coming years: More automation of

implementation activities and reuse of commercial components will reduce

implementation activities, resulting in relatively more burden on requirements and

design activities and environments.

More mature iterative development methods and Web-based architectures

will drive deployment activities into a larger role within the life cycle. More

mature iterative development environments (process and tooling) will enable

further reduction of life-cycle scrap and rework. Because iterative development is

more challenging than the simple management paradigm presented by the waterfall

model, disciplined software management and common sense will remain one of the

paramount discriminators of software engineering success or failure.

In many software domains, a distinct line divides development and

maintenance. Future software projects (legacy system upgrades, new

developments, or some combination of the two) probably will not differentiate

much between development and maintenance.

Iterative development and the Internet are driving software engineering

toward a more homogeneous software-management framework. With most of the

software industry focusing on iterative-process frameworks, advanced

requirements and design notations, and Web-based architectural patterns, we

should see dramatic improvements in software project performance and higher

returns on organizational software technology investments.

Ten years ago, about one in 10 software projects succeeded. Consequently,

software project managers spent too much time playing defense and worrying

about risk management. Today, that ratio has improved to about 1:4, still as

challenging as batting against a major league pitcher.

As modern iterative development and supporting environments advance, the

success ratio for delivering a software project 10 years from now could improve to

1:2. Software project managers should invest more time playing offense through

success management, and organizations should continue to accelerate software

development leverage to deliver more value and new features faster and more

profitably.

1.What is strategic assessment?

2. Difference between strategic assessment and technical assessment.

3. How to identify and estimate the cost of project?

4. What is cash flow?

5. How will you find the present value of future cash flow?

6. Write short notes on cash flow forecasting life cycle?

7. What is payback period?

8. What is ROI? How it is calculated?

9. Calculate the ROI for a software project development, where the net profit is

60,000 and the total investment is 300,000.

10. How to calculate the net present value for a software project?

11. Define risk profile analysis.

12. What are the different types of cost related to project development?

13. How are risks identified?

14. What is IRR? How is calculated?

15. What are the advantages of using IRR method?

16. What is meant by project portfolio?

17. How are decision trees helpful in risk handling?

ESSAY TYPE

1. Describe how cost- benefit evaluation techniques can be used to choose the best

among competing project proposal.

2. Discus the typical product life cycle cash flows in project development.

3. Explain how project can be evaluated against strategic, technical and economic

criteria.

4. What is risk management? How the risks are evaluated in software projects?

5. Explain in detail about the Amanda’s decision tree.

6. Discuss cash flow forecasting.

7. What do you mean by cost benefit analysis? Explain the different categories of

cost in detail.

UNIT –III

Checkpoints of the process

Three types of joint management reviews are conducted throughout the

process:

1. Major milestones. These system wide events are held at the end of each

development phase. They provide visibility to system wide issues, synchronize the

management and engineering perspectives, and verify that the aims of the phase

have been achieved.

2. Minor milestones. These iteration-focused events are conducted to review

the content of an iteration in detail and to authorize continued work.

3. Status assessments. These periodic events provide management with

frequent and regular insight into the progress being made. Each of the four phases-

inception, elaboration, construction, and transition consists of one or more

iterations and concludes with a major milestone when a planned technical

capability is produced in demonstrable form.

An iteration represents a cycle of activities for which there is a well-defined

intermediate result-a minor milestone-captured with two artifacts: a release

specification (the evaluation criteria and plan) and a release description (the

results). Major milestones at the end of each phase use formal, stakeholder-

approved evaluation criteria and release descriptions; minor milestones use

informal, development-team-controlled versions of these artifacts. Figure

illustrates a typical sequence of project checkpoints for a relatively large project.

MAJOR MILESTONES

The four major milestones occur at the transition points between life-cycle

phases. They can be used in many different process models, including the

conventional waterfall model. In an iterative model, the major milestones are used

to achieve concurrence among all stakeholders on the current state of the project.

Different stakeholders have very different concerns:

Customers: schedule and budget estimates, feasibility, risk assessment,

requirements understanding, progress, product line compatibility

Users: consistency with requirements and usage scenarios, potential for

accommodating growth, quality attributes

Architects and systems engineers: product line compatibility, requirements

changes, trade-off analyses, completeness and consistency, balance among risk,

quality, and usability

Developers: sufficiency of requirements detail and usage scenario

descriptions, . frameworks for component selection or development, resolution of

development risk, product line compatibility, sufficiency of the development

environment

Maintainers: sufficiency of product and documentation artifacts,

understandability, interoperability with existing systems, sufficiency of

maintenance environment

Others: possibly many other perspectives by stakeholders such as

regulatory agencies, independent verification and validation contractors, venture

capital investors, subcontractors, associate contractors, and sales and marketing

teams Table summarizes the balance of information across the major milestones.

PLANNING GUIDELINES

Software projects span a broad range of application domains. It is valuable

but risky to make specific planning recommendations independent of project

context. Project-independent planning advice is also risky. There is the risk that the

guidelines may be adopted blindly without being adapted to specific project

circumstances.

Two simple planning guidelines should be considered when a project plan is

being initiated or assessed. The first guideline, detailed in Table, prescribes a

default allocation of costs among the first-level WBS elements. The second

guideline, detailed in Table, prescribes the allocation of effort and schedule across

the lifecycle phases.

Web budgeting defaults

First Level WBS Element Default Budget

Management 10%

Environment 10%

Requirement 10%

Design 15%

Implementation 25%

Assessment 25%

Deployment 5%

Total 100%

Default distributions of effort and schedule by phase

Domain Inception Elaboration Construction Transition

Effort 5% 20% 65% 10%

Schedule 10% 30% 50% 10%

THE COST AND SCHEDULE ESTIMATING PROCESS

Project plans need to be derived from two perspectives. The first is a

forward-looking, topdown approach.

It starts with an understanding of the general requirements and constraints,

derives a macro-level budget and schedule, then decomposes these elements into

lower level budgets and intermediate milestones. From this perspective, the

following planning sequence would occur:

1. The software project manager (and others) develops a characterization of

the overall size, process, environment, people, and quality required for the project.

2. A macro-level estimate of the total effort and schedule is developed using

a software cost estimation model.

3. The software project manager partitions the estimate for the effort into a

top-level WBS using guidelines such as those in Table.

4. At this point, subproject managers are given the responsibility for

decomposing each of the WBS elements into lower levels using their top-level

allocation, staffing profile, and major milestone dates as constraints. The second

perspective is a backward-looking, bottom-up approach. We start with the end in

mind, analyze the micro-level budgets and schedules, then sum all these elements

into the higher level budgets and intermediate milestones. This approach tends to

define and populate the WBS from the lowest levels upward. From this

perspective, the following planning sequence would occur:

1. The lowest level WBS elements are elaborated into detailed tasks

2. Estimates are combined and integrated into higher level budgets and

milestones.

3. Comparisons are made with the top-down budgets and schedule

milestones. Milestone scheduling or budget allocation through top-down

estimating tends to exaggerate the project management biases and usually results in

an overly optimistic plan. Bottom-up estimates usually exaggerate the performer

biases and result in an overly pessimistic plan. These two planning approaches

should be used together, in balance, throughout the life cycle of the project. During

the engineering stage, the top-down perspective will dominate because there is

usually not enough depth of understanding nor stability in the detailed task

sequences to perform credible bottom-up planning.

During the production stage, there should be enough precedent experience

and planning fidelity that the bottom-up planning perspective will dominate. Top-

down approach should be well tuned to the project-specific parameters, so it should

be used more as a global assessment technique. Figure illustrates this life-cycle

planning balance.

PRAGMATIC PLANNING

Even though good planning is more dynamic in an iterative process, doing it

accurately is far easier. While executing iteration N of any phase, the software

project manager must be monitoring and controlling against a plan that was

initiated in iteration N - 1 and must be planning iteration N + 1.

The art of good project· management is to make trade-offs in the current

iteration plan and the next iteration plan based on objective results in the current

iteration and previous iterations. Aside from bad architectures and misunderstood

requirements, inadequate planning (and subsequent bad management) is one of the

most common reasons for project failures. Conversely, the success of every

successful project can be attributed in part to good planning.

A project's plan is a definition of how the project requirements will be

transformed into' a product within the business constraints. It must be realistic, it

must be current, it must be a team product, it must be understood by the

stakeholders, and it must be used. Plans are not just for managers.

The more open and visible the planning process and results, the more

ownership there is among the team members who need to execute it. Bad, closely

held plans cause attrition. Good, open plans can shape cultures and encourage

teamwork.

1. List the objectives of planning?

2. What are the advantages of project scheduling?

3. Define activity.

4. What is Activity –on- arrow (AOA) and Activity-on-node (AON)?

5. What are the different approaches used in identifying activities?

6. Define a product breakdown structure.

7. What is a hybrid approach of project scheduling?

8. What is SSADM?

9. What is forward pass?

10. Difference between forward pass and backward pass.

11. Write short notes on Hammock activities.

12. Why a network should not contain dangles?

13. List the types of activity float?

14. How to shorten the project duration?

15. What is Risk management?

16. How are risk classified?

17. List the factors involved in risk planning.

18. What are steps involved in planning for risk?

19. Define a brainstorming technique.

20. Write short notes on Hazards identification.

ESSAY TYPE

1. Explain the objectives of activity planning in detail.

2. Explain the different approaches of project activities.

3. What is project schedule? Explain the stages of project schedules.

4. Explain with an example how critical path can be identified in precedence

networks.

5. Discus the network model represented by the CPM network.

6. How to formulate a network model in projects?

7. Explain the categories of risk framework.

8. Briefly explain the risk planning in project development.

9. Explain risk planning and control in detail.

10. Define hazard. How are hazards identified and analyzed?

11. Describe with an example how the effect of risk on project schedule is

evaluated using PERT.