Download - 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
Research & Development Project Student Guidebook
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 Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
SECTION TWO - RESEARCH & DEVELOPMENT
PROJECTS - ACTIVITIES AND OUTCOMES
Table of Contents
2.1 Introduction
2.2 Nature of Projects and Deliverables
2.3 Assessment Points
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.7 Rationale for Project Decisions
2.3.8 Development Activities and Outputs
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
Research & Development Project Student Guidebook
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 Assessment Points
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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.
2.3.7 Rationale for Project Decisions
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
Research & Development Project Student Guidebook
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.
2.3.8 Development Activities and Outputs
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
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
Research & Development Project Student Guidebook
-
7/31/2019 Guidebook BCIS 2 2011 v2.6
25/58
Research & Development Project Student Guidebook
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.
Research & Development Project Student Guidebook
-
7/31/2019 Guidebook BCIS 2 2011 v2.6
26/58
Research & Development Project Student Guidebook
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)
Research & Development Project Student Guidebook
-
7/31/2019 Guidebook BCIS 2 2011 v2.6
27/58
Research & Development Project Student Guidebook
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**
Research & Development Project Student Guidebook
-
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
Research & Development Project Student Guidebook
-
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
Research & Development Project Student Guidebook
-
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:
Research & Development Project Student Guidebook
-
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
Research & Development Project Student Guidebook
-
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
Research & Development Project Student Guidebook
-
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.
Research & Development Project Student Guidebook
-
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%
Research & Development Project Student Guidebook
-
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