...
Table of contents
1 Introduction
1.1 General information
1.2 Goal and rationale of the course
1.3 Required Knowledge
2 Motivation on Project Work and Group Dynamics
2.1 About the Course
2.2 Project work in a didactic perspective
2.3 Training in group dynamics
3 Administrative information
3.1 Work load
3.2 Timeline
3.3 Group assignments
3.4 Rating of project work
3.5 Supervision and meetings
3.5 6 Project deliverables to examiners and jury on November 16 16
3.6 7 Final presentation and demonstration on November 23
3.7 8 Anti-plagiarism
3.8 9 Copyright or Intellectual Property Rights (IPR)
3.9 10 Course reflection, evaluation and feedback feedback
Appendix A – The project plan
A1. Overall project plan
A2. Concrete project work plan
A3. Project organization
A4. Templates and standards
A5. Version control procedures
A6. Documentation of project work
A7. Quality Assurance (QA)
A8. Test plan
Appendix B – Suggestion for appendices in your project plan
B1. Partners
B2. Concrete project plan
B3. Detailed phase plans
B4. Table for handling of risks
B5. Table for effort registration
Appendix C – Content of the phase/sprint documents/chapters
C1. Introduction
C2. Planning
C3. Pre-study of the problem space vs. solution space
C4. Lifecycle model: waterfall vs. agile?
C5. Requirements Specifications
C6. Estimation of realization effort of a use-case model
C8. Programming
C9. Testing
C10. Internal and external documentation
C11. Evaluation
C12. Project presentation and demonstration
C13. Appendices
4 APPENDIX D – Administrative and Technical Resources
D4.1 Office Resources
D4.2 Technical Resources
D4.2.1. Workstations
D4.2.2. Source Control Management
D4.2.4. Use of collaboration technology in the project
5 Appendix E – SCRUM – a popular agile method
E5.1. Product backlog
E5.2. Sprint planning meeting
E5.2.1. Daily Scrum status meeting
E5.2.2. Irregularities
E5.2.3. Sprint review meeting
E5.2.4. How do I prepare a project for Scrum (short tutorial)
6 Appendix F – Use-case based effort estimation
F6.1. Introduction to use-case estimation
F6.2. More on the estimation method
F6.3. A mini-discussion
F6.4. References
F6.5. Appendix: A small use-case diagram, with extra comments
F6.6. Add-on to use-case example
7 Appendix G – Guest Lectures
...
- means irrelevant
Let us assume that two time periods (T1-T2) have passed, with T3 just about to start.Anchor h.3l18frh h.3l18frh
Observation: in activity A1 after time T2 the Estimated running effort is 10 ph and the estimated accumulated effort (i.e. including T1) is 20+10 = 30 ph. However, the Actual effort for A1/T2 is 12 ph, and the accumulated effort is 13+12 = 25 ph. So it seems that A1 is a bit behind the estimated effort ("plan") – but that can have many valid reasons. We are only measuring resource usage (effort, time), not the actual state of the software under development!
Ex. what advice will you give to all the activities A1-A3 for the last T3 period?Anchor __RefHeading__28162_946898870 __RefHeading__28162_946898870
Appendix C – Content of the phase/sprint documents/chaptersAnchor h.206ipza h.206ipza
This appendix contains information about what the different phase documents (or report chapters) should include. See also former project reports for more details.
That is, it is common to divide a waterfall-based software project into the following 13 (or so) phases, whose
documentation whose documentation then becomes a chapter in your final project report:
C1. Introduction
C2. Planning
C3. Pre-study of the problem space vs. solution space
C4. Choice of lifecycle-model: waterfall vs. agile?
C5. Requirements specifications
C6. Estimation of realization effort for use-case model
C7. Construction/ design
C8. Programming
C9. Testing
C10. Documentation
C11. Evaluation
C12. Presentation and demonstration
C13. Appendices
If an agile lifecycle model is chosen, like in Scrum, we recommend one "phase" (or report chapter) per Scrum-sprint, typically 2-3 such. These "Scrum phases" will then replace the waterfall phases C5-C10. It may still be useful to include an initial requirements chapter and an initial Design and Architecture chapter, but this may vary from one project to another. It may also be a good idea to include a final Test chapter with test plans and test results.
Below you will find some more information on what each phase document is expected to contain. Note that the group can also select another phasing. C1. Introduction
Write a good, one-page abstract early, and explain the overall context, motivation, demands and results.C2. Planning
See appendix A – Project plan.C3. Pre-study of the problem space vs. solution space
The preliminary studies are vital for the group to obtain a good understanding of the total problem. Here, you will have to describe the problem at hand. You should describe the current system and the planned solutions (text, workflow, use-case scenarios, information flow, and other graphical presentations you can use). It is all about getting a good understanding of the challenges ahead! The group should investigate if existing and potentially competing solutions exists on the market. If such solutions exist, they should be described. You should also describe alternative solutions that fully or partially require custom implementations. The group must also set up evaluation criteria that form the basis for choice of a solution. Software by third party software providers (as OSS or COTS) should be actively pursued as candidates for implementation of large parts of your software system, see http://sourceforge.net
In cases where existing components can be applied as modules in the project solution, a simple cost-benefit analysis should be carried out.
Summary:
Describe the main business requirements, both functional and non-functional, that will constitute the requirements for the final solution and its functionality. These requirements will later form the base for later formalization of requirements. Try also to make use-case diagrams to express the major functional requirements, cf. the simple effort-estimation method in Appendix F.
Describe the situation and solutions of today ("as-is")
Describe the wanted situation and its possible solutions ("to-be")
Evaluation criteria
Market investigations
Description of alternative solutions
Evaluation of alternative solutions, including adjusted requirements and potential costs and benefits.
Choice of solution, in dialog with customer.
To conclude, the pre-study should have two main deliveries:- A (partly) prioritized set of requirements – cf. the Scrum "backlog".
- A proposed system architecture to enable a fast break-down (modularization) of the technical work
...
It is important to describe hidden problems that can have affected the work but is not shown in the project report. Make sure that you also describe any additional work that is not shown in the project report.
C12. Project presentation and demonstration
To be used in Section 3.7.
The start-up is divided into three parts:
- Presentation og video
Explain the project assignment and goals
Problems and priorities
Which solution did you choose? What were the alternatives? Why did you choose the final solution?
A description of the final solution
Some final reflections
...
Show your implemented prototype and its main functionalities. The presentation, video and demo should not exceed 30 minutes.
- Questions: max 5 minutes
...
- 5-10 minutes
Remember to give a hand-out of the presentation to your advisor, customer and external examiner (censor) at the presentation.
C13. Milestones and Feedbacks
At the beginning and the end of this class, each team will be asked to fill some questionnaires about this classes and yourself. For example, they may ask "What do you expect from this course?", "Have you participated any project before?", "Which parts do you think need to improve? And how to improve?" etc.
At each stage or phase of the development, each team needs to write their results into documents. Then the supervisors will collect them as feedbacks and basis of the next plan. We recommend the stage/phase report contain the following parts:
...