CM1202 Developing Quality Software coursework代写

Cardiff School of Computer Science and Informatics
Coursework Assessment Pro-forma
Module Code: CM1202
Module Title: Developing Quality Software
Module Leader: Dr Daniel J. Finnegan
Teaching Team: Dr Nervo Verdezoto Dias, Dr Carolina Fuentes Toro
Assessment Title: Resit Coursework
Date Set: Monday 19th July 2021
Submission Date and Time: Monday 9th August 2021 @ 09:30 UK time
Return Date: Within 4 weeks of the submission date.
If coursework is submitted late (and where there are no extenuating circumstances) a mark
of FAIL will be given for the assessment.
Your submission must include the official Coursework Submission Cover sheet, which can be
found here:
https://docs.cs.cf.ac.uk/downloads/coursework/Coversheet.pdf
Submission Instructions
Submit your coursework, electronically via Learning Central by the deadline above using the
following table as a guide to the number of files to submit and their file types.
Description Type Name
Coursework for
deliverables 1, 2,
and 3.
Compulsory One PDF (.pdf) file [student number]courseworkresit.pdf
Coversheet Compulsory One PDF (.pdf) file [student number]coversheet.pdf
This assignment is graded as either a PASS or a FAIL. Please note there is a strict 3-page
limit, and the font should be Calibri size 11. References do count towards this limit.
Appendices are not allowed.
Any deviation from the submission instructions above (including the number and types of
files submitted) may result in a mark of FAIL for the assessment.
Staff reserve the right to invite students to a meeting to discuss coursework submissions.
Assignment Scenario:
Background to the problem
At the start of the university’s academic year, Senior Personal Tutors throughout Cardiff
University spend considerable time assigning new students (undergraduate and
postgraduate) to personal tutors. Although the assignment might seem random, students are
assigned to appropriate staff where possible. For example, within the School of Computer
Science and Informatics (COMSC), students on specialist degrees are assigned to staff within
those research groups; also, where possible students are placed in personal tutor groups that
consist of students on one degree programme.
The current COMSC process – before students can be assigned to personal tutors, at the start
of the year, the Senior Personal Tutor needs to obtain a list of staff who will undertake
personal tutor duties, this list is provided by the head of school. The list changes year to year,
as new lecturers are employed, leave, or go on a period of research leave. We then decide
which staff members will have undergraduate (UG) tutees and postgraduate (PG) tutees and
how many tutees each staff member will be assigned. PG tutees are assigned following
enrolment, however UG tutees are assigned at the start of September once UCAS and clearing
has finished when the UG Senior Personal Tutor is provided with a spreadsheet, CSV file listing
all the new UG students from an admissions tutor. In addition to being assigned new students
tutees, personal tutors will have to be reassigned for other current students, if academic staff
have left or are on research leave for that year.
During the academic year, Senior Personal Tutors will need to search for the personal tutor
for a particular student, provide staff with an up-to-date list of their tutees, and provide the
School’s management team with the number of tutees each staff member has been assigned
per year or degree group. The tutor list also needs updating when students withdraw.
Occasionally students are individually reassigned tutors on request, this is usually if they
transfer degree programmes.
At the end of the academic year following the examination boards, the Senior Personal Tutor
will update the CSV files to be ready for the next academic year.
Task: Imagine you have been asked by COMSC to develop a prototype for a personal and
academic tutor system: a stand-alone application to be used by the School’s Senior Personal
Tutor. COMSC’s aim is to reduce the Senior Personal Tutor’s workload at a very busy time
of year, allowing more time to co-ordinate the other enrolment activities. For the PG Senior
Personal Tutor this is even more important given that currently they have an even quicker
turnaround time. Additional potential benefits that COMSC hopes to achieve are a more
reliable up-to-date list and the opportunity for more advanced personal tutor assignment
algorithms.
The prototype must assist the Senior Personal Tutor to undertake the tasks mentioned above
in ‘Background to the problem’. These include, but are not restricted to, the following use
cases:

1. assigning new students to tutors,
2. searching the personal tutor list for individual students,
3. displaying lists of tutees for a particular personal tutor,
4. providing information on the quota of tutees each staff member has been
   assigned per year or degree group.
   Deliverables:
5. Requirements specification
   a) Develop a list of functional requirements with brief descriptions indicating the features
   you would like to provide in your application (see scenario above). Requirements should
   be listed using the MoSCoW notation and be written so that they can be validated /
   acceptance tested.
   b) Non-Functional Requirements
   Provide a list of the most relevant non-functional requirements for the application along
   with acceptance criteria. It is very important that these requirements are written so that
   they are testable.
6. Class Diagram
   Create a class diagram modelling your system prototype. Your diagram should contain a
   complete set of classes such that the requirements from the sections ‘Background to the
   problem’ and ‘Task’ above are met. The diagram should include the classes and (possibly
   different types of) relationships between classes to capture the structure of the proposed
   system. For each class include representative attributes and methods. Describe how your
   class diagram will support ALL the major system functional requirements. This description
   for the complete class diagram should be a maximum of 1 A4 page.
7. Reflective Report
   Choose ONE of the following topics:

• Code Reliability
• Risk Assessments and Reporting
• Black and White Box Testing
  Write a reflective report on your chosen topic. Your report should introduce, discuss, and
  provide a personal reflection on your chosen topic. You should keep the following in mind
  when preparing your report:
  Introduction of your interest
  Your introduction need not be extensive: two or three paragraphs is enough. Be sure to make
  use of your academic source and of your learning artefact (see below) to introduce your
  subject.
  Learning Artefact
  Provide at least one research article/professional whitepaper that highlights the importance
  of your chosen topic. If providing more than one you can use the same or different types of
  reference.
  Your report should be no longer than 1 A4 page. It is important to write reflectively. For
  example, consider the following while writing your report:
• Write reflectively, not descriptively. DO NOT write like this: “Modularity means
  systems are modular in nature. Modularity is not just a feature of hardware but
  software too. I learned a lot about writing modular programs and which will help me
  in the future”. Instead, YOU SHOULD write like this: “Learning about modular program
  structuring was fun, and I learned a lot. At first, I assumed modularity was something
  hardware engineers focused on as each component of the computer system is
  manufactured independently and then slotted into one another when building the final
  system. However, I now understand how modularity can help with structuring
  software too. The most important take home message for me was the need to divide
  and conquer. Once a system has been decomposed to a set of smaller components,
  each with their own responsibility and computational purpose, the system is easier to
  comprehend. This will prove useful in future software projects where I’ll need to
  develop complex systems with hundreds or thousands of lines of code.”
• Give enough detail so that the reader can understand what you have learned about
  your chosen topic. Try writing a draft first and then passing it to a friend (NB: not
  another student from the School of Computer Science and Informatics at Cardiff
  University) or family member and ask them to read it and then say back to you what
  you learned. If they are right, then your draft is good. If they are wrong, then you
  should revise.
• Reference and index figures. Every figure appearing in your report should be indexed
  e.g., Figure 1, Figure 2, and use descriptive captions. They should also be referenced
  in the text. If they are not, then the implication is they are not discussed and therefore
  should not be included. If they are discussed, then they should be referenced. All
  figures should also have a caption.
  Criteria for assessment
  Credit will be awarded against the following criteria.
  Task 1: Requirements Specification
  Rating Requirements Validation/Testing
  Pass Functional and nonfunctional requirements are
  fully specified and
  demonstrate a good
  understanding of the
  system’s expectations.
  Requirements are written with
  partial validation and acceptance
  criteria, demonstrating a good
  understanding of evaluation and
  testing.
  Fail Little/no attempt at
  specifying the functional
  and non-functional
  requirements is made,
  demonstrating a lack of
  understanding of the
  system’s expectations.
  Little/no attempt at writing
  requirements with validation and
  acceptance criteria, demonstrating
  a lack of understanding of
  evaluation and testing.
  Task 2: Class diagram
  Hints:
• Use clear and concise class names
• Appropriate attributes and methods with associations and relationships
• Correct syntax
• The explanation will be also used in assessing completeness of the diagram.
  Rating Modelling Conventions Explanation Completeness
  Pass The model is a good
  attempt at following
  UML modelling
  conventions and
  contains a few errors in
  modelling syntax.
  The explanation
  demonstrates
  how the class
  diagram supports
  all the major
  system functional
  requirements but
  is limited and/or
  difficult to follow
  in some sections.
  The UML model is a
  good attempt at
  meeting the
  requirements of the
  project and little of
  the important
  information is
  missing.
  Fail The model does not
  follow UML modelling
  conventions and has
  many errors in
  modelling syntax OR no
  UML model has been
  given.
  No explanation
  has been given or
  the given
  explanation fails
  to demonstrate
  how the class
  diagram supports
  the system
  function
  requirements.
  The model meets
  few of the
  requirements of the
  project and much of
  the important
  information is
  missing OR no UML
  model has been
  given.
  Task 3: Reflective Report
  Rating Reflective Writing
  Pass The report demonstrates clear understanding and appreciation of
  the chosen topic. Writing is clear, concise, and features enough
  detail indicating you have engaged with the topic and what you
  have learned.
  Fail The report is vague, unclear, and/or demonstrates a lack of
  understanding and appreciation of the chosen topic. Writing is
  incoherent, verbose, and/or does not feature enough detail to
  indicate what you have learned about the topic.
  To pass, you MUST achieve a ‘Pass’ rating in all 3 tasks in this coursework.
  Learning Outcomes Assessed
  All learning outcomes specified in the module description are assessed in this assignment.
  Feedback and suggestion for future learning
  Feedback on your coursework will address the above criteria. Feedback and marks will be
  returned via email from the Module Leader