...

 

...

EMPLOYER
IDI, NTNU

...

 

...

COURSE
TDT4290 Customer Driven Project

...

 

...

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

Anchor
__RefHeading__28094_946898870 __RefHeading__28094_946898870

Anchor
h.30j0zll h.30j0zll

Introduction

Anchor
__RefHeading__28096_946898870 __RefHeading__28096_946898870

Anchor
h.1fob9te h.1fob9te

General information

This master-level course TDT4290 Customer Driven Project deals with a project assignment that is mandatory for all computer science ("Datateknologi") students in their 4th study year at NTNU/IDI, typically with 50-75 and mostly Norwegian students. In addition there are participants from the two-year, international master program in Information Systems at IDI (with 5-10 students from all over the world), plus Erasmus and other guest students (usually a handful of Europeans).
This compendium contains all the necessary information for this course, the assignments (one for each project-group), and a suggested outline for the final project report. In addition, some examples of what a project plan should contain.
Practical information regarding project-group composition, dates etc. can also be found on the web page of the https://www.ntnu.no/wiki/display/tdt4290/. All students should check this web page for updates. In case of mismatch between information in this compendium, information given during lectures, by email, and on the above web page, the last updated information should be regarded as correct. The following IDI people are involved with this course:
Course responsibles:
Prof. Jon Atle Gulla Course responsible jag@idi.ntnu.no tel 73591847
Letizia Jaccheri Course responsible letizia.jaccheri@ntnu.no tel 91897028
Kristin S. Karlsen Practical coordinator kristika@idi.ntnu.no tel 73595204
Group advisors:

...

Students will be divided in project groups of 6-8 students (detail in Section 3.3). Each group will be allocated an advisor from IDI - either a faculty member, a postdoc or a PhD student - plus a main customer representative.
The mandate of the advisor:
The group's advisor serves as a one-person "steering committee" for your project. His/her responsibility is to keep an eye on the main process of the work, and to oversee that sufficient contact with the customer is maintained. The advisor must therefore regularly receive updated status reports, copies of relevant work plans and technical documents from the group, so that all this can be discussed in a weekly advisor meeting.
In addition, the group should have several, weekly internal meetings, and regular customer meetings (detail in Section 3.5),

Anchor
__RefHeading__28098_946898870 __RefHeading__28098_946898870

Anchor
h.3znysh7 h.3znysh7

Goal and rationale of the course

The goal of course TDT4290 is to teach you and your fellow students – by working in groups –software engineering (SE) skills in the context of a development project to make a realistic prototype of an Information System (IS) "on contract" for a real-world customer.
Each project group is initially given a one-page project assignment from an external customer. All the phases of a typical IS/IT project are covered, e.g. project management and planning, pre-study, requirements, design, programming, testing, evaluation and documentation, but no "maintenance". However, we do not accept customers that just want the group to write a "summary and evaluation" of some hot topic, with no ensuing implementation. And inversely, we do not want customers that come with pre-made requirements, and just want the group to complete a pre-designed system architecture.
Due to resource constraints, the focus should nevertheless be on delivering a system or a prototype of system of called the minimum viable product (MVP). Sometimes the focus may be on the "early" lifecycle phases, i.e., project planning, pre-study, requirements specifications and system design – but the exact focus and emphasis will be decided by the group, in dialog with their customer. For instance, groups with focus on the early phases should not omit making a working prototype of some system parts. On the other hand, "programming-eager" groups may try to make a rather complete prototype, e.g. by applying agile iterations in Scrum-style (see C.4 and Appendix F). The important issue is that the group clearly justify their decisions, and that there is a logical flow in the project report from start to end of all the phases, and that all the phases and iterations build naturally on each other.
Each group should write a project report in English, and hold a presentation and demonstration of the final prototyped product for the customer, while an external examiner (censor) is present.
If a fundamental disagreement with the customer arises, the group has, if needed, "the final word" since the group members gets the credit through a final exam (report) worth 15 Sp. But such a dead-lock situation has hardly happened in the 40 years that this course has been arranged! However, the group and their advisor should do what is possible to resolve any major disagreements. Conflicts are to be explained, negotiated and resolved (managed), as this is part of the real world work. It is therefore crucial that the group is focused and has a good dialog with the customer.

Anchor
__RefHeading__28100_946898870 __RefHeading__28100_946898870

Anchor
h.2et92p0 h.2et92p0

Required Knowledge

Required theories and methods for making large and long-lived SE/IS systems are mostly covered in previous, bachelor-level courses. This knowledge base is supplemented by a double seminar on group dynamics, and four guest lectures on project management, Scrum, IT architecture, and use-case based effort estimation. In addition, we arrange a course in presentation techniques and a seminar on technical writing. These seminar, lectures and courses are mandatory. We will also recommend you to attend the course in drawing. That is voluntary.
Since 2008 in this course, the students have been encouraged to use the Agile software development method so-called "Scrum Given the time constraints of this student project, there is hardly time for more than 2-3 increments, called "sprints" in Scrum. Other agile methods, namely Extreme Programming, Kanban, Lean Software Development, Mobile-D and others may be considered as well. In reality, the method followed in the course is a composition of many methods. This should be carefully documented in the project documentation.
Many groups have since 2008 chosen an agile development model and had good results. As mentioned above, the structure of the final project report must reflect the choice of overall lifecycle model, i.e. waterfall vs. iterative/agile development methods.

Anchor
__RefHeading__28102_946898870 __RefHeading__28102_946898870

Anchor
h.tyjcwt h.tyjcwt

Motivation on Project Work and Group Dynamics

Anchor
__RefHeading__28104_946898870 __RefHeading__28104_946898870

Anchor
h.3dy6vkm h.3dy6vkm

About the Course

 

The goal of this course is to teach fundamental software engineering skills through realistic training in software development and project management. You will have the opportunity to apply the knowledge you have gained previously is your studies. During this course, you will experience situations that will require:

• Decision, solving and design and development of a relatively large and complex system.
• Creative and collaborative problem solving. Earlier in your studies, the tasks have been smaller and more well-defined. In this project, there are (conflicting) decisions to be made. You will have to show creativity, be pragmatic and be capable of solving fuzzy tasks under heavy time and resource constraints; i.e. fast decision making under great uncertainity.
• Coordination of efforts and distribution of work and responsibilities.
• Project management, cooperation, decisions, follow-ups, and a dispute resolution.
• Ability to adapt to no-ideal working situations.
• Planning and execution of plans. This involves creation of project plans and registration and monitoring of effort and resource usage.
• You must handle difficult customers. They can be unreliable and/or unavailable. They might change directions, come up with new ideas, and have an unclear picture of what they really want. An important part of this course is to manage the group project, so that the results match the customer's needs, even though the situation may turn difficult. This requires routines for quality control. Each group should deliver a project plan with resources and milestones, coupled to quantitative measures, and use both "dry" verification (mainly reviews) and "wet" testing.
• Structuring of requirements specifications.
• Documentation. The project documents must be complete, well structured and target the technical knowledge level of the customer.
• Defend decisions that are taken on behalf of the customer. You should document all delays, overruns, and weaknesses, so that they can be explained and argumented. Ideally, all decisions should match conditions coming from the customer (the customer has the right to complain on any aberration that is not his/her fault).
• To present (and sell) the final product for the customer / external examiner. Under the final presentation and demonstration, it is important to give the customer a complete and good impression of the system delivered.

 

Anchor
__RefHeading__28106_946898870 __RefHeading__28106_946898870

Anchor
h.1t3h5sf h.1t3h5sf

Project work in a didactic perspective

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!

Anchor
__RefHeading__28108_946898870 __RefHeading__28108_946898870

Anchor
h.4d34og8 h.4d34og8

Training in group dynamics

Good teamwork and group dynamics are essential for the success of any collaborative project. Therefore, "social" skills are of upmost importance to become a successful project co-worker. A seminar on group dynamics is planned as a part of this course, to support the project groups to learn more about team work and group dynamics. In addition to the seminar, the following time slots should be used wisely to create a good team atmosphere among your group, particularly at the beginning of the project.

Anchor
__RefHeading__28110_946898870 __RefHeading__28110_946898870

Anchor
h.2s8eyo1 h.2s8eyo1

Administrative information

 

Anchor
__RefHeading__28112_946898870 __RefHeading__28112_946898870

Anchor
h.17dp8vu h.17dp8vu

Work load

NTNU has officially an autumn semester with 19 weeks, and a spring semester with 21 weeks. Of the former 19 weeks, two are spent on continuation exams (and immatriculation etc.), and three are spent on exams in December − which you don't have. This implies 17 "study weeks" in the autumn semester, each of 40 person-hours (work-hours) per student. This again corresponds to 340 (17 * 25% * 40) person-hours per student for a "15-Sp" course (50% of 30-Sp semester total). Note that an hour has 60, not 45 minutes.
Since this project runs in 14 weeks (really 13.6) instead of 17 weeks, the weekly effort per student then be adjusted to 40 * 50% * 17/14 = 24.3 person-hours.
Furthermore, the official web page of the course − http://www.ntnu.edu/studies/courses/TDT4290 − specifies 24 weekly person-hours per student, but this is for 14 weeks. So let us round off to 25 person-hours per week and student, i.e., 350 person-hours per student for totally 14 weeks.
For a project group of 5-6 students, the available effort per group will lie between 1750 and 2100 person-hours, including own reading, meetings, lectures, and seminars. Earlier projects have shown that it is possible to deliver really good results within that timeframe.
It is important that everyone is honest and registers all effort (as person-hours) spent on the project. This means that the project documents must show the real work load. Effort overruns will result in less sparetime for you personally and less time for other courses. Inflated work effort does not affect the grades given in this course!

Anchor
__RefHeading__28114_946898870 __RefHeading__28114_946898870

Anchor
h.3rdcrjn h.3rdcrjn

Timeline

Anchor
h.26in1rg h.26in1rg

This is the preliminary time plan for the activities of this course. For further details and updates check http://www.idi.ntnu.no/emner/tdt4290/.

Anchor
__RefHeading__28116_946898870 __RefHeading__28116_946898870

Anchor
h.lnxbz9 h.lnxbz9

Group assignments

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.

Anchor
h.35nkun2 h.35nkun2

Overview of groups, customers and advisors

Anchor
__RefHeading__28118_946898870 __RefHeading__28118_946898870

Anchor
h.1ksv4uv h.1ksv4uv

is available at https://www.ntnu.no/wiki/display/tdt4290/

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.

...

Supervision and meetings

Your very first group

...

Your very first group-internal meeting is scheduled for the same day as the kick-off day. Each of you should introduce yourself to the others in the group, and try get the group organized for the first customer meeting the following hours. It is up to you!
Furthermore, your group should have a main advisor meeting with your advisor once a week, normally lasting one hour. Such meetings will have a group-specific content, but share a template agenda from Appendix A.7. All written documents for such meetings (agenda, weekly status report, phase-spesific documents etc.) must be delivered on paper or by email to the advisors before 14:00 the day before. In Appendix A – Project plan, you will find more information about such meetings.
Thus, during the first, pre-planned advisor meeting between your group and your advisor on Wednesday (see room/time in Appendix I), you will have to agree upon when and where the weekly advisor meetings shall take place for the rest of the semester. The group is responsible for booking a meeting room for these meetings (possibly helped by the advisor). During this hour, the advisor will also focus on the teamwork and group dynamics aspects and support you to establish a good group atmosphere.
Group rooms and room reservation You will probably need several weekly, internal group meetings. The groups have been allocated a group room once a week. For updated details see at https://www.ntnu.no/wiki/display/tdt4290/
If needed, you can book a room by contacting the reception at IDI on 735 93440.
It is also possible to book some rooms through the room reservation site "Romres" ({+}https://romres.ntnu.no/+). This reservation page is only accessible from users on the NTNU-intranet. ???
Anchorh.2jxsxqhh. 2jxsxqh
Customer meetings are held when needed, starting on the kick-off day (see rooms in Appendix I). The next customer meetings arranged in dialog with the customer, but the group is responsible for booking a room and other logistics. We recommend taking more contact with the customer, before the second advisor meeting in the following week.

Note: Before the first advisor, the group is collectively responsible for making a written resume of the first customer meeting held on the kick-off day. This resume should be sent by email to the persons involved (group members, advisor, customer) later on the same day. So take good notes of this first customer meeting!
Anchor__RefHeading__28122_946898870__RefHeading__28122_946898870 Anchorh.z337yah.z337ya

...

...

All material included in the final delivery (project documentation, prototype of the system, reflection report, final presentation) should be delivered to the 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.

Room: Rooms are reserved for the final presentation. If the project demonstration requires special facilities (such as 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.

...

/su/publ/ese/plagiarism.html.

Copyright or Intellectual Property Rights (IPR)

 

For the entire lifetime of this course, it has been "unclear", although rather frictionless, which "legal person" actually owned the IPR for the produced work, typically a project report and associated software. The Norwegian copyright law stands in LOV-1961-05-12-2 (http://www.lovdata.no/all/nl-19610512-002.html), and follows the Berne Convention for the Protection of Literary and Artistic Work from 1886.
Note: In Norway there is no need for a © symbol as in USA. Patents on software does not apply in Europe, but can be awarded in USA. Your employer owns the copyrights for software written as part of your employment contract (EØS rule).
IPR can be dealt with in four ways:

...

NTNU generally tries to coordinate its IPR policy with that of the University of Oslo from October 19, 2010: http://www.uio.no/for-ansatte/arbeidsstotte/fa/kontraktinngaaelse/ipr-politikk-191010.pdf, 16p. See also proposed extensions from the "Sejersted-II committee" at University of Oslo from May 20, 2011: http://www.hf.uio.no/imv/om/dok/2011/instituttstyret/SAK192011Høringsnotat[ |http://www.hf.uio.no/imv/om/dok/2011/instituttstyret/SAK192011Høringsnotat%20fra%20rektor.pdf]fra[ |http://www.hf.uio.no/imv/om/dok/2011/instituttstyret/SAK192011Høringsnotat%20fra%20rektor.pdf]rektor.pdf, 5p.
Check also what law professor Olav Torvund from University of Oslo has written in his interesting blog on IPRs and other issues: http://blogg.torvund.net/. See finally some overall comments from June 2008 by Reidar Conradi in: http://www.idi.ntnu.no/~conradi/IT-debate/ip-politikk-ntnu-26jun08.html, 6p.

...

Course reflection, evaluation and feedback

We intend to do a systematic evaluation of this project course. For this purpose, a "student reference group" must be established among the course participants. The course will be evaluated in the following ways:

...

The feedback received from the different parties will be used to improve the course for the future students.

...

.

...

Appendix A – The project plan

...

This section gives an example of how to structure a project plan. The project plan is a dynamic document that will evolve and change throughout the whole project. The project plan regulates the administrative part of the project and guides the project.
Depending on the type of lifecycle model you use you will have to structure the project plan differently.

...

...

A1.Overall project plan

Recommended content of the project plan ("project directive"):

...

• General terms. What are your limitations, tool selections, organizational demands from the customer, resources etc.?
• Based on the planned effort: How many person-hours are to be used?
• Schedule of results. When should deliverables be available as milestones or sprints/iterations?

 

...

• /iterations?

A2.Concrete project work plan

Recommended content:

• phases/sprints
• activities
• milestones
• person-hours per activity and phase + lectures + project management

...

Ideas to the content of the different phases are found in Appendix B. It is also recommended to look at previous project reports, which can be found at the web site of the course.

...

...

A3.Project organization

Recommended content:

• An organizational diagram of how the group is organized
• Roles, i.e., project leader, system analysis, system architect, system designer, test leader, customer contact, QA responsible, etc. Try to be inventive in role allocation!
• Responsibilities of the different roles
• Weekly schedule

...

...

A4.Templates and standards

The group should create templates for all relevant document types. Even though it will take some time to create these in the beginning, the group will benefit from these in two ways: 1) the layout will be correct when creating project documents and 2) reduction of irritation and stress within the group. Templates ought to be made for:

...

• organization of files
• naming of files
• coding style
• etc.

...

• .

...

A5.Version control procedures

The group must create a systematic procedure for version control for all textual documents, source code, etc., see Appendix D.4.2.3 on actual tools like CVS, SVN, Make etc.

...

A6.Documentation of project work

Internal project meetings
Try to have internal meetings at least once per week. In these meetings you should present the status, coordinate activities, divide tasks, and check the "mood" of the project. Set up an agenda and write precise minutes for each meeting.
Internal reports
A typical internal report:

...

Reporting of person-hours used should be done in written form to a specified time, e.g. as a part of the weekly reports.

...

reports.

A7.Quality Assurance (QA)

QA assumes that the relevant product qualities have been identified, so that the development process can be tailored to achieve these, e.g. reliability, performance, usefulness etc.
There exists an ISO-standard for this (ISO 9126). More information can be found on Wikipedia, see http://en.wikipedia.org/wiki/ISO_9126
Time of response
Make agreements with the customer. There should be time of response on:

...

The status report (see Section 4.1-4.5 above) should be handed in as a separate document.
Minutes of the weekly meeting with the advisors
Is attached to the next calling for meeting and is a fixed subject on the agenda.

...

...

A8.Test plan

The project has to have an overall test plan, which either can be part of the project plan or as a test document (the latter is recommended, see Appendix C6).

...

Appendix B – Suggestion for appendices in your project plan

...

 

...

...

B1. Partners

Owners, target audience, customer representative(s), project group, advisors. For each person, record:

• name
• address
• phone number
• e-mail
• etc.

...

B2. Concrete project plan

The current project plan and old project plans. By also keeping the old plans the group can see how they have evolved and also possible learn from previous experience.

...

they have evolved and also possible learn from previous experience.

...

B3. Detailed phase plans

A detailed description of what each phase consists of.
When ending a phase, the next phase is fine planned in detail. The detailed plans for each phase are put here and not in the end of last phase document.

Anchor
__RefHeading__28158_946898870 __RefHeading__28158_946898870

Anchor
h.28h4qwu h.28h4qwu

B4. Table for handling of risks

Project nn

L = Low, M = Medium, H = High

Anchor
__RefHeading__28160_946898870 __RefHeading__28160_946898870

Anchor
h.nmf14n h.nmf14n

B5. Table for effort registration

All projects needs to register the effort spent by each project participant on the different activities (e.g. Prestudy, Programming etc.) and in what period (week 1, week 2 etc.). This is needed to ensure that the project is on track according to the project plan. A weekly registration or periodization is common.
So each of you must weekly report - in a so-called time sheet – seven data items per relevant activity and period: project group no, person name, date of registration, period no, activity name or id, your effort spent and given in person-hours (possibly zero).
Make a template time-sheet for this information as soon as possible (a textual email-message format will do), and establish reporting procedures from the very project start. The reported effort data should be delivered ca. two days before the weekly advisor meeting. The project manager (or a delegated person) should be responsible to collect and synthesize the individual effort data into an updated project effort-matrix on a spread-sheet. The matrix data will be used to regularly monitor the planned (or estimated) effort vs. the actual one for the whole project. This matrix has time (period number) as the horizontal dimension, and activity as the vertical dimension. Each matrix cell contains a number measured in person-hours (ph).
So very early in the project, as part of making a Project Plan, you must break down the project's total available or estimated effort (ca. 1700 person-hours) into a dozen main activities or phases, which again are allocated to periods (week no 1-13), cf. Appendix A2. Naturally, activities belonging to the last part of the project cannot be broken down in detail in the start.
Thus the project plan must be adjusted over time.
Example: Assume that we have a software project with three estimated activities (A1-A3) over three time periods (T1-T3):

...

• 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

...

The source code should be commented and documented so well, that the customer easily can make modifications and build on your work after the project is finished.
At the end of your project, the source code and necessary resources should be included on the CD/DVD attached to the project report, supplemented  referenced  and supplemented with a Readme.txt file.
Code Review
Code Review, or Peer Code Review, is the act of consciously and systematically convening with one's fellow programmer to check each other's code for mistakes, and has been repeatly shown to accelerate and stramline the process of software development like few other practices can. There are some crucial insights about the code review from the book Best-Kept Secrets of Peer Code Review, which is about Cisco's peer-code review process condected by SmartBear team:

...

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  5-10 minutes

Total: 45 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:

...

1. User and installation guides (cf. external documentation?)
2. Technical/internal documents (cf. internal documentation?)
3. Other, e.g. special material provided by the customer.
4. Possible contracts and non-disclosure agreements.

 

Anchor
__RefHeading__28188_946898870 __RefHeading__28188_946898870

Anchor
h.43ky6rz h.43ky6rz

APPENDIX D – Administrative and Technical Resources

This chapter presents an overview over the resources available during the project work.

Anchor
__RefHeading__28190_946898870 __RefHeading__28190_946898870

Anchor
h.2iq8gzs h.2iq8gzs

D4.1Office Resources

 

 

Anchor
__RefHeading__28192_946898870 __RefHeading__28192_946898870

Anchor
h.xvir7l h.xvir7l

D4.2Technical Resources

 

Anchor
__RefHeading__28194_946898870 __RefHeading__28194_946898870

Anchor
h.3hv69ve h.3hv69ve

D4.2.1. Workstations

Fourth year computer science students have access to the 5th floor in the P15 building. Additionally IDI technical group offers virtual servers for all the groups to host/run any special software necessary that is not available on the normal servers available to students.
If technical problems occur or you have particular needs regarding the computers, contact the IDI technical group, drift<##>idi.ntnu.no

Anchor
__RefHeading__28196_946898870 __RefHeading__28196_946898870

Anchor
h.1x0gk37 h.1x0gk37

D4.2.2. Source Control Management

It is usually essential for groups to maintain some sort of source control management. We will not advise on a specific tool, but not that groups have had success with CVS, SVN, Git, Mercurial, Arch and Bazaar in the past.
It is worth to keep in mind that CVS and SVN both adopts a centralized repository design, a lot of developers are shifting towards distributed repositories due to weaknesses in a centralized design. Distributed alternatives to look at would be such as Git (and github), Mercurial, Arch and Bazaar (all open source).

Anchor
__RefHeading__28198_946898870 __RefHeading__28198_946898870

Anchor
h.4h042r0 h.4h042r0

D4.2.4. Use of collaboration technology in the project

The groups are encouraged to use some kind of collaboration technology (file sharing, defect registration etc.) to coordinate the different tasks among group the members. There exist several tools for this. The following is a list with some of the more well-known software packages for collaboration and information gathering:
Gathering of static information on the web:
Mediawiki: Open-source program for gathering static information on the web.
Example of use: wikipedia.org
Management software for defects etc:
Trac: Great for registration of defects, things to be done etc. Open-source.
Example of use: http://trac.edgewall.org/report
Sharing of files:
Microsoft Sharepoint: For sharing of files, documents etc. Commercial, but is available to NTNU students for free, under special licensing rules.
Example of use: http://office.microsoft.com/nb-no/sharepointserver/HA101672721044.aspx
Dropbox is another popular example, http://www.dropbox.com
Additionally Stud.ntnu.no offers group areas: http://www.stud.ntnu.no/kundesenter/
Appendix E – SCRUMP, Extreme Programming (XP) and Kanban board
Compared with the traditional projects development which usually is delivered in a series of phases, agile projects break down the development durations into releases and iterations. At the end of every releases and iterations, some small parts of the projects with functionality could be released. Figure 1 is the differences between traditional and agile methodologies.
The combination of SCRUM and XP is one of the most popular agile methodologies in use today. They complement each other well with tandem schedule.

Fig. 1. The basic workflow of Traditional development and agile development _https://www.inflectra.com/Methodologies/Scrum.aspx_
E1. SCRUM
SCRUM is an incremental and iterative framework for agile software development and project management. It contains sets of predefined roles and pracitices by breaking down development procedures into small pieces, separating features into manageable items of work which they tackle in time-boxed iterations called sprints. The mainly procedures include product backlog, sprint planning meeting, daily stand up, the sprint review and the sprint retrospective. Meanwhile, SCRUM teams comprise of three distinct roles - the product owner, the SCRUM master and development team members. The detailed information and steps will be described below.
E2. XP
XP focuses on customer satisfaction. It also maintains deviding development process into small iterations that a team could handle during a small period of time. Not like SCRUM, XP empowers the developers to confidently respond to changing customer requirements, even late in the life cycle. Teamwork is the key factor for XP process. Like SCRUM, XP teams also comprise of three roles – manager, customers and developers. They are all equal partners in a collaborative team, which could guarantee the effectiveness of development progress. In XP progress, there are five essential ways help to improve the project:
Communication: Everyone is part of the team, and should communicate face to face daily, or in our case every few days.
Simplicity: Promote the development progress from the most basic needs from the beginning. And maximize the value the team could get while mitigate failures as they happen. Keep the cost into reasonable value.
Feedback: Get feedbacks from tests and customers. Talk about the project and progresses to each other and then make any changes and adaptations when needed.
Respect: Give respect to each other with their efforts and ideas.
Courage: Often tell truth about progress and estimates. And have the courage to adapt changes whenever they happen.
Differences between SCRUM and XP:

...

E7. Other Agile Methodologies
If you don't satisfied with the combination of SCRUM, XP and Kanban, there are many other agile methodologies and you could always find the resouces you need online. Lean, Feature Driven Development (FDD), Crystal, Dynamic Systems Development Method (DSDM) etc.
A quick glance at these methods could see from https://www.versionone.com/agile-101/agile-methodologies/. You could choose one or some of them according to your need and requirements.

Anchor
__RefHeading__28200_946898870 __RefHeading__28200_946898870

Anchor
h.2w5ecyt h.2w5ecyt

Anchor
__RefHeading__28220_946898870 __RefHeading__28220_946898870

Anchor
h.48pi1tg h.48pi1tg

Appendix F – Use-case based effort estimation

Written for NTNU course TDT4290 Project-Driven Project.
by Bente C. D. Anda, UiO and adapted by Reidar Conradi, IDI in 2001-2011.
www.idi.ntnu.no/grupper/su/publ/reidar/tdt4290-usecase-estim-final-23aug11-rc.doc

Anchor
__RefHeading__28222_946898870 __RefHeading__28222_946898870

Anchor
h.2nusc19 h.2nusc19

F6.1. Introduction to use-case estimation

It is quite hard to get a useful (i.e. reliable) cost or effort estimate (measured in system size or work effort) to implement a set of high-level requirements, when almost no design decisions have been made. IBM et al. developed in the 1970s a Function Point (FP) method (http://www.functionpoint.com/) to convert ER- and flow-diagrams into Function Points (FPs), which can be converted into Lines-Of-Code (LOC), and then person-hours.
The FP method has recently been adapted for use-cases by Univ. of Linkøping (Karner 1993), Univ. of Oslo (Anda et al., 2001) and NTNU (Mohagheghi et al., 2005). Use-case based effort estimation aims to predict the implementation effort - in person-hours - of a requirements specification, given as a set of textually "upgraded" (also called "structured") use-case diagrams. Such an estimate covers all remaining design and programming work, plus unit and module testing.
Our industrial results have so far demonstrated satisfactory precision (+-20 %) for systems of moderate size, i.e. about 3000 person-hours or 20,000 Java-LOC.
We need your help: to try out and improve this estimation method, which only takes 30 minutes per "upgraded" use-case-diagram. The added text ("pseudo code") in the diagrams will anyhow be useful during remaining implementation work!

Anchor
h.1302m92 h.1302m92

Some background: other estimation methods include the Delphi approach, i.e. letting 3-5 "human experts" try to agree upon a common prediction - or simply use the median. There is also the Work Breakdown into Subsystems, which at least assumes a high-level design specification. Furthermore, estimates done by human experts often fares better than estimates built on formal models. Lastly, Prof. Magne Jørgensen at the Simula Research Laboratory outside Oslo claims that the industrial overrun of cost- or schedule estimates in software projects is about 30% - and has remained so for 30 years (Jørgensen 2005)!
Findings from the literature: An industrial software developer spends 40% of his time on Requirements and Design, 20% on Programming, and 40% on Testing and documentation. Given a work year of 1500 person-hours, he/she will annually produce 4 lines of C-code (C-LOC) per person-hour for mega-LOC systems. This means 6000 C-LOC or 3500 equivalent Java-LOC, or 60 Function Points per year per person. The number of defects "injected" by programmers in this software is about 4 per Function Point, or 40 defects per 1000 C-LOC, or 240 (6*40) defects totally per year. Of these defects, 204 (85 %) are pre-release ones, each costing 1-3 person-hours to correct. However, 36 (15%) of the defects will survive into the first release, and each will later cost 10-30 person-hours to correct (Jones 2007). This means that almost half the programming effort goes to defect correction!

Anchor
__RefHeading__28224_946898870 __RefHeading__28224_946898870

Anchor
h.3mzq4wv h.3mzq4wv

F6.2. More on the estimation method

The idea behind use-case based estimation is to add textual specifications, written in "pseudo-code", to document and thus upgrade the graphical actor and use-case models. This extra textual information is used to classify each upgraded actor and use-case model as either Simple, Average, or Complex - respectively with "cost points" 1, 2, 3 for actors and 10, 15, 20 cost points for use cases. From the aggregated and weighted cost points, a total effort estimate in real person-hours can be produced.
The estimation method takes only 30 minutes to perform, based upon upgraded use-case diagrams. The estimation method may also use a spreadsheet (www.idi.ntnu.no/grupper/su/publ/reidar/uc-ProjectEstimateMethod2011v2.xls), or you can do the conversion yourself with a pen and pencil in the same time.
You should later compare ("cross-check") the effort estimate against the person-hours actually consumed in the total design, programming and testing of each use-case, or accumulated for all the use-cases.

Anchor
__RefHeading__28226_946898870 __RefHeading__28226_946898870

Anchor
h.2250f4o h.2250f4o

F6.3. A mini-discussion

Challenges: How to achieve incremental maintenance - i.e., not only for the first release? How to handle reuse from 3^rd party software providers, such as Open Source Software (OSS) and Commercial-Off-The-shelves Software (COTS)? And how to scale up to larger systems: - student software has Productivity of 10-12, the smallish "office" systems in the Anda paper have a Productivity of 25-30, while the Ericsson telecom systems in the Mohagheghi paper have a Productivity of 60-70.

Anchor
__RefHeading__28228_946898870 __RefHeading__28228_946898870

Anchor
h.haapch h.haapch

F6.4. References

(Anda et al., 2001) Bente Anda, Hege[ |http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/d/Dreiem:Hege.html]Dreiem, Dag[ |http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/s/Sj=oslash=berg:Dag_I=K=.html]I. K. Sjøberg, and Magne[ |http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/j/J=oslash=rgensen:Magne.html]Jørgensen: "Estimating Software Development Effort Based on Use Cases-Experiences from Industry", In Martin Gogolla and Cris Kobryn (Eds.): Proc. _4th International Conference on The Unified Modeling Language, Modeling Languages, Concepts, and Tools (UML'2001), Toronto, Canada, Oct. 1-5, 2001, Springer Verlag Lecture Notes in Computer Science, Vol. 2185, ISBN 3-540-42667-1, pp. 487-502, DOI: http://dx.doi.org/10.1007/3-540-45441-1_3.
(Jones 1997) Capers Jones: Software Quality – Analysis and Guidelines for Success. 1997, Boston, MA: International Thomson Computer Press (a pearl of industrial data for mega-LOC systems).
(Jørgensen 2005) Magne Jørgensen: A review of studies on expert estimation of software development effort. Journal of Systems and Software 70(1-2): 37-60 (2005).
(Karner 1993) Gustav Karner: Metrics for Objectory. Diploma thesis, University of Linköping, Sweden. No. LiTHIDA-Ex-9344:21. December 1993.
(Mohagheghi et al., 2005) Parastoo[ |http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/m/Mohagheghi:Parastoo.html]Mohagheghi, Bente Anda, Reidar[ |http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/c/Conradi:Reidar.html]Conradi: "Effort estimation of use cases for incremental large-ware Development Effort Based on Use Cases-Experiences from Industry", In Gruia-Catalin Roman, William G. Griswold, and Bashar Nuseibeh (Eds.): Proc. 27th International Conference on Software Engineering (ICSE'2005), 15-21 May 2005, St. Louis, Missouri, USA, ACM Press, pp. 303-311, DOI: http://doi.acm.org/10.1145/1062455.10516.

Anchor
__RefHeading__28230_946898870 __RefHeading__28230_946898870

Anchor
h.319y80a h.319y80a

F6.5. Appendix: A small use-case diagram, with extra comments

A more detailed explanation of some points in the estimation method stands below

...

1. Apply the calculated effort estimate to either:
   1. Down-scale the requirements: Your group project will have a maximum budget of about 1800 person-hours, with perhaps 1/3 or 600 person-hours for implementation. Thus, your requirements must be trimmed to almost half. And this is definitely useful to know beforehand!
   2. Start implementing, record the actual effort – and compare with the estimate!

 

Anchor
__RefHeading__28232_946898870 __RefHeading__28232_946898870

Anchor
h.1gf8i83 h.1gf8i83

F6.6. Add-on to use-case example

Graphical use-case diagram, with text specification added for 3 Actors and one Use-case (**).

Anchor
h.40ew0vw h.40ew0vw

Example of added textual specification for actor A1.Clerk:

...

Anchor
__RefHeading__28234_946898870 __RefHeading__28234_946898870

Anchor
h.2fk6b3p h.2fk6b3p

Anchor
__RefHeading__28236_946898870 __RefHeading__28236_946898870

Anchor
__RefHeading__28238_946898870 __RefHeading__28238_946898870

Anchor
__RefHeading__28240_946898870 __RefHeading__28240_946898870

Anchor
__RefHeading__28242_946898870 __RefHeading__28242_946898870

Anchor
__RefHeading__28244_946898870 __RefHeading__28244_946898870

Anchor
__RefHeading__28246_946898870 __RefHeading__28246_946898870

Anchor
__RefHeading__28248_946898870 __RefHeading__28248_946898870

Anchor
__RefHeading__28250_946898870 __RefHeading__28250_946898870

Anchor
__RefHeading__28252_946898870 __RefHeading__28252_946898870

Anchor
__RefHeading__28254_946898870 __RefHeading__28254_946898870

Anchor
__RefHeading__28256_946898870 __RefHeading__28256_946898870

Anchor
__RefHeading__28262_946898870 __RefHeading__28262_946898870

Anchor
h.rjefff h.rjefff

Anchor
__RefHeading__28264_946898870 __RefHeading__28264_946898870

Anchor
h.3bj1y38 h.3bj1y38

Anchor
h.1qoc8b1 h.1qoc8b1

Appendix G – Software security

Written by Inger Anne Tøndel, PhD student IDI, Aug 2016.
Today, nearly all sectors of society depend on software systems to operate efficiently. As the dependence on software has grown, so have the threats towards these systems and the potential consequences of incidents in the systems. Though network security measures (such as firewalls and anti-virus software) can improve the security of the software systems, these only address the symptoms of the real problem: software that is crippled with vulnerabilities. Because of the general dependence on software systems, software security now needs to be taken into account for all software, not only for security-critical software.
The mantra in all information security work is that it should be risk based, so also for software security. It is way too costly (and probably impossible for complex systems) to aim for 100 % secure software, thus it is necessary to identify which part of the software is more critical regarding security, and which activities will be most efficient and effective in securing the software product.

Typical software security activities – the Touchpoints

Taking security into account for the system, means to build security into the system throughout the development process. One commonly referred approach for this is the seven touchpoints (see e.g. http://www.drdobbs.com/the-7-touchpoints-of-secure-software/184415391) that give an overview of seven activities that are in general recommended to do throughout development. These touchpoints are:

...

In this course the work on software security is expected to include some activities related to touchpoints 2, 5 and 6: Students are expected to identify key security requirements to their system and discuss the security implications of the functionality of the system and how attackers may go about attacking their systems, and they are expected to discuss security related to their architecture.

Software security games for analysing security risks and threats

Two techniques are used in this course, but students are only expected to use the technique they receive training on, that is only one of these techniques. In this section the two techniques are briefly described.

Protection Poker

Protection Poker is a security risk assessment technique for agile development teams proposed by professor Laurie Williams at NCSU.
In a risk analysis potential unwanted incidents in the system is identified (e.g. an attacker can get access to the database through some functionality and make changes) and one evaluates how likely this is and potential consequences. By doing this, one is able to gain an awareness of what are the main security issues of the product and make decisions on where to prioritise the security effort and what security mechanisms are needed
Protection Poker is played during every iteration planning meeting, and it is recommended that the full team (including developers, testers, product managers or business owners, project managers, usability engineers, security engineers, software security experts, and others) participates. One person should have the role as moderator, and this person will be responsible for leading the team through the game, and point the discussions in a good direction. One person should be responsible for making notes from the discussion, e.g. on potential issues, threats etc.
In one round of protection poker, the team plays about the features to be implemented in this iteration. The team starts with one feature and identifies the assets this feature touches upon. For assets that have not previously been assigned a value the team uses the protection poker cards and votes and discusses about the value until some reasonable agreement has been made. Afterwards the same thing is done for the exposure – to what extent the feature to be implemented makes it easier to attack the system. Full details on how to play Protection Poker can be found here: http://www.sintef.no/protection-poker.
After playing Protection Poker the team should have gained a common understanding of the security risks related to the features to be implemented in the iteration, and have the necessary foundation to make decisions on how much security and what type of security is needed.

Microsoft Elevation of Privilege (EoP)

Microsoft EoP is a game for threat modelling related to an architecture. Before playing the EoP game, there should be a sketch of the architecture in place, and it is beneficial if this sketch includes an overview of the flow of the information in the system. Then EoP is used to identify any security problems in this architecture.
EoP is played like many other card games, and looks much like an ordinary stack of cards except that there is different suits and that there are security hints on the cards. Players gain points, and the one that ends up with most points win. Points are made for winning rounds, but also for laying cards with hints that are considered to be potential issues in the system. These issues should be noted and looked into after the game. Details on how to play the Microsoft EoP game can be found here: https://www.microsoft.com/en-us/sdl/adopt/eop.aspx (see the related downloads part)

More on threats, vulnerabilities and what you can do about it

As input to playing Protection Poker and Microsoft EoP it is useful with an overview of some common threats, vulnerabilities and things to do about them. First a few things about terminology:

...

• For web-applications see the OWASP top 10 ( file:///C:/Users/ingat/Downloads/OWASP%20Top%2010%20-%202013%20(4).pdf)
• For a more general overview see the taxonomy of security errors known as the seven kingdoms (https://buildsecurityin.us-cert.gov/sites/default/files/bsi11-taxonomy_0.pdf).

 

Appendix H – Guest Lectures, meetings, presentations and rooms