Entity Modeling, Use Case Modeling, SDLC, And Data Migration Strategies

1. The Middle East College has two programs for the undergraduate students. The students have to access the college website to check the time table of the courses and for registration. When the student pays the course fees he/she get the fee statement. At the student service department, the employee prepared the course time table and updates courses information as required. The student service director can access the payment system to check the student’s details including payments, courses registration, and time table. The number of students registered at any course can be viewed by the lecturer, instructor and tutor.

1. List possible entities in the registration system, including their attributes.
2. Identify possible use cases and actors.
3. Draw the use case diagram that explain the students process of student registration.

You may need to make some assumptions with the required justifications

2. You want to analyse the office operations of the Sydney Dentist Centre (SDC). When the new patient is seen for the first time at the SDC, the patient has to full a form including patient name, address, phone number, and some medical history information. This information will be store at a SDC data base file system. If the patient wants to arrange a new appointment or change an existing appointment, the receptionist checks the appointment schedule file for an available time. An appointment is schedule for the patient when a suitable time is found. If the patient is a new patient, an incomplete entry is made in the patient database file system. The incomplete information to be completed when the patient arrives for the appointment. the receptionist usually reminds the patient about their appointment by mail and SMS messages in one week before the appointment.

1. List possible entities in the Sydney Dentist Centre System, including their attributes.
2. Identify possible use cases and actors.
3. Draw the use case diagram.

You may need to make some assumptions with the required justifications

Entity Modeling

1. Possible entities and their entities.

The possible entities from the case study are;

• Course(courseID, courseName, description)
• Unit(unitID, unitName, description, courseID)
• Unit_teachers(unitID, staffID)
• Staff(StaffID, firstName, lastName, address, annualSalary, type)
• Student(studentID, firstName, lastNmae, address, email)
• Registration(regID, courseID, studentID, regDate)
• timetable(unitID, staffID, day, startTime, endingTime, room)
• payment(paymentID, regID, amount, paymentDate)

1. Possible use cases and actors

Actors

• Student
• Director (student service director)
• Teaching staff (lecturer, instructor or tutor)

Use cases per actor

Student

• View courses
• Register for a course
• View fee statement
• Pay for a course
• View timetable

Director

• Confirm payment
• Manage courses (includes adding, updating or deleting a course)
• Manage timetable
• View student registrations

Teaching staff

• View student registrations
• View timetable
• Use case diagram

The use case diagram is modelled based on the following assumptions;

• Courses offered at the college each has more than one units. The unit can be taught by a one or more of the teaching staffs be it a lecturer, instructor or tutor.
• The units making up a course are used to make a timetable where by the timetable is based on the days of the week. A unit has an allocated time slot for a specific day of the week and a specific teaching staff is allocated to that lesson.
• A student pays for a course after registration. The registration process involves registering for a specific course to then generation of the fee statement which is used to pay for the course for the course registration to be successful.
• The service department employee approves the payments done by students for course registrations.

The student registration process takes place through the following steps;

1. A student views courses and selects a specific course to view more details. From this interface the student can see the units making up the courses and the teaching staff that are in charge of teaching staff.
2. A student registers for the course. Upon successful registration, the student gets a fee statement.
3. The student pays for the course as per the fee statement.
4. The service department employee approves the payment.
5. The course registration is complete and the student can view the time table.

1. Entities and their attributes;

• Patient entitity

Patient (patientID, firstName, lastName, address, phoneNO, medicalHistory)

• Appointment entity

Appointment (appointmentID, date, time, patientID, staffID)

• Staff

Staff (staffID, firstName, lastName, position)

2. Use cases and actors

Actors

• Staff (i.e. receptionist)
• Patient

Use cases per actor

• Patient
  • Register
  • Make appointment
  • Request appointment reschedule
• Staff
  • View appointments
  • Approve appointment
  • Send reminder
  • Reschedule appointment

3. Use case diagram

The use case diagram is modelled based on the following assumptions;

• A patient cannot make an appointment without registering as a patient in the system
• The receptionist approves appointments made by the patients.
• To reschedule an appointment, the patient makes a request and the staff reschedules the appointment if there is an available slot for the requested time.
• The receptionist sends reminders to the patients who have appointments using the system.

1. Entities and their attributes.

• Customer entity
  • customerNO (primary key)
  • firstName
  • lastName
  • streetName
  • suburb
  • postcode
  • city
  • state
  • dob
  • officeNumber
  • officePhone
• Vehicle entity
  • regNO (primary key)
  • make
  • model
  • colour
  • pricePerDay
• Reservation entity
  • reservationNO (primary key)
  • regNO (foreign key)
  • reservationDate
  • expectedRentalDate
• Booking
  • BookingID (primary key )
  • regNO (foreign key )
  • customerNO (foreign key )
  • staffNO (foreign key )
  • dateBooked
  • returnDate
  • totalCost
  • terms_conditions
  • reservationNO (foreign key, null)

1. Entity relationship diagram

• Work breakdown structure

Task ID	Task Name	Duration	Predecessor
1	System deign	5 days
2	Subsystem A design	5 days	1
3	Subsystem B design	4 days	2
4	Subsystem C design	5 days	3
5	Programming program A	9 days	4
6	Programming program B	5 days	5
7	Programming program C	8 days	6
8	testing	4 days	7

• Start and finish date and the critical path.

Start Date- Mon 9/11/18

Finish date- Fri 11/10/2018

Critical Path

Question two

• Work breakdown structure

Task ID	Task Name	Duration	Predecessor
1	Research	15 days
2	Understanding system requirements	14 days	1
3	Install required applications	7 Days	2
4	Writing algorithms and coding	20 Days	3
5	Debugging and testing	8 Days	4
6	Deplyoying and miantaining	5 Days	5

Start date- Tue 9/11/18

Finish date- Fri 12/14/18

Critical path 

To develop the MobCarHire App there are seven phases of the software development life cycle (SDLC) that the project will go through from when the project is started until when the project ends and the application is used by the client. The phases of the SDLC are;

• Planning

This is the first phase of the project life cycle. The planning phase involves defining the scope of the project in order to determine the project plan to be followed throughput the life cycle of the project. Planning involves coming up with the project budget that will be used to acquire resources and to pay for expenses during the project life cycle. At this stage the project team also helps the client to do feasibility analysis to determine whether the project is worth the investment or not. Depending on the results of the feasibility study, the client can either decide to proceed with the project or to continue using the same system. Another key element that is formulated at this phase is the project schedule. The project schedule outlines all the activities that will be carried out during the project life cycle and the amount of time each activity will take. This is mostly done using a work breakdown schedule which outlines all activities, their timelines and the resources including the team members involved.  Project planning is very important phase of the SDLC and should always be done carefully to make sure the blueprint of the project is clear and accurate. This minimizes the chances of project failure as poor project planning is one of the most common causes of project failure.

• System analysis and requirements engineering

This phase comes after the project plan has been formulated and analyzed to check its accuracy. This phase involves analyzing the business requirements of the client by conducting research so as to come up with the requirements of the system (Architects, 2017). Research can be done using various techniques depending on the type of business but for the proposed MobCarHire business the ideal research techniques to be used are;

• Interviews- Use of interviews is a costly and convenient way of gathering requirements. The type of interviews to be conducted is semi-structured interviews which are a combination of the structured and unstructured interviews. Thus the requirements gathering team will prepare a list of questions to ask employees at the client’s business and allowing the respondents to deviate from the questions so as to get more information from the clients.
• Observation- Observation is another technique that will be used for requirements gathering for the proposed MobCarHire application. This technique requires minimal resources to conduct. For the proposed system, the observation technique can be applied by sending the requirements gathering team to the client’s business premises for a few days. The team is supposed to engage in the business activities of the business so that they can get a better understanding on the business process that is followed by the business. After observation is done, the requirements gathering team is supposed to come up with a report consisting of the requirements that they have gathered.

Use Case Modeling

The two requirements gathering techniques are very effective when used together thus they will be used interchangeably for the proposed system.

After gathering the requirements and preparing a requirements document, its important to have the client review the document and approve it to make sure no requirements are missing or to identify requirements that are not described correctly. After approval of the requirements document, the requirements engineering team is supposed to review and analyse the documents to come up with a software specification document which will be used in the system design phase.

• System design

System design phase is done based on the software specification document prepared in the previous phase above. This phase involves coming up with the design of the proposed application. This can be done by use of wireframes to illustrate the design based on the specifications. The hardware and software requirements necessary to run the application are also defined for example the network infrastructure is defined if the application will be deployed in on premise server or a private cloud (Singh, 2016). Modelling of the system is also done at this phase. Unified Modelling Language is very applicable at this phase and helps the design team to model both the structural and behavioral elements of the application.

• Development

After the design phase is complete the next phase is the development phase. This is where the actual implementation of all the design models specified in the previous phase above are developed by coding. The development team can use Agile with Scrum to develop the proposed MobCarHire application. This development technique is ideal as it will help maintain a happy and motivated team thus the end result will meet all the requirements. The hardware and software required to run the application is also implemented at this phase. The database is developed and deployed.

• Integration and testing

After the development phase is done, integration and testing is done to make sure that all functional and non-functional requirements have been met. There are various types of tests done on the application including;

• Unit testing
• Component testing
• Integration testing
• System testing.

The system should pass all the tests before it is deployed for use.

• Deployment and maintenance

Deployment and maintenance is the final phase of the project life cycle and usually involves deploying the system and handing it to the owner. This phase also includes giving training to the end users. Maintenance of the system is also done in case of any bugs or patches that are needed to ensure the system I working correctly.

Work Breakdown Structure

Task ID	Task	duration	Predecessor
1	Planning	30 days
2	System analysis and requirements engineering	60 Days	1
3	System design	60 Days	2
4	Implementation	120 days	3
5	Integration and Testing	30 Days	4
6	Deployment	30 Days	5
7	Maintenance	60 Days	6

The requirements of the proposed system can be modelled using a use case diagram;

The use case is modelled based on the following assumptions

• A customer has to create an account before making any booking. However the customer can view vehicles that are available without creating an account.
• The customer makes a booking for a certain car if it’s available on the timeline they wish to have the car.
• The customer pays for the booking using the application.
• An employee can add, update or remove a car from the system.
• An employee confirms a booking done by an employee

To perform data migration there are two strategies that are supposed to be used to ensure that the migration is successful. This strategies are;

• Pre-migration testing
• Post-migration testing

Pre-migration testing

Before migrating the database from Microsoft access to Microsoft SQL Server the following pre-migration tests should be conducted;

• Ensuring that the existing database and its scope is understood for example understanding the database is made up of how many tables, the records in every tables, relationships between the tables. This ca be done using the ERD or data dictionary of the current database (Darby, 2016).
• Ensuring that the target database system is well understood by using a data dictionary or ERD.
• Understanding the data scheme for both the current system and the destination system. This should include knowing all the mandatory fields and data types.

The following tests can be done after data has been migrated to the Microsoft SQL server from Microsoft Access database;

• Inputting the wrong data- This test is done to make sure that validation rules are all enforced for example inputting data to violate a relationship between two tables like using a value for a foreign key that does not exist in the parent table. If the query throws an error then test is successful and if it doesn’t then the test has failed.
• Checking the record count for each table after the migration. If the record count is not the same as before the migration then the test is failed otherwise the test is passed.
• Performance testing- Running complex queries in both systems to test the performance. If the new database is not faster than the previous the test is failed.

References

Architects, I. (2017). SDLC: Seven Phases of the System Development Life Cycle. Retrieved from https://www.innovativearchitects.com/KnowledgeCenter/basic-IT-systems/system-development-life-cycle.aspx

Darby, P. (2016). Testing Data Migration | QualiTest. Retrieved from https://www.qualitestgroup.com/white-papers/considerations-planning-test-data-migration/

Singh, R. (2016). Software Development Lifecycle (SDLC) Phases: Explained. Retrieved from https://www.bankexamstoday.com/2016/11/software-development-lifecycle-sdlc.html