Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Engineering Large Practical coursework

1,295 views

Published on

A description of the requirements and the assessment and marking for the Software Engineering Large Practical.

  • Be the first to comment

  • Be the first to like this

Software Engineering Large Practical coursework

  1. 1. Software Engineering Large Practical Stephen Gilmore School of Informatics Wednesday 26th September, 2012 Stephen Gilmore Software Engineering Large Practical
  2. 2. Summary The requirement for the Software Engineering Large Practical is to create an app implemented in Java and XML for the Android phone. The purpose of the app is to develop a prototype system to help students to decide who they should vote for in student elections. Stephen Gilmore Software Engineering Large Practical
  3. 3. Outline In a student election, candidates nominate themselves for an office. For EUSA, these offices include President, Vice President (Academic Affairs), Vice President (Societies and Activities), Vice President (Services), and others. Candidates reflect on the issues which are important to them and make promises to the student body on what they will do about these issues if elected to office. Candidates can submit photographs of themselves and election statements explaining what they want to achieve in the hope of persuading people to vote for them. The photograph and statement are made available on the election website. Stephen Gilmore Software Engineering Large Practical
  4. 4. Details Photographs are made available in JPEG format with a maximum size of 2Mb. Images are at a resolution of 120 pixels wide by 150 pixels high. The number of words allowed in the election statement varies by office but is never more than 450 words. Stephen Gilmore Software Engineering Large Practical
  5. 5. Reducing environmental impact The traditional method of making and hanging posters for election candidates has been criticised as being environmentally unfriendly, aesthetically unpleasing, and somewhat old-fashioned. Posters only give a superficial impression of a candidate’s priorities because they only contain a slogan, meaning that voters must look elsewhere for more details. Stephen Gilmore Software Engineering Large Practical
  6. 6. The idea: an app In order to try to address these criticisms, the University of Edinburgh is considering investing in an app for the Android phone which will allow matriculated students of the university to: read about candidates standing for election, support the decision-making process, cast votes, and – if they wish to – share the news that they have voted. Stephen Gilmore Software Engineering Large Practical
  7. 7. Information on candidates The information on candidates is obtained by download of an XML document. This document specifies the candidates standing for election, their policies and other relevant details. The app should allow the user to browse this information and present it in a clear, readable display. Stephen Gilmore Software Engineering Large Practical
  8. 8. XML document http://www.inf.ed.ac.uk/teaching/courses/selp/ elections/election.xml Stephen Gilmore Software Engineering Large Practical
  9. 9. Interface mockup Stephen Gilmore Software Engineering Large Practical
  10. 10. Rating candidates In order to help with the decision-making process, users of the student voting app should be able to rate election candidates on a scale from zero to five stars and, if they are certain not to vote for them, to delete candidates entirely. The app should be stateful in the sense that ratings and deletions are preserved between sessions with the app. Stephen Gilmore Software Engineering Large Practical
  11. 11. Voting When the user has decided who to vote for they can use the app to send a private email to informatics.android@gmail.com with a carbon copy (CC) to matricno @sms.ed.ac.uk where matricno is the matriculation number of the student who is voting. This email should make clear who is being voted for, and for which office. It is possible to vote more than once for an office: later votes will override earlier ones. Stephen Gilmore Software Engineering Large Practical
  12. 12. Social aspects Once they have voted, users have the option to send a public tweet to @InformaticsAndr announcing that they have voted (but not who they have voted for). This tweet should be labelled with the hashtag #becounted Stephen Gilmore Software Engineering Large Practical
  13. 13. Informatics Android Twitter account https://twitter.com/InformaticsAndr Stephen Gilmore Software Engineering Large Practical
  14. 14. Summary (1/2) It should be possible for the user to specify their matriculation number in the app. It should be possible to download the XML database of candidate information from the server into your app. It should be possible to browse the candidate information and read election promises and election statements. It should be possible to rate candidates using a star rating system. It should be possible to delete candidates from the local copy of the candidate database. Stephen Gilmore Software Engineering Large Practical
  15. 15. Summary (2/2) It should be possible to vote for candidates from the app. This sends an email to informatics.android@gmail.com A carbon copy is sent to the user at their SMS email address It should be possible to send a tweet after voting. A tweet is sent to @InformaticsAndr This tweet should be labelled with the hashtag #becounted Stephen Gilmore Software Engineering Large Practical
  16. 16. Extra credit Additional credit will be awarded for additional useful features which are not on the above list. Thus, if you have time remaining before the submission deadline and you have already met all the requirements listed above then you can attract additional marks by being creative, conceiving of new features which can helpfully be added to the application, and implementing these. If you have added additional features to your implementation in order to attract extra credit then you should be sure to document these features if they are not immediately evident from normal use of your application. Stephen Gilmore Software Engineering Large Practical
  17. 17. AssessmentStephen Gilmore Software Engineering Large Practical
  18. 18. Early submission credit In practical software development, timing and delivery of completed applications and projects can be crucial in gaining a commercial or strategic advantage over competitors. Being the first to market means that your product has the opportunity to become known and similar products which come later may struggle to make the same impact, simply because they became available second. In order to motivate good project management, planning, and efficient software development, the SELP reserves marks above 90% for work which is submitted early (specifically, one week before the deadline for Part 2). To achieve a mark above 90%, a practical submission must be excellent in all technical, functional, and aesthetic aspects and in addition to this it must be submitted early. Stephen Gilmore Software Engineering Large Practical
  19. 19. Assessment criteria (1/3) This practical exercise will be assessed in terms of the completeness of the solution to the problem, the quality of the Java and XML code produced, and the ingenuity and craftsmanship which have gone into designing a good and robust solution to the problem. Stephen Gilmore Software Engineering Large Practical
  20. 20. Assessment criteria (2/3) For example, all other things being equal, an app which allows users to rate and delete election candidates should expect to receive more marks than an app which does not allow this. A more complete solution will get more marks. All else being equal, an app which when loaded into Eclipse reports static analysis errors (called “Java Problems” in Eclipse and displayed in the Problems View) should expect to attract fewer marks than one which does not. Sloppy development style ignoring compiler warnings will lose marks. Stephen Gilmore Software Engineering Large Practical
  21. 21. Assessment criteria (3/3) Additionally, all else being equal, an app whose code contains examples of poor Java programming style (such as empty catch statements) should expect to attract fewer marks than an application in which Java exceptions are handled gracefully. Poor programming style will lose marks. Finally, all else being equal, an application which contains logging statements (using the class android.util.Log and generating calls to Log.d or other methods) would expect to attract more marks than an equivalent application without logging (because the version with logging is more maintainable). Including logging will gain marks. Stephen Gilmore Software Engineering Large Practical
  22. 22. MarkingStephen Gilmore Software Engineering Large Practical
  23. 23. Marking (1/4) 1. The XML file specifying the information about the candidates is updated to include a previously-unseen candidate to be examined during testing. Submissions which have hardcoded in the candidate information will lose marks because they will not include the information about the previously-unseen candidate. 2. The accompanying documentation is read for instructions on how to use the app. Submissions with insufficient documentation will lose marks here. 3. The Eclipse project is imported into an instance of the Eclipse platform and inspected for errors or warnings (“Java Problems”) Submissions with errors or static analysis warnings will lose marks here. Stephen Gilmore Software Engineering Large Practical
  24. 24. Marking (2/4) 4. The project is launched as an Android application and run on the emulator Submissions which fail to install or launch will lose marks here. Requiring files to be pushed onto the emulator will lose marks here. 5. The app is evaluated in user mode by browsing for content. Submissions which have insufficient content will lose marks here. 6. Evaluation continued by rating and deleting candidates. Submissions which fail to rate or delete candidates will lose marks here. Producing “Application has unexpectedly quit” errors will lose marks here. Stephen Gilmore Software Engineering Large Practical
  25. 25. Marking (3/4) 7. Emulation is terminated and then restarted. Submissions which fail to retain ratings or deletions will lose marks here. 8. Other additional features of the application will be explored. Voting for candidates will be tested here. Tweeting will be tested here. Submissions with useful additional features will gain marks here. 9. Usability and aesthetics of the application will be explored. Organisation and readability of the application will be evaluated here. Layout, colours, fonts and visual design will be evaluated here. Stephen Gilmore Software Engineering Large Practical
  26. 26. Marking (4/4) 10. The Java source code will be inspected for good programming style. Submissions with insufficient logging will lose marks here. Submissions with too few comments will lose marks here. Submissions with blocks of commented-out code will lose marks here. Stephen Gilmore Software Engineering Large Practical
  27. 27. Project management Stephen Gilmore Software Engineering Large Practical
  28. 28. Managing a project Managing a project involves a range of skills. You need to: identify roles and responsibilities; carry out a range of tasks; be aware of deadlines; plan and anticipate problems; and deliver a product. Stephen Gilmore Software Engineering Large Practical
  29. 29. The Developer role Studies the problem; determines a solution. Installs software, APIs and frameworks. Reads documentation; learns about tools. Writes code; debugs code; tests code. Writes documentation. For the Software Engineering Large Practical You have been assigned this role. Stephen Gilmore Software Engineering Large Practical
  30. 30. The Project Manager role Identifies work which is to be done. Sets parameters such as platform/architecture/language. Sets priorities. Communicates priorities. Doesn’t install software on your machine. Doesn’t fix bugs in your code. For the Software Engineering Large Practical I have been assigned this role. Stephen Gilmore Software Engineering Large Practical
  31. 31. Plan for the unexpected In planning a project you should build in some contingency to deal with problems which could delay your progress. You don’t know which problems will occur, but it would be surprising if no problems occurred. So, consider problems which could happen . . . . . . the predictable unpredictables. Stephen Gilmore Software Engineering Large Practical
  32. 32. Predictable unpredictables You could catch flu — a flu epidemic is predicted this year. Laptop theft — if your laptop was stolen you would lose work. Laptop failure — failures can be irreparable with no warning. Broadband failure — your broadband service could fail. Strikes could happen — staff or students elect not to work. It could snow — labs and facilities could be closed or inaccessible. Total cost due to predictable unpredictables Events such as the above could delay you by a week. Stephen Gilmore Software Engineering Large Practical
  33. 33. Managing deadlines Most major projects have interim deadlines, milestones or deliverables. Missing interim deadlines, milestones or deliverables usually incurs a penalty of some kind. Stephen Gilmore Software Engineering Large Practical
  34. 34. Types of deadlines There are different types of deadlines: soft deadlines which are not usually specified precisely — “this should be completed by Christmas”; and hard deadlines which must be specified precisely — “Part 2 of the Software Engineering Large Practical is due on Thursday 20th December, 2012 at 16:00”. Stephen Gilmore Software Engineering Large Practical
  35. 35. Dealing with hard deadlines Factor in the potential problems with predictable unpredictables by taking the hard deadlines and subtracting the estimated delay (we are considering this to be one week). Part 1 is due on Thursday 25th October, 2012 at 16:00. try to complete this by Thursday 18th October, 2012 at 16:00. Early submission deadline for Part 2 is Thursday 13th December, 2012 at 16:00. try to complete this by Thursday 6th December, 2012 at 16:00. Part 2 is due on Thursday 20th December, 2012 at 16:00. try to complete this by Thursday 13th December, 2012 at 16:00. Stephen Gilmore Software Engineering Large Practical
  36. 36. Backing up your work Secure copy (scp) You should backup your code to your DiCE account. It is possible to copy an entire folder to your DiCE account with just one command. If user is your username (e.g. s1234567) scp -r ForumApp user @student.ssh.inf.ed.ac.uk:/home/user will copy the folder ForumApp to your home directory. Alternatives Windows solution WinSCP Cloud-based solution Dropbox — https://www.dropbox.com Hardware solution Memory stick/CD Caution GitHub Free access is open source—anyone can copy your files Stephen Gilmore Software Engineering Large Practical
  37. 37. Task management Applications which allow you to compile lists and categorise tasks can be useful when working on a large project. Several applications allow you to set dates and deadlines on tasks, set levels of importance and arrange lists to see tasks which need to be done in the next few days. These are now typically cloud-based solutions which let you see the same information on the Web, on the desktop and on mobile devices. Stephen Gilmore Software Engineering Large Practical
  38. 38. Task management: Wunderlist Stephen Gilmore Software Engineering Large Practical

×