Cybertrax 2.1 Client (project plan)

From UG

Revision as of 19:55, 22 June 2010 by Alex (Talk | contribs)
Jump to: navigation, search


Contents

About this doc

This wiki provides all Proj Management info for Cybertrax 2.1 Client project.

Intro

This project is very important therefore planning is critical.

Time vs Features vs Quality

Focus of this project is to deploy minimal set of core features ASAP. As a result feature set will be reduced to minimum and quality might be average (but must not fall below reasonable level)

Time allocated and Error margin

Summary of time allocated:
 * only 1 week for analysis and requirements gathering
 * only 1 week for design
 * only 3 weeks for coding, testing, rollout/training planning
 * only 1 week for staging/release
-----------------
Total: 6 weeks
                 NOTE: This is an estimate. Error is -1 week/+2 weeks.

Project documentation

All information is gathered and structured in several wikis under Category:Cybertrax 2.1 Client

Current list of docs:

Cybertrax 2.1 Client (Q and A)
Cybertrax 2.1 Client (data dictionary)	 
Cybertrax 2.1 Client (design)
Cybertrax 2.1 Client (glossary)
Cybertrax 2.1 Client (project plan)	 
Cybertrax 2.1 Client (requirements)
Cybertrax 2.1 Client (use cases)

Project communication

All communication is done through:

  • mantis
  • Skype
  • email (everyone must check min 2 times a day and reply or at least confirm e-mail received same day)
  • Q and A wiki article: Cybertrax 2.1 Client (Q and A)

All mantis tasks are under this parent: http://mantis.jaguarfreight.com/mantis/view.php?id=2077

Project broadcasts and forum

Project update meetings

  • who must attend: Andrei, Sasha, Alex, Denise, Tira
  • Tuesd, Thursd 10-11am
  • Skype chat
  • Coordinator on NY side / Host: Alex
  • Coordinator on Kiev side: Andrei

Project Team and responsibilities

  • Alex - Proj Manager and Solutions Architect; responsible for:
    • proj management/coordination
    • solution architecture/structure
    • helping everyone as required

Requirements and Documentation Team

  • Denise - Business Analyst; responsible for:
    • gathering requirements and interfacing stackeholders/clients/module owners
    • documenting requirements (#RFP specs)
    • must help Sys Analysts to discover info
    • proof reading/editing docs (in terms of English lang)
  • Tira - Systems analyst; responsible for:
    • creating solution based on requirements
    • documenting design
    • focus on creating user interface mockups
    • helping Denise in more technical aspects of requirements gathering/analysis
  • Andrei - Systems analyst; responsible for:
    • creating solution based on requirements
    • documentation (managing #3CS specs)
    • focus on analysing all existing docs and making sure nothing is missing

Implementation team

  • Kostya - Development Manager
  • Sasha - Lead developer
    • serving as a communication liaison between Implementation team (Kiev) and Requirements team (NY)
  • Andriy - Developer
  • Roma - QA and Support

Tasks

It is very important to find a good way to disect an monster into pieces to be able to digest it.

Requirements and Documentation tasks

  • 2126 Shipper functionality - Finalize specs/document
  • 2128 Planner functionality - Finalize specs/document
  • 2129 Jaguar functionality - Finalize specs/document
  • 2122 Misc functionality - Finalize specs/document

Support tasks

  • 0002140: (Client 2.1) Create User Guide, Rollout Schedule, Training Plan, Support plan

Implementation tasks

week 1

  • 2134 (Client 2.1) (implementation) Add Shipper, Planner roles to Non Jag User profile
  • 2135 (Client 2.1) Create all new DB fields

week 2

  • 2136 (Client 2.1) Code core Shipper functionality (create/edit/delete/list CTs)
  • 2137 (Client 2.1) Code core Planner functionality (authorize/list CTs)

week 3

  • 2138 (Client 2.1) Code all Jaguar functionality (new fields, constraints, Approval Report)
  • 2139 (Client 2.1) Code all misc functionality (notifications, etc)

Weekly Plan

Note: This plane have not been approved yet!

Important Dates

  • 1st date for Release: Thur, July 15
  • 2nd date for Release: Thur, July 22

File:2010 summer calendar.JPG

week 1: June 7 Mon - June 11 Fri

Plan

  • meetings with clients
  • preliminary design sessions
  • end of the week targets:
  • requirements: 50% done
  • design: 30% done
  • documentation: 10% done
  • coding: 0% done
  • QA: 0% done

Actual

Completed as planned!

week 2: June 14 Mon - June 18 Fri

Plan

  • analyze requirements
  • invent design
  • write detailed documentation
  • Wed 2pm: send draft to Simon, Marc
  • Fri 4pm: send ver 1.0 to Bill
  • end of the week targets:
  • requirements: 80% done
  • design: 70% done
  • documentation: 60% done
  • coding: 5% done
  • QA: 0% done

Actual

Completed as planned!

week 3: June 21 Mon - June 25 Fri

Coding week #1

Plan

  • Mon/Tue tasks for every developer must be defined/assigned, start coding
  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • end of the week targets :
    • specs:
      • 2126 Shipper functionality - Finalize specs/document
      • 2128 Planner functionality - Finalize specs/document
    • code:
      • complete 2134 (Client 2.1) (implementation) Add Shipper, Planner roles to Non Jag User profile
      • complete 2135 (Client 2.1) Create all new DB fields
      • start 2136 (Client 2.1) Code core Shipper functionality (create/edit/delete/list CTs)
    • metrics:
    • code: 30% done
    • QA: 20% done

Actual

TBD

week 4: June 28 Mon - July 2 Fri

Coding week #2

Plan

  • continue coding and QA
  • start UC testing
  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • end of the week targets
    • specs:
      • complete: 2129 Jaguar functionality - Finalize specs/document
      • complete: 2122 Misc functionality - Finalize specs/document
    • code:
      • complete: 2136 (Client 2.1) Code core Shipper functionality (create/edit/delete/list CTs)
      • start: 2137 (Client 2.1) Code core Planner functionality (authorize/list CTs)
    • metrics:
    • code: 60% done
    • QA: 40% done

Actual

TBD

week 5: July 5 Mon - July 9 Fri

Coding week #3

Plan

  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • end of the week targets:
  • complete coding and QA
  • complete UC testing
  • Create User Guide, Rollout Schedule, Training Plan, Support plan
  • documentation: 100% done
  • coding: 100% done
  • QA: 100% done

Actual

TBD

week 6: July 12 Mon - July 16 Fri

Plan

  • QA on staging
  • Release
  • Mon 9am: release to Staging
  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • Thur 7-8pm: release to Production

Actual

TBD

week 7: July 19 Mon - July 23 Fri

Plan

  • "2nd release date" in case we could not release previous week
  • Mon 9am: release to Staging
  • Tue 10pm: Kiev/NY status update
  • Thur 10pm: Kiev/NY status update
  • Thur 7-8pm: release to Production

Actual

TBD

Appendix. Two types of specs

Lets introduce the following.

RFP specs

All specs start as informal collection of information. At this stage they could be considered as a Request For Proposal. That is why this type of spec called "RFP type". .

3CS specs

Gradually specs should take shape and finally considered to comply to 3CS:

  • complete
  • correct
  • clear
  • structured

These type of specs we call "3CS specs".

Appendix. Two types of Design methodology

Lets introduce the following.

White box design

What we follow now in most cases:

  • Requirements doc completed
  • Sys analyst creates and documents Design based on Requirements doc
  • Design goes through review process
  • developer codes based on Design doc
  • QA tests based on Design doc

Black box design

Alternative approach:

  • Requirements doc completed
  • Developer codes based on Requirements doc (creating functional Prototype)
  • Sys analyst creates and documents Design based on Prototype
  • Design and Prototype go through review process
  • QA tests based on Design doc
Personal tools