T-76.115 Project Review

1
T-76.115 Project Review

• Magnificent Seven
• Project planning iteration4.11.2004

2
Agenda

• Project status (15 min)
• introduction to the project
• status of the iterations goals
• status of the iterations deliverables
• realization of the tasks
• working hours per person
• changes to the project
• risks
• Work results (20 min)
• project plan
• requirements document
• use cases document
• Used work practices (5 min)

3
Introduction to the project

• IRM (Information Resource Manager) is a task
  tracking software for computers used in the RD
  lab at Nokia Networks.
• Lacks a lot of functionalities to be useful
• Only for computers
• Split into several independent versions for
  different resources -gt maintenance problems.
• IRMii is a new and improved version of IRM
• A total re-make with the same functionalities as
  the baseline
• Any resources can be tracked
• Easier maintenance through modular development
• Key aspects
• Task tracking
• Resource reservation
• Re-make of the resource model (hierarcical and
  abstract)
• Modular implementation
• Well-documented
• Usability and maintenance
• Integration with Nokia Corporate network

4
Status of the iterations goals

• Goal 1 Understanding how resource management
  processes
• The customer has given us a good understanding
  about how the processes work in the RD lab. The
  situation in the project group is sound regarding
  this issue.
• Goal 2 Project planning
• The startup and initialization of the project has
  gone quite well.
• Goal 3 Process definitions
• Processes used in this project has been defined
  and we have now together with the outcome from
  project planning a good foundation for the coming
  tasks and challenges.
• Goal 4 Requirements specification and use cases
• This has been one of the major time consumers in
  this phase and if we have something to learn
  from, this would be the issue.
• Goal 5 Learning required tools and techniques
• The required tools and techniques have been
  studied to some extent, but we will continue to
  do this during the coming phase.
• Goal 6 Environment setup
• The environment will be set up during week 45.
  Note this should be OK when we have this review.
• Goal 7 SEPAs
• Initial selection have been done, but the
  implementation will come later.

5
Status of the iterations deliverables

• Project plan
• OK, except the QA plan, which will be added in
  the next phase.
• Requirements document
• This was the biggest part in this first phase and
  we have also been using twice the planned effort
  on it. It is still on a very high level, but this
  is not seen as a problem due to the iterative
  approach we are using.
• Details needs to be added.
• Use cases document
• The main use cases have all been described on a
  general level, but during the coming phase they
  will be made in more detail.
• Use cases will be drawn and updated alongside the
  requirements.
• Weekly status reports
• These have been sent on agreed times.
• SEPAs
• SEPAs have been selected and only the meeting
  practices have been taken into practice as of
  this phase.

6
Realization of the tasks

• There were some small estimation problems
  involving the requirements.
• We had to add all the functionalities of IRM in
  order to understand it better.
• Additional IRMii functionalities were added as
  well.
• Total realized effort is lower than the planned,
  but there are unplanned tasks that takes the
  grand total to the estimated level.
• Not started PHP documenting convention was put
  under some other task.
• Grand total 346.5 hours (1.5)

7
Working hours by person
Realized hours in this iteration
Real Plan Diff
Alexei 38 40 -2
Huan 49.5 48 1.5
Jing 40.5 35 5.5
Kalle 29 33 -4
Marko 62.5 58 4.5
Tommy 100.5 99 1.5
Zhiyi 26.5 32 -5.5
Total 346.5 345 1.5

• The requirements needed much more time than
  expected.
• The planned effort didnt include all needed
  tasks -gt added tasks.
• We needed to change the plan due to new tasks
  were needed to be done or that we had to put in
  more effort on some areas.
• Marko has also been developing our internal
  documentation system and this has taken time, but
  will help us in the future and hopefully help us
  save time and effort.

8
Working hours by person
Realized hours in this iteration
Plan in the beginning of this iteration
Real Plan Diff
Alexei 38 40 -2
Huan 49.5 48 1.5
Jing 40.5 35 5.5
Kalle 29 33 -4
Marko 62.5 58 4.5
Tommy 100.5 99 1.5
Zhiyi 26.5 32 -5.5
Total 346.5 345 1.5
PP Subtot I1 I2 FD Total
Alexei 34 34 64 53 50 201
Huan 38 38 53 58 52 201
Jing 32 32 53 59 54 198
Kalle 33 33 52 62 52 199
Marko 46 46 68 58 30 202
Tommy 83 83 41 37 55 216
Zhiyi 32 32 63 64 42 201
Total 298 298 394 391 335 1418
Latest plan (inc. realized hours and other
updates)

• The requirements needed much more time than
  expected.
• The planned effort didnt include all needed
  tasks -gt added tasks.
• We needed to change the plan due to new tasks
  were needed to be done or that we had to put in
  more effort on some areas.
• Marko has also been developing our internal
  documentation system and this has taken time, but
  will help us in the future and hopefully help us
  save time and effort.

PP Subtot I1 I2 FD Total
Alexei 38 38 64 53 50 205
Huan 49.5 49.5 53 58 52 212.5
Jing 40.5 40.5 53 59 54 206.5
Kalle 29 29 52 62 52 195
Marko 62.5 62.5 68 58 30 218.5
Tommy 100.5 100.5 41 37 55 233.5
Zhiyi 26.5 26.5 63 64 42 195.5
Total 346.5 346.5 394 391 335 1466.5
9
Changes to the project

• We will continue as planned no changes to the
  next iterations.

10
Risks

• Risks can be found in the Project plan, chapter
  7.
• The major risk is the project schedule and that
  we will not make the planned deadlines.
• We will have to plan each iteration very
  carefully.
• Close monitoring of the tasks progress.
• Another risk is that we have too little time per
  person and this will affect the outcome of the
  project.
• We need to discuss this and see if we should
  adjust the working hours.
• Solution two is to prioritize and drop
  requirements.
• Project group members not available for a
  critical stage in the project.
• Sickness
• Other reason

11
Results of the iteration

• Project plan
• Requirements document
• Use cases document

12
Project plan (1/4)

• Stakeholders
• Staffing

13
Project plan (2/4)

• Project goals
• Customer goals
• IRM functionalities as the baseline
• Fully-functional core system
• Modular and extendable system
• Implementation and documentation has good quality
• Light-weight and easy to use
• Project groups goals
• Satisfy the customers needs
• Get a good grade, preferably 5
• Learn new software engineering practices

14
Project plan (3/4)

• Practices and tools
• Iterative development
• Course requirement
• Iteration planning
• Planning the phase so everyone knows what we aim
  for
• Time reporting
• Weekly each Sunday
• Weekly plan is sent to PM each Sunday
• Weekly status report is sent to customer and
  mentor
• Documenting
• Marko has developed an XML-based system for
  collecting all project-related information.
• All members will be responsible for a part of the
  system.
• Requirements management
• Account manager will monitor the progress of the
  requirements.
• Version control
• CVS, SVN
• PHP conventions
• PHP standard conventions from PHP.net
• Communications

15
Project plan (4/4)

• Phasing
• Project planning is ready
• Implementation 1 should focus on the technical
  specifications and some of the systems core
  framework.
• Implmentation should implement most of the
  functionalities. This will be the phase when we
  put most effort into getting the system
  developed.
• FinalizationDelivery is maunly for correcting
  minor issues and bugs. Delivery to customer is
  the milestone in this phase.

16
Requirements document (1/2)

• The main requirements have been defined and
  recorded.
• Detail will be added when we identify the needed
  issues to add.
• The focus has been to get the big picture in this
  iteration and when people will get more into the
  system we can much easier add more requirements.
• This document will be updated quite much during
  the second phase as well, due to the technical
  specification.
• Functional requirements
• Resources
• Requests
• Reservations
• Tasks
• Reports
• Users
• Programs
• Projects
• Event log
• Other modules

17
Requirements document (2/2)

• Non-functional requirements
• Lookfeel
• Usability
• Performance
• Operational
• Maintenance and portability
• Security
• Cultural and political
• Legal
• Constraints
• Solutions

18
Use cases document

• The main use cases have been identified and
  recorded.
• Use cases will be finalized in the second phase.
• Use cases will be drawn.
• This contains more or less the essential parts of
  the system already, but will be modified a bit
  due to updates in the requirements document and
  technical specification.

19
Used work practices

• Mandatory practices
• Iteration planning
• Should be done better in the coming phases, so we
  might not have the same problems with deadlines
• Time reporting
• Fairly good way for the PM to monitor
• Documentation system
• good way to have everything in one place
• easy to transform into other format
• Version control
• good when in distributed team
• Communications
• this is an issue to tackle when working in
  distrubuted way
• More experiences as the team developes this in
  the coming phases
• SEPAs
• Meeting practices
• Heuristic evaluation (not used)
• Test-driven development (not used)
• Static methods (not used)
• We are going to adopt more practices during the
  coming phase and we will have much more to tell
  about these afterwards.

20
Questions?