Marking Guidelines for MVK Projects. MVK11 Version 6.2 (PPD, URD, ADD, revised URD+ADD, and software demo) 2012-05- 03 Final Grade formulas: MVK DD1365 Grade = PPD + URD. Bachelor s Thesis DD143X Grade = ADD + revised URD/ADD + 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. 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 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 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 3. 4. 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 are 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 a prototype GUI design which 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 implements at least three of these suggestions (you may think of others and discuss them with me), then that would satisfy a VG. 3. SRD I would suggest the following grading guidelines for the SRD. Recall that the overall Grade G minimum requirements 1. The SRD 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 logical model of the system (mainly in Section 2.7) that has a reasonably detailed and clear definition, though not necessarily using a formal notation such as UML. The logical model is reasonably convincing as an abstract and high-level description of a solution to the user requirements defined in the URD. There may be some doubts about details of the solution. 3. There is a clear holistic (birds-eye) view of the logical model in Chapter 2 and this is consistent with the detailed description of the model components in Chapter 3. 4. There is detailed description of the components of the logical model in Chapter 3. These components are presented in a systematic way. They can be organized either in terms of attribute type (file, class, interface etc.) or in terms of functionality (file browser, parser, database, etc.). Each component is clear and unambiguous. There are no obvious gaps in the logical model. 5. 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. The GUI should meet the customer needs in an appropriate way. 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 SRD 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 logical model that is expressed in a holistic way using a precise format such as a UML class diagram, activity diagram, package diagram, not an informal format. 3. A selection of important logical model behaviors and/or components are modeled in a detailed and precise way, for example as use case scenarios, (possibly specified in UML as sequence diagrams or interaction diagrams). 4. The model components and their functional and non-functional properties are defined in a systematic way using some kind of template for description. 5. There is a prototype GUI design that is implemented in html, visual basic, Java graphics library or something similar. The GUI should be well designed from an HCI perspective and meet the customer needs in an appropriate way. 6. There is evidence that the project customer has been involved in the development of the GUI design (user-centric development). 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. 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 an 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 in its detail. 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. (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. Revised ADD and URD The marking guidelines for the revised URD and ADD follow the same principles as for the original URD and ADD. However to obtain a G, all changes to the original documents must be: (i) clearly indicated, (ii) summarized, and (iii) easy to find. The
grade returned is the lesser of the two grades awarded to each revised document individually. (Example: a VG revised URD and a G revised ADD would give a G grade for the combination of both.) 6. 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 revised 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 revised 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 revised URD with the application shows that all the basic and most of the advanced features have been implemented. At most 10% of advanced features remain unimplemented (by number). Any departures from the revised 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 customer satisfaction with the product. Karl Meinke