Draft SRS (end of week 5)

Tasks Accomplished:

1. Met to start SRS document. Completed by entire team. Time spent: ~1 hour.
2. Talked with project sponsor about potential use cases. Completed by Geoff Berl. ~1 hour.
3. Met to work on SRS draft together. Completed by entire team. Time spent: ~1 hour.
4. Completed Use Case document with one detailed use case. Completed by entire team. Time spent: ~2 hours.
5. Completed first draft of SRS document. Completed by entire team. Time spent: ~4 hours.

Focus For Next Iteration:

1. Refine SRS as needed. Completed by entire team. Time estimate: ~2 hours.
2. Fully detail the rest of the use cases. Completed by entire team. Time estimate: ~4 hours.
3. Review SRS with sponsor. Completed by Geoff Berl (assistance from team). Time estimate: ~1 hour.
4. Project Presentation. Completed by entire team. Time estimate: ~2 hours.

Challenges and/or Issues:

1. Group meeting availability. 
2. Detailing use cases. Our team was able to think of a decent amount of high priority use cases for the system, but the details for them become a point of debate. For example, the steps that go into aggregating sensor data could be done in many different ways.
3. Time management. Some of our team has been more busy than usual preparing for the upcoming career fair.

Vision and Scope (end of week 3)

Tasks Accomplished This Week:

1. Talk with project sponsor to negotiate feature details. Completed by Geoff Berl. Time spent: ~1 hour.
2. Vision and Scope document. Completed by entire team. Time spent: ~4 hours.
3. Create Project Plan document. Completed by entire team. Time spent: ~1 hour.

Focus For Next Week:

1. Start Draft SRS and determine next steps. Completed by entire team. Time estimate: ~1 hour.
2. Talk to sponsor about requirements. Completed by Geoff Berl (assistance from team). Time estimate: ~30 minutes to 1 hour.

Challenges and/or Issues:

1. Group meeting availability. Our team's schedules do not match up very well. As a result, we have less time to meet together in person with all group members present. We try to mitigate this issue by delegating work efficiently while we are all present so that we can work remotely. We also try to keep frequent remote communication.
2. Prioritizing product features. Ultimately, this came down to trying to understand the problem fully and making group decisions about what features are most essential for a first release of the product.

Project Kickoff

Team 1

Company name:

MKS Instruments Inc. (http://www.mksinst.com/)

Domain:

MKS is a leading manufacturer of high reliability, compact, solid state, mid to extended (VHF) frequency RF power generators, impedance matching networks and plasma metrology, RF amplifiers for MRI equipment, and pulsed and continuous DC power generators in power levels up to 60 kW

Current Problem:

Due to the diverse nature of each product line it is difficult for even senior service technicians to seamlessly switch between evaluating products in various product groups.  Because of this, a lot of unnecessary resources are wasted by senior technicians who are well trained on a particular product when a transferring technician runs into issues.  It would be beneficial to have a way to aid transferring technicians in resolving simpler problems on their own.

Proposition:

Develop a system that allows users to select a product, enter a problem description, fault or attach a fault log.  The system would then use historical data to suggest potential troubleshooting solutions based on previous user search entries and repairs that resolved similar problems for units in the past. In addition, the system may use sensor data logged by the products to further assist with troubleshooting.

Example

Jim is a tech on the Spectrum product line, he has worked that product line for 10 years so he is very well trained in Spectrum.  Eric is a tech in the DFC product line, he has worked on that product line for 5 years so he is also very well trained in his product line.  The backlog gets low in DFC and Eric is moved to the Spectrum product line because they have the highest backlog and some high priority units.  Eric has a steep learning curve moving to Spectrum because the units in Spectrum are much different than those in DFC.  Eric is testing an incoming unit with a series of temperature overheat faults, these faults could be caused by a bad sensor, cable, heat sink or even just poor water flow.  Eric has no idea where to start so he asks Jim, “is there a common problem that you see with these units coming in with temperature faults?”  Jim responds “Yeah, those could be either that there is sludge in the heat sink causing poor water flow or it could be the temperature sensor cables.  If it’s from customer X then I would check the heat sink for water flow first, but otherwise it’s usually the temperature sensor cable, those can be easily checked with a multimeter.”

Outcomes of Example

While it is great that Jim was able to quickly answer Eric’s problem, if Eric had access to that historical information then he would not even need to ask Jim.  Jim should be focusing his time on getting those high priority units out, he can’t be continuously interrupted by Eric for basic problems that could be solved by knowing the solution to common problems.  These solutions to common problems could be identified by looking at historical data that the technician has personally logged, units that have been through the service department before or looking at sensor data from the units if it’s a problem related to output.  In addition, there have been situations where there is only one senior technician for a product line and that technician leaves the company for some reason, that knowledge in their head is lost (the ‘Bus Factor’).  Knowledge of the products should stay with the company and, in addition, knowledge from all sources should be combined for a single, globally accessible source of information on all service data.