Posted by XCRI Project Manager at 14/09/2012 15:05:07
The Foundations stage of the project is complete and we’re now entering the development phase. This is an agile project so development is split into a number of stages or iterations. The project is planned so that each iteration delivers a specific set of working functionality. This first iteration is a special case because its goal is to create a proof-of-concept of the whole system to verify that Sits is the right technology platform.
Prototyping is a key part of Atern because it allows you to ‘succeed sooner’.
- Specific design assumptions/hypotheses and the project’s overall direction can be verified with tangible examples.
- Staff can use these prototypes to give detailed and valid feedback throughout the project.
- The process is engaging and collaborative; business users are involved in the development and evolution of the product rather than simply having to use it at the end.
The high-level functional specifications for the prototype system are:
- Means of entering course data (M)
- Means of viewing course data (M)
- Means of amending course data (M)
- Means of producing HTML from course data (W)
- Means of validating course data(C)
The high-level non-functional requirements are:
- An Xcri-Cap feed automatically created from course data (M)
- The Xcri-Cap feed automatically published to a publicaly accessible location (S)
- The system to be supported and maintained within the current University ICT infrastructure (M)
- Individual users are able to enter and access their own data (W)
The letters next to each requirement are a shorthand for priorities determined through Atern’s MoSCoW process (Must, Should, Could and Won’t this time).
Although we’ve chosen to use Sits, we’ve decided against the outline Tribal solution demonstrated at Brunel University’s Sits Assembly in May. Tribal’s module was based upon course approval using programme specifications. Interviews with Marketing staff across the University during Foundations revealed that programme specifications were considered a contractual document and don’t contain the marketing information that Xcri-Cap requires. Using programme specifications would have required a two tier system with additional fields for marketing data maintained separately by marketing (rather than administrative or academic) staff. However, we recognise that the two share data in common and will investigate the possibility of a process for synchronising information between them.
For the proof-of concept we’ll create data entry and management screens using Sits e:Vision Vistas; Sits Standard Report Letters will wrap the course data with Xcri-Cap tags; and a stored procedure will be used to publish the feed publicly.
We’ve arranged for the prototype to be demonstrated at a forthcoming meeting of the Universitys Executive and Professional Development Forum. Staff involved in the administration and marketing of short courses and professional development will be able to see the prototype in use and provide feedback on the design direction. I’ll discuss the feedback and how development’s progressing in the next post.