Incremental Commitment Model Process Guidelines

for Software Engineering Class

Supannika Koolmanojwong, Pongtip Aroonvatanaporn, Itti Charoenthongtrakul

Center of Systems and Software Engineering

University of Souther California

Los Angeles, CA 90089-0781

{koolmano, aroonvat, icharoen}@usc.edu

Abstract. Effectively communicating the software process model to the

software engineers is essential in enabling them to understand the overall

process as well as specific areas of focus. To satisfy the objective of helping

students learn the software processes, an Electronic Process Guide (EPG) for

the Incremental Commitment Model (ICM) has been developed by the

University of Southern California (USC) Center for System and Software

Engineering (CSSE) and has been experimented for its efficiency and

effectiveness by software engineering students. This paper reports on the

experimental results of utilizing the EPG of the ICM process to develop

software systems comparing with the use of traditional paper-based guidelines

in the past. The analyses focus on both quantitative and qualitative aspects of

the software development process based on the objectives defined by

Humphrey and Kellner [8], process model characteristics defined by Fuggetta

[1], people-oriented process information aspects by Heidrich, et al. [6], and

students’ performances and feedbacks.

Keywords: Software Process Modeling, Electronic Process Guide, Incremental

Commitment Model, Software Engineering Course

1 Introduction

Having a properly defined software process models is essential, but the ability to

effectively communicate those models to the software engineers may prove to be far

more important. One of the key criteria defined by Humphrey and Kellner for having

an effective process model is its effective communication [9]. This paper discusses

about the use of EPG to model a software process and compare its usages to the

traditional paper-based version.

In the two-semester team project based software engineering course sequence

CSCI577ab at USC [20], students learn to use best software engineering practices to

develop software systems for real clients. In most situations, students were given the

paper-based guidelines to study and reference throughout the software development

process. However, as stated by Kellner, the paper-based, or the narrative version of

the guidelines, lacks the abilities to represent the big picture of the entire software

process [12]. The appropriate way to model the process is to enable multiple views of

the process such as task-oriented and role-oriented views allowing the readers to

understand the process from various perspectives [5,8,14]. Furthermore, graphical

representation of the process has been found to be more effective at communicating

the process than pure textual representation [12]. The EPG allows for both graphical

and textual representation of the process models.

In 2000, the Model-Based (System) Architecting and Software Engineering

(MBASE) process was electronically modeled using the Spearmint tool and was used

by the software engineering course; however, due to its maintenance difficulties, it

was no longer used by the software engineering course and rolled back to the paper-

based version in 2003. The tools to model processes have advanced since then, and in

2007, the Rational Method Composer (RMC), Little-JIL, and EPF Composer were

chosen to attempt to model the Incremental Commitment Model (ICM) [15].

Ultimately, the RMC was chosen to be the tool of choice to model the ICM and the

modeled guideline was first used by the software engineering class in Fall 2008.

In this paper, we observe the results of using the EPG in the software engineering

course to develop software systems and compare it with the results of using the paper-

based guidelines in the previous year. We focus on both the quantitative and

qualitative results based on the criteria of an effective software process model defined

by Fuggetta, Humphrey, and Kellner [5,8,12].

This paper is organized into 5 sections. Following the introduction, section 2

introduces the adapted version of the ICM and the tool used to model the process.

Section 3 describes in detail about the process itself and how it was modeled into an

EPG. In section 4, we discuss about the experimental results observed from

comparing the use of the EPG with the use of the paper-based guidelines. Finally, the

paper is concluded in section 5 with the discussion on research challenges and future

research possibilities followed by the references.

2 Background and Overview

2.1 Instructional Incremental Commitment Model for Software

The Incremental Commitment Model (ICM) is a new generation process model.

Instead of focusing only on the product development, the principles of ICM are the

satisfaction of the success-critical stakeholder and the incremental growth of system

definitions and stakeholder commitments. 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 reasonably

robust framework for system development [16]. However, there is currently no

evidence of the its success in software-intensive projects. As an initial step to

evaluate ICM in software projects, in 2008, we introduced ICM as a model to develop

software system to a graduate software engineering course (CSCI577) at USC.

In order for the ICM process to be usable by the software engineering course, it has

been tailored to aim the process at software development as well as reducing the

scope to fit the 2-semester, or 24-week, time schedule for an 8-person development

team (6 on-campus and 2 off-campus students). We call this version of ICM as the

Instructional Incremental Commitment Model for Software (IICM-Sw) [19].

As an initial experiment, the EPG is built to model the life cycle of the IICM-Sw

process in detail up to the end of the first semester from Exploration phase to the end

of the Foundations phase. Of the various roles defined in the IICM-Sw, the on-

campus students take on the roles of Project Manager, Operational Concept Engineer

(OCE), Requirements Engineer (RE), System/Software Architect (SA), UML

Modeler, Life Cycle Planner (LP), Feasibility Analyst (FA), and Prototyper, while the

off-campus students take on the roles of Quality Focal Point and Integrated

Independent Verification and Validation (IIV&V). However, the scope of experiment

for this paper covers only the process of operational concept development, system and

software requirements development, system/software architecture development, life

cycle planning, and feasibility evidence development. The artifacts generated to

capture the results of these activies are the Operational Concept Description (OCD),

System and Software Requirements Description (SSRD), System and Software

Architecture Description (SSAD), Life Cycle Plan (LCP), and Feasibility Evidence

Description (FED) respectively.

2.2 IBM Rational Method Composer

The IBM Rational Method Composer (RMC) is a process management platform that

integrates best practices of the Rational Unified Process (RUP) framework and

provides process content library, delivery processes, and capability patterns allowing

for process engineers to author, configure, view, and publish your software

development process [10]. There are two main purposes of the RMC [6]. Firstly, the

RMC acts a content management system that you can store, maintain and publish

your knowledge base of process contents to development practitioners. Secondly, its

purpose is to provide a tool for process engineers to select, tailor, and assemble

process contents that fit to their specific development projects.

3 Instructional Incremental Commitment Model for Software:

Electronic Process Guide (IICM-Sw EPG)

We have created an EPG of the IICM-Sw by using RMC. In this section, we will

discuss in further detail on how we used the tool to represent our software

development process.

3.1 Representation of Process Elements and Their Relationships

RMC represents process elements in terms of roles, tasks, work products, and

guidance as shown in the left panel of Fig. 1. A task is composed of steps, while a

work product can be categorized into artifacts, deliverables, and outcomes.

Furthermore, there are many kinds of guidance such as templates, examples,

guidelines, concepts, and tools. A process engineer can provide detailed descriptions

of each element in the forms of pure texts, hyperlinks, html-embedded texts, or

pictorial representations. Each process element notation is represented by

comprehensive and easy to understand graphical representations.

Fig. 1 Defining Relationship between Process Elements

RMC provides an easy way to assign relationships between each process element.

The left panel of Fig. 1 shows the process content library for feasibility evidence

development practice, which mainly comprises of tasks, work products, and guidance.

The bottom tabs of the right panel allows a process engineer to assign the primary and

secondary roles responsible for the task, specify the input and output work products,

and identify the related guidance, as in this case, for the “analyze_business_case”

task. Additionally, a process engineer can illustrate the relationships between a

particular role and his/her responsible tasks and work products, which can be output

in the form of an interactive graphical representation as shown in Fig. 2.

Fig. 2 Relationship between roles, tasks, and work product

In IICM-Sw EPG, we have created 6 practices, which are Operational Concept

Development Practice (Fig. 3), System and Software Requirements Development

Practice, System and Software Architecture Development Practice, Life Cycle

Planning Practice, Feasibility Evidence Description Practice, and Quality

Management Practice, 13 roles, 36 tasks, 15 work products, 9 examples, 9 templates,

9 guidelines, and 2 concepts.

Fig. 3 View of Operational Concept Development Practice

3.2 Process Representation

After all the process elements and their relationships have been defined, a process

engineer can configure the process framework by defining the time lines, such as

phases, iterations, and milestones, and constructing the work breakdown structure,

team allocation, and work product usage by assigning activities and the associated

tasks in the appropriate time lines. Fig. 4 shows that there are 6 phases and 5

milestones for software development in CSCI577ab software engineering class. With

the interactive interface, when the user double-clicks on a particular phase, the EPG

will display a flow of activities represented in an activity diagram. Furthermore, once

the user clicks on each activity, the EPG will show a list of related tasks for that

particular activity as shown in Fig. 5.

Finally, the view, or structure, of the published process can be customized in order

to fit one’s development project or type of project. Firstly, the list of navigation

menus can be created based on the views and pages that would facilitate the page

navigation of users or development practitioners. Secondly, the process elements can

be grouped together to specify elements that are related such as templates or example

documents. Lastly, the grouping of the process elements allows for various views to

be created for users, such as role-oriented or task-oriented views. This enables the

users to view the process from different perspectives, while allowing them to easily

navigate to their targeted process elements. As shown in Fig. 4, in the left panel, we

provide navigation including lists of practices, tasks, roles, work product, and etc. for

the students to navigate. The output is then displayed in the right panel.

Fig. 4 Incremental Commitment Model Life Cycle Process View

Fig. 5 View of Activities and Tasks in Valuation Phase

4 Experimental Results

In Fall 2008, Software Engineering students at USC have used the IICM-Sw EPG

to guide their software development projects. In this section, we will provide analyses

on the data of students’ efforts spent in their projects and the results comparing the

use of the EPG and the use of the paper-based guidelines. We have evaluated the EPG

based on process model objectives defined by Humphrey and Kellner [8] and good

characteristics of process modeling tools defined by Fuggetta [5]. Additionally, we

will discuss about the qualitative results based on the feedbacks provided by the

Software Engineering students who have used this EPG.

4.1 Instructional ICM-Sw EPG Analysis

Firstly, we analyzed the EPG by using Humphrey and Kellner [8]’s four objectives of

a good software modeling process tool, we found that

- In enabling effective communication regarding the process, RMC not only

provides basic process elements representation such as roles, tasks, and artifacts

or additional representations such as checklist, tool mentor, and template, but also

allows you to create special types of process elements with customized notations

to fit with your development projects. This empowers the process engineers with

more alternatives to provide guidance and various types of supporting materials.

- In facilitating process reuse, RMC clearly separates the method contents and

process contents, so the process engineer can tailor the method content without

affecting the process content, and vice versa. For example, when a process

engineer creates a new delivery process or an activity diagram, the current tasks

and roles can be reused as needed.

- In supporting process evolution, per our initial set of guidelines, the EPG

currently does not provide complete set of information that will be enough for

process adaptation and evolution. On the other hand, since RMC fully supports

process tailoring and configurations, the EPG can surely be extended to support

process evolution.

- In facilitating process management, RMC is fully interoperable with project

management tools such as the IBM Rational Team Concert [12], IBM Rational

Portfolio Manager [11], and Microsoft Project [16]. Although the current version

of the EPG does not provide project management facilities, it will be our

challenge in the future to pick the right tool to integrate with software

engineering class as well as to fit the nature of the development projects.

Secondly, to enable effective communication among various stakeholders, it is

important to use nomenclatures that will be widely comprehensible. RMC provides a

rich set of notations such as process element icons and graphical representations in the

delivery process descriptions and activity diagrams. Based on the criteria of good

notations proposed by Humphrey [9], we evaluated notations provided in RMC and

found that

- In preciseness and conciseness, RMC provides a set of graphical representations

that sharply conveys the meaning of each process element.

- In convenience to use, RMC provides sets of functionalities allowing the process

engineers to easily pick and choose the notations and elements in the course of

modeling a process.

- In being commonly understood, RMC uses pictorial icons that represent

standard real-world objects. The users will be able to interpret the icons in

universal meanings

- In being suitable for representing a broad range of software functions, even

though the current sets of notations cover a wide range of software activities,

RMC allows the addition of extra custom process element icons to fit with any

additional requirements a process engineer might see fit.

Lastly, Heidrich proposed in [7] that people-oriented process information should

describe role-specific responsibilities, activities, and abilities. RMC represents these

information by using work products, tasks, and properties respectively. The groupings

of these elements allow the process engineers to illustrate various perspectives of the

process to the readers enabling the ability to represent the big picture of the process as

well as specific views.

4.2 Effort Comparison between EPG and non-EPG

To determine the effectiveness of using the IICM-Sw EPG, we compared it with the

use of traditional paper-based version of the guidelines. The data used to perform the

comparisons were the effort, or the number of hours, spent by students in performing

specific project-related activities. These data were taken from the USC’s CSCI577a

Software Engineering course of Fall 2007 and Fall 2008 semesters where the Fall

2007 semester utilized the paper-based version and the Fall 2008 semester utilized the

electronic version. To compensate for the difference in class sizes, we took the

average of the class effort resulting in the average effort spent by each person on their

projects. The scope of activities used to perform the analyses are specified in section

2.1.

Fig. 6 Class Average Effort

Fig. 6 shows the average effort, in hours, spent by each student in both learning the

process and performing the project-related activities for each role, which are

Operational Concept Engineer (OCE), Requirement Engineer (RE), Software

Architect (SA), Life Cycle Planner (LCP), and Feasibility Analyst (FA). Switching

from the paper-based version of the guidelines to the EPG clearly displays a reduction

in effort required in all specified scope mentioned in section 2.1.

Fig. 7 Effort Spent in Role Learning and Documentation

In addition to analyzing the class average of the effort spent, we further analyzed

the effort spent by each role in learning the actual role and responsibilities from the

given guidelines as well as the effort required to document the artifacts shown in Fig.

7. From the left chart of Fig. 7, the amount of effort required to learn and understand

each role are significantly reduced with the exception to learning the software

architect role. Since the EPG allows for each person to focus on studying their

specific tasks and responsibilities, it enables them to understand their roles quicker

and better. Furthermore, the better understanding of the roles allows for each student

to generate the resulting artifacts more effectively and efficiently proven by the

reduced effort in documentation.

Fig. 8 Ratio Analysis

Furthermore, Fig. 8 shows another aspect of analyzing the effort different from the

prior analyses. Instead of focusing on role-specific activities, we took the effort spent

in learning the process and the effort of documentation and compared with the total

effort that students spend on the projects. This allows us to see the fractions of effort

students spend in learning the process and documentation with respect to the total

effort they put into project. In the Fall 2007 semester, the average student put in a

total of 209.57 hours to their project with 15.2 hours towards learning the process and

69.2 hours to documenting the artifacts, while in the Fall 2008 semester, the average

student spent a total of 175.8 hours in the project with 11.9 hours to learn and 46.6

hours to document. Although the percentage of effort required to learn the process

remain roughly consistent between the use of the EPG and the traditional paper-based

guidelines, the effort spent in documentation drastically reduced.

4.3 Feedback from students’ survey results

We had conducted a survey about the EPG usage in the software engineering class,

and the students provided their feedbacks on various dimensions. Regarding the

effectiveness in communication of the process, the IICM-Sw EPG greatly improves

their understanding about the software development process and also highly

supportive in discussing about the process among team members and communicating

the process to the project clients. Regarding the role-oriented process information, the

IICM-Sw EPG provides role-specific essential information such as responsibilities,

activities, and abilities, which crucially helps the student teams in task allocation,

project planning, and project management. Finally, for process modeling and support,

the IICM-Sw EPG highly assists the students’ teams to plan and execute the process.

Moreover, the IICM-Sw EPG mentors the students on the list of artifacts to be

created, maintained, and delivered. The majority of the students nominated that the

interactive graphical representation is the most useful feature, while the improper

search function is the least useful function. Role-specific information (Fig. 2),

delivery process (Fig. 4), templates, and example documents are the features that are

most helpful in aiding them learn and understand the development process.

At this stage, the experimental version of the IICM-Sw EPG does not fully support

students in process adaptation and process improvement, so we were not able to

obtain data for those aspects.

5 Conclusion and Future Challenges

The result of our initial experiment proves that the EPG is very effective in terms

of communicating the process model to the students, especially for the on-campus

students. With the role-oriented process information, on-campus students found that

it is easy for them to learn about their roles, responsibilities, activities, and

functionalities. This can be seen from two aspects of the results, which are the

reduced number of effort spent by every role of the team and the positive feedbacks

received from the students. However, it is interesting to notice that the on-campus

students are more satisfied with the EPG than the off-campus students. Since the

majority of the off-campus students are working professionals, this could imply that

this EPG would be more effective for, or preferred by, the students who have little

real-world work experienced.

Moreover, based on the incremental development of the EPG, our process

engineers found that the EPG is easy to maintain and the process contents can easily

be reused. In addition, the flexible and tailorable process management framework of

RMC allows our process engineers to configure the process contents to support the

process evolution and process management. The EPG provides a far more effective

means of communication compared to the old paper-based guidelines. Based on these

observations and the evidences of the experimental results, the IICM-Sw EPG clearly

meets some of the objectives defined by Humphrey and Kellner [8], Heidrich [7] as

well as the characteristics of a good process modeling tools defined by Fuggetta [5].

However, despite the strengths, few weaknesses were also found. Firstly, this

guideline does not fully support process adaptation. It does not provide the ability for

the students to modify the proposed process to better fit their projects. Secondly, by

using the EPG, it is difficult for student teams to perform process improvements since

they are learning process itself. There exists a very high learning curve to both

complete and improve the development process at the same time. Furthermore, the

guidelines for the development and operation phases have not yet been fully modeled

and experimented, so the data obtained are not representative of the entire software

development life cycle.

Moreover, the EPG can be further extended to improve the EPG itself as well as

its contribution to the software engineering class. Some of the future researches that

we are considering are integrating the EPG with other class tools and materials such

as effort reporting system [4] and Distributed Assessment of Risk Tool (DART) [3] as

well as integrating with project tracking and planning tools. In addition, more

research can be done on the type of information and guidance required to accelerate

the learning curves of the students in understanding the process, roles, and

responsibilities to overcome some of the learning overhead. Finally, we can look into

the scalability of the EPG itself. Modeling the ICM into an EPG can be scaled to

large-scale projects and use at the industrial level instead of being limited to class-

sized projects.

References

1. Boehm, B. and Lane, J., "Using the Incremental Commitment Model to Integrate System

Acquisition, Systems Engineering, and Software Engineering," CrossTalk Journal,

Volume 20, Number 10, 2007

2. Boehm, B. and Lane, J. 2008. A Process Decision Table for Integrated Systems and

Software Engineering. In Proceedings of the Conference on Systems Engineering

Research (Los Angeles, CA, USA, April 04-05, 2008)

3. DART Tool, http://greenbay.usc.edu:8080/dart/appManager

4. Effort Report System, http://greenbay.usc.edu/ERSystem

5. Fuggetta, A., Software process: a roadmap, Proceedings of the Conference on The Future

of Software Engineering, p.25-34, June 04-11, 2000

6. Haumer, P. IBM Rational Method Composer: Part 1: Key concepts, December 2005,

http://www.ibm.com/developerworks/rational/library/dec05/haumer/

7. Heidrich, J., Münch, J., Riddle, W.E., Rombach, D.: People-oriented Capture, Display,

and Use of Process Information. In: Acuña, S.T., Sánchez-Segura, M.I. (eds.) New Trends

in Software Process Modeling. Series on Software Engineering and Knowledge

Engineering, vol. 18, pp. 121–179. World Scientific Publishing Company, Singapore

(2006)

8. Humphrey, W. and Kellner, M. “Software Process Modeling: Principles of Entity Process

Models.” Proceedings of the 11th International Conference on Software Engineering, PA,

USA, 1989. pp. 331 – 342.

9. Humphrey, W., A Discipline for Software Engineering, Addison-Wesley Longman

Publishing Co., Inc., Boston, MA, 1995

10. IBM Rational Method Composer http://www-01.ibm.com/software/awdtools/rmc/

11. IBM Rational Portfolio Manager http://www-01.ibm.com/software/awdtools/portfolio/

12. IBM Rational Team Concert http://www-01.ibm.com/software/awdtools/rtc/

13. Kellner, M. “Software process modeling support for management planning and control”.

In Mark Dowson, editor, Proceedings of the First International Conference on the

Software Process, pages 8–28. IEEE Computer Society Press, August 1991

14. Kellner, M. Becker, U., Riddle, W., Tomal, J., and Verlage, M., “Process guides: Effective

guidance for process participants”. Proceedings of the Fifth International Conference on

the Software Process, pages 11–25, Chicago, IL, USA, June 1998 ISPA Press

15. Koolmanojwong, S., Phongpaibul, M., Laoteppitak, N., Boehm, B., "Comparative

Experiences with Software Process Modeling Tools for the Incremental Commitment

Model" USC CSSE Technical Report 2008

16. Microsoft Project, http://office.microsoft.com/en-us/project/default.aspx

17. Patterson, F. (1999). System engineering life cycles: life cycles for research, development,

test, and evaluation; acquisition; and planning and marketing, in Sage, A., and Rouse, W.,

ed., (1999) Handbook of Systems Engineering and Management, Wiley, pp. 59-111.

18. Pew, R. W., and Mavor, A. S. 2007. Human-System Integration in the System

Development Process: A New Look. National Academy Press.

19. Instructional ICM-Sw EPG, http://greenbay.usc.edu/IICMSw/index.htm

20. USC Software Engineering Class I Website,

http://greenbay.usc.edu/csci577/fall2008/site/index.html