Project introduction

Project outline
This document outlines the project plan for Software House 2s, Software engineering project. The aim of this project is to design a renderer for simple HTML files. The renderer itself will be able to read and translate a HTML file into a format appropriate for a screen. The system should be built in agreement with the initial customer requirements - as well as any additional requirements discussed and agreed upon at the customer meeting. We will go about tackling the project by dividing our software house into smaller groups of 2-3 members. Each section team will have particular responsibilities with regard to; analysis, design, implementation and quality assurance in order to see the project is completed successfully and within the time-limits set. This project will be carried out according to the guidelines of the Software Engineering quality manual. Project schedule The project has four main milestones. By 4pm Monday of Week 7, the following documents should be delivered to the customer:

The Project Plan.

By 4pm Monday of Week 10, the following documents should be delivered to the customer:

The Requirements specification, The Acceptance criteria, and The High-level design specification.

By 4pm Monday of Week 3, the following documents should be delivered to the customer:

The Detailed design specification.

By 4pm Thursday of Week 8, the following documents should be delivered to the customer:

The Source code, The Test specification, The User documentation.

Phase plan
Project phases Planning Tasks: Organise software house in section teams Establish overall project outline Establish major milestones Responsibility: These 3 tasks will be the responsibility of the entire team as a whole Identify roles within section teams Identify phases within sections Identify tasks within phases Responsibility: These 3 tasks will be the responsibility of each section team

Requirements analysis Milestones: The Requirements Analysis Phase has 7 major milestones: Establish requirements with customer Complete scenario based analysis by Thurs, week 5 Complete acceptance criteria by Wednesday, week 6 Complete class based analysis by Wednesday, week 6 Complete behaviour based analysis, by Wednesday, week 6 Complete flow based analysis, by Wednesday, week 7 Compile deliverable requirements specification by Thursday, week 7 Tasks: Establish requirements with customer Discuss requirements with customer at customer meeting Responsibility: This will be carried out by the entire analysis team and possibly members of other sections of the house, to ensure they each have a good understanding of what is to be expected of the system. Complete scenario based analysis Identify actors Create use-cases Create activity diagrams Create swim lane diagrams Responsibility: This will be carried out by the entire analysis team in order to incorporate different ideas into the system and achieve a wider scope. We will then compile our ideas and decide upon a particular direction to go in. In doing this, we will all be working with the same use-cases in mind when designing other diagrams. Complete Acceptance criteria Formalise requirements Responsibility: Matthew Kavanagh o Identify testable criteria Responsibility: Tristan Morrison o Create test procedures

Responsibility: Angus McAlpine

Complete class based analysis Identify classes Design class diagrams Responsibility: This will be done as a team, to ensure that we each have a good understanding of what the classes are, which will in turn allow us to create the remaining diagrams individually Create CRC cards Responsibility: Stefan Pearson Create collaboration diagrams Responsibility: Danielle Hamilton Complete behaviour based analysis Create State diagrams Responsibility: Kyle Truswell Create Sequence diagrams Responsibility: Danielle Hamilton Complete flow based analysis Create data flow diagrams Responsibility: Stefan Pearson Create control flow diagrams Responsibility: Kyle Truswell Write processing narrative Responsibility: Danielle Hamilton Complete Requirements specification Compile and explain diagrams Responsibility: Entire team

Design Milestones The Design stage has 2 major milestones: Complete High-level design specification Create Low-level design specification Complete Test specification Complete Manual page Tasks Complete High-level design specification Complete architectural design Responsibility: Entire team Complete common tactical policies Responsibility: Robert Stanley Complete requirements cross reference Responsibility: Jairo Kasmierchcki Complete Low-level design specification Responsibility: Entire team Complete detailed design Responsibility: Entire team Complete test specification o Define Scope

Responsibility: Angus McAlpine o Create Test plan Responsibility: Tristan Morrison o Establish Test procedures Responsibility: Matthew Kavanagh

Complete Manual page Responsibility: Jairo Kasmierchcki Coding Milestones The Coding stage has 2 major milestones: Create the structure of the program Create the content of the program Tasks Establish interface between classes Create the groups of classes separately

Responsibility: Entire team Each person in the team will write the code for one group of classes (assuming there are three groups of classes) or what works out to be roughly 33% of the classes. Use groups of classes together as one program

Responsibility: Entire team Each person's group(s) of classes will be combined to create one program.

Testing Milestones The Testing stage has 1 major milestone: Carry out test specification Tasks Carry out test specification o Carry out test procedures from acceptance criteria Responsibility: Matthew Kavanagh o Carry out test procedures from test specification Responsibility: All Quality Assurance team members, subdivided along logical lines. Delivery Milestones The Delivery stage has 2 major milestones: Create the installation guide Create the user guide Responsibilities: Entire team The user guide and installation guide will be written by the entire team. At a later date, specific parts of the writing process may be assigned to individual members.

HTML Renderer 1. Requirements Analysis 1.1 Establish 1.2 Complete Scenario analysis 2. Design 3. Coding 4. Testing

5. Delivery

2.1 High level design 2.1.1 Architectural Design

3.1 Structure of 3.2 Content of

4.1 Perform Tests

5.1 User guide 5.2 Installation guide

1.2.1 Draw Use case diagrams 1.2.2 Create Activity diagrams 1.2.3 Create Swim lanes 1.3 Acceptance 1.4 Complete Class 1.4.1 Define Class diagrams 1.4.2 Create CRC cards 1.4.3 Create collaboration 1.5 Complete Behaviour analysis 1.5.1 Create State diagrams 1.5.2 Create Sequence 1.6 Complete Flow 1.6.1 Create Data flow 1.6.2 Create Control flow diagram

2.1.2 Common tactical 2.1.3 Requirements cross2.2 Low level design 2.3 Test Specification 2.3.1 Architectural Design 2.3.2 Architectural Design 2.3.3 Architectural Design 2.4 Manual Page

This is the Work Breakdown Structure for the project. It shows how the tasks are broken down into tasks throughout the phases of the project: Analysis Design Coding Testing Delivery

1.6.3 Write Processing narrative

Milestone and task list Analysis Establish customer requirements Complete Scenario based analysis Create Use-Cases Create Activity diagrams Create Swim Lane diagrams Create Acceptance criteria Formalise requirements Identify testable criteria Create test procedures Complete Class based analysis Identify Classes Create Class diagrams Create CRC cards Create Collaboration diagrams Complete Behaviour based analysis Create Sequence diagrams Create State diagrams Complete Flow based analysis Create Data flow diagrams Create Control flow diagrams Write processing narrative Complete Analysis Design High-level design Architectural design Requirements cross-reference Common tactical policy Low-level design Class/Object diagrams Activity diagrams Diagram Integration Test specification Manual Page Complete Design Programming Create structure of program Create content of program Complete programming Testing Perform testing Complete Testing

Delivery Create User guide Create Installation guide Audit all documentation Complete Project

Organization plan
Staff organization

The review manager is Oliver Winks. The project manager is Danielle Hamilton (dch22@sussex.ac.uk) Analysis team The analysis team consists of:

Danielle Hamilton (dch22@sussex.ac.uk) manager Kyle Truswell (kt79@sussex.ac.uk) Stefan Pearson (sp233@sussex.ac.uk)

Design team The design team consists of:

Robert Stanley (rjs30@sussex.ac.uk) manager Jairo Kasmierchcki (jk216@sussex.ac.uk)

Programming team The programming team consists of:

Nathan Scully (ns214@sussex.ac.uk) manager James Johnstone (jpj21@sussex.ac.uk) Tudor Pascu (tp60@sussex.ac.uk)

Quality assurance team The quality assurance (QA) team consists of:

Matthew Kavanagh (mck22@sussex.ac.uk) manager Tristian Morrison (tm89@sussex.ac.uk) Angus Mcalpine(am376@sussex.ac.uk)

File space We have decided to use Google Code for our project hosting for a number of different reasons. The file space offered by the University would have sufficed, but Google Code has more useful features. For example, with Google Code, you can use SVN to automatically get the latest version of the code straight to your computer. You also get a group of Wiki pages which are a good way of everybody collaborating information together, because if somebody writes a page, anybody can edit anything, and a full history is kept too. Most of the members of the team had Google accounts already, and those who didn't have acquired them. The source code when uploaded to Google Code is well organised, and like the Wiki it shows a full version history and includes tools to easily compare and contrast different versions of the code. There is another interesting tool, called "Issues". It enables anybody to submit a bug report about the code, and the bug can be tracked so that it can be properly corrected. This will be very useful as a tool for collaboration between the programmers and the quality assurance team. Google Code also offers a sufficient amount of file space (2GB), and because it is Google, chances are it will be reliable and fast. We have also agreed that as a standard, all documents uploaded to the file space will be in the format of .doc, in order to avoid compatibility issues with different versions of Microsoft Word. However, we will use the Wiki in order to work on the same document together, until it is finalised and uploaded in a Word document. By using the Wiki, we will be able to track different versions of deliverables, which team member made changes and when.

Analysis team responsibilities Planning phase Identify section milestones, phases and tasks Decide upon roles of team members Analysis phase Discuss customer requirements at customer meeting Complete deliverable requirements specification Design phase Liaise with design team to ensure the design reflects the analysis Coding phase N/A Testing phase N/A Delivery phase Use the system built in order to get a good idea of how it works Create the deliverable user guide, which includes; an installation guide, user guide and Unix man page

Design team responsibilities

Planning phase As for Analysis team Analysis phase Design phase Complete deliverable high level design specification Complete deliverable low level design specification Coding phase Liaise with programming team to ensure the code reflects the design Testing phase N/A Delivery phase N/A

Programming team responsibilities

Planning phase As for Analysis team Analysis phase N/A Design phase Liaise with Design team, in order to give technical opinion in the event of any design complications Coding phase Produce the code Testing phase Liaise with the Quality Assurance team, in the event that problems are found with the system Delivery phase Liaise with Analysis team by being available to answer queries, which will in turn help them to write the user manual

Quality assurance team responsibilities Planning phase As for Analysis team Analysis phase Create the acceptance criteria Design phase Create the test specification Coding phase N/A Testing phase Carry out test plan on system Delivery phase Audit all documents produced and convert to html