SA re defined part 2

From UG

(Difference between revisions)
Jump to: navigation, search
(About)
Line 2: Line 2:
This is a continuation of an effort to streamline SA work. Fist article is here: [[SA re defined]]
This is a continuation of an effort to streamline SA work. Fist article is here: [[SA re defined]]
 +
 +
Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes:
 +
 +
* Alex will do SA for [[Project]] type tasks. All other tasks (tweaks) can be forwarded to Andrei for SA.
 +
** New SA will be hired to provide more m/h
 +
* Kostya will play a role of Architect and must review all [[Project]] type specs and major tweaks.
 +
** He also must post Architect comments into "Architect Review" section (ideally) or mantis
 +
* Spec will have the following structure:
 +
 +
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
 +
 +
* Since "Systems Analysis" section will not provide exact solution developer must fill in "Implementation Summary" so that QA and UAT know how to verify solution.
 +
* 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.
 +
* If Architect rejects solution then it must be returned to SA not BA
== Examples ==
== Examples ==

Revision as of 23:35, 12 December 2010

About

This is a continuation of an effort to streamline SA work. Fist article is here: SA re defined

Based on negative feedback from Dev Manager about a number of recent spec I propose the following changes:

  • Alex will do SA for Project type tasks. All other tasks (tweaks) can be forwarded to Andrei for SA.
    • New SA will be hired to provide more m/h
  • Kostya will play a role of Architect and must review all Project type specs and major tweaks.
    • He also must post Architect comments into "Architect Review" section (ideally) or mantis
  • Spec will have the following structure:
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
  • Since "Systems Analysis" section will not provide exact solution developer must fill in "Implementation Summary" so that QA and UAT know how to verify solution.
  • 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.
  • If Architect rejects solution then it must be returned to SA not BA

Examples

Below are examples of spec that were built with new principles in mind:

Personal tools