GDPA  
ISPW7 example problem description  

A-B-C- D-E-F- G-H-I- J-K-L- M-N-O- P-Q-R- S-T-U- V-W-X- Y-Z

Identification

ISPW7 Example - ISPW7 Homepage

Definitions/Uses

1991
Reference /Kellner, 1991d/ ISPW7 Software Process Example
Definition/
Use

Software Process Modelling Example for ISPW-7 Call for Participation

Contents  
  • 1. Background
  • 2. Instructions
  • 3. Distribution of Solutions
  • 4. Special Working Session
  • 5. Concluding Notes
  • ISPW-7 Problem
  • 1. Background

    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.

    2. Instructions

    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.

    3. Distribution of Solutions

    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.

    4. Special Working Session

    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.

    5. Concluding Notes

    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

    ISPW-7 Problem

    (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.

    See also

    Publications on ISPW-examples

    GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster