|Lifecycle (Sub) Process Demonstration Scenario (ISPW9)
This scenario is a continuation of the International Software Process Workshops tradition of providing a process scenario as an example of life-cycle sub-processes for specifications in different formalisms and implementation and demonstration in different systems.
These examples or scenarios, together with specific guidelines, were designed and planned with many objectives in mind, including:
The original example, from ISPW6, appears in the Proceeedings of the 1st International Conference on the Software Process, held in California, in October 1991. Extensions to this examples have been proposed in ISPW7 and ISPW8.
- i) to provide canonical examples as vehicles for distinguishing the distinct process definition approaches.
- ii) to provide samples of "real life" issues in order to facilitate the explanation of demonstrations and to make those demonstrations aplicable to prospective users.
- iii) to bring about specific technical issues to be addressed by different process formalisms and systems as a means to experiment with those issues in the various approaches and systems.
This year's scenario is a revision of the ISPW6 scenario, to take away some of its rigidity, to make it more realistic and tailorable, and to add items related to human-computer interaction and computed mediated cooperation. This scenario is flexible, i.e., it provides a base scenario which includes named but un-specified procedures and policies. Thus, demonstrators can extend the scenario to demonstrate diverse policies and models, and the strenghs of their systems.
This scenario focus on:
The base scenario appears bellow, followed by a set of sub-scenarios with recommended themes to be demonstrated together with this scenario. These themes either refine the base scenario by including specific procedures, or list candidate functionalities to be demonstrated.
- Life-cycle aspect: Problem Reporting and Change Process
- Theme: Roles of human in the process and automation support for individual/team activities.
- Objective: Demonstrate process execution and how a process-based SEE helps project users in their roles (e.g. project-manager, designers, developers, configuration managers) perform their activities and cooperate with each other.
At ISPW9, there will be a demonstration day preceeding the workshop (open only to workshop attendees). Demonstrators are requested to enrich the base scenario with the sub-scenarios. It has been our experience that the demonstrations provide a good source of ideas and concepts to be discussed throughout the workshop.
A.3 Problem Reporting and Change Process
- A software project is on-going, with "parts" of the system already designed, codified, tested and baselined (i.e. under configuration management control).
- A problem is reported by a tester on the testing of a piece of the system under development. The project's problem reporting and analysis procedures are then followed and a person is assigned the task of the analysis of the problem. (Note: these procedures can be formal or informal, depending on the type of the project. Notification can be affected by mail, by forms, by a tool. The procedures may include rules or guidelines telling who assigns people resources to study which problems and what kind of steps need to be followed).
- A developer/analyst analyses the problem and proposes a solution. After the analysis (Which can be illustrated via automated process support or assumed to have been done manually), the developer identifies that the problem affects one software module which has been coded, tested and baselined, and possibly also affects some documentation (e.g., design and/or testing documents). (Note: the related documentation can be identified explicitly with help form the system, or implicitly via existing predefined rules in the system).
- After some analysis, it is noted that the module to be fixed is currently being (re)-used by two separate users or teams (again how this is accomplished may vary, i.e., the system may flag this issue or this fact may be found explicitly by inspection by a configuration manager or developer). Those users are notified of the problem and that module will be changed.
- The change process starts according to pre-established change procedures (which entail assignement of resources, code and/or documentation modification, nalysis/testing/review, approval/rejection and new baseline of the module and associated documentation).
- The module is checked out of the baseline according to the CM procedures for change but reuse of the old version continues.
- The module is changed to fix the problem. (Optionally, the fix could be done by two or more separate developers and their cooperation may be illustrated via process support).
- The module is tested (formally or informally). Once the problem is fixed, procedures for acceptance/rejection are followed. Once the module is accepted (i.e., the change does fix the problem and it does not violate nay of the requirements), appropriate regression testing on the module/systems which reuse a prior version of this module can be performed.
- Once all is done, the change process is finalized.
Demonstration should explicitly include as many of the following sub scenarios as possible:
- Specify and demonstrate one or more specific procedures/policies to complement the scenario (preferably performed with automated process support):
- problem reporting and/or analysis
- testing procedure/method
- analysis of a problem using data in system
- configuration control: retrieval, storage
- code fix
- problem approval/rejection
- resource allocation
- User role(*) support
(*) Definition of life-Cycle User Role (adapted from Webster): An expected behavior pattern associated with one or more people when executing life-cycle activities (e.g., project manager, configuration manager, developer, system analyst). One person can play multiple roles in a project. For example, when someone is writing code, s/he is playing the role of developer, when s/he is doing configuration management, s/he is playing the role of configuration manager.
Demonstrate implicit/explicit support for project user roles, (multiple) user-to-(multiple)role assignment (static/dynamic), the impact of actions of one role upon another (i.e., automated cooperation among roles based on process definition), and how roles affect the interaction styles and other aspects of the process.
- Individual Support
Demonstrate how individuals are guided about what task to do next, how users are made aware of the state of the process, or how the system performs actions as a result of the users' actions. Demonstrations should clearly illustrate how users are aware of the process, how the environment and the individuals interact, and what variables control the different modes of interaction.
- People Coordination
Demonstrate coordination of multiple people, including any support for resolution and tolerance of inconsistency. In particular, demonstrations can illustrate which aspects of these policies, if any, are hard-wired into their systems, and which can be altered by the particular model, and when the policy selections are made.
- Configuration management
Demonstrate how software and/or documents are controlled for the purpose of change, and how individuals using a module in their development are made aware of problems and/or changes to that module.
- Project/Central vs individual coordination
Demonstrate how the executing process supports both individual and project activities, and how the interactions of those activities are supported/mediated by the system.
- Process Changes while in execution
Dynamically demonstrate changing any of the process definitions supporting the scenario and points 1-5 above, and the effects of those changes.