Software Engineering Group Project Handbook, Study notes of Software Engineering

Download Software Engineering Group Project Handbook and more Study notes Software Engineering in PDF only on Docsity!

Software Engineering Group

Project Handbook

Peter Blanchfield

Modified 17 August 2016

Contents

• Introduction
  • Supporting lectures.
• Activities
  • Expression of Interest
  • Formal meetings and Sprints
  • GitLab
  • Non-disclosure agreements (NDA) and IP
• Deliverables.............................................................................................................................................
  • Marks for Group Assessed Elements
  • Ethics Documentation
  • Marks for Individually Assessed Elements
  • Calculation of final marks..................................................................................................................
  • Assessment Guidelines
  • Peer Assessment
  • Specific issues in assessing software and use of software engineering tools.
• Appendix 1 Example call for Expressions of interest
• Appendix 2 Example Expression of Interest in response.
• Appendix 3 Example Individual Report G52GRP 2016/2017
• Individual Report...................................................................................................................................
• Peer Review

This is your chance to practice for a job interview. Often such interviews will put you into a group of people you have never met before and make you do a similar sort of pitch on a subject you have never heard of before. This will illustrate to you the soft skill of preparing presentations.

At the end of the project we hold a demonstration day. You may have seen your seniors doing this last year. It is modelled on the sort of trade show that you will often be asked to attend in your early years of your working life. Here the skill of one to one communication will be needed. You will effectively be acting as a sales person for your project.

If you have done all this before then you will have the opportunity to improve the soft skill of passing on to others good advice on how to work in teams and prepare such things.

You will also produce an individual report that will reflect on your group work and how you feel you worked. You will also give reviews of the peers in your group and this may contribute to how their marks being awarded.

A major component of the project will be to practice some of the software engineering techniques that you have covered theoretically or at a lower level of complexity in other modules. You will be expected to use some form of software repository system. For most projects you will use either the school GitLab server or an external Git server such as GitHub or BitBucket. There will be some externally sponsored projects where another repository will be used. Most of these will still be like Git in the way they work. There is a lot of documentation on Git available on the Internet. See for example https://git- scm.com/documentation. There will also be a couple of lectures on the use of Git in the early part of the first semester. You will also be introduced to the idea of a Trello board as an example of project process management board.

Supporting lectures.

As well as the lectures on Git there will be other lectures to help you understand what you need to do. In the first week there will be a lecture given by the Careers service on how to produce a CV. There will also be two lectures in the second semester on how to prepare for you open day stand and how to get posters printed. We will also give you input on how to prepare your final reports. Examples of what we are expecting of both the group and individual final reports are also given in the appendices below.

In addition to the specific lectures on how to do relevant tasks a number of guest lectures will take place in which industry partners will give input on how project management and software engineering work in their real world situation.

two weeks. Informal meetings with just the group present will take place regularly and more frequently. Attendance at formal meetings is compulsory and non-attendance will be taken into consideration when your supervisor reviews the individual reports. Attendance at informal meetings should not be avoided without some good cause and the need for non-attendance should be noted. Groups should ensure that they are not meeting informally regularly on a day and time when one or more members will regularly not be able to attend – for example when they have a class the others do not. Records of formal meetings in the form of minutes should be taken and kept on the GitLab repository on the school server. They should also be kept in a document repository agreed with the project supervisor and sponsor can access. Less formal meetings should also be recorded when important decisions have been made.

During the project formal “to do” lists will be introduced. This will be in the form of a set of business objectives worked out with the sponsor/supervisor at the first meeting. From these a backlog will be formed that is agreed by the team and the sponsor/supervisor. Generally a two week “sprint” will be set up and objectives for what will be demonstrated at the end of that sprint will be decided. A Kanban will be started. It is suggested that a Trello board is used for this purpose. Instructions on use of Trello will be given in a lecture with accompanying notes. The sprint backlog will be split up into tasks and checked out by team members with responsibility. Each time a task is completed this will be recorded by moving the task to a done list. Calculation of “burn down” can then be made so that it will be obvious when a task is ahead of or behind expected delivery. At the next sprint meeting (formal meeting) the demo will take place. There should also be a post mortem to decide what has gone well and what could be done better. This is designed to ensure that the targets for the end of the next sprint become gradually more realistic as the project progresses. Do not be afraid to share with the sponsor/supervisor when other class activities (course work for other modules for example) are going to be a pressure. This module is worth 10 credits per semester (20 in total) and you should only give this amount of work. Do not make this an excuse. 10 credits is supposed to take 100 hours of work per person for the semester. That means 600 person hours for a group of six. Work will take place over roughly 10 weeks so that is 10 hours per week each!

Each group should elect a team leader at their first meeting. As in the example Expression of Interest in the appendix this need not be the best coder in the group. There is a lot more to this type of project than coding and the best person is probably someone who has good people skills and understands people who don’t speak in CS acronyms. You will also need to elect a git master – see below.

GitLab

All groups will have a GitLab account. All members should sign up for this and will find they have been allocated to their appropriate project by the week after the pitch day (October 28 this year). The team will have to appoint a Git Master

and inform their supervisor of this. The supervisor will have the power to assign the member as a Git Master. This person will be responsible for making sure the state of the Git repository is kept up to date and no one commits anything to the master branch on Git that has not passed all unit tests and regression tests. Lectures will be given on the use of Git and Trello during the year. Many projects will use another repository for their working code development (for example teams might use GitHub making it more accessible to an external sponsor). However, the Git Master will be responsible for ensuring that all revisions to code etc. are regularly mirrored on the GitLab repository. You may want to use Google+ or OneNote to store your documents. This is allowed. It is not advisable to use Facebook. This is publically accessible – even when you form a private group – and you never know who will read this. (See below.)

Non-disclosure agreements (NDA) and IP

Those working on industry sponsored projects will need to sign non-disclosure agreements and agreements over IP usage with their sponsor. The School will work with the sponsor to ensure this is done legally. As a result no data or information pertaining to your project should be kept in a publically accessible form unless in line with the terms of the NDA.

As students at the University the Intellectual Property on any work you do as a formal part of your course belongs to the University. If the outcome of your project has any commercial potential then a separate agreement will govern its exploitation. An example non-disclosure agreement is shown in the appendix.

Deliverables

The formal deliverables for this module – the things you get marks for – are as follows:

 Initial expressions of interest  Personal CV  Performance at the pitch  Ethics form and continued adherence to ethics agreement (extend ethics form where appropriate)  Git and or other repository. Will include all minutes and other non- software documents as well as regular commits of developments. Further advice on the expectations of the repository are given below. Progress on the development of this will be assessed at the end of semester one and again at the end of the module.  Formal code/software including testing and documentation (for example Javadocs)  Final report. An example of what this should look like is given in the appendices based on the project from the example EoI. A pro forma for this will be available from the Moodle site.

Marks for Individually Assessed Elements

Element Percentage of individual mark

Due Date (2016/ session) CV 20% 17 October 2016 (To be submitted with the Group EOI) Peer Assessment 20% 12 May 2017 (Must be attached with the individual report) Individual report 60% 12 May 2017

Calculation of final marks

The final mark for an individual will be made up from a group mark and the individual mark. The group mark will count for 80% of the final mark and the individual mark counts for 20%. The group mark will be modified according to the peer assessments.

Important! Late submissions, be it of printed copies or electronic copies of reports and software, will be penalised at the standard university guidelines of 5 % per working day.

Assessment Guidelines

The Group Project Repository deliverable is marked by the module convener based on the

extent to which the the specified tasks have been achieved by the due date and, where

applicable, how well these tasks have been achieved.

For those in industrially based projects the opinion of the deliverable from the point of view of

the customer will be taken into account by the supervisor but the supervisor and members of

staff will be responsible for the marks that the project recievers.

The following guidelines are applied when judging the quality of the Group Reports and

Software:

 Exceptional (90–100 %) The reports, software and use of software engineering tools

(repository, Trello board etc.) should exhibit all the characteristics of an Excellent grade.

Additionally, the project should have been carried out in an utmost systematic and

professional manner, as evidenced by a problem analysis and subsequent requirements

specification of stunning clarity and insight, a system design of highest possible quality

that manifestly meets all requirements and given at a level of precision and detail that

directly could be translated into an implementation, an implementation of highest

possible quality and completeness whose conformance to the original specification has

been verified rigorously, and impeccable project management in terms of planning,

workload management, meeting deadlines, making the best possible use of each team-

member's skills and strengths, and with absolutely minimal (technical or otherwise)

guidance from the supervisor. For the industrially sponsored projects supervisors will

seek input from the sponsor to indicate whether in their opinion the project was

exceptionally exceeding their expectations in every way.

 Outstanding (80–89 %) The reports, software and use of software engineering tools

(repository, Trello board etc.)should exhibit all the characteristics of an Excellent grade.

Additionally, the project should have been carried out in a very systematic and

professional manner, as evidenced by a problem analysis and subsequent requirements

specification of significant clarity and insight, a system design of very high quality that

manifestly meets all requirements and given at a level of precision and detail that more

or less directly could be translated into an implementation, an implementation of highest

possible quality and completeness whose conformance to the original specification has

been verified thoroughly, and very skilled project management in terms of planning,

workload management, meeting deadlines, making vary good use of each team-

member's skills and strengths, and with very little (technical or otherwise) guidance from

the supervisor. For the industrially sponsored projects supervisors will seek input from

the sponsor to indicate whether in their opinion the project was undertaken in extension

of their expectations.

 Excellent (70–79 %) The reports, software and use of software engineering tools

(repository, Trello board etc.) should display a complete and thorough understanding of

the conceptual and practical issues surrounding the project topic, including related work.

The project should have been carried out in a systematic and professional manner, as

evidenced by a clear and insightful problem analysis and subsequent requirements

specification, a system design of high quality that meets all requirements and

substantially provides enough detail for implementation. Software should be completed in

all respects and exhibit very high quality. There should be evidence of a high degree of

testing. Supporting documentation should be complete and approaching the standard of

issues relating to the project topic. The reports would lack a clear structure and strong

argument, and the quality of analysis, requirements specification, and design would be

below average. The writing would be mediocre. Software would be incomplete, poorly

commented and difficult to understand; it would exhibit poor levels of quality. Supporting

documentation would be adequate. For the industrially sponsored projects supervisors will

seek input from the sponsor to indicate whether in their opinion the project was

adequately completed.

 Poor (below 40 %) The reports, software and use of software engineering tools

(repository, Trello board etc.)would display a very poor understanding of the project

area; there would be no clear structure and the analysis may be weak or incomplete. The

reports would be poorly written and presented. Software would be limited in capability,

and difficult to use. Supporting documentation would be inadequate for most purposes.

For the industrially sponsored projects supervisors will seek input from the sponsor to

indicate the extent to which the group failed to meet their expectations.

The Open Day is marked primarily on

 how well demonstrations work;

 the overall quality of the display;

 the professionalism of those manning the stall (attitude, ability to demonstrate and

explain).

All members of staff will be expected to provide marking on these criteria for every stall

they visit.

The Individual Report is primarily marked on

 The quality of the reflective statement for each section (see the pro forma in the

appendix.) This will include the quality of the peer assessment statements – whether the

opinion of other members is balanced and well explained against the criteria presented.

 The Individual Report is not marked on the contribution of an individual: peer assessment

takes care of that. But showing a clear understanding of ones role in the project, the true

value of one’s contribution, and what was learned about working as a team, including

honest self-assessment and peer assessments, is important.

Peer Assessment

As explained above, peer assessment is a key aspect of the overall assessment. It is used

to distribute the collective group mark to each individual according to merit as perceived by

the peers, i.e. the other group members. A written justification supporting the ratings is also

required for each member – see the example in the appendix. The peer assessments are

submitted in complete confidence. The following aspects should be taken into account

when judging your fellow students' contributions:

 General Contribution to the project – coding, relationship with customers, data gathering and so on.  Attendance at meetings  Creativity – ideas for the project. Creativity on preparing for open day, contribution to designs etc.  Work rate – did they do the work given to them or did others have to substitute for them? If they did not attend well they may still have delivered the required work as and when desired.  How did they perform as a team member? Someone who did a lot of coding but did nothing to help the others to play their role should not get extra credit.

Thus it is not just the amount of contributed work that is being evaluated, say in terms of

words in the reports or lines of source code, but a wide spectrum of contributions all of which

are important for a successful end result. This also means that everyone gets a chance to

contribute according to their specific skills and get proper recognition for this. Clearly,

someone who excels in designing the system architecture and implementing it has made a

conventions? Can someone else easily understand your project software so they could extend it? If, for example, you are using Java, have you used Javadoc compatible comments? Do the methods all have one function? All software should have been undertaken using testing. You should clearly have used test driven development where possible (some user interface components may be difficult to unit test so you may need to have clear user test patterns). Where possible – especially where a UI is being designed – beta testing should be reported. Bug reports should always be listed. In using the repository it should be clear that you have had a good structure of using such things as delivery branch, development branches and issues. Git has the opportunity to set milestones. Trello or similar software must be used to keep a Kanban for your project. There must be evidence of the development process you have used. Deliverables should be planned on a two week cycle through term time and results of demo days and post mortems will be recorded. Regular commits of developments should be made. There will be regular evidence of merging. There will be evidence that all commits have made sure that they do not commit with known bugs. General SE tools should be used and so should UML in designing the software including the use of Use Cases in defining unit tests. Evidence of all software testing should be recorded.

A repository of some form (Google+, OneNote etc) should be used for all documentation. Commits to this repository should include meeting minutes for formal meetings with the supervisor/sponsors. You should also be clear that all decisions made at “daily stand ups” are recorded. Lack of attendance at meetings can only be reported in Peer assessments if they are recorded in documentation. User manuals and so on should also be kept on this repository.

Appendix 1 Example call for Expressions of interest

Call for Expressions of Interest Date of Issue 28 Sept 2015 Expected Completion Date 27 April 2016 Project Title Website and app to support parents of preterm infants Company NUH-NHS Trust Preterm Baby Unit QMC Nottingham Contact Person Dr Shalini Ojha Contact Email Shalini.Ojha@nottingham.ac.uk Project Background information Preterm infants, i.e. those born earlier than expected are at increased risk of ill health and frequently have poor nutrition, growth and development. Parenting a preterm infant can be very stressful. Preterm infants often spend long periods in the hospital and even after the medical crises have passed, and the infant is discharged home, parents may continue to experience distress as they attempt to care for their fragile infant whose development and behaviour may be different to term-born infants. Good nutrition is a key concern for parents. Our work with the parent-partnership focus groups revealed that families of preterm infants would benefit from support in this area. Weaning is the process by which babies start taking foods other than breast or infant formula milk. This time can be very stressful for parents of preterm infants. It is difficult for parents to decide when the baby is ready to be weaned and there is a lack of information about what would be the correct method and food to use while weaning. We would like to design a website to provide information about nutrition and weaning in preterm infants. This site will include information on how to identify when the child is ready to be weaned, culturally acceptable food items that can be used, how to feed infants, and other information about nutrition after weaning. The website should be also available via an app which may be downloadable on a range of smartphones. Currently there are some leaflets that provide information about how to wean preterm infants. The most frequently used is available at https://www.cshsurrey.co.uk/sites/default/files/uploads/documents/services/Weaning%20pret erm.pdf We would like to create a website with this information and investigate if giving parents information through a website and an app may be more useful than giving out leaflets. For the website: we would like to have a platform that has text and pictures, videos as well as the option for parents to share their experiences. The materials will be provided by the Neonatal Team at the Queen’s Medical Centre. Requirements Group must provide CV for each member of team Description of skills that make the team suitable to complete the project Expected Skills Highly Desirable Desirable Programming in suitable language for producing a web site

Experience in producing web sites

Appendix 2 Example Expression of Interest in response.

Expression of Interest Project Title Website and app to support parents of preterm infants Organisation or Supervisor NUH-NHS Trust Preterm Baby Unit QMC Nottingham Contact person Dr Shalini Ojha Contact email Shalini.Ojha@nottingham.ac.uk Team Members Name Email Address Harry Potter psyhp17@nottingham.ac.uk Hermione Granger psyhg2@nottingham.ac.uk Ron Weasley psyrw14@nottingham.ac.uk Albus Dumbledore psyad@nottingham.ac.uk Rubeus Hagrid psyrh1@nottingham.ac.uk Severus Snape psyss@nottingham.ac.uk

Description of Team Skills (You m ust provide clear evidence of to what extent the team has the Highly Desirable and where possible the Desirable Skills detailed on the Original Project form)

Our interest in this project has been sparked by a general desire to respond to need. The needs of pre-term babies are significant and being able to produce a product that would help their parents is inspiring for us all.

We have a wide range of experience working with organisations due to out of school activities engaged in by a number of our members. Our team leader Harry Potter had a very difficult early life and this gave him experience of work under severe conditions which has given him great empathy for others.

We all have a range of experience in web design and with the related languages. Servus Snape undertook work between school and university where he was involved in setting up an extensive network.

We have experience in background research which will help us to make good use of contacts in the Bliss organisation. Hermione is particularly skilled in the “magic arts” and particularly those that will help her to get to the bottom of users real requirements and motivation.

Other members of the group also have noted experience. Ron, Harry and Hermione have all worked together on a number of successful projects, which though very challenging at times, have all ended successfully.

Albus has worked in a number of leadership roles and has a deep understanding of managing teams. However, his experience with the languages needed for this project is extensive and has the abilities to ensure

the system back end works well. He is particularly skilled in the use of various SQL languages including MySQL and MicrosoftSQL. Both of which would be suitable for this project.

Rubeus is a real team worker and has experience developing both IPhone and Android applications and will undoubtedly fit the needs of these developments.

We believe we are the right team for this project because we have all of the skills required.

Highly Desirable and Desirable Skills:

Programming in suitable language for producing a web site; Experience in producing web sites –

We have developed web sites in HTML5 and PHP

Knowledge of languages used in programming mobile platforms ; Experience developing for IOS and Android –

Members of the team have produced mobile apps in IPhone and Android format. We have learned Java in the first year and have above average grades in this.

Knowledge of Database Management Software; Experience using MySql –

As explained above one of our team has experience in a number of dialects of SQL.

Ability to work with patient parents; Experience working in a team including not just technical members –

Again background experiences of two of our members make them particularly useful in working with patients in these difficult situations. Members of the group have commonly worked in areas outside of the norm experienced by computer science students.

Knowledge of versioning software for maintaining software integrity; Experience with Git –

Servus has worked extensively in industry with different versions of Git making him a Git expert.

(488 words) Date of Submission of EoI 14 October 2016 Date of Pitch 28 October 2016 Notification of award 2 November 2016

Please make sure to attach one page CVs for each member of the group.