Guidebook BCIS 2 2011 v2.6

7/31/2019 Guidebook BCIS 2 2011 v2.6

1/58

Research & Development Project Student Guidebook

School of Computing & MathematicalSciences

Bachelor of Computer & Information Sciences

Research & Development

Project

(407003, 407008, 407009,407010)

Student Guidebook

7/31/2019 Guidebook BCIS 2 2011 v2.6

2/58


Table of Contents

Section 1 Conduct of Research & Development Projects

1.1 Aim

1.2 Nature of Projects

1.3 Selection of a Project

1.4 Project ProposalWork Integrated Project Learning Agreement

1.5 Project Planning and Control

1.6 Completion Date

1.7 Assessment Overview

1.8 Responsibilities of Project Supervisors

Section 2 Research & Development Projects - Activities andOutcomes

2.1 Introduction

2.2 Nature of Projects and Deliverables

2.3 Assessment Points

2.3.1 Project Proposal or Learning Agreement

2.3.2 Final Poster Presentation

2.3.3 Reflective Report and Project Review

2.3.4 Evidence of Project Planning and Control

2.3.5 Evidence of Teamwork and Communication with Stakeholders

2.3.6 Relationship with the Sponsor/Client

2.3.7 Rationale for Project Decisions

2.3.8 Development Activities and Outputs

2.3.9 Quality Assurance Activities and Outcomes

2.3.10 Implementation Activities and Outcomes

2.4 Bibliography and Selected References

7/31/2019 Guidebook BCIS 2 2011 v2.6

3/58


Research & Development Projects - Assessment

Appendix A - Project Documentation Guidelines

Appendix B Project Assessment Form

Appendix C Project Proposals Marking Schedule

Supplementary Appendix C Learning Agreement Assessment Criteria

Appendix D Project Progress Review Form

Appendix E Reflective Report Assessment Form

Appendix F Project Portfolio Contents Guide

Appendix G Assessment Criteria for Project Poster Presentation

Appendix H Individual Student Client Feedback Form

Appendix I Standard Disclaimer

Appendix J BCIS Project at a glance (indicative timeline)

Acknowledgements: This booklet has been collated from a number of sources, discussions and contributors, andbased upon my own experiences and the work of many practicing project supervisors, software developers, curriculum

developers, researchers and students. Particular recognition must be given to Chris Manford of AUT for his PJ300

Project Student Notes which have been used successfully over many years and extended to form a basis for this

guidebook. Likewise the work of the NACCQ in developing the curriculum for the project course within the National

Diploma in Business Computing must be acknowledged. The insights of Dr Noel Bridgeman in describing the

transition from the Diploma (PJ300) format of the project to the degree version in the Bachelor of Applied Information

Systems at Taranaki Polytechnic have been drawn upon. Noel has written and presented on the topic at NACCQ

national conferences and in the New Zealand Journal of Applied Computing and IT. The Handbook on IS301 Project

selection, Supervision and Assessment, Version 3.3, (Bridgeman N., 1995) has also been consulted in the course ofdeveloping this guide, as have John Robertsons generic notes as paper coordinator for the project course in AUTs

Bachelor of Applied Science degree. Some of the assessment materials are also based upon those used in the Bachelor

of Business Cooperative Education paper. Gordon Grimsey has also given helpful feedback upon the first version of

this guide produced for the Bachelor of Applied Science degree. Insights have also been gained from colleagues in the

ITiCSE 2001 working group at the University of Canterbury at Kent which resulted in the report Clear, Young et al.

(2001)Resources for Instructors of Capstone Courses in Computing SIGCSE Bulletin 33;4 ACM New York pp 93-

7/31/2019 Guidebook BCIS 2 2011 v2.6

4/58


SECTION ONE - CONDUCT OF RESEARCH &

DEVELOPMENT PROJECTS

1.1. Aim

Within the Bachelor of Computer & Information Sciences Degree the Project course (407003, 407008, 407009, 407010) is

described generically in the following terms:

An investigation into a selected area whether that be a specific problem domain, or an area of business

opportunity. The project is typically an original investigation but considerable flexibility is allowed. Typically

projects will involve either commercial software development for live clients, commercial research anddevelopment projects on behalf of live clients, or supervised research projects into selected areas of interest.

By the end of this paper through completion of a significant Research & Development Project students will be able to:

show the ability to successfully undertake original work

demonstrate a professional attitude demonstrate the ability to integrate the different disciplines required

communicate effectively with clients and sponsors communicate effectively in both written work and in group situations

effectively manage, monitor and control the activities involved in a development project

determine an appropriate process and accompanying set of deliverables for their project

show the ability to document appropriately the deliverables for their project - software specifications,project plans, source code, technical reports, white papers, literature reviews, academic articles for

publication etc.

select and justify an appropriate methodology for their project

The project aims at bringing together what you've been taught from many other courses that you have studied so far. Thesemay include such subjects as data and process modelling, database, systems administration, software design and

implementation, software engineering and quality assurance, project management, programming, algorithm design, needs

analysis, human computer interaction, IT operations service and support, or network security. These notes are intended to

help you throughout all stages of the project.

1.2. Nature of Projects

While it is intended that as much flexibility as possible be afforded to students taking the course, it is envisaged that

projects might fall into one of the following broad categories:

1. Sponsored software research and development project, which might involve investigating, evaluating,developing a proof of concept application and recommending a software solution to a given problem for an

organization or commercial client.

2. Sponsored research and development project, which might involve investigating, evaluating, modifying,configuring and installing a proof of concept application and recommending through to installing and

7/31/2019 Guidebook BCIS 2 2011 v2.6

5/58


While the deliverables for each of the above models may differ, and the time and scope of the project might dictate thatnot all phases of larger projects can be completed, it is intended that a graduate of the Bachelor of Computer &

Information Sciences be equipped with a broad set of capabilities that will equip them for work as an IT professional,

or for further study and potential research careers. Therefore each project will involve the production of professionallydesigned, documented and tested software or other artefacts and professional quality documentation and supporting

models or prototypes relevant to each phase of the project undertaken. It is expected that this documentation will be

appropriate to the project in question and will be provided to a standard that supports full system operability, usability

and maintainability (DOE, 2002b).

Wherever possible students will be encouraged to work in teams, as this is a key capability for an IT professional, andenables larger, more challenging and realistic projects to be undertaken. For more research-oriented projects it is

expected that students will also be able to produce either a suitable commercial report or an informative, readable,

finished article in a scientific format. Regardless of chosen option, students will be expected to produce a final

portfolio demonstrating their work and including a reflective report upon their experience.

1.3. Selection of a project

From experience we have found that working in a small group (2 to 4 people) increases the chance of a successful outcome.

Because most projects cover the full development cycle they require a wide range of skills. It is unusual to find all these

skills in a single person. Working in a group offers a better skill mix. The second reason relates to motivation. Whatever

you do as a project you are going to get problems for which you do not immediately know the solution. Unless you can

sustain your motivation during these periods it may put your project in jeopardy. When a group is involved you have othersto discuss your problems with and to assist with motivation.

This does NOT mean we disallow individual projects. But you should recognise that these are more difficult to bring to a

successful and timely conclusion. In the interest of developing professional capabilities, it must also be recognised that

most commercial software is developed in teams, and the ability to work effectively within a team environment is a key

requirement for an IT professional or for a researcher in computing. Therefore students wishing to undertake individual

projects will require specific approval from the project coordinator.

The project coordinator will aim to find sufficient projects so that you have some element of choice. You are also activelyencouraged to find your own project and recommend a suitable sponsor. If you are able to find your own project then so

much the better, but you MUST discuss the suitability of the project you find with the project coordinator prior to making

any promises to the company concerned or commencing work on the project.

Prior to the first meeting of the Project students you will be presented with a prospectus of the projects available. Ideally

before that first session, (and at the latest by the end of the first week of the semester), you must have indicated your project

preferences and the project coordinator will take into account your wishes to the extent possible and assign you to your

project and the team with whom you will work.

After this meeting the project coordinator will assign a project supervisor to your project. The project coordinator will then

contact the companies/sponsors who have submitted projects and inform them whether or not their project has been selected

by the students. For the projects that are going ahead, they will be informed of the team members and supervisor.

In this initial period you will need to identify your project resource needs, and whether you will be working on site at the

clients premises or off-site. These factors will be taken into account when assigning working space in the dedicated BCIS

7/31/2019 Guidebook BCIS 2 2011 v2.6

6/58


1.4. Project proposal or Work Integrated Project Learning Agreement

1.4.1 Project ProposalThe first main activity of the project is to prepare a project proposal. This proposal should describe in broad terms, the

client or sponsor's vision or set of expectations, (whether they be based upon a problem, need or perceived opportunity) and

the proposed approach to achieving an outcome or solution.

The project team arrange a meeting with the client/sponsor and project supervisor as soon as possible after the project has

been assigned. From this initial meeting, and possibly others, the project team extract sufficient information for them to

develop their project proposal. The following information should be included in your project proposal:

1. Name(s) of project team member(s) contact phone numbers and email addresses while at AUT (there is aphone available in the dedicated project rooms WT026 + WT027 extension 5880 & 5801) and after hours.

2. Name of contact person at the company/institution.3. Name of client's company/institution.

4. Phone number and email address of contact.

5. Skills and knowledge involved.

Identify the skills and knowledge expected to be gained by the student(s) in the execution of the

project. Be specific where possible, and include a full range of personal, professional and

technical capabilities.

6. Project proposal details.a. Terms of reference.

b. Brief description of existing system or area of enquiry.

c. Description of the proposed solution including benefits and hardware/software environment.

d. Description of proposed actions needed to reach that solution, including proposed approach, chosen

development or research methodology to be applied, resources required and their location.

e. Identify all costs incurred to reach that solution, both one-off and on-going, by the client, AUT, and

the student. (Do not forget to include any costs or resources associated with the development

environment required for the project!!).

f. Justification for proposed actions (including details of alternatives considered, if any).g. List of all activities necessary for completion (don't let this inhibit your creativity later in the

project).

7. Additional information needed for your project plan - when it is known (see below for details of

project plan).

a. A detailed list (including time estimates) of all activities necessary for completion of the project.

b. A Gantt chart showing dependencies of these activities.

c. An assessment schedule (refer appendix B).8. An appendix including the standard disclaimer, clarifying the nature of the relationship involved when

undertaking projects on behalf of external clients (refer Appendix I)

Note: For projects involving the implementation of a packaged software solution, the article by Morisio, et al.,

(2000) (cf. Bibliography section below), may offer one example of a suitable methodology.

As you develop your proposal ready for presentation discuss it with your project supervisor and ensure that the final version

is shown to your supervisor beforehand who will review it for suitability to present.

7/31/2019 Guidebook BCIS 2 2011 v2.6

7/58


1.4.2 Work Integrated Project - Learning AgreementThe Learning Agreement is a key document for the work assignment. Your work assignment, what you expect to learn, and

how this will be accomplished, are formed in negotiation with your academic and workplace supervisors.

Content of a Learning Agreement:As with a proposal,

1. Cover page containing:i. Name(s) of project team member(s) contact phone numbers and email addresses while at AUT

(there is a phone available in the dedicated project rooms WT026 + WT027 extension 5880 &

5801) and after hours.

ii. Name of contact person at the company/institution.iii. Name of client's company/institution.iv. Phone number and email address of contact.

2. A section for all three parties to sign (the workplace supervisor, student/s, academic supervisor)3. Work Assignment

A description of the work you have agreed to undertake and how you plan to achieve it. This ensures

that you and the workplace and academic supervisors clearly understand what you are expected to

achieve so that you both have a common understanding. It also acts as a planning tool to help you

to focus on the tasks and how to work efficiently towards achieving them.

Description of Work Assignment:

The work assignment is each given separately as described under (your individual contribution to the

assignment).

The work assignment, the objectives and expected result of the work assignment (from theperspective of the workplace).

The standards which must be met in completing the work assignment

The strategies to be adopted

The necessary resources

Evidence of accomplishment

How the evidence is to be validated

If it is not obvious how this work relates to your major or discipline, please describe the relationship.

4. Work Plan

Include a plan to support the work assignment including tasks and milestones5. Relating Theory to PracticeDescribe the theories, concepts and models (and APA references to these) that will be relevant to your

work assignment. This shows your understanding of the theories that you will apply in practice toachieve your expected outcomes for the work assignment.

6. Adding Value to the Clients OrganisationA critical evaluation of how your work assignment will add value to the clients organisation.

Identification of the personal characteristics that might contribute to your completing the assignment.

7. Discipline and Capability Goals and Outcomes (for each team member)

Provide a description of the discipline goals; areas of your discipline where you expect to improve yourcurrent knowledge and ability.

Give a description of the capability goals, personal skills and capabilities that you expect to improve.

Describe each goal or objective, the outcome of the goal, the strategies you will employ to achieve the

goal and the evidence of accomplishment.

8. Arrangements for the work placementDescribe the conditions such as start and end dates, work hours, or any other relevant conditions or

7/31/2019 Guidebook BCIS 2 2011 v2.6

8/58


1.5. Project planning and control

Now think about all the activities you need to do to achieve what you've defined in your proposal/learning agreement. Next

list any activities that other people need to do. This could involve purchasing Hardware or Software, identifying userprofiles and suitable groups to conduct usability evaluations, arranging with service providers to install technology

infrastructure, establishing necessary development and testing environments, employing temporary staff for data

conversion, checking the results of acceptance testing etc. Remember to include all stages of the project development.

You'll need to decide upon an implementation or handover strategy in order to complete the plan. This is important as it

identifies clear responsibilities between the project team members and client. It also serves to provide other people involved

with ample warning of what is expected of them.

In addition to the activities involved with your project there are a number of discrete processes to be considered. Your

assessment programme recognises that it will be important for you to manage these processes effectively in order tosuccessfully complete your project. You may already have been exposed to many of these processes in prior courses such

as software engineering and IT project management. Examples of relevant processes can be found in ISO (1998), and

include primary life cycle processes such as development processes incorporating process implementation, software

requirements analysis, software architectural design, software integration, software qualification testing, software

acceptance support, etc., supporting life cycle processes such as a documentation process, configuration management, and a

quality assurance process, incorporating verification and validation and joint reviews, organizational lifecycle processes

such as a management process incorporating initiation and scope definition, planning, execution and control, review and

evaluation and closure. Project and risk management are further examples of relevant management processes.

Develop a more detailed schedule (e.g. a Gantt chart, spreadsheet) showing all the activities and an estimated completion

time for each. Consider the specific processes involved in your project (the previous list of processes may be a guide in

this) and the deliverables required to support each process. Cameron (2002) and ISO (1998) may be useful guides to

identifying relevant deliverables. For each deliverable item there will be one or more associated tasks to be included in your

plan. Plan the current phase of your project and your most immediate tasks in considerable detail, and plan later phases at a

more indicative level, which identifies the major activities that are to be undertaken, and their critical predecessors. As a

rule of thumb, try to plan at a level of granularity which includes at least three tasks per week with specific outcomes

from each. This is the start of your project plan. Use MS-Project or other appropriate support tool.

Part of the process of project definition and planning requires you to produce an estimate of the scope of your project and

the effort involved, based upon the information you have gathered while determining the project requirements. One useful

technique for this estimation in software development projects is to conduct a function point analysis of your project. UsingEarly Function Point analysis (Santillo & Meli, 1998) this can be done quite early in your project. Use the results to help

with your estimates.

Part of the quality assurance for your project involves some form of project quality review. Your development

methodology may for instance incorporate a form of continuous review, such as pair programming, or your project may

produce alternative artefacts such as a policy proposal, a procedure manual, design component, or a process model which

would benefit from peer and expert scrutiny. You will need to explicitly schedule project quality reviews for at least two

key decision points or deliverables produced during your project. Your project cohort, your project supervisor and any

other suitable experts would expect to participate in these quality reviews, held in the scheduled weekly project time slots,

which should be completed and signed off before you continue to the next stage of your project.

ALLOW TIME IN YOUR PROJECT PLAN FOR THESE QUALITY REVIEWS AND OTHER PROJECT AND

7/31/2019 Guidebook BCIS 2 2011 v2.6

9/58


At this stage of your project, we expect the whole group will be involved in all activities but when tasks are to beconducted by individual group members (particularly during construction) then these should be clearly identified

in your plan.

Especially remember to take into account that the project is not the only activity that you are undertaking,

so ensure when assigning your time that you include allowances for your other courses, part time job,

family life, vacation or breaks etc.

1.6. Completion date

In your project plan you must identify a completion date for your project. This date is normally determined by the academiccalendar. An overview of the cycle for the Research & Development Project is given in Appendix J, and you should make

sure that your plans work to that broad schedule. Research & Development Project scoping and estimating is often achallenging process, and it is difficult to find projects that are an exact match with the time and resources available. Thus, if

you are undertaking a project on behalf of a live client you may consider what your commitments are to the academic

dimension of the project separately from that of your commitment to your client. For instance you may negotiate to provide

and support extra functionality for your client after the satisfaction of your academic requirements on agreed commercial

terms and conditions.

It is important that you meet the deadlines that you set. If you are unable to meet the deadline, then at your final assessment

you will need to give convincing reasons for not doing so, and have an agreed set of understandings with your sponsor.

Projects that do not complete on time will normally be ineligible for A grade marks.

If the methodology you adopt does not specifically address issues of scope variation, completion criteria etc., then to avoid

any uncertainty about the final status of your project, it may be a good idea to negotiate a project completion plan (IBM,

1979) with your client. IBM has recommended that this plan include the following points:

Original project scope

Significant approved changes

Remaining budget (person-hours)

Remaining tasks (yours and the clients) Products remaining to be developed

Completion criteria

Phase-over plano To cover phase out of the development team and phase-in of user and operational support

responsibilities.

Once your project is completed the project coordinator will arrange for your project to be assessed.

7/31/2019 Guidebook BCIS 2 2011 v2.6

10/58

7/31/2019 Guidebook BCIS 2 2011 v2.6

11/58


SECTION TWO - RESEARCH & DEVELOPMENT

PROJECTS - ACTIVITIES AND OUTCOMES

Table of Contents

2.1 Introduction

2.2 Nature of Projects and Deliverables


2.3.1 Project Proposal or Work Integrated Project Learning Agreement

2.3.2 Final Poster Presentation

2.3.3 Reflective Report and Project Review2.3.4 Evidence of Project Planning and Control

2.3.5 Evidence of Teamwork and Communication with Stakeholders

2.3.6 Relationship with the Sponsor/Client



2.3.9 Quality Assurance Activities and Outcomes2.3.10 Implementation Activities and Outcomes

2.4 Bibliography and Selected References

7/31/2019 Guidebook BCIS 2 2011 v2.6

12/58


2.1 Introduction

This section of the guide outlines the expectations of students and the nature of project deliverables and associated

assessment. The section is structured around the activities and items of assessment in the course and the deliverablesthat might accompany, or provide evidence for, each item to be assessed.

2.2 Projects and Deliverables

As outlined in Section One it is expected that projects will fall into one of the following broad categories:

Sponsored software Research and Development project

Sponsored Research and Development project

Sponsored software development project Consultancy project

Support/Maintenance project

Applied or theoretical research project

The activities, outcomes and deliverables for each of these project types will naturally vary, but it is expected that your

portfolio will evidence your work under each of the assessment categories.

2.2.1 Team Projects

In the case of team projects students must be able to demonstrate that the work presented is their own.

Mechanisms such as personal diaries, weekly logbooks and reports, project plans identifying responsible parties for

tasks, meeting minutes and notes, quality and project review notes and peer reviews could all be used to provide

evidence of individual work for later assessment.


2.3.1 Project Proposal or Work Integrated Project Learning Agreement

The first main assessment activity is your project proposal or learning agreement. This document describes, in broad terms,the client or sponsor's problem (or expectations) and the proposed approach to achieving a solution. Requirements for this

have been outlined previously in section 1.4 above

2.3.1.1 Project Progress Reviews

At a chosen point(s) in your project, normally at the mid way point, or at any other point at which your supervisor deems

appropriate, you should conduct a project progress review, involving your whole team, your supervisor, and the project co-ordinator. Appendix J provides indicative timings for these reviews. Please work with your supervisor to ensure that this

meeting is scheduled.

Prior to the review you should collect your deliverables from the project to date as evidence of your progress in a draft

portfolio, together with your diary, any progress reports or other materials which could build towards your final portfolio

evidencing your work. Refer appendix F for ideas of what you might include in an early edition of your portfolio, which

7/31/2019 Guidebook BCIS 2 2011 v2.6

13/58


The forms for this review are provided in Appendices D, D1 and D2. There are three most likely outcomes of this review:

Your project will be permitted to continue with or without conditionso This is the normal and hoped for situation

It may be recommended that your project be cancelledo This is clearly undesirable, but may be the best solution if the project shows a general failure to make

headway, or circumstances surrounding the project warrant its cancellation.

o In this event team members may be reassigned to other projects, with the option of extending the durationof their studies, or may be required to accelerate their contribution to complete within the timeline of the

other project team. These decisions will be made by the project coordinator in consultation with your

supervisor.

o However there can be no guaranteed outcome for students in this situation, and each case will need to beindividually negotiated.

It may be recommended that you confer with your client over the state of your projecto In this situation there may be some problem with the client relationship, availability, expectation from the

team, etc. which the team will need to resolve with the client. Your supervisor should help lead these

discussions.

2.3.2 Final poster presentation

2.3.2.1 Notes on project assessment

On completion of their project, students are required to conduct a final poster presentation involving a formal posterpresentation of the project to a panel of assessors, and including delivery of their project portfolios for scrutiny. The overall

grade for the project will subsequently be determined on completion of a detailed assessment of the project portfolio by the

project coordinator and project supervisor.

The final recommendation at that stage will be for one of the following outcomes:

PASS

CONDITIONAL PASS

REFERRALFAIL

The criteria used for the passing grades are explained below.

Where a conditional pass has been recommended the assessors are satisfied with the overall standard of the project but one

or more of the assessment points are outstanding or require revision. The project coordinator will determine a set of

conditions to be met and a duration within which they are to be satisfied. Provided these conditions are completed by the

stated deadlines and to the satisfaction of the client and/or project supervisor then the project will meet the conditions of a

Pass.

In the case of a referral, major deficiencies have been identified with the project, which are judged both reasonable and

within the abilities of the team to rectify. This will require the team members to resubmit the project to the assessors at a

later date. It is likely that a maximum achievable grade (normally less than a B) will be stipulated in such an event. Again

the deficiencies to be addressed will be brought to the attention of the project team members.

7/31/2019 Guidebook BCIS 2 2011 v2.6

14/58


2.3.2.2 Purpose of Poster Presentations

The final project poster sessions offer an opportunity for students to present their work in the form of a team poster and

project deliverables and reflect upon their achievements before an audience. The project deliverables will include

artefacts produced during the project and may include a demonstration of software. The assessment team will take intoaccount the ability of students to clearly communicate their work in a poster presentation that describes the scope,

depth and significance of their work, and critically reflects upon their experience.

2.3.2.3 Audience

The audience comprises senior academic staff of the School of Computing and Mathematical Sciences, including the

project coordinator and supervisor(s) and industry members of the industry advisory committee (IAC). The project

sponsor or nominee is invited to attend, and students are required to arrange their attendance. Studentsenrolled in the Research and Development Project may also attend to observe and support their colleagues. The student

attendance is restricted to after the assessment period to enable interactive discussion and assessment.

2.3.2.4 Suggested content of poster presentation

The following points would normally be covered during the course of your poster presentation.

Outlined project concept/rationaleHow you went about defining what the client/sponsor wanted. It should include the explanation of the existing situationor issue, and if relevant, how work was done and by whom. It should provide relevant background information or prior

literature. It should show whether the system has links to, or is based upon, another computer system.

Project artefacts (e.g. architecture, models, design, software, client deliverables)Identify the key constraints on your design or equivalent for each project type, eg existing hardware/software, languages

etc. Present your high level design or equivalent artefacts: Use Cases, Class Diagrams, or DFDs, entity model etc.

Present the low level design or equivalent: interaction diagrams, screen layouts, report layouts, forms, algorithms etc.

(For a more research oriented project the experimental design may be elaborated upon here). Justification of solution:why it is the best solution for the problem. This may include discussion of progress made and recommendation for

extensions to an initial prototype, or an evaluation report with recommendations for a particular technology option.

Remember that you are presenting to a technically competent audience so you can provide an in depth picture of

your work. They will be interested in the design and technical details of your solution. For many of them it may

be an opportunity to learn about how a new technology solution is actually designed and implemented.

How artefacts were produced and areas of greatest challengeA critical review of the processes adopted in carrying out the project, including quality assurance and discussion of

what worked well and what did not. This critique should relate any insights to relevant readings. Issues related to theeffectiveness of communication processes, team and personal or professional strategies could be covered.

Demonstration of completed or prototype system, or other demonstrable project artefacts (e.g. a tutorial, a future

business process map or a strategic IT plan for a consultancy project, or an improved technology platform for a

sponsored R& D project).

7/31/2019 Guidebook BCIS 2 2011 v2.6

15/58


2.3.3 Reflective Report and Project review

Fincher and Petre (2001) in their book titled Computer Science Project Work Principles and Pragmatics place special

emphasis upon the value of reflection: reflection on experience underpins the process of successful learning and is

essential to the success of education. However, not only is reflection on experience educationally valuable, but

engaging in reflective practice engenders a mindset that is invaluable for effective professional performance.

The reflective practice model was drawn from the work of Argyris & Schon (1974) and Schon (1987) in which

professional work involves an ongoing process of reflective practice involving self monitoring, continual improvement

and action cycles (plan, act, observe, reflect). AUT itself values the concept in its own teaching - "the term 'reflective

practitioner' was embraced because it admits a variety of strengths and openness in terms of beliefs about teaching

methodologies. The teacher, as reflective practitioner, is committed to evaluating and re-evaluating performance both

individually and collegially in order to sustain the never-ending drive to performance improvement. The more we learn

the more there is to learn. And the more we improve the more we recognise how much more we can improve"

(Hinchcliff, 1997).This model equally applies to the effective IT professional and the reflective work assessed in the project is aimed at

developing such capabilities.

Student reflection is encouraged in several ways in the project course.

Before the project students are required to consider their professional and personal needs, and in the projectproposal/learning agreement submission indicate the skills and knowledge involved in order for them to

successfully complete their projects.

During the course of the project a number of individual, peer and group reviews will be conducted, enabling

students to reflect upon the quality or appropriateness of their work and their behaviours.

It is recommended that students maintain an active personal diary or journal, to track activities and time spent onthe project and to note events and your own reflections upon them as they occur each day.

At the completion of the project the final poster presentation offers students an opportunity to reflect upon anddemonstrate what they have learnt, the results they have achieved, and the problems they have successfully

overcome. The formal reflective report also offers an opportunity for students to reflect upon the significance of

their work, and what they have gained personally and professionally from the experience and where they still have

to develop. This report is not merely descriptive of the project, but should include a broader critical dimension as

befits a final year degree course. This critical dimension should include reflection upon the project, its significanceand the wider context, and reflection upon personal and professional effectiveness in the conduct of the project.

This reflective comment should in turn be related to the relevant literature, such as that by Argyris (1996), Argyris

& Schon (1974) and Schon (1987) discussing the nature of professionalism and the concept of theories of action.

The reflective practitioner model requires that we surface the personally embarrassing and uncomfortable issues, and

deal honestly and openly with our shortcomings. For software development and other IT professionals, where flawed

assumptions must be critically challenged to avoid costly errors (or even disastrous project failure) and theory often

unfolds through the practice situation, this reflective ability is crucial to the improved performance of an individual or a

group. For students an honest diary or journal consistently and thoughtfully maintained throughout the project, or a

well considered self evaluation in the reflective report can prove effective tools in this journey.

2.3.3.1 Content of Reflective Report

The focus of the report must be not on mere description of your project and the activities you have undertaken, but on critical

analysis, evaluation and reflection, and your ability to demonstrate the application of relevant theory to the project experience.

7/31/2019 Guidebook BCIS 2 2011 v2.6

16/58


2.3.4 Evidence of Project Planning & Control

In identifying and managing the necessary set of processes to successfully complete your project, you will need to consider

your chosen lifecycle model and the accompanying processes, activities and deliverables required to carry it out, and

demonstrate that you have done so effectively. There are several techniques available to you to provide evidence ofeffective control of your project.

Throughout the project you are required to maintain a project diary. This is a day-by-day record of the number of hours

you worked and what you did during that time. Your diary should show a consistent work record for the duration of the

project. Maintain a running total of the number of hours you spent on project work. Your diary is also a useful historical

tool to track the reasons for your design decisions at key points in your project. Many companies require you to do this for

costing purposes especially if you are working on several different projects at the same time. Your supervisor may ask tosee your dairy at any time, so that you can provide a clear indication of your progress, the effort you are dedicating to the

project, your degree of personal contribution and the activities you have been working on. The online progress reportsposted each week to the course support database are a way of recording these in a more formal manner, and keeping your

supervisor up to date with progress on your project.

The main evidence of your project planning activity will come from your chosen project planning and reporting techniques,

with documents such as MS-Project Gantt charts showing all the activities, baseline plans, estimated and actual completion

times for each. Your online logbooks create an effective audit trail of your project monitoring and progress reporting and

should be included in your portfolio.

Reports tracking effort against estimate at an overall level could be provided as evidence of your project control activity,

using the time and task analysis spreadsheets from the course support database.

Sound estimates of the scope of your project and the effort involved, using techniques such as a function point analysis of

your project, or detailed work breakdowns, and decisions about project scope based upon the metrics provided, could be

included.

Reports of project quality reviews, planning or end phase reviews, and risk or quality management plans could provide

further evidence of project control.

As evidence of your own ability to control and track your project and build your evidence portfolio, it is recommended that

you buy a large ring binder at the beginning of your project, and progressively fill it (day by day and week by week) with

the team and individual artefacts which you will produce over the project duration. This will force you to consider from anearly stage how best to organise and present your work so that you can provide evidence against each of the assessment

criteria. It will also help you to consider configuration management issues as you track the historical versions of your

artefacts and adequately reflect changes across the full body of artefacts which apply to your project. You should bring this

portfolio to the regular meetings with your supervisor and discuss the contents on a regular basis.

2.3.5 Evidence of Teamwork and CommunicationEffective communication in a group context is an important aspect of teamwork, which is a key dimension of the project

experience, therefore supporting evidence demonstrating the exercise of these skills should be provided.

In addition to the reflective reports, group meeting minutes with clear assignment and identification of individual tasks, and

tracking of performance against assigned actions may evidence effective group project control, and teamwork.

7/31/2019 Guidebook BCIS 2 2011 v2.6

17/58


2.3.6 Relationship with the Sponsor/Client and Stakeholders

Managing client expectations is a key aspect of project success. Feedback from the client is the main means of

demonstrating that the team maintained a productive relationship with its client. This will normally be provided at or beforethe final poster presentation session at which the client will be asked for input into this assessment criterion. The supervisor

will have observed the interactions between the project team and the client throughout the project, and will also contribute

to this assessment.

It's VERY important to keep in touch with your clients/sponsors throughout the project, and you could develop a client

communication strategy or plan to address this. Maintain regular contact (every week might be a guideline for some

projects) and see them if possible, let them know what you are doing. There are many ways of maintaining your clientsinvolvement. You might demonstrate prototype versions of your software, to your clients, include them in quality review

sessions, confirm expectations through document sign-offs and reviews of change proposals, involve them in user profilingand usability tests, enlist their aid in developing user documentation, planning, developing and conducting acceptance tests,

or find other ways of maintaining regular contact. 5% of the final mark for your project is determined by how well you

communicate with your client.

Formal memos, sign-off documents, meeting minutes, records of discussions, working papers etc. may be other means to

evidence a professional communication process with the client. The role of a technical report or a working paper to

formally raise an issue for resolution by the client can be a useful mechanism, and could also provide evidence of active

project control.

Your own reflections discussing the clients feedback in your reflective report are another form of evidence.

Note:

It isstrongly recommendedthat you provide the feedback form (appendix H) to your client to fill in before you write your

reflective report. This form will be returned direct to your supervisor, who will in turn give it back to you soyou will need

to plan this step in advance, up to a month and at least two weeks before the scheduled project poster presentation date.

Stakeholders in the project typically extend well beyond sponsors/clients. Such parties might be day-to day users,

managerial users, end-customers or clients of a service provider for whom the system is developed, the wider academic

community in the case of a research project, oneself as a developer, ones colleagues in the development/research team or

related teams, the project supervisor, future developers or researchers intending to support the system or extend the work,

and system administrators or support personnel responsible for installation, operation and maintenance of the deliveredsolution.

To serve this community a wide range of supporting materials is required, and evidence of forms of communication

addressing these several needs should be provided. Examples might be interviews, user questionnaires, user profiles,

usability testing plans and records, prototypes, formal specifications and sign-offs, meeting minutes, quality review

presentation slides, email and other correspondence records, user guides and manuals, design rationales and specifications,

project standards, information security policies and standards, experimentation records, testing plans, records, error reports

and clearances, installation guides, developers guides, operational manuals etc.


As noted in 2.3.5 above, your project may serve the needs of a wide range of stakeholders, and therefore you will need to

7/31/2019 Guidebook BCIS 2 2011 v2.6

18/58


clearly outlined); a business case or cost benefit analysis; a technology or design evaluation report; the use of multi criteria

decision analysis to derive a set of recommendations; change and configuration management records; an issues registernoting issues and their resolution throughout the project, project working papers; reflective reports etc.


As a guideline you could consider the development process to comprise a broad set of activities that may involve iteration

and evolution of artefacts and documents towards your final working software or technology solution or sets of research or

consultancy conclusions.

In the course of development activities for non software based projects you will typically engage in a variety of activities

including one or a combination of the following depending upon the type of project: investigating, evaluating,

modifying, configuring and installing a proof of concept application and recommending through to installing and

deploying a pre-built software solution; planning, evaluating, project management, analysis, modelling, specifying,designing, or implementing policies, procedures, processes, plans, guidelines or systems; administering, operating,

monitoring, modifying, configuring, testing, installing or deploying IT infrastructure and systems; rigorously

investigating, evaluating, developing a model, an algorithm or a proof of concept or prototype application, and

recommending a resulting solution.

In the course of software development you will engage in a variety of activities including reuse planning, architectural

design, test design, coding, design, testing, refactoring, user interface design, and requirements elaboration (Philpott,

2003). A variety of support processes will in turn support these activities to effectively deliver the desired outcomes. Such

management processes include team management, project management, rationale management, configuration and quality

assurance (Philpott, 2003).Your portfolio should include suitable records and examples of artefacts, code and documents to evidence the conduct of

these activities and their results.

In some sense we may think of development as involving a mapping process, which perhaps more generally reflects the

whole process of design. This mapping process depicted below takes some real world practice or issue, transforms it into a

conceptual model or series of models, and then further transforms that into a computer implemented solution. This notion

of development can be considered generic to all types of projects. In a good software development process, thesetransformations reconceive the real world practice in some way that will improve upon the present. So the developer works

in partnership with a client to add value in producing the new work practice or process and/or supporting technologies andsoftware.

ConceptualModel

ComputerisedImplementation

Real World

Figure 1: Design as a Mapping Process

7/31/2019 Guidebook BCIS 2 2011 v2.6

19/58


But note that these phases do not necessarily follow one another in the neat sequence suggested by the classic

waterfall model, and often occur in parallel with writing and testing your software or technology platform,

demonstrating initial versions, getting client feedback, reviewing for usability and refactoring your designs.

If you have selected an iterative or incremental approach for your project lifecycle, only parts of these designs may be

produced in each iterative sequence, together with components of tested software. There may be several points in an

incremental lifecycle, at which each set of design and software deliverables are produced, and available for review. In amore sequential lifecycle the documents will also evolve and build towards completion over time, so that a final version of a

requirements specification with fully evolved analysis models may be produced quite late in the project. Reasonably solid

drafts would be expected relatively early in the lifecycle. Therefore the following section on design (which is strongly but

not exclusively focused towards the needs of software development projects) should be read with the above caveats in mind,noting that actually writing and testing parts of your software is one concrete means of developing, iterating and getting

feedback on your designs.

2.3.8.1 Conceptual Design

This process should clearly address the WHY and WHAT of the project, and could be thought of as the statement and

elaboration of a set of requirements or conceptual design, in a manner dictated by the type of project and the methodology

you have selected.

2.3.8.1.1 Conceptual Design Documents

This may result in a variety of documents (e.g. project vision, scoping document, initial feasibility study, requirements

definition, and conceptual and logical models which may incorporate a high level architecture, data models, context diagramand DFDs, Use Case models, scenarios, or other relevant documentation such as initial evaluation reports, technology

surveys, literature reviews, etc.). Roggio (2003) depicts one process by which use case evolve from domain to basic to

extended use cases, and become fleshed out as requirements become better understood. Bruegge & Dutoit (2000, p. 126)

propose an outline for a fairly classic requirements specification. This could typically be supplemented by a justification or

business case for your system, incorporating a full cost-benefit analysis, and a set of estimates for the project based upon

suitable metrics such as COCOMO II or Function Point Analysis.

This documentation may vary by project, for instance if your work is for a commercial client you may have to work to the

in-house methodology and documentation style in one previous project we produced documentation which included a

current business baseline, a future process model and an evaluation report, supplemented by a prototype application.In the case of a research project the requirements may arise from a formalisation of a research goal supported by a literature

review.

For an IT security or more infrastructure focused project, there may for instance be a proposal for a new policy, or an

architectural blueprint for a network or server configuration.

2.3.8.1.2 Conceptual Design Artefacts

If your project is adopting a more agile methodology (cf. http://www.agilealliance.com/), then your documentation may

evolve progressively with the production of a set of artefacts, such as a series of prototypes, interview notes, mock-ups,concept sketches, process maps, project backlogs, use case diagrams, essential use cases or scenarios, from a joint design

session, plus screen shots, rough report layouts etc., which could supplement an eventual final package.

2.3.8.1.3 Managing Evolution of Requirements

These requirements should be confirmed at various points in your project by your team and then presented for review by

7/31/2019 Guidebook BCIS 2 2011 v2.6

20/58


2.3.8.2 Logical Design

This process should clearly address the WHAT and HOW of the project, and could be thought of as the statement and

elaboration of a set of high level design goals, addressing external and logical design, again in a manner dictated by the type

of project and the methodology you have selected.

In this process you need to review the feasibility of your project (technical, operational etc.), and construct suitable design

artefacts and documentation. Typically these will be based upon UML and object oriented design documentation such as

scenarios, Class diagrams, state or interaction diagrams etc. or according to the structured methodology such as a physical

DFD and ERD. When considering system or software architectural design, UML component and deployment diagrams

may be a useful way to depict your design architecture. Again refer Bruegge & Dutoit (2000, p. 222) for an outline for a

system design specification. More sophisticated projects may further dictate that you produce a separate architectural

design document, depicting the overall design framework for your software or proposed technology solution. This design

documentation again will evolve with your project, and should include at various stages the key models and artefacts that

have driven your design thinking. One thing your design should include is a justification for your design decisions, based

upon a review of alternative options, with their respective advantages and disadvantages.

Once developed these models, documents or artefacts may be subjected to a quality review by the whole group, and selected

experts that you may invite to the session. But note: since the goal of quality reviews is to improve the quality of work, it

may be preferable to select a single key design model or concept that is critical to your application, and subject that to an

early quality review. While you should have actually thought through the concept, model, prototype or specification and

packaged your work in a respectable standard for review, do not wait to achieve a 100% complete state, as a review after

you have finalised and tidied all your design concepts and decisions will add far less value than one which confirms or

rejects possible paths.

2.3.8.3 Physical Design

This process should now clearly address the HOW of the project, and could be thought of as the statement and elaboration

of a set of low level design components, addressing internal and physical design, but once again in a manner dictated by the

type of project and the methodology you have selected.

Detailed design or physical design can be represented by paper based documents or a combination of documents and

prototype components. It could include: class diagrams with full elaboration of attributes and methods, a data dictionary (or

equivalent, documenting database tables, forms, queries, other computer processes, etc.), report layouts etc. Appropriate

UML static and dynamic models should be included for critical elements of the system. User Interface design elementssuch as screens and menus, navigation or site maps, could also form part of the design deliverables.

In decomposing your design elements into classes, components, or papers, consider any appropriate design patterns that

may apply, so that your design is robustly architected and potential for re-use is maximised.

Consider aspects of usability and usage centred design. Ensure that the needs of your stakeholders and the likely contexts in

which your application will be used, have been considered.

For projects of the R&D style the documentation at this phase may include an Information Technology evaluation report,

and possibly a design proposal for a prototype or proof-of-concept application or technology platform.

Research oriented projects may represent the physical software design in a similar manner to the above but to the level of

7/31/2019 Guidebook BCIS 2 2011 v2.6

21/58


You could consider producing a brief conversion/cutover strategy to assist in planning the implementation process, and to

plan roles and responsibilities clarifying how user or service provider intensive activities such as establishing technologyinfrastructure, test environments, acceptance testing, data capture, developing user documentation, training, installation,

hosting arrangements, migration from the old system/method, operational and support responsibilities, handover etc. will

take place. Remember too in your planning to include realistic estimates of the time required for you to learn a new

technology or environment, and time for other parties to familiarise themselves and complete their activities.

You should work with your project supervisor and your client to ensure that this has been achieved.

2.3.8.4. Evidence for Writing and Testing your Software or Technology Platform

Consider the set up of your development environment, and special testing or hardware/software needs. Think through the

change control and configuration management strategy how will you communicate changes to other team members, and

ensure that you are all working on a consistent version of the software specification and programs. It is good practice to

apply a change control mechanism initiated at the outset of the project, to help manage subsequent change by ensuring thatchanges are consciously assessed for impact and agreed by all parties, rather than simply accepted. Use of a source

management system is expected.

Documentation and artefacts here should evidence that you have produced thorough and detailed work in a careful manner

and to a professional level of quality. It could include program specifications, test data design and program unit test

specifications, test results and program source code listings. These listings should be organised in a manner that makes

them easy to follow, and suitably formatted and documented according to professional standards, (e.g. indexed with a table

of contents for the section of the portfolio and sorted in a logical order). Names for any classes for which you provide the

source code should be cross-checked to your design documentation, to ensure that they are consistent and that someonereading your code can easily refer to the design to understand how the different classes, functions or components interrelate.

Supporting artefacts will include a copy of the working application, installation instructions if necessary, and sufficient test

data to exercise and demonstrate the software. You may also include evidence of any refactoring of your software that you

have undertaken at key points in your project.

For non software projects you will need to consider how to plan and evidence the testing processes, by which you have

demonstrated the efficacy of your installed technology platform, consulting recommendations, new set of policies,processes or procedures or changes to the present environment.

2.3.9. Quality Assurance Activities and Outcomes

Given that a key goal of your project is to produce professionally written quality software, technical advice or soundly

installed technology platforms, you will need to evidence effective processes for ensuring the quality of both your

development process and results. You may for instance choose to define standards for aspects of your work and the

resulting deliverables should conform to these. The planning process for testing especially should be demonstrated, with

progressive, continuous and varied forms of testing being applied throughout each project. Some methodologies e.g. Test

First (Highsmith, 2002) may be test driven, and require automated testing tools, and the plans and resulting deliverables

should reflect the chosen process.

Both formal testing specifications in which you pre-plan the tests to be conducted to demonstrate the robustness of the

solution provided, and continuous quality review and inspection processes should be considered, as these will be applicable

to any type of project. For every piece of work you produce in your project, you should consider, how can I ensure

that this is to a suitable standard of quality? What review or checking process do you need to put in place? The

7/31/2019 Guidebook BCIS 2 2011 v2.6

22/58


documentation, training, installation, hosting arrangements, migration from the old system/method, operational and support

responsibilities, handover etc. You will also need to clarify what support commitments are required from the project team.Similar planning requirements will apply if your project involves a new technology platform, and a managed migration

from the prior system. A large technology roll-out for instance (e.g. a new desktop platform for a multi-user multi-branch

operation), will have similar needs for a careful and stage managed transition. In the same way a more operational

assignment should have robust change management procedures by which regular smaller changes are implemented into aproduction environment.

You should by now have conducted your previously planned range of tests (e.g. unit, integration, usability, and performance

and acceptance tests), documented your results and convinced the user that your software, your technology platform or yourproposed new system or process really works. This phase may involve data conversion in the case of software or platform

migration projects and be costly and drawn-out, while you are waiting for users to check results or do parallel runs etc.

You will need to very consciously determine the end point of your project, by defining a set of completion criteria both for

academic purposes, and for providing a tidy handover package to your client. You may also choose to commit to a periodof support during a warranty period after the system is cutover in the user environment. Consider such things as

arrangements for ongoing support of your software, for a warranty period, for future enhancements etc. and the point at

which you migrate from being a student developer to either a paid provider of development services, or one who has

relinquished maintenance responsibilities to the client or a third party.

Similar requirements apply to research and IT infrastructure related projects in most cases, where your handover package

should enable others to review and readily pick up and carry on your work.

Documentation again should evidence that you have produced work in a careful manner and to a professional level ofquality. It could include integration and acceptance test specifications, test data design and test result reports, outstandingerror schedules, any known shortcomings, conversion/cutover plans, user manuals, operational and technical manuals,

program and system installation instructions, program executable code and source code listings. Soft copies of executables

and data will be necessary to exercise and handover any completed software. Sufficient test data to exercise the software

should be provided in sample datasets with your handover package. Formal user sign-offs accepting the delivered solution

(or solutions in the case of phased deliveries) should also be included in your evidence for this phase(s) of your project.

h & l j S d G id b k

7/31/2019 Guidebook BCIS 2 2011 v2.6

23/58


Possible Deliverables List

For those requiring guidance as to what should be included in their portfolio for the various project phases, a list of key

artefacts from which a possible set of deliverables for a software development project could be selected is given below.

This list is a subset of life cycle process outputs taken from the International Standards Organisation Standard InformationTechnology Guide for ISO/IEC 12207 (Software Life Cycle Processes), Technical report TR15271 1st edition 1998-12-

01. A further useful source of guidance is the article by Cameron (2002) on configurable development processes,

suggesting how to define a set of deliverables to suit the needs of your project. The names of deliverables will vary from

one standard set to another and these ISO standard names may equate to several other names or equivalent artefactsmentioned above. The format of these artefacts may also vary considerably depending upon your project and chosen

approach, and tend to reflect a relatively traditional and formal waterfall based lifecycle. For a more research-oriented or IT

infrastructure focused project, many of these deliverables will be inappropriate, but some generally equivalent set of work

products, that provides evidence for each of the key activities in your assessment schedule (cf. appendix B below) should be

considered.

Process Sub-

clause

Outputs Output Type

Supply 5.2.2.1 Proposal Proposal

5.2.4.5 Project management Plan(s) Plan

5.2.6.4 Evaluation Report Report

Development 5.3.1.4 Development Plans Plan

5.3.2.1 System requirements Specification Description5.3.3.1 System Architecture Document Description

5.3.4.1 Software Specification Description

5.3.5.1 Architecture Specification Description

5.3.5.1 Software configuration item Software

5.3.5.4 Users manual(s) Manual

5.3.5.5 Test Requirements Description

5.3.6.1 Detailed Design Description

5.3.6.5 Software unit test requirements Description

5.3.10.1 System integration and test results Record

5.3.10.2 Software qualification test requirements Description

5.3.13.1 Software acceptance review and testing Record

5.3.7.1 Software units and databases Software

Operation 5.4.1.3 Test procedure for Operational Environment Procedure

Maintenance 5.5.1.1. Maintenance Plan Plan

5.5.5.2 Migration Plan Plan

Quality Assurance 6.3.1.3 Quality Assurance Plan Plan

Training 7.4.1.1 Training Plan Plan

R h & D l t P j t St d t G id b k

7/31/2019 Guidebook BCIS 2 2011 v2.6

24/58


2.4 BIBLIOGRAPHY AND SELECTED REFERENCES

The following brief list of readings provides a few sources that can be useful in the conduct of your project. Some of

these will be provided as handouts during the course, others may be available via the e-library (the ACM and IEEE

Explore Digital libraries are extremely valuable computing databases, which contain quality academic and professionalarticles from a range of journals and conferences) or in the project room library for reading within the project room.

Abran, A., Moore, J., Bourque, R., Dupuis, P., & Tripp, L. (Eds.). (2001). Guide to the Software Engineering Body of

Knowledge (Vol. 1). New Jersey: IEEE Computer Society Press.

Acuna, S., & Juristo, N. (2004). Assigning people to roles in software projects. Sofware - Practice and Experience, 34,

675-696.

Ambler, S. (2001-2002).Essay - Agile Documentation. Retrieved 14/02/2003, 2003, from

http://www.agilemodeling.com/essays/agileDocumentation.htm

Ambler, S., & Constantine, L. (2000). The Unified Process Inception Phase. Lawrence: CMP Books.Argyris, C. (1996). Unrecognized Defenses of Scholars: Impact on Theory and Research. Organization Science, 7(1),

79-87.

Argyris, C., & Schon, D. (1974). Theory In Practice: Increasing Professional Effectiveness. San Francisco: Jossey

Bass.

Aurum, A., Petersson, H., & Wohlin, C. (2002). State-of-the-Art: Software Inspections After 25 Years. Software

Testing Verification Reliability, 12(3), 133-154.

Beck, K. (2000).Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley.

Biggs, C., Birks, E., & Atkins, W. (1980).Managing the Systems Development Process. Englewood Cliffs, New

Jersey: Prentice-Hall.Boehm, B. (1988). A Spiral Model of Software Development and Enhancement.IEEE Computer(May), 61 - 72.

Brooks, F. (1995). The Mythical Man-Month (Anniversary ed.). Boston: Addison Wesley Longman.

Bruegge, B., & Dutoit, A. (2000). Object Oriented Software Engineering. New Jersey: Prentice Hall.

Bruegge, B., & Dutoit, A. (2004). Object Oriented Software Engineering Using UML, Patterns and Java. New

Jersey: Pearson Prentice Hall.

Cameron, J. (2002). Configurable Development Processes. Communications of the ACM, 45(3), 72-77.

Clear, T. (1997). Quality Control Expert System: A Project Review. The New Zealand Journal of Applied Computing

and Information Technology, 1(1), 49 - 62.

Clear, T. (2001, Dec). "Programming in the Large" and the need for Professional Discrimination. SIGCSE Bulletin, 33,9-10.

Clear, T. (2003, Jun). Documentation and Agile Methods: Striking a Balance. SIGCSE Bulletin, 35, 12 - 13.

Clear, T. (2003, Dec). The Waterfall is Dead - Long Live the Waterfall!! SIGCSE Bulletin, 35, 13-14.

Clear, T. (2004, Dec). Students Becoming Political and "Incorrect" Through Agile Methods. SIGCSE Bulletin, 36, 13 -15.

Cockburn, A. (2003). People and Methodologies in Software Development [Online available:

http://alistair.cockburn.us/crystal/books/alistairsbooks.html Accessed 11/02/2005]. Unpublished Doctoral

Dissertation, University of Oslo, Oslo.

Cockburn, A. (2004). The End of Software Engineering and the Start of Economic-Cooperative Gaming. ComSISJournal, Computer Science and Information System [Online available

http://alistair.cockburn.us/crystal/articles/teoseatsoecg/theendofsoftwareengineering.htm, accessed 10/2/2005],

Submitted for publication(tba), tba.

Constantine, L., & Lockwood, L. (1999). Software for Use. Reading: ACM Press.

"Departmental Information Systems Engineering (DISE) Guidance, Volume 2, Managing DOE IT Projects".Retrieved

7 July 2011 from http://www cio energy gov/documents/DISE V2 D20 122702 pdf


7/31/2019 Guidebook BCIS 2 2011 v2.6

25/58


IBM. (1979).Managing the Application Development Process: Project Reviews. New York: IBM Corporation, DPD

Education.Jones, C. (1994).Assessment & Control of Software Risks. Englewood Cliffs: Prentice Hall.

Larman, C. (1998).Applying UML and Patterns: An Introduction to Object Oriented Analysis and Design. Upper

Saddle River, NJ: Prentice Hall.

McConnell, S. (1996).Rapid Development. Redmond: Microsoft Press.Morisio, M., Seaman, C., Parra, A., Basili, V., Kraft, S., & Condor, S. (2000, 4-11 Jun).Investigating and Improving a

COTS-Based Software Development Process. Paper presented at the 22nd International Conference on

Software Engineering, Limerick, Ireland.

Naur, P. (1985). Programming as Theory Building.Microprocessing and Microprogramming, 15, 253-261.Philpott, A. (2003). Bachelor of Information Technology, Software Engineering Presentation. Auckland: Unpublished.

Pressman, R. (2001). Software Engineering - A Practitioner's Approach (5th International ed.). Singapore: McGraw-

Hill.

Roggio, B. (2003). Use cases and traceability: a marriage for improved software quality. Paper presented at the 16th

Annual NACCQ Conference, Palmerston North.Santillo, L., & Meli, R. (1998).Early Function Points: some practical experiences of use. Paper presented at the

ESCOM - ENCRESS Process Control for 2000 & Beyond, Rome, Italy.

Schon, D. (1987).Educating the Reflective Practitioner. San Francisco: Jossey Bass.

Stevens, P., & Pooley, R. (2000). Using UML (Updated ed.). Harlow: Pearson Education, Addison Wesley Longman.

Umphress, D., Hendrix, T., & Cross, J. (2002). Software Process in the Classroom: The Capstone

Project Experience. IEEE Software, Sept-Oct, 78-85.


7/31/2019 Guidebook BCIS 2 2011 v2.6

26/58


PROJECT ASSESSMENT FORMS

Table of Contents

Appendix A - Project Documentation Guidelines

Appendix B Project Assessment Form

Appendix C Project Proposals Marking Schedule

Supplementary Appendix C Learning Agreement Assessment Criteria

Appendix D Project Progress Review Form

Appendix E Reflective Report Assessment Form

Appendix F Project Portfolio Contents Guide

Appendix G Assessment Criteria for Project Poster Presentation

Appendix H Individual Student Client Feedback Form

Appendix I Standard Disclaimer

Appendix J BCIS Project at a glance (indicative timeline)


7/31/2019 Guidebook BCIS 2 2011 v2.6

27/58


Appendix A

STUDENT RESEARCH & DEVELOPMENT PROJECTS(Paper 407003)

Project Documentation Guidelines

1.0 Preamble

These project guidelines are based upon those for a generic project within the degree, and give a recommended

approach to the researching and writing of the project, especially relevant to those projects which involve the research

option outlined in 1.2 (Nature of Projects) above.

The project is a key stage in preparing students to work as professionals in the Information Technology industry or to

progress to further study and potential research careers, and therefore one implicit assessment criterion is that all work

be produced to a level of quality that would be acceptable in a professionally managed commercial environment.

If you have any questions or concerns, please ask the paper coordinator. For 2009 Research & Development projects

this is Tony Clear and Gwyn Claxton.

2.0 Project Portfolio

The intention is that the project portfolio shall essentially be the record of the students (and/or teams) activities

throughout the project, to provide evidence of their achievements and the quality of the work produced. The portfolio

should include as a separate and confidential appendix a reflective report upon their personal experience and their

learning process.

A guide to the material to be included in a comprehensive individual portfolio is provided in Appendix F.:

3.0 Size of formal project reports and style of presentation.

3.1 Research Project Reports

Project research reports, such as an experimentation record, must have a minimum and maximum size.

Suggested format

Font size 12, 1.5 spaced, standard fonts.

Cover page (must have title, student name, ID No., date, supervisors name and paper number).Abstract page

Acknowledgments page

Table of contents 1 page

Introduction 2 - 5 pages

Experimental 2 - 5 pages**


7/31/2019 Guidebook BCIS 2 2011 v2.6

28/58

p j

Note: Certain types of project deliverables such as annotated bibliographies or reviews will have different sizes and

formats. Research & Development Projects may typically not involve formal experiments, but a research method ordevelopment methodology should be made explicit and a suitable report and evidence for each assessment criterion

produced to accompany any working artifacts.

Any deliverable produced from the project should clearly identifythe date produced, the version number and

change history if applicable, and its authorship.

3.2 Portfolio Presentation

Written components of the project should be typed using a word processor, A4, double sided and presented in a simplefolder, with separators for distinct sections. Diagrams, references, photographs and other material may be

incorporated into the text or added as appendices. Copies of executable and source code, with suitable test data and

installation instructions may be provided in electronic form, but at least one printed copy of the source code (or

appropriate samples) should be provided in a coherently assembled and indexed sequence. Copies of project portfolios

will be held in the School of Computer and Information Sciences and will be available for inspection.

No plastic sleeves or covers are to be used except for the front and back external covers. Reflective reports should be

attached as a separate confidential appendix. The preferred binding for the reflective report is coil binding using clear

acetate sheets front and back and a cover page which clearly states:

1. The project title2. The authors name3. The authors Student ID number

4. The month and year of submission

Two (2) copies of the portfolio and all associated reports will be submittedand students should retain a furthercopy for their own reference. The portfolio should be appropriately sectioned with tables, diagrams, tables of

contents, indices where helpful, models, screen shots, and illustrations etc.where these add to the development of the

topic. The text should show citations, be referenced using the APA referencing style and acknowledge sources of help.

References may be as footnotes or as an appendix. References should be credible academic references, (e.g. from

journals or conference papers in the ACM or IEEE Explore digital libraries - not simply websites or wikipedia), and

follow a style that is used by one of the major scientific journals in the area of study.

By agreement with the supervisor(s) one of the copies may be submitted on a clearly labelled CD-ROM in Word

and/or Adobe Acrobat format. At least 1 paper copy must be submitted for the school records. All CD-ROM

submissions must be labelled on the CD and on the "Jewel Case" with the the project title, the authors name, the

authors Student ID number and the month and year of submission (as above)

4.0 Academic Integrity

Students are expected to clearly understand the requirements for academic integrity in consciously and formallyacknowledging the thoughts and contributions of others to your work. Phrased more negatively you are expected to

understand the definition of plagiarism and the consequences for plagiarism and dishonesty in the course. The School of

Computing and Mathematical Sciences handbook covers these issues in detail and students are advised to familiarise

themselves with the relevant section of the handbook before submitting their work. Plagiarism means borrowing from the

work of another without indicating by referencing (and by quotation marks where exact phrases are borrowed) that the ideas

expressed are not ones own Students may use the ideas and information of other authors including re use of source code


7/31/2019 Guidebook BCIS 2 2011 v2.6

29/58

Appendix B

Bachelor of Computer & Information Sciences

Research & Development Project (407003, 407008, 407009)

Name of project:

Team members:

Name of member being assessed:

Assessment points:

Point Description / Comments %age Date

completed

StatusComplete/in

progress/needs

review/not started

1 Project proposal/learning agreement 5

2 Final poster presentation 10

3 Reflective report 15

4 Project planning and control 5

5 Teamwork and Communication 5

6 Relationship with the sponsor/client and

stakeholders

5

7 Supervisor Feedback 10

8 Rationale for project decisions

9 Development activities and outputs

10 Quality Assurance activities and outcomes

11 Implementation activities and outcomes

Total 100

Note: %ages for points 8 11 must add up to 45 marks, exact weightings to be negotiated in advance with project

supervisor

Project assessment results

Circle recommendation(s): PASS CONDITIONAL REFERRAL.FAIL

Project Assessment Form


7/31/2019 Guidebook BCIS 2 2011 v2.6

30/58

Appendix B

Research & Development Project - Overall Comments & Recommendations:

Circle recommendation: PASS CONDITIONAL PASS REFERRAL FAIL

If conditional pass or referral is circled please note conditions which apply below:

If pass is circled please note any comments below:


7/31/2019 Guidebook BCIS 2 2011 v2.6

31/58

Appendix B1

Bachelor of Computer & Information Sciences: Research & Development Project

Research & Development ProjectPortfolio Feedback Form

Student..

Portfolio feedback is given against the eight broad headings below.

CCRRIITTEERRIIAA FEEDBACK

Quality of Reflective report (see schedule below fordetails)

See separately completed assessment form (Appendix

E)

Evidence of sound and effective Project Planning andProject control

Evidence of sound and effective Teamwork and

communication

Evidence of effective relationship with the sponsor/client

and relevant project stakeholders


7/31/2019 Guidebook BCIS 2 2011 v2.6

32/58

CRITERIA (Contd) FEEDBACK

Quality and completeness of Rationale for project

decisions

Quality and completeness of Development Activities

and Work Products

Quality and completeness of Quality Assuranceactivities and outcomes

Quality and completeness of Implementation activitiesand outcomes


7/31/2019 Guidebook BCIS 2 2011 v2.6

33/58

Appendix C

MARKING SCHEDULE for RESEARCH & DEVELOPMENT PROJECT PROPOSALS

Students name

Student ID number

Brief Title of project

Date submitted Date

Name and signature ofAssessor

Name and signature ofModerator

Conditions/ Suggestions (if any) from review panel:

Other Comments:

Project Proposals will be assessed holistically. The feedback form that follows will be used.


7/31/2019 Guidebook BCIS 2 2011 v2.6

34/58

Appendix CMARKING SCHEDULE for RESEARCH & DEVELOPMENT PROJECT PROPOSALS (Contd)

CRITERIA FEEDBACK

Proposal includes all required elements

(refer project proposal section of student

handbook)

Terms of reference and initial project

scope clearly identified

Methodology and Approach clearly

delineated and justified

Required costs and resources for project

identified

Proposed actions (with deliverables)

identified and justified

Skills and Know-how involved identified

Quality of proposal document presentation

Grade for Project Proposal

A+ A A- B+ B B- C+ C C- D

Over

40%

D

Under

40%


7/31/2019 Guidebook BCIS 2 2011 v2.6

35/58

Assessment Criteria for Learning Agreement Supplementary Appendix C

Student..

The Agreement will be assessed holistically. The feedback that follows will be used.

CRITERIA FEEDBACK

Agreement includes all required elements:Work assignment (BBus project), Relating Theory to Practice, Adding

Value to the organisation, Discipline and capability goals, Contact

arrangements with academic supervisor(s)

Work assignment and learning goals cover all components described in

appendix C1

The components of the work assignment are appropriatelylinked and described:For outcomes appropriate to goals, strategies appropriate to outcomes or

objectives, demonstration / evidence and assessment appropri

Guidebook BCIS 2 2011 v2.6

Documents

Transcript of Guidebook BCIS 2 2011 v2.6