SA re defined part 2

From UG

(Difference between revisions)
Jump to: navigation, search
(To improve BA to SA cooperation)
(I am adding impact mantis field)
Line 41: Line 41:
* tasks with impact = ilow could be assigned directly to Developer
* tasks with impact = ilow could be assigned directly to Developer
-
* Role of Architect to be introduced:
+
=== Role of Architect to be introduced ===
-
** tasks with impact = ihigh/imed must be reviewed by Architect (after BA and SA sections are completed)
+
* 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)
-
** If solution is accepted then developer must be assigned and task forwarded for estimation
+
* If solution is accepted then developer must be assigned and task forwarded for estimation
-
** Kostya will play this role
+
* Kostya will play this role
-
* Spec will have the following structure: (template is here [[Spec Example]])
+
=== Spec will have the following structure ===
 +
 
 +
* template is here [[Spec Example]])
  1 Info
  1 Info
  2 Business Analysis
  2 Business Analysis
-
   2.1 Requirements
+
   2.1 Business Needs
-
  2.2 Possible solutions
+
   2.3 RFP
   2.3 RFP
  3 Systems Analysis
  3 Systems Analysis
  4 Architect Review
  4 Architect Review
-
  5 Implementation Summary
+
  5 Implementation Notes
  6 QA Plan
  6 QA Plan
  7 History
  7 History
Line 65: Line 66:
** 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.
-
* Below see examples of specs that were built with new principles in mind:
+
=== Examples of specs that were built with new principles in mind ===
-
** [[0002525 PI redesign]]
+
* [[0002525 PI redesign]]
-
** [[2157 dev]]
+
* [[2157 dev]]

Revision as of 04:07, 16 December 2010

Contents

Intro

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:

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 impact=ihigh type tasks; impact=ilow can be forwarded to Andrei for SA; impact=imed to Andrei or Alex.

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 RFSA wiki and to forward this to SA
  • SA is to post/manage his work in RFD wiki and to forward this to Developer (subject to review by Architect in some cases).
  • RFSA wikis are in: Category:RFSA
  • RFD wikis are in: Category:RFD
    • example of naming convention: 2211 rfd
  • RFSA wikis are for SAs only! Use special background color to make sure developers/architects do not get confused:
[div style="background-color:wheat"] .... [/div]

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

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

1 Info
2 Business Analysis
  2.1 Business Needs
  2.3 RFP
3 Systems Analysis
4 Architect Review
5 Implementation Notes
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 of specs that were built with new principles in mind

Personal tools