Sysiphus's Goals

The primary goal of sysiphus is to allow participants in a distributed software engineering project to collaborate on the development of models over an extended period of time. In particular, sysiphus focuses on:

  • Providing a uniform and extendable modeling environment
  • Supporting short term collaboration
  • Supporting rationale management
  • Providing user-defined views over the model
  • Allowing evolutionary changes

Providing a uniform and extendable modeling environment

The primary design goal of sysiphus is to provide a simple and integrated solution to manipulate system models and rationale, embedding only minimal process specific knowledge. This enables users to adopt different development processes for different projects and to use rationale for a broad range of activities. Sysiphus includes a suite of tool centered on a central repository, which stores all models, rationale, and user information. The repository controls access and concurrency, enabling multiple users to work at the same time on the same models.

Supporting short term collaboration

Sharing models is needed for supporting distributed development, but it is not sufficient. Participants must also share information about current discussions about the models, plans, and current status. Moreover, to provide accurate context for collaboration, this information needs to be attached to specific model elements to which they relate. In sysiphus, project participants collaborate by attaching annotations to model elements. The main types of annotations supported by sysiphus are:
  • comments, denoting an informal thread of discussion,
  • issues, denoting problems to be solved, such as design issues, ambiguities, defects, and
  • action items, denoting work to be done, including due dates, status, and responsible individual.

Supporting rationale management

After decisions are made and implemented, most information generated in during short term collaboration quickly looses its value, as it becomes obsolete or difficult to understand outside its original context. For example, participants do not need to keep action items in the system after they have been completed and acknowledged. However, a great deal of rationale, often implicit, is generated during collaboration, explaining the reasoning behind decisions. When issues involve multiple stakeholders or takes a while to be resolved, it is often useful to capture the decision together with its justification, in order to facilitate future discussions involving related issues. In sysiphus, project participants consolidate rationale into an issue model, representing the issues that were addressed, the options explored, and the criteria used to evaluate each option, and the current decision selected to resolve the issue. Issues are linked to the model elements that are involved in the decisions. Rationale elements are also model elements, enabling participants to attach comments, subissues, or action items to any issue.

Providing user-defined views over the model

Not all project participants need to see all models and their associated annotations. For example, a requirements engineer is primarly concerned with use cases and nonfunctional requriements, while system testers are primarily concerned with test cases. However, different participants often need to see overlapping sets of models. Requirements engineers and system testers both need to know the relationship between use cases and test cases. In sysiphus, model elements are organized into documents that provide role or activity specific views. For example, a requirements analysis document can be defined in terms of sections that include use cases and nonfunctional requirements. Moreover, the same model element can also appear in different documents. The number, purpose, and goal of documents can be customized to project needs.

Allowing evolutionary changes

Sysiphus evolves as we learn to support distributed projects. As distributed projects entail many research issues, we anticipate that sysiphus will continue to evolve for a long time. Hence, an architectural goal of the project is to enable smooth transitions of existing models to new versions of sysiphus and to allow the coexistence of different versions of sysiphus tools at run time.