|ISPW7 example problem description|
|Reference||/Kellner, 1991d/ ISPW7 Software Process Example|
Software Process Modelling Example for ISPW-7 Call for Participation
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.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.
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: firstname.lastname@example.org
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.
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:
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.
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 TeamworkThe 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 ManagementExtend 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 CommunicationThis 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 ExampleThe 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:
4.2 Process ChangeThe 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 ModificationIn 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 (18.104.22.168) 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.
4.2.2 Process ExceptionsSuppose 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.
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|