SEO Suggestions for Desklib - Online Library for Study Material

This document contains SEO suggestions for Desklib, an online library for study material. It includes information on possible entities, use cases, and actors, as well as work breakdown structures and use case diagrams for various projects. Additionally, it provides strategies for data migration and testing.

COVER PAGE

Contents
Portfolio One...............................................................................................................................................3
Question one...............................................................................................................................................3
Question two...............................................................................................................................................5
Portfolio No 2..............................................................................................................................................7
Portfolio No 3..............................................................................................................................................9
Question One...........................................................................................................................................9
Question two.............................................................................................................................................10
Portfolio No 4............................................................................................................................................11
Portfolio No 5............................................................................................................................................15
References.................................................................................................................................................16

Portfolio One
Question one
i. 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)
ii. 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
iii. Use case diagram

Figure 1: 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.
Process of student registration
The student registration process takes place through the following steps;
a. 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.
b. A student registers for the course. Upon successful registration, the student gets a fee
statement.

c. The student pays for the course as per the fee statement.
d. The service department employee approves the payment.
e. The course registration is complete and the student can view the time table.
Question two
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
o Register
o Make appointment
o Request appointment reschedule
 Staff
o View appointments
o Approve appointment
o Send reminder
o Reschedule appointment
3. Use case diagram

Figure 2: Q2 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.

Portfolio No 2
a. Entities and their attributes.
 Customer entity
o customerNO (primary key)
o firstName
o lastName
o streetName
o suburb
o postcode
o city
o state
o dob
o officeNumber
o officePhone
 Vehicle entity
o regNO (primary key)
o make
o model
o colour
o pricePerDay
 Reservation entity
o reservationNO (primary key)
o regNO (foreign key)
o reservationDate
o expectedRentalDate
 Booking
o BookingID (primary key )
o regNO (foreign key )
o customerNO (foreign key )
o staffNO (foreign key )
o dateBooked
o returnDate
o totalCost
o terms_conditions
o reservationNO (foreign key, null)
b. Entity relationship diagram

Figure 3: ERD

Portfolio No 3
Question One
A- 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
B- Start and finish date and the critical path.
Start Date- Mon 9/11/18
Finish date- Fri 11/10/2018
Critical Path

Question two
A- 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

Portfolio No 4
Task
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;
o 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.
o 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.
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;
o Unit testing
o Component testing
o Integration testing
o 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;

Figure 4:MobCarHire 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

Portfolio No 5
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.
Post-migration testing
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