App Dev Scenario
This scenario describes a common flow in a generic software development process. The goal is to describe a flow that touches on the connections between resources in four of the primary OSLC domains: RM, QM, AM, and CM.
OSLC AM, CM, RM and QM servers are set up and configured. A software development effort is already underway.
Bob - business analyst, responsible for managing requirements
Al - solutions architect, responsible for designing solutions to meet requirements
Deb - developer, develops code using designs and requirements.
Tanuj - quality engineer
Rebecca - project manager
- Rebecca tasks Bob to add a new feature to the application. She creates a change request and assigns it to Bob.
- Bob accepts the change request and starts working on it. He references existing requirements, designs and tests as he develops adds new requirements (oslc_rm:Requirement) and defines new requirements collections (oslc_rm:RequirementCollection) which defines the user requirements.
- Bob reviews the new requirements with Rebecca, the marketing team and and the chief architect.
- Upon successful review Rebecca decides to include this new feature in the next release of the application. She creates change requests for Al to specify and design a solution, and for Tanuj to design and develop the test cases.
- Al accepts the change request and begins the process of specification and design. During specification process he creates new requirements and requirement collections and links them to the user requirements (oslc_rm:satisfies). <YY: Usually, satisfy links are created between design elements and requirements (e.g. UseCase satisfies Requirements). Maybe the right link type here would be Derived Requirement (derivedReqt) or Allocate.> During design Al references <img: what does “references” mean here?> the requirements, related requirements and existing design resources.
- Al creates new design resources, linking them to specific requirements and/or collections (oslc_rm:elaborates, oslc_rm:specifies). <img: Yuriy, can you expand on the SysML-defined predicates?>
<YY: If we want to keep this scenario as simple as possible, we can just say that ‘Al links new design resources to requirements using Satisfy predicates’. I believe this is the only SysML predicate that is fit this scenario. Alternatively we can add one more actor, a System Engineer, who creates systems level design elements (Use Cases - Blocks - Activities - etc.) that Refine, Satisfy, or Trace user requirements and then allocates design elements to software requirements, which will be analyzed by Deb later on.>
- Al reviews the designs with the architecture team.
- The reviewed design is presented to Rebecca who assigns its development to Deb.
- Tanuj accepts the change request and begins the process of creating a test plan and cases for the new feature. He may reference existing similar test cases and designs.
- Tanuj examines the requirements collection for the new feature and decides on which test cases need to be created, estimating the level of complexity and priority. <img: Classification of testing - system, integration, unit?>
- Tanuj works with marketing team to prioritize the test environments.
- Each test case is linked to the subset of requirements that drive it.
- Deb accepts the task of implementing the new feature and design.
- Deb researches her task by navigating through the related requirements, designs and test cases.
- Deb implements and locally tests the new feature. She completes the change request.
- Rebecca sees the completed implementation change request and tasks Tanuj to test the new feature.
- Tanuj tests the new feature, creating a new test execution record.
- Tanuj discovers a problem and creates a new defect. He assigns it to Deb.
- Deb accepts the defect and starts working on it.
- Deb develops a fix and delivers it.
- Deb marks the defect as resolved.
- Tanuj sees the change in defect status and confirms the fix.
- Tanuj verifies the fix and marks the defect closed.
- Rebecca monitors the overall status of work on the feature.