Software Engineering Large Practical coursework

Software Engineering Large Practical

Stephen Gilmore

School of Informatics

Wednesday 26th September, 2012

Stephen Gilmore Software Engineering Large Practical

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.


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.


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 oﬃce but is never more than 450 words.


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
superﬁcial impression of
a candidate’s priorities
because they only
contain a slogan,
meaning that voters
must look elsewhere for
more details.

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.


Information on candidates

The information on candidates is obtained by download of an
XML document.
This document speciﬁes 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.


XML document
http://www.inf.ed.ac.uk/teaching/courses/selp/
elections/election.xml


Interface mockup


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 ﬁve 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.


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 oﬃce. It is possible to vote more than once for an
oﬃce: later votes will override earlier ones.


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


Informatics Android Twitter account

https://twitter.com/InformaticsAndr


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.


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


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.


Assessment


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.


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.



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.



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.


Marking


Marking (1/4)

1. The XML ﬁle 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 insuﬃcient 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.


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 ﬁles 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 insuﬃcient 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.


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.


Marking (4/4)

10. The Java source code will be inspected for good programming
style.
Submissions with insuﬃcient 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.


Project management


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.


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.


The Project Manager role

Identiﬁes 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 ﬁx bugs in your code.

For the Software Engineering Large
Practical
I have been assigned this role.


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.


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.


Managing deadlines

Most major projects have interim deadlines, milestones or
deliverables.
Missing interim deadlines, milestones or deliverables usually
incurs a penalty of some kind.


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”.


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.


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 ﬁles


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.


Task management: Wunderlist


Software Engineering Large Practical coursework

More Related Content

What's hot

Viewers also liked

Similar to Software Engineering Large Practical coursework

More from Stephen Gilmore

Recently uploaded

Software Engineering Large Practical coursework