The Incremental Commitment Model Process Patterns
for Rapid-Fielding Projects
Supannika Koolmanojwong and Barry Boehm Center of Systems and Software Engineering
University of Souther California Los Angeles, CA 90089-0781 {koolmano, boehm}@usc.edu
Abstract. To provide better services to customers and not to be left behind in a competitive business environment, a wide variety of ready-to-use software and technologies are available for one to grab and build up software systems at a very fast pace. Rapid fielding plays a major role in developing software systems to provide a quick response to the organization. This paper investigates the appropriateness of current software development processes and develops new software development process guidelines, focusing on four process patterns: Use single Non-Developmental Item (NDI), NDI-intensive, Services-intensive, and Architected Agile. Currently, there is no single software development process model that is applicable to all four process patterns, but the Incremental Commitment Model (ICM) can help a new project converge on a process that fits their process drivers. This paper also presents process decision criteria in terms of these drivers and relates them to the ICM Electronic Process Guide.
Keywords: Software Process Modeling and Representation, Software Process Guidelines, Non-Developmental Item (NDI), Net-Centric Services (NCS), Rapid Fielding, Rapid Applications
1 Introduction
The growing diversity of software systems (requirements-driven, Non-Developmental-driven, services-driven, learning-driven, qualities-driven, systems of systems) has made it clear that there are no one-size-fits-all processes for the full range of software systems. Rapid Fielding is becoming an increasingly important software system objective. To fit into market windows and respond to competition, several possible process patterns can be used. Some process models are being developed that provide specific evidence-based and risk-based decision points. One of the most thoroughly elaborated of these models is the Incremental Commitment Model (ICM) [1]. To quickly select and follow the appropriate process pattern helps the development to finish the project faster and more efficiently. Overall characteristics of each process pattern and the ICM decision points have been defined on a general-experience basis [2] but process guidelines and process selection
decision criteria are lacking on the ability to help produce a viable process decision early in the life cycle.
For rapid-fielding projects, current technologies like Net-Centric Services (NCS) and Non-Developmental Items (NDI) provide ready-to-use functionalities, which in turn speed up the software development process. In addition, agile process with agile-ready people can provide faster time to market [3]. NDI, such as COTS, open source software or free library, plays crucial roles in today’s software development [4]. Considering the tendency toward net-centric services usage, reflected in USC’s Software Engineering Class Projects [5], Fig. 1 shows an increasing trend in using net centric services in real-client software development projects. A similar trend is shown in the industry: 80% of the world economy provides services in various forms [6]. Based on programmableweb.com [7], there are at least 3 new mashups or web service extensions created and listed at this website every day. The users who are consuming these services need to know how to select the right service and utilize the service properly. The service-intensive or NDI-intensive application developers need to choose the appropriate process guidelines.
Fig. 1 Net Centric Services Usage in Software Development Projects in USC Software Engineering Class
This paper presents three new software development processes, for Architected Agile, Use single NDI, and Services-Intensive, and one updated software development process, NDI-intensive, which are extended from Yang and Boehm’s COTS-Based Application Development guidelines (CBD) [8] by applying the risk-driven approach of the ICM and feedback from Bhuta’s empirical analysis on COTS interoperability assessment [9]. This paper also reports the current rapid-fielding software development process investigation and analysis, the decision driver of process pattern selection, and the software development process guidelines for 4 process patterns which are implemented and represented in terms of the electronic process guide.
This paper is organized as followed: Section 2 contains background information of the ICM, the differences between NDI and NCS, and USC Software Engineering course. Section 3 provides information about the nature of rapid-fielding projects, process decision drivers, process selection graph, and the ICM EPG. Section 4 contains preliminary empirical project results on process selection and on the results of process usage. Section 5 provides conclusions and future work.
2 Background
2.1 The Incremental Commitment Model (ICM)
The ICM [2] is a new generation process model. ICM covers the full system development life cycle consisting of the Exploration phase, Valuation phase, Foundations phase, Development phase, and Operation phase. ICM has been evaluated to be a flexible but robust framework for system development [2]. The core concepts of the ICM include 1) commitment and accountability of system stakeholders, 2) success-critical stakeholder satisficing, 3) incremental growth of system definition and stakeholder commitment, 4) concurrent engineering, 5) iterative development cycles, and 6) risk-based activity levels and milestones. One of the main focuses of the ICM is feasibility analysis; evidence must be provided by the developer and validated by independent experts. The ICM combines the strengths of various current process models and limits their weaknesses. The ICM, like the V-Model [10], emphasizes early verification and validation, but allows for multiple-incremental interpretation and emphasizes concurrent rather than sequential engineering. Compared to the Spiral Model [11], the ICM also focuses on risk-driven activity prioritization, but offers an improvement by adding well-defined in-process milestones. While ICM, RUP, and MBASE [12] perform concurrent engineering that stabilizes the software process at anchor point milestones, ICM also supports integrated hardware-software-human factors oriented development. Comparing with Agile methods [3], ICM embraces adaptability to unexpected change and at the same time allows scalability. In [2], it shows how the ICM can be applied to a broad spectrum of software-intensive systems processes, which are categorized into 12 process patterns as follows: Use Single NDI, Agile, Architected Agile, Formal Methods, Hardware with embedded Software component, Indivisible Initial Operational Capability, NDI- intensive, Hybrid agile/ plan-driven system, Multi-owner system of systems, Family of systems, Brownfield, and Services-Intensive.
2.2 Process Patterns of Software Development Project
For the small e-services projects developed in our project course, four of the 12 process patterns of the ICM [15] predominate:
• Architected Agile - For less than 80 agile-ready-people team size and a fairly mature technology project, agile methods can be scaled up using an Architected Agile approach emphasizing early investment in a change-prescient architecture and all success-critical-stakeholders team building [2]. The Valuation phase and Foundations phases can be brief. A scrum of Scrums approach can be used in the Development phase. For example, a database application project that majority of the implementation tasks are building the right architecture and custom coding. • Use Single NDI – When an appropriate NDI (COTS, open source, reuse library,
customer-furnished package) solution is available, it is an option to either use the NDI or develop perhaps a better version by oneself or outsource such a
development which generally incurs more expense and takes longer to begin capitalizing on its benefits. On the other hand, an NDI may come with high volatility, complexity, or incompatibility. Major effort will then be spent on appraising the NDI. For example, an accounting system that could be totally satisfied by using a single ready-made accounting management software.
• NDI-Intensive –NDI-Intensive system is a system where 30 - 90% of end-user functionality is provided by NDI [4]. A great deal of attention goes into appraising the functionality and interoperability of NDI, effort spent on NDI tailoring and Integration, and NDI upgrade synchronization and evolution [14]. For example, a website development project that majority of the functionalities are provided by one or more read-made software, but needs additional custom coding, tailoring or glue coding.
• Services-Intensive –Net Centric Services support community service organizations in their online information processing services such as donation, communication or their special interest group activities such as discussion boards, file sharing, and cloud computing. Similar to NDI-Intensive, the focus goes to appraising the functionality of the available services and tailoring to meet needs. For example, a website development project that some functionalities are provided by other online services and may need additional custom coding, tailoring or glue coding.
The proposed four process patterns of software development processes in ICM are developed by combining strengths from several development processes. The Architected Agile case balances a plan-driven approach in building up the steady architecture and an agile-driven approach in iterative incremental and frequent delivery as practice in Scrum [16] or Agile Unified Process [3]. The Software Engineering Institute (SEI) CMMI-COTS [17] and USC-CSSE COTS-Based Development (CBD) Guidelines [8] provide strong foundations for Use Single NDI, NDI-Intensive or COTS-Based systems (CBS). Regarding Services-Intensive, most of the processes, including CMMI-SVC [6], cover only the process of how to develop and maintain web services. None of them are able to pick, choose and use available online services.
Although the Services-Intensive case is similar to the NDI-intensive case, we found that the differences between NDI and NCS shown in Table 1 below make the CBD guidelines an imperfect fit with a Services-Based development process.
Table 1. Differences between NDI and Net-Centric Services Category Non-Developmental Item
[ includes open source, customer-furnished software]
Net-Centric Services
Payment • Some tools have no monetary cost • Expensive initial costs, moderate
recurring fee, training fee, licensing arrangement-dependent
• Free/ pay per transaction
• Low initial costs, moderate marginal cost, duration depending license Platform • Specific/ limited to specific platform
• Generally supported on a subset of platforms or multiple platforms but with different editions
• Platform and language independent; • Server /client can be on different
platform
• Machines Interaction over a network Integration • Generally more tightly coupled
• Not very flexible on existing legacy systems when proprietary standard
• Generally more loosely coupled • Common web standards • Requires internet access
• Difficult when platform dependent and different technologies involved in it. • detailed documentation and on-site
extensive support
• Support forums /API documentation • Integration could be done merely in
code, without additional installation of external component
Changes • Version freezable, under user control • Designed for specific use so costly for
customization and change
• Change on server side doesn’t impact the client side
• Major releases once in a while
• Requires end user intervention to upgrade
• Out of developers/users’ control • Not easy to predict change
• End-user has the latest version Change on the server side can result in the client side
• Minor releases frequently (through patching)
• Does not require end user intervention Extensions • Only if source is provided and the
license permits
• Extension must be delivered to and performed at the end-user’s site
• Custom extensions may not be
compatible with future releases
• Extension is limited to data provided by the web services
• In-house extension such as wrapper or mashup
• Little control over performance overhead
Evaluation Criteria
• Cost, size, extensibility, scalability, reliability, dependency, support, maintainability, upgrades, access to source, code-escrow considerations • Upfront costs opposed to subscription
• Platform compatibility; Feature
controllability
• Cost, reliability, speed, support availability, predicted longevity of the service provider, bandwidth
• Recurring costs to use of the service and future functionality offered • Standards compatibility; Feature- data
controllability Support
Services
• Support sometimes available for a fee • Help topics or FAQs would likely not
be updated after installation • Upgrades/ data migration support • Can be customized for specific user • Upgrade through purchasing new
releases, self-install
• Support generally not available • Help topics frequently updated;
self-learning
• Usually not customized
• Patching on service provider’s side; mostly not require installation on client side
Data • Data often stored locally. • Backups: responsibility of the user • Data access is generally fast • Possible variety of proprietary formats • May be inflexible but more secure • Platform-dependent data format • Can process data offline
• Data stored on host’s servers. • Backups by provider • Data access could be slower • Common XML standard
• Data from different web services can be used by a single client program • Process data online
Table 2. Characteristics of the Rapid-Fielding Process Patterns
Process patterns Architected Agile
Use Single
NDI NDI- intensive
Services-intensive
Example Business data
processing Small accounting Supply chain management Community Services
Size, Complexity Med Med-High Low-Med
Change Rate (%/Month) 1-10 0.3-3 0.3-3
Criticality Med-High Med-Very High Low-Med
NDI Support Good; most in place Complete NDI-driven architecture Tailorable service elements Organizational and Personnel Capability Agile-ready Med-high NDIexperienced; med-high NDI- experienced Time/Build; Time/Increment 2-4 wks; 2-6 months SW:1-4 wks; Systems: 6-18 mos <= 1 day; 6-12 months
Table 2 summarizes the overview characteristics of rapid fielding projects in each process pattern. As shown in Fig. 2, different risk patterns for each project yields different software processes. For example, in the second case, when in the Exploration phase, the developers spend a good amount of effort to explore and find a perfect NDI that satisfied all the win conditions, the development team could skip the Valuation and Foundations phase. In the third and the fourth case, if the development team found possible NDIs/NCSs in the Exploration phase, the team could spend more effort evaluating the NDIs/NCSs, prioritizing their win-conditions or constraints. On the other hand, since NDIs/NCSs will provide a majority of the end product features, the development team could spend less time in Foundations and Development-related efforts. But NDI and NCS have different risk patterns; hence they need different process to follow.
Fig. 2 Different Risk Patterns yield Different Processes
2.3 USC Software Engineering Course
In the keystone two-semester team project graduate software engineering course sequence CS577ab [5] at USC, students learn through experience how to use good software engineering practices to develop software systems from the Exploration Phase to the Operation Phase, all within a 24-week schedule. Six on-campus and two off-campus students team up to develop real-client software system products. All teams will follow the ICM Exploration Phase guidelines to determine their most appropriate process pattern. Most of the clients are neighborhood non-profit organizations, small businesses or USC departments. Because of the semester break between Fall and Spring semester, for the Software Engineering class, we added a short Rebaselined Foundations phase to accommodate the possible changes.
3 Rapid-Fielding Process Guidelines
3.1 The Incremental Commitment Model for Rapid Fielding Projects
As shown in Fig. 4, a rapid fielding project starts by identifying the objectives, constraints and priorities (OC&P) and exploring all possible software development alternatives. If there is no relevant NCS or NDI that would satisfy the OC&Ps and OC&Ps cannot be adjusted, then this project will proceed to follow the Architected Agile process. The first three phases will be focused on building a change-prescient architecture and user/developer/customer team building. In the development phase and operation phase, with the agile techniques, the developers welcome and manage change through a product backlog, planning capabilities for multiple future increments, based on stakeholder priorities.
On the other hand, if there are possible NDI/NCSs that satisfy the project’s OC&Ps, the project will proceed with either Use Single NDI, Services-Intensive, or NDI-Intensive process pattern. In the Exploration and Valuation phase, spend a good amount of time in assessing NDI/NCS candidates. If multiple candidates are required, one needs to analyze their interoperability. When the selected NDI/NCS provides full or partial functionalities, the foundations phase could be skipped or shorten. In the development phase, perform custom coding, tailoring or glue coding as required.
For all rapid-fielding projects, synchronization and stabilization are required for each and between development cycles. Continuous verification and validation is also required for quality assessments.
3.2 The Incremental Commitment Model – Electronic Process Guide (ICM EPG)
Having properly-defined software process models is essential, but the ability to effectively communicate those models to the software engineers is also important. For Software Engineering class at USC, we have been using the IBM Rational Method Composer (RMC) to develop an Electronic Process Guide (EPG) for the ICM. The ICM EPG enables process users/ students to understand the overall process as well as specific areas of focus. The ICM EPG as shown in Fig. 4, describes the software development process by providing guidance in multiple-view representations, which are role-based representation, activity-based representation, chronological event-based representation, and artifact-event-based representation. Moreover, additional artifact templates and supplementary guides have been demonstrated to speed up the users’ learning curve and support them in their development process [18,19].
3.3 Process Decision Drivers
In order to select the appropriate process pattern, the development team will use the 16 decision drivers presented in Table 3 to evaluate the project status and map it with the possible maximum-minimum boundary range of each possible process pattern. The “Importance” attribute, whose values are 1-Low, 2-Medium, 3-High, will act as a tie breaker to support decision making in selecting the best fit process pattern. The value of project status ranges from 0-Very Low to 4-Very High.
Table 3. Process Decision Drivers
Fig. 5 shows an example of a website development team. The team found a possible content management system NDI, but it does not satisfy all of the capability win conditions. The team rates the project status based on 16 decision drivers, the result is shown in the blue line. The background block diagram is the max-min boundary of NDI-Intensive project defined in Table 3. The red underline represents High Importance level, while green dashed underline represents Low Importance level.
Fig. 5 An example of using decision drivers to map project status with the NDI-Intensive process pattern
When the blue point lies on gray box, it shows that the project status conform to the process pattern on that driver. As a result, the decision driver shows that this team could follow the NDI-intensive software development process. On the other hand, as shown in Fig. 6, if we plot the project status on the Architected Agile process pattern, 8 non-conforming points are found. As a result, comparing Fig. 5and Fig. 6, there are less non-conforming points on Fig. 5, so that means this project would fit more to the NDI-Intensive process pattern.
Fig. 6 An example of using decision drivers to map project status with the Architected Agile process pattern
4 Preliminary Results
In Fall 2009, Software Engineering students at USC have used the ICM EPG to guide their rapid-fielding software development projects. Once the students form their teams and select the projects, teams will follow the ICM Exploration phase process to determine their most appropriate process patterns. 28% of projects are able to deliver in one semester, instead of two semesters comparing to 12.5% from previous year. Clients are highly satisfied with the project results.
4.1 Preliminary Results on the ICM EPG
With the data from effort reporting system, Table 4 shows that with the ICM EPG, process users and developers spent less time in learning about the process and with the help of templates and supporting documents, they saved more than 20 hours per person in documentation effort.
The result of our experiment also shows that the EPG is very effective in terms of communicating the process model to the developers. With the role-oriented process information and rich set of notations such as process element icons and graphical representations, process users and developers found that it is easy for them to learn about their roles, responsibilities, activities, and functionalities. For the process engineers, IBM Rational Method Composer (RMC) supports process reuse, tailoring and configuration. The ICM EPG can be extended to support process management because RMC is fully interoperable with various project management tools.
Table 4. Comparison of effort between paper-based guidelines and the ICM EPG Guidelines \ Average Effort (hours) Learning Documentation Total Effort
Paper-based process guidelines 15.2 69.2 209.57
4.2 Preliminary Results on the Process Decision Drivers
Comparing the result of the teams’ process selection by using process decision drivers with the experts’ opinion from the architecture review board, 8 out of 14 teams selected the right process pattern from beginning of the valuation phase. Three out of 14 teams selected wrong process pattern because of unclear project scope, but the teams followed the right process after further exploration, more prototyping or found available NCS/NDI. Two out of 14 teams faced the minor changes, so they have to change the process by the end of Valuation phase. One project followed the right process pattern but found that the client’s requirement is infeasible within a defined budget and schedule, hence the team proposed the feasible solution and had to switch the process 3 times. In addition, based on the survey result, the process decision drivers help the teams to select the most suitable process pattern. Moreover, when the scope or status of the project changes, the development teams found it useful to reconfirm or to re-identify the process pattern with the process decision drivers.
4.3 Limitations
This section discusses possible validity threats and ways in which the threats could be reduced.
• Inconsistent Effort Reporting: It is possible that there might be inaccurate efforts reported, so 2 forms of effort reporting will be used.
• Non-representativeness of subjects: On-Campus students might not represent software engineers in the industry. However, the clients and off-campus students are full-time working professionals.
• Learning Curve: Providing tutorials and discussion sessions in order to build the foundations for all participants.
• Non-representativeness of projects: Although conforming to fixed semester schedules, this is to some degree representative of fixed-schedule industry projects. The projects are small e-services applications, but are developed for real clients, and used the same NDI/NCS. Moreover, the process guidelines and decision drivers are cross checked with experts in the field for enterprise-level compatibility.
5 Conclusions and Future Work
The growing diversity of software systems and the wide variety of current technologies provide us new opportunities for rapid-fielding strategy. The Incremental Commitment Model (ICM) is the most thoroughly elaborated process model with specific evidence-based and risk-based decision points. Architected Agile, Use Single NDI, NDI-intensive, and Services-intensive are four common ICM process patterns in rapid-fielding project. Four process guidelines are developed in the form of the ICM EPG. The result of the experiment shows that, at least for small, real-client e-services project, the EPG is very effective in terms of communicating and learning the process model and speeding up the development process. The process
pattern decision drivers help the development teams produce a viable process decision very early in the life cycle process with faster time to market and high customer satisfaction. Continuing efforts are underway to evaluate the efficacy of the ICM by analyzing risk patterns, incidence of direction changes at reviews relative to outcomes and team performance based on team grading and compare to previous years data.
References
1. Pew, R.W., Mavor, A.S.: Human-System Integration in the System Development Process: A New Look. National Academy Press (2007)
2. Boehm, B., Lane, J., Koolmanojwong, S.:A Risk-Driven Process Decision Table to Guide System Development Rigor. In: Proceedings of the 19th International Conference on Systems Engineering, Singapore, July, (2009).
3. Agile, Principles behind the agile manifesto, http://agilemanifesto.org/principles.html. 4. Yang, Y.,: Composable Risk-Driven Processes for Developing Software Systems from
Commercial-Off-The-Shelf (COTS) Products,: PhD Dissertation, Department of Computer Science, University of Southern California, December (2006)
5. USC CSCI577ab Software Engineering Course,
http://greenbay.usc.edu/csci577/fall2009/site/index.html
6. CMMI for Services Version1.2, ftp://ftp.sei.cmu.edu/pub/documents/09.reports/09tr001.doc 7. ProgrammableWeb http://www.programmableweb.com/mashups accessed on 11/9/2009 8. Yang Y. and Boehm B.: COTS-Based Development Process guidelines,
http://greenbay.usc.edu/csci577/spring2007/site/guidelines/CBA-AssessmentIntensive.pdf Accessed 08/24/07
9. Bhuta, J.,: A Framework for Intelligent Assessment and Resolution of Commercial-Off-The-Shelf Product Incompatibilities” PhD Dissertation, Department of Computer Science, University of Southern California, August (2007)
10.V-Model Lifecycle Process Model http://www.v-modell.iabg.de/kurzb/vm/k_vm_e.doc accessed on 10/9/2009
11.Boehm B,: A Spiral Model of Software Development and Enhancement, In: IEEE Computer, 21(5):61-72, May (1988)
12.Boehm B, Anchoring the Software Process, IEEE Software, v.13 n.4, p.73-82, July 1996 13.Boehm, B. Turner, R..: Balancing agility and discipline: a guide for the perplexed.
Addison-Wesley, Boston. (2004)
14.Li, J.; Bjoernson, F.O.; Conradi, R.; Kampenes, V.B.: An empirical study of variations in COTS-Based Software Development Processes in Norwegian IT industry. In: Journal of Empirical Software Engineering vol. 11, no.3, pp 433-461 (2006)
15.Boehm, B., Lane, J. and Koolmanojwong, S.: A Risk-Driven Process Decision Table to Guide System Development Rigor, In: Proceedings of the 19 th International Conference on Software Engineering, Singapore, July, 2009.
16.Rising, L., & Janoff, N. The Scrum Software Development Process for Small Teams. IEEE Software, July/August 2000
17.CMMI for COTS-based Systems,
http://www.sei.cmu.edu/publications/documents/03.reports/03tr022.html
18.Koolmanojwong, S., et.al,: Comparative Experiences with Software Process Modeling Tools for the Incremental Commitment Model, In: USC CSSE Technical Report 2007-824 19.Phongpaibul, M., Koolmanojwong, S., Lam, A., and Boehm, B., : Comparative Experiences
