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.