Cybertrax 2.1 Client (project plan)

From UG

Revision as of 14:53, 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
  • Andriy - Developer
  • Roma - QA and Support

Subcomponents

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

Functionality for this project naturally can be divided into:

  • Shipper functionality
  • Planner functionality
  • Jaguar functionality
  • Misc functionality

All wiki docs are structured this way and mantis tasks as well.

Requirements 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

Implementstion tasks TBD. We might just pass tasks above as we normally do. Kostya has to tell us how they split work inside Impl team.

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

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:
  • completed 2126 Shipper functionality - Finalize specs/document
  • completed 2128 Planner functionality - Finalize specs/document
  • coding: 30% done (what was coded - TBD)
  • QA: 20% done

Actual

TBD

week 4: June 28 Mon - July 2 Fri

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:
  • 2129 Jaguar functionality - Finalize specs/document
  • 2122 Misc functionality - Finalize specs/document
  • coding: 60% done
  • QA: 50% done

Actual

TBD

week 5: July 5 Mon - July 9 Fri

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