I have an assignment and the details are below:

Assessment Size or Length: 7000 Words (Excluding Appendices) In accordance with UWE Bristol’s Assessment Content Limit Policy (formerly the Word Count Policy), the word count encompasses all text, including (but not limited to): the main body of text (including headings), all citations (both within and outside brackets), text boxes, tables and graphs, figures and diagrams, quotes, and lists. 
Maximum word count or other limitations (with no +/- 10% margin) are to be adhered to.

Module learning outcomes assessed by this task:

This assignment assesses the following module learning outcomes:
Demonstrate project management skills and techniques in the planning and implementation of a practical software project.	
Employ appropriate software development process models, software development languages, methods and tools.	
Demonstrate critical understanding and consideration of legal, social, ethical and professional issues	
Employ appropriate configuration and quality management standards and procedures for both the software process and the developed software product.

Section 1: Completing your assessment 

Broadly speaking, the assignment entails collaborating within a group of 5 to 7 students to develop either a stand-alone, command-line, or web application for the hospital-based system outlined below, using any programming language of choice.

This assignment is collaborative.

For any questions regarding this assignment, please reach out to the teaching team via email or post them on the Assignment forum on Blackboard.

Below, you will find a basic description of a hospital system and a transcript of an interview between the software engineer and the hospital administrator. Your group's task is to design and implement an application for this hospital-based system.
1.Description of a Hospital System
A typical hospital has several wards divided into male wards and female wards. Each ward has a fixed number of beds. When a patient is admitted they are placed onto an appropriate ward. The doctors in the hospital are organised into teams such as Orthopedics A, or Pediatrics, and each team is headed by a consultant doctor. There must be at least one grade 1 junior doctor in each team. The Administration department keeps a record of these teams and the doctors allocated to each team. A patient on a ward is under the care of a single team of doctors, with the consultant being the person who is responsible for the patient. A record is maintained of who has treated the patient, and it must be possible to list the patients on a ward and the patients treated by a particular team.
2.Transcript of an interview between the Software Engineer and the Hospital Administrator
Now read thorough the transcript below of an interview between the Software Engineer (SE) and the Hospital Administrator (HA). The Software Engineer is trying to clarify the scope of the system and to determine the use cases that are needed.

SE: So let me just check what this system must do. You need to admit patients and discharge them, and you also need the system to be able to output various lists? 
 
HA: Yes, oh and also to record who has treated a patient.

SE: So the system needs to know about doctors and consultants too?,

HA: Yes that is right.

SE: Let me just get this clear, does this system also need to be able to record what treatment a patient has received?

HA: No, that is done by a separate medical records system, not by this system.

SE: OK, so let's look at something specific to this system. You initially need to admit a patient to a ward, which we talked about earlier, but does a patient always stay on the same ward? 

HA: No, not necessarily, sometimes we transfer patient between wards.

SE: What information needs to be provided when this happens?

HA: The administrator has to identify the patient, and then the ward they are being transferred to.

SE: Presumably the new ward has to be of the right type?

HA: Of course, and there must be room on it too.

SE: And what is recorded when a patient is transferred?

HA: That the patient is on the new ward.

SE: Is there any need to record that they used to be on a different ward? 

HA: No, not by this system.

SE: You mentioned some lists; tell me about what kind of information the system needs to output?

HA: We need a list of all the patients on a particular ward, and a list of all the patients cared for by a particular team.

SE: Let's take the first one first. What does that involve?

HA: The administrator identifies a particular ward and the patients' names and ages should be displayed. Perhaps the ward could be identified by selecting from a list of ward names?

SE: We'll bear that in mind, but we'll leave the details of the user interface until later. How about the second list?

HA: Well the administrator identifies a team and all the patients cared for by that team should be listed.
SE: And what do you need on this list?

HA: The patient's name and the name of the ward that the patient is on.

SE: So let's move on to what you need to do to record treatment. Do you need to know every doctor in a team who has actually treated the patient?

HA: Yes, we need the system to record this.

SE: What exactly does this entail?

HA: Well the administrator has to identify the patient, and the doctor (consultant or junior doctor) who has treated the patient, and the system should record that the doctor has treated the patient.

SE: But only doctors in the team that the patient is allocated to can treat the patient.

HA: Yes, that is right.

SE: OK, do you ever need to list exactly who has treated the patient?

HA: Yes, I forgot about that. For any particular patient we need to know the name of the consultant responsible for the patient, and the code of the team that is caring for the patient, as well as the name of each doctor who has treated the patient, and their grade if they are a junior doctor.

SE: Do you really need all of this information on this list? Surely if you know the code of the team you could have the system look up the name of the consultant doctor?

HA: Yes that is true, but it would be convenient to have it on the list.

SE: So tell me what happens when a patient leaves the hospital?

HA: Well we have a discharge process, and the discharged patient should be removed from this system.

SE: So what does the administrator do?

HA: Oh they should just tell the system which patient is to be discharged, and all information relating to that patient should be removed from the system.

SE: So you don't need any record of a patient once they are discharged?

HA: Well of course we keep their medical records, but not on this system, that is a totally different system.




Section 2: Deliverables
The group should submit a single Word document file (no pdfs allowed). This must be submitted on Blackboard.  The Word document file should take the following structure:

1.Introduction: Introduce the assessment and provide a summary of the project proposal and how you have progressed from the project proposal stage. 

2.Literature review: Provide a review of literature on both the existing system described in section 2, and other hospital management systems that you have researched as part of your feasibility study. This could include reviewing systems, methods and technologies used.    

3.Design and development: Discuss the design and development using the requirements you have gathered. Provide rationale for the decisions taken in your design and development. Design and development documentation should be presented in an appendix. Whilst you are NOT expected to code or produce a fully functioning system, if you decide to code you must include full source code in an appendix. If you have not produced code, then the appendix must include your algorithms/pseudocode.  You may use snippets from your appendices in the main body of the report, to illustrate specific points. 

4.Rationale for the groups overall technical approach: This section must provide an overview of the various different software development models your group considered using and discuss the rationale for your choice of a specific method over the others in the context of your project. Within the chosen model, you need to further discuss your choice and use of the specific techniques you have used in the project.
 	
5.Discussion: You should discuss how your overall approach, as described in the section above, differs from the formal SDLC.  How have you applied/not applied or deviated from the formal literature related to the SDLC/lectorial activities? 
For example, if you have not produced code in your project, you could discuss that fact that, although you have developed test plans based upon the requirements, you are not able to run those test plans to validate the system- thus deviating from the formal SDLC as described in the literature. 
 
6.A critical appraisal of the groups achievements: Do not focus on individual aspects in this section.  For example, what skills have you gained, and how might you use these skills in the future? Are there any limitations in what has been achieved by the group? Are there any things that the group particularly excelled at?

7.Group conduct and management: How did your group conduct itself throughout the module? Include evidences of group conduct and management. You could make references to Teams Files. Remember to provide examples. To what extent did the group embed SLEP (Social, Legal, Ethical and professional) aspects into the project.  

8.User acceptance test: Using a user acceptance model for the prototype/design, what might be the predicted outcome if this system were to be deployed in future. You are expected to use literature in this section to support your arguments.

9.Prototype: Where the group has not produced code, this could also include wireframe If the group decides to use wireframe, it must still adhere to the same rigour and process.   
 
Your final submission zip file for the group-based project need to contain the following:
- A named folder containing the contribution of each team member (e.g., John Forest_Group1_Contribution)
- A folder containing final / complete deliverables for each unique project group (e.g. Group1_Final Deliverables). This should be well organised for easy access for the module team.


Submit a zip file of your implementation for the hospital system. This must be submitted on Blackboard at 2.00pm. The zip file should contain what is described in sections 2.1 and 2.2 below.

      2.1  A .doc/.docx file containing a brief discussion of your implementation choices

A .doc/.docx file containing a brief discussion of your implementation choices. The discussion should include a description of the limitations of your implementation, any alternatives that you considered and discarded and the rationale for your solution. Please ensure that you use the format for this that has been discussed in class.


      2.2  A zip file containing the following set of information about your project

–Product Backlog (and evidence of history and management)
–Iteration Plan
–Risk Register (and proof of history)
–Design Documentation
–All source Code 
–Runbook (this should tell the user how to run your code)
Any technical requirements
E.g. OS
Programming Language Version e.g. Scala 2.10.3
Database and version information
Any required tools e.g. Eclipse Scala IDE / SQLWorkBench
Where to find all resources
Code, models, documentation, data etc.
All libraries used
Names, versions
Where to find, how to configure if appropriate
Steps to build, deploy and test database
Steps to build, test domain model
Steps to build, deploy and test PPL

–Any Limitations & Enhancements of your proposed tool
–Group Assessment (also append your group’s contribution matrix)
What went well
What did not go so well
How the group could improve / do better next time
Any Legal, Ethical or Professional Issues (e.g. licensing)
How well the Development process worked (e.g. would you use Agile again) 
Recommendations on tooling 
Experience with environments / tooling you used


Section 3: About the assessment

Where should I start?

As part of this module's requirements, you are required to schedule weekly meetings to discuss the progress of your group and outline the roles and responsibilities for each group member. Additionally, you should prepare a project proposal that includes the problem statement, Gantt chart, and risk plan. This will enable the group to monitor the progress of the project development in an appropriate manner.

What do I need to do to pass? 

To successfully complete the module, a minimum score of 50% or higher is required (as stated in Section 5: Marking Criteria).

How do I achieve high marks in this assessment?

Please see the marking criteria (as stated in section 5). To gain high marks, 
•you will submit a report that provides a comprehensive overview, and the literature review is relevant and up-to-date. 
•Methods can be explored thoroughly, with justification provided for the chosen approach. 
• The source code must be clear and structured. 
•The discussion ought to be insightful, with analysis of limitations and proposed enhancements. 
•The group's performance needs to be assessed holistically, with recommendations for improvement. 
•The chosen user acceptance model must be well-evaluated, and the functioning prototype meets all client requirements.


Section 5: Marking Criteria (For excellent results)

Introduction (5%) - Introduction covers all areas and is coherent. 
Literature review (10%) - Literature review is relevant, thorough and up to date.  Relates to the concepts of the project chosen. Gaps in literature has been identified, justified in the context of the chosen project.
Method (20%) - Methods presented is critically examined. Justification of the method chosen is provided on the basis of research and is within the context of the project.
Design and development  (10%) - Source code is complete, suitably commented, structured, with clear separation between technologies, clear self checking tests, compiles runs but some what lacks in the application of method. Partially implemented system delivered including documentation covering maintainability.
Discussion  (5%) - Discussion is thorough and critical examining various dimensions of the project under development. The submission demonstrates some level of understanding of industry practice. 
Group assessment  (10%) - Clear analysis of limitations with implications of these explained along with the examples in the context of the chosen project.
Group conduct and management  (20%) - Clear analysis of the group as a whole with presentation of what the group did well, what did not go well and proposals for how the group could improve their operation. Analysis of Social, Legal, Ethical and Professional issues with description of how well development process worked and recommendations on tooling.
User acceptance test  (10%) - Chosen user acceptance model is fully evaluated, appropriate in the context of the project and well justified. 
Prototype    (10%) - Functioning prototype demonstrated that satisfies all requirements provided by the client. 

Now, as comprehensively detailed as possible, explain to me step by step how to get this done in the best possible way, for the best possible results, in the shortest possible time.