Shaman is the technical incarnation of URDNet, a Distant Learning project, initiated at l'Université René Descartes, Paris 5. It is an ambitious project, and, for this reason, a first "round" should give Decision Makers an overview of :

• Satisfied needs
• Technical feasibility
• Previsional costs

The intent is not to provide a production-ready project at the end of the first round, but :

• A set of demos to show product capabilities
• The basis of a framework for an extensible product
• Enough specifications to let other people continue the work (the lead developer may not stay after the first "round")

We must confess that the project was not really defined at startup. Before asking what should be done, we were bound to ask how could we know what should be done. The answer to the last question defined the project approach, according that :

• End-Users are teachers and students, who don't have experience of expressing their needs for specifying software.
• Many (Open-Sourced and free) components are available on the market. They do near everything we can dream of. The only challenge is to make them working together.

  "Component" means here "some reusable software stuff". In that perspective, a Web server is a component.

It was clear that our End-Users were not ready for a top-down approach. The problem is too open, they don't know what's feasible, they don't have a clear vision of the whole problem (especially when related to system, security or administrative aspects).

An Xtreme-Programming approach (pure incremental) was not the solution, neither. It would require constant user feedback. It would not solve the problem of getting a system overview at the early development stage. And the first deadline was too close for delivering even a near-operational system.

The solution came for studying risk.

Since integrating components is, at the same time, a Good Thing (for the benefits of software reuse) and a dangerous thing (sometimes, it's hard to make them cooperate), there was an inherent risk on this side.

The system was planned to be evolvable (with new standards support, new features, etc)."Evolvable" means nothing by itself, if it is not backed by a careful design. Adding flexibility to a system has a cost, and there is always the risk of not adding flexibility where it should.

Don't expect a User to tell you what should (really) be flexible.

For the reasons explained above, we decided to base our project's approach on technical architecture. "Approach" is the idea behind questions like :

• Priorities : what we do first, what to validate in first
• How to find Use Cases
• How to target audience for project documentation
• How to define what could evolve

This approach combines the major advantages of offering the Best of breed of software components we know, and adressing the major problem of requirement evolvings at early stage.

Determination of project phases has been an incremental process for about one month, ran in parallel of architectural decisions.

Insight is the subproject which is the "hard part" of Shaman. The Logicsheet is its API, used by Legend (the part designed to embrace feature changes). More details on those subsystems collaboration can be found in architecture document.

Here is the template of our priority matrix :

It takes care of two aspects, which are reflected by two dimensions :

• Providing the most useful features from End-User point of view ASAP
• Exploring the most risky technical options first.

Time is not the critical resource. The critical resource is time at the start of the project. The sooner a feature is implemented, the sooner design can be corrected. The problem is that, we cannot implement everything at the start of the project.

We do not plan to set a schedule for tasks during the first round, because of our lack of experience on the software platform(s). Moreover, we do not have the time to keep a schedule up to date. We deliver what we can, in respect of established priorities.