Introduction

Software Engineering Large Practical

Today's Lecture

  • Today I will discuss:
    • General introduction, make sure you are all in the right place
    • Context for the practical, timing and deadlines
    • Some further constraints
    • Some points to consider when making your proposal

Organisational Matters

Restrictions

  • The Software Engineering Large Practical is a third-year undergraduate course. It is only available to third-year undergraduate students.
  • The Software Engineering Large Practical is not available to visiting undergraduate students, or to fourth-year undergraduate students and MSc students, who have their own individual projects.
  • This practical cannot be taken in combination with the Computer Science Large Practical or the AI Large Practical.
  • See the Degree Programme Tables (DPT) in the Degree Regulations and Programmes of Study (DRPS) for your degree for clarification.
  • If you are in any doubt you should see your PT as soon as possible

Context

  • So far most of your practicals have been small exercises
  • Next year, you will undertake an honours project
  • This practical represents something in between those
  • It is larger and less rigidly defined than your previous course works
  • It is more rigidly defined and smaller than your honours project
  • The SELP tries to prepare you for
    • The System Design Project (in the second semester)
    • The Individual Project (in fourth year).
  • But note that it still represents something of a contrived development environment with respect to real-world software development projects

How much time should I spend?

  • 100 hours, all in Semester 1, of which
  • 8 hours of lectures
  • 92 hours practical work, of which:
    • 70 hours non-timetabled assessed assignments
    • 22 hours private study/reading/other

How much time is that really?

  • There are 13 weeks remaining in semester 1 (Weeks 2 to 14)
  • 7 * 13 = 91 hours
  • So you can think of it as 7 hours per week in the first semester
  • This could be one hour a day including weekends
  • You could work 7 hours in a single day
    • for example work 9:00-17:00 with an hour for lunch

Managing your time

It is unlikely that you will want to arrange your work on your large practical as one day where you do nothing else, but one day per week all semester is the amount of work that you should do for the course.

Scheduling work

Course lecturers have been asked not to let deadlines overlap Weeks 11-14 because students are expected to be concentrating on their large practical in that time.

The Software Engineering Large Practical Requirement

  • The requirement for the Software Engineering Large Practical is to create a working web site
  • There are some restrictions:
    • There should be some notion of user account
    • There should be a ranking of user accounts, which means that in some way your website represents a kind of competition
    • It should involve an amount of work commensurate with 70 hours of work

The Software Engineering Large Practical Requirement

  • In the first part of the practical you will propose the purpose of the website
  • In the second part of the practical you will deliver an implementation of your proposal
  • You need not have an instance open to the world, simply allowing me to run your web-server on localhost and access it there is sufficient.

The Software Engineering Large Practical Requirement

Suggestion: Turn based game

  • Turn based games lend themselves well to being played over a web site
  • Chess, Go, Backgammon, etc.
  • You could increase the interest in this by implementing simultaneous moves
    • In which both players move without seeing their opponents move first
    • Obviously some rule modifications may be needed, for example if they move to the same position
  • The ranking here is relatively obvious but could be done to a high level of sophistication

The Software Engineering Large Practical Requirement

Suggestion: Travel Log

  • A travel website for people to record the places they have visited
  • Ranking could be done on number of places visited or miles travelled
  • Could give weighted points, for places which are not commonly visited
    • You may think how to verify someone's travels, cheaters would not gain much, but might mess up everyone else's rankings.
    • GPS or location could potentially be used

The Software Engineering Large Practical Requirement

Suggestions

  • But I am hopeful you can come up with your own ideas which you are far more likely to be interested in
  • If you are a user, you will increase your odds of implementation success
    • This is a general rule, not one limited to this practical or coursework in general

Deadlines

The Software Engineering Large Practical is split in two parts:
  • Part 1
    • Deadline: Thursday 16th October, 2014 at 16:00
    • This is the proposal for what you will do
    • Part 1 is zero-weighted: it is for feedback.
  • Part 2
    • Deadline: Thursday 18th December, 2014 at 16:00
    • Part 2 is worth 100% of the marks.

Scheduling work

  • It is not necessary to keep working on the project right up to the deadline.
  • For example, if you are travelling home for Christmas you might wish to submit the project early.
  • In this case you need to ensure that you start the project early.
  • The coursework submission is electronic so it is possible to submit remotely.

Early submission credit

  • 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).
  • The early submission deadline is thus: Thursday 11th December, 2014 at 16:00
  • Work submitted less than a week before the deadline does not qualify as an early submission, and the mark for this work will be capped at 90%. Thus, the mark may be 90%, but it may not be higher than this.
  • Regardless of when it is submitted, every submission is assessed in exactly the same way, but submissions which attract a mark of above 90% which were not submitted early have this mark brought down to 90%.

Early submission credit

Question:
Can I submit both an early submission version and a version for the end deadline and have the marks for whichever is highest?
Answer:
No. Before the early submission deadline you have to choose whether or not you are going to hope for a mark above 90% then, or have an extra week to accumulate more marks up to 90%. The submission marked will be the latest one made before the deadline. Hence if you submit both before and after the early submission deadline, only the last submission will be marked and it will be capped to 90%.

Extensions

Estimating

  • One of the most challenging aspects of software development is estimation
  • Unfortunately I do not have the time to go into the reasons for this nor some of the mitigation approaches
  • But if there is time at the end of today's lecture we may try a quick estimation quiz, just for fun

Estimating

  • Often we are asked to estimate how long a given piece of work will take
  • Since we are terrible at this, one alternative is to choose a time and estimate how much can be done in this time
  • This is essentially what you are doing in this practical, the time is set, the amount of work is not
    • Hint: Try to choose something which can be expanded to fill the time if there proves to be too much of it

Estimating

  • It may seem harsh to ask you to estimate your own amount of work to do
  • This is realistic, you are often asked for an estimate of how long a given piece of work will take, either by a customer or a manager
  • Naturally if you propose too much you will miss your deadline, but equally if you propose too little you risk being undervalued by whoever is asking for the estimate
  • To make things a little easier on you, I will provide feedback on your proposal regarding whether a completion is likely to be too much or too little work

Part One

Feedback

  • By default you will receive some feedback about your proposal
  • This will mostly be concerned with whether or not I think it represents an appropriate amount of work
    • Hint: The more detailed your proposal is the more accurate my feedback about this may be
  • By default, that is all I will comment on. However, you are free to illicit feedback on anything you wish

Part One

Feedback

For example, you might:
  • Ask more specifically about aspects of your proposal
    • “Does my ranking scheme make sense?”
    • “Do you think this scales well to many users?”
    • “Is my proposal all or nothing?”
  • Submit work other than your proposal and ask for feedback on that:
    • Some code and ask for specific feedback about that
    • Your commit messages in your repository so far
    • Suggest which language and technologies you intend to use and ask for some comment on those

Part One

Feedback: Be Specific

Very BAD!
  • “What language should I use?”
  • “Is my design okay?”
  • “What do you think of my code so far?”

Part One

Feedback: Be Specific

Better
  • “I have started to use Node.js because this will mean I can write both backend and user-interface code in the same language. Otherwise I may have to re-implement the rules for valid chess moves, does this reasoning make sense?”

Further Constraints

  • There are further constraints listed in the coursework description
  • I will briefly mention these now
  • But of course you should read the coursework description
  • HERE IT IS!!!

Constraints

Implementation Language

  • You may choose whichever programming language(s) you deem most suitable. However:
    • Your application should compile and run on DiCE
    • Here is an obvious list of languages which should work on DiCE without any problems: C, C++, C#, Haskell, Java, Python, Objective-C, Ruby. However care should be taken with versions.
    • If you wish to use something else it would probably be prudent to ask me first.

Constraints

Implementation Language

  • You may choose whichever programming language you deem most suitable. However:
    • It is up to you to choose suitable languages
    • Your choice will not be judged, however if you choose poorly, this will not be reflected in more lenient marking.
    • Whatever choice you make, you must live with

Constraints

Source Code Control

  • For this project source code control is mandatory
  • You will have to use the git
    • This is somewhat realistic
    • Any project you join will likely already have some form of source code control set up which you will have to learn to use rather than any system you might already be familiar with
    • See the git homepage

Constraints

Source Code Control

  • The practical is not looking for you to become an expert in git
  • You will not need to be able to perform complicated branches, merges or rebasing
  • This is, afterall, an individual practical
  • What is key, is that your commits are appropriate:
    • Small frequent commits of single units of work
    • Clear, coherent and unique commit messages

Constraints

Source Code Control

Getting Started
Do this today.
  $ mkdir selp # You do not need to call it 'selp'
  $ cd selp
  $ git init
  $ editor README.md
  $ git add README.md
  $ git commit -m "Initial commit including a README"
  

Constraints

Code Sharing Sites

  • Code sharing sites are a great resource but please refrain from using them for this practical. This is an individual practical so code sharing is not allowed. Even if you are not the one benefiting.
    • This is a bit of a shame, but again somewhat realistic
    • It is at least somewhat likely that in the future you will be unable to publicly share all of the code you produce at your place of employment.
  • That being said, after the deadline (and any extensions) you are more than welcome to share any of your own code you like anywhere you like

Part One

Your Proposal

Your proposal should be:
  • Clear and concise but specific
  • Written in a human readable form, I suggest Markdown (or CommonMark), HTML, or PDF
  • Like the rest of your project, under source code control
    • Hence a plain text source such a Markdown or LaTeX may help you

Part Two

Implementation

  • For part two you submit the implementation of your proposal

Part Two

Report

  • In addition you should submit a report
  • In this report you can detail any changes made to your proposal and why
  • You may also point out missing elements and how your design/code base allows such elements to be added/modified easily
  • For example, you will not be judged for poor graphic design skills, but your report can specify how the look of your website can be modified independently of the implementation.

Part One and Part Two

  • For part one, submit your proposal
  • For part two, submit your implementation and report
  • These are all specified in the coursework handout

Coursework Handout

Discussion Forum

  • A discussion forum has been setup, please use this to discuss aspects of the course.
  • https://discuss.inf.ed.ac.uk/?q=forum/5
  • I will periodically check for questions and provide answers where I can

Any Questions

Time for an Estimation Quiz?