Software Project Management a process Driven Approach by Ashfaque pdf

part from
process 1 is
being fed
Wrong
product
Process 2
Process 3
Process 4
Process 5
Wrong
product
Wrong
product
Wrong
product
Figure 15.8 Input defective part is being processed to produce a defective part.

---

Process Standards Introduction
◾ 
225
of origin of the defects, the xing could have been achieved at a fraction of these costs. Even if it 
would have taken some extra hours in conducting inspections, then those few hours could have 
been spent well, in view of saving time and costs at downstream activities.
e moral of the story is that defect prevention is the best policy in software development 
projects. e earlier the defect is caught in the development life cycle, the better.
at is why defect prevention is an integral part of software development projects. Defect 
prevention is implemented using software engineering techniques.
15.13 Software Project without Process
In software industry parlance, there is a term called “jumping to the code”. On many software 
development projects, the project teams start coding the moment they get the requirements. e 
management at these places also thinks that making a project and process plan is a waste of time. 
Steve McConnell, of Construx Software and the author of such books as 
Code Complete
and 
Rapid Development: Taming Wild Software Schedules
argues that on many projects, jumping to 
the code creates more rework and quality issues than it lets the project team do some productive 
work. On many such projects, the actual schedule overruns by as much as 1500% with associated 
cost overruns. ese kinds of projects are characterized by more re ghting than anything else.
Here is a case study which shows how the lack of a well-de ned process standard can severely 
a ect software projects.
Suppose a company realized that it was losing market share due to its obsolete technology infra-
structure. e root cause was that the order ful llment cycle was taking more than 2 days compared 
to the average of 1 day for the competitors. It was due to the fact that arranging trucks and loading 
them from their warehouses was taking more than 10 h on average compared to an average of 3 h 
for the competitors. is was happening because the warehouse application was not integrated with 
their transportation management system. A team was formed to study and present recommendations 
for improving the situation. After their study, the team suggested that the two applications should be 
integrated seamlessly so that information from the transportation system would be available to the 
warehousing system whereby the warehouses would have advance information about available trucks 
and what kind of content can be loaded on these trucks. Using this information, they can plan for 
truck loading and intimate the same to logistics service providers who supply trucks.
A software development team was formed with the task of integrating these applications. ey 
analyzed the interfaces of the two applications and started work on integration. After 2 months of 
the start of their work, the MIS manager asked the project manager to submit a status report on the 
project. e project manager submitted a report saying that the project would be completed 1 month 
late because of di culty faced by the team in understanding the interfaces for integration. e MIS 
manager, in turn, called for a status review meeting and asked the project team to discuss the issues 
on the project. In the meeting, the MIS manager realized that the project will not be completed even 
within 1 month of delay as the team still lacked understanding of the tasks involved. Next day after 
the meeting, the MIS manager met the CIO of the company and informed him about the situation. 
e CIO then decided to scrap the project and decided to hire a specialist service provider that was a 
expert on integration work. Later, the service provider team was able to do integration within 3 weeks.
During his study on why the project failed in the rst place, the CIO found that his MIS 
team failed because they were not following a standard process. Everything done by the team was 
on ad hoc basis. e team lacked skills on specialized tasks like integration, and so a plan should 
have been made rst to train the team for the associated skills. Only then they should have started 

---

226
◾ 
Software Project Management: A Process-Driven Approach
working on their tasks. He also found out that the project manager had not included a quality 
review process in his project plan. Without sticking to quality control at each stage of the project, 
it is impossible to achieve worthwhile quality at the end of the project.
e CIO published his ndings on the company intranet and later set up a process control 
group at the MIS level whose task was to ensure each project would incorporate quality control as 
well as adherence to standard processes.
So we see that if any project is executed without a standard process then there are risks of proj-
ect failures in terms of quality, costs, and schedules.
15.14 Process Improvement
One of the goals of CMMI standards is to select and deploy incremental, innovative improve-
ments that measurably improve the organization’s processes and technologies [12]. How an orga-
nization is currently using processes to execute projects and how performance on these projects 
can be improved further is a continuous process that needs to be measured, analyzed, and correc-
tive actions taken. is will help in improving productivity and quality further, which in turn will 
result in increased customer satisfaction and reduced costs of operations.
Some techniques that can provide substantial gains include peer reviews, code inspections, 
automation, and standard templates (Figure 15.9).
Process improvement is the most important aspect of implementing software process models. 
e CMM model has a maturity level of 5 when companies reach optimization level. At this level, 
companies have a separate software engineering process group (SEPG) that not only oversees 
implementation and observation of follow-up of process standards on projects, but also keeps 
looking for opportunities to improve processes further. Whenever they nd that some process can 
be improved, it makes a plan of implementing an improved process on projects. It develops the 
new process model and then chooses an appropriate project to pilot it. e project is then executed 
with this new process model. Results of that project are analyzed and assessed to determine if the 
project bene ted from the new improved process model. If it does then this new process model is 
applied to all projects that get executed with the same base model.
Problem areas
encountered
Review reports
Customer
suggestions
Customer
complaints
Process
improvement
opportunity
Audit results
Figure 15.9 Process improvement opportunities.

---

Process Standards Introduction
◾ 
227
15.15 Final Word
Any person or organization can learn a new thing in two ways. It can either do trial and error 
or use past experience (both success and failure) to learn. If the person or organization is always 
resorting to trial and error, then it can be said that it is not learning from past experience. Most 
people learn through experience. As they age, they have ample experience to cope with even dif-
cult situations in life. is is because they apply the learning they have gained in the past to deal 
with the current situation. Sadly in context of organizations, past experience is often not applied 
to deal with new challenges. In software services companies, they may have executed hundreds 
of projects in the past but when a new project arrives, they reinvent the wheel in planning and 
executing this project (not using the experience of past projects). ey simply do not apply the past 
learning. In e ect, they resort to trial and error for dealing with a new situation.
If these companies want to improve, then repeatable process techniques (in form of software 
development process standards) is extremely useful. For using statistical methods, data from past 
projects is saved in a repository. When a new project arrives, past data can be retrieved and put to 
use. For instance, e ort and cost estimates for a new project can be calculated using the data from 
similar past projects.
is is true for most activities that are similar to past projects. If some task that is totally di er-
ent from past projects arrives, in those cases, statistical methods will not work. In such cases, the 
project is to be treated like a research and development project and should be executed accordingly.
Review Questions
15.1
Discuss if quality processes alone can produce a quality product.
15.2
What is the di erence between process quality and product quality?
15.3
Name some of the standards for software development projects.
15.4
What are the costs of nonstandard processes in software development projects?
15.5
What kinds of processes are involved in any software development project?
15.6
What factors contribute to software development/maintenance project abandonment?
15.7
What can be done to avoid project abandonment?
Recommended Readings
1. K. Ewusi-Mensah (2003) 
Software Development Failures: Anatomy of Abandoned Projects
, MIT Press, 
Cambridge, MA.
2. H. Fujita, M. Mejri (2005) 
New Trends in Software Methodologies
, IOS, Amsterdam, e Netherlands.
3. M. Wiener (2006) 
Critical Success Factors of O shore Software Development Projects
, Springer, London, 
U.K.
4. T. Li (2008) 
An Approach to Modelling Software Evolution Processes
, Springer, Berlin, Germany.
5. R. Conradi (2006) 
Software Process Improvement: Results and Experience from the Field
, Springer, Berlin, 
Germany.
6. J. T. Marchewka (2006) 
Information Technology Project Management
, Wiley, New York.
7. S. H. Kan (2003) 
Metrics and Models in Software Quality Engineering
, Addison-Wesley, Boston, MA.
8. B. Meyer, M. Joseph (2007) 
Software Engineering Approaches for O shore and Outsourced Development 
Projects
, Springer, Berlin, Germany.

---

228
◾ 
Software Project Management: A Process-Driven Approach
9. S. Datta (2007) 
Metric-Driven Enterprise Software Development: E ectively Meeting Evolving Needs
, 
J. Ross Publishing, Fort Lauderdale, FL.
10. J. McManus (2004) 
Risk Management in Software Development Projects
, Butterworth-Heinemann, 
Oxford, U.K.
11. D. Huizinga, A. Kolawa (2007) 
Automated Defect Prevention: Best Practices in Software Management
, 
Wiley, Hoboken, NJ.
12. E. McGuire (1999) 
Software Process Improvement: Concepts and Practices
, Idea Group Inc, Hershey, PA.