...

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.6 Pre-delivery for examiner and writing course Project deliverables to examiners and jury on November 16
3.7 Final presentation and demonstration on November 21 23
3.8 Anti-plagiarism
3.9 Copyright or Intellectual Property Rights (IPR)
3.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

...

Several evaluations have been carried out of previous versions of TDT4290 (i.e. "Systemering prosjektarbeid" and "Programmering prosjektarbeid"). These evaluations are generally very positive. See Markus Sorge: "Evaluering av prosjektundervisningen ved IDI, NTNU", Program for lærerutdanning, NTNU, spring 2000, 63p,
http://www.idi.ntnu.no/undervisning/siving/docs/prosjektevaluering.pdf.
Technology is experience-based knowledge – composed and refined over many years − to be able to satisfy human-societal needs in a cost-effective way. Engineering is the process of combining and applying suitable technologies to construct specific means, such as houses, food, clothing, roads, bridges, vehicles, books, sewing machines − and recently − computer- and information systems. That is, an engineer creates new reality (e.g., kitchen tables) − not only studies the existing one (e.g., a humming bee in a forest).
Engineering requires a domain-specific methodology (a technology itself) for how to describe the actual context − being farming, bridge-building, or banking. An engineer will apply scientific insight (both technical and social), combined with knowledge and experience from many sources – all representing different technologies. It is often a strong relationship between what is being constructed and the available time, budget, and tools / methods. Because of the substantial complexity and diversity of the engineering work and the characteristics of the processes, it is often necessary for several people to work together. That means that engineering has a social dimension, since it is executed as group work. Cooperative and communicative skills are therefore essential.
Project work in teams is an important part of the engineering discipline. Your study program at NTNU is among the ones with most emphasis on project work. Project work means on the one hand that you need to make an agreement with a customer (customer / organization) about what should be constructed. On the other hand, you have to design and implement technical solutions that satisfy the elicited constraints and requirements. You also have to consider changes over time, as most customers are not sure about what they really want. As a consequence, the proposed unfinished solution must be modified. The project groups must also be well organized and effective, and try to avoid destructive internal conflicts.
All this means that you will get a hectic work situation – sometimes at the edge of chaos. You have to combine your theoretical knowledge from previous courses to solve specific and practical problems. You have to use a considerable amount of effort in cooperation, communication, planning, and improvisation and show capabilities of working under pressure.
Your project will give you essential training to become a professional software engineer. Feedback from industry says, that it is almost impossible to get more done in 3 months than what such a group of students is capable of. Further, software engineers from NTNU are useful from day one: they posses the theoretical knowledge and know how to work efficiently in teams.
So, the expectations are great from all participants: the IDI department, lecturers, advisors, external customers and of course the students themselves. The project report (written in English) should not be more than 200 150 pages, exclusive appendices and graphics.
If your group experiences that some of the team members are not participating satisfactorily, you should immediately contact your advisor. If you experience other minor problems, the advisor is the one to contact. However, most (minor) problems are to live with; in fact, it is a part of the course to learn to deal with such issues in a project.
So, welcome to an interesting and hectic semester in this course!

...

We expect about 80 students in total. This gives in total 12 groups with 6-8 students per group. Each group is preallocated to one customer and one group advisor. The groups should therefore have a tight cooperation with their advisor.
Group assignments are essentially made randomly. This is done intentionally to create groups where the members generally do not know each other beforehand. This is a typical situation in a real life, especially when working as a consultant.
Since many of the students in the course are foreign, with limited or no knowledge to Norwegian language, the lectures and seminars will be held in English.

Rating of project work

The project work will be evaluated based on the basis of the quality of the project report,the functioning prototype of the system, the video and the presentation delivered at the end of the course as well as and the students' reflections on the project work. The project will be evaluated by delivered report, the functioning prototype of the system, the final presentation and the reflection report, which all are included in the final delivery.   The project is intended to be conducted as a team work effort. This also means that the team dynamics will have an impact on the final grade. The final grade is a composition of the abovementioned components.

The project report must be written in English, and the presentation must be done in English,. Both the The project report, the video and the presentation count towards the grade in an integrated way (they are not formally weighted against each other).
How   How the group actually has worked, technical problems, customer behaviour and availability, etc. are a part of the reflections report . The group is asked to deliver a 3-4 page report, reflecting upon their experiences during the project and reflecting upon what they had learned and how they could have done things differently. The focus of this part is on the process rather than the product. This report is due at the end of the course and will be evaluated by the group advisor and the course coordinator.

The following criteria are evaluated in an integrated way:

• Whether the group has solved the given assignment, according to the customer's objectives of the project.
• Team work efficiency and the team dynamics
• Team work process improvement efforts
• Reasonable grounds for decisions taken.
• Logical flow in the report.
• Visibility of limitations doneimposed.
• Layout and structure readability.
• The students' ability to reflect on the process during the project.

The criterias are not formally weighted against each other.
Note  Note that since the presentation counts towards the grade, it is important that you maintain a functioning version of your program in case you (the group) appeal the result (grade). If an appeal is made, you will have to make your presentation for the new examiner, including demonstration of the program.

...

All material included in the final delivery (project documentation, prototype of the system, reflection report, final presentation) should be delivered to the group's advisor by midnight of the final delivery date. The group agrees with the advisor the delivery protocol (email, dropbox, google docs, other). 

...

Project deliverables to examiners and jury on November

...

16

By November 16 (23:59) every group needs to email the following to the course responsibles (Letizia Jaccheri and Jon Atle Gulla) and the course coordinator (Kristin Karlsen):

• URL of final project report (pdf)
• URL of 1 minute video presenting their project and product

Note that there is no printed deliverables in the course.  Since it is only the report that is handed in on November 16, you may still modify your code until the final presentation on November 23 (as long as it does not affect the report itself). 

Final presentation and demonstration on November 23

Follow up on https://www.ntnu.no/wiki/display/tdt4290/ for details about the arrangement for the day Follow up on https://www.ntnu.no/wiki/display/tdt4290/ for details about the arrangement for the day.
All groups have to make their presentations in English.

Room: Rooms are reserved for the final presentation. If the project demonstration requires special facilities (such as virtual reality or cave equipment), the groups can also book and have the presentation in other rooms. If your group needs to have the presentation in a specific room, please notify the course coordinator (Kristin Karlsen). Remember that the room must have space for 10-15 persons. The time and place for each presentation, will be published on the course webpage.
Laptop: Most groups use one of their personal laptops for the demonstration. If your group do not have a suitable laptop for the presentation, please notice drift@idi.ntnu.no two weeks before the presentation. A beamer will be made available in all presentation rooms.
Copying project documents: We want four printed and bound copies of the project report. The costs for copying and binding four complete project reports are covered by IDI. Copying should be carried out, at the latest, one day before the final presentation

Deliverables on November 23:

• USB key with final report, video, code and presentation slides to customer
• Presentation slides URL and code (e.g.

...

• Github) to course coordinator

The presentation schedule of November 23 is as follows:

Please note the following:

• The present day starts with an obligatory introduction at 9.30 in Drivhuset.  All students should attend.
• All members of the groups are to be present during their own presentations.
• The presentations are in English and open to the public.  The groups must invite their customers, but may also invite other people that have been involved in the project or may find the project results interesting.  The supervisors will be present.
• Normally a presentation includes both a description of the project as well as a video and demo of the implemented system.
• Each presentation is up to 30 minutes long, including the video and demo.  The examiner and the general audience have up to 15 minutes for questions.
• The group hands over the USB key to the customer at the end of their presentation.
• The presentation rooms are equipped with projectors, but other necessary equipment must be brought and installed by the student groups themselves.

• Customer
• Examiner
• IDI archive
• Advisor

...

Anti-plagiarism

The rules for this are very strict, see §36 in "Forskrift om studier ved NTNU" (page 23 in "Studiehåndbok for Sivilingeniørstudiet 2011-12") regarding cheating and http://www.lovdata.no/all/hl-20050401-015.html#4-7
See also http://www.idi.ntnu.no/grupper/su/publ/ese/plagiarism.html.

...

• 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

  Anchor
  h.206ipza h.206ipza

  Appendix C – Content of the phase/sprint documents/chapters
  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:

1. 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.

1. Questions: max 5 minutes

...

1.  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:

...