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