Lab 5 – PASS Lessons Learned
1
RUNNING HEAD: LAB 5 – PASS LESSONS LEARNED
Personal Alert and Safety System
Lab 5 – Lessons Learned
CS 411 Blue Team:
Jon Szewczak
Gene H. Price
April 19, 2011
Lab 5 – PASS Lessons Learned
2
Risk Management and Mitigation
During the concept evaluation phase for the Personal Alert and Safety System (PASS)
project, several risks were identified. Among the identified risks were high maintenance costs,
high implementation costs, and costly customer outlay. As can be seen, all of the high risks were
based on financial factors. This is due in large part to the fact that the majority of the system
requires little to no new technical innovation. The hardware specifications are based on existing
technologies that have been proven and implemented in a variety of fields. However since PASS
is a large system, there is consequently a large monetary outlay required by both implementer
and customer. The prototype that was developed for PASS did not address any of these factors.
In fact, the prototype development process identified several key technical details that would
negatively affect the financials of an implemented product.
The first additional factor that popped up relates to the transceiver hardware. In the
initial concept stages it was believed that the transceiver modules as specified were a selfcontained item that included all of the logic controllers necessary to perform its functions. It was
discovered that this was not the case and that an additional microcontroller would be needed to
be added to the devices in order for them function properly. In the prototype the microcontroller
functions are handled by the Arduino Prototyping Board. The addition of the microcontrollers to
the devices increases the costs of manufacture and therefore increases the financial risk to the
project.
Similarly, the fob device specification also ran into troubles. The fob that was originally
specified as a commercial-off-the-shelf item cannot be used for the purposes of the PASS project
in a production environment. Instead, the fob will need to be custom made in order to suit the
special programming instructions that will be needed by PASS. Manufacturing and assembly
Lab 5 – PASS Lessons Learned
3
costs for the fob were not included in the initial estimates of project cost. Therefore, like the
additional components for the transceivers, the implementation costs will be driven even higher.
Budget
Due to the dual test version of the prototype (hardware and software simulation) the
budget for the prototype exceeded initial estimates. The vast majority of the money that was
spent went to the purchase of testable hardware components. There were relatively few
problems with the hardware that was received. Each component ordered was received in time to
complete the setup, testing, and performance monitoring of the prototype. The setup was able to
achieve the desired results, and therefore, can be considered a worthwhile investment.
The only issue stemmed from lead time. Two of the most important components were
ordered from a source that has a long lead time. This piece of information was not relayed to the
PASS project team before ordering, and therefore it became a source of concern as the time
before the demonstration drew near.
Scheduling
The PASS prototype scheduling was a unique challenge all of it own. The volume of
technical documents that needed to be developed almost caused an irreparable delay in the
software development of the simulation application. Each document was an enormous effort to
put write and assemble. The due dates for each document were also spaced in such a manner,
that accomplishing the technical aspects of development were delayed until the very end. The
development therefore was rushed and some pieces may not have been completed to their fullest
extent.
Moving forward in this project, it is recommended that the project team be augmented by
several individuals whose only task is to generate the documentation necessary. This will allow
Lab 5 – PASS Lessons Learned
4
the core team to manage and oversee production. This is the only path to complete success in
Phase 2.
Prototype Development
Despite nearly overwhelming challenges in personnel and time constraints, each phase of
the prototype was completed prior to the demonstration deadline. The hardware setup for the
Hardware Demonstration works as designed. It shows that the required wireless communication
between fob, transceiver and PC is not only possible, but fully achievable. The completed
software simulation demonstrates that the key algorithms that needed to be implemented by
production hardware and associated interface modules are fully functional.
Real World Product Solution and Scope
Based on the findings of the prototype phase, it can be concluded that the PASS project is
technically feasible. However because of the current global economic situations it may not be
financially rewarding to pursue this project any further. One option that could be taken to make
this initiative work would be to scale back some of the implementation characteristics. Yet, if
that were to take place it is likely that the product specifications would become no better than the
few other solutions out there. And since PASS would no longer be able to distinguish itself from
its competitors, it would likely fail as a venture.
Conclusion
To sum up the experiences of this PASS project member would be simple. PASS was
too big of a system for the Old Dominion University Computer Science Department’s
CS410/411W classes. There were too many details to be worked out and too much everything
else. Because of the sheer amount of work to completed, tensions rose in the project team and
Lab 5 – PASS Lessons Learned
personal flare ups occurred. It can be easily surmised that if the team had chosen to pursue a
different project goal, some of the conflicts that arose could have been avoided. It is with relief
and an overall sense of accomplishment that the author closes out this document and his
involvement in the PASS project.
5