Executive Summary
In the engineering of software, the software methodology applied plays a significant role in the final product of the process. For example, in a traditional linear model software is created following a set of steps and changes are often difficult and costly to implement. The pressure created by increased connectivity and the possibilities that it creates in engineering have led to the need to reconsider software engineering approaches. In light of this, approaches such as paired programming have emerged and are likely to playa major role in the future of software engineering. Paired programming has brought with it numerous advantages that could positively affect the engineering procedure. The purpose of this report is to introduce paired programming and improve the reader understanding on the topic.
Introduction
In this report the author intends to present various arguments that are hoped will be useful in altering the perception of software developers and organizations with regards to paired programming. However, before embarking further on the discussion it is essential that the reader is introduced to concepts in software design and engineering. The software development lifecycle is a crucial aspect in the construction and design of software projects (Jeremy 25). This is the process that guides various participants such as the project manager from conception, implementation to the maintenance phases of a software project.
Through the lifecycle of the software project as defined through the SDLC the developers can take necessary steps to guarantee results and quality of the final product (Jeremy 25). For example, with adequate planning the developers can identify potentially problematic areas in the project and allocate these additional resources. Such planning in the course of developing a system allows for improved overall management of the software project. In construction of a software project the SDLC allows us control over essential aspects such as the plan, the course and the staff. It goes without saying that these also represent the most volatile aspects of a software project.
Based on the above information it becomes clear to see that a well planned SDLC is essential in ensuring success of a software project. There are various models used in managing the software project lifecycle each of which is suited for different situations. Among the examples that have been mentioned to be useful in ensuring quality include the traditional or waterfall model (Jeremy 25).
It has been noted within the software engineering industry that trends affecting modern commerce such as increased connectivity pose a potential problem for software developers. As a result of this several alternative approaches are being designed to improve both the process of engineering and reduce the time taken in completion of tasks (Jeremy 26). Take the example of a developer who spends countless hours designing and constructing a software solution but is thrown off balance by a release of a similar product by a competitor a week to release.
This problem could be further compounded if the competing product is somewhat more efficient say due to cost of increased features. For this reason software developers need to gain whatever advantages they can over the competition. It has been suggested that among the best ways of doing this is the use of a number of tools that can make adjustments to the SDLC (Jeremy 26). Such tools can assist a development team in reducing time spent on tasks, increase their accuracy in execution and improve resource management to ensure there is no excess over the budgeted estimates.
Alternatively a developer could always perform market research prior to releasing a product but it is always wiser to concentrate on the SDLC which can positively affect the final product. Due to this observation majority of software developers has changed the focus to make adjustments to the SDLC.
Factors that Influence Successful Software Engineering
It is reported that the average quality of software products manufactured within the US has changed minimally since 1979 (Jones 555). Despite this data few companies have made serious changes in their procedures with the exception of those who have instituted mechanisms that allow them to measure quality. This is possible through using tools that provide predictions which can be used to measure the quality of products against competing products.
These same companies are also observed to utilize defect removal methods such as joint application design (JAD) in addition to quality improvement methods such as Team Software Process (TSP). This could be influenced by the fact that historically the size of the software project often determines the time and resources spent on defect removal and error checking (Jones 555). This is influenced by the fact that efficiency in removal of defects within the industry indicates an average of about 85%. Thus the major maintenance cost in the software industry is the identification and removal of bugs accidentally included in the product released to the customer.
This data posits that the major cost in ownership of software is incurred in bug removal and defect identification. It has been stated that this cost ranges at between 30% and 50% of every dollar spent on software (Jones 555). It has also been stated that in the majority of cases where a software project is reported as overdue or exceeds budget allocated the primary reason is excessive defect levels. These bugs often slow down the testing procedures and force the development team into costly delays and often budget overruns.
It should be noted that bugs can be identified in any stage of the SDLC. Other than the code bugs that are made during coding, bugs could exist in the requirements definition and design in which case their effect is often worse and far reaching. Errors in requirements are reported to account for 20% of total software defects while being responsible for over 35% of highly severe defects in software (Jones 559). A stark reminder of this is the infamous millennium bug which was not a coding error but an error in definition of requirements.
Based on this information it becomes clear that software quality is to a large extent influenced by the degree to which effort is made to identify and remove defects. Planning is therefore crucial in the process of designing, implementing and maintaining software and the end result of any software engineering is dependent on the degree of planning made from the onset.
Defining Quality Software
A good definition for quality software is often based on the needs of those composing the terms. As a result there is a lot of variation in published definitions though there are known fundamental issues such a definition should address. For example it is known that quality should be predictable before the application commences (Jones 556). This position is easily understood given that all software are aimed at a specific task and the quality can be predicted based on the performance in relation to accomplishment of the task.
Further quality needs to consider all deliverables and not just the code to be constructed (Jones 556). This issue is especially easy to understand when using the perspective of the user. The user does not just simply purchase code but intend to receive user guides, technical support, etc (Evans 3). It is not uncommon to find software that is supported by very good code but very poor interfaces. The end result is the product does not satisfy the user requirements and is likely to perform dismally when compared with an inferior product.
Quality is also expected to be measurable in the course in development (Jones 556). As earlier mentioned in the report there are a number of tools that can be put into use during development to improve the engineering process. These constructs can help iron out issues that lie hidden thus reducing costs such as those associated with maintenance. In line with this it is also essential that quality remain measurable after release of a product (Jones 556). This may be implemented through a network that allows for information to flow from the consumer to the producer and back.
Agile Processes
In light of the current global environment characterized by increased connectivity and collaboration it is not uncommon for a single task to bring together several programmers in different locations. For the accomplishment of such tasks it has been noted that there was a need to shift from traditional approaches to software engineering. This has been the main reason behind the development of agile processes which has resulted in completion of software with less iteration and allow for more major modifications in design (Tsui and Karam 108).
The use of agile processes is relatively new and revolutionary and is the result of vast experience with other iterative and incremental process of software engineering. Further due to the labor intensive nature of software engineering these processes shift focus to the human and team aspects of software engineering processes (Tsui and Karam 108). Though there is still no formal definition as to what agile systems are they share some fundamental characteristics.
One of these is short iterations and releases in the production of software. As opposed to the traditional approaches where each software project follows a complete path that often takes a long duration, agile approaches focus on reducing the time spent on completion and implementation. In addition to that software is constantly improved resulting is several releases of the product with each new release improving the quality (Tsui and Karam 108).
Another trait common to agile processes is an incremental design to software (Tsui and Karam 108). It is possible to suggest that this position is the result of experience with traditional approaches to software engineering. In traditional incremental approaches to software engineering, each task is accomplished and completed before the next task in the engineering process. Agile systems tend to prefer to prepare a solution based on a minimal set of requirements. This is because most requirements may be difficult to establish before the project is launched. After the launch of the project an incremental approach is taken towards addressing emerging requirements and challenges.
It has also been stated that agile processes tend to require a lot more user involvement. Rather than attempting to provide a comprehensive set of standards for a product these approaches tend to involve plenty of user interaction. It has been observed that increased feedback from users often results in a better and more comprehensive system. Agile processes are also characterized by minimal documentation. They often have only necessary documentation.
Another common characteristic with agile processes is a large degree of informal communication. As earlier mentioned the user involvement in these processes is comparatively high. These informal communication channels provide essential feedback to the developers. Informal communication is normally a good method of improving the quality of communication (Tsui and Karam 108). Lastly agile processes are characterized by plenty of change. This is based on the assumption that requirements will change from time to time and will require the product to adapt suitably (Tsui and Karam 108).
Reasons for Selecting Agile Processes
It was mentioned earlier that due to distributed development environment changes were effected that have given rise to procedures such as agile processes. However, there are other reasons for the selection of these processes over the traditional approach to software engineering. The first reason stems from the need to bring about significant reduction in completion time of software projects (Tsui and Karam 109). Large software projects using traditional approaches have been known to require between 1 an 5 years to completion. This is very inappropriate given the rapid changes occurring in business that suggest such a duration is likely to result in a product that is outdated upon release.
Another reason behind the shift to agile processes is attributed to the inflexibility of traditional approaches (Tsui and Karam 109). Most industries change at a very high rate and businesses within the industry are often forced to adapt in order to maintain competitive advantage. Traditional approaches to software engineering often find it very difficult to implement change as the project progresses resulting increases in the cost of software.
In line with the above point is the fact that traditional approaches assume requirements are completely understood before embarking on the project. This is an unstated assumption in traditional approaches which is both wrong and inappropriate (Tsui and Karam 110). It is not uncommon to find that the user does not know fully what he/she requires during requirements analysis (Tsui and Karam 110). Thus an approach that assumes it has a comprehensive set of requirements is seriously inappropriate.
Complexity is another factor that has led to an increased emphasis on agile processes. Traditional approaches often require the adherence to detailed specifications of activities and work products (Tsui and Karam 110). In addition to this is the waste and duplication of efforts associated with traditional software engineering approaches. For example, much documentation is often unecessary; requirements such as essential diagrams for production of code are a source of agony for development teams. A diagram has to be changed each time a change in requirements results, requiring the team to labor with repetitive tasks prior to completion of the software project (Tsui and Karam 110). Based on these reason it was deemed necessary to amend the approach to software design hence the increase in preference for agile processes.
Some Examples of Agile Processes
Open Source
Another widely used approach to developing software is the open source approach (Aksoy and Pelin 111). In this approach the developer submits the entire software product to the user including source code for the user to change as they see fit. This type of software is licensed to the original manufacturer though users are allowed to make amendments without having to pay any legal or royalty fees (Aksoy and Pelin 111). It is based on this relationship between the user and the developer that the software is referred to as open source. The code is developed in a collaborative manner.
This alternative approach to software should not be construed to mean that the software is not proprietary. Upon completion of development and in the course of releases the software remains a licensed product owned by the original developer (Aksoy and Pelin 112). The major advantage with open source software stems from the fact that due to this collaborative code development process the resultant product can be much more refined as it has a much more in depth requirements analysis due to the number of contributors. The approach has been successfully used in development of both large and small software applications. Common examples of open soft products include Mozilla Firefox, Open Office, MySql, Linux, among others (Aksoy and Pelin 112).
Though they are fairly widely accepted there is tremendous variation open source production. Some products are entirely the work of a single corporation such as MySql. The Linux Corporation also develops a large number of these applications providing some sound corporate backing to its products.
Crystal Family Methodology
This group of methods was developed by Alistair Cockburn and is based on the assumption that one method is adequate for all software projects (Tsui and Karam 118). Furthermore the developer assumed that the method can be adapted to meet the needs of any software project. The developer provides guideline son what parts of the method to adapt and what considerations should be made with regards to different software projects (Tsui and Karam 118).
According to Cockburn software projects can be classified based on three essential factors namely; the size of the software project which can be determined by the number of developers; the criticality, which can be estimated by the degree of loss that a malfunction could cause and their priority which can be measured by the pressure of time imposed on the project (Tsui and Karam 118). Based on these factors Cockburn defines three main methodologies namely Crystal Clear, Crystal Orange and Crystal Clear Web.
Crystal Clear is considered appropriate for projects which are not critical, with possibility of causing financial loses at the discretionary level and those requiring teams of between six and eight people (Tsui and Karam 119). Crystal Orange is adequate for management of critical projects not including life critical projects with teams of 40 people and below. Under this method it is considered wise to use the heavier methodologies for more critical projects.
Pair Programming
This approach is among the first and more popular to agile development of software and may be traced to the initial efforts associated with extreme programming (Tsui and Karam 112). The approach is commonly implemented in small teams that work closely together in the same room sometimes even sharing a keyboard with the goal of improved communications. The approach typically proposes the production of only the essential documentation where both code and unit tests serve as a part of the documentation (Williams and Kessler 177). Despite the fact that most programmers were introduced to the concept through extreme programming, it can be valuable in any programming environment (Stellman and Greene 91).
Due to the team oriented approach junior members of the team can learn more quickly from their seniors on projects. Though it may seem inefficient to assign two people to a single task paired programming does in fact improve efficiency (Stellman and Greene 91). The approach is fairly easy to implement given that any two programmers willing to give it a shot may pair for a project. It is however wise to select members to pair when both parties have had experience with similar projects in the past. The approach suggests a process that has a continuous code review without the time and effort spent to hold an individual code review being accounted for during the project. Based on this it is evident that pair programming can provide significant time saving to the project team (Stellman and Greene 91).
The core values of paired programming are similar to those mentioned in relation to agile processes with minor exceptions. There is frequent communication within the team as well as between the team and users. There is also plenty of feedback at several different levels (See Fig 5). For example the results from testing provide valuable feedback to developers while iterative communications with users is used to collect feedback (Tsui and Karam 112). It is also common in paired programming projects to make bold but essential decisions at any point during the course of development. Based on this characteristic some projects are ill suited for development using paired programming.
In addition to the core values of agile processes, paired programming also relies heavily on the roles of rapid feedback. This is possible essential during the coding, unit testing, and is the basis for short iterations between stages and frequent releases (Tsui and Karam 108). These minimal changes add up to incrementally improve the overall system quality. The approach to software development suggests that the solution sought is the simplest at the onset and advances can be made with iterations. Thus in paired programming projects it is not common to consider a variety of solutions given that emphasis is on the completion of the task.
Through the paired programming approach the software product constructed is meant to easily amendable in future. This position is reflected in the strict adherence to coding standards in these projects (Tsui and Karam 114). This unified approach to production of code ensures that communication can be achieved through code. This makes it easy to modify code produced by other team members and ensures continuity in the project development process.
Software produced using a paired programming approach is thus completed rapidly and therefore must embody the principle of delaying decisions on a single path till the last moment (Tsui and Karam 112). This can be accomplished through code refactoring to improve the code structure of the software application (Williams and Kessler 176). Refactoring suggests making changes to the system without changing its behavior. Design is not completed as a singular task but is completed on demand or in relation to the specific task at hand.
As it was mentioned earlier, the approach opts for the simplest approach in solving problems. The simple approach should not be taken to mean the poorest quality. Instead this suggests a team with the capacity to provide a high quality solution in a short time (Tsui and Karam 112). The skill of the team members must thus be reasonably advanced to ensure the simplest approach selected is also of a permissible quality. The main reason for the approaches popularity can be attributed to the minimal investment required for its implementation (Tsui and Karam 112). This is even more pronounced due to the attitude the approach brings to solving software problems. The pay to win attitude ensures most software problems can be tackled.
Based on the manner in which projects undertaken with paired programming are likely to be handled it is very essential to plan effectively prior to beginning actual work on a project. It is this phase that the team must establish essential features to be included in the software release. It is clear that for this to be done the team must possess a proper understanding of business processes, needs and competitive environment. This allows the team to release working version very fast and prepare updated releases in short cycles thereafter (Tsui and Karam 113). Upon release of a version the customer feedback on the features are the requirements for future releases. Typical release times may range from between two to four weeks.
It can be suggested that such an approach may be unsuitable due to the lack of a formal architecture. This is not the case as instead of formal architecture metaphor is used to describe the complete system. This option is suitable as it allows for as much change as possible before work is done on the actual system (Tsui and Karam 113). Appropriate metaphors are difficult to come up with but play a major role in the design process.
Further paired programming suggests that while finding the shortest path to a solution, aspects such as design should be simplified. Any unnecessary complexity is avoided even though these are often based on future considerations. It is more prudent to provide minimal functionality and improve aesthetic in later iterations (Tsui and Karam 113). In line with this refactoring is widely used in paired programming.
Paired programming relies heavily on testing and it should be done continually or even automated where testing. This has led to a practice where tests are prepared even before the code and further customer oriented testing is done to provide feedback (Tsui and Karam 113).
In projects developed using paired programming software is produced in a joint effort and as such changes can be made easily. Furthermore the inclusion of both unit and integration testing throughout ensures these changes will be managed and are unlikely to bring overall system instability (Tsui and Karam 114). Due to the possible time savings of the approach it becomes possible to complete the work at a sustainable pace and avoid delays in completion.
Common Misconceptions Associated with Pair Programming
One common myth company’s associate with paired programming is that it will increase the cost of software production. This assumption is based on the premise that having two people doing the work of one individual doubles the workload (Williams and Kessler 14). In a formal experiment to assess the veracity of these claims some researchers carried out an experiment. The experiment involved 41 students who wrote 4 programs over a 16 week semester from the University of Utah. Results indicated that the students who worked in pairs completed the tasks in half the time with far fewer defects. This is crucial as it is important to recap the point that the major cost in software is associated with removal of defects (Williams and Kessler 14).
Another myth associated with pair programming can be traced to the fact that many project teams believe once code has been developed by a pair the developers will never want to work alone. This is a misconception that has been dispelled by surveys that indicate only a small percentage (22%) of programmers in such projects spend over 80% of their time working in pairs (Williams and Kessler 14). In addition to that instances have shown that programming alone can be risky due to the lack of an alternative perspective.
Also some company’s refrain from paired programming based on the assumption that approach only works well when a pair is well suited. It has been established that other than in extreme cases most people can work with almost anyone (Williams and Kessler 15). Another myth that causes company’s refrain from the use of pair programming is the notion that pair programming is good for practice but useless when all programmers are skilled. It has been observed that even when the pair is experienced the skill in specific areas will provide unforeseeable benefits to the project (Williams and Kessler 15).
Another myth associated with pair programming is the fact that programmers will avoid joining pairs as it makes it difficult to gain credit for effort. This myth is dispelled by the fact that pair programming ensures a much higher quality of the completed task than in the case of solo programming. Further the major time reduction that this approach affords the software project all work in favor of the team (Williams and Kessler 15).
Lastly some company’s tend steer clear of pair programming on the wrong assumption that the approach will result in a need for greater interpersonal management issues that may derail the project. However, this is not the case as it has been observed in reports from programmers working in pairs that each member of the team applies a positive pressure that minimizes the distractions and improves the quality of work (Williams and Kessler 21).
Pros and Cons of Pair Programming
Proponents of paired programming argue that when there is a large amount of cohesion in the project team the time spent on software projects can be significantly reduced. Also in line with this is the advantage inherent through code inspection during the coding stage. The presence of an additional set of eyes on site during coding has been observed as a reason behind the relatively low amount of error in projects handled using paired programming. This advantage is very important to the overall product owing to the fact that software cost is mainly increased by the expenditure on bug removal (Shelly and Rosenblatt 24).
Also due to the implementation of a paired programming approach there are some advantages gained that are specific to the team. The increased communication in the application of this technique is often reported to develop strong cohesiveness between team members (Shelly and Rosenblatt 24). This position works to the advantage of the user as the team work much better together towards a solution. This has been observed in reports from pairs indicating the increased concentration and effort aimed at not letting the other partner down (Williams and Kessler 21).
Also the through the use of paired programming software is normally created in a series of small incremental steps. This approach has also been noted as a good way to reduce bugs in software (Shelly and Rosenblatt 24). Since paired programming focuses heavily on testing the end product is expected to contain relatively fewer errors due to thorough testing and the effect of the pair on the code. When this fact is coupled with an incremental approach to engineering the bugs are reduced even further as each incremental version eliminates bugs from previous versions.
A major disadvantage of paired programming arises whenever there is a disagreement between the pair of coders involved in a software project. Take the example of a project that is being handled using the paired programming approach to software design and there is a need to make an urgent or necessary decision. In such a case the best option would be to have a discussion on the next action to take to solve the problem (Wells and Williams 231). It is not uncommon in such instances for the coders to have a different opinion with respect to the solution. The procedures that have to be followed in handling such disputes make the approach prone to stalling.
In resolving such dilemmas the most appropriate option would be to provide criteria to resolve the dispute without placing too much emphasis on the concerns of the coders. Though the project is bound to continue it is clear to see that this will injure the project. Though it may be possible to use assessment criteria to ease the selection process, it is clear to see that such a situation can be very detrimental to the outcome of a software project (Tsui and Karam 129).
In addition to the above mentioned disadvantages it has been observed that paired programming can suffer due to the lack of documentation (Shelly and Rosenblatt 24). This problem can be overcome by the proper application of the coding standard which will act as additional source of info in the event of adjusting or making changes to the project in future. In a situation where the previous pair is unable to continue with the project this lack of documentation is a disadvantage.
This because coding standards simply clarify rules governing the code produced. Decisions based on design considerations are not included and thus may result in conflicting positions in different teams (Shelly and Rosenblatt 24). This approach is also likely to fall victim to problems emerging from blurred lines of accountability and too little emphasis on the larger business picture. The informal nature of such projects makes it difficult to pose questions to an individual with regard to decision making.
Agile Processes XP Case Study: Chrysler Corporation
Pair programming has been used in some large projects with relative success. In this case the use of the approach is reported following a project at Chrysler Corporation (Tsui and Karam 111). This was mainly due to the work of Kent Beck and Ward Cunningham and their efforts in providing work on simple yet efficient approaches to engineering software (El-Haik and Shaout 42). In 1996, there was a desperate attempt to revive the Chrysler Corporation comprehensive compensation project leading to the hire of Beck as a consultant.
The first recommendation was to abandon the entire code from the previous project and the waterfall model used by the corporation. In the 14 months that followed Beck and his associates began the payroll project from scratch (El-Haik and Shaout 42). The new team only maintained the existing GUI’s and employed a variety of software development concepts as they progressed. By mid 1997 the project was successfully completed and Beck had turned this informal set of software engineering concepts into what became known as Paired programming.
In this maiden run of the methodology Beck and his team implemented the pair programming approach to the coding and testing processes. The team also excluded the analysis and design phases in the development of a solution. On the other hand though there was user acceptance testing of each unit as the project moved along in an incremental fashion (Anderson 225). Following this initial success the team leader Beck published a book on the approach in 2000. The approach has since generated much interest in the press and in software engineering conferences (Anderson 225).
Agile Processes AUP Case Study: Sabre Holdings
Sabre holdings a leading company that is in the business of travel commerce and the travel industry. The organization is involved in merchandising, distribution and booking of air travel, car, hotel, cruise and other related items. The company performs these activities via a number point of sale terminals that are either online or offline (Zielinski and Szmuc 27). The company serves travelers, corporations and travel agents/suppliers in many locations around the globe.
The organization operates several companies such as Travelocity, Sabre travel network, Sabre Airline Solutions among others. The organization had vast experience in the use of the waterfall model for engineering the software required (Zielinski and Szmuc 27). The problem of changing requirements and difficulty associated with making suitable adjustments prompted the organization to consider alternative development methods.
In light of these issues the organization began to attempt alternative agile solutions from 2001. The organization was impressed by the agile solutions available but were not entirely convinced sue to the lack of track record. The organization opted for a combination of the Rational Unified Process (RUP) and agile approaches such as scrum and resulting in a mix of technologies and concepts known as Agile unified Process (AUP) (Zielinski and Szmuc 28).
Since this concept was introduced the organization has adopted many principles from paired programming such as having programmers share a keyboard (Bidogli 188). The approach was characterized by stand up meetings, code reviews, continuous integration, unit testing, limited documentation and distributed teams (Zielinski and Szmuc 35).
Despite having to overcome several challenges with the project the organization noted a significant improvement in the quality of the end product. The organization reported benefiting immensely from the new approach and boasted and end product with a significant improvement in terms of errors in the software produced (Bidogli 188).
Further the company benefited from significant reduction in time taken to complete the entire project and cost reduction due to relatively fewer errors (Zielinski and Szmuc 37). This point is very significant given that the majority cost of software is associated with maintenance and the effects of these errors are responsible for 45% of computer downtime in the US (Bidogli 188). These statistics just reiterate the importance of error reduction to software engineering and the software consumer.
Capability Maturity Model Integration (CMMI)
This CMMI Model was introduced by the Software Engineering Institute (SEI) in 1990 as a frame work aimed at helping software institutions and companies improve their software and software engineering processes through introduction of best practice (O’Regan 43). The SEI and indeed many software engineering professional’s believe there is a close relationship between the maturity of the engineering model and the quality of the end product. The CMMI institution focuses on the improvement of software processes to ensure that they satisfy the business requirements (O’Regan 43). The CMMI model is useful for organizations as it allows them to benchmark themselves against other organizations. This is possible by the classifications offered by the CMMI (See Fig 1.).
Through this process of self evaluation an organization will be able to assess its performance against that of its competitors. This allows an organization to identify whether any steps made to improve the engineering process do indeed affect its overall rating among competitors (O’Regan 48). In addition to providing a scale for benchmarking, the CMMI also provides an industry wide analysis of the maturity level in a country or the world (See Fig 2).
In addition to making a local and global comparison the CMMI is useful in allowing organizations a means to plan for the future. As each level of maturity is defined the organization can assess what features of the next maturity level it is not yet giving adequate attention and make changes to improve its software engineering and use processes (O’Regan 50).
For a better understanding on what to improve it is crucial to be able to identify the competition’s position and specifically have knowledge what they are doing that is not being done within an organization (See Fig 3.). This is crucial because the CMMI also performs a periodic industry wide assessment that allows them to establish and provide information on potential benefits of improvements. This data is gathered based on statistics from the industry and can be used in support of improving software engineering approaches (See Fig 4.).
Conclusion
In this report the discussion began by reviewing information relevant to software engineering. In the beginning it was thought crucial to mention the software development cycle and its role in the constructions of software projects. In line with this the report mentions the role of the cycle and relates it to current global business demands. This relationship is essential due to the fact that software products are normally constructed to satisfy a business need.
The report clarifies the changes in the global business environment and suggests possible effects this has had on software engineering. In addition to that the report also mentions the cost of the current approaches and the effect this has on software as a whole. This data is further supported by data from the CMMI in relation improved software engineering approaches. This data is useful in assisting organizations form decisions on agile processes given that most of the models are relatively new and as such there is little data in support of their implementation (O’Regan 49).
In line with that the report identifies a few common approaches that have been designed to satisfy business needs and maintain essential engineering aspects. In this regard it is noted that various engineering approaches are suited for various projects. The report attempts to provide some information to assist in selecting the most appropriate paradigm for software engineering.
However, in the course of discussion each paradigm is found to have specific shortcomings and as such can not entirely profess to offer a perfect solution to the dilemma. Based on this fact the report concludes that no single approach can be taken to be a valid solution to the problems of engineering software. It would be more suitable to understand the needs associated with a software project and select an appropriate methodology.
Works Cited
Aksoy, Pelin and Laura DeNardis. Information Technology in Theory. Boston: Course Technology, 2008. Print.
Anderson, David James. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. New Jersey: Pearson education Inc, 2004. Print.
Bidgoli, Hossein. MIS 2010. Boston: Course Technology, 2011. Print.
El-Haik, Basem S. and Adnan Shaout. Software Design for Six-Sigma: a Road map for Excellence. New Jersey: John Wiley & Sons Inc, 2010. Print.
Evans, Isabel. Achieving Software Quality through Teamwork. Norwood: Artech House Inc, 2004. Print.
Jones, Capers. Software Engineering best Practices: Lessons from Successful Projects in the Top Companies. Printed in USA: The McGraw-Hill Companies, 2010. Print.
Lewis, Jeremy. SDLC 100Success Secrets. Brisbane: Emereo Publishing, 2008. Print.
O’Regan, Gerard. Introduction to Software Process Improvement. London: Springer-Verlag London Limited, 2011. Print.
Shelly Gary B. and Harry J. Rosenblatt. Systems Analysis and Design. Boston: Course Technology, 2010. Print.
Stellman, Andrew and Jennifer Greene. Applied Software Project Management. North Sebastopol: O’Reilly Media Inc, 2006. Print.
Tsui, Frank F. and Orlando Karam. Essentials of Software Engineering. Sudbury: John Bartlett Publishers, 2011.
Williams, Laurie and Robert R. Kessler. Pair Programming Illuminated. Boston: Pearson Education Inc, 2003. Print.
Wells, Don and Laurie Williams. Extreme Programming and Agile Methods: XP/Agile Universe 2002.second XP. Berlin: Springer-Verlag Berlin Heidelberg, 2002. Print.
Zielinski, Krzysztof and Tomasz Szmuc. Software Engineering: evolution and emerging technologies. Amsterdam: IOS Press, 2005. Print.
Appendix
