PROGRAM BSc IT

SEMESTER SIXTH
SUBJECT CODE & NAME BT0092, Software Project
Management

Que1. Explain any five activities involved in project management.

Ans. Project Management Activities
Project Management is composed of several different types of activities such as:

1) Planning the work or objectives: A manager must decide what objectives are to be
achieved, what resources are required to achieve the objectives, how and when the resources
are to be acquired and how the objectives are achieved.

2) Assessing and controlling risk (or Risk Management): Risk is associated with several
issues. It can be technical risk, methodology risk and financial risk etc. Manager need to plan
from the starting of the project, to handle unexpected or sudden occurrence of risks.

3) Estimating resources: Resource estimation is another crucial task to the project manager. A
resource can be software, hardware, human personnel, capital etc. Resource estimation
involves the planning of required resources for the given tasks in the given period of time.
Optimum utilization of these resources is the ultimate goal of manager.

4) Allocation of resources and assigning tasks: This involves identification of task and
allocation of required resources to fulfill the given task. For example, identification of skilled
personal to solve the given task.

5) Organizing the work: Organizing involves clear lines of authority and responsibility for
groups of activities that achieve the goals of the enterprise.

6) Acquiring human resources (staffing): Staffing deals with hiring personnel, which involves
recruiting, compensating, developing and promoting employees.

7) Directing activities: Directing involves leading subordinates. The goal of directing is to guide
the subordinates and to understand and identify the organizational structure and goals of the
enterprise.

8) Controlling project execution: Controlling consists of measuring and correcting activities to

ensure the goals are achieved. Controlling requires the measurement against plans and taking
corrective action when development occurs.

9) Tracking and reporting progress: After assigning the tasks to the team members, it is
essential to track and monitor the work progress. The work progress is documented at regular
intervals.
10) Forecasting future trends in the project: The project must be designed to facilitate
extensibility of new features in the forth coming days. This is very crucial task of manager or
designer. Designers have to keep this point in mind, while designing architecture for the system.

11) Quality Management: Satisfying the customer requirements is called quality. Quality
reflects in many ways. It can be through functionality, performance and external factors like
portability etc. So the project manager needs to implement different quality management
techniques from the analysis phase itself.

12) Issues solving: An issue can be a conflict among the team members, sudden increase in
the attrition rate of employees, sudden drop in rupee value etc. Based on the issues, proper
corrective action need to be taken to ensure the smooth working of the system.

13) Defect prevention: A defect is a flaw in the system. It is more serious than an error. A
defect occurs because of improper design, poor quality etc. A thorough testing is needed before
and after implementation of the product, to avoid the defects.

14) Project Closure meet: Project closure describes the overall project details. The details can
be conveyed through closure reports. Ex. Performance reports, testing reports and project
completion reports.

15) Controlling: Controlling consists of measuring and correcting activities to ensure the goals
are achieved. Controlling requires the measurement against plans and taking corrective action
when development occurs.

Que2. Define software cost estimation process. Why it is required?

Ans. Software Cost Estimation
Dear student, cost in a project is due to the requirements for software, hardware and human
resources. The bulk of the cost of software development is due to the human resources needed,
and most cost estimation procedures focus on this aspect. Most cost estimates are determined
in terms of person-months (PM).
As the cost of the project depends on the nature and characteristics of the project, at any point,
the accuracy of the estimate will depend on the amount of reliable information we have about
the final product. When the project is being initiated or during the feasibility study, we have only
some idea of the data the system will get and produce and the major functionality of the system.
There is a great deal of uncertainty about the actual specifications of the system. As we specify
the system more fully and accurately, the uncertainties are reduced and more accurate cost
estimates can be made. Despite the limitations, cost estimation models have matured
considerably and generally give fairly accurate estimates. Software cost estimation techniques
also provides an essential part of the foundation for good software management.
Software project management begins with a set of activities that are collectively called project
planning. Before the project can begin, the manager and the software team must estimate the
work to be done, the resources that will be required, and the time that will elapse from start to
finish. Whenever estimates are made, we look into the future and accept some degree of
uncertainty as a matter of course.
According to Frederick Brooks, although estimating is as much art as it is science, this important
activity need not be conducted in a haphazard manner. Useful techniques for time and effort
estimation do exist. Process and project metrics can provide historical perspective and powerful
input for the generation of quantitative estimates. Past experience (of all people involved) can
aid immeasurably as estimates are developed and reviewed. Because estimation lays a
foundation for all other project planning activities and project planning provides the road map for
successful software engineering, we would be ill-advised to embark without it.

Que3. Define risk assessment. Explain the elements of risk

Assessment and risk control.

Ans. Effective Risk Management

There are two stages in the process of Project Risk Management, Risk Assessment and Risk
Control. Risk Assessment can take place at any time during the project, though the sooner the
better. However, Risk Control cannot be effective without a previous Risk Assessment. Similarly,
most people tend to think that having performed a Risk Assessment; they have done all that is
needed. Far too many projects spend a great deal of effort on Risk Assessment and then ignore
Risk control completely. Figure 7.1 shows the steps necessary for effective risk management.

Risk Assessment
Risk assessment involves estimating the level of risk estimating the probability of an event
occurring and the magnitude of effects if the event does occur. Essentially risk assessment lies
at the heart of risk management, because it assists in providing the information required to
respond to a potential risk.
Risk assessment may be the most important step in the risk management process, and may
also be the most difficult and prone to error. Once risks have been identified and assessed, the
steps to properly deal with them are much more programmatically. Risk Assessment has three
elements:

Identify Uncertainties

Explore the entire project plans and look for areas of uncertainty.

Analyze Risks
Specify how those areas of uncertainty can impact the performance of the project, either in
duration, cost or meeting the users' requirements.

Prioritize Risks

Establish which of those Risks should be eliminated completely, because of potential extreme
impact, which should have regular management attention, and which are sufficiently minor to
avoid detailed management attention.
In the same way, Risk Control has three elements, as follows:

Mitigate Risks

Take whatever actions are possible in advance to reduce the effect of Risk. It is better to spend
money on mitigation than to include contingency in the plan.

Plan for Emergencies

For all those Risks which are deemed to be significant, have an emergency plan in place before
it happens.

Measure and Control

Track the effects of the risks identified and manage them to a successful conclusion.
Figure 7.2 shows various risk management activities.
Que4. Mention and explain different types of Software Testing.

Ans. Types of Software Testing

Software testing consists of several subcategories, each of which is done for different purposes,
and often using different techniques. Software testing categories include:

Functionality testing to verify the proper functionality of the software, including validation of
system and business requirements, validation of formulas and calculations, as well as testing of
user interface functionality.

Forced error testing, or attempting to break and fix the software during testing so that
customers do not break it in production.

Compatibility testing to ensure that software is compatible with various hardware platforms,
operating systems, other software packages, and even previous releases of the same software.

Performance testing to see how well software performs in terms of the speed of computations
and responsiveness to the enduser.

Scalability testing to ensure that the software will function well as the number of users and
size of databases increase.

Stress testing to see how the system performs under extreme conditions, such as a very
large number of simultaneous users.

Usability testing to ensure that the software is easy and intuitive to use.

Application security testing to make sure that valuable and sensitive data cannot be accessed
inappropriately or compromised under concerted attack.
In some cases, there may even have to be other types of testing such as regulatory
compliance testing, depending on the type of software and intended industry.
There are two basic methods of performing software testing:

1) Manual testing

2) Automated testing

Manual testing
As the name would imply, manual software testing is the process of an individual or individuals
manually testing software. This can take the form of navigating user interfaces, submitting
information, or even trying to hack the software or underlying database. As one might presume,
manual software testing is laborintensive and slow. There are some things for which manual
software testing is appropriate, including:

User interface or usability testing

 Exploratory/ad hoc testing (where testers do not follow a script, but rather testers explore
the application and use their instincts to find bugs)

Testing areas of the application which experience a lot of change.

User acceptance testing (often, this can also be automated)

The time commitment involved with manual software testing is one of its most significant
drawbacks. The time needed to fully test the system will typically range from weeks to months.
Variability of results depending on who is performing the tests can also be a problem. For these
reasons, many companies look to automation as a means of accelerating the software testing
process while minimizing the variability of results.
Automated testing
Automated software testing is the process of creating test scripts that can then be run
automatically, repetitively, and through much iteration. Done properly, automated software
testing can help to minimize the variability of results, speed up the testing process, increase test
coverage (the number of different things tested), and ultimately provide greater confidence in
the quality of the software being tested.
There are, however, some things for which automated software testing is not appropriate. These
include:

End user usability testing is not typically a good candidate for automated testing.

Tests which will not be run more than a couple of times are typically not a good candidate for
automated testing, since the payoff of in test automation comes after many test executions.

Tests for areas of the application which experience a lot of change are also not a good
candidate for automation since this can lead to substantial maintenance of test automation
scripts. Such areas of the application may be more effectively tested manually.

It is important to note that test automation is software, and just like the software you are building
for internal or external customers, it must be wellarchitected. A good test automation
architecture, such as a keyword-driven testing framework, will reduce the overall cost of
ownership of your test automation by minimizing maintenance expense and increasing the
number of automated tests, allowing your organization to run more tests (and achieve higher
quality) for the same investment of time and money.

Que5. What is the role of software reengineering?

Ans. Software Reengineering Process Model

Reengineering takes time; it costs significant amounts of money; and it absorbs
resources that might be otherwise occupied on immediate concerns. For all of these
reasons, reengineering is not accomplished in a few months or even a few years.
Reengineering of information systems is an activity that will absorb information
technology resources for many years. Thats why every organization needs a pragmatic
strategy for software reengineering. A workable strategy is encompassed in a
reengineering process model. Well discuss the model later in this section, but first,
somebasic principles. Reengineering is a rebuilding activity, and we can better understand the
reengineering of information systems if we consider an analogous activity, the rebuilding of a
house.
Consider the following situation.
You have purchased a house in another state. Youve never actually seen the property, but you
acquired it at an amazingly low price, with the warning that it might have to be completely
rebuilt. How would you proceed?

Before you can start rebuilding, it would seem reasonable to inspect the house. To determine
whether it is in need of rebuilding, you (or a professional inspector) would create a list of criteria
so that your inspection would be systematic.

Before you tear down and rebuild the entire house, be sure that the structure is weak. If the
house is structurally sound, it may be possible to remodel without rebuilding (at much lower
cost and in much less time).

Before you start rebuilding, be sure you understand how the original was built. Take a peek
behind the walls. Understand the wiring, the plumbing, and the structural internals. Even if you
trash them all, the insight youll gain will serve you well when you start construction.

If you begin to rebuild, use only the most modern, long-lasting materials. This may cost a bit
more now, but it will help you to avoid expensive and time-consuming maintenance later.

If you decide to rebuild, be disciplined about it. Use practices that will result in high quality
today and in the future.

Although these principles focus on the rebuilding of a house, they apply equally well to the
reengineering of computer-based systems and applications.
To implement these principles, we apply software reengineering process model that defines six
activities, shown in figure 10.1. In some cases, these activities occur in a linear sequence, but
this is not always the case. For example, it may be that reverse engineering (understanding the
internal workings of a program) may have to occur before document restructuring can

commence.

The reengineering paradigm shown in the figure is a cyclical model. This means that
each of the activities presented as a part of the paradigm may be revisited. For any
particular cycle, the process can terminate after any one of these activities.

Que6. Explain the Role of Closure Analysis.

Ans. Project Closure Analysis
Project closure analysis is the key to learning from the past so as to provide future
improvements. To achieve this goal, it must be done carefully in an atmosphere of safety so that
lessons can be captured and used to improve the process and future projects. Before we
describe the details of the closure analysis report, we briefly discuss the role of closure analysis
and its implementation.
The Role of Closure Analysis
The objective of a postmortem or closure analysis is "to determine what went right, what went
wrong, what worked, what did not, and how it could be made better the next time. Relevant
information must be collected from the project, primarily for use by future projects. That is, the
purpose of having an identified completion analysis activity, rather than simply saying, "The
project is done," is not to help this project but rather to improve the organization by leveraging
the lessons learned. This type of learning can be supported effectively by analysis of data from
completed projects. This analysis is also needed to understand the performance of the process
on this project, which in turn is needed to determine the process capability.
As noted earlier, the data obtained during the closure analysis are used to populate the process
database (PDB). The data from the PDB can be used directly by subsequent projects for
planning purposes. This information is also used in computing the process capability, which is
used by projects in planning and for analyzing trends. Figure 14.1 illustrates the role of closure
analysis.
The amount of raw data collected in a project can be quite large. For example, a project
involving five people and lasting for 25 weeks will have 125 entries for weekly effort, data for
about 250 defects (assuming about 0.05 defects injected per person-hour), data on many
change requests, various outputs, and so on. Clearly, these data will be of limited use unless
they are analyzed and presented within a proper framework and at a suitable level of
abstraction. Closure analysis aims to accomplish this goal.
After data analysis and extraction of all lessons learned from the analyses, the results should be
packaged so that they can be used by others (packaging is the last step in the quality
improvement paradigm). Furthermore, to leverage this information, project processes must be
constructed so that their execution requires the effective use of data. It can be argued, however,
that even if others do not learn from the packaged information, the project personnel will have
consolidated their experience and will carry the lessons learned from the analysis into future
projects. In other words, a closure analysis is useful even if others do not directly gain from it.
Performing Closure Analysis
In some of the CMM level 5 companies, the project manager carries out the closure
analysis with help from the quality adviser associated with the project. A template for the
analysis report has been defined. The person carrying out the closure analysis must fill out
this template properly, using mostly the metrics data, thereby keeping the focus on objective
information.
As discussed earlier, the effort data are available from the weekly activity report database. The
defect data can be gathered from the defect control system. Size data are obtained from the
project. Planning data appear in the project management plan. These data constitute the main
information needed for metrics analysis.
The data are first analyzed by the quality adviser, who develops an initial interpretation of the
results. A meeting is then held among the quality adviser, the project leader, and other project
members. The initial report serves as the basis of discussion, and further points and
observations from the meeting are also noted. This meeting yields the basis of the final closure
analysis report.
The final report is submitted to the business manager of the project and is shared among the
project team members. The report is also entered in the PDB, making it available for future
projects and analyses.