SA re defined part 2
From UG
(Difference between revisions)
Line 26: | Line 26: | ||
** SA is to forward only dev type wiki to Architect/Developer | ** SA is to forward only dev type wiki to Architect/Developer | ||
- | * | + | * I am adding "impact" mantis field. With values: {ihigh, imed, ilow} |
- | ** SA | + | ** This value indicates a level of impact of particular task on entire system deign |
+ | ** tasks with impact = ihigh/imed must be reviewed by Architect before coding or even SA phase | ||
+ | ** tasks with impact = ilow could be assigned directly to Developer | ||
+ | * Below see examples of specs that were built with new principles in mind. | ||
* Role of Architect to be introduced: | * Role of Architect to be introduced: | ||
- | ** must | + | ** tasks with impact = ihigh/imed must be reviewed by Architect (after BA and SA sections are completed) |
** must post Architect comments into "Architect Review" section | ** must post Architect comments into "Architect Review" section | ||
** If Architect rejects solution then it must be returned to SA (not BA) | ** If Architect rejects solution then it must be returned to SA (not BA) | ||
Line 53: | Line 56: | ||
** to be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution. | ** to be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution. | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
Examples: | Examples: |
Revision as of 20:13, 14 December 2010
Subject: New directives to streamline SA (and BA) work
From: CT2 Project Manager
To: CT2 Team
This is a continuation of an effort to streamline SA (and BA) work. Fist article is here: SA re defined
Due to additional negative feedback about recently submitted designs/specifications I introduce the following directives:
- We need to bring Systems Analysis on a new professional level:
- It is a critical activity and must be done by a professional with appropriate level of technical training, experience and proven abilities
- core skills: excellent technical skills (details TBD), excellent communication skills, excellent documentation skills (Systems Analysis section and Proposal)
- existing staff must be re-trained or/and new staff must be hired
- For now: Alex will do SA for Project type tasks; all other tasks (tweaks) can be forwarded to Andrei for SA
- We need to continue to improve BAs work:
- continue to train BAs to bring their skills and experience to acceptable level
- skills that are critical for BA role: writing, analytical thinking, interviewing
- BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
- To improve BA to SA cooperation:
- BA is to post/manage her info in RFD type wiki
- SA is to post/manage his work in Dev type wiki
- See example here: Category:Acc
- SA is to forward only dev type wiki to Architect/Developer
- I am adding "impact" mantis field. With values: {ihigh, imed, ilow}
- This value indicates a level of impact of particular task on entire system deign
- tasks with impact = ihigh/imed must be reviewed by Architect before coding or even SA phase
- tasks with impact = ilow could be assigned directly to Developer
- Below see examples of specs that were built with new principles in mind.
- Role of Architect to be introduced:
- tasks with impact = ihigh/imed must be reviewed by Architect (after BA and SA sections are completed)
- must post Architect comments into "Architect Review" section
- If Architect rejects solution then it must be returned to SA (not BA)
- If solution is accepted then developer must be assigned and task forwarded for estimation
- Kostya will play this role
- Spec will have the following structure: (template is here Spec Example)
1 Info 2 Business Analysis 2.1 Requirements 2.2 Possible solutions 2.3 RFP 3 Systems Analysis 4 Architect Review 5 Implementation Summary 6 QA Plan 7 History
- I introduce Implementation Summary section
- needed since "Systems Analysis" section will not provide exact solution, just direction in many cases
- to be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution.
Examples: