Cybertrax 2.1 Client (project plan)
From UG
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
- Broadcasts / News posted into mantis: http://mantis.jaguarfreight.com/mantis/view.php?id=2127
- Questions / answers about proj planning should be posted there as well
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
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
