SA re defined part 2

From UG

(Difference between revisions)
Jump to: navigation, search
(About)
(Intro)
 
(32 intermediate revisions not shown)
Line 1: Line 1:
-
== About ==
+
[[Category:News]]
-
This is a continuation of an effort to streamline SA work. Fist article is here: [[SA re defined]]
+
== Intro ==
-
Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes:
+
See 1st part of the article here: [[SA re defined]]
-
* 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
+
'''Subject:''' New directives to streamline SA (and BA) work
 +
 
 +
'''From''': CT2 Project Manager
 +
 
 +
'''To''': CT2 Team
 +
 
 +
Due to additional negative feedback about recently submitted designs/specifications I introduce the following additional 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]])
** 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
+
** existing staff must be re-trained 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
+
** 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:
+
=== We need to continue to improve BAs work ===
** continue to train BAs to bring their skills and experience to acceptable level
** continue to train BAs to bring their skills and experience to acceptable level
** skills that are critical for BA role: writing, analytical thinking, interviewing
** 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
** BA should provide as detailed info as possible about problems/needs including background info, existing workflows, etc
-
** SA must help BA to finalize her section. This means potentially re-writing it or writing it together.
 
-
** SA should avoid repeating info that was already presented in BA section
 
-
* Role of Architect to be introduced who must review all [[Project]] type specs (BA and SA sections) and major tweaks.
+
=== To improve BA to SA cooperation ===
-
** He must post Architect comments into "Architect Review" section (ideally) and mantis
+
* BA is to post/manage her info in [[RFSA]] wiki and to forward this to SA
-
** If Architect rejects solution then it must be returned to SA (not BA)
+
* SA is to post/manage his work in [[RFD]] wiki and to forward this to Developer (subject to review by Architect in some cases).
-
** If solution is accepted then developer must be assigned and task forwarded for estimation
+
* [[RFSA]] wikis are in: [[:Category:RFSA]]
 +
** example of naming convention: [[2211 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]
-
* Spec will have the following structure:
+
=== 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 ===
 +
 
 +
* template is here [[Spec Example]])
  1 Info
  1 Info
-
  2 Business Analysis
+
  2 Requirements and Solutions
-
  2.1 Requirements
+
  3 Architect Review
-
  2.2 Possible solutions
+
  4 Implementation Notes
-
  2.3 RFP
+
  5 QA Plan
-
  3 Systems Analysis
+
  6 History
-
4 Architect Review
+
 
-
  5 Implementation Summary
+
* I introduce Implementation Summary section
-
  6 QA Plan
+
** It is optional but needed IF "Requirements and Solutions" section does not provide exact solution, just direction
-
  7 History
+
** to be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution.
-
* Since "Systems Analysis" section will not provide exact solution I introduce Implementation Summary section.
+
* <font color="red">SA must first to discuss solution/requirements with Architect/Developer if he feels that request is "not simple and could be translated into alternative non-standard solutions, etc </font>
-
** To be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution.
+
** Not discussing might result in: a) a very lengthy spec; b) rejection of solution later
 +
** Architect / Developer must always find time to talk to SA
-
== Examples ==
+
=== Keep spec simple and short ===
-
Below are examples of spec that were built with new principles in mind:
+
* keep it simple
 +
* keep it short
 +
* do not say same thing twice
 +
* if not sure about something then discuss it first (over mantis,email, Skype) before writing about it in spec
 +
=== Examples of specs that were built with new principles in mind ===
* [[0002525 PI redesign]]
* [[0002525 PI redesign]]
 +
* [[2157 dev]]

Current revision as of 17:29, 23 December 2010


Contents

[edit] Intro

See 1st part of the article here: SA re defined

Subject: New directives to streamline SA (and BA) work

From: CT2 Project Manager

To: CT2 Team

Due to additional negative feedback about recently submitted designs/specifications I introduce the following additional directives:

[edit] Directives

[edit] 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 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.

[edit] 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

[edit] 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]

[edit] 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

[edit] 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

[edit] Spec will have the following structure

1 Info
2 Requirements and Solutions
3 Architect Review
4 Implementation Notes
5 QA Plan
6 History
  • I introduce Implementation Summary section
    • It is optional but needed IF "Requirements and Solutions" section does not provide exact solution, just direction
    • to be completed by Developer. Goal: provide enough info so that QA and UAT know how to verify solution.
  • SA must first to discuss solution/requirements with Architect/Developer if he feels that request is "not simple and could be translated into alternative non-standard solutions, etc
    • Not discussing might result in: a) a very lengthy spec; b) rejection of solution later
    • Architect / Developer must always find time to talk to SA

[edit] Keep spec simple and short

  • keep it simple
  • keep it short
  • do not say same thing twice
  • if not sure about something then discuss it first (over mantis,email, Skype) before writing about it in spec

[edit] Examples of specs that were built with new principles in mind

Personal tools