Professional Documents
Culture Documents
SEMESTER
SUBJECT CODE & NAME
BSc IT
SIXTH
BT0092, Software Project
Management
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.
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.
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.
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
Exploratory/ad hoc testing (where testers do not follow a script, but rather testers explore
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?
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.