Capstone Project. This was a group effort to build a Networked Point of Sale system for a small pharmacy chain in the Ohio Valley. The major selling point was compliance with Federal Regulations surrounding Ephedrine sales.

1. Electronic Product Sale
Logging System
Smith’s Pharmacy
Victor Amaya, Chris McCoy and Robert Berus
October 25, 2007

3. Table of Contents
1. EXECUTIVE SUMMARY.....................................................................................................................................1
1.1. PURPOSE...............................................................................................................................................................1
1.2. BACKGROUND..........................................................................................................................................................1
1.3. INDUSTRY..............................................................................................................................................................1
1.4. VISION..................................................................................................................................................................1
1.5. SCOPE..................................................................................................................................................................2
2. PROJECT CHARTER...........................................................................................................................................3
2.1. PROJECT OBJECTIVES..................................................................................................................................................3
2.2. PROJECT CONCEPTION................................................................................................................................................3
2.3. PROBLEM STATEMENT................................................................................................................................................3
2.4. FINANCIAL RISK ANALYSIS............................................................................................................................................4
2.5. INITIAL SCOPE OF THE PROJECT.......................................................................................................................................4
2.6. PROJECT VISION.......................................................................................................................................................4
2.7. BUSINESS CONSTRAINTS..............................................................................................................................................4
2.8. TECHNOLOGY CONSTRAINTS..........................................................................................................................................5
2.9. PROJECT STRATEGY....................................................................................................................................................5
2.10. PROJECT DOCUMENTATION AND COMMUNICATION..............................................................................................................5
2.11. PROJECT ORGANIZATION AND STAFFING APPROACH.............................................................................................................5
3. PROJECT VALUE STATEMENT...........................................................................................................................6
3.1. BACKGROUND .........................................................................................................................................................6
3.2. VALUES.................................................................................................................................................................6
4. PROJECT STRATEGY STATEMENT.....................................................................................................................7
4.1. METHODOLOGY OVERVIEW..........................................................................................................................................7
4.2. MEETING FREQUENCY................................................................................................................................................7
4.2.1. A-Team Project Development Meetings......................................................................................................7
4.2.2. Smith’s Pharmacy Client Update Meetings.................................................................................................7
5. SYSTEM PROJECT METHODOLOGY...................................................................................................................8
5.1. ELECTRONIC PRODUCT SALE LOGGING SYSTEM PROJECT METHODOLOGY......................................................................................8
5.1.1. Requirements...............................................................................................................................................8
5.1.2. Design...........................................................................................................................................................9
5.1.3. Implementation............................................................................................................................................9
5.1.4. Verification...................................................................................................................................................9
5.1.5. Maintenance..............................................................................................................................................10
6. GENERAL SYSTEM ANALYSIS..........................................................................................................................11
6.1. CONTEXT MODEL...................................................................................................................................................11
6.2. EVENT LIST...........................................................................................................................................................12
Page | i

4. 6.3. EVENT DICTIONARY..................................................................................................................................................12
7. BUSINESS REQUIREMENTS AND RULES..........................................................................................................14
8. TECHNICAL REQUIREMENTS AND ASSUMPTIONS...........................................................................................22
8.1. EXISTING LAN AND WAN.......................................................................................................................................22
8.1.1. Network Operating System and Client PC Configuration..........................................................................22
8.1.2. WAN Infrastructure Overview....................................................................................................................23
8.1.3. LAN Infrastructure Overview......................................................................................................................24
8.1.4. IT Equipment Rack Diagram ......................................................................................................................25
8.2. POINT OF SALE SYSTEM............................................................................................................................................26
8.3. TECHNICAL SUPPORT................................................................................................................................................26
9. TECHNICAL PLATFORM AND TOOLS REQUIRED..............................................................................................27
9.1. .NET FRAMEWORK 2.0............................................................................................................................................27
9.2. VISUAL STUDIO 2005 ............................................................................................................................................27
9.3. WINDOWS SERVER 2003.........................................................................................................................................27
9.4. SQL SERVER 2005...............................................................................................................................................27
9.5. CANDIDATE MATRIX................................................................................................................................................28
10. THIRD-PARTY NEEDS....................................................................................................................................29
10.1. VENDORS...........................................................................................................................................................29
10.1.1. Dell...........................................................................................................................................................29
10.1.2. Microsoft..................................................................................................................................................29
10.1.3. IBM...........................................................................................................................................................29
10.1.4. Suppliers...................................................................................................................................................30
10.1.5. Consultants..............................................................................................................................................30
11. DATABASE/ERD MODEL...............................................................................................................................31
12. DATA FLOW DIAGRAM................................................................................................................................32
13. SYSTEM ARCHITECTURAL DIAGRAMS...........................................................................................................33
14. PROJECT RISK AND RISK MANAGEMENT......................................................................................................34
14.1. RISK MANAGEMENT PLANNING..................................................................................................................................34
14.2. QUALITATIVE/QUANTITATIVE RISK ANALYSIS...................................................................................................................36
14.2.1. Risk Response Planning............................................................................................................................36
14.2.2. Monitoring and Control...........................................................................................................................36
15. PROJECT COSTS, STAFFING, RESOURCES, DEPENDENCIES AND SCHEDULE.....................................................37
15.1. BENEFITS...........................................................................................................................................................37
15.2. BILL OF MATERIALS...............................................................................................................................................38
15.3. TRIPLE COST ANALYSIS...........................................................................................................................................39
15.4. RETURN ON INVESTMENT ANALYSIS.............................................................................................................................40
15.5. PROJECT SCHEDULE...............................................................................................................................................41
PROJECT STAFFING........................................................................................................................................................42
16. INTEGRATION OF INTERNAL/EXTERNAL SYSTEMS........................................................................................43
Page | ii

5. 17. SYSTEM ADMINISTRATION, SECURITY, BACKUP AND RECOVERY..................................................................44
17.1. POLICY..............................................................................................................................................................44
17.2. ACCOUNT MANAGEMENT........................................................................................................................................44
17.3. ADMINISTRATIVE...................................................................................................................................................44
17.4. BACKUP RECOVERY OF NETWORK SERVERS AND DATA.......................................................................................................45
17.5. MICROSOFT SQL SERVER 2005 BACKUP.....................................................................................................................46
17.6. COMPUTER VIRUS PREVENTION..................................................................................................................................47
17.7. INCIDENT MANAGEMENT.........................................................................................................................................47
17.8. INTERNET USE.....................................................................................................................................................47
17.9. PASSWORDS........................................................................................................................................................47
17.10. PHYSICAL ACCESS................................................................................................................................................47
18. REFERENCES................................................................................................................................................48
Page | iii

6. Table of Figures
FIGURE 1: FINANCIAL RISK ANALYSIS...................................................................................................................4
FIGURE 2: DEVELOPMENT METHODOLOGY OF THE APPLICATION OF THE ELECTRONIC PRODUCT SALE LOGGING
SYSTEM..............................................................................................................................................................8
FIGURE 3: CONTEXT MODEL..............................................................................................................................11
FIGURE 4: EXISTING WAN ARCHITECTURE..........................................................................................................23
FIGURE 5: EXISTING LAN/WAN ARCHITECTURE..................................................................................................24
FIGURE 6: RACK CONFIGURATION .....................................................................................................................25
FIGURE 7: POINT-OF-SALE ARCHITECTURE AND CONNECTIVITY..........................................................................26
FIGURE 8: CANDIDATE MATRIX..........................................................................................................................28
FIGURE 9: ENTITY-RELATIONSHIP DIAGRAM......................................................................................................31
FIGURE 10: DATA FLOW DIAGRAM....................................................................................................................32
FIGURE 11: PROPOSED SYSTEM ARCHITECTURE.................................................................................................33
FIGURE 12: ANNUAL COST AVOIDANCE.............................................................................................................37
FIGURE 13: BILL OF MATERIALS.........................................................................................................................38
FIGURE 14: LIFE CYCLE COSTS............................................................................................................................39
FIGURE 15: ROI ANALYSIS.................................................................................................................................40
FIGURE 16: PROJECT STAFFING..........................................................................................................................42
FIGURE 17: INTEGRATION OF INTERNAL AND EXTERNAL SYSTEMS AND SERVICES..............................................43
FIGURE 18: TAPE BACKUP ROTATION................................................................................................................45
FIGURE 19: EMC RETROSPECT CONFIGURATION................................................................................................46
Page | iv

7. 1. Executive Summary
1.1. Purpose
This purpose of this project is to provide a technological solution to the problem of manual logbook
management of pseudoephedrine logging for a fictitious, small retail pharmacy chain located in the Ohio
Valley area called Smith’s Pharmacy. This solution will help to provide data and systems needed to track
across state lines while providing reporting capabilities and compliance with Federal regulations.
1.2. Background
Smith’s Pharmacy is a four-store retail chain located in the Ohio Valley area. The company operates
stores in Cumberland, Maryland, Wheeling, West Virginia (where the management office and computer
systems are also located), Washington, Pennsylvania and St. Clairsville, Ohio. These stores provide a
business model based on traditional brick and mortar retail pharmacy, similar to those of its
competitors, CVS Pharmacy, Rite Aid and Kroger. A more recent focus for Smith’s has been its log
keeping activities related to sales of products impact by Pseudoephedrine legislation. Currently, Smith’s
maintains its Pseudoephedrine logbooks manually, using a handwritten account of each sale. This is
required to maintain compliance with State regulations in its Ohio and West Virginia locations.
Specially, Smith’s must abide by statutes Ohio Revised Code, Section 2925.56 and WV 60A-10-5
governing requirements of controlled substances. Violations are severe. Both states impart a fine of
violations; Ohio enforces a maximum of $1,000 and West Virginia $10,000. In addition, Ohio’s statues
call for a jail sentence not to exceed 180 days.
1.3. Industry
Smith’s is a regional, small retail pharmacy chain. Its competitors include larger brick and mortar retail
chains such as CVS and Kroger and mail order. Mail order is particularly troublesome for Smith’s in
particular and the retail industry in general, because it allows consumers to obtain a 90-day prescription
supply instead of one 30-day supply for each co pay. Since Smith’s is much smaller than these national
chains and mail order pharmacies, gaining a competitive advantage in the marketplace is critical to its
continued growth and success. For this project, the automation of the logbook function will provide an
increase in productivity and customer satisfaction by reducing wait times in pharmacy lines. Keeping
compliance is also critical to the continued success of the business by streamlining the audit processes
and eliminating financial risks from non-compliance.
1.4. Vision
We envision a complete change in the way Smith’s tracks sales of pseudoephedrine-legislated items.
Our solution will eliminate the current system of manual logging and each of the four stores will
participate in an online-networked solution for tracking pseudoephedrine sales using an online logbook
application that is auditable from a central data source.

8. 1.5. Scope
The scope of this project will include the following:
1. Design of a centralized database in the Wheeling, West Virginia office to serve as the repository
for pseudoephedrine sales data.
2. Expand the existing WAN network infrastructure to support the new system.
3. Design of an application for each retail location that will collect pseudoephedrine sales data at
point of sale and provide a management reporting capability.
4. Project planning for implementation of the new information system.
5. End user training plan.

9. 2. Project Charter
2.1. Project Objectives
• Create a unified infrastructure across the Smith’s retail pharmacy chain to track Pseudoephedrine
sales by replacing manual logbook tracking measures with an automated system.
• Increase Smith’s regulatory compliance capability by eliminating errors caused by manual log
keeping.
• Increase productivity for the business by reducing customer wait times related to the existing
manual logging procedure.
2.2. Project Conception
The A-Team Consultants envision a system for Smith’s pharmacy that will allow the organization to solve
the problems of manual logbook tracking the sale of products containing pseudoephedrine, ephedrine
or phenylpropanolamine by creating a scalable, automated system to replace the manual logbook with a
high-tech, online solution. This solution can be used by pharmacists in each of Smith’s four locations to
determine of sale of these products to an individual customer is within compliance of Federal and local
regulations. If the company decides to open additional stores in other locations, it can quickly
implement the system into the existing technology infrastructure.
2.3. Problem Statement
Smith’s retail pharmacy stores must record identities of people who purchase over-the-counter
pseudoephedrine products as a deterrent to methamphetamine manufacturing. Currently, Smith’s
Pharmacy tracks this activity on a handwritten log, which presents the following issues
1. They are handwriting information.
2. They are duplicating information (multiple purchases by the same person).
3. They are not meeting privacy requirements because they log multiple sales on one page.
4. They are unable to enforce the intent of the law because they have no immediate, ad-hoc
reporting capabilities at the time of sale, particularly across several locations.
5. They are at financial risk from fines because of 3 and 4.
A solution is needed to replace the traditional logbook in order to provide longer-term (e.g., monthly,
quarterly) reporting functionality across multiple locations and assure these stores meet compliance to
avoid potential legal penalties.

10. 2.4. Financial Risk Analysis
Estimated Financial Exposure, St. Clairsville, Ohio, Location
Based on Smith's Pharmacy FY2007 Sales Data
Revenue, Total Store $811,000
Revenue, Impacted Products $9,780
Average Sale Price, Per Product $25
Transactions, Per Year $391
Estimated Non-Compliance Rate 5%
Non-Compliant Transactions $20
Fine, Per Incident $10,000
Net Impact, Annual $200,000
Impact, % to Total Revenue 24.6%
Figure 1: Financial Risk Analysis
2.5. Initial Scope of the project
This project will implement an automated logbook system to track for Smith’s current chain of four retail
locations in the greater Ohio Valley area. We will develop a system to track information from each
location in a database located at the company’s central site in Store #1, located in Wheeling, West
Virginia. The other three stores – located in Cumberland, Maryland, St. Clairsville, Ohio, and
Washington, Pennsylvania – will have the same tracking application installed in each store. These
systems will interface with the central database in Wheeling using the company’s existing network
infrastructure.
2.6. Project Vision
A-Team Consultants envisions a solution for Smith’s Pharmacy that will provide an automated tracking
of pseudoephedrine sales data with a centrally managed database, and management reporting
capability. The conversion from manual logs in each site to a single unified online system will provide a
means to track pseudoephedrine sales across the chain of stores. The system should include a point of
sale entry capability as well as a reporting module to provide statistical information regarding sales and
compliance.
2.7. Business Constraints
• Training schedule may require additional overtime hours for employees.
• Implementation may require additional pre-deployment testing.
• Up front budget costs of Development, Systems Implementation (including all necessary
equipment), and Training may influence profitability until ROI is achieved.
• Willingness or resistance of employees to adapt to the new system might affect initial success of the
new system.

11. 2.8. Technology Constraints
• Budget will be a consideration in terms of the quality and speed of the equipment.
• Faster computer equipment comes at a higher cost.
o Information Security Solutions are often expensive.
o Budget for database and application development and testing is needed.
o Time required to build the database and applications must be considered.
• Time to test the new system will be needed to ensure stability and reliability.
• Implementation of high security measures for the information systems is critical to keep data private
and maintain regulatory compliance.
2.9. Project Strategy
• Expand existing network infrastructure to house new technology components.
• Build Database Application to include the following:
o User Interface Data Input Screen
o Output Data (Purchase Approval Screen)
o Database Reporting Screens
• Test Application across WAN infrastructure at all four locations.
• Go-Live on approved/agreed date.
2.10. Project Documentation and Communication
We will document the project via a comprehensive project implementation plan. This plan will outline
the details of the development and implementation of the new pseudoephedrine online tracking
system. Communication throughout the life of the project will be in writing or in person between A-
Team consultants and the client, Smith’s Pharmacy. A-Team will meet with the client once per week to
provide progress status updates for the implementation. A-Team will also hold its own meetings once
per week to verify progress.
2.11. Project Organization and Staffing Approach
A-Team Consultants will work closely with members of the Smith’s management team to identify
business requirements related to the project, and to ensure that the project’s technical solution aligns
well with Smith’s strategic business goals. A-Team’s three-member team owns expertise in the fields of
Project Management, Network Engineering and Health Information Systems. The project team for A-
Team will consist of a project manager and 2 technical consultants. The Smith’s management team will
provide two subject matter experts to assist in ensuring that all technical initiatives meet compliance
with local, state and federal regulations. We will provide training on the new system to all store
managers, cashiers, pharmacists and pharmacy technicians.

12. 3. Project Value Statement
3.1. Background
Smith’s Pharmacy has continued to develop a loyal base of customers in Ohio Valley. There is great
potential to grow this business in terms of both local customer base and new retail locations, provided
the company utilizes the automated and centralized logbook solution. With potential expansion further
into the surrounding areas it serves, a project of this nature holds great possibilities for creating a local
competitive edge and greater competition with larger retailers such as CVS and Rite Aid. The value
provided by the Smith’s chain is at great risk if it violates any local, state or federal laws regarding these
products. Violations could negatively affect operations, placing the health of its customers at risk.
3.2. Values
• Increase logbook compliance through database automation.
• Increase customer satisfaction through reduced customer wait times.
• Decrease likelihood of fines and penalties through advanced reporting capability.
• Help reduce illegal methamphetamine production in the region through better enforcement and
accounting of pseudoephedrine sales within legal limits.
• Provide better store expansion capability through system scalability.

13. 4. Project Strategy Statement
4.1. Methodology Overview
A-Team consultants will utilize the Waterfall project development model to complete the Electronic
Product Sale Logging System project for Smith’s Pharmacy. Noting the original methodology as
developed by W.W. Royce, A-Team will follow the prescribed sequential methodology consisting of the
following phases as waterfall steps:
1. Requirements
2. Design
3. Implementation
4. Verification
5. Maintenance
A-Team will build the requirements phase of the development through information gathered from the
client and the business requirements as defined in the business requirements section. Because this
methodology incorporates a staged approach to systems development, it will provide a better structure
for the development of the Electronic Product Sale Logging System for our client. This method is
recommended for situations where the project has a clear objective and solution and resources need to
be conserved (CMS, 2005).
4.2. Meeting Frequency
4.2.1. A-Team Project Development Meetings
The A-Team Consultants will hold staff meetings regularly to review project updates and modifications
as necessary. We will conduct weekly project meetings to review milestones for development, testing,
and rollout schedule in a manner consistent with the aforementioned waterfall methodology.
4.2.2. Smith’s Pharmacy Client Update Meetings
We will conduct weekly status meetings with the Smith’s Pharmacy management team, using the
client’s preferred meeting method. This may include web conferencing, conference calls or face to face
on site. Each meeting will review the project milestones and schedule to keep the project on track for
timely delivery of the new system. The project team will report any unanticipated project issues or
delays to Smith’s Pharmacy management immediately.

14. 5. System Project Methodology
5.1. Electronic Product Sale Logging System Project Methodology
The Electronic Product Sale Logging System will use the Waterfall methodology to development of the
new systems through each phase of the project and system lifecycles. A-Team will follow the prescribed
sequential methodology consisting of five steps. The diagram below shows the standard Waterfall
methodology.
Requirements
Design
Implementation
Verification
Maintenance
Figure 2: Development Methodology of the Application of the Electronic Product Sale Logging System
5.1.1. Requirements
We will build a list of business requirements through close collaboration with Smith’s management
team.

15. 5.1.2. Design
Based on business requirements, we will compose logical and physical designs.
The project team will transform the company’s business requirements into a high-level business plan
from which we will create the logical plan. The following steps are required:
1. Create Use Cases based on Business Requirements
2. Create Data Flow Diagrams to show the flow of information through the model
3. Create Data Model from which the physical database can be created
The technical plan for the project will transform business requirements into a physical design. We will
use these solutions for several critical design milestones:
1. The design of the application, including the user interface
2. The design of the database including all tables, schemas and structures
3. Analysis of the existing network LAN/WAN infrastructure to verify data capacity requirements
4. The integration of an additional application server running the database and application system
software
5. The project planning required for implementation of such solutions
5.1.3. Implementation
Based on the final design and project scheduling, we will present a detailed plan for rollout of the
technologies for Smith’s Pharmacy management team. Once the management team has approved such
implementation, A-Team Consultants will complete a test of the entire system and all functionality prior
to rollout of the system for daily production. The goal of a successful implementation will be to
complete the rollout with minimal impact or interruption to business during the process.
5.1.4. Verification
Critical to the success of the rollout for this system will be pre-production testing. The following items
are critical to the success of the verification phase:
1. Network capacity testing between all four sites
2. Network security testing
3. Application/Database testing using sample data files
4. Database Management Report Testing

16. 5.1.5. Maintenance
The solution will utilize regular maintenance windows for the following purposes:
1) Daily
a) Database Backup to Tape
b) System OS and Image backups to tape
c) Ongoing break/fix maintenance as needed for all hardware, software and applications
2) Quarterly
a) Application Upgrades
b) Security Patches
c) Regularly Scheduled Database Maintenance
d) Network upgrades as required

17. 6. General System Analysis
6.1. Context Model
Store Supervisor Seller
(Clerkr/Phar macist )
Printer
Manual Customer and
Author ization Seller Data Input
Response
Bar Code Reader
Approval for
Purchase/Return
Request
Output Notice /Alert
Automatic Customer Data Input
Stor e & Receive Signature/
Product Info Complete Purchase
Logbook
Electronic Logbook Customer
Database Stor e & Receive
Purchase Request
Customer Info
Purchase Approval
Response
Maintenance/
State & Federal
Updates Regulators
Updates/
Upgrades
A-Team Consultants
Customer
Signature
Signature Capture
IT Department
Pad
Figure 3: Context Model

18. 6.2. Event list
1. Add/Update Customer information
2. Add/Remove Product
3. Process product returns
4. Calculate state and federal limitations of product sale and generate alerts/notices
5. Add/Remove Transaction information (date/time, location, clerk name, product name, quantity)
6. Product summary reports
6.3. Event dictionary
Event Name: Add/Update Customer to database
Event ID: 1
Description: When a customer wants to purchase a product, the customer’s information must be
entered into the database.
Stimulus: Customer wants to purchase a product
Activity: • If user does not exist in the database, then add a record of that customer into the
database.
• If customer is purchasing a product, verify whether it is more or less than 60mg of
PSE. If it does not, no signature is required. If it is, generate a printable notice
warning.
• If Customer is returning a product, adjust transaction record in database.
Response: User Added/Updated.
Effect: If there are no alerts/notices, the customer is able to continue transaction
Event Name: Add/Remove Product to database
Event ID: 2
Description: When a customer wants to purchase a product, the product’s information must be
entered into the database.
Stimulus: Customer wants to purchase a product
Activity: • If the product does not exist in the database, then add a record for that product into
the database. Update product inventory.
• If customer is purchasing a product, verify that it is available from Product
Inventory. If it is available, verify the quantity being sold and update product
inventory.
• If Customer is returning a product, add new transaction and update product
inventory.
Response: Product recorded.
Effect: If there are no alerts/notices, the customer is able to purchase the product.

19. Event Name: Add Process product returns
Event ID: 3
Description: After a customer has purchased a product, they can return it using this feature.
Stimulus: Seller enters transaction number, name and address in return screen.
Activity: The system verifies if the return is valid and requires approval of supervisor. If it is, then
add new transaction and update inventory.
Response: Return is processed.
Effect: Adjusted Transaction/Product details
Event Name: Calculate state and federal limitations of product sale and generate alerts/notices
Event ID: 4
Description: After a customer submits a purchase, this feature verifies if the purchase can complete.
Stimulus: Seller inputs customer and product information on purchase screen.
Activity: The system verifies the sale against federal and state regulations. If a violation occurs, a
notice and warning is displayed in a message box. If not violation occurs, the purchase
can be completed.
Response: Purchase is processed.
Effect: If there are no alerts/notices, the customer is able to purchase the product.
Event Name: Add/Remove Transaction (date/time, location, seller name, product name, quantity)
Event ID: 5
Description: When a customer purchases a product a transaction is recorded into the database.
Stimulus: Customer submits purchase request
Activity: • Create a record in transaction table with date/time, location, product name and
quantity of sale and seller name.
• If the customer is making a purchase, verify that customer is eligible and the
quantity is within state and federal limitations. If eligible record transaction details
in database
• If customer is returning a product, mark returned item into transaction database.
Response: If there are no alerts/notices, the customer is able to purchase the product.
Event Name: Product summary reports
Event ID: 6
Description: Produces reports per query specified by seller, state or federal regulators.
Stimulus: Seller or regulator enters query information into reporting screen.
Activity: Return query results and display in web page for view. The results are adjusted so they
are in print format.
Response: Processed Query results.

20. 7. Business Requirements and Rules
Use Case Name 1. Process Transaction
Scenario Process new sale
Triggering Event Customer attempts to purchase a controlled product
Brief Description When the customer wishes to purchase a product controlled by
Methamphetamine law, the sale must be logged and validated
against sale restrictions.
Actors • Store employee
Related Use Cases
Stakeholders • Customer wants to buy product.
• Pharmacist wants to sell product.
• Company wants to remain compliant with applicable laws
• Regulatory bodies want to control distribution of controlled
products
Pre-conditions • Customer must exist in audit tool.
• Product, Product Category records must exist.
Post-conditions • Transaction record must be created.

21. Use Case Name 1. Process Transaction (continued)
Flow of Events Actor System
1. Customer goes to pharmacy
counter to purchase desired
product.
2. Pharmacist identifies
product requested by
customer.
3. Pharmacist collects
government-issued (State or
Federal) identification from
customer.
4. Pharmacist initiates a new 4.1. P.O.S. begins a new
transaction in the existing transaction journal entry.
P.O.S. system.
5. Pharmacist scans or 5.1. P.O.S. retrieves item details.
manually enters UPC for 5.2. Flag in P.O.S. controller
desired product. indicates transaction must
flow through real-time audit
process.
6. Pharmacist scans or 6.1. P.O.S. system passes
manually enters unique Product and Customer
customer identifier from I.D. parameters to audit
program for validation.
6.2. P.O.S. system adds line item
to transaction if audit
passes.
7. Pharmacist completes sale 7.1. P.O.S. logs transaction
per S.O.P. details to audit system.
Exception Conditions 3.1. If customer cannot provide proper identification, no transaction
is performed.
6.3. If customer does not exist, prompt Pharmacist for customer
demographic information.
6.4. If customer demographic information is not correct, Pharmacist
completes transaction per S.O.P, then invokes 2. Maintain
Customer.
7.1. If audit control program flags sale as invalid, P.O.S. system voids
line.

22. Use Case Name 2. Maintain Customer
Scenario Update customer demographic data
Triggering Event Customer demographic data needs updated.
Brief Description When a customer’s demographic data needs updated, the
Pharmacist must update it via a web portal.
Actors • Store employee
Related Use Cases
Stakeholders • Company wants to remain compliant with applicable laws
• Regulatory bodies want to control distribution of controlled
products
Pre-conditions Customer must exist
Post-conditions
Flow of Events Actor System
1. Pharmacist collects 1.
government-issued (State or
Federal) identification from
customer.
2. Pharmacist logs into web
portal
3. Pharmacist enters maintain
customer screen.
4. Pharmacist locates existing
customer record.
5. Pharmacist updates
necessary attributes.
6. Pharmacist saves updates.
Exception Conditions

23. Use Case Name 3. Add Product Category
Scenario Create a new product category
Triggering Event Legislative changes require new tracking method
Brief Description Applicable laws require sellers to track the sales of certain products
specific ways and limit them specific quantities. Product Categories
allow the company to specify business rules that adhere to the
appropriate laws any particular location must meet.
Actors • Company auditor
Related Use Cases
Stakeholders • Company wants to remain compliant with applicable laws
• Regulatory bodies want to control distribution of controlled
products
Pre-conditions
Post-conditions Existing and new Products must be associated with the new Product
Category.
Flow of Events Actor System
1. Auditor identifies the need
for a new Product Category.
2. Auditor identifies the
appropriate
constraints/business rules
for this Product Category.
3. Auditor logs into web portal.
4. Auditor enters add Product
Category screen.
5. Pharmacist enters necessary
attributes.
6. Pharmacist saves new 6.1. System creates a new
Product Category. Product Category record.
The new Product Category
is made available for use.
Exception Conditions

24. Use Case Name 4. Maintain Product Category
Scenario Maintain an existing product category
Triggering Event Legislative changes require modified tracking method
Brief Description Applicable laws require sellers to track the sales of certain products
specific ways and limit them specific quantities. Product Categories
allow the company to specify business rules that adhere to the
appropriate laws any particular location must meet. This Use Case
also represents instances wherein a Product Category is no longer
legislated for controlled sales.
Actors • Company auditor
Related Use Cases
Stakeholders • Company wants to remain compliant with applicable laws
• Regulatory bodies want to control distribution of controlled
products
Pre-conditions
Post-conditions Existing and new Products must be associated with the updated
Product Category.
Flow of Events Actor System
1. Auditor identifies the need
to modify an existing
Product Category.
2. Auditor identifies the
appropriate
constraints/business rules
for this Product Category.
3. Auditor logs into web portal.
4. Auditor enters Maintain
Product Category screen.
5. Pharmacist modifies
necessary attributes. 6.1. System updates existing
6. Pharmacist saves updates. Product Category record.
Exception Conditions

25. Use Case Name 5. Add Product
Scenario Add a product to the audit program
Triggering Event • Legislative changes require new tracking method
• New product received
• Correction
Brief Description Applicable laws require sellers to track the sales of certain products
specific ways and limit them specific quantities. Product Categories
allow the company to specify business rules that adhere to the
appropriate laws any particular location must meet.
Actors • Company auditor
Related Use Cases
Stakeholders • Company wants to remain compliant with applicable laws
• Regulatory bodies want to control distribution of controlled
products
Pre-conditions Product Category must exist.
Post-conditions
Flow of Events Actor System
1. Auditor identifies the need
for a new Product tracking.
2. Auditor identifies the
appropriate Product
Category.
3. Auditor logs into web portal.
4. Auditor enters add Product
screen.
5. Pharmacist assigns desired
Product Category.
6. Pharmacist saves new 6.1. System creates a new
Product. Product record.
Exception Conditions 5.1. If Product Category does not exist, user pauses this use case
and invokes 3. Add Product Category.

26. Use Case Name 6. Maintain Product
Scenario Maintain an existing product
Triggering Event • Legislative changes require modified tracking method
• Correction
Brief Description Applicable laws require certain products to be tracked in specific
ways and limited to specific quantities of sales. Product Categories
allow the company to specify business rules that adhere to the
appropriate laws any particular location must meet.
Actors • Company auditor
Related Use Cases
Stakeholders • Company wants to remain compliant with applicable laws
• Regulatory bodies want to control distribution of controlled
products
Pre-conditions
Post-conditions
Flow of Events Actor System
1. Auditor identifies the need
to modify an existing
Product.
2. Auditor identifies the
appropriate changes.
3. Auditor logs into web portal.
4. Auditor enters Maintain
Product screen.
5. Pharmacist modifies
necessary attributes.
6. Pharmacist saves updates. 6.1. System updates existing
Product record.
Exception Conditions 1.1. If product has had ingredient changes necessitating change, the
Product Specialist should inactive the existing item code in the
company’s P.O.S. system, a new item number created and the
U.P.C. linked to the new product. Then, a new Product record
should be created via the 5. Add Product Use Case.

27. Use Case Name 7. Generate Summary Reports
Scenario Report needed
Triggering Event Information needed
Brief Description Process to generate reports.
Actors • Company auditor, or
• Pharmacist, or
• Store Management
Related Use Cases
Stakeholders • Company wants to remain compliant with applicable laws
• Regulatory bodies want to control distribution of controlled
products
Pre-conditions
Post-conditions
Flow of Events Actor System
1. User identifies the desired
report.
2. User logs into web portal.
3. User enters Reports screen.
4. User selects appropriate 4.1. System queries database,
report and enters necessary assembles report and
criteria. displays in web browser.
5. User views report.
Exception Conditions

28. 8. Technical Requirements and Assumptions
Smith’s Pharmacy currently owns a networked point-of-sale (POS) sales entry system. The company
purchased the system from IBM to improve the checkout process for the organization. A 100Mb LAN
connects the POS systems within each of the four locations and a WAN provides e-mail connectivity and
internet access across a secured MPLS network from the centralized firewall located in the Wheeling
store. A more detailed description of the existing network is provided in the next section.
8.1. Existing LAN and WAN
8.1.1. Network Operating System and Client PC Configuration
Smith’s Pharmacy uses a small Microsoft Windows Active Directory (AD) Domain running on Windows
2003 Server. This server also provides DNS support required for connectivity of the AD domain, clients
and the Microsoft Exchange e-mail server. Clients (Management PC’s) are configured with the Windows
XP operating system running Service Pack 2; Microsoft Outlook 2003 is used for e-mail, contact and
schedule management.

29. 8.1.2. WAN Infrastructure Overview
Smith’s Pharmacy utilizes a Sprint Multiprotocol Label Switching Wide Area Network (MPLS) consisting
of dual T1 connections to each store. The Wheeling store hosts the e-mail server and serves as a central
proxy point for Internet Web Browsing. All web browser requests traverse the MPLS to the Wheeling
Store where a Checkpoint FW-1 firewall running on a Dell 1850 1U rack-mount server handles packet-
forwarding decisions. This firewall limits inbound access to HTTP (Web browsing) and SMTP (e-mail)
requests. E-mail traffic also traverses the same MPLS cloud for the remaining stores.
The MPLS WAN provides a controlled secure network environment and protects data traffic between
stores from compromise by unauthorized third parties. The diagram below contains a high-level view of
the overall WAN network connectivity. The POS System utilizes the LAN for connectivity to a central
POS controller in each store. The company utilizes the MPLS to manage all locations’ POS systems using
specialized management software.
Figure 4: Existing WAN Architecture

30. 8.1.3. LAN Infrastructure Overview
The following diagram shows a more detailed view of Smith’s Pharmacy LAN architecture in each store
and the physical connectivity of the WAN routers. Note that this diagram also includes one additional
Dell server the company will need to purchase for the application and database implementation. This
diagram also includes a backup circuit for business continuity. A tape backup system using a single
internal mammoth two-tape drive on the Windows 2003 AD domain controller server running EMC
Retrospect backup software Data backups are handles data backup. The current daily full system
backup has approximately 70% available capacity on the existing tape drive to handle additional data.
Figure 5: Existing LAN/WAN Architecture
Each site is connected to the MPLS via a Dual T1 (bundled) 3Mb connection. The backup (failover)
circuit is an ISDN 384k line, with a standard vendor agreement in place for a per-usage based charge. As
previously mentioned, the Wheeling site is the primary IT location for server support. Here, the e-mail
server handles all e-mail for the stores. A separate, dual T1 configuration handles the Internet Web
Browsing requests from all sites.

31. 8.1.4. IT Equipment Rack Diagram
This section shows each store’s rack configuration. The single rack configuration in each location
provides a simple effective solution that occupies minimal space in the computer room in the back of
the each store. An air conditioner cools the room to a constant temperature of 70 degrees Fahrenheit
to protect the IT equipment. A-Team consultants will utilize this existing infrastructure to support the
Electronic Product Sale Logging System. The MPLS as a means of cross-site communication will provide
a secure solution for transfer of the data from all sites to the database located in the Wheeling store.
Figure 6: Rack Configuration

32. 8.2. Point of Sale System
Smith’s Pharmacy utilizes IBM’s ‘Sure POS 300 Series’ point of sale system. IBM describes the Model
300 system as a “cost effective solution to managing cash register transactions in each of its four
locations” (IBM, 2005). Each store’s POS system is capable of operating at the current 100Mbps LAN
speed. The systems are thick-client based PCs, running Windows XP Professional with Service Pack 2.
The POS terminals are connected to a POS Controller, which tracks transactions and inventory across the
LAN. Additionally, the company can remotely audit each controller using IBM’s remote management
software. IBM describes this system as having an “open platform with broad operating system support.”
This provides a user-friendly computing environment with scalability for future growth of the business.
As shown in the diagram below, management can audit all four locations across the MPLS WAN from
any other location. Each store location has four terminals in the front of the store checkout area and
one terminal to service the pharmacy counter.
Figure 7: Point-of-Sale Architecture and Connectivity
8.3. Technical Support
Smith’s has existing technical support in place for the following systems:
• WAN – MPLS via Sprint, the MPLS service provider for the organization’s WAN.
• LAN – Sprint Business Services, including all Cisco LAN hardware, and PC’s:
(Sprint, 2007)
• POS – Support contract with IBM on all IBM POS equipment
• Tape Backup – EMC provides technical support for Retrospect Software. Smith’s Pharmacy store
management in the Wheeling Store handle the changing of daily backup tapes and are trained
on the administration of the Tape backup software.

33. 9. Technical Platform and Tools Required
9.1. .Net Framework 2.0
We will target Microsoft’s .NET Framework, version 2.0, to facilitate the development of the proposed
solution. The framework provides many precompiled software components that implement
functionality commonly used by developers, and many available programming languages. Amongst
these are user interface elements, web application features and database connectivity. Additionally, the
framework facilitates code-reuse and language interoperability, thereby streamlining development time,
future maintenance and testing requirements. Our primary advantage of targeting the .Net Framework
will allow us to reuse the data connectivity code between the web portal and the point-of-sale system.
9.2. Visual Studio 2005
A-Team Consultants will use Microsoft’s Visual Studio 2005 to create the necessary interfaces for the
proposed solution. Visual Studio 2005 targets version 2.0 of Microsoft’s .Net Framework, streamlining
application development for a multitude of platforms. It provides support for database connectivity and
websites, allowing developers to create all content from one development environment.
9.3. Windows Server 2003
We have selected Microsoft’s Windows Server 2003 operating system as the server platform for our
solution. It seamlessly integrates .NET Framework 2.0, provides security, reliability and performance
benefits and completes the unified system architecture desired for this project. Importantly, Windows
Server 2003 includes Internet Information Services 6, allowing the use of ASP.NET applications using
.NET Framework 2.0 developed with Visual Studio 2005. It provides a stable and secure host platform
for our database management system.
9.4. SQL Server 2005
Microsoft’s SQL Server 2005 will provide the back-end data structures and decision logic systems for use
in the proposed solution. It provides a comprehensive, integrated data management and analysis
package that enables organizations to reliably manage mission-critical information and confidently run
today’s increasingly complex business applications. SQL Server 2005 provides scalable product offerings
to allow the organization to meet its needs in a cost effective manner. Also, it provides several
connectivity options for basic and advanced reporting and analysis features via third-party applications,
such as Microsoft’s Access 2007. Clearly, the use of .NET, Visual Studio, Windows Server 2003 and SQL
Server 2005 creates a complete and robust architecture that meets the needs of the organization.

34. 9.5. Candidate Matrix
Characteristics Candidate 1 Candidate 2 Candidate 3
Portion of System New Client/Server web Same as Candidate 1. Same as Candidate 1.
application logbook
Computerized
system.
Benefits Web application would Web application is System would be fully
be independent of all independent of current integrated with current
current systems. All systems. System (or enhanced) systems.
technology is available. framework is already in Great Plains Solutions
place, needing only Provider would manage
configuration and light all technical requirement
visual enhancements. and implementation.
Servers and Microsoft Windows Microsoft Windows Microsoft Windows 2003
2003 servers and IIS 6. 2003 servers and IIS 6. servers and IIS 6.
Workstations
Microsoft SQL Server Oracle 9i. Microsoft SQL Server
2000/2005. 2005.
Workstations use
Workstations use Microsoft Windows IBM POS systems
Microsoft Windows 2000/XP OS. integration.
2000/XP OS.
Workstations use
Microsoft Windows 2000/
XP OS.
Software Tools Microsoft Visual Studio Microsoft Visual Studio Microsoft Visual Studio
2005 2005 2005
Needed
.Net Framework 2.0. .Net Framework 2.0. .Net Framework 2.0.
Application Custom solution built Custom solution built Custom solution built by
by IBM products by Oracle Business the Microsoft products
Software
integrated into current Suite products integrated into current
IBM POS system. integrated into current IBM POS system.
IBM POS system.
Method of Data Client/Server. Same as Candidate 1. Same as Candidate 1.
Processing
Output Devices Laser and Bar Code Same as Candidate 1. Same as Candidate 1.
printers.
and Implications
Input Devices and Keyboard, mouse and Same as Candidate 1. Same as Candidate 1.
bar code reader.
Implications
Storage Devices Microsoft SQL Server Oracle 9i DBMS with 10 Same as Candidate 1.
DBMS with 10 GB GB storage.
and Implications
storage.
Figure 8: Candidate Matrix

35. 10. Third-Party Needs
A-Team focuses on delivering a complete range of cost-effective services tending to our customer’s
requirements. We provide support prior and post sale support through comprehensive after sale
maintenance and support to ensure our client’s investment. A-Team undertakes all software planning
and development in-house to maintain the privacy and integrity of our customers. A-Team does not
associate with external partners, suppliers or consults.
Smith’s Pharmacy has presented its current systems in place to our team; therefore, A-Team will focus
on tailoring software requirements to meet those specifications. Smith’s Pharmacy will need to acquire
additional hardware and software for the implementation of the logbook application.
10.1. Vendors
10.1.1. Dell
Dell Inc. (Dell) designs, develops, manufactures, markets, sells and supports a range of computer
systems and services that are customized to customer requirements (Reuters, 2007). These include
enterprise systems (servers, storage, workstations and networking products), client systems (notebook
and desktop computer systems), printing and imaging systems, software and peripherals, and global
services. The Company markets and sells its products and services directly to its customers, which
include corporate, government, healthcare and education accounts, as well as small-to-medium
businesses and individual customers.
10.1.2. Microsoft
Microsoft Corporation develops, manufactures, licenses and supports a range of software products for
computing devices (Reuters, 2007). The Company's software products include operating systems for
servers, personal computers (PCs) and intelligent devices, server applications for distributed computing
environments, information worker productivity applications, business solution applications, high-
performance computing applications and software development tools. The Company has five segments:
Client, Server and Tools, the Online Services Business, the Microsoft Business Division, and the
Entertainment and Devices Division. The type of licensing for Microsoft Windows Server 2003 and SQL
Server 2005 will need to be identified and purchased depending on the needs for the logbook
application
10.1.3. IBM
International Business Machines Corporation (IBM) is an information technology company. IBM also
provides business, technology and consulting services. The Company's major operations comprise a
Global Services segment, a Systems and Technology Group, a Software segment and a Global Financing
segment. (Reuters, 2007) IBM offers five kinds of software solutions. The Company's software offerings
include Information Management Software, an advanced database and content management software

36. solutions that enable clients to leverage information on demand; Lotus Software, a collaboration and
messaging software that allows businesses to communicate, collaborate and increase productivity;
Rational Software, an integrated tools designed to improve an organization's software development
processes and capabilities; Tivoli Software, a software for infrastructure management, including
security, change, configuration, job scheduling, storage capability, performance and availability, and
Websphere Software, which provides management of a range of business processes using open
standards to interconnect applications, data and operating systems.
IBM provides a range of services, which includes Business Performance Services (BPS), Business
Transformation Outsourcing (BTO), Consulting and Systems Integration (C&SI), Strategic Outsourcing
Services (SO), Integrated Technology Services (ITS), Application Management Services and Applications
on Demand (AoD). BTO delivers improved business results to clients through the strategic change and
the operation and transformation of the client's business processes, applications and infrastructure. ITS
provides service offerings that help clients access, manage and support their technology infrastructures,
through a combination of resources, software and IBM's knowledge of business processes. C&SI
provides consulting services for client relationship management, financial management, human capital,
business strategy and change and supply chain management, as well as application innovation and the
transformation of business processes and operations.
10.1.4. Suppliers
No additional will be needed.
10.1.5. Consultants
No additional will be needed.

37. 11. Database/ERD Model
ProductCategories
PK ProductCategoryId COUNTER
Description CHAR(50)
State CHAR(2)
TrackSales BIT
SizeLimit DOUBLE
Customers assigned to
PK CustomerId COUNTER
Products
StateId CHAR(10)
State CHAR(2) PK ProductId COUNTER
StreetAddress 1 CHAR(50)
StreetAddress 2 CHAR(50) UPC CHAR(18)
City CHAR(30) FK1 ProductCategoryId LONG
PostalCode CHAR(10) Size DOUBLE
sold on
Transactions
PK TransactionId CHAR(24)
makes
Timestamp DATETIME
FK2 CustomerId LONG
FK1 ProductId LONG
QtySold LONG
Voided BIT
Figure 9: Entity-Relationship Diagram

38. 12. Data Flow Diagram
Changes required 2.
Pharmacist Maintain
Update Ok Customer
Process Transaction
Sale Ok Response
Customers
1.
Process
Transaction Products
Product
Categories 4.
Add/update
Product
Changes required
Transactions
Update Ok
3. Changes required
Add/update Company
Product auditor
Category Update Ok
Figure 10: Data Flow Diagram

39. 13. System Architectural Diagrams
The Electronic Product Sale Logging System will tie into the existing IBM POS System. The diagram
below shows a high-level view of the overall system.
Figure 11: Proposed System Architecture
As indicated in the diagram, the POS Controllers will interface with the new database application to
provide a real-time ephedrine logging process, which will initiate from the POS terminal. The
transaction process will be coordinated between the POS controller and the database to provide
approvals, log transactions and track customer specific purchase information to maintain compliance
with regulatory officials. Management can use its existing PCs to generate reports via the POS
controllers, which will pull data from the database server in Wheeling.

40. 14. Project Risk and Risk Management
A-Team strives to integrate consistent practical risk management and loss management standards of the
highest quality into all our business processes. We firmly believe in our ability to develop strategies to
manage and mitigate risk if in case it should arise. The following, are the processes to manage project
risks:
• Risk Management Planning
• Risk Identification
• Qualitative/Quantitative Risk Analysis
• Risk Response Planning
• Monitoring and Control
The purpose of these processes is to influence the probability and impact of risks.
14.1. Risk Management Planning
We have identified possible risks associated with the Electronic Logbook Application and prioritized
them whereby the risks with the greatest loss and the greatest probability of occurring are tended to
first and risks with a lower probability of occurrence are tended to in descending order.

41. Risk Environmental Impact Probability Risk Response
component Variable
Scheduling and Unrealistic project Moderate High Implement Further Actions to Reduce
Budget Risks schedule delays Risk; Continue Existing Controls;
Generate Contingency Plan; Review at
least every 3 Months
Unrealistic project Significant High Take Immediate Further Remedial
budget overrun Action to Reduce Risk; Contingency
plan on standby; Review at least
Monthly
Project canceled prior Significant Medium Quickly Implement Further Actions to
to completion Reduce Risk; Continue Existing
Controls; Generate Contingency Plan;
Review at least every 2 Months
System Developing wrong user Minor Medium Tolerate; Continue existing Simple
Functionality interface Control Measures; Review at least
Risks every 6 Months
Develop wrong Minor Low Tolerate; No action: Continue Control
software functions if Required; review at least Annually
Real-time performance Moderate Very High Quickly Implement Further Actions to
shortfalls Reduce Risk; Continue Existing
Controls; Generate Contingency Plan;
Review at least every 2 Months
Requirements Unmet user Moderate High Implement Further Actions to Reduce
Management requirements Risk; Continue Existing Controls;
Risks Generate Contingency Plan; Review at
least every 3 Months
Gold Plating Minor Very Low Tolerate; No action: Continue Control
if Required; review at least Annually
Continuous Significant Very High Take Immediate Further Remedial
requirement changes Action to Reduce Risk; Contingency
plan on standby; Review Continuously
Resource Usage Hardware/Software Minor Very Low Tolerate; No action: Continue Control
And technology upgrades if Required; review at least Annually
Performance
Straining computer Moderate Medium Tolerate; Continue existing Control
Risks
science capabilities Measures; Possible Contingency Plan;
Review at least every 4 months
Personnel Insufficient expertise Significant Low Tolerate; Continue existing Control
Management and expectations for Measures; Possible Contingency Plan;
Risks personnel Review at least every 4 months
Personnel shortfalls Significant High Take Immediate Further Remedial
Action to Reduce Risk; Contingency
plan on standby; Review at least
Monthly
Project manager’s Significant Very Low Tolerate; Continue existing Control
training/Experience Measures; Possible Contingency Plan;
Review at least every 4 months

42. * The Probability is identified as 'Very Low', 'Low', 'Medium', 'High' and 'Very High’. However, it must be considered that very
low probabilities may not be very reliable.
Green - minor, no harm event or near miss, requires no follow-up
Yellow - moderate event or near miss, requires local management action
Red - significant event or near miss, requires senior management attention
14.2. Qualitative/Quantitative Risk Analysis
Qualitative risk analysis is the cost-effective process of assessing the impact and likelihood of identified
risk. It prioritizes risks according to their potential effect on project objectives.
Quantitative risk analysis is the process of numerically rating the probability of each risk and its
consequence on project objectives.
14.2.1. Risk Response Planning
This process employs a number of different techniques to reduce and mitigate risk on projects (Stoeller,
2003):
• Risk acceptance - project team decides not to change project plan and “accepts” the risk. Active
acceptance includes developing a contingency plan. Passive acceptance leaves project team to
deal with risk if it occurs.
• Risk avoidance - involves changing the project plan to eliminate the risk such that the risk no
longer exists.
• Risk mitigation - involves a mix of techniques aimed at either reducing the probability or impact
of a risk.
• Risk transfer - involves transfer of ownership of the risk to another party with the right skills that
is available.
• Risk reserves are buffers in our schedules and budgets set aside for alligators or puppies.
14.2.2. Monitoring and Control
This process monitors newly arising risks, and tracks existing risks and trigger conditions during the
project lifecycle. Project managers perform this process in order to determine:
• Determine if risk responses were implemented as planned.
• Determine if response actions are as effective as expected.
• Determine if project assumptions are still valid.
• Determine if risk exposure has changed.
• Determine if a risk trigger has occurred.
• Determine if an unidentified risk has occurred (Holtzman, 2004).

43. 15. Project Costs, Staffing, Resources, Dependencies and
Schedule
The Cost Analysis presents the costs for materials, design, development, testing, training,
implementation and maintenance for the system to be developed. It is expected that each team
member will work a 40 hour week.
For this release the expected budget is $35,555.12.
15.1. Benefits
The primary projected benefit of the new system is the cost avoidance of the salaries of the pharmacy
staff currently doing this effort. The secondary benefit is the efficiency, speed and accuracy of the
reports. The system will provide the tracking reports on the first day of the new month rather than
inconsistent days into the month as prior. Accuracy in the data stored will vastly improve due to
elimination of most manual errors currently entered.
The primary benefit is the current cost to Smith’s of the personnel manually entering data. Per our
meetings and reports provided by Smith’s, it’s apparent that about 25% of an employee’s time is spent
manually entering data and trying to validate it in-case it isn’t legible. Therefore, we estimate that 75%
of the time for each of Smith’s locations would be available for other duties. We anticipate that the
proposed solution will eliminate approximately 20% of the current effort. Therefore, the annual cost
avoidance of each store will be equal to 20% of the annual cost of an employee’s salary.
Annual Burdened Cost (BC) Cost Avoidance Factor (CA) # of Workers Annual Cost Avoidance
$70,000 0.20 10 $140,000
Figure 12: Annual Cost Avoidance

44. 15.2. Bill of Materials
This section provides a bill of materials elements required for Smith’s Electronic Product Logging System.
Component Description Quantity Price
Dell PowerEdge 1950 Dual Core Intel® Xeon® 5148LV, 4MB Cache, 2.33GHz, 1333MHz FSB,ES, 1 $3,537.37
Server Windows Server® 2003 R2, Standard Edition with SP2, Includes 5 CALs
Microsoft Windows Server management operating system. 1 *Free
Server 2003
Microsoft Visual Studio Development software for applications, websites, service, etc. 1 $0
.Net 2005
Microsoft SQL Server SQL Server Management Studio Express, for easily managing a database. 1 Free
2005 Express
Totals $3,537.37
*Windows Server 2003 is included with Dell PowerEdge 1950 Server
Figure 13: Bill of Materials

45. 15.3. Triple Cost Analysis
Three alternatives were considered for developing, designing and maintaining the new system. The
alternatives and their estimated present value costs for a year are as follows.
• Minimal Alternative - $26,068. This solution focuses on rapid project delivery date and minimal
training costs.
• Recommended Alternative - $32,018. This solution focuses on the best project delivery
schedule, minimal delays and interference with current work.
• Maximum Alternative - $55,959. This solution focuses on maximum benefits for the new system
with an extended schedule life.
Life Cycle Costs of Project Alternatives
Minimal Recommended Maximum
Alternative Alternative Alternative
Define Requirements $1,928 $2,689 $7,035
Designs Costs $4,459 $6,139 $10,400
Development Costs $8,660 $9,740 $12,640
Testing Costs $4,988 $5,698 $12,480
Training costs $1,768 $1,829 $4,440
Implementation Costs $4,265 $5,924 $8,964
Warranty Costs $0 $0 $0
Total Life Cycle Costs $ 26,068 $32,018 $55,959
Figure 14: Life Cycle Costs

46. 15.4. Return on Investment Analysis
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5
Initial Costs $ (35,555.12)
Maintenance $ (2,000.00) $ (2,200.00) $ (2,420.00) $ (2,662.00) $ (2,928.00)
Discount Rate @ 14% 1.00 0.88 0.77 0.67 0.59 0.52
Discounted Costs $ (35,555.12) $ (1,754.39) $ (1,692.83) $ (1,633.43) $ (1,576.12) $ (1,520.71)
Cumulative Costs $ (35,555.12) $ (37,309.51) $ (39,002.33) $ (40,635.77) $ (42,211.88) $ (43,732.59)
Benefit Revenue $ - $ 140,000.00 $ 145,600.00 $ 151,424.00 $ 157,481.00 $ 163,780.00
Discount Rate @ 14% 1.00 0.88 0.77 0.67 0.59 0.52
Discounted Benefits $ - $ 122,807.02 $ 112,034.47 $ 102,206.89 $ 93,241.39 $ 85,062.20
Cumulative Benefits $ - $ 122,807.02 $ 234,841.49 $ 337,048.38 $ 430,289.77 $ 515,351.97
Cost-Benefit $ (35,555.12) $ 85,497.51 $ 195,839.16 $ 296,412.61 $ 388,077.89 $ 471,619.38
Payback Period = $35,555 / $85,498 Payback 0.42
Return-on-Investment = $471,619 / $43,733 ROI 235.68%
Net Present Value = $515,352 + ($43,733) NPV $471,619
Figure 15: ROI Analysis

47. 15.5. Project Schedule
1. Requirements 6.2.3.Update POS Terminals
1.1. Document Requirements 6.2.4.Perform Smoke Test
1.2. Requirements Review 6.3. Milestone: Installation Complete
1.3. Approve Requirements 7. Warranty Contingency
1.4. Milestone: Requirements Defined 8. Milestone: Project Complete
2. Design
2.1. Develop Design
2.2. Design Review
2.3. Approve Design
2.4. Milestone: Completed Design
3. Development
3.1. Develop Database Components
3.2. Develop Web Components
3.3. Develop POS Terminal Components
3.4. Unit Testing
3.5. Code Review
3.6. Milestone: Development Complete
4. Testing
4.1. Write Test Scripts
4.2. Test Script Review
4.3. Approve Test Scripts
4.4. Milestone: Test Scripts Developed
4.5. Setup Test Environment
4.6. Perform Functional Testing
4.7. Review Results
4.8. Approve Results
4.9. Milestone: Testing Complete
5. Training
5.1. Reset Testing Environment
5.2. Develop Training Plan
5.3. Train Plan Review
5.4. Approval Training Plan
5.5. Milestone: Training Plan Document
5.6. Perform Training
5.7. Training Teachback
5.8. Milestone: Training Complete
6. Implementation
6.1. Hardware Installation
6.1.1.Procurement
6.1.2.Configuration
6.1.3.Test
6.1.4.Milestone: Hardware Installed
6.2. Software Installation
6.2.1.Install SQL Server 2005
6.2.2.Install IIS

48. Project Staffing
Position No. of Duties Answers to
Positions
Smith’s 1 Monitor the overall operation and plan for future Smith’s President
Management opportunities.
Pharmacist 1 Manage the day-to-day operations of the electronic Smith’s Manager
logbook system.
Project Manager 1 Manage/Monitor the Information Systems needs of A-Team Consultants
the operation. Management
Software Engineer 1 Develop/Maintain system Project Manager
Systems Architect 1 Develop/Maintain system Project Manager
Network Engineer 1 Develop/Maintain system Project Manager
QA Tester 1 Test system Project Manager
Figure 16: Project Staffing

49. 16. Integration of Internal/External Systems
The integration of the new Ephedrine product database with Smith’s existing IT infrastructure requires
some additional application programming to create a web services environment that will communicate
with the existing IBM 300 series POS system. The goal is to invoke the database application using the
existing POS so that the existing system is enhanced, not replaced.
The Electronic Product Sale Logging System will tie into an existing IBM POS300 Point of Sale System
currently in operation at Smith’s Pharmacy. The application system will be installed on each POS
controller to tie in with the existing POS software.
Based on the DBMS structures and stored procedures, a web server will connect to the DBMS to execute
the stored procedures. The website will expose some web services than the POS system will consume.
The POS system will send parameters to the web service and handle the response activity for the POS
terminal.
Figure 17: Integration of Internal and External Systems and Services

50. 17. System Administration, Security, Backup and Recovery
17.1. Policy
Smith’s Pharmacy secures its I.T. assets to protect corporate information and protect the privacy of such
information. With the integration of the new online logbook tracking system, the integrity of this secure
environment must be maintained. All networked computer and POS data is considered confidential and
property of Smith’s Pharmacy, Inc.
17.2. Account Management
Internal accounts are maintained for e-mail and management of the POS system. Managers are
equipped with a laptop for management purposes. This laptop contains a Windows domain account,
which is maintained on an Active Directory domain server in Wheeling. In addition, each POS terminal
contains a logon capability for each cashier. All Cashiers (Including Pharmacists) have a user account
maintained in the domain controller for logon to the POS terminals.
17.3. Administrative
To ensure all Administrative accounts with elevated access privileges on computers, network devices,
and other critical equipment (example: accounts used by system administrators and network managers)
are used only for their intended administrative purpose, all authorized Users must be made aware of the
responsibilities associated with the use of privileged special access accounts and comply with all
associated policies, standards, and /or procedures established by the company.

51. 17.4. Backup Recovery of Network Servers and Data
The Wheeling, West Virginia site has a small tape backup system consisting of a single tape drive
(installed within a single Dell 1850 rack mounted server). The tape drive’s daily data backup routine is
managed using an EMC product called “Retrospect.” This tape management software product is geared
toward small and medium sized business. As a part of the daily backup routine, store managers are
responsible for changing the data tapes. Tapes are rotated offsite in a 3-week rotation. A single week’s
tapes (five tapes), 2 weeks out of rotation are stored offsite with a local tape archive company in a
controlled environment to protect the physical integrity of the tape. These tapes may be recalled at any
time for any reason should the need arise to restore lost files.
Figure 18: Tape Backup Rotation

52. The current backup system protects e-mail, files from the POS controllers and user account information
for the local area network. The new logbook system will require backup of database information stored
in the new Microsoft SQL database. The current capacity of the tape will support the additional data,
but as the size of the database grows, future consideration might be made to expand the tape backup
capability by adding an additional tape drive and expanding the terms of the contract for offsite storage
to accommodate the additional tapes. As shown in the diagram below, the Exchange e-mail server
mailboxes, POS controller data and network directories are backed up. The SQL database backup will be
added to the daily data backup prior to go-live for the new application.
Figure 19: EMC Retrospect Configuration
17.5. Microsoft SQL Server 2005 Backup
To provide a complete disaster recovery option for the new application, a proper backup of the
Microsoft SQL database must be performed. Microsoft’s specific recommendations for backup (and
restore) of the SQL 2005 database can be found at http://technet.microsoft.com/en-
us/library/ms187048.aspx and http://technet.microsoft.com/en-us/library/ms186289.aspx.