A standard OO model for the system (some scenarios, all class diagrams and some sequence diagrams) will be released after the Assignment 1 due date, along with details of the database schema. You may then use your group members’ joint experience of developing their own OO models to determine the rest of your design. You may also deviate from the standard design as you see fit. This will give different development teams some freedom in their implementation choices.
OO Model versus WPF
In the OO model each view is a separate class, which in WPF corresponds to defining a UserControl for each major view. Because this may complicate some of the event handling code, it is acceptable in the assignment to place separate views directly within the main window. Note, however, that the HD level of the Use of WPF assessment criterion requires that at least one user control be defined, and that defining your own controls will actually make each individual source file easier to manage.
WPF is not available in MacOS; development of the GUI and the final stages of the software will need to be completed in Windows.
1/4 KIT206 Software Design & Development KIT506 Software Application Design & Implementation
Development approach
Because the final application requires knowledge of the C# language, how to communicate with a database using C# (and LINQ) and how to design and construct GUIs using WPF, and because these topics are to be covered over a period of some weeks, as foreshadowed in the Week 6 lecture, we recommend that you take a prototyping approach to the development of this application. This will allow you and your team to make useful progress on parts of the system even before you have obtained the skills required to implement the whole system. (Note that this will likely entail some manual copying of source files between projects as you migrate from a console application to a WPF application.) We suggest the following implementation stages (you may of course adopt a different development path if you find it suits your team better):

OO Packages and C# Namespaces
As C# applications have a top-level namespace, which was not part of the OO Design, we recommend that each package in the OO Design becomes a nested namespace within your application’s top-level namespace (which should be HRIS). Note that the namespace and project name do not have to be the same, even though Visual Studio will initially make them the same.
The School Database (aka HRIS Database)
The case study MySQL database is available via the following settings:
Database: kit206
User Id: kit206
Password: kit206
Data Source: alacritas.cis.utas.edu.au
A2 Release 1: 2020-08-27 2/4
KIT206 Software Design & Development KIT506 Software Application Design & Implementation
You can also browse the data via phpMyAdmin (append that to the end of the server name). As the database is shared it will not appear in your own list of databases on alacritas if you log in under your own user name. An EER Diagram for the database plus some details on enumerated value columns accompanies this document. If you are not on campus, you will need to use VPN (https://utas1.service-
now.com/selfservice/?id=kb_category&kb_category=c06bbabbdbd86bc08bf8413b3a9619bb) to access the database.
Data quality
The database is currently live and contains fictitious data. The data are consistent in that foreign key relationships are all valid, although initially there will not be much information in the database. More entries, or more realistic entries, may be added later in semester, but this is not guaranteed.
The Testing Report
Concurrently with development of the application you will create a test plan containing four test cases to verify the following subset of requirements in the HRIS RTM:

• SWC 1 (Entry 1 in the RTM)

• UC8_User_views_StaffList

• UC16_User_selects_StaffDetails

• UC24_User_selects_Unit

Each test case will be based on the Test Report Template, which is available on MyLO. Each test case that is based on a use case should include at least two methods by which the requirement will be tested. NTH features of use cases should also be tested and so will provide additional methods, even if they were not implemented; the quality of the test case will be assessed, not the one line outcome of whether it passes or not. The test cases for the SWC will likely need only one, brief method in order to be tested.
Ensure that all instructional entries (Repeat the following box…, , Repeat Method and Outcome…) and unused method–outcome rows are removed from your submitted test plan. The document should include a title and your team name on the first page; the first test case can start immediately below that.
When the application is complete, apply the test plan to it and record the outcome for each method. Remember that if the outcome is ‘fail’ then an explanation of when (which step) or how must also be recorded.
Sources of information for compiling the testing plan
Follow the procedures described in Module 5 Use case-Based Testing to derive the test cases for the indicated SWC and SW entries. The RTM will be your primary resource for identifying the criteria for each test case. The original requirements document may also provide some useful information. The structured scenarios you prepared during Assignment 1, in conjunction with the specific application being tested, will provide the basic structure of the testing methods in each test case, since they describe the user’s actions in each use case.