Software Process Modelling Example for ISPW-7 Call for Participation
As part of the Seventh International Software Process Workshop (ISPW--7),
participants are invited to solve a process modelling problem,
to submit those solutions for examination, and to meet
on the day before the workshop proper to discuss those solutions.
The purpose of this exercise is
to enhance our mutual understanding of the variety of approaches that have
been developed for software process modeling.
As many of you know, the idea of providing a modelling problem
was first attempted last year as part of ISPW--6.
This exercise proved to be very successful and everyone felt
that it should be continued in future workshops.
Rather than trying to construct a completely new problem,
the ISPW--7 problem extends and modified the ISPW--6 problem.
The extensions attempt to address issues in two areas:
team work and process change.
The example problem consists of a required core problem and several
optional extensions.
For those of you who did not participate last year, you may choose
to just do the core part of the problem.
You should make a good
faith effort to comprehensively solve the entire core problem.
As a result of the ISPW--6 exercise, it is clear that
most approaches can expect to encounter some aspects of the core
problem that either cannot be expressed or are quite awkward to handle.
It would be quite helpful in such cases if the modeler would identify these
difficulties in comments accompanying the solution.
For those of your who have seen the problem before,
we have provided some suggested modifications to the problem
and we would expect you to address one or more of these problems.
As with the new-comers, we would hope that you will provide some
written insight into your solution and the problems that you
encountered.
Solutions to the example problem will be distributed to participants
prior to the Workshop.
Electronic distribution will be used where possible.
This will enable people to review them in advance,
thus speeding our efforts during the working session.
The Software Design and Analysis company (SDA)
has agreed to duplicate and distribute the solutions.
Incidentally, this will be a separate mailing from the position paper
preprints.
Example problem solutions must be received by October 1, 1991
in order to be duplicated and distributed.
Solutions may be sent
in Postscript form via e-mail, or in plain ASCII
text via e-mail.
Paper copies may also be sent, but E-mail is preferred for fast
distribution.
No Other Formats Are Acceptable.
Do not send material with embedded
formatting commands that must be submitted to a text processor! Send
solutions to
ISPW--7
Software Design and Analysis
POB 3521
Boulder, CO 80303
USA
e-mail: ispw7@sda.com
If your solution is not ready by the October 1 deadline, you are, of course,
free to distribute your solution at the example session.
But there is no guarantee that you will be given time for a formal
presentation.
A special working session to review the solutions is planned for
Tuesday, 15 October 1991,
in the same Hotel as the workshop. It is anticipated that this will
be a full-day session.
This year, unlike last year,
all participants of the workshop are invited to
attend the example session to be held on the day before the workshop.
You need not submit a solution to attend and discuss the solutions.
However, formal presentations at the example session will be
limited to those participants who have submitted a solution.
On the day of the example session,
we will divide into two or three groups each of which
will discuss their solutions.
The basis of the division into groups is still tentative.
It will depend on the number and nature of the submitted solutions.
At the moment we have two proposals for dividing into groups:
- Divide by nature of the modelling language used.
In this case, we might expect to divide into
two basic groups: those using a non-executable process modelling language
and those using an executable process programming language.
This latter group might in turn be divided into one group
whose languages are primarily procedural and another group
whose language is primarily rule-based.
-
Divide by solution.
Those whose solution focused on team issues would be in one
group and those who focused on process change in another group.
New-comers would be divided equally among the two groups.
Each group
will have a designated leader who will be responsible for
guiding the presentations and discussions.
Each group will be expected to provide a summary of their discussions.
We intend to provide some specific questions for each groups to answer
in its summary.
During the regular workshop, one session will be devoted to
presentations of the group summaries.
Additional details regarding the
meeting will be distributed as they become available.
This modified solution is the result of efforts
by Marc Kellner, Dewayne Perry, the program committee of ISPW--7,
and, of course, the ISPW--6 group responsible for the original problem.
The members of the ISPW--7 committee
sincerely hope that you will participate in this exploration of
modeling approaches, and we look forward to meeting with you at
the workshop.
Following this cover letter are three sections.
First is a description of the teamwork extension.
Second is the description of the process change extension.
Third is the text of the original ISPW--6 problem statement.
Marc I. Kellner
Software Engineering Institute
and
Dennis Heimbigner
University of Colorado, Boulder
(Extensions to ISPW-6 Problem)
The set of new extensions to the ISPW-6 example
has been divided into two parts. One part focuses
on teamwork aspects and a second part focuses on process change.
In turn, each part has several specific extensions.
You should choose to solve one of the specific extensions
under one part. Thus, you may choose one of 4.1.1, 4.1.2, 4.1.3,
4.2.1, or 4.2.2 to solve. You are, of course, free to do
more than one part or to add detail (within reason) to your choice
if you feel it will show useful features of your formalism.
4.1 Teamwork
The teamwork extensions actually consist of two extensions
plus a collation of the teamwork-related options from the original
example statement.
The extensions address two specific
issues in teamwork. One issue (4.1.1) is the managerial problem
of allocating various constrained resources, especially human resources,
in order to complete a schedule of tasks.
A second issue (4.1.2) is the coordination of multiple programmers
working in parallel.
Section 4.1.3 is slightly different.
The observation has been made that the original example,
and especially the optional extensions,
contained a significant amount of teamwork related exercises;
it is especially rich in role-related material.
As part of this exercise,
we decided to collate much of the pre-existing material and allow
it to serve as an additional ``extension'' to be solved.
If you choose to use section 4.1.3, please note carefully
exactly which parts you are addressing.
If you have not attempted the ISPW-6 example before,
you may find that solving one or more of the pieces
mentioned in 4.1.3 can help focus your solution to the whole problem.
4.1.1 Resource Management
Extend the information available about a schedule to include
duration and personnel information.
Assume a set of reasonable durations for each step in the process (e.g.,
3 days to modify design, 4 days to modify code, etc.).
Based on your process model, attempt to generate a schedule for the completion
of the process.
Now, given this schedule and a resource database about personnel
commitments, attempt to assign people to tasks in accordance
with commitment and time constraints.
Specifically address the problem of people serving multiple
roles.
You may simplify the problem if you wish by assuming that
the schedule to be addressed has no loops in it.
That is, it represents a linear sequence of steps through
the process assuming perfect execution of all steps
(e.g., the modified design is approved at the first review).
The intent of this choice is to explore the
management issues involved in process scheduling, resource
management, and role assignments under constraints.
It is also intended to exercise the data modeling capabilities
of your approach.
4.1.2 Coordination and Communication
This extension involves converting the code modification step (2.7)
of the original example from a single person activity
to an activity involving parallel modifications and merging
of effort.
Assume that multiple, interdependent pieces of code
must be chosen and modified to satisfy the design modification.
Given the pieces of software, your solution should model
the instantiation of parallel modification steps (possibly
including assignment of people to each parallel activity).
Your solution should also allow for interdependencies
between code pieces and for coordination of changes
between interdependent code pieces.
As a concrete scenario to consider,
assume that two pieces of code
have been chosen for modification and that they are to be modified
in parallel. But assume that the two pieces of code are interdependent.
For example, assume that one piece defines an interface used by the other
and that this interface needs to be changed.
The two programmers involved should notify each other of the required change,
should perhaps review each other's changes,
and should coordinate to decide when the two pieces are finished
and consistent.
The intent of this choice is to exercise your ability to specify
concurrent activities and to demonstrate how,
concretely, team members will coordinate activities.
There are some dimensions to this problem that may not
be immediately apparent.
The first dimension is the degree of coupling
between coordinating participants.
In this problem we assume
the coordination is what we will term ``asynchronous,''
as opposed to ``synchronous.''
By synchronous coordination, we mean to imply that the people
doing the coordinating are typically in the same room
and will primarily coordinate by direct verbal communication.
Part 2.6 of the original example would be an instance of synchronous
coordination.
In asynchronous coordination, we assume that the participants
mostly operate independently and when they coordinate, they
use the process formalism as an intermediary for that coordination.
The second dimension is the dynamic specification of the number
of parallel activities. Obviously if one
specifies the number of parallel threads and their interdependencies
in advance,
then it is relatively
easy to accommodate them in any reasonable formalism.
The intent here is that the number of pieces of code
that must be modified is determined as part of the process
and then an appropriate number of threads of activity are created.
It is these threads that must coordinate with each other.
4.1.3 Options from the Original Example
The ISPW-6 Software Process Example (original problem) illustrates a
number of teamwork issues in various ways throughout its structure.
At a high level of abstraction, it assigns a group responsibility
for a high level process abstraction. That is then decomposed into
more refined and specific tasks and associated responsibilities.
The original example also details many specifics of the interactions
between activities and agents (flows of information and objects, as
inputs and outputs; physical communication mechanisms for conveying
those flows; coordination details specified as constraints on
sequencing, pre-conditions, etc.). The issue of multiple roles is
also a thread throughout the existing core problem. Three original
extensions provide additional semi-structured opportunities to
explore teamwork issues more fully.
More specifically, Develop Change and Test Unit (2.3 - the overall
process) is carried out by the project team (2.3.4), whose structure
is spelled out in the last paragraph of 2.2. The original example
goes on to decompose this higher level process into 8 major
components, each of which has its own assignment of personnel
responsible for performing that task. Two of these major components
are specifically carried out by teams. The Review Design step
(2.6) is carried out by a team of 4 specified individuals (2.6.4),
including the design and QA engineers working this change plus two
other software engineers. Similarly, Test Unit (2.10) is carried
out by a two-person team of the design and QA engineers working this
change (2.10.4).
The original example also illustrates role issues. Specifically,
the key individuals (agents) in this process (i.e., project manager,
specific design engineer, specific QA engineer) each play multiple
roles within the process. For example, the QA engineer has four
roles: (a) reviewer (2.6 - Review Design), (b) test plan modifier
(2.8 - Modify Test Plans), (c) unit test package modifier (2.9 -
Modify Unit Test Package), (d) tester (2.10 - Test Unit).
Three of the original extensions provide additional
settings within which to explore teamwork issues:
- Review Design Details (3.3)
- Scheduling and Resource Constraints (3.4), and especially
Scheduling Under Resource Constraints (3.4.3)
- Aggregation of Multiple Changes (3.5), especially with interacting
changes
Finally, we should note that
the new extensions above (4.1.1, and 4.1.2) essentially elaborate the
original extensions 3.4.3 and 3.5, respectively, to focus on team
work issues.
4.2 Process Change
The process change extensions addresses two forms of change.
One, which we term ``process modification,''
is intended to represent some form of permanent evolution of
a process. The second form of process change, which we term
``process exception,'' concerns a temporary modification to
the process to handle some exceptional circumstance.
Note that the mechanisms involved in handling either part
may be very similar and it would be of interest if you
explained why (or why not) your approach for one
extension would differ for the other.
4.2.1 Process Modification
In the original example, it was possible to begin coding
before design was approved.
Suppose that it is decided to change the process
and to tighten the requirements detailing when coding can begin
(2.7.4.1) in order to require that the design be approved before
coding may begin.
Further, assume that this process change is to affect some
currently ``executing'' or ``instantiated'' process.
Show how the change affects the state of that executing process
and how the consequences of the change will be communicated
to the user of the process.
You may want to consider three cases
of process modification.
- The executing process has not yet reached the step
affected by the change, so the change will have no immediate
impact on the process state.
In this case, that would mean that coding has not yet begun.
Note: this case is sometimes termed a ``static'' process change.
- The executing process has reached or passed
the steps affected by the change, but for whatever reason,
the change is consistent with the existing process state.
In this case, that would mean that some coding was in progress,
but it just happened that no coding actually occurred
before the design was approved.
- The executing process has reached or passed
the steps affected by the change, and
the change is inconsistent with the existing process state.
In this case, that would mean that some coding was in progress
but the design was not yet approved.
Note that you have two options here: (1) you may allow
the inconsistency to remain, or (2) you may attempt to change
the state (by rollback, or whatever) to achieve consistency.
The intent of this extension is to
highlight the mechanism by which
various approaches handle changes in an already defined process model
and to begin to address some of the issues involved in on-the-fly
modification of processes.
4.2.2 Process Exceptions
Suppose that due to unavailability of assigned
personnel, it is decided to bypass a follow-up (say second) design review.
This decision is made dynamically at the time that this review was
scheduled to occur.
The rest of the process continues normally in this instance.
How would the process model cope with such a dynamic change?
Note that in this scenario, we would expect you to minimize
the undesirable side-effects of the exception. For instance, if later steps
in the process assume (and check for) completion of all design
reviews, then we would hope that handling the original exception
would not also produce an exceptional condition at these later steps.
The intent of this choice is to explore how your approach
handles exceptional situations: situations that were not
covered in the original process, but which are not viewed
as requiring permanent changes in the process model.
Identification
GDPA Online