[Year 12 IT Apps] Evaluation criteria in Design

[Garth, Lucas A]

>>Please: *somebody* stop me going on about evaluation criteria being
>>developed during the design stage of the PSM. I bore MYSELF to death going
>>on about that

OK I'll bite...but feel free to ignore a fairly wordy response.

Most evaluation criteria (or at least success critieria as students would most likely define it) shouldn't be completed in Design. One would logically think that it's an Analysis task: scope out the solution and form Business Requirements Statements (BRS). The problem then arises: well what else do we do in Design if not "Design Solution"?  Can't have a phase with just one activity.

Thankfully there are plenty of other Design phase activities that could be included.  Like such as (Miss South Carolina reference):
- Develop Service Level Agreements (defining these agreements are a critical part of any project) - when we talk about evaluation criteria we can refine it to include the formalising of all agreements between customer and solution provider (taking the solution BRS and creating measurable KPIs)
An example of an SLA is to say we want 99% up time from the system following project implementation of security features - if not achieved there are consequences to project team by way of refunds/warranties.
- Build data models (but we don't want to go into data flow diagrams again...)
- Plan development testing - this is crucial in project delivery.  Planning testing before coding increased the chances that testing of core functionality would be completed well before UAT (and the chance for a business user to get rightly annoyed at the lack of quality in development of their solution)

In design phase, teams can turn the BRS / Scope of solution into a workable design by creating not just the physical/logical design data models but also through SLA/OLAs create testing plans that relate directly to the business requirements.  One such method was called V model testing (http://istqbexamcertification.com/what-is-v-model-advantages-disadvantages-and-when-to-use-it/) - and though it was not flawless it was certainly helpful in keeping customers in good communication with projects and the delivery of high quality results.

I digress....
If there's one thing that gets my goat about the whole PSM it's that there's no part dedicated to implementation, which I view as even more important when deploying solutions on a web (i.e. 24/7/365.25) platform.  Many projects that I worked on required a clearly defined window of implementation where the database was updated, the front-end modified, the user accounts created, etc. This cannot be defined as Modifying (coding), Validation (should have already been effectively covered in form design) nor any form of Alpha or Beta/UAT.  Documentation forms a PART of implementation, but only a small one.  I can understand why Implementation isn't heavily covered in what is intended to be simple for Year 11/12 students to understand, but ignoring it completely from a project cycle is plain wrong.  So says a support analyst who had to give birth to projects that had very rocky implementations.
</rant>
Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.