The course will be taught by Henrik Bærbak Christensen.
The dSoftArk course covers techniques in software engineering and architecture that are in daily use in industry to produce flexible and reliable software.
The course has a primary and secondary focus:
Key techniques are: Test-driven development, compositional design, test doubles, design patterns, frameworks, and systematic black-box testing techniques.
Also dSoftArk's mandatory project requires you to utilize modern tools that are widely used in industrial practice, defaulting to Ant, IntelliJ, and Git.
dSoftArk in particular extends knowledge and skills you have acquired in dIntProg and dProg2.
dSoftArk is rooted in a software engineering tradition rather than a (mathematical) computer science tradition. Thus - no QEDs - sorry to you folks who like knowledge that is provably true :(. In contrast, the techniques in dSoftArk are justified by empirical means: they have shown that they work in industrial practice so many times that we tend to believe they are valid.
There are 2+2 lectures every week. The two lectures Thursday and first lecture Monday are presenting new material (curriculum) while the last lecture Monday is dedicated to going over aspects of the mandatory project (reflections/no new stuff introduced).
There are 3 hours laboratory workshops every week for the classes. They are called "TØ" by the scheduling people, but in dSoftArk they are by no means 'theoretical'. In the lab the teaching assistent will discuss issues and assignments from the mandatory project, as well as act as consultant on your work.
TAs or I will hang around in the Ada Cellar and helping you out in the study cafe. The time we are there are:
Mandag 16-17, tirsdag 9-10, onsdag 14-15, torsdag 16-17 og fredag 14-15
Isolated exercises are (to a large extend) replaced by a single, large, project that you are going to develop in groups in an agile and test-driven development process. Each week there will be an assigment, a sprint, that adds features (and academic reflections) to the project.
The group will hand in the result using your Blackboard login, and will be reviewed and accepted/rejected by the teaching assistent.
The mandatory project will be HotCiv which is a boiled down Civilization game. However, the focus is not on getting all the proper functionality in place---the focus is on getting the proper architecture in place to handle a lot of variable game behaviour.
Thus you will be awarded for proper flexible and reliable designs that however may skip some functional requirements.
And you will NOT be awarded for a fully functional game with an inflexible and unreliable architecture
Your process is important. The best configuration is a three person group that do same-time, same-location work in three roles:
Take turns of about one half hour - then change roles so you all get experience in all roles!!!
In a two person group, one person must take on the last two roles.
Generally, as each week's work span several exercises to be handed in separately, I strongly advice handing in as soon as you have "clean code that works", so you can get feedback quickly.
For the ultimate deadlines for each week and for each class, see the delivery plan.
Morale: Start well ahead of the dealine in order to get feedback early.
The mandatory program consists of a set of exercises per week, all about the central project of the course. A solution proposal for the mandatory exercise(s) must be defined in groups of two to three persons.
The mandatory exercise will be a topic for discussion at the laboratory with the TA and has to be handed in for approval.
The delivery deadline can be viewed in the Blackboard system for each class. I will spend all or part of the last Monday lecture on aspects of the hand-ins.
The hand-in must conform to a number of rules: