Project Planning
Large courses are divided into several teams so that each team has ten to forty members. Each team has a lecturer or a tutor as their leader. The lecturer prepares the course defining learning goals due based on personal convictions. Sometimes learning goals are predefined because of an encompassing study plan.
For each team a desired system is defined as a vision document. Each team is set the task of realizing as many features of the desired system as possible. The work is finished when every student has worked a fixed total number of man hours - a figure agreed at the beginning of the course. The course is not finished by a milestone, that enforces a predefined feature set, but with a checkpoint.
At course start the following initial activities are important:
- the definition of the desired systems
- the definition of the desired artifacts
- the development of the system architectures
- optionally, the development of architectural spikes
Typically the lecturer defines the desired systems, artifact sests, system architectures and implements the spikes in the project planning phase. However, in advanced courses some or all of these task can be done by the students during the micro process.
In EASE, task planning is artifact-oriented. Desired artifacts are defined, e.g. analysis artifacts, design artifacts and implementation artifacts. In contrast to the theory of stage-wise or waterfall-like software management, EASE assumes that different artifact sets are developed simultaneously from the outset - simultaneous improvement. EASE is deliberately not prescriptive at the level of engineering activities in order to avoid micro management. Instead it is designed to be an instructive challenge for the students. They must find the tasks that contribute best to progress on their own.
The definition of the artifacts is accompanied by choosing technologies and techniques and by developing a system architecture. It is a good practice to develop an architectural spike for this purpose. An architectural spike is a prototype system which realizes just one or a few representative use cases of the desired system. All the technologies on which a chosen system architecture is based are used. There are subtle differences between the reasons for architectural spikes in EASE and those found in practice. The purposes of a spike in practice is estimating risks associated with a particular architecture. In a software course a spike solution can be used to present the chosen architecture and technologies to the students. It serves as both start point and reference point during the rest of the course. The spike solution must consequently avoid encompassing unnecessary features and exhaustive functionality. Using a spike this way has the following benefits
- "in a nutshell" - the students understand the architecture as a whole.
- "jump start" - the students have early success in handling technology.