SA re defined part 2

From UG

Current revision as of 17:29, 23 December 2010

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

[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

• template is here Spec Example)

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

• 0002525 PI redesign
• 2157 dev