School of Science and Technology
COURSEWORK ASSESSMENT SPECIFICATION (PG)
In this specification, you will find information about:
Details of Module and Team
What Learning Outcomes are assessed?
What are my deadlines and how much does this assessment contribute to
my module grade?
What am I required to do in the assessment?
What are my assessment criteria? (What do I have to achieve for each
grade?)
Can I get formative feedback before submitting? If so how?
What extra support could I look for myself?
How and when do I submit this assessment?
How and when will I get summative feedback?
What skills might this work evidence to employers?
SOFT40141: Software Engineering 2 2
| MODULE CODE | SOFT40141 |
| MODULE TITLE | Software Engineering 2 |
| MODULE LEADER(S) | Dr David Adama |
| COURSEWORK TITLE | Design and implementation of a work management system |
| LEARNING OUTCOMES ASSESSED |
All learning outcomes |
| CONTRIBUTION TO ELEMENT | 100% of the module |
| DATE SET | Wednesday, 27 January 2022 |
| DATE OF SUBMISSION | 11:59PM Friday, 25th March 2022 |
| METHOD OF SUBMISSION | Electronic hand-in via NOW Dropbox |
| DATE OF FEEDBACK | Wednesday, 20th April 2022 |
| METHOD OF FEEDBACK | NOW |
| Work handed in up to five working days late will be given a maximum grade of Pass whilst work that arrives more than five working days will be given a mark of zero. Work will only be accepted beyond the five working day deadline if satisfactory evidence, for example, an NEC is provided. Any issues requiring NEC https://ntu.ac.uk/current_students/resources/student_handbook/appeals/index.html The University views plagiarism and collusion as serious academic irregularities and there are a number of different penalties which may be applied to such offences. The Student Handbook has a section on Academic Irregularities, which outlines the penalties and states that plagiarism includes: ‘The incorporation of material (including text, graph, diagrams, videos etc.) derived from the work (published or unpublished) of another, by unacknowledged quotation, paraphrased imitation or other device in any work submitted for progression towards or for the completion of an award, which in any way suggests that it is the student’s own original work. Such work may include printed material in textbooks, journals and material accessible electronically for example from web pages.’ Whereas collusion includes: “Unauthorised and unacknowledged copying or use of material prepared by another person for use in submitted work. This may be with or without their consent or agreement to the copying or use of their work.” If copied with the agreement of the other candidate both parties are considered guilty of Academic Irregularity. Penalties for Academic irregularities range from capped marks and zero marks to dismissal from the course and termination of studies. To ensure that you are not accused of plagiarism, look at the sections on Plagiarism Support and Turnitin support. |
AssignmentTutorOnline
SOFT40141: Software Engineering 2 3
I. Assessment Requirements
The aim of this assignment is to demonstrate knowledge about the design of a small software
system, and implementation of such software system, according to the specifications given
below.
You are required to produce an executable solution of a specific module of the software, which is
reflected on the design. These two parts (design and implementation) are detailed below and the
percentage of marks for each is indicated.
Design (35%)
You are required to produce a single report (MS Word or PDF format) containing the design for
this system, following the object- oriented methodology and notation taught in this module.
Software Solution (55%)
Your submission should be a development report explaining your software application (MS Word
or PDF document) and a compressed folder (.zip or .gz) of the complete project, including all
source codes that you have written. These must be submitted separately. When the files are
extracted, the project should compile and run. Make sure any extra file needed to run is
included. Note that the software solution is only for the portion of the software that was
analysed and designed.
Consistency and others (10%)
The design and implementation should be consistent; if you use approaches that go beyond the
lecture’s content, you will be rewarded under this section.
The project should be compressed together with the software solution and the design report. The
compressed folder should be uploaded to the appropriate NOW dropbox.
Plagiarism Declaration
The following PLAGIARISM DECLARATION must be entered into the report and the name and ID
completed:
“This report and the software it documents are the result of my own work. Any contributions to
the work by third parties, other than tutors, are stated clearly below this declaration. Should this
statement prove to be untrue I recognise the right and duty of the Board of Examiners to take
appropriate action in line with the university’s regulations on assessment.
Name:………………………………………………………………………………………….ID No………………………………. ”
Good luck and have fun!
SOFT40141: Software Engineering 2 4
II. Assessment Scenario/Problem
1. Scenario
The Y2K company is a consulting firm that develops software tools and solutions for technological
companies with branches across the United Kingdom. The software engineering unit of their London
office handles the development of software solutions and the maintenance of existing ones for their
nationwide branches.
A challenge the team faces relates to how the client projects and tasks are managed and monitored.
Tom Jones, the head of the software engineering unit has to exchange several emails with his
colleagues daily to ascertain the progress of their work. Given that Tom manages over fifty staff, the
task is becoming more difficult and time-consuming.
Additionally, he checks his logbook to know which developer is working on which project and features
before emailing them for a progress report. Another problem Tom faces has to do with the report he
receives from the developers as they are sometimes inaccurate or exaggerated e.g., they may claim to
have implemented a feature that they haven’t. This results in conflicting information that Tom finds
hard to wrap his head around.
2. Solution Overview – Suggestion
You are to develop a standalone Work Management System (WMS) that will allow Tom and his
team to monitor project progress. Everyone can see the status of the projects (Not Started, InProgress or Completed). The system must show members working on the project and the tasks
assigned to them, percentage completion of the entire project. Also, it should show the sub-tasks
within each project and the progression messages posted by the project team members (in the
form of short comments) displayed on a timeline. Members working on a project could be able to
communicate on the project timeline and the communication logs should be saved. All the data
must be saved to persistent storage.
When a project is created, members must be assigned to the project and have tasks allocated to
them. The members could receive email notifications of the assignment. Tasks assigned to
individuals must only be editable to them or the super admin. The owner must be able to update
the percentage completion and add a comment/remark to the tasks.
Each user must be able to log in to access the system, there should be an authorization feature
with at least two roles (super-admins and users). Once a project is completed, the admin should
be able to mark the project as closed, and the team could get an email notification of the project
completion.
3. Your Task
As a junior software engineer you are required to develop the proposed WMS. The application
must be designed using object-oriented techniques and coded in C Sharp (C#). You are expected
to come up with a suitable design which should meet the requirements of a basic WMS. You are
not limited to any design specification in terms of functionality your program. However, as a
baseline you MUST identify AT LEAST TEN requirements for the system which you will design
and implement. You can assume that the data will be sufficiently small to be memory-resident
during the daily operation of the software, in which case you must manage the files yourself; or
you can perform the development of an RDBMS based application. A console application would
be enough, and it would be up to you if you wish to use libraries to develop a GUI application.
Automated testing must be done for your software using one of the frameworks taught in the
class. In addition, you are also required to use version control in your code development.
4. Task Deliverables
SOFT40141: Software Engineering 2 5
Design
The project should contain the following design and description for the software system you are
required to develop:
S1 – A description of how cohesion and coupling have been considered in the class design.
S2 – The Class diagram. This must reflect your chosen design pattern.
-Include all attributes, operations and associations derived from the above design.
S3 – A Sequence diagram for ONE use case/scenario of interest.
S4 – State diagram for ONE class. Transitions should be consistent with the related sequence
diagram.
S5 – Component diagram.
S6 – Deployment diagram.
S7 – Description of a design pattern used.
Each of these seven points provides an equal proportion of the overall grade for this section.
Software Solution
S8 – Implementation (45%)
The implementation should be focused on the functional aspects of the system. An
implementation of the classes identified in your design will be required, using as many levels of
inheritance needed. Some of the manipulations you may consider could include user profile,
login, create, save, delete and update project details etc. The implementation of the system is
divided into 2 options of increasing technical difficulty (see below). It is up to you which level of
difficulty (or how many levels) you implement, but a good implementation of a higher difficulty
would bring extra rewards in the final mark.
Option 1. Use containers (such as Lists or Dictionaries) from the standard library (STL) to store the
projects and their related data. Implement functionality to create, update, delete and search. The
search can be done by, e.g., member name, project title, project date, etc. [80% of the marks for
this section]
Option 2. Use a SQL server database to store the bookings and the related data. Implement
functionality using SQL statements to create, update, delete and search projects and their
related data. The search can be done by, e.g., member name, project title, project date, etc.
[100% of the marks for this section].
– You should use private member functions for common functionality that should not be exposed
in the public interface.
– You should predefine some data for your application so that the required information can be
correctly inserted.
– For Option 1, data needs to be stored permanently in ASCII (text) files on the local hard drive,
hence functions for loading data from files and for saving data from memory into a file are
required. The files could be comma separated values (CSV) which you need to submit together
with the code.
S9 – Testing and Version Control (10%)
– For any implementation option selected, you should include a test plan describing the
automated testing incorporated in your software solution.
– In addition to testing, you are required to use version control to store your work. You are
expected to use the Git server provided by the university (https://olympuss.ntu.ac.uk) and you
SOFT40141: Software Engineering 2 6
will need to share access to your coursework repository with your tutor. You must commit your
code regularly to your repository during development as this will be checked by your tutor. You
must include a copy of your final Git log from your repository.
Development report
You will deliver a structured document that should contain:
1. A cover page
2. A table of contents page
3. A general description of the system
4. A description of how cohesion and coupling have been considered in the class design.
5. Illustrations of Class Diagram, Sequence Diagram (one diagram), State Diagram (one diagram),
Component Diagram and Deployment Diagram
6. An explanation of any design pattern and/or MVC used
7. An explanation of the internal data structures (e.g., classes for realising lists, dictionaries or
classes for connecting RDBMS) used (Please indicate which option of difficulty chosen)
8. An explanation of the implemented algorithms/SQL statements for create, update, delete
and search (Please indicate which option of difficulty chosen)
9. A description of the file format(s) used – these should be ASCII text files if Option 1 is
chosen; or the table structure of database, if Option 2 is chosen
10. A description of software test implemented using a test framework.
11. A user manual and instruction of the software for the work management system module.
(regardless if your software is based on GUI or console interface)
Demo
You are required to give a live demonstration of your program running, during which you should
demonstrate the program’s functionality (including how the program copes with erroneous input,
if applicable). You should be prepared to answer questions about your C# code, and how it
provides the program functionality.
III. Assessment Criteria
Your overall grade can be understood with reference to the table at the end of this document.
There is no grade for the demonstration itself, but attending the demonstration is compulsory, and
a zero grade will be awarded for program functionality if you do not attend. You will not receive
credit for any code that that you are unable to explain during the demonstration.
IV. Feedback Opportunities
Formative (Whilst you’re working on thecoursework)
You can ask for guidance during the weekly lab sessions and you will also be given the opportunity
to book appointments to discuss the assessment outside of class time.
Summative (After you’ve submitted the coursework)
You will receive specific feedback regarding your coursework submission together with your
awarded grade when it is returned to you. Clearly, feedback provided with your coursework is
only for developmental purposes so that you can improve for the next assessment or subjectrelated module.
V.Resources that may be useful
Referencing styles please use Harvard as detailed here
SOFT40141: Software Engineering 2 7
Guide to planning your time here and an automated planner here
Remember to use resources such as calendars to manage the use of your time between lectures and
labs to work on this coursework.
VI. Moderation
The clarity of this specification, and the appropriateness of the assessment criteria, have been
checked by two members of the Department of Computer Science. The submissions will be
marked by two members of the module team, and the grades awarded will be reviewed by
another member of the Department to check for consistency and fairness.
VII. Aspects for Professional Development
The ability to critically analyse a range of software engineering concepts.
To show expertise in the design of software in the context of procedural and object-oriented
systems, showing analytical judgement in the selection and use of tools and techniques.
To demonstrate an ability to produce object-oriented computer software, involving development
of a robust software system, with accompanying documentation.
The ability to design and implement a software solution in response to a customer specification.
SOFT40141: Software Engineering 2
SOFT40141: Software Engineering 2
| Grade/ Grade point Assessment criteria |
Distinction (Excellent) | Commendation (Very Good) |
Pass (Good) | Fail (insufficient) | Zero | Grade/ Comment |
|||||||
| *Exceptional Dist. 15.5 – 16 |
High Dist. 14.5 – 15.4 |
Mid Dist. 13.5 – 14.4 |
Low Dist. 12.5 – 13.4 |
High Comm 11.5 – 12.4 |
Mid Comm 10.5 – 11.4 |
Low Comm 9.5 – 10.4 |
High Pass 8.5 – 9.4 |
Mid Pass 7.5 – 8.4 |
Low Pass 6.5 – 7.4 |
Marginal fail 4.5 – 6.4 |
Mid Fail 2.5 – 4.4 |
Low Fail 1.5 – 2.4 |
Zero 0.0 – 1.4 |
| Behaviour Design (S3-S4) (10%): – Sequence diagrams – State diagrams |
A thoroughly convincing design communicated well through |
An excellent design communicated well through the use of all model diagrams. Decisions made during design show insight |
Reasonably good design but may require multiple iterations for implementation. Sufficient detail in use case, sequence and/or state flows and alternative flows added. |
A number, though not all, requirements have been identified. Use of UML for identified cases, sequence and state. Some flow diagrams may be missing or incomplete. |
Major mismatch between requirements and design diagrams. Shows a lack of |
No merit or absence |
|||||||
| the use of all | about all the requirements | understanding of the | |||||||||||
| model | required methodology. | ||||||||||||
| diagrams. | Lack of understanding of | ||||||||||||
| Decisions made | UML notations. | ||||||||||||
| during design | |||||||||||||
| insight about all | |||||||||||||
| the | |||||||||||||
| requirements. | |||||||||||||
| Some use cases | |||||||||||||
| beyond the specs | |||||||||||||
| were defined. | |||||||||||||
| Structure Design | The diagrams show an exceptional grasp of the requirements and an understanding of the problem. Critical evaluation of key needs for extra functionality of the project. |
The diagrams show an extensive grasp of the requirements and an understanding of the problem. The diagrams are consistent with the others. Design pattern/MVC used. |
The diagrams demonstrate the ability to grasp the requirements. The diagrams are consistent with the others. |
The diagrams generally communicate result of the design. Decisions made on the design show understanding of most of the requirements. Some inconsistencies can be seen. |
The diagrams incomplete or inappropriate. Misunderstanding of some of key requirements. No diagram consistency at all. Lack of understanding of UML notations. |
No merit or absence |
|||||||
| (S1-S2, S5-S7) 25%: | |||||||||||||
| – Class diagrams. | |||||||||||||
| – Cohesion and | |||||||||||||
| Coupling | |||||||||||||
| – Associations | |||||||||||||
| – Operations and | |||||||||||||
| attributes identified. | |||||||||||||
| – Use of UML notation. | |||||||||||||
| – Component Diagram | |||||||||||||
| – Deployment Diagram | |||||||||||||
| – Design patterns | |||||||||||||
| and/or MVC | |||||||||||||
| Implementation | Exceptional breadth and depth of knowledge and understanding of OO programming. |
Excellent knowledge and understanding of OO programming. Program includes more functionality than was specified, to provide new insights; several levels of inheritance; reasonably |
Very good knowledge and understanding of OO programming. Some functionality beyond the required range, although not all specified functionality may be |
Good knowledge and understanding of OO programming Most required program functionality provided; classes throughout but with public attributes. |
Insufficient knowledge and understanding of OO programming. Understanding is typically at the most basic level with program |
No merit or absence |
|||||||
| (S8) 45%: | |||||||||||||
| – Functionality | |||||||||||||
| – Architecture (use of | |||||||||||||
| classes to realise MVC) | |||||||||||||
| – Data Structure ( | |||||||||||||
| Lists and dictionary) |
SOFT40141: Software Engineering 2
| – SQL and RDBMS management – Inheritance – Exception handling |
Program meets all the required functionality and much more; three levels of inheritance used; well implemented data structure or SQL/DB management and good exception handling; |
implemented data structure or SQL/DB management and good exception handling; MVC used. |
provided. Two levels of inheritance used; implementation of data structure or SQL/DB management but with limited functions, simple classes throughout, no public attributes; Search algorithm implemented |
Use of simply implemented data structure; two levels of inheritance used and some throw and catch blocks implemented. Search methods might be missing. |
being uncompilable, or compiles but does nothing; fails to address any of the functionality required by the specification. No classes implemented. Arrays used as data structure. No search functionality implemented. |
|
| Testing (S9) 10%: – Test Plan – Results and screenshots – Workarounds. – Use of debugging tools (e.g. gdb) – Use of Tests framework. – Test report |
Exceptional testing strategy and use of testing tools. |
Excellent testing strategy and excellent use of unit testing. |
Very good unit testing | Good / sufficient use of unit testing |
Insufficient use of unit testing [FMARG]. insufficient testing [FMID/FLOW]. |
No unit testing |
| Others (S10) 10%: – Consistency between design and implementation, w.r.t. requirements |
Design and implementation are perfectly consistent. Every significant design decisions are reflected and implemented. |
Design and implementation are generally consistent. Nearly all design decisions are reflected in the code. |
Design and implementation are generally consistent. There may be some small amount of mismatch but can only be noticed by carefully investigating. |
Design and implementation have something in common. But, some classes are missing or some associations are mismatched. |
Design and implementation are generally inconsistent. Very limited connection can be found between diagrams and the classes. |
No merit or absence |
SOFT40141: Software Engineering 2
- Assignment status: Already Solved By Our Experts
- (USA, AUS, UK & CA PhD. Writers)
- CLICK HERE TO GET A PROFESSIONAL WRITER TO WORK ON THIS PAPER AND OTHER SIMILAR PAPERS, GET A NON PLAGIARIZED PAPER FROM OUR EXPERTS
