App Dev Scenario

Overview

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.

Preconditions

OSLC AM, CM, RM and QM servers are set up and configured. A software development effort is already underway.

Actors

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

Main Flow

1. Rebecca tasks Bob to add a new feature to the application. She creates a change request and assigns it to Bob.
2. 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.
3. Bob reviews the new requirements with Rebecca, the marketing team and and the chief architect.
4. 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.
5. 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.
   1. 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.>
   2. Al reviews the designs with the architecture team.
   3. The reviewed design is presented to Rebecca who assigns its development to Deb.
6. 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.
   
   1. 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?>
   2. Tanuj works with marketing team to prioritize the test environments.
   3. Each test case is linked to the subset of requirements that drive it.
7. Deb accepts the task of implementing the new feature and design.
   
   1. Deb researches her task by navigating through the related requirements, designs and test cases.
   2. Deb implements and locally tests the new feature. She completes the change request.
8. Rebecca sees the completed implementation change request and tasks Tanuj to test the new feature.
9. Tanuj tests the new feature, creating a new test execution record.
   1. Tanuj discovers a problem and creates a new defect. He assigns it to Deb.
10. Deb accepts the defect and starts working on it.
    1. Deb develops a fix and delivers it.
    2. Deb marks the defect as resolved.
11. Tanuj sees the change in defect status and confirms the fix.
    1. Tanuj verifies the fix and marks the defect closed.
12. Rebecca monitors the overall status of work on the feature.