Marking Guidelines for MVK Projects. MVK12. Version 6.2 (PPD, URD, RURD, ADD and software demo)

Transcription

1 Marking Guidelines for MVK Projects. MVK12 Version 6.2 (PPD, URD, RURD, ADD and software demo) Final Grade formulas: MVK DD1365 Grade = 33% PPD + 66% URD. Bachelor s Thesis DD143X Grade = ADD + RURD + RADD + Software Demo. (In addition, in order to pass DD143X, a final project report must also be submitted) 1. PPD I would suggest the following grading guidelines for the PPD. Recall that the overall (1) The most important part of the document is background research about similar or related products. If this has not been carried out satisfactorily the grade will be U. This is difficult to quantify, but 1 or 2 related products would be a minimum. Another aspects of the document is (2) the revised product description. There must be more detail in the PPD (relative to the original project description) and it should be restated in the students own words, otherwise the grade will be U. The third important aspect of the PPD is (3) the group description. There must be some reasonably detailed discussion of the skills baseline of the group, otherwise you should award a U. If all these three components are present, and the other components of the document (see the template), are covered at least to some extent, then you can award a G. For a higher grade (VG), you could either reward a very well written survey of related products (say 3 or more products), or a very good (detailed) description of the application to be developed. In this case there should be clear evidence of significant interaction with the client. Some understanding of the clients business model is also a bonus. There should also be a set of recent project meeting minutes. This is not a graded component, but if they are missing they must be submitted before a grade can be returned.

2 2. URD I would suggest the following grading guidelines for the URD. Recall that the overall Grade G minimum requirements 1. The URD exactly follows the PSS-05 standard in format, and mostly follows the PSS- 05 format in content (i.e. there may be one or two items that are in an inappropriate section, according to the online standard we use.) 2. There is a data model which has a reasonably detailed definition using some clear format. Possible formats include UML class diagrams, data dictionaries, entity relationship diagrams, XML models, but are not limited to these. 3. There is a clear holistic (birds-eye) view of the product requirements in Chapter 2 and this is consistent with the detailed functional requirements in Chapter There is a clear identification of the different types of end-users of the application (for example as actors) and some knowledge of the differing needs and IT skills of each type. 5. There is a collection of detailed functional and non-functional requirements presented in chapter 3. Each of these is presented using the requirement template in the correct way, and with all relevant template sections filled in, including need, priority and verifiability. The verifiability criterion for each functional and performance requirement shall be credible with appropriate detail. Each requirement is clear and unambiguous. There are no obvious gaps in the requirement set. The requirements are not obviously inconsistent. All five of the above conditions must be satisfied. Grade VG minimum requirements In addition to the requirements for G some suggestions are: 1. The URD exactly follows the PSS-05 format both in format and content. No section has been incorrectly interpreted. There is good, clear and credible detail in every relevant section. 2. There is a detailed data model, using a precise format such as a UML class diagram, ER diagrams, XML DTD, not an informal format such as a data dictionary. 3. A selection of important requirements is modeled in a detailed and precise way, for example as use case scenarios, (possibly specified in UML as sequence diagrams or interaction diagrams).

3 4. There is a prototype GUI design that is at least hand-drawn but preferably implemented in html, visual basic, Java graphics library or something similar. 5. There is clear evidence of a systematic approach to requirements capture, such as use of questionnaires, interviews, brainstorming sessions, etc (for a detailed list of approaches see the course notes.) If a group can implements at least three of these suggestions (you may think of others and discuss them with me), then that would satisfy a VG. 3. RURD I would suggest the following grading guidelines for the RURD. As usual the overall Grade G minimum requirements 1. The RURD exactly follows the PSS-05 standard in format, and mostly follows the PSS-05 format in content (i.e. there may be one or two items that are in an inappropriate section, according to the online standard we use.) 2. There is a revised version of the entire RURD text that makes use of the copywriting skills of the Bergh s students. The communication style of the document should be clear, focused and easily readable for non-technical clients. Technical jargon should be clearly explained, and its use should be motivated. There should not be excessive reference to technical solutions at the expense of discussing the client s actual problems. 3. (a) Commercial style applications: There should be a discussion of the business context and business model of the client. On this basis there should be an argument presented for the business case of developing the application. This can take account of existing competitive applications, and can include discussions such as potential return on investment. (b) Research Style applications: There should be a discussion of the potential need and market for any future implementation. To what extent will the envisaged application solve the identified research problem? Is further research necessary? What additions and refinements would be necessary to make a commercial product? 4. There is a data model which has a reasonably detailed definition using some clear format. Possible formats include UML class diagrams, data dictionaries, entity relationship diagrams, XML models, but are not limited to these.

4 5. There is a clear holistic (birds-eye) view of the product requirements in Chapter 2 and this is consistent with the detailed functional requirements in Chapter There is a clear identification of the different types of end-users of the application (for example as actors) and some knowledge of the differing needs and IT skills of each type. 7. There is a collection of detailed functional and non-functional requirements presented in chapter 3. Each of these is presented using the requirement template in the correct way, and with all relevant template sections filled in, including need, priority and verifiability. The verifiability criterion for each functional and performance requirement shall be credible with appropriate detail. Each requirement is clear and unambiguous. There are no obvious gaps in the requirement set. The requirements are not obviously inconsistent. All five of the above conditions must be satisfied. Grade VG minimum requirements In addition to the requirements for G some suggestions are: 1. The RURD exactly follows the PSS-05 format both in format and content. No section has been incorrectly interpreted. There is good, clear and credible detail in every relevant section, especially under validation methods for individual requirements. 2. There is a detailed data model, using a precise format such as a UML class diagram, ER diagrams, XML DTD, not an informal format such as a data dictionary. 3. A selection of important requirements is modeled in a detailed and precise way, for example as use case scenarios, (possibly specified in UML as sequence diagrams or interaction diagrams). 4. There is an executable prototype GUI (if appropriate) that is implemented in html, visual basic, Java graphics library or something similar. Screenshots of this GUI must be included in appropriate places where they support requirements discussions. 5. There is clear evidence of a systematic approach to requirements capture, such as use of questionnaires, interviews, brainstorming sessions, etc (for a detailed list of approaches see the course notes.) 6. There is a detailed usability analysis for the application. This should itemise the client s usability needs, and discuss how the user interface design will meet these needs. If appropriate, a user interface metaphor can be suggested. If a group can implements at least three of these suggestions (you may think of others and discuss them with me), then that would satisfy a VG.

5 4. ADD I would suggest the following grading guidelines for the ADD. Recall that the overall Grade G minimum requirements 1. The ADD exactly follows the PPS-05 standard in format, and mostly follows the PSS- 05 format in content (i.e. there may be one or two items that are in an inappropriate section, according to the online standard we use.) 2. There is a clear holistic (birds-eye) view of the system and its context in Chapter 3. There is some description of the interfaces between the system and its context in Sections 3.n, e.g. file formats, communication protocols, XML formats, etc. 3. There is a architectural model of the system (mainly in Section 4.2) that has a reasonably detailed and clear definition, though not necessarily using a formal notation such as UML. (It could e.g. be a flowchart or a dataflow model). The architectural model is reasonably convincing as a detailed implementation of the user requirements defined in the RURD. There may be some doubts about details of the solution and/or the connections to the RURD requirements. 4. There is detailed description of each of the components of the architectural model in Chapter 5. Each component is presented using the PSS format. Each component is clear and unambiguous. There are no missing components. 5. There is an attempt to plan the remainder of the project (detailed design, coding and testing) in terms of man-weeks and specific tasks in Chapter 6. All five of the above conditions must be satisfied. Grade VG minimum requirements In addition to the requirements for G some suggestions for VG requirements are: (1) There is evidence of use of standardized architectural models: such as 3-4 tiered database, model-view-controller, layered architecture, client-server etc. (2) There is evidence of use of design patterns (small scale architectures) such as Façade, Factory, MVC, etc. (3) There is clear and correct use of UML languages for architectural modeling, such as class diagrams, package diagrams etc. There are no serious mistakes in the use of UML.

6 (4) There is a reasonably detailed and credible risk analysis of the project using some risk identification template (such as one of the two course handouts). There is critical identification of the main risks to the project, and some suggestion for how to deal with these. (5) There is some significant critical analysis of the software engineering properties of the chosen architecture, including engineering aspects such as coupling and cohesion. (6) There is some significant critical discussion of the design method, such as top-down design, object-oriented design, etc. (7) There is a detailed plan for the remainder of the project that clearly identifies: tasks, personal responsibilities, time dependencies between tasks, a critical path through the timeline, and hence the overall time needed to complete. A GANTT chart is included. If a group can implements at least three of these suggestions (you may think of others and discuss them with me), then that would satisfy a VG. 5. Software Demo The software demo is an oral demonstration, and therefore somewhat harder to specify grades for. Nevertheless there are student guidelines and a URD document to assess. Grade G minimum requirements (All requirements must be satisfied) 1. There is an initial structured demonstration by the students. This goes through the main features of the product in an organized manner (for example by considering the main use cases that arise during an end-to-end session (i.e. start-up of the app through to shut-down). 2. The students demonstrate that the application is robust to errors, (e.g. by means of bad data). The application has no more than 2-3 crashes. 3. A comparison of the initial URD with the application shows that all the basic and at least one third of the advanced features have been correctly implemented. Any departures from the URD can be motivated. 4. Student responses to the final questions indicate an adequate understanding of the software engineering principles used during the project. Grade VG minimum requirements (At least three requirements must be satisfied) 1. The students demonstrate that the software is highly robust to crashes. The application has no crashes at all. 2. A comparison of the URD with the application shows that all the basic and most

7 of the advanced features have been implemented. At most 10% of advanced features remain unimplemented (by number). Any departures from the original URD can be well motivated. 3. Student responses to the final questions indicate an excellent understanding of the software engineering principles used during the project. 4. Students can give a good account of the application testing process, and this has been thorough and well structured. 5. There is documented feedback from the end-user which indicates a high degree of satisfaction with the product. Karl Meinke