Prosjektplan for INF 3120-prosjekt: <navn på prosjekt>
INF3120: Originalen til denne malen er hentet fra www.construx.com. Vi har tilpasset malen til prosjektoppgaven i INF3120 ved å:
•	Fjerne deler som ikke er så viktige for små prosjekter
•	Konkretisere deler av innholdet
•	Legge føringer på hvordan deler av planen skal utformes.
Den engelske teksten er beholdt, men det vil trolig være hensiktsmessig for dere å skrive planen på norsk.

Tips: 
1)	Les HELE malen før dere begynner å skrive.
2)	Det er mange punkter og det er viktig å holde innholdet knapt og konsist. Det teller negativt at en prosjektplan er lenger enn nødvendig, dvs inneholder tekst som ikke har noen betydning for gjennomføringen av prosjektet eller er et SKAL-krav.
Kriteriene vi bruker for å evaluere leveranser der plan og estimater inngår er i hovedsak:
1)	Hvor godt planen egner seg som styringsinstrument, dvs i hvilken grad de tingene som er viktig for styringen (SKAL-kravene) bidrar til at prosjektet blir effektivt gjennomført. Dette vil vi evaluere både ved å se på planen, men også på selve gjennomføringen – f eks om godkjent leveranse leveres på tid.
2)	Om alle SKAL-kravene er oppfylt.
3)	I hvilken grad planen viser at pensum om prosjektplanlegging og styring er forstått og brukt.

This document outline is based on the IEEE Standard 1058.1-1987 for Software Project Management Plans. 
This is the controlling document for managing a software project, and it defines the technical and managerial processes necessary to deliver the project requirements. 
The paragraphs written in the “Comment” style are for the benefit of the person writing the document and should be removed before the document is finalized. 
Version: Draft
1 September, 2006
[Authors]
sdp.doc
Revision Chart
INF3120: Ferdig prosjektplan og revidert prosjektplan SKAL legges på prosjektets hjemmeside.
Dere bestemmer selv prosessen fram mot ferdig prosjektplan, men det kan være lurt å bestemme en dato for når “inspiserbar” plan skal være ferdig, dvs når planen skal sendes til kommentering til de andre (helst alle) i gruppa og når oppdragsgiver skal kunne gi kommentarer. Dette tidspunktet bør være slik at dere rekker å ta hensyn til kommentarene fra gruppedeltakerne.

PS: Forkortelsen “TBD” står for “To Be Decided”.

This chart contains a history of this document’s revisions. The entries below are provided solely for purposes of illustration. Entries should be deleted until the revision they refer to has actually been created. 
The document itself should be stored in revision control, and a brief description of each version should be entered in the revision control system. That brief description can be repeated in this section. Revisions do not need to be described elsewhere in the document except inasmuch as they explain the development plan itself. 
Version	Primary Author(s)	Description of Version	Date Completed	
Draft	TBD	Initial draft created for distribution and review comments	TBD	
Preliminary	TBD	Second draft incorporating initial review comments, distributed for final review	TBD	
Final	TBD	First complete draft, which is placed under change control	TBD	
Revision 1	TBD	Revised draft, revised according to the change control process and maintained under change control	TBD	
Revision 2	TBD	Revised draft, revised according to the change control process and maintained under change control	TBD	
etc.	TBD	TBD	TBD	

Preface
The preface contains an introduction to the document. It is optional and can be deleted if desired. 
Contents
New paragraphs formatted as Heading 1, Heading 2, and Heading 3 will be added to the table automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the table to be easy to maintain, do not change it manually.
1. Introduction	
1.1 Project Overview	
1.2 Project Deliverables	
1.3 Evolution of the Software Project Management Plan	
1.4 Reference Materials	
1.5 Definitions and Acronyms	
2. Project Organization	
2.1 Process Model	
2.2 Organizational Structure	
2.3 Organizational Boundaries and Interfaces	
2.4 Project Responsibilities	
3. Managerial Process	
3.1 Management Objectives and Priorities	
3.2 Assumptions, Dependencies, and Constraints	
3.3 Risk Management	
3.4 Monitoring and Controlling Mechanisms	
3.5 Staffing Plan	
4. Technical Process	
4.1 Methods, Tools, and Techniques	
4.2 Software Documentation	
4.3 Project Support Functions	
5. Work Packages, Schedule, and Budget	
6. Additional Components	
7. Index	
8. Appendices	

List of Figures
New figures that are given captions using the Caption paragraph style will be added to the table automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the table to be easy to maintain, do not change it manually.
This section can be deleted if the document contains no figures or if otherwise desired. 
Error! No table of figures entries found.
1.	Introduction 
INF3120-tips: Selv om Innledningen kommer først er det ikke alltid lurt å begynne med å skrive denne. Deler av innledningen bør vente til det meste av det andre er skrevet. Mye av innledningen bør tas fra oppdragsgivers uformelle kravspesifikasjon.

This section should describe the project and the software product being to be built. No text is necessary between the heading above and the heading below unless otherwise desired. 
1.1	Project Overview
Give a short summary of the project objectives, the software to be delivered, major activities, major deliverables, major milestones, required resources, and top-level schedule and budget. Describe the relationship of this project to other projects, if appropriate. 
1.2	Project Deliverables
List all of the major items to be delivered to the customer (external customer, in-house user, etc.). 
List the deliverables, delivery dates, delivery locations, delivery method (email, FTP, CD, etc.), and quantities necessary to satisfy the project’s requirements. 
1.3	Evolution of the Software Project Management Plan
Describe how you expect this document to evolve over time. This section should be very similar to the “Revision Chart” earlier in the document. The revision chart should list what has already been done to this document. This section should list what is expected to be done to this document. 
This chart contains a plan for the document’s revisions. The entries below are provided for purposes of illustration. The progression from “Draft” to “Preliminary” to “Final” and then through a section of “Revisions” is one typical approach. 
Version	Primary Author(s)	Description of Version	Date Expected	
Draft	TBD	Initial draft created for distribution and review comments	TBD	
Preliminary	TBD	Second draft incorporating initial review comments, distributed for final review	TBD	
Final	TBD	First complete draft, which is placed under change control	TBD	
Revision 1	TBD	Revised draft, revised according to the change control process and maintained under change control	TBD	
etc.	TBD	TBD	TBD	
1.4	Reference Materials
List all the documents and other materials referenced in this document. This section is like the bibliography in a published book. 
1.5	Definitions and Acronyms
Provide definitions or references to all the definitions of the special terms and acronyms used within this document. 
2.	Project Organization
In this section, describe the process model (e.g., lifecycle model), the organizational structure (e.g., chain of command or management reporting structure), and responsibilities of individuals on the project. 
No text is necessary between the heading above and the heading below unless otherwise desired. 
2.1	Process Model
INF3120: Her SKAL prosessmodell beskrives. (Den mer detaljerte aktivitetsbeskrivelsen gis i Kapittel 5.)

Describe the following items:
•	The project’s lifecycle model (e.g., waterfall model, spiral model, evolutionary prototyping model, etc.)
2.2	Organizational Structure
INF3120: Kun nødvendig dersom dere synes det er nyttig.
Describe the internal management structure of the project. Use org charts, matrix diagrams, or other appropriate notations to describe the lines of authority, responsibility, and communication within the project. 
2.3	Organizational Boundaries and Interfaces
INF3120: Kun nødvendig dersom dere synes det er nyttig
Describe the relationships between the project and each of the following organizations:
•	Parent organization (upper management)
•	Customer organization (internal or external)
•	Subcontracting organization(s) (if any)
•	QA organization, if separate
•	Documentation organization, if separate
•	End-user support organization, if separate
•	Any other organizations the project interacts with
This list should include a description of a specific person or project role that is responsible for maintaining the interface between the project and each of these other organizations. 
Be sure to identify the person who has ultimate decision-making authority over the project. 
2.4	Project Responsibilities
INF3120: Denne SKAL dere ha med. Angi hvem som er hovedansvarlig for hver hovedaktivitet og pass på at dette samsvarer med den mer detaljerte aktivitetsbeskrivelsen i kap. 5.
Identify and describe each major project function  and activity, and identify the person(s) responsible for each function and activity. You might use a table like the one below:
Responsibility	Persons responsible	
Overall Project Manager	TBD	
Engineering Manager	TBD	
Quality Assurance Manager	TBD	
End-User Documentation Manager	TBD	
Requirements Development	TBD	
Software Architecture	TBD	
Technical Self-Reviews	TBD	
Etc.	TBD	

3.	Managerial Process
Describe management objectives, priorities, project assumptions, dependencies, constraints, risk management techniques, monitoring and controlling mechanisms, and the staffing plan. 
No text is necessary between the heading above and the heading below unless otherwise desired. 
3.1	Management Objectives and Priorities
INF3120: Kun nødvendig dersom dere synes det er nyttig
Describe the philosophy, goals, and priorities for management during the project. Consider including the following items: 
•	kind of status reporting
•	relative priorities among functionality, schedule, and budget
•	risk management procedures
•	approach to acquiring third party software
•	approach to modifying or using existing software
3.2	Assumptions, Dependencies, and Constraints
INF3120: Kun nødvendig dersom dere synes det er nyttig. 
Describe the assumptions upon which the project plans are based, the dependencies of the project plans, and the constraints upon the project plans (e.g., schedule, budget, quality, functionality, etc.) 
3.3	Risk Management
INF3120: Denne SKAL være med i form av en “Top 10 Risk list” og tiltak for å møte risiko. Angi både sannsynlighet og alvorlighet av risikofaktor, f eks på skalaen: lav, middels, høy. Midt og sluttrapporter skal rapportere hvordan risiko utvikler/utviklet seg, f eks som vist på figuren.

Figuren viser at risikofaktor R1 i starten av prosjektet var vurdert til middels sannsynlig og middels alvorlighet. I løpet av perioden har både sannsynlighet og alvorlighet blitt mindre, f eks som følge av risikohåndteringstiltak.

Describe the major risks to the project, which the project plan has been designed to address. Describe how risks will be tracked and monitored—using a Top 10 Risks list, risk officer, or so on.
3.4	Monitoring and Controlling Mechanisms
INF3120: Denne SKAL være med. Dere skal registrere timer underveis (per aktivitet) og ha en midt- og en sluttrapport, samt at prosjektet skal ha en hjemmeside. Registreringen av timer skal følge samme struktur som planleggingen – for å kunne brukes i erfaringsrapporten (leveranse IV). Gi en KORT beskrivelse av dette.

Describe how project cost, schedule, quality, and functionality will be tracked throughout the project. Consider describing the following:
•	Report contents/formats
•	Reporting structure and frequency
•	Audit mechanisms
•	Project website
•	Time accounting
3.5	Staffing Plan
INF3120: Kun nødvendig dersom dere synes det er nyttig.
Describe the numbers and types of personnel needed to conduct the project. Describe the required skill levels, start times, duration on the project, method of obtaining the personnel, training required, and phasing out of project personnel. 
4.	Technical Process
This section describes the top-level technical processes used on the project including the technical methods, tools, and techniques; major software documents; and supporting activities such as configuration management and quality assurance. 
No text is necessary between the heading above and the heading below unless otherwise desired. 
4.1	Methods, Tools, and Techniques
INF3120: Alle punktene nedenfor SKAL være med (men gjør det kortfattet).
Tips: I mange tilfeller holder det å referere til en ekstern beskrivelse (f eks av retningslinjer som er beskrevet andre steder eller til en design-metode) og eventuelt beskrive tilpasninger som er gjort.

Describe the following:
•	Software tools including design tools, source code control, time accounting, compiler or IDE, debugging aids, defect tracking, and so on
•	Development methodologies including requirements development practices, design methodologies and notations, programming language, coding standards, documentation standards, system integration procedure, and so on (these will not all be defined when the first draft of the project plan is created; the section should be updated as the plans become more detailed)
•	Quality assurance practices including methods of technical peer review, unit testing, stepping through code in a debugger, system testing, automated regression tests, and so on
4.2	Software Documentation
INF3120:Ta med dersom dere finner det hensiktsmessig.

4.3	Project Support Functions
INF3120: Det SKAL gis en kort beskrivelse av hvordan konfigurasjonsstyring og kvalitetssikring er planlagt gjennomført. Det som er beskrevet i 4.1 skal ikke gjentas her.

Describe or give references to other documents that describe the plans for functions that support the software development effort, including configuration management, quality assurance, and end user documentation. Whether included in this document or described elsewhere, the plans for these supporting functions should be developed in as much detail as the plans for the software itself are. (This includes responsibilities, resource requirements, schedule, budget, and so on.)
5.	Work Packages, Schedule, and Budget
INF3120: Beskrivelsene i dette kapitlet SKAL gjøres vha:
1)	Nedbryting av prosjektet i del-aktiviteter (WBS) (se regneark).
2)	Estimering av ressursforbruk til hver delaktivitet (se regneark)
3)	Angivelse av minimum og maximum med tilhørende sannsynligheter (se regneark)
4)	Gantt-diagram over aktiviteter og leveranser som er tilpasset tidsfrister (NB: legg inn noe risikobuffer, f eks 25% av mest sannsynlig arbeidsmengde!).
5)	Tilordning av aktiviteter til personer, helst slik at det blir rimelig lik belastning mhp ressursforbruk.

NB: Til aktivitet 2) og 3) kan dere sjekke om estimatene ”matcher” minimum og maksimums-verdiene deres ved å bruke et verktøy som kan lastes ned fra: http://www.eptacom.net/betterestimate/. Dersom det er vesentlige avvik mellom de estimatene som ”BetterEstimate” genererer og de som dere har oppført som ”mest sannsynlig” bør dere gå en ekstra runde.
6.	Additional Components
INF3120: Kun nødvendig dersom dere synes det er nyttig
Include additional components needed to manage your specific project. Possibilities include subcontractor management plans, security plans, training plans, hardware procurement plans, facilities plans, installation plans, cutover plans, and software maintenance plans. 
7.	Index
INF3120: Kun nødvendig dersom dere synes det er nyttig
The index is optional according to the IEEE standard. If the document is made available in electronic form, readers can search for terms electronically.  
8.	Appendices
INF3120: Kun nødvendig dersom dere synes det er nyttig
Include supporting detail that would be too distracting to include in the main body of the document.