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 ............................................................................................................................................ 3 Supporting lectures. ............................................................................................................................ 4 Activities .................................................................................................................................................. 6 Expression of Interest ......................................................................................................................... 6 Formal meetings and Sprints .............................................................................................................. 6 GitLab .................................................................................................................................................. 7 Non-disclosure agreements (NDA) and IP .......................................................................................... 8 Deliverables............................................................................................................................................. 8 Marks for Group Assessed Elements .................................................................................................. 9 Ethics Documentation ......................................................................................................................... 9 Marks for Individually Assessed Elements ........................................................................................ 10 Calculation of final marks.................................................................................................................. 10 Assessment Guidelines ..................................................................................................................... 10 Peer Assessment ............................................................................................................................... 14 Specific issues in assessing software and use of software engineering tools. ................................. 15 Appendix 1 Example call for Expressions of interest ............................................................................ 17 Appendix 2 Example Expression of Interest in response. ..................................................................... 19 Appendix 3 Example Individual Report G52GRP 2016/2017 ................................................................ 22 Individual Report ................................................................................................................................... 23 Peer Review .......................................................................................................................................... 24 5 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. 6 Activities The project will have a number of distinct stages and deliverables. On the first week the teams will meet in the assigned lecture theatre on the assigned day. This year (2016) the lectures will take place on Friday at 13.00 in LT2. The first lecture will be on October 7. Expression of Interest The first activity will be to write a response to a call for expressions of interest. At the beginning of the course all these will be accessible via the Moodle page. You should get together as a team and discuss the projects on offer and decide a shortlist of ones you are interested in. Then you have to produce your expression of interest in the projects. A fictitious project description and a fictitious expression of interest are given in the appendices at the end of this document. You need to apply for four and you need to model the application on the original call – so don’t just recycle the same one for each application you make, make sure you illustrate how you have the skills needed for the given project. Most need the same skills but you will need to do your reason for choosing each of the projects. This will be a first opportunity to divide the work up between the group members. You will, of course, have to do your own CV. You will have a lecture on the first lecture day on how to write CVs given by a member of staff from the careers office. There is also a dummy CV for one of the members of the fictitious group members in the appendices. Each member needs to provide one of these for the expression of interest. The main aim of this document will be to explain why you are interested in the given project and why the project sponsor should choose your team. The next activity is to give a pitch for the projects. The project sponsors will look at all the applications and choose two groups they want to call to give an oral pitch of their expression of interest. The sponsors will make their decision and you will be given notice the week before the pitch of which ones you have to give. Some of you may not get any of the projects you want and may be attached to a project that does not get a satisfactory match by the time of the pitch. The majority of the projects have an industrial sponsor with some sponsors offering more than one project. You will be given a project by the Friday after the pitch day (October 28th this year). Formal meetings and Sprints One the project proper starts you will have to make arrangements for regular meetings with your project supervisor. If you are to be working on an industrially sponsored project you will need to liaise with the project sponsor for meeting times and arrangements with them also. Some will take place via video conferencing, some by physical visits to the companies and some by the companies visiting you. Regular meetings should take place between you and your supervisor and sponsor so that the supervisor and sponsor are kept in touch with project progress. Formal meetings should take place at least every 7 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 10 Marks for Individually Assessed Elements Element Percentage of individual mark Due Date (2016/17 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 11 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 12 high quality professional documentation. For the industrially sponsored projects supervisors will seek input from the sponsor to indicate whether in their opinion the project was undertaken with complete attention to their expectations.  Good (60–69 %) The reports, software and use of software engineering tools (repository, Trello board etc.) should show a good understanding of the conceptual and practical issues surrounding the project topic, including an adequate grasp of related work. The quality of the analysis, requirements specification, and design should be good, and the writing of the reports should be good in general. Software should be competently written. Evidence of testing should be presented. The software should be a complete and usable package which not only illustrates the principles of the work but also exhibits good levels of quality. Supporting documentation should be excellent for all purposes; it should be complete, well written, well presented and generally exhibit high quality. For the industrially sponsored projects supervisors will seek input from the sponsor to indicate whether in their opinion the project was fully completed with little still needing to be completed.  Average (50–59 %) The reports, software and use of software engineering tools (repository, Trello board etc.) would be expected to display an adequate understanding of the key conceptual and practical issues, although weakness may be present in some areas. Some account taken of related work. The quality of the analysis, requirements specification, and design would exhibit significant weaknesses; the design would not as it stands constitute an adequate basis for implementation. The writing would exhibit some flaws. Software should be adequate to illustrate principles; it may display weakness in areas not central to the work and lack comprehensive testing. Supporting documentation would be well presented yet lack completeness; the quality of the documentation should be very good. For the industrially sponsored projects supervisors will seek input from the sponsor to indicate whether in their opinion the project was following their expectations but lacking in some ways.  Adequate (40–49 %) The reports, software and use of software engineering tools (repository, Trello board etc.) would display an incomplete understanding of the central 15 very important contribution. Likewise, someone who is a great writer and took the lead on getting the group reports together has also made a big contribution. But someone who was instrumental in mediating between conflicting views, say, and thus helped holding the group together has clearly also made a very valuable contribution to the group as a whole. The contribution of each peer will be rated on a 5-point scale ranging from 1 for “None” via 2 for “Inadequate”, 3 “Adequate”, 4 “Superior” to 5 “Excellent”, where “Adequate” means that the assessed person has done what is expected: no less, no more. Note that it is the relative performance of group members that matters as the peer marking only serves to redistribute the assigned collective group mark. For example, if everyone rate everyone else “Excellent”, the end result is that everyone gets the same mark for their contribution to the group work which is going to be equal to the collective group mark. Assessing your peers is a privilege and big responsibility. Be fair and objective in your evaluations. Do not come to any agreements with your peers to “give each other 3 or 4” or any other thing. Make sure you make your judgements based on your real views. How well you express your opinion of your peers’ contributions will have an impact on your own individual report. You also will not be able to control what others actually write and the marks you give. People are not always able to say what they really think if they are face to face with you. In the past, the members of the School Faculty have been very impressed with the quality and honesty of the peer assessment, and there have been few problems. Each supervisor is charged with carrying out a sanity check on the peer marks based on what they have learnt during the interaction with the group members throughout the year, as well as from the group and individual reports. Should there be obvious problems with some of the peer marks, then the supervisor together with the module convenor will override any or all of those marks where necessary. Specific issues in assessing software and use of software engineering tools. In addition to the marks you obtain for the software and software engineering in your project some of our industrial sponsors will provide project prizes for the best code quality and the best overall project. These will be independent of the marks you get from the staff markers. Code quality does not just look at whether the code works. We will also look at aspects of code complexity. Is the software well commented? Does it have a good and clear layout? Have you used consistent and appropriate naming 16 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. 17 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 20 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. 21 22 Appendix 3 Example Individual Report G52GRP 2016/2017 Individual Project Report Harry Potter Date of Submission 17 May 2017 Expected Submission Date 17 May 2017 Project Title Website and app to support parents of preterm infants Sponsoring Company NUH-NHS Trust Preterm Baby Unit QMC Nottingham Contact Person Dr Shalini Ojha Contact Email Shalini.Ojha@nottingham.ac.uk Project Supervisor Dr Peter Blanchfield Supervisor Email Peter.blanchfield@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. Skills required Highly Desirable Desirable Programming in suitable language for producing a web site Experience in producing web sites 25 Ron Weasly General Contribution to the project I have to admit to bias here as Ron was my best friend even before we came to university. I think his performance was excellent. We had worked together on a number of previous projects so we communicated very well. Attendance at meetings More than half but less than 2/3. He would often forget we were having meetings rather than deliberately not come Creativity Ron is more of a team worker than an ideas person. He always tried hard Work rate He worked really hard often staying up to the early hours to get work finished. How did they perform as a team member Ron is very friendly and gets on and does things. He likes most people though he seemed a bit nervous of working with Servus. Albus Dumbledore General Contribution to the project He was really good at the SQL programming and without him we would not have got finished. He really knows his languages and was able to back up Servus when he needed help. Attendance at meetings Less than ½. Generally this was through forgetting and being too busy at work on the project as much as other things. Creativity He is a brilliant ideas person and always has answers. He is a bit introverting and will not come out with his solution until he is fully sure whether it is right. Work rate Despite not coming to meetings he was always ahead of the rest in being ready. How did they perform as a team member He got on with everyone. He seemed to have a special belief in Servus and kept saying he would work out well in the end. Rubeus Hagrid General Contribution to the project Rubius is a hard worker and always looked out for others. He seemed to have a level of experience beyond the rest of us in the work processes. Attendance at meetings Attended all the meetings Creativity Rubius is another team worker rather than someone who is generating ideas. He could always help everyone. 26 Work rate High. Sometimes tiring he has the energy of a giant. How did they perform as a team member He was great at solving issues between team members. Especially when Servus was being criticised by others. Servus Snape General Contribution to the project He tended to work on his own and come up with software faster than the rest of us were ready. He found that frustrating as he knew he could do most of the work quicker if he did it on his own. I did my best to help him to see the idea of the project was as much about team work as developing your own skills. Attendance at meetings Less than half – usually because he believed he knew more than the rest of us but also he was trying to get ahead on his other work. Creativity High. He really is a wizard of a programmer and we all could have learned a lot from him. Shame he was not as approachable as the others Work rate High. Despite not attending many meetings he always had the work done when it was needed and usually ahead of time How did they perform as a team member He did not seem a team player at all during most of the term but when it came to the Open day he came in to his own, making sure we were all ready to answer questions. As Albus said he did work out well in the end.