Software Processes and Agile

Formalizing these SDLCs leads to planned software processes. The core building blocks of these software processes are their roles, deliverables (with templates), activities, and tasks (Unhelkar). These building blocks are supported by guidelines for configuration into usable "components," "chunks," or "fragments." Within the composite Agile approach described here, they are called process maps. Eventually these process maps, as building blocks of a process, can be embedded in CASE tools. Three software processes, the RUP, Mentor, and OPEN, are described below in the context of Agile.


Rational Unified Process (RUP)
The focus of RUP is mostly on UML-based visual models rather than on text-based documentation. RUP enables all team members regardless of their role in the project to "share a common language, process and view of software development" (Rational Software, 2001). Notice how Agile methods focus only on sharing of code rather than on sharing of visual models. Furthermore, pure Agile methods also depend for such sharing on the specific motivation and skill of a team member. However, workers in RUP have roles in a project that are more elaborate and more formally defined than in an Agile process. Activities are assigned to a worker who formally owns and completes them. There is minimal formality in the assignment of tasks in Agile—and minimal individual ownership (as it is joint ownership). Artifacts, which are project deliverables, are primarily comprised of a code in Agile projects. Workflows in RUP provide higher levels of granularity for activities as they enable sequencing of a group of activities.

RUP claims to be incremental and iterative. According to Kruchten (2003), the iterations in RUP enable a more efficient use of resources and a high level of code reuse. This is in line with the Agile practices of iterations and refactoring. However, according to Chatterjee (2006), RUP is not able to manage enterprise-level issues and organizational issues too well. Agile on its own is also not able to manage organizational issues. RUP is a formal process that needs to be initiated and customized according to the "organizational assessment and the production of a development case" (Ambler, 2005). There is no such need for up-front work in configuring and using a process in Agile. Agile and RUP can work together only when Agile practices are embedded within the activities and tasks of RUP.


Process Mentor
Process Mentor is a platform for creating and modifying process architectures that cover the entire SDLC. This includes process support for concept exploration, alternative evaluation, business investigation, requirements analysis, system modeling, design, development, implementation, and testing (Process Mentor, 2009). The stages within Process Mentor include business investigation, requirements, modeling, design, development and testing, and project management. These stages are supported by road maps, process units, and roles. The development and implementation modules of Process Mentor are the ones that lend themselves to the use of Agile principles and practices. Thus, once again, the importance of Agility in this planned process comes from the way in which the activities and tasks of development are carried out, rather than their sequencing, tracking, and reporting.


Object-Oriented Process, Environment, and Notation (OPEN)
Object-Oriented Process, Environment, and Notation (OPEN) is a software development process framework. The OPEN process framework is made up of three main elements (Firesmith et al., 2005). These three elements are a metamodel, a repository of reusable method components (or method fragments), and construction and usage guidelines (OPFRO, 2009). OPEN is a flexible and tailored process framework that covers business, quality, modeling, and reuse issues within the SDLC (Henderson-Sellers and Unhelkar, 2002). A number of opportunities exist to embed Agility within the OPEN framework. For example, the "Build" method fragment can easily make use of most practices of Agile. Similarly, opportunities for inserting Agile principles and practices within the development and testing method fragments exist within OPEN. OPEN also bases itself on the fountain model of software development (see the sidebar). Hence, OPEN is inherently iterative and incremental.