...

Postal address: NO-7491 TRONDHEIM
Telephone: 73 59 34 40
Telefax: 73 59 44 66

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
3.7 Final presentation and demonstration on November 21
3.8 Anti-plagiarism
3.9 Copyright or Intellectual Property Rights (IPR)
3.10 Course reflection, evaluation and 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

...

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 course (http://www.idi.ntnu.no/emner/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. KarlsenPractical 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

...

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 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 quality of the project report and presentation delivered at the end of the course 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 project report and the presentation count towards the grade in an integrated way (they are not formally weighted against each other).
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 done.
• 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 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.

Anchor
__RefHeading__28120_946898870 __RefHeading__28120_946898870

Anchor
h.44sinio h.44sinio

Supervision and meetings

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

Anchor
h.2jxsxqh h.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

Anchor
h.z337ya h.z337ya

Anchor
__RefHeading__28124_946898870 __RefHeading__28124_946898870

Anchor
h.3j2qqm3 h.3j2qqm3

...

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

Final presentation and demonstration on November 23rd

...

All the attachments should be described in the final report as a .pdf-file, with relevant implementations enclosed (source code etc.). All this should be documented by a Readme.txt file.

Anchor
__RefHeading__28126_946898870 __RefHeading__28126_946898870

Anchor
h.1y810tw h.1y810tw

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.

Anchor
__RefHeading__28128_946898870 __RefHeading__28128_946898870

Anchor
h.4i7ojhp h.4i7ojhp

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.

Anchor
__RefHeading__28130_946898870 __RefHeading__28130_946898870

Anchor
h.2xcytpi h.2xcytpi

Course reflection, evaluation and feedback

...

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

• Project name
• Project sponsor (customer)
• Partners including responsible third party providers
• Background for the project: software system development
• Measurement of project effects, i.e. goals like:
• Reduce the time it takes to create a daily production report with 3 hours…
• 30% cost reduction of…
• 40% increase in sales…
• etc.

...

• 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?

 

Anchor
__RefHeading__28136_946898870 __RefHeading__28136_946898870

Anchor
h.qsh70q h.qsh70q

A2.Concrete project work plan

Recommended content:

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

...

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:

• Person-hours - used and remaining (according to plan)
• Activities - done and remaining
• Achieved and not achieved milestones. These are important progress indicators.

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

Anchor
__RefHeading__28146_946898870 __RefHeading__28146_946898870

Anchor
h.3fwokq0 h.3fwokq0

A7.Quality Assurance (QA)

...

Anchor
__RefHeading__28150_946898870 __RefHeading__28150_946898870

Anchor
h.4f1mdlm h.4f1mdlm

Appendix B – Suggestion for appendices in your project plan

 

Anchor
__RefHeading__28152_946898870 __RefHeading__28152_946898870

Anchor
h.2u6wntf h.2u6wntf

B1. Partners

...

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.

Anchor
__RefHeading__28156_946898870 __RefHeading__28156_946898870

Anchor
h.3tbugp1 h.3tbugp1

B3. Detailed phase plans

...

Anchor
__RefHeading__28158_946898870 __RefHeading__28158_946898870

Anchor
h.28h4qwu h.28h4qwu

B4. Table for handling of risks

Project nn

...

• Test descriptions (the operations that should be carried out)
• Data that will be tested (input and expected output)

 

When testing, you should perform the test after completing a phase/design/component etc. This is very close to the V-model used in software development. For more information about this, the Wikipedia article gives a good introduction (http://en.wikipedia.org/wiki/V-Model_( software, development )).
C10. Internal and external documentation
A user- and installation-guide for the final product must also be created. It should include an installation guide, which describe the installation process step by step.
Note, that your system and its installation will be tested by your advisor.
Hint: start on the documentation as soon as possible, as it describes the current state of the project for the project team.
C11. Evaluation
The groups decide themselves what to include in the project evaluation, but we recommend including the following elements:

1. The internal process and results: How have you worked together as a team? What have you done well? What have you not done so well? What would you have done differently? Conflicts that arose and how these were handled? Did you reach the project goals? What did you learn?
2. The customer and the project task: How was the communication with the customer? How did you experience the project assignment?
3. The advisors: How was communication with the advisors? Was the supervision good enough? How could the course be improved to next year?
4. Further work: Give an estimate for how much effort that is necessary to complete the product/project.
5. Suggestions for improvement. What is missing to make this course better for both students, customers and advisors.

...

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

...

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

...

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

...

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

...

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

1. Make first a well-structured, textual requirement specification, with requirements numbered e.g. as Ra-b.y (a,b:letters, y:digit). This is assumed made on beforehand.

 

1. Make a graphical use-case diagram in the usual way. That is, an actor is depicted as a "match-stick" figure, and a use-case as an "oval". Lines or arrows between these symbols show relations between the underlying entities.

 

1. Upgrade the graphical diagrams with textual specification for the actors and users. The actual use-case diagram has 10 use-cases and 3 actors (see example later). You must therefore make textual descriptions for totally 13 entities, see below.

 

1. For each participating actor, categorize him/her as easy, average, or complex:
2. A simple actor relates to a single system with a defined programming interface (API).
3. An average actor relates to either another system through a communication protocol, e.g. TCP / IP, or communicates to another actor via a textual interface.
4. A complex actor communicates via a graphical interface.
5. Count up the number of actors in each category.

Ex. Here, the 3 actors are all persons who shall communicate with the system through a graphical interface. Thus, we have 3 complex actors (all are complex, so we do not need textual actor descriptions to clarify this).

1. Similarly, for each use-case, categorize it as simple, average, or complex, depending on the number of major or alternative transactions in the event flow. A transaction is defined as an event, that occurs between an actor and a system:
2. A simple use-case has 3 or fewer transactions.
3. An average use-case has 4 to 7 transactions.
4. A complex use-case has 8 or more transactions.
5. Count up the number of use-cases in each category.

Ex. The use-case "Transfer application to another clerk" is one of 10 such, and is marked in the diagram with **. It contains totally10 transactions – 7 in normal event flow and 3 in its only variation flow (5a1-5a3). This use-case must therefore be categorized as complex. The other 9 use-cases are up to you to categorize. The spread-sheet has tentatively been filled up with 5 complex use-cases, 3 average and 2 simple.

1. A total of 21 (!!) context factors to express the effect of technical and environmental issues. These must be provided by you in the general case. In the spread-sheet, all these are just pre-set to 3, i.e. "neutral", giving an overall multiplicative context factor of 1. So just drop these!

 

1. Summing up: We first multiply the actor numbers (0,0,3) with "cost points" 1,2,3 for respectively Simple,Average,Complex actors, i.e. 1*0 + 2*0 + 3*3 - or totally 9 such points. We then multiply the use-case numbers (2,3,5) with cost points 5,10,15 for respectively Simple,Average,Complex use-cases, i.e. 5*2 + 10*3 + 15*5 or totally 115 points. The total is 9+115 = 124 so-called Use-case-Cost-Points (UCP). Congratulations, you are now done!! That is, only six "numbers" on actors and use-cases must be provided by you!
2. Productivity per UCP: At last, a Productivity factor must be multiplied with UCP above to get an effort estimate in person-hours. With a Productivity of 10, we will get 10*124 = ca. 1250 person-hours!!

 

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

...

Example of added textual specification for actor A3.Customer:

Example of added textual specification for a simple use-case:

Comments on the description of event flow:

• The event flow shall be described as a list of transactions on the form:

...

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:

1. Static analysis tools – to automatically identify security bugs in the code
2. Risk analysis at the design and architecture level
3. Penetration testing
4. Risk-based security tests
5. Abuse cases – to get into the mind of potential attackers
6. Security requirements
7. Security operations

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

...

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

...

These are explained here: https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx
Information on common vulnerabilities and how to mitigate them (what countermeasures to use) can be found at the following resources:

• 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

Introduction: Tuesday 23/8 12-16
Meetings with supervisors: Wednesday 24/8-16 15.15 – 17.00