Project Management and Software Quality - Term Paper Example

PROJECT MANAGEMENT AND SOFTWARE QUALITY Contents Contents 2 1. Introduction There are about a million software projects each year, but unfortunately, many of these projects never reach the level of quality the customers expect. Other projects fail to deliver the software on agreed data and budget. The common reason for such failures is poor project management characterized by unclear objectives, bad planning, lack of appropriate project management methodology, and inefficient project teams (Jalote 2005, p.1). The following sections discuss how various software models affects software quality and the role of project management methodologies in ensuring customer satisfaction. These include a review and analysis of different software development models from Waterfall to contemporary AGILE approaches. In relation to software development, this paper also conducted critical analysis of relevant project management approaches to determine the most appropriate in terms of software quality and customer satisfaction. A comprehensive discussion regarding the relationship between project management and software quality is in Section 5. These include software quality metrics and project management approaches explaining the quality aspects of software development and that can deliver software quality requirements respectively. 2. Software Project Management Software projects usually consist of two main activities. The first one is engineering that deals with system building while the second is project management responsible for planning and control engineering activities. Software project management is an important activity in software engineering and responsible for activities like design, planning, development, and support for computer software. In other words, software project management covers the knowledge, technique, and essential tools to manage software products development properly (Agarwal et al. 2011, p.1). The level of effectiveness and performance of project management method is like measuring a complete business process wherein effectiveness, efficiency, and profitability are important factors of performance (Kelsey 2006, p.1). How well the project meets, the budget and timely delivery determine the effectiveness and efficiency in this context. According to Jones (2009), the failure of software projects are commonly due to failure in software project management rather than shortcomings of technical staff. For instance, cancellation of the majority of software projects were due to underestimated schedule and resource requirements (p.355). These include projects that fail due to designers, developers, and testers’ inability to cope with changes that commonly originate from various factors such as sudden stakeholder change of mind, discovery of more efficient way to develop the software, conflicting requirements, and others (Steelman & Greene 2005, p.120). In project management, a project is a container for process, people, and product models, and in software development, project models are working together with process models. The agile method for instance takes into count both process and product models, as they are important elements of the method's activities. Activities in software process model such as requirements determination, design, coding, and testing are major blocks that separate a model from another. The waterfall process model for instance, commonly implements an activity in a clear-cut manner until it is complete. In contrast, activities in iterative models such as eXtreme Project Management and Rapid Application Development, are commonly looping as review of activities are taking place in each cycle (Sobh 2010, p.36). 3. Review and Analysis of Software Development Models 3.1 Waterfall Waterfall development models are methodologies used in the manufacturing of electronic hardware during the 1970s where power and progress flow downhill to predetermined end. The waterfall model is broad and rigid, and in software development, waterfall enables segmented and bureaucratic activities (Kadre 2011, p.27). The common step in project's following the waterfall model starts with conversion of customer’s business requirements into a software system requirements specification. Activities include analysis of collected requirements in order to identify appropriate data structures required for subsequent design works and establishment of relationships between data structures, hierarchies, processes, and discovery of other classes and objects. It is only after establishing the relationship, testing, and deployment is complete that the coding or programming can start (Sudhakar 2010, p.15). The common cited disadvantage of the waterfall model is the fact that it does not allow feedback between stages of development, thus only useful in projects with stable requirements. In the waterfall model, the customer commonly has to take care of product operations including the additional cost of software maintenance. However, according to Futrell et al. (2002), waterfall activities are easy to understand, enable tight control of project, convenient planning and staffing, better quality control, and progress of development is easy to track. Unlike contemporary project management models, the waterfall model suffers from its inherently linear sequential nature. Therefore, any attempt to correct an error can result to additional cost and significant adjustments in the project schedule. Another problem with the waterfall model is the absence of tangible interim deliverables for the customer because the product will be only available at the end of the long process (p.119). 3.2 V-Process Contrary to the waterfall model's rigidity, the V-Process model allows corrections to occur in any stage of the requirement. If there is an error in any of the stage, correction of the following activity is necessary, thus the whole process flows like a V-shape. For instance, if an error is found in the high level design stage, documents associated with a high level design is then corrected leading to low level design document modifications including source code. The major advantage of V-Process model is the reality that developer does not have to wait until all stages of the project are complete, and since it enables correction to occur at every stage of development, the software is bug-free before it reaches the final stage (Sudhakar 2010, p.17). The V-Process model is straightforward and easy to apply. Because the model check and validate every activity during the development process, developer will be able to test every product before the software's completion. For this reason, the model is more appropriate for systems with reliability requirement. However, the V process model does not support iteration and change of requirements and since it reacts on errors when it is found, the model does not perform risk analysis before a project starts (Sangeeta 2008, p.13). 3.3 Spiral Spiral is an evolutionary software development model that combines iterative and traditional linear and segmented model. Before a software development begin spiral allows identification, modification, and elimination of any risks that can directly or indirectly affects the successful completion of software and its operation as well as expensive rework. The spiral model is ideal for large and complex systems with various features and facility requirements. It is also useful when trying out new technology or when customer and users are unable to provide clear requirements for the project (Agarwal et al, 2011, p.35). Four quadrants represent each phase of the spiral model. The first quadrant determines the objectives and alternative solutions for a particular phase of the project, while constraints and other barriers associated with these alternatives are deal with in the second. The third quadrant deals with strategies that can resolve uncertainties and risks that may affect the project. This quadrant includes activities such as benchmarks, simulation, and prototyping in order to determine appropriate solutions. The fourth or the last quadrant deals with meeting the objectives in the following cycle of software development leading to the completion of the system. It is important to note that spiral is not linear but cyclic thus no application of strict standard in any stage of software development. The phases in this model have no specific beginning or end. It is suitable for large projects where risk analysis is often necessary. It is risk driven, flexible, capable of creating prototypes, and requires minimal documentation (Agarwal et al. 2011, p.36). 3.4 Incremental and Iterative Incremental software development promotes incremental requirement processing. It divides the overall project requirements into manageable size. The purpose of this approach is to reduce production waiting time and risks associated with implementing large requirements at the same time. In this model, the customer can in part evaluate the product in the development process and solve problems found early. However, it may be possible that the defects introduced in the upper phases can still propagate to the lower phases particularly when the relationships of requirements is not well understood (Xiong 2011, p.35). Incremental model advantages include the ability to provide some feedback. Its requirements are small, easily understood, and stable in each increment. Addition of new requirements is also possible during modification while increasing functionality in every release. The project can stop any time after the first cycle leaving a working or usable product. Project risks are not concentrated in one cycle but spread out over several cycles. Minimal number of staff is required and testing easier. However, incremental model requires identification of a majority of project requirements and demands determination of the relationship between each module in the beginning of the development. Modifications can increase cost and schedule overruns while it requires users to learn in each deployment of a new system (Xiong 2011, p.36). In contrast, an iterative model can begin without full knowledge of project requirements and defects at the end of each iteration is rectified (Kelsey 2006, p.53). However, additional activities and changes can negatively affect both cost and project schedule. Similarly, multiple releases may increase risks due to delayed approval of funding, prioritizes operational needs rather than goals of the program, and possible quality deterioration when changes are not effectively controlled (Xiong 2011, p.39). 3.5 Prototyping model Prototyping is a phase development model, where software developer creates prototypes of the new software system in a short period. The purpose of this approach is to enable rapid customer and user feedback. The prototype may or may not be a part of the final system since it is only interested in the most successful prototype. Prototyping activities are repeated in several iterations and are suitable for projects with a high degree of technological risk associated with them. Estimation of cost and schedules is difficult because it is experimental in nature (Field & Keller 1998, p.66). According to Stair et al. (2009), advantages of prototyping include allowing users to try the system and provide feedback during development thus, detection of errors and omission is possible at the earliest time. This also results to users becoming more interested in the process and the results. However, determining the scope or end of the project is difficult and system document is often incomplete. More importantly, since production of prototype is within a short period, system security and performance may be overlooked (p.500). 3.6 Rapid Application Development (RAD) RAD or Rapid Application Development model is modularization of requirements and solutions in order to create an independent system. Software development using RAD only usually takes 60 to 90 days to complete. Various teams responsible for developing these modularized systems integrate the modules in later stage to create a large software system. Moreover, basis for modularization can be on functionality, technology, or architectural depending on purpose of the system. Rapid Application software development typically includes business, data, and process modelling, application generation, testing and turnover. Business modelling deals with information and processing of requirements while data modelling is for refining data to support the business model. Process modelling enables information flow from object to object to complete a business function. The Rapid Application Development model generates an application using fourth generation techniques such as reuse of existing program components or creating reusable components with automated tools. Since most of the programs are reused and tested, testing in RAD is less compared to other models since it only need to test new components of the system (Agarwal et al. 2011, p.39). RAD advantages include delivering products in a short period and ensured customer satisfaction. However, RAD requires more human resources particularly when modularizing large and complex requirements. RAD is highly dependent on the customer’s commitment to get involved in fast pace RAD activities thus likely to fail due to lack of cooperation. According to Taylor (2004), RAD applies new and sophisticated techniques. However, RAD developers must be careful not to commit associated mistakes such as poor stakeholder management and unnecessary promises resulting to unrealistic expectations from customers. Project team members may attempt to accomplish unrealistic goals just to satisfy customer or higher management. Moreover, there may be some hesitations on the part of the project manager to eliminate unproductive or problematic employees and late addition of people in order to recover schedules (p.221). 4. Critical Analysis of Major Project Management Methodologies PMBOK stands for Project Management Body of Knowledge with a number of agile project management processes. Structured using five groups such as initiation, planning, execution, controlling, and closure and nine knowledge areas include integration, scope, time, cost, quality, human resource, communication, risk, and procurement management. Agile project management follows a different set of principles. These include embracing change, recognition of customer value, incremental delivery, collaboration, and continuous learning. Agile, in traditional project management perspective, is an incomplete system. This is because some important processes in project management are missing (Sobh 2008, p.378). The PMBOK guide is methodology neutral as it supports all good project management practices regardless if its waterfall or agile (Sliger & Broderick 2008, p.15). Like PRINCE, it PMBOK is a generic project management methodology, as opposed to domain-specific methods like Rational Unified Process and MSF. It presents project management as closed loop and defines software development workflows (Papadopoulos 2009, p.425). PRINCE stands for "Projects in Controlled Environments" created by CCTA or "Central Computer and Telecommunication Agency" in 1989. Originally, PRINCE is for Information Technology projects, but later used as a generic standard for all types and size of projects in all environments in 1996 as "PRINCE2". However, it does necessarily mean that it can deal with all aspects of project management since it lacks support for network planning, Gantt charting, and software packages. This is because like "PMBOK", "PRINCE2" has no limit. In fact, it facilitates adoption of methodologies complying with software development practices. "PRINCE2" is ideal for projects in a changing environment, stakeholder focused, business driven, and collaborative (Hedeman et al. 2006, p.21). It works well with various development life cycles and effective in governing and controlling projects in all stages of management. The focus of PRINCE2 is on creating quality products that meet business expectations and desired benefits (Office of Government Commerce 2010, p.44). On the other hand, the design of AGILE method is to ensure customer satisfaction through early and continuous software releases. A survey of project management methods conducted in 2007 shows that the majority of development teams around the world are using AGILE methods such as eXtreme, SCRUM, Pair Programming, CRYSTAL, and RUP or Rational Unified Process. In contrast, these AGILE methods are primarily concentrating on people rather than the software development process. It is suitable for projects that expect frequent changes in customer requirements, as incorporation of new requirement in between iteration is possible. Changes in scope and requirements are normal to AGILE as their definition is coming from the release plan that contains assumptions, constraints, risks, and divided deliverables in multiple but short iterations. However, the success of AGILE methods depends on the close involvement of the customer and efficiency of self-managing teams. For instance, rapid feedback from customer enables development team to incorporate features in the following iteration resulting to faster evolution of the product. More importantly, the inserted features will give the highest value to the customer (Sudhakar 2010, p.200). According to Chemuturi & Cagley (2010), using AGILE as project management framework requires developers to consider at least five important characteristics. These include metaphor, teamwork and collaboration, guiding principles, open information, constant monitoring, and adjustment. Since AGILE development commonly require several teams working on different components at the same time, the concept of central metaphor, acting as reference for all teams, enable them to work in the same direction. Teamwork and collaboration on the other hand, ensure positive team interaction while focusing on a particular short-term goal. The guiding principle in AGILE replaces traditional methods processes, procedures, checklist, and documentation with a set of metaphoric limits where each team is free to define the methods of their work within these limits. Similarly, information such as stories, project codes, and status are open and shared among team members, so each of them can leverage on the power of available information. This is the reason why most AGILE development teams are working in proximity. The free exchange of information also enables constant monitoring and real time adjustment (p.197). "RUP" or Rational Unified Process is another AGILE method that follows "PRINCE2"’s neutrality over project management best practices. Rational Unified Process is a flexible project management framework that allows incorporation of different project management technique. For instance, an organisation using RUP is first encouraged to determine which important component is missing in their existing project management environment. This assessment enables the organisation to decide the amount of change they need to do and implement without stretching their resources. Rational Unified Process model include workflows similar to Rapid Application Development model but it has a number of iteration phases requiring inception, elaboration, construction, and transition of each workflow. Rational Unified Process model also encouraged adoption of best practices of contemporary software development in order to reduce the inherent risk in such environment. These mainly include iterative development, effective requirements management, component-based architecture, visual models, constant quality verification, and controlled change (Charvat 2003, p.72). 5. Project Management and Software Quality As discussed earlier, software quality is highly dependent on the software development model, project management method, requirements, and amount of risk. For instance, if measurements of project management method’s efficiency and effectiveness are on time delivery and nominal expense then the software is likely poor in quality. Similarly, if the software project management underestimates the schedule and resource requirements, postponement or cancellation of the project is possible. Moreover, the development team will be also helpless against conflicts and changes in requirements if project management mismanaged their stakeholders.  Majority of software developers do not want to use the waterfall model because it is too rigid and highly structured for software development purposes. More importantly, software development often requires flexibility and effective stakeholder management which waterfall cannot provide. Moreover, since it does not do any correction in each stage, it cannot guarantee customer satisfaction. In fact, additional cost of software revisions and frequent maintenance will fall on the customer. Although V-Process allows correction and refinement, it does not support iteration and ignore the importance of risk analysis. Similarly, although spiral is an evolutionary approach with iterative and traditional linear model combined, the reality that it is cyclic, it does not apply any strict standard, and no defined project beginning and end, makes it more risky and costly. Like spiral, prototyping is also problematic since its main interest is to get rapid feedback through experimental approach, which is also risky and costly. On the other hand, modularization looks more promising as managing smaller requirements is undoubtedly faster and easier. Moreover, reusing existing program components saves time and money for testing, while automated tools makes development faster. However, RAD is evidently costly since it requirements more human and technological resources. It is also dependent of customer commitment thus vulnerable to the impact of uncooperative stakeholders due to poor people management. Moreover, the idea of rapid development entails greater responsibility thus tendencies to attain unrealistic goals may affect the overall quality of the product. In order to build quality into the software system, it is evident that understanding and documentation of all the requirements must be clear. Another is to keep that same quality throughout the life cycle. However, this cannot be determined by merely monitoring, and therefore require software metrics. Software quality metrics is classified in important categories – product, process, and project that are focus entirely on the quality aspects of software development. Similarly, software quality is determined in two ways – intrinsic product quality and customer satisfaction. The quality of software produced by a project management method therefore is identifiable by its mean time to failure, defect density, customer problems, and customer satisfaction (Malhotra & Tiple 2008, p.26). If one would investigate the characteristics of software quality mentioned earlier, it would be clear that customer satisfaction determines the software quality. This is because, in reality, a software developer cannot satisfy customers with negative experiences and defective software. The ideal software project management method is one that can guarantee customers satisfaction. PRINCE2 is on top of the list as it can effectively handle projects in both stable and changing environment; it recognised the value stakeholder management; drive by business need as strictly follows customer requirements; and supports the collaborative approach in software development. However, since it allows incorporation of different methodologies and techniques, the quality of software produced out of PRINCE2 is still dependent on the people who will manage the project and relevance of selected methods. Similarly, although AGILE in some aspects and with workflows similar to RAD, RUP will also suffer from its neutrality as PRINCE2. There is nothing wrong with adopting best practices in software development, but the process of selection, which may be subject to bias and mistakes and impact of mixing two or more methodologies must consider these possibilities. Since the bottom line is customer satisfaction, then it may be more appropriate to select one AGILE method. Besides, there must be a good reason why majority of participants in the 2007 survey mentioned earlier use AGILE methods. AGILE methods particularly eXtreme and SCRUM are designed with customer satisfaction in mind while producing defect-free software through iterations. However, although iterations may guarantee quality, these AGILE methods should ensure that they have a well-organized and efficient stakeholder management strategy before starting the project. This is because expected participation and rapid feedback required for the next iteration may not occur due to stakeholder unavailability due to disappointment and lack of interest in the project. 6. Conclusion Customer satisfaction determines the software quality. Similarly, compliance with software requirements and customer expectations determine the effectiveness of a development model and project management methodology. Review and analysis of different software development models (RAD, RUP, AGILE) and project management methodologies (PRINCE2 and PMBOK) suggest that those based on iterations and stakeholder focused are likely to produce quality software. In contrast, those that are linear and more interested in the development process are likely to encounter problems in the final product resulting to customer dissatisfaction. In a similar manner, poor project management characterized by inflexible and bureaucratic activities, bad planning, and unclear objectives that have no value in software development result to cost and schedule overruns and a number of quality problems. 7. References Agarwal B, Dhall S, & Tayal S, (2011), Software Project Management, University Science Press, New Delhi Charvat J, (2003), Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Projects, John Wiley and Sons, United States Chemuturi M. & Cagley T. (2010), Mastering Software Project Management: Best Practices, Tools, and Techniques, J. Ross Publishing, United States Field M. & Keller L, (1998), Project Management, Cengage Learning EMEA, United States Futrell R, Shafer D, & Shafer L, (2002), Quality Software Project Management, Prentice Hall Professional, United States Hedeman B, Heemst G, & Fredrikz H, (2006), Project Management Based on Prince2, Van Haren Publishing, Scotland Jalote P, (2005), Software Project Management in Practice, Pearson Education Asia Limited, China Jones C, (2009), Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies, McGraw-Hill Professional, United States Kadre S, (2011), Going Corporate: A Geek’s Guide, Apress, United States Kelsey R, (2006), Software Project Management: Measures for Improving Performance, Management Concepts, United States Malhotra J. & Tiple B, (2008), Software Testing and Quality Assurance, Nirali Prakashan, India Office of Government Commerce, (2010), Delivering IT Services Using Prince2, The Stationery Office, United Kingdom Papadopoulus G, Wojtkowski G, & Wojtkowski W, (2009), Information Systems Development: Towards a Service Provision Society, Springer, United States Sangeeta S, (2008), Software Engineering, New Age International, India Schwalbe K, (2009), Information Technology Project Management, Cengage Learning, United States Sliger M. & Broderick S, (2008), The Software Project Manager’s Bridge to Agility, Addison-Wesley Professional, United States Sobh T, (2008), Advances in Computer and Information Sciences and Engineering, Springer, United States Sobh T, (2010), Innovations in Computing Sciences and Software Engineering, Springer, United States Stair R. & Reynolds G, (2009), Principles of Information Systems, Cengage Learning, United States Stellman A. & Greene J, (2005), Applied Software Project Management, O’Reilly Media Inc., United States Sudhakar G, (2010), Elements of Software Project Management, PHI Learning Pvt, India Taylor J, (2004), Managing Information Technology Projects: Applying Project Management Strategies to Software, Hardware, and Integration, AMACOM, United States Xiong J, (2011), New Software Engineering Paradigm Based on Complexity Science: An Introduction to NSE, Springer, United States Read More