The Software Engineering Large Practical exposes students to the problems that arise with the design and implementation of large scale computer systems, and to methods of coping with such problems.
Further details can be obtained by visiting the drps page for the course.
The coursework will be detailed further in the lectures.
The coursework handout will become available on the 17th of September 2014.
More generally this seems to be asking, how you make sure the dependencies you install locally are available for me. Of course if you install them to your DiCE account, they will not be available for me. However, by installing them into your DiCE account, you are demonstrating that they are installable using DiCE.
The requirement is because; what I do not want is for me to attempt to run your web server only to find an error, caused by a missing dependency, which upon further investigation is difficult or impossible to install on DiCE, because you have been developing under Windows/Mac or something else.
What I need from you is a set of instructions on how to install the dependencies and run your web server. You should be able to write these instructions in an executable form (that is, a script). So I should be able to install the dependencies with a single command and run your web server with a single command.
If you want a really concrete requirement then aim for this: "You
should have two scripts in your submission directory, install.sh and
run.sh, I should be able to install and run your web server by simply
executing the following command at the prompt:
$ source install.sh && source run.sh"
If you cannot manage this, then you should ask yourself why not? If you cannot automate installation and execution of your software then you have a very fragile development environment.
Bonus points if you manage to install things to the current directory, so that it does not eat into my home directory space, but that is not a requirement.
There is a bit of tension here, I basically wish for you to develop some "large" piece of software and demonstrate that you are capable of doing this in a maintainable manner, producing sound code with a sound development process. Additionally I'm keen for you all to be engaged with what you are doing rather than uselessly spending your time coding for some made-up need. You could obviously do this whilst developing an app rather than a browser-based front-end. However, in addition, you are supposed to be demonstrating that you can work within the constraints imposed upon you. You are unlikely to be in a situation where you get to develop whatever you want, using whatever technologies you wish. Sometimes the person paying for the software wants what they want and they may even have good reasons for it, even though you are sure you know better.
So upon reflection you can do this, however, in your final report you should justify why you are not creating an HTML5 based app that the user could use both from a web-browser (on any kind of device) and from a mobile device.
In other words treat the creation of a browser-based interface as a specified requirement. Deviation from that should be done if you have a good reason for it. If you have a good reason, to suggest that the requirement is wrong for the particular problem that you are solving then explain why.
You should of course specify this in your proposal. I would not recommend developing an application without a browser-based interface without stating this in your proposal. Of course, the decision to switch from a browser-based interface may come up during development after your proposal has been submitted. In this case you should be able to justify it well, and it would not hurt to ask via email.
Finally, be extra careful to make sure that your app can be run entirely on DiCE (presumably through an emulator).
Yes you can use third-party frameworks/libraries and are encouraged to do so.
The key issue regarding working on DiCE is not that DiCE is some kind of special environment in which I expect you to only use elements that are installed on DiCE. The point is simply that if it works on DiCE then I will be able to evaluate it. Without being able to compile/run your web server I won't be able to evaluate your work effectively. So installing extra things is perfectly fine, provided they can be installed with minimal fuss.
If you simply provide instructions for installing dependencies in the local directory that is fine. Preferably these “instructions” are a script which I can run with a single command (and if not, you might want to ask yourself why that is not possible).
For example, in answer to the specific question posed by a student, Python
is well supported on DiCE and I do not see you having any difficulty with
providing such an install/setup script. So
pip install -r requirements.txt is
fine, that's a single command. I can handle that.
Care has to be taken not to break the University's regulations.
Firstly you cannot submit work that has already been assessed. Secondly, the time aspect is an important aspect of the project, in particular managing the amount of work to be done in the given time.
That being said, the whole reason I wish for you to make your own proposal is so that you are working on something useful (or at least engaging), rather than uselessly implementing some contrived and made-up set of requirements for something that simply isn't needed, only for the purposes of assessment. Whilst implementing something contrived for the purpose of assessment can be useful, I think for the "large" practical it makes sense to allow you to spend your time more productively.
Hence, if you are clear what currently exists and what work you are doing for this project then I'm keen to allow you to continue working on an existing project.
A couple of points: Firstly, you are going to be marked on your development process. The work you have done so far, should not count towards your grade, but equally it should not count against you. So I won't penalise decisions/actions you have taken before the start of this project. However, naturally, distinguishing the two will be tricky. It would help if you detail anything you are not proud of in the report and specify whether you did this prior to the start of the project or not. Additionally, if you have made poor choices prior to now which impede you in making good choices now, tough luck, you accept that possibility when you work on an existing project. I think that is fair. Secondly, if your project is not hosted under git I suggest you do that now, and tag it as “work pre-SELP” or words to that affect.
In this case I also highly recommend submitting a proposal. One danger is that you take work you have already done and then spend some time on “window dressing”. If you do this, I simply won't have enough evidence of merit to award a high grade.
No. Before the early submission deadline you have to choose whether or not you are going to hope for a mark above 90% now, 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%.
That's a good question. First of all I would suggest coming along to the first lectures of both. You should be able to switch courses up until the end of week one (it's a tad unfortunate that the CSLP will have its first lecture on Friday not leaving much time after that). I should of course also suggest that you speak with your PT, but I'm guessing you already have and they have essentially told you that either is fine.
The two courses do have quite a bit of similarity. In both cases you will be developing some large piece of software (size is relative, we mean large in comparison to the coursework you have done for other individual courses). The difference is what you learn from doing so. The software engineer is concerned with producing a piece of software to satisfy some set of requirements. Often those requirements will not be very well specified and in some cases the correct thing to build will not be known when you start. The focus is on building a piece of software that is fit for purpose and hence can be used by the intended users. The computer scientist on the other hand is likely more interested in finding out some particular fact or facts. They are using the computer to gain insight and hence they may be less concerned with how *others* can use their software provided that their software can answer the questions *they* care about.
Of course in real life, the computer scientist may write more general software. So you may start with a computer program which is capable of, for example, computing your own devised economic model. But you then realise that many other economists could benefit from much of your functionality (suppose it solves a set of differential equations), so you generalise your software a little and you come up with some kind of DSL for inputting the economic model. At this point, you may have some users and you become something closer to the software engineer. Even if your software does not go down this path it is rarely a bad thing to keep your source code well organised and maintainable so that you can update it in the future, if only because you now want to answer a *similar* question to the one before. Additionally you may well have collaborators who either want to use your program or modify your source code.
If I can try to sum up the difference in a short sentence or two, I might try something like this: The SELP is focussed on developing a particular piece of software to fulfil some requirement and as such is more concerned with your development process and the end result. The CSLP is more concerned with using programming skills to investigate some interesting problem or question.
Another attempt might look something like this: The CSLP produces a program that has some desired output from some given input, whereas the SELP has some desired *behaviour*, and this behaviour should be intuitive to the intended user (although that may be another machine).
Just as the computer scientist may turn software engineer, the software engineer may turn computer scientist. The correct behaviour may require the correct computation of some function. For example a smartphone application which acts as a pocket unit-converter must have an intuitive interface, but it must also accurately convert metres into yards, lbs into kilograms etc.
Just as a final note, in theory the Software Engineering Large Practical could be devoted to a project to investigate some aspect of software engineering. However, for this year at least, the course will be centred around applying software engineering principles and practices to the development of some (hopefully interesting) piece of software.
I hope this has not confused more than it has helped but I did not want to simply repeat what you have already read in the DRPS.
Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: email@example.com
Please contact our webadmin with any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh