Enhancing Educational Efficiency

Part 1

i.A brief overview of the organisational problem your software system is intended to solve and how significant the problem is for your chosen organisation.

The organisation is a secondary state school, based in the UK (school x). School x is an academy converter, community school that enrols 1900, gender mixed pupils, from which 350 are in the 6th from. There are a high proportion of students from minority ethnic backgrounds, who speak English as an additional language.

The schools aim at the education of the public by promoting the development and wellbeing of the society. School x institutional goal is the development of highly literate, articulate, numerate, resilient and confident students, equipped with the qualifications and skills required to succeed in the 21st century.

The organisational problem comes up from schools need to:

Manage students’ academic progress;

Manage their finances;

Manage their operations. (121)

ii.A description of the product functionality and quality requirements, based on the requirements document template of Unit 2, Section 2.3 (i.e. the first template you encounter in that unit). You should focus on high-level requirements which clearly relate to the business rather than low-level technical requirements.

Product overview

The software solution presented will focus on the students’ academic progress and attendance. For the present problem, the financial and operational data will not be addressed.

Automation is the use of technology to produce and deliver the products with minimal human intervention (technopedia, 2021). The product aims at automating the students’ management system (SMS). SMS are crucial tools nowadays in any educational organisation for storing and processing school data such as recording students’ legal registration, achievement, and sanctions and to manage public examinations. SMS is available nowadays as COTS packages are also able to manage the financial and operational activities.

The main users of the system will be the school staff, parents and external staff. Registration, attendance record and attendance report will be carried on by the school staff, constrained by different logins and system permission. Parents and external staff will be limited to report view and it is also constrained by different logins and system permission.

Product functionality

The management of students is a continuous task in any educational organisation. The attendance registration in particular, is a legal requirement that any school has to keep and provide a record if required. Traditionally, this process has been done manually, which implies the maintenance of big carbon printed archives due to the number of classes, students, subjects, etc. This storing process ends up being very time expensive and prone to errors, resulting in poor data quality and mismanagement. Also, apart from the professionals that have access to the archives and students’ files, the parent’s reports generated by the end of each school period are also maintained. There is no possible way to track a student’s attendance without the delay gap from accessing the files and generating the report by hand. Automated students’ management system allows for a more reliable and effective student attendance registration by the teacher. Creating a SMS data base is possible to be accessed and shared between all the stakeholders as illustrated by figure 1. (317)

The functional requirements will be to:

Register a student;

Record attendance of students;

Generate student attendance reports;

View reports;

Quality requirements

Usability requirements: the system should be compliant with the school policy on accessibility.

Operational requirements: the system should be able to record, process and output students’ attendance report, possible to be viewed online through the standard web browsers.

Legal, security and compliance requirements: access to personal data should conform in line with national and international regulations, which they abide by such as the General Data Protection Regulation of the EU* (GDPR, 2016) and the Data Protection Act 1998. (94)

iii.A summary of the main stakeholders of the system by organisational role or in relation to the system, and the extent to which they have contributed to the elicitation and validation of the requirements in (ii) above.

iv. A UML use case diagram providing an overview of use cases, actors and their relationships. You should focus on sea-level use cases.

You should also explain and justify your modelling choices with respect to three requirements of your choice from (ii) above.

The use cases of the Students (Attendance Registration) Management System are identified as:

“Register student”;

“Record Attendance”;

“Generate Report”;

“View Report”; (22)

Table 1

v.A ranking of the use cases, with justification, and an indication of which use cases should be tackled first and why; you should also indicate which stakeholders were involved, and how, in the validation of the use cases and their ranking.

Table 2

The process of ranking used cases was coordinated by the SLT team. SLT team is responsible to plan and implement the national educational policies at school X. Hence, it was the SLT team decision to rank the used cases as shown above for a matter of registration process sequence and safeguarding reasons. (53)

vi.A description, based on the format introduced in Unit 2, Section 3.2, of three high-ranking use cases.

Name, identifier, version: Register student, SMS 01, Version 1.0

Initiator: Admin.

Goal: to register a new student;

Assumptions: A student has to be eligible to be registered (age; previous school; address; etc).

Main scenario:

1. Student requires to be registered;

2. Admin. checks that student is eligible;

3. Student completes registration;

4. Admin. checks if registration is complete and in the right format to be submitted;

5. Admin. submits register to the system;

6. System registers;

7. Use case ends;

Name, identifier, version: Record Attendance, SMS 01, Version 1.0

Initiator: Teacher

Goal: to record students’ lesson attendance;

Assumptions: A student has to be previously registered.

Main scenario:

1. Each classroom teacher is required to follow the school’s policy and submit the attendance record in the first 15 minutes of each lesson;

2. The teacher makes the call and registers in the system students’ attendance;

3. Teacher saves the register with the absences/late/etc., marked;

4. System saves the register;

5. Use case ends;

Extensions:

1.a User is not the teacher of that class/classroom;

2.a The student is not from that class/classroom;

Name, identifier, version: Generate Report, SMS 01, Version 1.0

Initiator: Admin

Goal: to generate the Attendance Record Report;

Assumptions: A student is/was part of a class.

Main scenario:

1. The Admin logs into the system;

2. The Admin selects the class which the student is part of;

3. The Admin selects the student;

4. The Admin requests the report to the system;

5. The system processes the request;

6. The system outputs the report with the option to carbon print;

7. Use case ends;

Extensions:

1.a User does not have Admin access;

4.a User cannot request the report;

Extension B:

3.a The student is not properly registered;

5.a The system cannot process the request;

Name, identifier, version: View Report, SMS 01, Version 1.0

Initiator: Parent/Carer/External staff

Goal: to view the Attendance Record Report;

Assumptions: A Parent/Career/External staff must be officially registered as such to have access to the system;

Main scenario:

1. A Parent/Carer/External staff logs into the system;

2. The System displays the students associated with that parent/career; the system displays the different school years and classes registered at that school for the external staff.

3. The parent/career selects the student/s; The external staff selects the school year and class;

4. The Parent/Career/External staff requests to view the report;

5. The system processes the request;

6. The system outputs the report with the option to carbon print;

7. Use case ends;

Extensions:

1.a User does not have Parent/Career/External staff;

4.a User cannot request to view the report;

Extension B:

3.a The student is not properly registered;

5.a The system cannot process the request; (444)

vii.A description of four key business processes which relate to the software system, with an explanation of such a relationship, and their relevant business rules.

Table 3

viii. A UML activity diagram model of one such process, with appropriate business rules as UML constraints. You should justify your process model and indicate which stakeholders were involved, and how, in the construction and validation of the model.

The UML activity diagram presented below, figure 3, illustrates the Student Registration Process (SRP). SRP is one of the main functional requirements that the software solution offers. The SRP checks that, the child is eligible for registration and it is a precondition for consequent operations, such as student attendance record, associated with a unique student school number to a child. The student school number will also guarantee that, safeguarding policies are kept by ensuring privacy and security.

The SRP process starts by requiring Admin login credentials to have access to the system. If successful, the user will access to the system, enabling student registration and the creation of attendance record reports. If the user does not have Admin login access, the system will impose a constrain, looping back to login.

The Admin starts by selecting a ‘new register’, followed by ‘creating new register’- filling in the student register details. ‘Submission’ is then selected, that will check if the student is eligible for registration. If yes, the registration is validated and the system will notify the user/admin that the register was successfully created. If the student is not eligible for registration, the system will enforce a constrain, looping back to ‘creating new register’ option.

The stakeholders involved in the process of construction and validation of the model, were the Governors/SLT, the Admin, and the Teacher. Governors and SLT are the stakeholders, who are responsible for ensuring that, the school complies with national educational policies. Hence, they are the ones in charge for planning and executing the educational and administrative processes that will qualify an organisation as a school. This way, it was decided between the stakeholders, that the process of managing students’ learning progress starts by the student registration in the school system. Failing to do so, the student will not be recognised as part of the school and tasks such as student attendance record cannot be performed. Therefore, it was categorical that, for logistic and safeguarding reasons, the process would be broken down into two major steps: - Register and attendance record, both operations require two distinct logins, allowing two different access limits. Not enabling a teacher’s login to perform a registration or output an attendance report, for example. (366)

ix.A UML class diagram, consistent with the artefacts produced in the previous parts of this question and decorated with appropriate constraints. You should give a brief account of how you arrived at your class diagram, e.g. any lexical analysis you may have performed.

The diagram should include appropriate classes, associations and their multiplicities, constraints, and attributes and their types; it should also discuss and justify four non-trivial modelling choices you have made, highlighting possible alternatives whenever appropriate. You should also include a related glossary.

The UML class diagram presented bellow, figure 4, illustrates the ‘Student Management – Attendance Record - System’ (SMS), as the software solution for the organisational problem proposed. The classes arrived from specification modelling, carried by grammatical parsing that focused on representing the software fundamentals and the services provided by the system as entities (OU, 2021). As illustrated by the diagram, the SMS class is defined with the stereotype <>. This is because the class SMS <> encapsulates all the other classes, such as ‘Attendance Record’, ‘Student Registration’, ‘Attendance Record Report’ and ‘View Attendance Report’. Having has attributes, the different logins required to access such <> functionalities/classes. ‘Student Registration’ requires Admin login as a constraint and it is the process that allows a ‘child’ to be recognised by the school system as a student. Hence, an association class ‘child’ was created with the constrain that a ‘child’ has to be eligible for registration. Once the registration is successful, a unique student school number, a class and timetable are associated with the student. This first step, will then allow the student attendance to be recorded, having Teacher login as a constrain, and, as shown in the diagram, the ‘Student Attendance Record Report’ to be outputted as a dependency, having also as constrain Admin login. Following the process, Report View is understood as a dependence of ‘Attendance Record Report’. In the same fashion, the modelling reason is that, without an ‘Attendance Record Report’ there is no report to be viewed. ‘ReportView’ is here taken as an <> superclass, with the subclasses ‘TeacherView’, ‘ParentView’ and ‘ExternalStaffView’. This is so, because ‘ReportView’ is the complete attendance record report, without being tailored for specific user view.

As an alternative modelling choice, there was the option to represent the different users’ views, as dependencies of ‘Report View’, but that would miss to define ‘Report View’ as an <>, which entails the other subclasses within. On the same note, the different views also lack the enough weight to be considered as independent entities. (332)

Continue your journey with our comprehensive guide to Enhancing Deal Execution and Communication Skills.

x.A specification, based on the template in Unit 4, of two system operations consistent with the artefacts produced in the previous parts of this question.

You should indicate which system class(es) your operations refer to, adding the class(es) to your previous diagram if necessary.

You should also describe the contracts embodied in your operation specifications.

Identifier, version: SMS 01, Version 1.0

Context: School X

Signature: attendance Record

Invariant: True

Precondition:

-- the student has to be registered in the system

-- the student has a student School Number

-- the student is part of a class

-- the student has a timetable

Postcondition:

-- the student attendance record is possible for every lesson the student attends

By following Design by Contract, this operation embodies the contract in Table 4:

Table 4

Identifier, version: SMS 01, Version 1.0

Context: School X

Signature: student Registration

Invariant: true

Precondition:

-- the student is not registered at school X

-- the student address belongs to the area covered by school X

-- the student school year is taught by school x

-- the student does not have any Special Educational Need not supported at school X

Postcondition:

-- a new Student Registration is created

-- and linked to a new student school number

-- and linked to a class

-- and linked to a timetable

By following Design by Contract, this operation embodies the contract in Table 5:

Table 5

b. Evaluate the extent to which the methods and techniques through which you arrived at your answer to subpart (a) above were effective. Outline any appreciable changes or improvements you would apply if you were to do it again.

The methods and techniques employed in subpart (a), allowed for a sequential learning process of modelling the software solution for the organizational problem proposed. The sequence started with the definition of the domain model (DM) as a representation of the organizational problem, followed by the specification modelling (SM) that offers a software solution for the problem defined. This first step was then carried on by describing the product overview, functionality and quality requirements that will set a first definition of the software. Stakeholders’ elicitation and validation followed, presenting the main stakeholders and in what way they have contributed to the definition of the system requirements. At this point there was an idea of what is in general terms expected from the system and the main stakeholders involved in the process. From here, the project moved on to create a use cases diagram that illustrates actors, use cases and their relationships. Use cases ranking and the definition of three high-ranking use cases took place, and business processes and their relationship and rules were defined. Steps (iv., v. and vi.), facilitated the creation of an activity diagram that offers a view of the sequential workflow of one such process, making use of business rules as UML constrains. The use cases diagram was also an essential starting point for the definition of the class diagram. The class diagram was developed through grammatical parsing, and includes classes, associations and multiplicities, constrains, attributes and types. Offering a general view of the different type of objects within the system and the relationship between them is effective. Part 1 – a., finished with the specification of two system operations and the Design by Contract that covers the specifications. The class diagram was an essential step to describe the two system operations, by looking at verbs/actions within the system and developing the steps required, referring the pre and post conditions for completing such operation. The methods and techniques used are understood as effective. The sequential flow facilitated the incremental development of the project, step-by-step. Prompting at the same time, the changes are required for improvements of previous steps. It is accepted, that the sequence followed would be applied again during the Domain and Specification modelling, till it is mastered in such a way that a simplification of the process would be possible. (378)

PART 2

Compare and contrast model-driven and Agile development as two approaches to software development for continuous integration / continuous delivery (CI/CD). You should focus on:

what is meant by Agile (software) development and model-driven development

their key distinguishing characteristics, with particular reference to the type of software development processes they recommend and support

their commonalities and differences in terms of requirements elicitation, analysis, specification and modelling practices

claimed benefits for CI/CD and acknowledged limitations of each approach, and the extent of any supporting evidence

any observation you may have on how they may differ from or align with your own software development practice and experience, and knowledge you have acquired in the module.

Agile software development, is a ‘time-boxed’ iterative software development method, which encompasses the definition of requirements and solutions through self-organizing* and cross-functional* teams’ collaboration with key stakeholders (Kushwaha, 2015). Agile methodology promotes continual integration and delivery, by adaptive planning and evolutionary development, emphasising a flexible culture to change (Sacolick, 2020). The agile movement development values are:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Model-driven development (MDD), is a software development method, which emphases the creation of domain models that represents abstract concepts of knowledge and actions that are part of the software solution (Kushwaha, 2015). This allows the reuse of standardized models, increasing productivity and improving the compatibility between the systems. MDD splits out the modelling from the coding process, reducing the risk associated with the traditional programming. Additionally, MDD enables code to be generated from the models created, allowing a better attention to software requirements (Gillis, 2018).

Both the methods emphases the importance of keeping stakeholders enrolled into the process of elicitation during analysis, with the difference that agile method is more flexible by insisting in frequent iterations and feedbacks, enrolling the stakeholders during all the development process.

Continuous Integration (CI), is a software development practice, where code is integrated into a shared code base promoting a fast feedback of the viability of the code by automated testing, allowing this way, for several teams to work effectively on the same software project. Continuous Delivery (CD), is a software development practice that makes use of automation to build, test and release software in short cycles of time. Both methods are intertwined. The development process starts with CI that creates and tests the code and is finalised with CD that releases the tested product. CI/CD is a core part of the agile methodology, allowing the teams to focus on business requirements, code quality and security, given that deployment is automated (Peterson, 2020).

In terms of implementation, CI/CD carries some challenges such as automation costs and work culture resistance. Energy, time and money are required to hire and keep developers that work with CI/CD and creating repositories in Git. On the same note, changing a work culture entails to relearn processes and this requires willingness and perseverance to do so (quintagroup, 2021).

During this first TMA, there was the opportunity to start developing an idea of what is object-oriented programming and the process of modelling with objects. How to define and document the requirements through Elicitation and Analysis in consultation with the stakeholders. The process of abstraction and building sea-level use case diagrams. The definition of business processes and rules are as Unified Modelling Language (UML) constraints. How to build an activity diagram from the business processes definition, with the usefulness of grammatical parsing for entities, relationships and properties definition. The class diagram is as a development of the use cases diagram. With its attributes, types, multiplicities, constraints, associations, etc. Design by Contract and its benefits and how to specify system operations (OU, 2021).

Bibliography

Agile 101 (2015) What is Agile [Online]. Available at:

https://www.agilealliance.org/agile101/

InfoWorld (2015) What is agile methodology? Modern software development explained [Online]. Available at:

https://www.infoworld.com/article/3237508/what-is-agile-methodology-modern-software-development-explained.html

LinkedIn (2015) Software Development-Agile or Model driven development [Online]. Available at:

https://www.linkedin.com/pulse/software-development-agile-model-driven-development-arun/

TechTarget (2018) model-driven development (MDD) [Online]. Available at:

https://searchsoftwarequality.techtarget.com/definition/model-driven-development

quintagroup (2021) CI/CD: Differences, Advantages, Challenges [Online]. Available at:

https://quintagroup.com/blog/ci-cd-differences-advantages-challenges

WhiteSource (2020) CI/CD and the Promise of Agile Transformation [Online]. Available at:

https://www.whitesourcesoftware.com/resources/blog/all-about-ci-cd/