Analysis and Design with UML | My Assignment Tutor

Faculty of Engineering and Environment KF7011 System Analysis and Design with UML Assignment: Design Enhancing the current Quality Control processes of Newcastle Special’s to improve their data integrity and efficiency. Module: KF7011 – Systems Analysis and Design with UML Module tutor: Honglei Li Group 04: Joel Pearson (w17005730)Hugh Woodford (v090258963)Ismael J. Gomez (w20051520)Akramul I. Fahim (w19052798) Word Count: 4271 Executive Summary EXECUTIVE SUMMARY Newcastle Specials Quality Control unit is a quality control and assurance department operating for Newcastle Specials under Newcastle Hospitals business arm. Its’ main job is to be responsible for the testing and release of pharmaceutical products coming from the production unit. The current worksheet, paper-based system is a step-by-step process where a product is received into lab, a note is made that the product (along with its batch number) is awaiting testing, then when staff are available, they will print a worksheet for that specific product and carry out testing. Test results are recorded onto the worksheet, and if errors occur then a QCNC (Quality Control Non-Compliance) is generated and investigated. Upon conclusion or if the worksheet is completed without error, it goes to final approval and product release, generating a certificate of analysis. The products are then labelled as released and are then ready for dispatch. The worksheets are then archived for later access if required. The current process is prone to a high volume of input and technical errors that must be identified by a senior member of staff before data entry. There is also an issue with recording and storing test data for certain equipment that has no such internal or external mechanism. The proposed system looks at automating this process through the use of digital worksheets than can be checked automatically before data entry takes place. This system will also benefit from the faster release of products, cut down costs of printing and storage. The creation of a “live” digital system will also allow for potential multiple user views, meaning that other departments such as the stores dispatch staff may view the progress of any given item that is in process. The live QC test record system has been designed to improve the data integrity and efficiency of Newcastle Specials Quality Control (QC) processes by streamlining dataflow, providing authentication for employees and digitalizing the overall product testing process. This document outlines the planning and analysis phase of design which involves functional, structural and behavioural modelling. CONTENTS Executive Summary 2 1.0 System Request 5 2.0 Feasibility Analysis 6 2.1 Technical Feasibility 6 2.2 Economic Feasibility 7 2.3 Organizational Feasibility: If we build it, will they come? 7 2.4 Cost Benefit Analysis 9 3.0 Requirements Definition 11 3.1 Functional Requirements 11 3.2 Non-functional requirements 12 4.0 Functional Modelling 13 4.1 Use Case Descriptions 13 4.1.1 Current System (“as is”) 13 4.1.2 Intended System (“to be”) 19 4.2 Use Case Diagram 24 4.3 Activity Diagrams 25 4.3.1 Product Receival 25 4.3.2 Product Testing 26 4.3.3 QCNC Generation 27 4.3.4 Approval of record data 28 5.0 Structural Modelling 29 5.1 Class Responsibility Collaborator (CRC) Cards 29 5.2 Class Diagram 34 5.3 Object Diagram 36 6.0 Behavioural Modelling 37 6.1 Sequence Diagrams 37 6.1.1 Product Receival 37 6.1.2 Product Testing 38 6.1.3 QCNC Generation 38 6.1.4 Approval of Record Data and Product Release 39 6.2 Communication Diagrams 40 6.2.1 Product Receival 40 6.2.2 Product Testing 40 6.2.3 QCNC Generation 40 6.2.4 Approval of Record Data 41 6.2.5 Product Release 41 6.3 Behavioural State Machine 42 6.3.1 Product Receival 42 6.3.2 Product Testing & QCNC 43 6.3.3 Approval of Record Data 44 6.3.4 Product Release 45 6.4 CRUDE Matrix 46 7.0 Group Report 47 References 49 A. Client Contact 50 A.1 Interview Transcript 50 A.2 Follow up email 52 B. Code of Conduct 53 C. Meeting Minutes 57 C.1 Meeting 01 57 System Request Project Name: Enhancing the current Quality Control processes of Newcastle Special’s to improve their data integrity and efficiency.Project Sponsor: Name: Adam Walker Department: Quality Control Organization: Newcastle Specials (Newcastle Hospital RVI)Business Need: A data integrity system fit for purpose. Certain processes of the current system are not immediately recorded onto an electronic system. Furthermore, the MHRA (Medicines and Healthcare products Regulation Agency) would prefer a system that would allow data to be immediately recorded and that cannot be changed or tampered with at a later date. Produce a “live certification” system for products for prompt release. The current system would highly benefit from a live certification system in order to release products without delay. Increase efficiency of the QC processes. The existing system needs a faster, more efficient and more reliable QC process overall.Business Value: Tangible: A more accessible system for all staff members. Time saving due to reduced needs for communication between departments. Greater efficiency, as the database checks should become easier and quicker to complete for senior staff members.  Better product overview, system will allow a user to see the “journey” of the product.Intangible: Greater system security and greater compliance with MHRA requirements. Provides staff with additional tools and an easier way to overview products and see potential issues to facilitate earlier product release. They would feel more comfortable and satisfied at their workstations.  Potential improvement of customer communication.Special Issues or Constraints: There is a need to work around current IT systems in place. This may limit the scope or scale of the work.   Securing user authentication data.  Can the current database system be transposed into the new system?  Is there potential to reconstitute the current QCNC (quality control non-compliance) system into the new system?  Feasibility AnalysisTechnical FeasibilityFamiliarity with business function There are several systems at play in the current QC process. Refining these systems into a conciliated overarching system should be possible  given the current system functions. There may be limits due to the networking and various departments involved. The person/team that is building the system will be able to use this consultancy as instructions to carry out the work. However, a small degree of knowledge and context will need to be known in order to fully understand the instructions and build the system effectively.  Familiarity with the technology Few computer machines in the lab. Possibility of adding more technological features in order to implement the system. The system implementation will require knowledge of databases and how to implement them, along with networking knowledge. The intended system will need to make use tablet technology in order to operate from within the lab. This will provide employees with a portable device that can be used around the lab to record test results digitally. Therefore, there will be a small degree of training to get employees familiar with the new system.The project will involve deploying the system on a cloud-based server; therefore, some degree of knowledge and experience will be required for both implementation and maintenance. Project Size and Scope The scope of the project will be initially limited to improving the current QC processes. There may be the opportunity to add more layers to the system which will be reviewed as the project proceeds and further meetings with the project sponsor.   The client has requested a system that is “fit for purpose”. For example, the client has stated that certain test procedures do not fully comply with data integrity requirements, as they have no means to document evidence of those particular tests. We would have to evaluate the different options to provide a workable solution. This is expanded on in the requirements definition section.The client has requested to evaluate the viability of a live certification system, which would involve the partial generation of a certificate of analysis as the testing steps are carried out. This would mean staff (such as business sales or stores dispatch staff) could view where a product is along the release process. However, because of the way the current system works, information is only passed to a certificate of analysis once all the data is in the database. For this to work, information would need to be passed contemporaneously once recorded. Therefore, our system provides a compromise where the user will be able to view a worksheet in progress. This can be provided by authentication and user views and permissions. Economic FeasibilityTangible Benefits Earlier product release, faster customer service.  Less printing of paper reports and certificates.  Intangible Benefits Time saved by lessening the burden on inter-departmental communication. Scalable solution that will be future proof. Increased security lessens threat of losing or corrupting data, meaning less external support required. Compliance with MHRA guidelines and greater data integrity, a system fit for purpose (Greater protection against penalties in the future).Time saved for individual scientists, less time spent checking and transcribing information to the database. A direct increase in the amount of available man hours per week for the lab. Organizational Feasibility: If we build it, will they come? Table 2.1: Organizational feasibility table.  Role Techniques for Improvement Champion A champion: Adam Walker (Quality Controller for Newcastle Hospitals) Initiate the project.  Promote the project.  Provide information and resources.  Allocate time to project (meeting with consultancy team). Present the aims and objectives of the proposed system as well as the expected benefits it will provide. Demonstrate a prototype of the developed system in order to show its value. Senior Management Head manager of production unit and Business manager:  Know the potential use of the to-be system.  Meet the economic needs for the completion of the project. Break down and market the benefits of the project with a presentation and memos. System Users Daily users of the system; Quality Control Scientists, Lab Manager, Senior Operatives.  Provide feedback on produced designs and prototypes in order to make improvements. Liaise with daily users to address needs and concerns. Ask if daily users have any features or suggestions that they would like to be implemented that would facilitate ease of use or improve the service. Other Stakeholders Suppliers.  Programmers in charge of implementing the system.  Potential business partners.  Sellers of the system to other interested institutions. A clear set of aims and a design model that is intuitive and simple to follow. The stipulations of the design process must be clearly shown, and any potential issues or ambiguity must be addressed preemptively.  Potential commercial benefits, the system could be sold or licensed.  Cost Benefit Analysis Our client clearly states that the main concern of the proposed system is a change to regulatory compliance and data integrity systems as shown in Appendix A.1. “Overall, the value of this project is in increased regulatory compliance rather than time savings – our current system is not fit for purpose!”. As such, there isn’t a focus on significant cost saving but instead of making a more secure system. However, we have evaluated any potential savings that could be gained from reduced printing costs, along with potential man hours saved due to this new system. As we have not been able to acquire certain sensitive data, estimates of savings will be provided based upon speculated figures based upon a group member’s previous work experience (2 years at Senior Quality Operative) at the unit. Units: British Pounds (£) Table 2.2: Cost benefit analysis table for the next 5 years. 20212022202320242025TotalBenefitsPrint savings5005055105155202,550Man hours saved3,6943,7303,7683805384318,840Total Benefits4,1944,2354,2784,3204,36321,390Development CostsConsultation2.000––––2,000Installation30,000––––30,000Hardware4.000––––4.000Staff training100––––100Total Development Costs36,100––––36,100Operational CostsMaintenance–7507507507503,000Cloud Server–1,2001,2201,2401,2604,920Total Operational Costs–1,9501,9701,9902,0107,920Total Costs31,906-2,285-2,308-2,330-2,35322,630 Break-even point = 13 years (2034) Break-even point is calculated by a compounded cost saving based upon an increase of 1% of product output, saving roughly £2200-2600 (trending towards the latter) every year. As savings are in man-hours and some printing costs, this is contingent upon the maximum level of product output being achieved by the unit. Calculation for money in man-hours saved per year through hours saved by scientists: Hours worked per year 37.5×52 = 1950hrs/y Yearly wage = 34,638 34,638/1950 = £17.76 8 hours p/w x 17.76 = 142.08 p/w New estimate time 4 hours = £72.04 £7,388.16 current cost p/y £3,694.08 new cost p/y Savings of £3,694.08 p/y in man hours Requirements DefinitionFunctional RequirementsThe system must have an approve option. After a user has recorded test results, a senior member of staff must have an option to approve the results (for after they have reviewed the results) so that they can be passed to the database. The system must implement a method where QC technicians can record their test results digitally. It is important that the results are in a digital format before being passed to a senior member of staff for review. The system must have a method of catching and highlighting errors to be further confirmed. It will give the user an option to discern between a technical error and an input error. Technical error (QCNC):An error that was made by the user (e.g., wrong testing, over confidence, precision errors, etc…) and should be corrected by a senior member. This will lead to the generation of a QCNC. Input error:An error that where the user, inputs the incorrect value. This could be simply (e.g. writing the value 97 instead of 98 for a test result). The system must have a method that allows the users to access different types of product QC tests. Newcastle Specials handle many different types of products and each has a unique set of tests to be carried out on them. To improve efficiency for the user, the QC technicians must have easy access to all the different QC tests for each product. The system must be able to be used by multiple users at the same time. It will need to be used by multiple technicians in the lab. The system must provide the user (internal or external customers) with an option to print a released Certificate of Analysis after the results have been approved by a Senior QC Scientist or Lab Manager. This was a direct requirement from the sponsor. The system must have a user authentication function. This is to improve the data integrity of the system so that multiple users can’t alter the same documents and to ensure that only senior members can approve QC results. The system must provide users with a function to add and customize their own templates (worksheets). This function will provide users with the tools to create and customize their own templates for future scalability and added functionality. The system should have a live certification that is viewable in-organization. This live certificate will show complete and incomplete data so that another user (e.g., business office) can view the current state of a product and where it is “in the pipeline”. The system should prompt users to change passwords every 3-months. This function will make the system more secure by having users consistently changing their password. The system could have a system that highlights out of trends and potential problems. “Out of trends” are those products that give out of trend results, e.g., a product typically ranges from 97-102% gives a result of 104%, this will be highlighted, and a record kept. Products with common out of trends could give user prompts that highlights specific parts of the process that frequently cause problems, with the user having to acknowledge this before moving on. The system could contain all of Newcastle Special’s SOPs for digitalized easy access. A nice addition for the system would be to have all the SOPs accessible by the QC technicians for easy referral. Non-functional requirementsThe system must be deployed on the cloud. This gives the system a better level of scalability. The system must be accessible from multiple locations. If a staff member is at home or not in the lab because of any reason, it would let them access the system. The system must have a saving/auto-saving system. It would provide data-integrity and would make sure that data won’t get lost if you have a break and come back to your task after some time. The system should make use of a username and password to authenticate a user login. This is opposed to other authentication methods such as a pin-code or two-factor authentication techniques. The system could “lock”data that is under review. It is viewable in-house but cannot be edited except by a senior manager or the person who originally inputted the data. System should automatically logout a user after 30 minutes of inactivity. To increase security and data integrity, after 30 minutes of inactivity a user will be logged out to ensure that the system cannot be accessed by others. Functional ModellingUse Case Descriptions The use-case descriptions below provide an overview of the business processes involved in the developing system (Dennis, Wixom and Tegarden, 2015, pp. 146; Bolloju and Sun, 2012, pp. 2182). The approach for this project involved developing use-case descriptions for the current processes of Newcastle Specials (section 4.1.1) to identify areas that could be improved. Then use-case descriptions of the intended system (section 4.1.2) were developed with the enhancements in mind. Using this approach, the group was able to remove a use-case altogether from the current processes which will lead to a more efficient system with a more streamlined flow of data. Current System (“as is”) Use-case’s describing the current system/processes of Newcastle Special’s. Use-case Name: Product receivalID: 0Importance Level: MediumPrimary Actor(s): Production staff, QC staffUse-case Type: ExtensionStakeholders and Interests: QC staff, Senior Production staffBrief Description: This use-case describes the process of how a product is received by the QC staff to then be tested.Trigger: The product is received through QC hatch from the production unit. Type: InternalRelationships: Association: Product testing Include: Extend: Generalization:Normal Flow of Events: A sample of the original product produced by the Production Staff is passed through to QC for the testing to be carried out. Product name is recorded onto a white board and the type of testing it needs. Product is stored in the correct conditions, awaiting testing (in quarantine).Sub-Flows: N/AAlternate/Exceptional Flows: N/A Use-case Name: Product TestingID: 1Importance Level: HighPrimary Actor(s): Senior QC Scientist, Senior QC OperativeUse-case Type: EssentialStakeholders and Interests: QC Staff, Business Staff, CustomerBrief Description: This use-case describes how standard testing is carried out following a QC worksheet.Trigger: Product is received through QC hatch from the production unit. Type: ExternalRelationships: Association: Product Manufacture, Approving record data Include: Extend: QCNC Generalisation: QC product testingNormal Flow of Events: Product is selected from white board Relevant QC worksheet printed Testing carried out on product Results recorded on QC worksheet Product paperwork put back into tray for review by senior staff memberSub-Flows: N/AAlternate/Exceptional Flows: When there is an error in the testing process or a result that is outside of tolerance, then a QCNC must be generated (after event 8) Use-case Name: QCNC generationID: 3Importance Level: MediumPrimary Actor(s): QC Operative, QC ScientistsUse-case Type: ExtensionStakeholders and Interests: QC StaffBrief Description: When an error or adverse event occurs, then a record of events must be made, and a root cause identified.Trigger: Adverse event, error or result obtained from testing out spec, spread, or limit. Type: ExtensionRelationships: Association: Include: Product Testing, Approval of record data Extend: Generalisation:Normal Flow of Events: Upon trigger, a QCNC code is generated for the product batch. This is recorded on EXCEL worksheet. All relevant SOPs for recording the QCNC investigative process are printed. A senior member of QC staff will lead the QCNC questioning phase to assess whether there were any procedural errors on behalf of the QC staff carrying out the original testing. If procedural error was found, then go to sub flows. Investigate whether there was a potential error in production, or errors due to faulty equipment. Print off new worksheet and append to original batch documentation. If no immediate root cause can be identified, then repeat tests (2) to ensure accuracy. Complete paperwork concluding investigation, identifying root cause, any changes required in process etc. Manager signs off paperwork closing QCNC investigation.Sub-Flows: S-1: If procedural error, repeat testing and record new results.Alternate/Exceptional Flows: N/A Use-case Name: Approval of record dataID: 4Importance Level: HighPrimary Actor: Senior QC ScientistUse-case Type: EssentialStakeholders and Interests: QC scientists – wants to ensure that the recorded data is correct in order for it to be approved. QC senior scientistsBrief Description: This use-case describes the processes carried out for approving the recorded test results of a product.Trigger: Once the initial testing is competed, and data has been recorded by previous process a Senior QC staff member takes results from the tray for review. Type: InternalRelationships: Association: Product Testing, Data input Include: Extend: QCNC Generalization: QC product testingNormal Flow of Events: Senior QC staff member retrieves worksheet from completed tray. The results are reviewed and compared against known tolerances (out of limits) and to identify “out of trends”. The Senior QC staff member will also review all mathematical processes, weights measured etc. to make sure that everything is recorded correctly.Sub-Flows: S-1.1: No “out of limits” or “out of trends” are identified. S-1.2: The testing can be approved.S-2.1: An issue is identified. S-2.2: A QCNC is generated.Alternate/Exceptional Flows: A product gets approved that shouldn’t have been approved (The Senior QC member just made a mistake). A product recall is generated. Use-case Name: Data inputID: 5Importance Level: HighPrimary Actor: Senior QC ScientistUse-case Type: EssentialStakeholders and Interests: Senior QC staff – wants to make sure that the approved test results are successfully stored in the product database.Brief Description: This use-case describes how the approved recorded test results are inputted into the product database.Trigger: Once a worksheet has been approved and the document is placed in the “approved” tray. Type: InternalRelationships: Association: Approving record data, product release Include: Extend: Generalization: QC product testingNormal Flow of Events: A senior staff member retrieves an approved worksheet from its corresponding tray. The data is then manually inputted into the product database (simple data entry).Sub-Flows: N/AAlternate/Exceptional Flows: An input error is made when entering the data into a database. The error can be noticed on the final certificate. Use-case Name: Product releaseID: 6Importance Level: HighPrimary Actor: Senior QC ScientistUse-case Type: Detail, EssentialStakeholders and Interests: QC Staff – wants the product to be successfully releasedTrigger: The product has undergone all relevant testing and been approved. Type: InternalRelationships: Association: Data input, Business Sale Include: Extend: Generalization: QC product testingNormal Flow of Events: The product certificate of analysis is produced using the database tool Final sign-off of paperwork to confirm that product is ready for release The Senior QC staff member will apply “released by QC” to the relevant product.Sub-Flows: N/AAlternate/Exceptional Flows: N/A Intended System (“to be”) Use-case’s describing the intended system/processes of Newcastle Special’s. Use-case Name: Product receivalID: 0Importance Level: MediumPrimary Actor(s): Production staff, QC staffUse-case Type: ExtensionStakeholders and Interests: QC staff, Senior Production staffBrief Description: This use-case describes the process of how a product is received by the QC staff to then be tested.Trigger: The product is received through QC hatch from the production unit. Type: InternalRelationships: Association: Product testing Include: Extend: Generalization:Normal Flow of Events: A sample of the original product produced by the Production Staff is passed through to QC for the testing to be carried out. Open a new product entry using the live system and add name and test required. Product is stored in quarantine until testing is requiredSub-Flows: N/AAlternate/Exceptional Flows: N/A Use-case Name: Product TestingID: 1Importance Level: HighPrimary Actor(s): QC Operatives, QC ScientistsUse-case Type: EssentialStakeholders and Interests: QC StaffBrief Description: This use-case describes how a product is tested.Trigger: A product that has been recorded onto the system is ready for testing Type: InternalRelationships: Association: Product receival, Approval of record data Include: Extend: QCNC generation Generalisation:Normal Flow of Events: QC Staff sign into system. Digital Worksheet produced. Tests carried out according to SOP standards. Results recorded via the live system. Upon contemporaneous check by 2nd member of QC staff, results recorded onto live system. “Confirm” function is used to after completion of testing.Sub-Flows: S-1: Product retrieved from quarantine.S-2: Where appropriate (e.g. using non-networked equipment such as pH meter) take photo of result and attach to worksheetAlternate/Exceptional Flows: When there is an error in the testing process or a result that is outside of tolerance, then a QCNC must be generated (after event 4) Use-case Name: QCNC generationID: 2Importance Level: MediumPrimary Actor(s): QC Operative, QC ScientistsUse-case Type: ExtensionStakeholders and Interests: QC StaffBrief Description: When an error or adverse event occurs, then a record of events must be made, and a root cause identified.Trigger: Adverse event, error or result obtained from testing out spec, spread, or limit. Type: ExtensionRelationships: Association: Include: Product Testing, Approval of record data Extend: Generalisation:Normal Flow of Events: Upon trigger, a QCNC code is generated for the product batch. (This should be automatically created in the same database as the product database?) All relevant SOPs for recording the QCNC investigative process are printed. A senior member of QC staff will lead the QCNC questioning phase to assess whether there were any procedural errors on behalf of the QC staff carrying out the original testing. If procedural error was found, then go to sub flows. Investigate whether there was a potential error in production, or errors due to faulty equipment. Complete paperwork concluding investigation, identifying root cause, any changes required in process etc. Close out QCNC investigation on database. Input post-retesting results onto live system with manager/senior approval.Sub-Flows: S-1: If procedural error, repeat testing and record new resultsAlternate/Exceptional Flows: N/A Use-case Name: Approval of record dataID: 4Importance Level: HighPrimary Actor(s): Senior QC scientistUse-case Type: EssentialStakeholders and Interests: QC scientists, Senior QC scientistsBrief Description: This use-case describes the processes carried out in order to approve the recorded test results of a specific product.Trigger: Once the testing phases are complete, a senior QC scientist oversees the recorded data before it is registered in the system. Type: InternalRelationships: Association: Product testing, QCNC generation, Data input Include: Extend: QCNC Generalisation: QC product testingNormal Flow of Events: A Senior QC scientist logs into the system via the authentication function. System flags and highlights any “out of bounds”. The recorded results are compared against known tolerances (out of limits) and “out of trends”. Mathematical processes, measured weights, etc. Are reviewed to verify everything is correct. The Senior QC Scientist indicates the registered data is reviewed and correct using the approve function. The Senior QC scientists confirms submission of document data by clicking “approve”. This data is uploaded to the database upon approval (via a simple SQL insert statement).Sub-Flows: S-1.1: No “out of limits” or “out of trends” are identified. S-1.2: The testing is approved in the IT system.S-2.1: An issue is identified. S-2.2: A QCNC is generated.Alternate/Exceptional Flows: A product that should not be approved gets approved by the Senior QC scientist by mistake. A product recall is generated. If an error is spotted, or there is a result that is outside of tolerance, then a QCNC must be generated. Use-case Name: Product releaseID: 6Importance Level: HighPrimary Actor: Senior QC StaffUse-case Type: Detail, essentialStakeholders and Interests: QC Staff – wants the product to be successfully releasedTrigger: Data input use-case. Type: InternalRelationships: Association: Data input Include: Extend: Generalization: QC product testingNormal Flow of Events: Sign off batch confirming release Manually label approved product with “pass” stickers. A certificate of analysis is generatedSub-Flows: N/AAlternate/Exceptional Flows: N/A Use Case Diagram The use-case diagram produced represents the actors, use-cases and the relationships between them. It helps show how the system interacts with the user and indicates the actor’s activity with the system. When comparing the use-cases for the current processes and the intended system, it is clear that the new system will be more efficient which is indicated through the fewer number of use-cases of the intended system. By cutting out the ‘data input’ use-case, the intended system will be more streamlined and have a better flow of data. The system boundary has been defined excluding the database from our current system design. It is important that realistic goals can be achieved within the scope of this project. Consultation with the client (appendix A) made it clear that database management lies outside the control of the QC department, and as such designing a system that can work independently from the database system, whilst still considering its future potential incorporation is the best course of action. Figure 4.1: Use Case Diagram. Activity Diagrams The activity diagrams below provide a visual representation of the use-cases developed previously (section 4.1.2). This represents the step-by-step processes of the system which indicates the workflows between use-cases. The main purpose of activity diagrams is to capture the dynamic behaviour of the system. The activity diagrams have been proposed and designed with regards to the current system so as not to change or overhaul any of the testing processes, but to simply provide a more efficient and secure platform to record test results. Moreover, the decision nodes for each activity diagram are essentially contingent upon errors occurring during the testing processes, whereby QCNCs are generated, and investigations carried out if required. If no errors occur, then the activity diagrams are straightforward with no branching. Product Receival Product Testing QCNC Generation Approval of record data Structural ModellingClass Responsibility Collaborator (CRC) Cards CRC cards are used to document the responsibilities, collaborations, attributes and relationships of a class (Dennis, Wixom and Tegarden, 2015, pp. 172; Dalton, 2019). The CRC cards were developed from the use-cases, where the initial objects could be brainstormed, and the responsibilities defined for a more object-oriented view of the intended system. However, when initially creating the CRC cards, we overlooked the implementation of the Log and Interface classes. It wasn’t until we began developing the class diagram that we were able to identify missing features of the system. This is likely because the class diagram provides a better visualisation of the system whereas the CRC cards are good for establishing more precise details of each class. Because of the agile approach we have taken as a group, we were able to revisit the CRC cards to add the additional classes. FRONTClass: EmployeeID: 1Type: Concrete, DomainDescription: This class contains the information of each employee.Associated Use-cases: Product receival, Product Testing, Approval of record data.Responsibilities: Define employee responsibilities through authentication level. Hold data relevant to employee.Collaborators:BACKAttributes: Employee ID (string) Name (string) Role (string)Relationships: Generalization (a kind of) –Aggregation (has parts) –Other Associations – Worksheet FRONTClass: WorksheetID: 2Type: Concrete, DomainDescription: This class represents a digital worksheet that is used to record test results for various products.Associated Use-cases: Product testing, data input, GCNC generation, approval of record data.Responsibilities: Record product test results Log user’s actions Generate QCNC Attach image/videoCollaborators: Interface Attachment Log QCNCBACKAttributes: Batch Number (string) Tests to be carried out (string) Date (string) Test Results (string)Relationships: Generalization (a kind of) –Aggregation (has parts) – QCNC, Attachment, LogOther Associations – Interface, Product FRONTClass: InterfaceID: 3Type: Concrete, Domain, PublicDescription: This class represents the main Graphical User Interface of the system.Associated Use-cases: Data input, Product receival, QCNC generation, Approval of record data, Product release, Approval of record data.Responsibilities: Log in to the system. Provide access to worksheets and associated QCNCs. Provide access to logs. Create new product object for pending testingCollaborators: LogBACKAttributes: Title (string) Label (string) UI Buttons (button) Graphics (string)Relationships: Generalization (a kind of) –Aggregation (has parts) – Other Associations – Employee, Worksheet FRONTClass: AttachmentID: 4Type: Abstract, DomainDescription: This class contains image or video data associated with certain product tests.Associated Use-cases: Product Testing, Approval of Record DataResponsibilities: Provide evidence of test data in the form of video or image dataCollaborators: Employee InterfaceBACKAttributes: Batch Number (string) Test type (string) Result (string) Date (string)Relationships: Generalization (a kind of) –Aggregation (has parts) –Other Associations – Worksheet FRONTClass: LogID: 5Type: Concrete, DomainDescription: This class contains a data log of all activities undertaken associated with the worksheet.Associated Use-cases: Product Testing, Approval of record data, QCNC generationResponsibilities: Provide timed and dated evidence for each step of the testing phase, and who was responsibleCollaborators: Employee InterfaceBACKAttributes: Batch Number (string) Testing Step (string) Time and date (string) Employee ID (string) Checker’s name (string) QCNC code (string)Relationships: Generalization (a kind of) – Aggregation (has parts) – Other Associations – Worksheet FRONTClass: QCNCID: 7Type: Concrete, DomainDescription: This class contains all information on QCNCs generated.Associated Use-cases: Product receival, Product Testing, QCNC Generation, Approval of record dataResponsibilities: Provide a thorough description of the error and how it occurred. Provide investigation and evidence of steps taken to resolve the error. Provide a potential solution to minimize chances of error repeating in the future. A sign off by manager confirming QCNC investigation is complete.Collaborators: Interface Employee ManagerBACKAttributes: Batch Number (string) Time and Date (string) Description of events (string) Employee ID (string) Description of resolution (string)Relationships: Generalization (a kind of) –Aggregation (has parts) – Other Associations – Worksheet FRONTClass: ProductID: 8Type: ConcreteDescription: Thisclass represents an object product.Associated Use-cases: Product receival, Product Testing, QCNC Generation, Approval of record dataResponsibilities: Store data related to the products, such as test type, storage conditions etc. Provides samples for testing against using worksheet.Collaborators: InterfaceBACKAttributes: Batch Number (string) Product Name (string) Product Units (integer) Storage condition (string) Product description (string)Relationships: Generalization (a kind of) –Aggregation (has parts) –Other Associations – Worksheet Class Diagram The class diagram depicts how the classes of the system will interact, along with the attributes and operations that a class can carry out. The Worksheet class is central to the system. QCNCs, digital Worksheet Attachments (photos, video) and the Log can be accessed and triggered through and act as appendices to the worksheet class, which will tie up all relevant information on any testing process for any give product and batch number. Employees of all levels can access the digital worksheet system through the digital interface. The manager can set permissions based upon the employees given role as well as create and delete users through the interface. This system redesign will allow for greater levels of data integrity and make the system better fit-for-purpose as per the client requirements. According to Scott and Fowler (1999, Chapter 4: Perspectives) “… the key to effective OO programming is to program to a class’s interface rather than to its implementation.” Therefore, the class diagram and the operations of all classes have been designed in such a way that they should be applicable to any form of practical implementation into a physical system. This is particularly notable in the Interface class, where the attributes and operations have been made as encompassing as possible for various potential practical implementations. As such, there is no need to fully model the software that may handle these operations. During the development of the class diagram, we decided to implement a log class that is responsible for recording the actions performed on a worksheet by a particular user and at what time. This would be extremely beneficial to the QC staff as it would provide a full paper-trail of the actions carried which is required by the MHRA (Medicines and Healthcare Regulation Agency). Figure 5.1: Class Diagram Object Diagram The object diagram below shows an instance of a specific employee (a QC scientist) completing a worksheet for Sodium Chloride testing, with a triggered QCNC and attachments and log. The employee accesses the worksheet system through a username and password and takes a product sample for testing. Tests, results and all associated worksheet activities are recorded in the log. Figure 5.2: Object Diagram Behavioural ModellingSequence Diagrams The sequence diagrams shown below provide an illustration of the objects that participate in a use-case and the messages that pass between them over time (Dennis, Wixom and Tegarden, 2015, pp. 204). These diagrams help to understand the real-time specifications of the intended system and depict the flow of control for a scenario by time. Product Receival Product Testing QCNC Generation Approval of Record Data and Product Release Communication Diagrams The communication diagrams below illustrate a detailed view of all the different communication processes in the proposed system based on the Sequence Diagrams presented above (Satzinger, J. et al., 2000). Furthermore, Ambler W. Scott (n.d) further discusses the fact that each of the diagrams must describe the message flow and the relationships between the different classes and actors attributed to the system. Subsequently, the processes presented in these diagrams are equivalent to the ones given in the sequence diagrams as both describe the dynamic structure of the system chronologically. However, Communication Diagrams usually bring a more obvious and intuitive representation which is why they are very pragmatic when it comes to having a “simpler” understanding of the overall behaviour of the system. Product Receival Product Testing QCNC Generation Approval of Record Data Product Release Behavioural State Machine The Behavioural State Machine Diagrams provided below show an insightful representation of the behaviour of the processes within each use-case of the system (Fakhroutdinov, n.d.). Moreover, each of them clarifies and describes the different states and the evolution of each procedure over the occurrence of different events. In addition to this, Fowler M. (Chapter 10: State Machine Diagrams, pp. 85/113, 2013) mentions that “state machines can only show what the object directly observes or activates” and as mentioned before, it can be said that Behavioural State Machines are a mere representation of actions happening and reacting to situations making them change their behaviour. For example, the Product Receival State Machine is a very straightforward process since each state can only transition to a single next state (state: blue box). However, in the Approval of Record Data, depending on the results of the testing for a specific product, the “Testing” state could transition to the “Confirm” state or to the “Error” state, depending on any errors detected throughout the testing of a product. Product Receival Product Testing & QCNC Approval of Record Data Product Release CRUDE Matrix According to Dennis et al, (2015, pp. 228-229), a CRUDE matrix can be used to as means to gain a better system-wide understanding of how the classes of an object-oriented approach interact and collaborate. Classes are labelled with the interactions C(reate), R(ead), U(pdate), D(elete), and E(xecute). Dennis et al state (2015, pp. 230) “CRUDE analysis also can be used to identify complex objects. The more…entries in the column associated with a class, the more likely the instances of the class have a complex life cycle. As such, these objects are candidates for state modelling with a behavioural state machine”. Due to the agile approach taken to this project, this has allowed us to identify the importance of specialising the employee class into specific roles and make changes where necessary to the class diagrams and behavioural models. As the Worksheet class is central to the system, it has the most interactions of any class. Key – C (Create), R (Read), U (Update), D (Delete), E(Execute). Group Report Following the assignment brief, we arranged our first group meeting as soon as possible in order to organise ourselves for the upcoming work and to meet and greet one another. One of the first tasks we carried out was the development of a code of conduct document (appendix B), in which we established the guidelines we must all follow regarding the way in which conduct ourselves and treat other group members. In this document we also agreed upon a regular meeting time and determined the ways in which our group would operate. In one of our early group meetings (appendix C.1), we agreed we would all present a project idea for the following week. As it so happened, Hugh proposed a project idea that related to enhancing the QC processes at his old workplace Newcastle Specials (a pharmacy production unit based at the RVI Newcastle Hospitals foundation). Liking the idea of using a real-world client and the challenges of taking on a more complex project, we were eager to make a start. Furthermore, Hugh was also the one to reach out to Adam Walker, our project sponsor, in order to set up our first meeting (appendix A). Adam was very communicative and collaborative, which helped us to have a bit more insight of how we could design our project to fit Newcastle Specials needs. Subsequently, we decided to work together in our Microsoft Teams environment so as to keep all of our work and progress in one single place. The main reason for this, was due to Covid-19 restrictions that meant we would have to carry out our work remotely. The storage and organisation of work was mainly carried out by Joel and Ismael. We undertook an agile approach throughout the development of this project. A solid work ethic lay the foundations for group, as we consistently met and produced work that could be used or reviewed for the project later down the line, which had the benefit of easing the workload towards the project deadline. Whilst we initially assessed objectives and completed rough drafts of diagrams as a group, we would reconvene and reassess the work done prior to establish if any changes were needed after completing later objectives in the project. For example, after we made changes to our activity diagrams after completing our class diagrams, we realised the process was not mapped out correctly. Individual members would then go back and make adjustments based upon any discoveries (errors, improvements, flaws) and show their work to the group. Upon final group approval, we would submit the work to the final document draft. Much of the work was done in different documents and Joel took on the responsibility of combining all the work carried out into one single document. One of the key problems we encountered was related to the creation of diagrams, where collaborative software of model creation was limited. For example, Visual Paradigm has a collaborative feature that proved inefficient for our group. Additionally, Lucid-Chart, which although seemed like a good alternative at first, had limited features that restricted our group. To mitigate this issue, a lot of the diagrams were split amongst the group members and, in some cases, required one person to create the diagram while sharing their screen. This ensured that group members could offer advice and input for the development of larger more important models. All models for the assignment were created using Visual Paradigm software. In terms of developing our understanding of the concepts relating to system analysis and design our groups agile approach involved reading up on and revisiting topics as and when needed. Additionally, there were times our group members did not agree on certain decisions. This was mitigated through extensive discussions which were always resolved and resulted in a more detailed and consistent design, and a more comprehensive overview of the intended system. Listed below is a breakdown of the individual contributions: Executive summary – Joel, HughSystems Request – GroupFeasibility Analysis – GroupCost benefits – Joel, HughRequirements – GroupUse Case Descriptions – GroupUse case diagram – GroupActivity Diagrams – GroupCRC Cards – GroupClass Diagram – Group finished by HughObject Diagram – HughSequence Diagrams – JoelCommunication Diagrams – Group finished by IsmaelBehavioural State Machine – IsmaelCrude Matrix – HughGroup Report – Group To conclude, we as a group have learnt a lot about the planning and analysis phase of system design as well as the ability to work in a group effectively despite the current circumstances regarding Covid-19. We have maintained good communication and followed our code of conduct throughout the duration of this project. References REFERENCES Ambler W, S. (n.d). “UML 2 Communication Diagrams: An Agile Introduction”. [online]. Advanced online publication: [Accessed April 2021]. Bolloju, N. and Sun, S. X. Y. (2012). “Benefits of supplementing use-case narratives with activity diagrams – An exploratory study”. Journal of Systems and Software, Vol 85(9), pp. 2182-2191. Advanced online publication: [Accessed April 2021]. Dalton, J. (2019). “Class, Responsibilities, Collaborators (CRC) Cards”. In Great Big Agile, pp. 152-154. Advanced online publication: [Accessed April 2021]. Dennis, A., Wixom, B. H., Tegarden, D. (2015). “Systems Analysis & Design: An Object-Oriented Approach with UML”. 5th ed. New Jersey, Wiley Publisher. Fakhroutdinov, K. (n.d). “State Machine Diagrams”. uml-diagrams.org [online]. Advanced online publication: [Accessed April 2021]. Fowler, M. (2003). “UML Distilled: A Brief Guide to the Standard Object Modelling Language”. 3rd ed. Addison-Wesley Object Technology Series. Satzinger, J., Jackson, R. B. and Burd, S. D. (2000). “System Analysis and Design in a Changing World”. Advanced online publication: [Accessed April 2021]. APPENDIX A Client Contact CLIENT CONTACT This appendix shows the communication group 04 were able to establish with their project sponsor. Interview Transcript The following transcript is from a video call with client Adam Walker, Quality Controller for Newcastle Specials and the project champion (note that it has been edited to contain the relevant information). (G – Group, A – Adam) G – “Hi Adam. Would you like to tell us about Newcastle Specials Quality Control systems and areas that could be improved?” A – “Sure. Currently we use a system that is not 100% fit for purpose. Testing on certain machines and equipment is fine because there is the option to retrieve data from the machine for any batch number. For example, our Chromatography machines automatically record and backup data to a server. However, we have issues with some of our other equipment where test record data is not retrievable, such as with our pH meter and conductivity meter.” G – “So then you would need changes to the system that allows contemporaneous data recording and the ability to retrieve evidence of test data?” A – “Yes, a change to a more secure, searchable data system for these types of machines would benefit data integrity” G – “Great. Are there any other concerns about your systems?” A – “We could improve our efficiency in product release and save printing, paper, and storage costs.” G – “In what way?” A – “We use a lot of paper in our worksheets, and even more when a QCNC is generated. We must also archive worksheets for 5 years, which means the storage costs add up. When releasing a product, we must go onto the database and manually release and print a certificate of analysis, then after releasing and labelling the product we must inform Production Stores that the product is ready for dispatch” G – “So would an ‘online’ or ‘live’ system that stores digital worksheets be beneficial?” A – “Transitioning to a paperless system would save both time and money and allow other users such as production store staff to view the progress of a worksheet or batch without having to contact us directly.” G – “A digital system would require some kind of log in and authentication system, we could also log all worksheet related activity to the logged-in user if that sounds beneficial? A- “That would be great, as it would allow us to show a ‘paper trail’ for any given product and related activity” G – “Excellent. Roughly how much time do you think we could save the lab with this new system? We could cut out the manual database input by linking the new system to the database and allowing digital upload, for example.” A – “A QC scientist probably spends at least 2 hours per week submitting data to the database, by manually inputting the results from our paper worksheets into the database.” G – “Would this also make sure that the data on the worksheet is correctly transcribed, cutting out errors at this stage?” A – “Correct, it would increase data integrity.” G – “How about your database”? Do you think integrating it into our system is feasible?” A – “I’m not sure as we would have to involve IT. Our database is due renewal at some point in the not-too-distant future and we aren’t sure what the plan is yet in regard to that. It would be best to avoid it for now and focus on making our testing systems fit for purpose.” G – “That should be enough questions for now. Can we send you an email with some follow up questions regarding costs and future plans for the business? A – “That will be fine, I will not be able to answer all questions relating to business but send it over and I’ll do my best.” G – “Great thank you, and thanks for the meeting.” A – “No problem, speak soon.” Follow up email APPENDIX B Code of Conduct CODE OF CONDUCT This appendix shows the code of conduct used throughout the work carried out by group 04. 1. Introduction to the Code of Conduct: This document outlines the aims of conduct for Group 04, including but not limited to the adequate fairness, decorum and manner of conduct that all group members, regardless of task, must follow. Failure to follow these guidelines will result in the consequences stated later in this code of conduct being enforced. 2. Guidelines: Respect We won’t all agree all the time, but disagreement is no excuse for disrespectful behaviour. We must respect all aspect of a group member including their ideas, time and values. We will all experience frustration at times, but it is unacceptable to allow that frustration to become personal attacks. An environment where people feel uncomfortable or threatened is not a productive or creative one. Fairness Be patient and courteous, all team members opinions and ideas are to be respected and taken into consideration. All team members are treated equally, and work is spread out fairly. Equality of Opportunity & Inclusivity Everyone should have ample opportunity to speak, write, or otherwise contribute to the progress and direction of the project. Considerate We all depend on each other to produce the best work we can as a group. Each of our decisions will affect our end grade, and we should take those consequences into account when making decisions. We should always at least consider someone’s idea’s and they are not to be disregarded until further explored or discussed. Compromise All group members must be willing to compromise on their ideas of the correct direction of the group and must strive to find a middle ground to peacefully resolve conflicts of ideas. Group members must be free to voice their opinion, as there is a strength in diversity of opinion. The group must work towards a compromise of ideas, and towards a common purpose, to integrate different ideas and viewpoints. Harassment, Discrimination & Bullying In general, if someone asks you to stop something, then stop. When we disagree, try to understand why. Differences of opinion and disagreements are mostly unavoidable. What is important is that we resolve disagreements and differing views constructively. Under no circumstances are harassment, discrimination or bullying of any kind to be tolerated in the group. Encouragement & Support If a group member needs help with a task, other group members are expected to lend a hand to an extent. For our group to do well and produce the best work we can it is important that people feel comfortable to ask for help amongst the group. It’s a good idea to encourage each other on tasks and to praise each other when someone has done well. Also, to encourage someone to do better and offer help rather than diminish them if they don’t perform well. Self-Identification and self-evaluation All group members have different backgrounds in one way or another, leading to different skill sets and differing strengths and weaknesses. All group members must be open to discussing their strengths and weaknesses and areas that they could improve. This will allow for the optimal distribution of work and will reinforce the ideas set out in section “Encouragement and Support”. Group members should not ridicule, put down or demoralise other group members if there is an area in which somebody may be lacking knowledge or confidence, and instead see what they can do to help or redirect work in such a way that it is positive and productive. 3. Leadership It may be beneficial to have a group moderator to manage and coordinate the group. In order to maintain an element of fairness, group 04 have agreed to elect a different group moderator each week. This will ensure that everyone gets a chance to represent the group and experience a more managerial role. The responsibilities of the group moderator will include: Carrying out the notification points highlighted in section 5.Act as the moderator in timetabled sessions. This will involve speaking to the tutor, receiving tasks for the session and passing them on to the rest of the group.Complete the meeting minutes document for that week. 4. Group Meetings Details Every Monday at 12:00 via MS Teams. Everyone to attend unless they have a valid reason for not being able too. Procedures All group members will be notified of the weekly group meeting at least 24 hours before-hand, to ensure everyone is aware by the team moderator that week. At the end of these meetings, a simple meeting minutes document will be filled out detailing the key points made and aims for the coming week. In addition, group 04 have decided to complete a meeting review document every 4 weeks during this assignment. This involves individually completing a review template that will provide insight on how the meetings are going and to ensure everyone is comfortable in the way the group is operating. Reasons Regardless of the project situation, it is important to have allocated time each week where adequate face-time can be made possible. Even if to just have a quick catch-up, this will help in ensuring everyone is on task and can get the help they need. It is an opportunity to collaborate, design and make decisions as a group. How To carry out the procedures and the way our group operates we have a group chat on WhatsApp for general queries and discussions. This is great way to contact all members of the team at once and to keep everyone updated and aware of things relevant to the group. We also have a MS Teams group, that is used for our weekly face-to-face collaborative sessions. The MS Teams also provides a method of making all project documentation accessible to all team members including: The code of conductMeeting minutesInitial ideas and notes 5. Decision Making Group 04 have agreed to adopt a majority voting style when it comes to making decisions as a group. Any decisions regarding the direction of the group work will be decided by a majority vote where the minority inputs are listened too and implemented where possible. If a decision cannot be reached, compromises must be made until so. 6. Notification Group members must be notified 24-hours before a scheduled group meeting takes place by the team moderator that week. Group members must inform the group if they are unable to attend a scheduled meeting with 24-hour notice. Exceptions will be made for valid reasons. 7. Consequences Policy Depending on the circumstance and severity of the offense, an infringed group member will be fined either a grade 1, grade 2 or grade 3 punishment. Procedure Grade 1: The offender must write a hand-written apology addressed to the members of group 04, that states their sincere regret and humble apology for their actions. The letter must state what they are sorry for and what they have learnt as a result. Grade 2: The offender must perform a silly dance move in the next group meeting for all others to see. This will be recorded for evidence and future reviewing purposes. Grade 3: The offender will receive one strike towards the groups 3-strike-policy. If a group member receives 3 strikes, they will be reported to the module tutor and face potential expulsion from the group. How In order to enforce the consequences agreed upon by group 04, appendix C provides a simple table template that will allow all infringements to be monitored and recorded. APPENDIX C Meeting Minutes MEETING MINUTES This appendix shows some of the meeting minutes recorded throughout the assignment. C.1 Meeting 01 GROUP 04 MEETING MINUTESModerator for the week: Joel PearsonDate:01/02/2021Attendees: Joel Pearson Hugh Woodford Ismael J Gomez Akramul I FahimWhat did we do last week? Meet and greet. Produced the final coded of conduct document. Established means of communication – via MS Teams and WhatsApp.What are we doing this week? Produced initial ideas document Review and discussion Share of potential ideas for the Assignment 1 + word document Focus on potential clients and ideasPotential blockers: Covid-19 – hard to see client’s face to faceNotes: Any more ideas (no matter how detailed) we can add to the initial ideas document for the week. The overall GOAL for the week is to have a final client and potential proposed system decided by the start of week03.