There are several frameworks, models, and prac- tices that guide agencies in acquiring software- intensive systems. These include the software acquisition capability maturity model (SA-CMM; Cooper & Fisher, 2002), the supplier agreement management process of capability maturity model integration (CMMI; CMMI Product Team, 2001), IEEE’s (1998b) Recommended Practice for
Software Acquisition, and the C4ISR architecture framework (Department of Defense [DoD] Ar- chitecture Working Group, 1997).
SA-CMM offers a framework for organiza- tional improvement, and it focuses on building the acquisition-process capability of an organiza- tion. It defines five levels of software-acquisition process maturity.
The CMMI supplier agreement management process area is targeted to manage the acquisition of products from suppliers for which there exists a formal agreement. It has a context for system and software acquisition, and remains more generic when compared to other models. It includes the practices for determining the type of acquisition that will be used for the products to be acquired, selecting suppliers, establishing and maintaining agreements with suppliers, executing the supplier agreement, accepting delivery of the acquired products, and transitioning acquired products to the project.
The Software Engineering Institute’s (SEI) models and practices specified above describe what characteristics the acquisition process should possess, and do not mandate how the acquisition process should be implemented or who should perform an action. In other words, neither of them guides as an acquisition life cycle. IEEE’s (1998b) Recommended Practice for Software Acquisition offers such a life cycle for a typical software-acquisition process, which primarily includes planning, contracting, product imple- mentation, product acceptance, and follow-on phases. IEEE defines and relates one or more steps to each of these phases, as given in Table 1. It should be noted that these steps might overlap or occur in a different sequence, depending upon the organizational needs.
Another model, which was primarily devel- oped and has been used for military acquisitions at the U.S. Department of Defense, is the C4ISR
Table 1. Software-acquisition phase milestones (IEEE, 1998b)
Phase Initiation Phase
Milestone
Phase Completion
Milestone Steps in Software-Acquisition Process
Planning Develop the idea Release the RFP 1) Planning organizational strategy2) Implementing organization’s process 3) Determining the software requirements
Contracting RFP is released Sign the contract
4) Identifying potential suppliers 5) Preparing contract requirements 6) Evaluating proposals and selecting the supplier
Product
Implementation Contract is signed Receive the software product 7) Managing supplier performance Product Acceptance Software product is received Accept the
software product 8) Accepting the software Follow On Software product is
accepted
Software product is no longer in
Architecture Framework (DoD Architecture Working Group, 1997). This framework provides the rules, guidance, and product descriptions for developing and presenting architecture descrip- tions of the systems to be acquired. The aim of this effort is to ensure building interoperable and cost-effective military systems.
The DoD Architecture Working Group (1997) defines an architecture description in the C4ISR architecture framework as “a representation, as of a current or future point in time, of a defined domain in terms of its component parts, what those parts do, how those parts relate to each other, and the rules and constraints under which the parts function” (p. 2-1). There are three major views that logically combine to describe architecture: the operational, systems, and technical views. Since each view provides different perspectives on the same architecture, DoD suggested using an “integrated” description that would provide more useful information to the planning, pro- gramming, and budgeting process and to the acquisition process. Figure 1 shows the linkages that describe the interrelationships among the three architecture views.
One of the primary reasons underlying the definition of these models is to develop a mecha- nism to appropriately define the requirements of a software-intensive system, which will be taken as a basis by both acquirer and supplier organizations throughout the acquisition. Defin- ing software-intensive system requirements is not straightforward; it requires extensive under- standing of the domain and representing domain knowledge formally and visually, not getting lost in the domain and skipping any point, as well as enabling the ease of understanding and health of validation. There are several approaches and related techniques used to gather domain knowl- edge, including functional approaches such as data flow diagrams (DFDs), scenario-based approaches such as use cases, and business-process-oriented approaches such as business process modeling.
Business process modeling is a technique used to understand, depict, and reorganize business processes of an organization. Davenport (1993) defines a process as “a specific ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs: a structure for action” (p. 5). A business process
Figure 1. Fundamental linkages among the views (DoD Architecture Working Group, 1997)
operational view
(identifies information needs and warfighter
relationships)
technical view
(prescribes standards and conventions)
system view
(relates capabilities and characteristics to operational requirements) Processing and levels of information exchange requirements Basic technology, supportibility and new capabilities Systems associations to nodes, activities, needlines and requirements Processing and inter-nodal levels of information exchange requirements
Specific capabilities identified to satisfy information exchange levels and other
operational requirements Technical criteria governing interoperable implementation /
procurement of the selected system capabilities
defines how an organization achieves its purpose including its vision and goals.
The analysis and design of business processes are the major tasks of business process reengineer- ing (Hammer & Champy, 2001; A. W. Scheer, 1994). Business process modeling has been implemented by a large number of organizations as part of business process reengineering during the last decades (Davenport, 1993; Hammer & Champy). It is claimed that it adds the most value when the application environment is complex and multidimensional, and many people are directly involved in using the system (Yourdon, 2000).
The analysis of business processes requires understanding the current business processes of the organization before designing the new ones. Especially in complex organizations, there is no way to migrate to a new process without under- standing the current one. Existing business process models enable participants to develop a common understanding of the existing state, and are used to establish a baseline for subsequent business process innovation actions and programs. The design of business processes is performed before implementation of the system in order to translate the requirements of the business process innova- tion into proposed system requirements. Existing business processes are the foundation of this kind of study for finding out the weak points. When designing the new system, it is worthwhile to try to describe the new processes based on the business objectives to respond to business requirements (Cummnis, 2002). The target process models serve as the foundation for implementing the new business processes and defining the requirements for new information technology systems.
As a result, business process modeling brings the following advantages to the requirements elicitation of software-intensive systems. • Brings broader view to business domain • Creates a common language between ana-
lysts and customers or users, leading to an
increase in customer and user participation in the requirements-elicitation process • Increases efficiency in determining deficien-
cies in the current business processes and modeling the target business processes • Helps in identifying business requirements
as the knowledge is captured at a more abstract, business-need level than many other specification approaches (Demirörs, Demirörs, Tanik, Cooke, Gates, & Krämer, 1996; Wiegers, 1999).