page-info

:title}
{anchor:ContentsofthisPage}{panel:title=Contents of this Page}
{toc:minLevel=2}
{panel}

h2. Use Case - Automated review

|| *Use Case Number* \\
The author-assigned number to refer to each specific use case. The format of this number is _<SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>_, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc. \\ | Initpm7.SD200.1 |
|| *Brief Description* | This use case describes the automated review of XMI submitted by developers using Business Process Management (BPM) tool \\ |
|| *Actor(s)* for this particular use case | Developers |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | The developers are ready with the UML model and an annotated xmi \\
\\
A BPM tool is configured to understand and perform the steps involved in metadata creation, submission, storage, review, and acceptance \\
Developers have access to BPM tool \\
The BPM tool has the necessary interface with SIW \\ |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | Automated emails are generated informing the stakeholders of the result from SIW run \\ |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | 1. Developers have the complete submission package \\
2. log in to the BPM and submit the XMI \\
3. The BPM invokes the SIW to validate the xmi \\
4. Automated emails are sent to the stakeholders informing them of the result of SIW run. \\ |
|| *Alternate Flow* \\
Things which would prevent the normal flow of the use case \\ | None \\ |
|| *Priority* \\
The priority of implementing the use case: *High, Medium or Low* \\ | High |
|| *Associated Links* \\
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case. \\ | |
|| *Fit criterion/Acceptance Criterion*&nbsp; \\
How would actor describe&nbsp;the acceptable&nbsp;usage scenarios&nbsp;for the software or service that meets the actor's requirement? \\ | SIW run for a given XMI is automated \\ |

h2. Init1pm7.SD200.3-Automate model upload on Sandbox

|| *Use Case Number* \\
The author-assigned number to refer to each specific use case. The format of this number is _<SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>_, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc. | Init1pm7.SD200.3 \\ |
|| *Brief Description* | This use case describes the automated upload of model submitted by developers using BPM to caDSR sandbox |
|| *Actor(s)* for this particular use case | Developers |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | 1) The developers have approved the XMI after recieving it from the EVS team \\
2) A BPM tool is configured to understand and perform the steps involved in metadata creation, submission, storage, review, and acceptance \\
3) Developers have access to BPM tool |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | Metadata available on caDSR Sandbox \\ |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | 1.Developers log in to the BPM and submit the XMI \\
2.The model is successfully loaded on caDSR in sandbox environment \\
3.Automated emails are sent to the stakeholder |
|| *Alternate Flow* \\
Things which would prevent the normal flow of the use case \\ | None |
|| *Priority* \\
The priority of implementing the use case: *High, Medium or Low* \\ | High |
|| *Associated Links* \\
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case. \\ | |
|| *Fit criterion/Acceptance Criterion*&nbsp; \\
How would actor describe&nbsp;the acceptable&nbsp;usage scenarios&nbsp;for the software or service that meets the actor's requirement? \\ | Uploading on caDSR is automated \\ |

h1. Init1pm7.SD200.4-Automate caDSR model submission on production


|| *Use Case Number* \\
The author-assigned number to refer to each specific use case. The format of this number is _<SemCon Ops Initiative><analyst's initiatls><requirement number>.< <use case number>_, for example Init1dbw1.1, Init1dbw1.2, Init2dbw2.1, 2.2, etc. | Init1pm7.SD200.4 |
|| *Brief Description* | This use case describes automated upload process to caDSR production \\ |
|| *Actor(s)* for this particular use case | none |
|| *Pre-condition* \\
The state of the system before the user interacts with it \\ | 1) The Model owners have reviewed and approved the metadata on caDSR sandbox \\
\\
2) A BPM tool is configured to understand and perform the steps involved in metadata creation, submission, storage, review, and acceptance \\
\\ |
|| *Post condition* \\
The state of the system after the user interacts with it \\ | Metadata is available on Production \\ |
|| *Steps to take* \\
The step-by-step description of how users will interact with the system to achieve a specific business goal or function \\ | 1. The BPM tool understands that model owners have approved model on caDSR sandbox and uploads it to production \\
\\ |
|| *Alternate Flow* \\
Things which would prevent the normal flow of the use case \\ | None |
|| *Priority* \\
The priority of implementing the use case: *High, Medium or Low* \\ | High |
|| *Associated Links* \\
The brief user stories, each describing the user interacts with the system for the one function only of the use case. There would potentially be a number of user stories that make up the use case. \\ | |
|| *Fit criterion/Acceptance Criterion*&nbsp; \\
How would actor describe&nbsp;the acceptable&nbsp;usage scenarios&nbsp;for the software or service that meets the actor's requirement? \\ | \\
1. upload to caDSR is automated \\ |
\\
{scrollbar:icons=false}