Each year in the U.S., the total cost of software development projects is around $275 billion, and unfortunately 70% of these projects fail to honor their contractual arrangements. The most common factors that compromise software development are imprecise client specifications, insufficient planning and analysis, poor project management, continually moving goalposts, unrealistic short timescales, weak quality assurance, underestimated resources, an unfit schedule and scope commitments. These factors highlight two sources of complexity in software development projects: social and technical complexities.
A software development project is a complex socio-technical activity. The social aspects of such a project, which are linked to the complexity of the development activities, include how the developers and their clients interact, behave, and organize. For example, developers create and modify the software with the necessary coordination to avoid conflicts and improve the team’s performance and effectiveness. By contrast, technical aspects and their inherent complexity include appropriate design and use of algorithms, architecture, development techniques, and computing technologies.
Various software development methodologies have been created to guide the software development process and to reduce their complexities. Some of the development methodologies are agile methods, iterative processes, waterfall processes, and formal methods. Each of these models provides to software developers 1) methods and tools to understand, interpret, and manipulate the software artifact, and 2) computer-support cooperative methods and tools such as configuration software management and other process-based software development systems.
The objectives of these socio-technical systems is to meet the requirements of standards like ISO 9000, SPICE, BOOTSTRAP, SEPRM, Capability maturity model, Personal software process, and Total quality management. The purpose of this post is to compare and contrast three team-oriented software development process models: Unified Modeling Language (UML), Extreme Programming (XP), and Rational Unified Process (RUP) regarding their impacts on group software development.
Software Development Practices in XP, UML, and RUP XP, UML, and RUP are the most commonly and extensively used models throughout the software development industry. XP, UML and RUP have considerably influenced the industry in a way that proprietary models, for instance, Microsoft operations and solution frameworks (MOF and MSF) have espoused their practices and values.
Group Software Development Support in XP
XP is the most well-known agile software development approaches compared to the other methods such as Adaptive software development, Lean Development, Crystal, Dynamic Systems Development Method, Feature Driven Development, and SCRUM. This methodology was developed by Beck in 1996 to solve many of the major issues that led to software project complications. The XP lifecycle consists of six phases, which includes exploration, productionizing, planning, first release iterations, maintenance, and death. As a rigorous approach for group software development support, XP is characterized by a tight customer-developer loop that ensures that misunderstandings between the developer and the customer are corrected early in the development lifecycle.
XP is also characterized by pair programming, one of its 12 core practices. The other practices are pair programming, planning game, small releases, metaphor, continuous integration, refactoring, collective ownership, simple design, testing, onsite customer, coding standards, and 40-hr week. XP shares the same values (communication, courage, feedback, and simplicity) as described in the Agile Manifesto that places the highest priority of the interactions on the development team, the developers and their customers. From the group software development perspective, one can note XP’s lack of practices to facilitate the communication and discussion of abstractions, the separation of analysis and development roles, the provision of components’ interfaces and design patterns. These functionalities are available in UML.
Group Software Development Support in UML
UML had been successfully applied to various domains since the adoption of its first version (UML 1.0) in 1997 and the subsequent revisions (from UML 1.2 in 1998 to UML 2.0 in 2002) by the Object Management Group. This model was influenced by various languages used in object-oriented methodologies. Like RUP, UML combined the concepts of Object Oriented Design (OOD) of Booch, Object Oriented Software Engineering (OOSE) model of Jacobson, and Object Modeling Techniques (OMT) of Rumbaugh. Many scholars consider UML as the de facto standard for designing and architecting software systems and for object-oriented modeling.
The UML meta-model is subdivided into foundation, behavioral elements, and model management packages. These packages and the rigorous specification of the UML diagrams facilitate communication and understanding between customers and developers. Although various authors have questioned the UML communication ability because of the technical aspects of the diagrams, the UML remains the closest model in the industry that facilitates such communication.
Group Software Development Support in RUP
The three principal developers of UML (Booch, Jacobson, and Rumbaug) developed RUP in 1998. RUP is use-case-driven, iterative, and incremental with a four-phase development cycle. Similar to XP, each phase is subdivided into iterations that consist of nine disciplines which result in a working software. For each discipline, developers are assigned specific artifacts, activities, and responsibilities. The virtues of RUP, like those of XP, are quick development, customer satisfaction, and low cost.
However, some scholars and practitioners noted the lack of appropriate values to guide beyond the development practices in RUP even though guiding principles such as Develop Iteratively are provided. One of the most common criticisms of RUP is that it is excessively burdensome in terms of procedures and paperwork. Many developers argued that although RUP shares a number of similarities most notably emphasizing iterations and disciplines that produce working deliverable software, the method does not share agile principles that characterized XP.
Finding Common Group Software Development Practices
The criteria catalogue is based on the assessment of the practices, values, and principles of RUP, UML, and XP. A feature is selected based on its ability to support a group software development. In this paper, seven criteria have been selected: customer requirements and understanding between stakeholders, documentation, group memory, pair programming, software configuration management process, group awareness, and continuous verification of quality. Prior research has identified similar criteria including the support for code sharing, generating awareness, simplicity, and interface design as important elements in software group projects. UML and RUP seem to be more advanced than XP regarding group software development support. XP lacks useful support practices for group software development such as group memory and documentation. However, the practice of pair programming in XP seems to contribute significantly to high software quality.