Managing Software Development Project

Software development is a large and complex work. With the increasing of computer systems complexity and increasing of user demand for more powerful software, software engineering project becomes more and more challenging to manage. Good quality software will give benefits to the user’s organization. The result of good quality software is higher productivity, quicker delivery of systems products, better reliability, and improved morale (Bill, 1996). Meanwhile, the resources and time to produce new software are limited. Software developer face two dilemmas regarding trade-off between resources and time, software quality, and user demands growth during the software development process. If the software delivered on time and within planned budget it might result on poor quality and not fulfill user demand, otherwise development time and resources will exceed previous estimation significantly (Hayes, 1997). Poor software quality means that software delivered with defect on it that will significantly reduce the quality of users’ work (Hayes, 1997). Anthes (1997, p.75) addressed all of those caused by lack of attention from IS Managers to quality assurance due to budget cuts, user demands, competitive pressures, and rapidly change technology. Defect is a result of poor project management on software development process (Williamson, 1997). With the bigger user’s dependency on the software, defects will only result in degradation of user’s work result and at the end organizational cost is rising and other significant intangible lost occurs (Bill, 1996). This paper would like to examine the practice of better software development project management to produce better quality software. The focus of this paper is to reduce defect by eliminate or reduce it during the software development process. The discussion will mostly concentrate on the management issues rather than just technical issues.

Software Defect

Software engineering evolved to deal with the needs of large systems developed by multiple large teams, and it has struggled to keep up with the increasing size and complexity of large systems ever since and the targets of software engineering continually become larger (Laitinen, Fayad, & Ward, 2000). Haque(1997, p.24) recognize that today’s distributed, heterogeneous software development environments are turning into increasingly complex beehives housing software engineers working in parallel and concurrently. One of the biggest burden in software engineering, as Bernstein and Yuhas (1998, S27) notes, is as people come to depend on systems for their live hoods and sometimes for their very lives, software must be made to behave reliably. It is also well known that budget and time to produce software is limited. Many times a software development projects are fall behind schedule and over budget. One of the main reason is requirement creep, as describe by Strehlo (1996, p.67) that unplanned growth of the size and complexity of a development project is particularly thorny because the growth tends to occur not in total size of the code, but rather in the number of functions required to complete the tasks. In other word the project scope is increasing during the project completion time.

Modern companies are getting more and more dependent to software in order to complete their work efficiently. Software development project is large and complex work. A lot of constraint but yet a lot of expectation made it even difficult to produce high quality software. Dutta, Wassenholve, and Kulandaiswamy (1998, p.77) specifically describe the complexity of software engineering as in addition to software’s ubiquity, the amount of code in most consumer products and systems is doubling every two to three years. Consequently, software developers are scrambling to cope with the pressures of systems that are not only a couple of orders of magnitude larger and more complex than those developed a few years ago but also have to meet ever-increasing demands for quality and performance.

The result of poor quality software development project is software defect. Williamson (1997, p.81) have presented a data that shows in 1996 commercial software vendors fielded 200 million calls for technical support, 38% of which were because of bugs. Hayes (1997, p.48) states that cost of fixing software defect rises exponentially the later it is discovered. Software defects in products can not only tarnish a corporation’s public image, but can also have a severe impact on the bottom line (Bill, 1996).

Improving Software Quality

Several opinion and improvement to increase software quality during the development project have been introduced. Bill (1996, p.32) notes that quality starts with the leader of corporation and permeates throughout the entire organizations. It is a structured process, which requires discipline, measurements, and commitment to improvement. Anthes (1997, p.75) recognize that software quality is affected by IS managers lack of attention to quality and they often resist major quality improvement programs because they fear failure and see the results as uncertain. Onoma (1998, p.81) offered a method to prevent defect during the software development process by using multilevel regression testing framework that can be easily adapted. This method needs software developer to reevaluate the software quality in every steps of software development. Williamson (1997, p.81) suggest that commercial software developer to prevent software defect before release it to the market by conducting in-house testing. In-house testing has been proved could find approximately 95% of software defect. Many other methods to prevent or reduce software defect before it being used has been introduced, such as Quantum improvement in software system quality (Arthur, 1997), reengineering inspection methods during the software development project phase (Johnson, 1998), pair programming model in which developer team-up in small 2 persons unit to reduce time needed (Biggs, 2000), and any other technical methods or improvement. However, all of this technical improvement could not solve the problem itself. All new improvement techniques must be managed in order to produce good quality software, otherwise it only result in disaster. The next part will discussed the project management view in order to reduce defect.

Better Project Management

Even with new and improved technical methods and all quality assurance methods mentioned above, it would not solve the main problem of software development, which is better project management. Large and complex software development project involved a large number of people, resources, fund, and need a longer time to be completed. It is not unusual that the project find conflict of interest among each component, for example dedicated resources allocation and quality of software delivered (Schultz, 1998). All technical methods to improve software quality will only help on certain phase of software development. The most important thing is how to manage all of those conflict, resources, component, and methods to deliver high quality software on time and within budget. This part will discuss software development process from the early phase of the project and the methods could be used to improve the software development process.

According to Schultz (1998, p.23) the quality will be determined when the project started. Project manager will set the quality by negotiating it with project sponsor. Schultz (1998, p.23) believes that quality is a trade-off among cost, schedule, functionality, and durability. Project manager and project sponsor have to share a common understanding of the risks associated with the trade-off they have agreed to.

After the project started, project manager need to establish project outline, which will act as the blueprint of the entire project (Adhikari, 1996). Adhikari (1996, p.59) propose new approach software development process as an adoption of assembly line by automating process management. Process management is subset of project management, which also encompasses test, change, and configuration management (Adhikari, 1996). This blueprint could guide developer during the software development process. King (1998, p.37) has present a proof that inspecting application design and actual code can reduce software defects by 50%. However, getting developers to follow step-by-step instruction, such as regular reviews and meeting could do this with users is a difficult task. Project manager should encourage his or her developer to act according to the blueprint from time to time. Trepper (2000, p.57) suggest that organization should establish standard first and then apply the process management techniques accordingly.

Organization could actually deliver quality software on time and on budget by using the discipline of configuration management (Haque, 1997). According to Haque (1997, p.24) process configuration management act as an insurance policy against software crises and enables developers to keep the bugs out of software and implement fixes, while progressing deliverables concurrently and in parallel throughout the various phases of development. Process configuration management software is available on the market.

In order to refine software development process there are two different approaches. There are continuous process improvement approach (Trepper, 2000) and quantum improvement approach (Arthur, 1997).  Trepper (2000, p.57) acknowledge that the continuous process improvement (CPI) approach could be applied. In CPI approach organization should establish a common standard to develop software. Managing IT project in standard, formal manner provides mechanism to share the best practices created or discovered by the staff. It will result in shorter learning curve, which is mean shorter development time, and at the end will reduce the same mistake or defect being made during the software development process. This approach requires the project manager actively encourage developer under his or her responsibility to comply with current standard and resolving any possible variation.

In the CPI approach, improvement will occur gradually. For some project this approach will be not suitable. Arthur (1997, p.46) suggests another method named quantum improvement. This approach based on the Total Quality Management principles applied by US West Technologies. Arthur (1997, p.47) has pointed 5 mistakes in the software development project that caused defect: focusing on learning instead of results, lack of focus, lack of sponsorship, trying to involve everyone, and teaching theory instead of developing real-world experience. Arthur’s finding is supporting the previous discussion in this part. Software defect is not entirely caused by the lack of technical skills but by the lack of project management skills. Arthur (1997, p.46) suggests applying Shewhart Cycle to drive quantum improvements, which are: focus on improvement efforts, focus on immediate results, check, and act.

Both CPI approach and Quantum improvement suggest that project manager should continuously track the project achievement. Project manager have to ensure that each delivered results from each phase have met the requirement. To improve evaluation of the software development project there is two methods could be used, there are regression testing (Onoma, 1998) and reengineering inspection (Johnson, 1998).

Onoma (1998, p.81) suggest using multilevel regression testing framework to identify defect or potential defect during the software development process. Basically in every phase of software development process, developer team should test the result. The test result then compared with the expected result. Any variation from the desired output should be examined. If the software fails in the test it must have fault on it. Developer should identify what caused the fault. Once fault have been identified, programmers must mitigate the fault. After the faulty parts have been fixed, the software has to be tested using regression method. With this kind of testing, developers could track the development process and pinpoint every fault has been occurred and every modification have been done. Regression testing result could be a guidance to find the fault should there are bugs found in the future after the software being used or commercially released.

Johnson (1998, p.49) suggests project manager to reengineer the inspection methods in order to find more defect or potential defect than using the existing methods. Even with automatic software inspection method, Johnson (1998, p.49) believes that human inspection is still important. Organization could employ Formal Technical (FTR) review to improve inspection methods. FTR is an umbrella term for review methods involving a structure encounter where a group of technical personnel analyzes an artifact in order to improve both the quality of the product and the review process (Johnson, 1998). Johnson (1998, p. 49) suggest guidelines to start the process, which are: software development method-specific FTR, minimal meeting and asynchronous FTR, beyond defect removal to improved developer quality, beyond defect removal to organizational guideline knowledge, outsourcing review and in sourcing review knowledge, computer-meditation, and review mega-groups.


Project manager is responsible to reduce defect since the beginning of the software development project. As the software development project become larger and more complex, more problems are faced by the project manager. Software must be delivered meeting the requirement on time and on budget while facing many constraints including resource allocation (Hayes, 1997). One of the main issues of software development is software quality. Software quality refers to defect in the software. Many methods have been proposed to improve software quality in the field of reducing defect, such as organizational involvement (Bill, 1996; Anthes, 1997), pair programming model (Biggs, 2000), quantum improvement approach (Arthur, 1997), continuous process improvement (Trepper, 2000), and many others methods. However, the role of project manager is the most important. Project manager should establish the project scope and requirement with the project sponsor and resource allocation (Schultz, 1998), establish project blueprint and standard (Adhikari, 1996), and using appropriate method to ensure that software requirement are met.


Adhikari, R. (1996) Developers Benefit From A Process Blueprint, Software Magazine, 16(3), pp. 59-63.

Anthes, G.H. (1997) Quality?! What’s That?, Computerworld, 31(41), pp. 75-76.

Arthur, L.J. (1997) Quantum Improvements in Software System Quality, Association for Computing Machinery. Communications of The ACM, 40(6), pp. 46-52.

Bersntein, L. and Yuhas, C.M. (1998) Making Software Trustworthy, America’s Network, 102(4), pp.s27-s30.

Biggs, M. (2000) Pair Programming: Development Times Two, InfoWorld, 22(30), pp. 62-64.

Bill, T. (1996) Travelling Along The Road to Quality, Computing Canada, 22(22), pp.32-34.

Dutta, S., Wassenhove, LNV., and Kulandaiswamy, S. (1998) Benchmarking European Software Management Practices, Association for Computing Machinery. Communications of The ACM, 41(6), pp.77-86.

Hayes, L. (1997) The Big Lie, Datamation, 44(1), pp.48

Haque, T. (1997) Your Insurance Policy Against Bugs, Crises, Computing Canada, 23(2), pp.24-25.

Johnson, P.M. (1998) Reengineering Inspection, Association for Computing Machinery. Communications of The ACM, 41(2), pp.49-52.

King, J. (1998) Ignoring Development Guidelines Raises Costs, Computerworld, 32(20), pp.37-38.

Laitinen, M., Fayad, M.E., and Ward, R.P. (2000) The Problem with Scalability, Association for Computing Machinery. Communications of the ACM, 43(9), pp.105-107.

Onoma, A.K, Tsai, W., Poonawala, M.H., and Suganuma, H. (1998) Regression Testing in An Industrial Environment: Progress is Attained by Looking Backward, Association for Computing Machinery. Communications of the ACM, 41(5), pp.81-86.

Schultz, Y. (1998) Approach Quality Trade-off Questions Carefully, Computing Canada, 24(37), pp. 23.

Strehlo, K. (1996) Catching Up with The Joneses and ‘Requirement’ Creep, Infoworld, 18(31), pp.67-68.

Trepper, C. (2000) Continuous Process Improvement, Informationweek, Issue 800, pp.57-65

Williamson, M. (1997) Box Full O’ Bugs, Computerworld, 31(33), pp. 81.

Leave a Reply

Your email address will not be published. Required fields are marked *