Once the project has been formally signed off, the project manager has to carry out a meticulous planning. The project plan document has to completely describe the development process including all the managerial processes such as technical reviews, managerial reviews, peer reviews etc. We will discuss the project planning and monitoring process in detail to meet the overall objective of delivering quality product within the time and within the budget. A format for the project plan document is given which contains all the details such as estimates of effort, cost and manpower; review plan, configuration management plan, risk management plan etc.
Development Life Cycle Model
The first step in project planning is to select the suitable model for software development life cycle. Choice of a wrong model will cause irreparable damage to the project and hence sufficient thought has to be given while selecting the development life cycle model. Selection of a particular model depends on various factors such as
• The type of project—commercial or research.
• Type of the end user—IT specialist or non-IT specialist.
• Availability of clear-cut specifications.
• Risks associated with the project.
• Generic product or customized software development.
• Whether the project involves development of new technology or use of
proven technology.
The life cycle development model can be chosen based on the following guidelines:
• Projects with clear SRS: If the project has very well defined SRS and
the customer is IT-literate, the waterfall model is the right choice.
• Projects with clear problem definition but no SRS: The development
team has to discuss with the client to ascertain whether the problem
definition can be converted into a specification document fast. If the
customer is IT-literate or an existing system already exists, then the
job is easy. If the client is not IT literate, it is better to develop a
prototype and demonstrate to the users and then write the
specifications. Hence prototyping model is the right choice.
• Projects without a clear problem definition: The customer may have a
very vague idea of what is required. Or, a new concept has to be tried
out, for product development. In such a case, it is difficult to even
attempt an SRS, but the software has to be built incrementally and
checked for its features. Evolutionary development model is to be
chosen for this type of development.
• Projects without clear goals: Research projects will have a very broad
problem definition (or an over-ambitious problem definition). For
taking up such projects, the project has to be divided into phases and
requirements for each phase have to be worked out and development is to be taken up. Spiral model is suggested for this type of projects.
• Product development in a high-tech area: For product development,
that too, in Internet time, the specifications evolve in parallel with the
product development. The user feedback also needs to be incorporated
during the development process. In such a case, synchronize-and-
stabilize model is the best choice.
Execution Model
How the project has to be executed is the next question. The execution model is concerned with how and where the development has to be carried out. The software can be developed in-house or subcontracted; it can be subcontracted with on-site development or off-shore development.
• Projects with clear SRS: When the detailed specifications are available
and the waterfall model can be used for development, the project can
be executed using the off-shore execution model. To ensure that there
is no slippage on time, a strict monitoring process has to be framed and
followed. However, if the project has to be executed with a condensed
time frame (a ‘death march’ project), it is advisable to follow the on-
site execution model for better monitoring.
• Projects involving legacy systems: For projects which involve
integration with a legacy database or reengineering of legacy software,
on-site model is the best choice as remote testing will be very difficult.
• Projects for IT user industries: For projects which require a close
interaction with the client and the end users to obtain the requirements,
a combination of on-site and off-shore models has to be followed. The
prototype can be developed on-site closely interacting with the client.
After the prototype is demonstrated to the client and the feedback
obtained, the rest of the development can be done using the off-shore
model.
• Projects without clear goals: Projects, for which evolutionary
development model is to be followed, need to be executed on-site for
easy monitoring and also for risk resolution.
To summarize, off-shore development model is the best choice when the requirements are very clear and close interaction (on a daily basis) with the client or the end users is not necessary. Otherwise on-site development model needs to be chosen.
Review Planning
Most of the software projects are not reviewed well enough. Lack of planned reviews is one of the main reasons for cost and time overruns, and sometimes failure of a software project. In this section, we will discuss the various types of reviews to be conducted during the execution of the project. The review meetings have to be planned during the
The review process is carried out in the following manner:
• Form the review team.
• Prepare the agenda for each review meeting along with any
background material required.
• Circulate to all the members the background material along with the
meeting notification.
• Conduct the review meeting, sticking to the agenda and the timings.
• Resolve the issues and decide the follow-up action to be taken along
with the person responsible for each action item.
After the meeting, the project manager has to follow up on the action items and ensure that the activities are completed before the next meeting.
Specifications Review
Once the specifications are finalized, an internal review has to be done to ensure that they are complete and can be implemented. The specifications review has to take care of the following aspects: whether the SRS captures all the requirements of the user, whether the SRS meets all the internal requirements, whether the requirements can be implemented; and whether the requirements such as portability, expandability, maintainability and other quality aspects can be met. To achieve these objectives, the following review meetings should be planned:
• Internal review meetings of the development teams to ensure that all
the requirements are captured in the SRS document.
• Meetings with the quality and test teams to ensure that the SRS is as
per the quality standards of the organization and also to ensure that
based on the SRS, an Acceptance Test Plan (ATP) can be prepared or
the ATP given by the client can be validated.
• Meetings with the client and the end users to ensure that all functional
and performance requirements are included in the SRS, the
assumptions made in the preparation of the SRS are correct and also to
clarify any other aspects which have some vagueness.
Design Reviews
The project manager has to plan design reviews to ensure that the design satisfies all the user requirements. The following design review meetings have to be planned:
• Internal design review meeting to check that all the modules are
correctly designed, the module interconnection definitions are clear
and all the design goals are met.
• A critical design review meeting with the quality and test teams to
ensure quality in the design process.
A design review meeting with the client’s group formally completes the design phase. Even if the client is not IT-literate, the review meeting is important to review the user interface, the performance requirements, the hardware and software environment etc. This forum also is used to make any formal requests for changes in the specifications in case some functional/performance requirements cannot be met, or in case implementation of some features need to be postponed for a later release.
Code Review
In small projects with a few engineers, the project manager may like to review the code. This is impractical for large projects involving many software engineers and programmers. The project manager’s responsibility would be to define a clear process for code review and ensure that the process is strictly followed. The project manager must develop a document detailing the ‘coding guidelines’ and train all the programmers on these guidelines and check whether the programmers are following the guidelines.
Carrying out a line by line code review should be left to the peer review i.e., the project manager has to make it clear that the ’source code’ is a work product that has to undergo peer review and the peer review report should be submitted to him/her.
The project manager has to be physically present in some peer review meetings to check that the peer review meeting focus is on the code and not on the individual who has written the code.
Peer Reviews
Peer reviews are performed for all phases of the software development life cycle. During the planning stage, the work products that should undergo peer review are identified. Peer reviews must focus on the work product and not on the individual who produced the work products. The project manager should not use the results of the peer review meetings to evaluate performance of the individuals.
Peer reviews should be conducted under the supervision of a project leader (a senior engineer) who is trained to carry out such reviews. Otherwise, peer reviews may result in clashes and personal abuses defeating the very purpose of such reviews. The project manager should review the results of peer review meetings and initiate the follow-up action.
Peer reviews enhance the quality of the product and the process, and the project manager has to encourage peer reviews.
Process Review
During the planning stage, the project manager decides the development process to be followed. It does not mean that the process is a rigid entity and cannot be modified. For example, if a decision is taken to follow the waterfall model but after a few interactions with the client, the development team realizes that it is not possible to write a very clear SRS, it is foolish to say that we will not go further till the SRS is complete. Such attitude will make the program manager being branded as a ‘process bureaucrat’. A better approach would be to see whether an alternative development model (say prototyping) would be better suited for the project. Event-driven decision-making is required to bring in dynamism in the process-oriented development.
The process also needs to be reviewed periodically with the quality group. A comprehensive process review has to take place at the end of the project.
• After the project is complete, the postmortem analysis has to be done
and the results are analyzed. If there are differences between the
estimates and the actual values, the reasons can be attributed to the
process. The recommendations of the development team based on this
analysis should be communicated to the process engineering group.
• The development team should conduct a formal meeting with the
quality team and discuss the possible improvement in the organization-
wide process definition.
Process Auditing
It is not enough to define a process, the project manager has to ensure that the process is being followed meticulously and implementation is being done as per the defined process. A periodic auditing is required to check this.
Auditing can be done either by internal audit team or external audit team, preferably both. Initially, the internal audit team (to be formed by the project manager) consisting of engineers specializing in quality along with senior software developers from other groups can do the audit. Subsequently, an external audit team (people from other organizations specializing in quality processes) can do the audit.
Audit is carried out by
Interaction with the development team on the methodologies being followed.
- Checking the documentation being produced.
Observing the development team while on the job.
Participating in the review meetings.
- Informal interaction with the project manager and the team members.
After the audit is complete, an audit report has to be prepared highlighting the positive and negative impressions of the audit team on the process. Any deficiencies in the
process implementation have to be brought to the notice of the project manager and team members so that the development team can improve upon the process implementation.
For organizations, which already have obtained quality certification, as well as for organizations which plan to obtain quality certification, both internal and external auditing are compulsory.
Risk Management Planning
A well-defined risk management plan reduces the crises. To identify the possible risks for the project, it is important to obtain the perceptions and fears of different people.
The manager has to create a culture wherein the team members tell openly the risks perceived by them—regarding the technology and the time. Particularly the time risk is very high in many projects. The manager should not bulldoze his way through but listen carefully the apprehensions about the project risks. Through brain-storming discussions, the manager has to elicit the opinions of all the team members and identify the risks. Each risk has to be analyzed and the impact of each risk item on the cost, time and implementation has to be discussed and recorded. The necessary steps to overcome the risks are also planned. The various activities involved in risk management are shown in Fig. 2. Risk assessment is carried out during the planning stage and risk control during the project execution stage. These activities are described in this section.
Risk Item Identification
At the time of acceptance of a project, there will be many uncertainties, but still, we accept the project. These uncertainties are the root cause of risk. In addition, there will be internal risks, such as suddenly some key people leaving the project as a result of which the time frame cannot be met. Boehm identified the 10 top risk items based on a survey of a large number of software managers. These risk items are:
> Personnel shortfalls: non-availability of skilled people for the job.
> Unrealistic schedules and objectives: time frames are over-committed and
so are the features of the software.
> Developing wrong software functions: Due to wrong interpretations or
lack of full understanding of the user requirements, software engineers
develop wrong or unnecessary functionality into the software.
> Wrong user interface: user interface is the most complex part of the
software design, changes are certainly likely if early feedback is not
obtained.
> Gold plating (features which are marginally required): creating flashy
icons, adding frills to the software are waste of time, the engineers do not
agree, but managers know better.
> Continuous stream of requirements changes: After the initial discussions
with the client, you ‘freeze’ the specifications. But the client will not.
(“The software must be so flexible that making changes should be very
easy for the next two years” or “specifications are a moving target” are the
common remarks you hear from the clients).
> Shortfalls in externally furnished/purchased components: Interfacing the
software with external hardware or software is always risky. We assume
things and start the project and realize that the assumptions are wrong.
Enough thought has to be given to this aspect during the feasibility studies
stage.
> Shortfalls in externally performed tasks: Think the case of interface with a
legacy database. What appears to be an easy task at the outset, will turn
out to be a Herculean task.
> Real-time performance: For systems which need real-time response, such
as process control systems, ensuring that the design would achieve the
necessary performance is always risky. Unless the system is implemented,
the response time cannot be measured and if the response time is not
within the required limits, the whole project gets into trouble.
> Straining computer science capabilities: Some users want you to do certain
things which are not technically possible, with the present state-of-the-art.
Examples include unlimited vocabulary speaker-independent speech
recognition, natural sounding text to speech conversion, automatic
language translation etc. If the software developer has no knowledge of
the application domain and accepts the project, then he is in trouble.
The risks associated with most of the projects are likely to be amongst these items. While carrying out the risk planning, the risks have to be identified with the above list serving as a good starting point. If there are any other risk items, keep adding to this list (a step towards process improvement).
Risk Analysis
For analyzing the risk, one can do the worst-case effort estimation. The impact of a risk item can be calculated by the loss. The loss consists of direct loss and indirect loss. The direct loss in terms of dollars is not difficult to estimate, but the indirect loss in terms of loss of credibility is difficult to estimate.
Risk Prioritization
After identification of risks and assessing their impact, one can list the risk items in the order of impact or priority with which they need to be tackled. Of course, it is likely that the priorities may keep changing. The prioritization helps in bringing the risk item into focus so that the top management can address it immediately.
Though there are a number of mathematical models to quantify the risk impact, in practice very few managers follow the models, and the impact is generally done based on subjective assessment. While doing subjective assessment, it is preferable if the opinions of other team members are also taken into consideration.
Risk Control
Risk control is done during the review meetings. These meetings may be conducted exclusively to review the risk items and their impact or along with other project review meetings.
A risk control team may consist of the project manager and other senior team members. Based on the priority and the impact, the senior management representative may also participate in the meetings.
To control the risks, a risk management plan has to be prepared which describes
What are the risk items?
What is the impact of each risk item?
Which risks have to be addressed with high priority?
Who is responsible for risk management?
What resources are required to overcome the risk?
For example, if important team members leave the organization jeopardizing the progress of the project, the risk becomes a high-priority risk and steps need to be taken to resolve the problem. The alternatives such as recruiting a temporary consultant, subcontracting a
portion of the work, informing the client of the problem and requesting for more time are the alternatives which need to be discussed and a decision arrived at.
A good project manager is one who can foresee the risks, resolve the risks by continuous monitoring of the risk items and takes a corrective action before the risk leads to a crisis. The project manager should always strive not to get into a crisis.
Tools for Automation of Software Engineering Activities
A number of tools are available for various project planning/management activities, which enhance the productivity of the manager. They include
• Project review and tracking tools
• Project estimation tools
• Tools for software metrics
These tools certainly help the manager in doing a better job (such as the Project of Microsoft), but their effectiveness depends on the input data entered. These tools also help in the manager not to leave important activities by oversight. Particularly the tools that help in measurement are of immense value. These tools, used by the engineers, would provide the necessary inputs to the manager in product and process quality. Some such tools are
• For finding the number of lines of source code, with the ratio of
commented lines to uncommented lines, which gives a measure of the
embedded documentation in the source code.
• Function point measurement tools which give an exact value of the
actual complexity of the code.
• Tools for project effort and time estimation based on COCOMO
model.
For tracking and review, the project manager has to enter the data for the actual reviews, the team members involved in various modules and the module review dates, dependencies of one activity on other activities etc. After inputting the data, the tools give a pictorial representation in the form of bar chart which will help in monitoring the progress of the project.
CASE Tools
Because of the rising costs of software developers and also to reduce some of the mundane work being carried out by the programmers, a number of Computer-Aided Software Engineering (CASE) tools are available in the market (and lots of them on the Internet too) which increase the productivity and also reduce development costs. Such tools can be categorized into
Software specification and design tools such as those for object-
oriented analysis and design.
• Automatic program generation tools (such as lex and yacc in UNIX)
which generate code in a specific programming language. Though the
code is not necessarily optimum, it is a highly maintainable code. If
required, optimization can be done subsequently.
• Automatic testing tools such as profilers, test case generators, static
analysis tools, and dynamic profilers.
• Tools for testing the portability of the code (such as lint in UNIX)
• Powerful debuggers which facilitate easy and fast debugging of code.
Presently, lot of research is going on to develop tools by which business software can be developed without writing any code at all. The GUI tools reduce the programming a lot, but more sophisticated tools are likely to be available soon.
Every organization has to define a process whereby new CASE tools can be introduced to enhance the productivity and improve the quality of the products.
If the project manager decides to use any of the project management and CASE tools, he/she needs to decide about them in the planning stage itself and provide the necessary training to all the team members on these tools.
Project Plan Document
A project plan document giving the complete details of the plan has to be prepared which acts as the guide for the entire project management. Most of the project managers have a plan ‘in their brains’ and invariably that leads to chaos—a disorder that cannot be streamlined later. A representative format for the project plan document is given in this section. Depending on the requirements of a specific project, suitable modifications can be made.
Format of Project Plan Document
Project Plan Name of the project Client
Project start date Project completion target date Project manager Purchase order reference Estimations
Effort (in PMs)
Time
Budget
Assumptions made in estimation Bar chart with milestones Project team structure Team members
Name Responsibility
Development life cycle model Project execution model Quality standards to be followed Work products to be generated and kept under configuration control
Project Plan document
Software Requirements Specifications Document
Design Document
Test Plan
Source Code Test Results
(any other work products to be mentioned)
Review meetings plan
Specification review
Design review
Critical design review with the client
Code review
Test plan review
Test results review
Acceptance test plan review
Field trial results review
Process review
Peer reviews
Postmortem review
Events that may require extra ordinary review meetings Training required for project personnel
Name required training (areas/topics)
Software configuration control board
Chairman of SCCB Members
Procedure for configuration management
Internal audit team
Internal audit dates
External audit team
External audit dates
Risk management
Risk items
Risk analysis
Risk management reviews
Project management tools to be used CASE tools to be used
Table I. Format of Project Plan
Project Monitoring
The project plan has to be used as the guiding document during the entire project period. If the plan document is followed meticulously and reviews are carried out as planned, then the project is likely to be executed smoothly.
However, the project plan document is also a ‘live’ document that needs changes based on the events. The project manager has to ensure that the plan document changes are also recorded as per a systematic procedure and only the latest plan document is available to all the team members.
During the project execution, the manager has to review the plan document periodically to check whether the planned activities are implemented. In addition, the effort, cost and schedule have to be monitored using the Bar chart and Cost-Schedule-Milestone chart. The Cost-Schedule-Milestone chart (Fig. 3) gives the estimated values of the effort (or cost) and schedule vis-a-vis the actual values as on date. This chart is an effective tool for the top management to monitor and hence control the effort and budget, and take any corrective action required.
|
|
