tim
kylecs14
Project.docxProject Milestone 1: Planning
Create a plan
Step 1: Read Patterson case study for ideas
Step 2: Assign clear roles and assignments for each subtasks/activities
Step 3: Create a work plan (GANTT chart)
Step 4: Identify the critical path using a PERT chart
Step 5: Create a System Request
Step 6: Create a Feasibility analysis for technical factors.
Step 7: Create a feasibility analysis for economic factors.
Step 8: Create a feasibility analysis for organizational factors.
Step 9: Add in any Sources
Execute the plan
Step 2: Assign clear roles and assignments for each subtasks/activities
Roles & Responsibilities
|
Tasks |
Group member(s) responsible |
|
Complete a system Request |
|
|
A work plan |
|
|
Feasibility analysis for Technical factors |
me |
|
Feasibility analysis for economic factors |
|
|
Feasibility analysis for organizational factors |
|
|
Phase 1 Tasks |
Start Date |
Due Date |
Duration (hours) |
|
Work plan (GANTT) |
1/16/18 |
1/17/18 |
1 |
|
System request |
1/17/18 |
1/20/18 |
3 |
|
Feasibility Analysis for Technical and Economic |
1/19/18 |
1/22/18 |
6 |
|
Feasibility Analysis and Organizational Factors |
1/20/2018 |
1/22/18 |
3 |
Step 3: Create a work plan (GANTT chart)
GANTT CHART
|
1/16 1/17 1/18 1/19 1/20 1/21 1/22 |
|
|
Work plan (GANTT) |
|
|
System Request |
|
|
Feasibility Analysis for Technical, & Economic |
|
|
Feasibility Analysis Organizational Factors |
|
Step 4: Identify the critical path using a PERT chart
PERT chart
The critical path for this is to do the steps in order.
Step 3 ---> Step 4 ---> Step 5 ---> Step 6
Step 5: Create a System Request
System Request - Service Personnel Management System
Project Sponsor: Thomas Tong, Service & Support Division Global Operations
Business need: This project has been initiated with the intent to form a
system to manage the training, scheduling and maintenance of service engineers who goes out to customer sites to install/repair/service equipment.
Business Requirement:
· Manage the training, scheduling and maintenance of service engineers
· hold information that servers will access to both retrieve and update data.
· The individual servers will be responsible for hosting a website.
· Each website will be a functional unit for the system, such as the course management tool, personnel/skill management tool, scheduling tool, or service order management tool.
· Statistical analysis is performed to track the amount of time taken to service an equipment, relative to the type of problem.
Business Value:
We expect our Service Personnel Management system to be better than others because it is more efficient and easy to use if you are a new user to the system. It will keep track of the employees, equipment/products, courses and CRM (customer relation management.) The beauty of our SPMS is that you can access on the go at all times from your smartphone and tablet.
Conservative values of tangible value to the company per system:
· $250,000 in sales from new customers
· $500,000 in sales from existing customers
Special Issues or Constraints:
· Training needs to start immediately from approval date, so everyone can become familiar with the interface and workings of the system.
· The Service Personnel Management department views this as a strategic system that will add value to the current business model and will also provide customers with increased convenience and satisfaction.
Step 6: Create a Feasibility analysis for technical factors.
Feasibility for Technical Factors
· The liabilities brought about by the system or the development process of a system would be minimal compared to gains due to the lack of any predominant risks. The combined capabilities of preexisting internal staff should suffice for the development of a Service Personnel Management System, assuming strong to mild proficiency in design pattern knowledge, general programming, and in Object Oriented Programming knowledge.
· Managing the proposed system would also be of little consequence, as the system would manage applications and databases from a more comprehensive viewpoint, and not one dedicated to more minute management of individual components of each application and database.
· Development should run smoothly due to the aforementioned staff experience as well as the vigor with which this task would likely be approached with.
· The sheer size of the project could prove to provide some hurdles within development, as from the outside the project’s scope may seem excessive for the less-than-ten person team that has been tasked with tackling the project. However, given the other risk-diminishing factors, the completion of development of the SPMS can be considered a foregone conclusion.
· Future management will still likely be necessary to enforce and ascertain proper training, scheduling and maintenance of service engineers, but the management team would likely require only a fraction of the development team, and an even smaller fraction of the budget over the systems lifetime, assuming linear development speed.
· Course manipulation through the field advisors won’t be difficult to implement, as it won’t be completely separate from the system, although distinctions will definitely be made.
· Finally, further goals for technical aspects of the SPMS include allocating service engineer dispatching based on even distribution among SEs as well as implementation of both training and personnel deficiency warnings and remedial options.
Step 7: Create a feasibility analysis for economic factors.
Feasibility for Economic Factors
|
Income per system |
2017 |
2018 |
2019 |
|
Service from new customers |
$250,000 |
$275,,000 |
$330,000 |
|
Service from existing customers |
$500,000 |
$550,000 |
$620,000 |
|
Total Benefits: |
$750,000 |
$825,000 |
$950,000 |
|
Cost |
|
|
|
|
Labor: Analysis and Design |
$50,000 |
0 |
0 |
|
Labor: Implementation |
$130,000 |
0 |
0 |
|
Staff Training |
$4,000 |
0 |
0 |
|
Software |
$15,000 |
0 |
0 |
|
Hardware |
$10,000 |
0 |
0 |
|
TOTAL DEVELOPMENT COSTS: |
$209,000 |
0 |
0 |
|
Labor: Computer Operations |
$50,000 |
$54,000 |
$58,,000 |
|
Labor: Customer support |
$50,000 |
$52,000 |
$54,000 |
|
Labor: Management oversight |
$72,000 |
$74,000 |
$76,000 |
|
Labor: 3 staff |
$90,000 |
$95,000 |
$100,000 |
|
Software: upgrade/licensing |
0 |
$3,000 |
$3,000 |
|
Hardware upgrades |
0 |
$3,000 |
$3,000 |
|
User training |
$2,000 |
$1,000 |
$1,000 |
|
Connectivity/Communication charges |
$20,000 |
$20,000 |
$20,000 |
|
Promotional expenses |
$30,000 |
$30,000 |
$30,000 |
|
TOTAL OPERATIONAL COSTS |
$317,000 |
$332,000 |
$345,000 |
|
TOTAL COSTS |
$526,000 |
$332,000 |
$345,000 |
|
TOTAL PROJECT BENEFITS/COST |
$224,000 |
$493,000 |
$605,000 |
This cost-benefit analysis shows how the Service Personnel system will add significantly to the bottom line of the company.
Step 8: Create a feasibility analysis for organizational factors.
Feasibility for Organizational Factors
· From the organizational standpoint, our project carries a low risk as total benefits exceeds costs, leaving us with total projected benefits with $224,000 in 2017 and increasing our profit to $605,000 in 2019
· Our goals with our system is to have an accurate tracking system as well as a user friendly UI to help a new user easily manage their customer relations, as well as their employees, equipment, products, and courses wherever they are.
· We also want to increase sales and amount of users in the next 5 years by providing more customer service and training on the system. Our sponsor is Thomas Tong, Service & Support Division Global Operations, who will be regularly meeting with senior management to discuss ways to increase sales for the system and show the benefits over the next 3-5 years for the system.
· Senior management has thus far been supportive of the system and is looking to see how it expands over time. Since many clients are looking for a more efficient, responsive way for a management tracking system, this proposal is expected to have many users
· Because this proposal has gained traction as a sought after system by clients and other buyers, there should be increased sales in the next 3-5 years and clients and other buyers would be looking to switch over to this system
Step 9: Sources
Patterson case study: https://classroom.google.com/u/0/c/MTAzNjc1Njk0NjVa
Project MileStone 2: Gathering and Analysis Phase
Table of Contents
Project MileStone 2: Gathering and Analysis Phase 1
System Request - Service Personnel Management System 2
|
Tasks |
Roles & Responsibilities |
|
Executive Summary |
|
|
Business Needs/Requirements/Values |
|
|
Work Plan |
|
|
Requirements Definition |
|
|
Functional Model |
|
|
Structural Model |
|
|
Behavioral Model |
me |
Executive Summary
This system request is going to be implemented in order to help improve the current Service Personnel Management System. We have witnessed too many inconsistencies with the current system and we will improve it by making the system easier to understand and more user friendly.
The key to this working is the training that needs to be done with the system so that the workers who are using it know exactly what to do (type of improvements or how we want to help out).
The main target group for our system would be any large company that needs help with the collection of their clients or keeping track of schedules and appointments. There isn't a specific person that we aim to help. We don't discriminate against any clients. As long as the service engineers we have can work through the issues.
The way we would promote this would be to compare it to previous systems and show how ours is vastly improved. We could use some sort of online advertisements and do conference calls to continue to sell the system. Once we have it in one company, the rest is word of mouth. They could continue to expand the network by recommending our service/system in social circles.
The way we would handle a large amount of clients is to continue hiring qualified service engineers who are prompt and are properly trained. We would also need service personnel managers that understand our company goals and how to properly manage service engineers to properly implement the system. This would be the easiest way to handle an increased demand and we could even add in inter-connected client systems if they wanted to collaborate with other companies using our system.
System Request - Service Personnel Management System
Project Sponsor: Thomas Tong, Service & Support Division Global Operations
Business need: This project has been initiated with the intent to form a
system to manage the training, scheduling and maintenance of service engineers who goes out to customer sites to install/repair/service equipment.
Business Requirement:
· Manage the training, scheduling and maintenance of service engineers
· Hold information that servers will access to both retrieve and update data.
· The individual servers will be responsible for hosting a website.
· Each website will be a functional unit for the system, such as the course management tool, personnel/skill management tool, scheduling tool, or service order management tool.
· Statistical analysis is performed to track the amount of time taken to service an equipment, relative to the type of problem.
Business Value:
We expect our Service Personnel Management system to be better than others because it is more efficient and easy to use if you are a new user to the system. It will keep track of the employees, equipment/products, courses and CRM (customer relation management.) The beauty of our SPMS is that you can access on the go at all times from your smartphone and tablet.
Conservative values of tangible value to the company per system:
· $250,000 in sales from new customers
· $500,000 in sales from existing customers
Special Issues or Constraints:
· Training needs to start immediately from approval date, so everyone can become familiar with the interface and workings of the system.
· The Service Personnel Management department views this as a strategic system that will add value to the current business model and will also provide customers with increased convenience and satisfaction.
Workplan
GANTT CHART
|
2/11 2/12 2/13 2/14 2/15 2/16 2/17 2/18 2/19 |
|
|
Work plan (GANTT) |
|
|
Executive Summary |
|
|
Business Modeling (Needs, Values, Requirements) |
|
|
Requirements Definition |
|
|
Functional Model (Activity Diagram, Use-Case Diagram) |
|
|
Structural Model (CRC Cards, Class Diagrams, Object Diagram) |
|
|
Behavioral Model (Sequence Diagrams, Communication Diagrams, Behavioral State Machines, CRUDE matrix) |
|
|
Appendices (Additional material relevant to the proposal e.g interviews, questionnaires) |
|
Requirement Definition
We identified what we want our product to do. We want it to be able to be a top tier health care system that will be able to work will complete a number of different tasks, and is reliable when used. Below are both the functional and nonfunctional requirements:
|
Non-Functional Requirements: |
|
1. Operational Requirements 1.1 The system will operate in a Database (MySQL, Oracle, SAP) 1.2 The system should be available to students 1.3 The system will update at midnight |
|
2. Performance Requirements 2.1 The system should be able to update in 5 seconds or less 2.2 The system should be able to retrieve information in 5 seconds or less. 2.3 The system will be available for 365 days. |
|
3. Security Requirements 3.1 Only Field Supervisors can register or delete SE from courses 3.2 Only Field Supervisors can update/create training schedules 3.3 Only Field Supervisors can update/create schedules |
|
4. Cultural and Political Requirements 4.1 Meet all the regulatory requirements. 4.2 Strict Compliance with all aspects of HIPAA to be maintained at all times. |
|
Functional Requirements: |
|
1. Manage Training 1.1 Creates Training Schedule 1.2 Update Training Schedule 1.3 Reminds users when there is new training is available |
|
2. Manage Scheduling 2.1 Customer creates appointment 2.2 Customer changes appointment 2.3 Customer cancels appointment |
|
3. Service Management (Product) 3.1 Request Service engineer to Install Equipment 3.2 Request Service engineer to Service Equipment |
|
4. Manage Course 4.1 Register SE in course 4.1 Delete SE from course |
|
5. Manage Employees 5.1 Updates skill set of employees |
Functional Model
a. Use-Case Diagram -
Activity Diagram
b. Set the scope of the activity being modeled
c. Use-Case Descriptions
|
Use Case Name: Manage Training |
ID: 1 |
Importance Level: High |
|
Primary Actor: Staff |
Use Case Type: Essential |
Trigger: Training Schedule creation, updating, and reminding |
Stakeholders & Interests:
· Staff - Training schedule creation and management.
· Service Engineers - Reminded of schedule if necessary.
Brief Description:
· Manages the training schedules, for creation of the schedules as well as the updating of the training schedules. Also keeps service engineers on schedule through reminders.
Relationships:
· Association: Staff
· Include :
· Extend: Service Management
· Generalization:
|
Use Case Name: Manage Scheduling |
ID: 2 |
Importance Level: High |
|
Primary Actor: Customer |
Use Case Type: Essential |
Trigger: Customer creates appointment. |
Stakeholders & Interests:
· Staff - Customer appointments are created, and must be managed and stored.
· Customer - The customer triggers the appointment for a required service engineer.
· Service Engineers - Stand to gain job opportunity through use case trigger.
Brief Description:
· Manages scheduling through obtaining the created appointment and requests of the customer. And by retaining that information, the system itself can do its job by assigning case-based solutions.
Relationships:
· Association: Customer
· Include:
· Extend:
· Generalization:
|
Use Case Name: Service Management |
ID: 3 |
Importance Level: High |
|
Primary Actor: Staff |
Use Case Type: Essential |
Trigger: Customer request goes through. |
Stakeholders & Interests:
· Staff - This is the product of the system, and the results that the customer wants.
· Customer - The customer should receive this as the product.
· Service Engineers - The requests here are what the service engineers do.
Brief Description:
· Requests a service engineer to install equipment as well as to service equipment.
Relationships:
· Association: Staff
· Include: Training Management
· Extend:
· Generalization:
Structural Models
a. CRC cards (about use cases
Front:
|
Class Name: Customer |
ID: 1 |
|
Description: An individual inquiring to be serviced |
Associated Use Cases: |
|
Responsibilities:
|
Collaborators:
|
Back:
|
Attributes: |
|
Relationships:
Generalization (a-kind-of): Person
Aggregation (has-parts):
Other Associations: Appointment, Staff |
Front:
|
Class Name: Service Engineer |
ID: 1 |
|
Description: An individual can install and service equipment |
Associated Use Cases: |
|
Responsibilities:
|
Collaborators:
|
Back:
|
Attributes: Skill Appointment List |
|
Relationships:
Generalization (a-kind-of): Person
Aggregation (has-parts):
Other Associations: Appointment, Training, Staff, Customer |
Front:
|
Class Name: Appointment |
ID: 2 |
|
Description: A customer appointment with a service engineer |
Associated Use Cases: |
|
Responsibilities:
|
Collaborators:
|
Back:
|
Attributes: Date Time |
|
Relationships:
Generalization (a-kind-of):
Aggregation (has-parts):
Other Associations: Staff, Customer, Service Engineer |
A reminder for scheduled event
Front:
|
Class Name: Training |
ID: 2 |
|
Description: A course taken to be a certified service engineer |
Associated Use Cases: |
|
Responsibilities:
|
Collaborators:
|
Back:
|
Attributes: Course Name |
|
Relationships:
Generalization (a-kind-of): Appointment
Aggregation (has-parts):
Other Associations: Staff, Service Engineer |
A course to train employees
Front:
|
Class Name: Scheduler |
ID: 3 |
|
Description: Orchestrates pairing service engineers to appointments, and paring service engineers to trainings |
Associated Use Cases: |
|
Responsibilities: · Make Appointment · Make Training |
Collaborators:
|
Back:
|
Attributes:
|
|
Relationships:
Generalization (a-kind-of):
Aggregation (has-parts):
Other Associations: Appointments, Training, Calendar |
Front:
|
Class Name: Calendar |
ID: 3 |
|
Description: List of appointments and trainings |
Associated Use Cases: |
|
Responsibilities: · Get Available Appointments · Get Available Trainings |
Collaborators:
|
Back:
|
Attributes:
|
|
Relationships:
Generalization (a-kind-of):
Aggregation (has-parts):
Other Associations: Scheduler |
Description: A list of appointments and Trainings.
b. Class diagram
Behavior Models
a. Interaction Diagram
· Sequence Diagrams
· Above is the sequence diagram for our system
· The company client manager requests a service engineer through our system when they are in need of a service repair, installation, or update
· The request is sent to the service personnel manager, in which the service manager confirms and analyzes the company’s request and ensure that there are available engineers at the time of the request/appointment
· Once that is confirmed, the manager will then determine which service engineer is appropriate for the company’s request
· Once that is determined, the manager will choose that service engineer to help the company out
b. CRUDE matrix (about use cases)
|
|
Service Engineer |
Staff |
Customer |
Appointment |
Training Schedule |
Request |
|
Service Engineer |
|
|
|
R |
R |
|
|
Staff |
|
|
|
CUD |
CUD |
U |
|
Customer |
|
|
|
CUD |
|
|
|
Appointment |
|
|
|
|
|
|
|
Training Schedule |
|
|
|
|
|
|
c. Behavioral State Matrix
Project Milestone 3
TIM 58 - Group 19:
Chapter 10 Slides - for reference in the design phase.
Service Personnel Management System example
Draw.io Useful tool to make diagram, has a lot of default template we need.
Table of Contents
Table of Contents:
Design Phase
-Verify and validate the analysis models
-Object-Oriented Analysis Models
-CRC Card(Ben)
-Class Diagram(Ben)
-Use-Case(TRE)
-Use-Case description(TRE)
-Activity Diagram(TRE)
-Sequence Diagram (Andre)
-Communication Diagram(CELIA)
-CRUDE Matrix(TRE)
-Behavioral State Machine (CELIA)
- Evolve the analysis models into design models(page 32 in slides)
-Object-Oriented Analysis Models
-CRC Card
-Class Diagram
-Use-Case description (BYRON)
-Activity Diagram (BYRON)
-Sequence Diagram (BYRON)
-Communication Diagram (CELIA)
-CRUDE Matrix (Andre)
-Behavioral State Machine (TRE)
- Create packages and utilize package diagrams(page 36 in slides)
-Package Diagram.(CELIA) - Decide upon a design strategy
-Determine tools and skills needed for in-house development(TRE) -Identify existing packages that satisfy the users’ needs(Lyanna) -Locate companies who can build it under contract(TRE) -Create an alternative matrix to organize the pros and cons of each possible choice( TRE)
Plan:
Functional Models:
CRC Cards(about use cases):
CRC Card #1
Front:
|
Class Name: Customer |
ID: 1 |
|
Description: An individual inquiring to be serviced |
Associated Use Cases: |
|
Responsibilities:
|
Collaborators:
|
Back:
|
Attributes: |
|
Relationships:
Generalization (a-kind-of): Person
Aggregation (has-parts):
Other Associations: Appointment, Staff |
Verification/Validation of CRC Card #1:
-Test the Fidelity of each model:
-Test the Fidelity between models:
Evolution of CRC Card #1:
CRC Card #2
Front:
|
Class Name: Service Engineer |
ID: 1 |
|
Description: An individual can install and service equipment |
Associated Use Cases: |
|
Responsibilities:
|
Collaborators:
|
Back:
|
Attributes: Skill Appointment List |
|
Relationships:
Generalization (a-kind-of): Person
Aggregation (has-parts):
Other Associations: Appointment, Training, Staff, Customer |
Verification/Validation of CRC Card #2:
-Test the Fidelity of each model:
-Test the Fidelity between models:
Evolution of CRC Card #2:
CRC Card #3
Front:
|
Class Name: Appointment |
ID: 2 |
|
Description: A customer appointment with a service engineer |
Associated Use Cases: |
|
Responsibilities:
|
Collaborators:
|
Back:
|
Attributes: Date Time |
|
Relationships:
Generalization (a-kind-of):
Aggregation (has-parts):
Other Associations: Staff, Customer, Service Engineer |
A reminder for scheduled event
Verification/Validation of CRC Card #3:
-Test the Fidelity of each model:
-Test the Fidelity between models:
Evolution of CRC Card #3:
CRC Card #4
Front:
|
Class Name: Training |
ID: 2 |
|
Description: A course taken to be a certified service engineer |
Associated Use Cases: |
|
Responsibilities:
|
Collaborators:
|
Back:
|
Attributes: Course Name |
|
Relationships:
Generalization (a-kind-of): Appointment
Aggregation (has-parts):
Other Associations: Staff, Service Engineer |
A course to train employees
Verification/Validation of CRC Card #4:
-Test the Fidelity of each model:
-Test the Fidelity between models:
Evolution of CRC Card #4:
CRC Card #5
Front:
|
Class Name: Scheduler |
ID: 3 |
|
Description: Orchestrates pairing service engineers to appointments, and paring service engineers to trainings |
Associated Use Cases: |
|
Responsibilities: · Make Appointment · Make Training |
Collaborators:
|
Back:
|
Attributes:
|
|
Relationships:
Generalization (a-kind-of):
Aggregation (has-parts):
Other Associations: Appointments, Training, Calendar |
Verification/Validation of CRC Card #5:
-Test the Fidelity of each model:
-Test the Fidelity between models:
Evolution of CRC Card #5:
CRC Card #6
Front:
|
Class Name: Calendar |
ID: 3 |
|
Description: List of appointments and trainings |
Associated Use Cases: |
|
Responsibilities: · Get Available Appointments · Get Available Trainings |
Collaborators:
|
Back:
|
Attributes:
|
|
Relationships:
Generalization (a-kind-of):
Aggregation (has-parts):
Other Associations: Scheduler |
Verification/Validation of CRC Card #6:
-Test the Fidelity of each model:
-Test the Fidelity between models:
Evolution of CRC Card #6:
Class Diagram:
Verification/Validation of the Class Diagram:
-Test the Fidelity of each model:
-Test the Fidelity between models:
Evolution of Class Diagram:
Use-Case #1
Verification/Validation of Use Case #1:
Test the Fidelity of each model:
To complete the validation and verification of the Use Case is to check if it matches all the same functional requirements of the other functional models. Our Use-Cases matches all other activity diagrams and use cases along with the descriptions.
Test the Fidelity between models:
The use cases all match the activity diagrams and show the same functional requirements.
Evolution of Use Case #1:
Use Case #2
Verification/Validation of Use Case #2:
Test the Fidelity of each model:
This use-case is for Service Management and it definitely matches up with everything else in the previous stages of the processes.
Test the Fidelity between models:
Compared to the use case diagrams and the activity diagram the use cases match up perfectly with whatever in the previous processes.
Evolution of Use Case #2:
Use-Case #3:
Verification/Validation of Use Case #1:
Test the Fidelity of each model:
They are 100% correct and it lines up with what we wanted the use cases to be. It makes sense in the total aspect of what we want to achieve in the problem.
Test the Fidelity between models:
Between the functional models and the use case it makes sense in respects to the work we put into the other stages.
Evolution of Use Case #1:
Activity Diagram #1:
Verification/Validation of Activity Diagram #1:
Test the Fidelity of each model:
The model makes sense to what we are trying to do going forward with the creation of the sequence diagram and with everything we laid out before hand.
Test the Fidelity between models:
To check the Fidelity between models we want to go over the cohesiveness of the total package of the project to make sure that it makes sense. For this activity diagram it makes complete sense to what we are doing for the project with the other functional models.
Evolution of Activity Diagram #1:
Activity Diagram #2
Verification/Validation of Activity Diagram #2:
Test the Fidelity of each model:
When we made this model we used the other use-cases in order to keep it correct and make sense in the aspects of our service management product.
Test the Fidelity between models:
Between the models and this activity diagram the way as before follows the same logic of what we put in the previous functional diagrams.
Evolution of Activity Diagram #2:
Activity Diagram #3
Verification/Validation of Activity Diagram #3:
Test the Fidelity of each model:
This activity diagram is valid and makes sense in the total aspect of the problem and follows some of the key points we wanted and this activity diagram does that.
Test the Fidelity between models:
To look at the relationship between the use-case diagrams and definitely matches the use case for service management. This made it really easy to make the use case diagrams.
Evolution of Activity Diagram #3:
Sequence Diagram:
· Above is the sequence diagram for our client management system
· The company client manager requests a service engineer through our system when they are in need of a service repair, installation, or update
· The request is sent to the service personnel manager, in which the service manager confirms and analyzes the company’s request and ensure that there are available engineers at the time of the request/appointment
· Once that is confirmed, the manager will then determine which service engineer is appropriate for the company’s request
· Once that is determined, the manager will choose that service engineer to help the company out
Use Case Descriptions:
Use Case Description #1:
|
Use Case Name: Manage Training |
ID: 1 |
Importance Level: High |
|
Primary Actor: Staff |
Use Case Type: Essential |
Trigger: Training Schedule creation, updating, and reminding |
Stakeholders & Interests:
· Staff - Training schedule creation and management.
· Service Engineers - Reminded of schedule if necessary.
Brief Description:
· Manages the training schedules, for creation of the schedules as well as the updating of the training schedules. Also keeps service engineers on schedule through reminders.
Relationships:
· Association: Staff
· Include :
· Extend: Service Management
· Generalization:
Verification/Validation of Use-Case #1:
Test the Fidelity of each model:
The model has the same aspects that we want to follow with the logic for everything else.
Test the Fidelity between models:
The model has the same aspects of the use-cases and takes everything from it and describes what the use-case is saying. This made it really easy to make the activity diagram.
Evolution of Activity Use-Case #1:
Use Case Description #2:
|
Use Case Name: Manage Scheduling |
ID: 2 |
Importance Level: High |
|
Primary Actor: Customer |
Use Case Type: Essential |
Trigger: Customer creates appointment. |
Stakeholders & Interests:
· Staff - Customer appointments are created, and must be managed and stored.
· Customer - The customer triggers the appointment for a required service engineer.
· Service Engineers - Stand to gain job opportunity through use case trigger.
Brief Description:
· Manages scheduling through obtaining the created appointment and requests of the customer. And by retaining that information, the system itself can do its job by assigning case-based solutions.
Relationships:
· Association: Customer
· Include:
· Extend:
· Generalization:
Verification/Validation of Use-Case #2:
Test the Fidelity of each model:
This model is correct and is the same process for the use-case we wanted to define in the implementation of the project.
Test the Fidelity between models:
The model has the same aspects of the use-cases and takes everything from it and describes what the use-case is saying. This made it really easy to make the activity diagram.
Evolution of Activity Use-Case #2:
USe Case Description #3:
|
Use Case Name: Service Management |
ID: 3 |
Importance Level: High |
|
Primary Actor: Staff |
Use Case Type: Essential |
Trigger: Customer request goes through. |
Stakeholders & Interests:
· Staff - This is the product of the system, and the results that the customer wants.
· Customer - The customer should receive this as the product.
· Service Engineers - The requests here are what the service engineers do.
Brief Description:
· Requests a service engineer to install equipment as well as to service equipment.
Relationships:
· Association: Staff
· Include: Training Management
· Extend:
· Generalization:
Verification/Validation of Use-Case #3:
Test the Fidelity of each model:
The use-case description is great and makes sense in the aspects of what we want to accomplish with our implementation.
Test the Fidelity between models:
The model has the same aspects of the use-cases and takes everything from it and describes what the use-case is saying. This made it really easy to make the activity diagram.
Evolution of Activity Use-Case #3:
Behavioral Models:
Communication diagram:
Verification/ Validation of Communication Diagram:
Test the Fidelity of each model:
The communication diagram accurately depict the processes that are needed to request a service engineer. This is done by ensuring that all the steps in the process are portrayed on the diagram.
Test the Fidelity between models:
The Communication Diagram is consistent with the Sequence Diagram. Every actor and object have been correctly included in the Communication and Sequence Diagram. In addition, the messages on the Sequence diagram have a matching association of the communication diagram. As well as every message on the sequence diagram has a message on an association on the communication diagram. Finally sequence numbers are included with message labels in the communication diagram to ensure the sequential order in which messages will be sent.
Evolution of Communication Diagram:
CRUDE matrix (about use cases):
|
|
Service Engineer |
Staff |
Customer |
Appointment |
Training Schedule |
Request |
|
Service Engineer |
|
|
|
R |
R |
|
|
Staff |
|
|
|
CUD |
CUD |
U |
|
Customer |
|
|
|
CUD |
|
|
|
Appointment |
|
|
|
|
|
|
|
Training Schedule |
|
|
|
|
|
|
Verification/ Validation of Crude Matrix:
Test the Fidelity of each model:
This model is right, directly determining if there is a need for create, read, update or delete in an application containing SQL.
Test the Fidelity between models:
The CRUDE matrix directly relates to our use cases and determines what is needed to do with each of those use cases. The CRUDE matrix helped correctly identify the Tables in our Database which are used in any User interaction with a web site. This all came from our use cases.
Evolution of CRUDE matrix:
|
|
Service Engineer |
Staff |
Customer |
Appointment |
Training Schedule |
Request |
|
Service Engineer |
|
|
|
R |
R |
|
|
Staff |
|
|
|
CUD |
CUD |
U |
|
Customer |
|
|
|
CUD |
|
C |
|
Appointment |
|
|
|
|
CUD |
|
|
Training Schedule |
|
|
|
|
|
C |
Because converting the CRUDE matrix into the design phase would mean adding non-functional requirements, it could affect the CRUDE matrix in its evolution. However, the non-functional requirements would not affect the CRUDE matrix much in this scenario; the CRUDE matrix maintains what it had in the analysis phase, but also adds other elements that factor in from the non-functional requirements, from the analysis phase to the design phase.
Behavioral State Machine:
Verification/ Validation of Behavioral State Machine:
Test the Fidelity of Each Model:
Each state in the Behavioral State Machine is reachable, and it is possible to leave each state except for the final state which is either a service engineer is sent to the company or a a service engineer was not found for the given request in which the request is closed in both cases.
Test the Fidelity between models:
All of the transition contained in the state machine are associated with messages being sent on a sequence and communication diagram.
Evolution of Behavioral State Machine:
Package Diagram:
Decision Strategy:
The design strategy is first developed. It clarifies whether the system will be developed by the company’s own programmers, whether the system will be outsourced to another firm (usually a consulting firm), or whether the company will buy an existing software package.
Step 1: Determine tools and skills needed for in-house development(TRE)
Below is a table of what would need to happen if we went with either custom development, a packaged system or if we outsourced the design strategy.
Being that we are trying to incorporate both a mobile application and a computer software we would need someone who could work with both types. Need our developers to be creative in solving our business needs in case we decide we want to go with a custom system. Custom development also allows developers to be flexible and creative in the way they solve business problems. Additionally, a custom application is easier to change to include components that take advantage of current technologies that can support such strategic efforts. If we wanted to go with a packaged system we need a strong communicator who can coordinate with the vendors and or set a definite time table with the developer.
Step 2: Identify existing packages that satisfy the users’ needs
(NEED TO DETERMINE WHAT PACKETS WE HAVE SO FAR) Step 3: Locate companies who can build it under contract(Tre)
When deciding on our companies policy with whatever method we want to use, whether that being outsourcing or producing it by ourselves. First thing first is to determine companies that could possibly build our software under contract. We can have companies that specialize in either
· Custom Application Python
· Custom Application JAVA
· Packaged Software Product ABC
Step 4: Create an alternative matrix to organize the pros and cons of each possible choice.
A big part in determining the way we want to go forward is by making an alternative matrix to fully understand what we are up against with the different options we can choose.
|
Evaluation Criteria |
Relative Importance(Weight) |
Alternative 1: Custom Application Using Python |
Score (1-5) |
Weighted Score |
Alternative 2: Custom Application Using Java |
Score (1-5) |
Weighted Score |
Alternative 3: Packaged Software Using ABC |
Score (1-5) |
Weighted SCore |
|
Technical issues: |
|
|
|
|
|
|
|
|
|
|
|
Ease of use |
20 |
|
5 |
100 |
|
5 |
100 |
|
3 |
60 |
|
Pattern knowledge |
10 |
|
3 |
30 |
|
4 |
40 |
|
3 |
30 |
|
Product scalability |
20 |
|
2 |
40 |
|
4 |
80 |
|
3 |
60 |
|
Economic Issues |
|
|
|
|
|
|
|
|
|
|
|
Minimizes cost |
25 |
|
2 |
50 |
|
3 |
75 |
|
4 |
100 |
|
Organization Issues |
|
|
|
|
|
|
|
|
|
|
|
Data capability |
25 |
|
2 |
50 |
|
3 |
75 |
|
4 |
100 |
|
Total |
100 |
|
|
270 |
|
|
370 |
|
|
350 |
So after creating the alternative matrix we can see that the best design strategy to use the custom application by using java. That’s because it has the highest utility from the technical issues, economic issues and the organizational issues described in the alternative matrix. The way we are moving forward is with in-house application and this will require us to get employees who can provide us with some type of programming background in order to help out with the implementation of the software as well as the managing and updating the software as time goes on.
