Docstoc

USPS Development Plan 2

Document Sample
USPS Development Plan 2 Powered By Docstoc
					United States Postal Service
PMRE | Predictive Monitoring and Reporting Environment
Development Plan | Version 2
February 20, 2006



Preface
This document contains the formal Development Plan for the United States Postal Service
project dubbed PMRE, Predictive Monitoring and Reporting Environment. The organization of this
document follows the IEEE std. 830 guide, modified for the needs of our project. Items that are
ITALICIZED are defined as they pertain to this project in the glossary.



     Extended Requirement Specification Outline
     1. Overview of the Project
     2. Measurable Operational Value
     3. The Project Management Structure
     4. Solution Description
     5. Assumptions
     6. Constraints
     7. Requirements
     8. Interfaces
     9. Architecture
     10. Design Simplifications
     11. Sample Use Cases
     12. Feature List
     13. Deliverables
     14. Algorithm
     15. Risk Assessment
     16. Implementation Details
     17. Function Point Analysis
     18. sQFD and ICED-T Metics
     19. Gantt Chart and COCOMO
     20. Test Plan
     21. Glossary
     22. References
     23. Change Log and Expected Changes
     24. Team Composition


1.      Overview of the Project

Client Background
The USPS is the nation’s largest not-for-profit courier of parcels. The organization of
the company is such that they employ multiple regional sorting facilities based on
geographic mail volume patterns. The size of these facilities ranges from man operated
to large warehouse style buildings with dozens of automated sorting machines. Millions
of items are sorted each day in some of these sub-centers.

Problem Description
The sorting facilities employ dozens of automated machines to sort mail based on
several predetermined characteristics. The organization of the large sorting facilities is
such that the machines require varying sized bins to store sorted parcels. Some
locations have over 100,000 of these bins on hand, but they are often scattered
throughout a building. Employees face a scavenger hunt each time a machine requires
additional bins which left machines idle.

Scope of the Problem
This same problem is undoubtedly present at sorting facilities word wide and is likely
to be present in tasks other then mail sorting. Intuitively, the solution should be
customizable enough to address this problem regardless of the physical location or
organization.

Client Specified Solution Characteristics
The USPS needs a reliable, fault tolerant, secure system to solve this efficiency and
organizational problem while providing an API that will allow the solution to grow and
evolve as the technology available changes.

Why this Project?
The particular project presented a unique set of challenges. The need for both a
mathematically sound algorithm for mail volume prediction and an ascetically pleasing
web based application is akin to real world development. With the recent trends
towards decentralized web based applications this project gave us an opportunity to
gain experience in this new and fast growing sector of computer science. Additionally,
the project also involves the use of some hardware to software interfacing for the RFID
Tracking system. At no time in our four years here at Stevens have we been given
such an opportunity to code drivers for hardware manipulation. These opportunities
and characteristics led us to choose this project.


2.     Measurable Operational Value

PMRE will increase the efficiency and corresponding capacity of the USPS’s current
parcel sorting infrastructure by 30% through predictive historical data analysis and
strategic equipment placement while improving economic viability. Engineering
Management studies have shown that sorting machines run idle for approximately
30% of the day as employees search for bins by increasing the efficiency 30% (.30 x
.70 = .21), to a new capacity of 91% leaving only 9% idle time. PMRE will minimize
the amount of time these sorting machines remain idle.




3.     The Project Management Structure
Our Project Management Structure was constructed to address two key points of risk
in a project: Failover (loss of that individual from the project), and Supervision (the
need to monitor project progress). The structure is shown below, a formal explanation
follows each section.



Team Mangers
Anthony Virtuoso            Development Manager                  avirtuos@stevens.edu
Paul Ballantyne             Document Manager                     pballant@stevens.edu
As shown above we have two overall mangers. To remove the burden of document
management and other administrative tasks from the development team the
Document Manager addresses these issues and has the authority to make decisions
regarding related tasks. The Development Manger the overall decision making
power in the group to avoid power conflicts. His primary role is to coordinate the
development process and step in where necessary to ensure the schedule is met.


Special Agents
Ilya Chalyt                  Configuration Manager                ichalyt@stevens.edu
Yuriy Stelmakh               Systems Architect                    ystelmak@stevens.edu
David Byrne                  Statistician                         dbyrne@stevens.edu
Jacob Kosinski               Testing Manager                      jkosinsk@stevens.edu

The Configuration Manager is charged with the task of documenting and replicating
the settings, and attributes of both development systems and the software being
developed. By managing such items we can avoid costly configuration errors between
the target system and development. The Systems Architect is responsible for
designing and maintaining the system architecture and works closely with the
Configuration Manager to provide a development and target platform. The
Statistician was specially created for this project because of the large mathematical
dependencies of the underpinning algorithms. His primary purpose is to formulate the
prediction engine outlined in the project requirements. The Testing Manager handles
all the integration testing and organizes the unit testing data provided by the
developers. Each of these individuals is also considered a developer but take on these
addition responsibilities depending on the stage of project.


Developers
Vedant Bhanderi              Developer                            vbhander@stevens.edu
ChunWing Lam                 Developer                            clam2@stevens.edu
Steve Su                     Developer                            psu@stevens.edu
Eric Frey                    Developer                            efrey@stevens.edu

The Developers primary role is to code the application and avoid the distractions that
are to be handled by the management structure. Each developer is responsible for
documenting and testing the modules they are assigned. They report to the testing
manager who in tern compiles and turns in software modules to the Development
Manager.

EM Contact
Eliot Dahood                 Engineering Management               edahood@stevens.edu

The Client in our project has played a limited role. Because of their limited availability
and the proof-of-concept nature of this project we were only furnished a problem
description and some minimal requirements. Therefore we are to create a full solution
of our own design.



4.     Solution Description
A good generalization of the solution would be: ‘an application that can accept the
organization of a facility, historical mail volume data, and an inventory of bins on hand
as parameters and provide accurate predictions of how many bins to place in the
predefined staging areas.’

        By analyzing historical mail volume data for a given day one could accurately
         predict the number of bins needed to handle the items.
        With defined staging areas throughout the facility bins could be stockpiled in
         these areas based on mail patterns (per machine) for the surrounding floor
         area.
        Overfilled staging areas are offloaded to nearby locations with available space.
        Further analysis could easily be incorporated to address multiple shifts in a
         given day and other factors such as machine servicing.

By making this application a web based solution the end result will be a product that is
easily maintained, cross-platform, and avoids complex deployment issue.


*USPS is considering this as one of many possible solutions to the problem and as
such it must be treated as a proof-of-concept. Extra documentation and simulation
data will be important in the success and adaptation of this product.



5.       Assumptions
Our goal is to improve the efficiency of this sorting process by decreasing time
machines run idle because of poor bin placement. The following assumptions are the
foundation of this software design product.

        All machines of a specific type have an equal load.
             o This is based on the notion of efficiency and is a key simplification of the
                problem being faced. If one machine is running at full capacity and two
                other machines are sitting idle there is lost productivity. However, if all
                three machines run at a comparable load then we are maximizing
                throughput.
        All staging areas are uniformly spaced.
             o An uneven distribution of staging areas should not occur if the need of a
                particular area requires additional storage the size of the staging area
                should be adjusted. Grouping of physically separate areas into a single
                staging area is also an alternative.
        Machines of similar type or function are either evenly dispersed or grouped.
             o Violation of this assumption would introduce and inherent inefficiency in
                the organization of the facility that would add an order of magnitude to
                the degree of this problem thereby limiting the gains realized by any
                solution.
        There are no barriers sufficiently large in correspondence to the walking
         path such that they alter the efficiency of one path versus another.
             o Based on the map provided by USPS there were no cases where a large
                obstruction significantly altered the efficiency of one walking path versus
                another.
             o The distance between staging areas is sufficiently large such that the
                difference in path chosen is erroneous.
        Staging areas and machines are defined by the client and are not to be
         varied by our algorithm.
              o   The client is able to specify the location and size of staging areas. The
                  application may not assume these to be variable. The client can change
                  these at any time.
              o   The client is able to specify the location and capacity of a machine. The
                  application may not assume these are variable. The client can change
                  these at any time.




6.         Constraints

           1. The client software should not require any specialized hardware or software
              requirements other than the application itself. (not including web browser)
           2. There is no budget allotment for the development process. No proprietary
              solutions may be used in the development process.


7.         Detailed Requirements

     I.       Overall Requirements
              a. The application will be referred to as PMRE :: Predictive Monitoring and
                 Reporting Environment.
              b. The application will improve the efficiency of the sorting process by
                 organizing the supporting infrastructure to reduce the down time of any
                 given sorting machine.
              c. The application must use historical data to predict future mail flow
                 volumes.
              d. The application must allow users to override the predictions if they so
                 chose.
              e. The application must take the predicted (or overridden) value for the
                 mail volume of a specific category of mail and recommend the quantity
                 and location of bins to handle the volume.
              f. The application must formulate its recommendation for bin placement in
                 a manner that will minimize the travel time for the bins to reach the
                 machine.
              g. In addition to this predictive organizing algorithm, the application will
                 track the location of bins so that in the event of a shortage employees
                 know the location of the nearest suitable bin.
     II.      Integration
              a. PMRE must be able to co-exist with the current way of managing
                 equipment.
              b. Deployment will be staggered to mitigate integration and migration
                 woes.
     III.     Architecture
              a. The application must be implemented as a Web-Based Application
                 implemented in PHP and HTML with a MySQL database server.
              b. Deployment
                       1. The application must be accessible from any terminal desired,
                          regardless of location (intranet and internet).
              2.   The application must be cross-platform, supporting Wintel,
                   UNIX, and LINUX variants.
      c. Scalability
              1. The application should be able to support a minimum of 10
                   concurrent users and a maximum of 100.
      d. Availability
              1. The application must be available 99% of the time during
                   business hours (9am – 9pm).
      e. Reliability
              1. The application must support simultaneous and redundant
                   shadow copying of the production environment.
              2. The database server must support replication and transaction
                   recovery.
      f. Safe
              1. The application must do no harm to surrounding systems in the
                   event of a malfunction.
              2. Data integrity must be preserved wherever possible in the
                   event of a failure.
IV.   Security
      a. Transportation and Communication
              1. The application must be secured from malicious intruders by
                   utilizing an encrypted data transport protocol.
              2. Authenticity of communication should be validated through the
                   use of SSL certificates.
              3. All data transmission must be encapsulated in a secure socket
                   layer, SSL.
              4. Data must not be altered during the process of transportation.
      b. Connection Sessions
              1. The application should not allow users to remain connected to
                   the system if they are idle for more than 15 minutes.
              2. Users can only access data for which their accounts have been
                   permission.
      c. Permissions
              1. Any user on the intranet that visits the website should be able
                   to view a read-only copy of staging area states.
              2. Users outside of the intranet may login and view a read only
                   copy of the staging area states.
              3. Users on the intranet who login will be able to perform
                   administrative actions on the system. This means modifying
                   any of the adjustable parameters for the system.
              4. Only SYSTEM ADMINISTRATORS are allowed to add, remove, or
                   modify user accounts.
              5. A user can only be logged in from one location (ip address) at a
                   time. (note: use the PHP function $REMOTE_ADDR)
      d. User Account Requirements
              1. Users must have a unique identification string consisting of
                   between 5 and 20 alphanumeric characters.
              2. Users must have a password associated with their accounts
                   consisting of between 5 and 10 characters and contain both
                   numbers and letters.
              3. The user’s password must always be encrypted. This includes
                   during transmission and storage.
              4.   All passwords must be stored using a one-way encryption hash.
                   MD5 in our case.
               5. The user must be able to change his or her password.
               6. If the user enters the wrong password 3 times or more their
                   account will be locked until such time that an administrator
                   verifies their identity. The user should be notified to contact
                   their administrator.
               7. Each time the user enters an incorrect password (< 3 times)
                   they should be given the option to reset their current password
                   by answering their security question. The new, random
                   password will be emailed to the address on record.
               8. The activities of a user should be logged with timestamps.
                   Logins and modifications of the database must be tracked.
V.    Data Storage and Collection
      a. The system will utilize a relational database server.
      b. Our implementation will take advantage of the open source MySQL 4.1
         Relational Database Server.
      c. The application will be written in such a way that any database may be
         used in the future by simply providing a set of interface functions to
         replace the ones we have created for MySQL.
      d. The database must also contain log tables for the following transactions:
         RFID movements, user overrides of predicted values. Defined Below
                 statistics(s_date, shift_id, type_id, quantity)
                   This table will hold historical mail volume data.
                      s_date: The date the statistic has been obtained.
                      shift_id: The shift id of the statistic.
                      type_id: The type id of bins used.
                      quantity: The quantity of bins used.

                   travel_log(t_date, rf_id, loc_id)
                   This table will hold historical bin travel history generated by RFID tracking.
                    t_date: The date the statistic has been obtained.
                    rf_id: The rfid of the item.
                    loc_id: The location id where the bin arrived.
                   rec_log(r_date, shift_id, loc_id, type_id, uid, quantity)
                   This table will hold recommendations generated by this system and users.
                  r_date: The date the recommendation is for.
                  shift_id: The shift id pertaining to recommendation.
                  loc_id: The location for this recommendation.
                  type_id: The type of bins for this recommendation.
                  uid: user id of the override. (-1 :: auto generated)
                  quantity: The recommended number of bins
      e. The application will allow new data to be entered from other applications
         through the API or SOAP interface.
      f. All recommendations, predictions, and user overrides of predictions
         must be stored in the database.
VI.   Data Analysis and Prediction engine
      a. The application must predict mail volume to within 10% of the actual,
         95% of the time.
      b. The application must learn by incorporating new data as it becomes
         available.
      c. The database must hold historical mail data with respect to the following
         properties:
                1. s_date: The date the statistic has been obtained.
                2. shift_id: The shift id of the statistic.
                3. type_id: The type id of bins used.
                4. quantity: The quantity of bins used.
      d. The application will allow the user the ability to enter new ‘historical
         data’ as it is collected.
      e. The application will NOT take into account any bins generated by the
         sorting of mail. (bins carry unsorted mail, as these bins are emptied
         they may be reissued but the type, number, and speed of this
         generation are in no way predicable hence it is irrelevant)
      f. The user will have the ability to override the prediction of mail volume if
         it is incorrect, and specify a new value. (logged in on the intranet)
                1. The system will then log the user id that made the change and
                    recalculate the distribution of equipment for the staging areas.
      g. The user will also have the ability to modify the prediction algorithm if a
         new, more reliable alternative becomes available. (logged in on the
         intranet)
      h. The mail volume prediction engine must be accessible to other
         applications through the API and SOAP interfaces.
VII. Staging Area Organization
      a. The system will make recommendations on the quantity of bins to be
         placed at specific staging areas throughout the facility. The criteria to be
         considered follow:
                1. Machines are mapped to the closest staging area.
                2. Staging areas that are overfilled will move spillover to their
                    nearest sibling.
                3. If present, a staging area simulation model will be used to
                    make any further recommendations.
VIII. RFID Simulation
      a. Assuming all bins and equipment are tagged with RFIDs the system
         should track the movement of these items.
      b. Since the development costs are extraordinary for this module it will be
         stubbed out and replaced with a simulation to determine the cost to
         benefit ratio for such a component.
      c. The RFID system will be treated as an external (stand alone)
         component.
      d. Our application will provide an interface to the rest of the PMRE system
         that the RFID system may use.
      e. The system must track history of tag movement by storing the
         transactions in the database.
                1. Log arrivals at staging areas.
                2. Log departures from staging areas.
      f. PMRE must enforce data consistency and integrity in the event of
         felonious data from the RFID stub.
                1. This will be done through the use of selective database
                    constraints.
IX.   API | Application Program Interface
      a. PMRE will provide a defined API for all developers and external
         applications to interact with PMRE and its components. This API will have
         two key components, listed below:
                1. A documented set of routines that can be dynamically linked for
                    the purposes of invoking PMRE system calls. (This will be a
                    Dynamic Link Library)
               2.  A communications gateway protocol known as SOAP that will
                   allow for RPC, Remote Procedure Calls, on PMRE.
      b. The routines supported by the DLL, Dynamic Link Library are listed in
         the interface section of this document but are subject to change as
         needed.
      c. The list of routines must be prepared and approved by the client during
         the architecture phase of the project.
      d. The SOAP protocol will support the above functionality but in accordance
         with the Standard Simple Object Access Protocol (SOAP) 1.1 published
         by the W3C Note on 08 May 2000
X.    Notifications and Alerts
      a. At the start of each day, all registered users should receive an email
         with the recommended bin distribution for the staging areas along with
         any predictions for mail volume.
      b. At the end of each day, all registered users should receive an email with
         the results for the day (accuracy of predictions).
      c. If the inventory of bins is insufficient to handle the days mail volume the
         system should alert all registered users.
XI.   Use Cases and UI
      a. The UI must follow the USPS color scheme and incorporate their logo.
      b. Responsiveness should be below 3 seconds for any page to draw and
         below 5 seconds for all calculation intensive actions preformed by the
         user.
      c. The web application will consist of three portals.
               1. Admin section that requires authentication (intranet only)
               2. Read-only public section (intranet only)
               3. Read-Only section that requires authentication (internet)
      d. Global Properties
               1. Uniform layout throughout the site.
               2. All pages are rendered with respect to date as represented by a
                   logged in user defined system variable.
                     1. Essentially a user can look ahead to tomorrow or any day
                         in the future and use the system as if it were that day for
                         planning purposes.
                     2. A user can also go back in time to view a read only state
                         of the system’s predictions for that day. (if the data has
                         not be invalidated by changes to the facilities layout)
      e. The Main Page (intranet) will contain
               1. A Read-Only Snapshot of the facility and staging areas
                     1. Snapshot of location states
               2. A Login form for administrators
                     1. Login / Password Form
                     2. ‘Remember Me’ option that will store their login name for
                         later visits to the page.
                     3. Help – Link to documentation
                     4. Lost Password recovery link
               3. Contact Administrator – Email Prompt
      f. The Main Page (internet) will contain
               1. A Login form for users
                     1. Login / Password Form
                     2. ‘‘Remember Me’ option that will store their login name for
                         later visits to the page.
                     3. Help – Link to documentation
                     4. Lost Password recovery link
                2. Contact Administrator – Email Prompt
       g. Read-Only Snapshot of the facility and staging areas will include the
          following.
                1. A list of all staging areas, their location, and current contents.
                2. Mail volume predictions for the day.
                3. Announcements and Outage reports from Administrators.
                4. Internet users that are logged in can also specify an RFID in a
                   form on this page to receive its travel history displayed on
                   screen.
XII.   After logging in on the intranet, users should have the following
       privileges and abilities.
       a. Configure staging areas
                1. A staging area has a fixed location in the facility, capacity and
                   status. They can be either used to support operations or a
                   storage area of excess equipment.
                2. All of these actions will result in a flushing of current to future
                   predictions and recommendations as they will be no longer valid.
                3. Add new staging areas
                4. Remove old staging areas
                5. Modify current staging areas
       b. Configure shifts
                1. A shift is a period of the day when sorting takes place.
                2. All of these actions will result in a flushing of current to future
                   predictions and recommendations as they will be no longer
                   valid.
                3. Add new shift
                4. Remove old shift
                5. Modify current shift
       c. Configure Equipment
                1. Sorting Machines
                     1. All of these actions will result in a flushing of current to
                          future predictions and recommendations as they will be no
                          longer valid.
                     2. Sorting machines can be of varying capacity and location
                          throughout the facility. Each machine has a specific
                          requirement of bins and type of bins used in sorting.
                     3. The status of a sorting machine can also be changed from
                          active, to out of order.
                     4. Add, Remove, Modify machine
                2. Bins
                     1. Bins can be of varying volume. They can also be out to
                          repair, or active.
                     2. Add bin
                     3. Remove bin
                              a. Remove all of a specific type
                              b. Remove bin with a specific RFID
                     4. Modify bin
                     5. RFIDs
                              a. RFIDs are simply a small electronic device that can
                                  be fixed to a piece of equipment for identification
                                  and tracking purposes.
                              b. Add, Remove, Modify RFID
                     3. Bin Types
                          1. There are many possible types of bins varying in
                             dimensions and volume. This category is used to track the
                             different types.
                          2. Add, Remove, Modify
                    4. Status
                          1. Bins and equipment can be in different states: Out for
                             repair, available, out of order.
                          2. Add, Remove, Modify
           d. Predictions
                    1. The user should be able to view all prediction made in the
                        system.
                    2. The user should be able to override all predictions made by
                        entering a new value to use in its place.
                          1. This action will be logged in order to keep a record of such
                             activities.
                    3. Configure Algorithm
                          1. The user must be able to configure the algorithm by
                             adjusting the amount of over prediction used to provide a
                             safety zone.
                          2. See Polymorphic Algorithm Dissertation
                    4. Manage Historical Data
                          1. The user should be able to view past mail volume data.
                          2. The user should be able to enter new mail volume data as
                             it becomes available.
                          3. The user should be able to view past prediction accuracy
                             by having the system compare recorded recommendations
                             with the actual activity measured on a specific day.
           e. Manage Users
                    1. User email addresses must be stored. A maximum of 100
                        characters may be used as an email address.
                    2. Only user’s whose accounts are designated as SUPER
                        ADMINISTRATORS will have the rights to add, remove, and
                        modify user accounts.
     XIII. Documentation
           a. User and Administrator manuals
           b. Installation and maintenance manuals
           c. API Specification (man pages)


8.      Interfaces

Database Interface
The database server should support any standardized SQL query client assuming the
authentication is successful. This will allow applications that require direct access to
the database to have such access. In addition, MySQL allows for table by table
permission so that outside application can have restricted access when accessing the
database.

API :: Application Program Interface
PMRE will have a defined API for use by developers in later iterations of PMRE as well
as other applications that may want to interact with PMRE and its functionality. In the
PMRE API document is a listing of functions supported by the API. More shall be added
as needs are identified.

Scripting Support
Through the use of NU_SOAP or php-scripting users are able to write and execute
custom scripts to add features to the application without modifying the core
components of the program. This provides the user with ultimate flexibility at the end
of the development process.


9.     Architecture

I) Process View

At highest level of abstraction PMRE will have 4 distinctive processes:
     Data Storage and Collection Process
     Analysis and Prediction Process
     Notifications Process
     RFID Tracking Process




                                                              Analysis and
                                                               Prediction
        Data Storage                                            Process
        and Collection
          Process




                                                               Notifications
             RFID Tracking                                       Process
               Process



Data Storage and Collection Process is in actuality a group of smaller processes that
will be described in detail following the high level diagram of the system.
Data Storage and Collection Process communicates with the Analysis and Prediction
Process to obtain predictions of future mail flow based on historical data. Also Data
Storage and Collection Process communicates with the Notifications Process to notify
the users and administrators of important events such as recommended bin
distribution for the staging areas along with any predictions for mail volume, results
for the day including accuracy of predictions, and also some other important alerts.

Both Analysis and Prediction Process and Notification Process will also automatically
execute on a daily basis along with the ability of being spawned on demand by the
user or an administrator.

RFID Tracking Process will track the movement of RFID equipment tags and log
changes to the database through the Data Storage and Collection Process.



Now let’s look at the Data Storage and Collection Process. It will consist of four main
processes:
    Login Process
    Data Collection Process
    Data Transfer Process
    Logging process

                         Data Storage and Collection Process



              Login                                        Data
             Process                                    Collection
                                                         Process




          Data Transfer                               Data Logging
            Process                                     Process




Login Process will be responsible for obtaining and storing user’s login information into
a session cookie.

A Data Collection Process will consist mainly of the user interface pages that will be
used to enter important data into the system. After the data has been inputted into
the form fields and submitted to the server, this process will communicate with the
Data Transfer Process.
Data Transfer Process will be the one actually responsible for connecting to the
database and saving/retrieving the up-to-date data.

Logging Process will be called upon by other processes to store log data into the
database.



II) Logical View

Logical view of the system is based mostly on the functional requirements. For PMRE
the primary functional requirements are:
     To predict future mail flow volume based on historical data
     Manage facility equipment including machines and bins
     Manage users and operating shifts

Hence we can define at least three separate class categories and one class utility.



             Equipment Management




                                                                   Data Services
                Staff Management




            Analysis and Predictions
                           Equipment Management



          Machine                                         Locations
         Management                                      Management
            Class                                           Class




                              Bin Management
                                   Class




Equipment Management Class Category will consist of three classes:
    Machine Management Class
    Locations Management Class
    Bin Management Class

Machine Management Class will be responsible for managing machines. Locations
Management Class will manage staging areas and other equipment locations. Bin
Management Class will take care of all bins and RFID tags that will go along with bins.

                               Staff Management




          User Management                         Shift Management
                Class                                    Class




Staff Management Class Category will consist of two classes:
     User Management Class
     Shift Management Class

User Management class will deal with everything pertaining to the system users and
administrators while the Shift Management Class will be responsible for managing
different shifts.
                            Analysis and Predictions




             Data Analysis
                                                    Predictions Class
                 Class




Analysis and Predictions Class Category will consist of two classes:
    Data Analysis Class
    Predictions Class

Data Analysis Class will be responsible for analyzing data that will later be used by the
Predictions class to generate future mail flow predictions using the available algorithms.

III) Physical View

         USPS INTERNAL NETWORK




             PMRE SERVER
                                                                              Client

                                                       INTERNET
                                                                                        Client




                                                                              Client


                                                                             EXTERNAL CLIENTS




PMRE server will be running Apache 2.0 with PHP 4.3 and MySQL 4.1 database.

Primary users will be internal network terminals. External Clients will have the ability to
only view the data in the PMRE database and will not be able to change it.

Client PC requirements are the following:
     IE 5.0+
       Firefox 1.0+
       Netscape 7+
       OS capable of running any of the above

IV) Development view

PMRE    has three distinct development layers as follows:
        Database Layer
        API Layer
        UI Layer


                                     User Interface
                                 All UI Pages
                                 PHP and HTML



                                       API Layer
                                 PHP functions
                                 Equipment Management
                                 Staff Management
                                 Analysis And Predictions



                                    Database Layer
                                 Database Connection
                                 Simple Data Queries
                                 Data Access Levels



At the early stages of the requirements planning we decided to use the WinWin Cycle
of Risk Management Driven Project Development. Each development iteration the cycle
is repeated with a new risk assessment and requirements review taking place. This
minimizes our overall risk and helps to ensure our client gets the best possible result.


V) Nonfunctional Requirements Specifications

   Performance Budgets
        o Responsiveness should be below 3 seconds for any page to draw and below
           5 seconds for all calculation intensive actions preformed by the user.
        o The application should be able to support a minimum of 10 concurrent users
           and a maximum of 100.
        o The application must be available 99% of the time during business hours
           (9am – 9pm).

   Safety
       o The application must do no harm to surrounding systems in the event of a
           malfunction.
       o Data integrity must be preserved wherever possible in the event of a failure.
     Reliability
          o The application must support simultaneous and redundant shadow copying
              of the production environment.
          o The database server must support replication and transaction recovery.
     Operations and Administration
          o Administrators will be responsible for updates on the server machine and for
              the user administration.
          o End users will not be involved at all in administration.

     Human Interface Metaphor
        o PMRE will employ a web-based user interface.

     Configuration constraints
         o May change without modifying system:
                  Server URL/location
                  All Database user/password information

10. Design Simplifications

I).       Reuse: platforms, COTS, components, tools

Platform
To minimize the about of peripheral code needed PMRE is using a LAMP, Linux Apache MySQL
PHP, based platform. Since all of these components are Open Source, they are hardened against
malicious attacks.


COTS
At the moment, the only COTS PMRE will employ is a C# hardware driver for our RFID reader.

Components
Because the design of PMRE allows for a rich API, code reuse from component to component is
very high but reuse from external applications is almost nonexistent due to the high level of
customization in this system.

Tools
         Zend PHP Studio, a proprietary PHP development tool capable of detecting syntax and
          logical errors in code.
         MS Visual Studio 2005 .NET. a proprietary IDE capable of supporting and developing C#
          applications.
         MySQL EMS, a free MySQL administration tool that allows for remote database
          manipulation from a simplistic UI.



II)       Requirements Interpretation

Based on our interpretation of the requirements we have made the following
assumptions to simplofy this software design product.

         All machines of a specific type have an equal load.
              o This is based on the notion of efficiency and is a key simplification of the
                problem being faced. If one machine is running at full capacity and two
                other machines are sitting idle there is lost productivity. However, if all
                three machines run at a comparable load then we are maximizing
                throughput.
       All staging areas are uniformly spaced.
            o An uneven distribution of staging areas should not occur if the need of a
               particular area requires additional storage the size of the staging area
               should be adjusted. Grouping of physically separate areas into a single
               staging area is also an alternative.
       Machines of similar type or function are either evenly dispersed or grouped.
            o Violation of this assumption would introduce and inherent inefficiency in
               the organization of the facility that would add an order of magnitude to
               the degree of this problem thereby limiting the gains realized by any
               solution.
       There are no barriers sufficiently large in correspondence to the walking
        path such that they alter the efficiency of one path versus another.
            o Based on the map provided by USPS there were no cases where a large
               obstruction significantly altered the efficiency of one walking path versus
               another.
            o The distance between staging areas is sufficiently large such that the
               difference in path chosen is erroneous.
       Staging areas and machines are defined by the client and are not to be
        varied by our algorithm.
            o The client is able to specify the location and size of staging areas. The
               application may not assume these to be variable. The client can change
               these at any time.
            o The client is able to specify the location and capacity of a machine. The
               application may not assume these are variable. The client can change
               these at any time.


III)    Algorithms

The PMRE algorithm for predicting mail volume patterns is described in the Predictive Algorithm
document. The system is dependant on two assumptions for computing simplification:

   The volume ratio between different shifts and different days of the week is not
    affected by what month it is, even though the total volume varies from month to
    month.
   The plant is sufficiently large that shortest path can be considered to be a straight
    line.

The use of Mean Deviation to approximate Standard Deviation has also greatly reduced the
computational complexity and resources needed to complete the calculation of each prediction.



IV)     Re-factoring

Three areas of PMRE have been re-factored: API Code, Component Organization, Security Level
Implementation.
      API Code: After the initial development of the API Code, the code was sent through
       testing and review. In the review process we have discovered some inefficiency in the
       code and will be re-factoring these functions to improve these problems.
      Component Organization: SOAP, and the RFID Tracking Software have been made into
       external applications. They will no longer be in PMRE application space but rather
       independent entities with their own copies of an dependencies. This greatly reduces the
       complexity of any one module as well as the communication channels between them.
      Security Level Implementation: Because of the trivial nature of the multiple security
       level requirement we will only be implementing the to INTRANET grade levels.




11.    Common Use Cases
The most common use cases have been outlined below. They will be modeled in the
prototype.




                 User Logon and Main Menu


                                           / Click Home




                                                           / Click Help
                                                                                Help Page

                       / System Access                    / Incorrect Login
                                         Main Page                             Incorrect Login Page



                                                                    / Correct Login

                                                                                                      Main Access Page
            Equipment Management

                                                                   / Remove A Bin,Add A Bin,Change Bin State


                   / Click Equipment Management                           Equipment Management Page
Main Access Page


                                                                            Inadeqate Permissions Page




                                                   / Click Back To Main Access




                                               Shifts Page

                                                   / Modify Shift Start Time,Add A Shift,Remove A Shift,Modify Shift End Time


                                  / Click Shifts                                  Shifts Page
      Main Access Page


                                                                                   Inadeqate Permissions Page




                                                          / Click Back To Main Access
                             Statistics Page

                                                / Modify Shift Start Time,Add A Shift,Remove A Shift,Modify Shift End Time


                             / Click Shifts                                     Shifts Page
Main Access Page


                                                                                  Inadeqate Permissions Page




                                                        / Click Back To Main Access




                             Bin Types Page


                                                                         / Remove Bin,Add Bin,Modify Type Volume


                                    / Click Bin Types                                  Bin Types Page
          Main Access Page


                                                                                      Inadeqate Permissions Page




                                                             / Click Back To Main Access
                   User Administration Page



                                                                             / Add a User,Remove a User,Set Time


                             / Click User Adminstation                            User Administration Page
         Main Access Page


                                                                                 Inadeqate Permissions Page




                                           / Click Back To Main Access




                               Data Input Page


                                                             / Modify Data Point,Delete Data Point,Input Data Point



                            / Click Data                                       Data Input Page

Main Access Page


                                                                              Inadeqate Permissions Page




                                    / Click Back To Main Access
                                                   Locations Page

                     / Add Location,Modify Location Type,Modify Location Quantity,Modify Location Description,Modify Location Owner,Remove Location




                           / Click Data                                     Locations Page
Main Access Page


                                                                           Inadeqate Permissions Page




                                   / Click Back To Main Access




                   1. User Enters Main Page
                         a. User Logs in Incorrectly
                                 i. With remember me checked
                                ii. With remember me unchecked
                         b. User Clicks Help Link
                         c. User Logs in Correctly
                                 i. With remember me checked
                                ii. With remember me unchecked
                                       1. The user logs out
                                       2. The user enters Equipment Management
                                              a. The user adds a bin
                                              b. The user removes a bin
                                       3. The user enters Statistics
                                              a. The user gets a recommendation
                                              b. The user sets a recommendation
                                              c. The user views the algorithm
                                              d. The user sets the algorithm
                                       4. The user enters Shifts
                                              a. The users adds a shift
                                              b. The user removes a shift
                                              c. The user modifies a shift start time
                                              d. The user modifies a shift end time
                                       5. The user enters Locations
                                              a. The user adds a location
                                              b. The user removes a location
                                              c. The user modifies a location owner
                                              d. The user modifies a location type
                                              e. The user modifies a location quantity
                                              f. The user modifies a location description
                                       6. The user enters Bin Types
                                              a. The user adds a bin type
                              b. The user removes a bin type
                              c. The user modifies by type volume
                        7. The user enters User Administration
                              a. The user adds a user
                              b. The user removes a user
                              c. The user reviews all users
                              d. The user sets time
                        8. The user enters Data
                              a. The user reviews a data point
                              b. The user modifies a data point
                              c. The user deletes a data point
                              d. The user inputs a data point




12.   Feature List and Metrics
            Write the abstract list of features
            ICE-T and Simplified QFD Analysis: See Metrics Document

  I. Home Page (Login Page)
        a. User login area
                 i. User can enter Login ID
                ii. User can enter Password
               iii. User can select ‘Remember Me’
               iv. User can select Enter or Clear
        b. Help options
                 i. Link to help-page with documentation
                         1. Help documents for creating & accessing accounts
                         2. Help documents for administrators
                         3. Help documents for use of application
                ii. Link to lost password option
                         1. User is presented with an email window so that a message to the
                             administrator can be send.
        c. PMRE menu
                 i. PMRE menu displayed on the page
                         1. Link back to home page
                         2. System status (date/time/availability)
                         3. Important messages
        d. Snapshot of facility
                 i. If the user is not logged in
                         1. List of staging areas, locations and current contents.
                         2. Mail volume predictions
                ii. If the user is logged in
                         1. Option to specify RFID
        e. Link for administrator login.
 II. User Application page (After login)
        a. PMRE menu
                 i. PMRE menu displayed on the page
                         1. Link back to home page
                         2. Link to other pages (to be defined at later point)
                         3. System status (date/time/availability/user)
                         4. Important messages
                ii. PMRE menu should be displayed on every page of the PMRE application
        b. Link to configuring staging areas
                 i. Link to add a new staging area
                         1. User can add a new staging area or cancel this task
                ii. Link to remove a staging area
                         1. User can remove a staging area or cancel this task
                iii. Option to select one of the existing staging areas to modify it
                iv. Listing of all of the staging areas available in the system
                         1. Ability to select each of the areas and see its specifications
         c. Link to configuring shifts
                  i. Link to add new shift
                         1. User can add a new shift or cancel this task
                 ii. Link to remove a shift
                         1. User can remove a shift or cancel this task
                iii. Option to select one of the existing shifts to modify it
                iv. List of all of the shifts available in the system
                         1. Ability to select each shift and see its specifications
         d. Link to configuring equipment
                  i. Link to add new machine
                         1. User can add new machine or cancel this task
                 ii. Link to remove a machine
                         1. User can remove a machine or cancel this task
                iii. Option to select one of the existing machines to modify it
                iv. Listing of all of the machines available on the system
                         1. Ability to select each machine and see its specifications
         e. Link to configure bins
                  i. Link to add new bins
                         1. Specify the bin dimensions and volume
                         2. User can add new bin or cancel this task
                 ii. Link to remove bins
                         1. User can remove a bin or cancel this task
                iii. Option to select one of the existing bins to modify it
                iv. Listing of all of the bins available on the system
                         1. Ability to select each bin and see its specifications
                 v. RFIDs
                         1. Link to add RFID
                                  a. User can add a new RFID or cancel this task
                         2. Link to remove RFID
                                  a. User can remove RFID or cancel this task
                         3. Option to select one of the existing RFIDs to modify it
         f. Predictions
                  i. User should be able to view predictions for the sorting facility
                         1. All of the predictions should be displayed with the option to view
                              details for each prediction
                         2. User can select each prediction and a new page should be
                              displayed with the option to make modifications to each
                              prediction.
                                  a. Option to make changes to the algorithm
                 ii. Link to historical data
                         1. User can view past mail volume data
                         2. User can enter new mail volume data
 III. Administrator Application page (After login)
         a. Link to administrative users.
                  i. Add new user to PMRE
                 ii. Remove user from PMRE
                iii. Change setting for a PMRE user
                iv. View/export all users of PMRE
         b. Notification area
                  i. Able to view, modify and generate all information messages for the
                     PMRE system



13.   Deliverables
The project itself will be a web application developed in PHP, HTML, and Java with
MySQL as a backend. Eventually the backend will likely move to Oracle, a seamless
migration, but for ‘cost’ reasons we will be using MySQL.




This project has five key parts, shown in the pyramid above. The focus of our project
will be the underlying prediction system and the corresponding management
components that go with it. The key is to respect the Efficiency Model and RFID tag as
evolutionary requirements. By doing this we can build our current system but still
leave room (an API) for those future components to easily be integrated.

While we will not fully implement either the Efficiency Model or the RFID system at this
time, we will work to plan and document requirements for these items. As our
prediction system comes on line, simulations of these components can prove if their
addition in a later iteration of the product is worthwhile. This approach protects the
client from possible flaws in the ‘ideas’ that would prove costly if caught after the
product went to development.

Implementation Deliverables
1.   A formal database Model – supporting all evolutionary requirements
2.   The needed Data Trend Analysis Algorithms
3.   A mail volume prediction engine
4.   Historical data storage – stored predictions for accuracy analysis
5.   Adaptive Setup – allows application to work at multiple sites (building setups)
6.   A full featured User Interface
7.   Cross platform support
8.   System administration infrastructure
9.   A defined API for later modules – RFIDs & Staging Area Modeler

In future iterations of the product evolutionary items will be implemented as the
necessary information becomes available.
14.     Algorithm

   The volume ratios between different shifts and different days of the week are not
    affected by what month it is, even though the total volume varies from month to
    month.
   The plant is sufficiently large that shortest path can be considered to be a straight
    line.

        One of the most important aspects of this project is the method in which we will
determine the expected number of bins needed on a given day. If our bin prediction is
poor, it will render the system completely useless. This makes our prediction method
crucial to the success of the project. There are several important factors we need to
take into account. First, our requirements specify that our prediction can have no
more than a 10% error at least 95% of the time. Second, we must make sure that we
don’t make underestimates. Any overestimate will result in an excess of bins, while
underestimates result in an unacceptable loss of time while more bins are acquired.
Third, there are four main variables that need to be accounted for: shift, day of week,
month, and holidays.
        To come up with our prediction, we use a combination of these four elements.
We start with specific volume data for a given tour, and a given day of the week.
Below is some sample data we have received from a USPS employee:

Tour 2:
            Monday     Tuesday    Wednesday      Thursday    Friday       Saturday     Sunday
Avg. Vol.   722,354    856,132    1,072,860      1,122,32    1,089,175    629,496      585,872
                                                 1


        When the system is being used, this data will be updated daily so as to stay
accurate. We take the appropriate number, and then adjust it based on a scaling
factor for the given month. Our sample data for different months is listed below:

Month        Average Monthly Volume       Scaling
                                          Factor
January      10,019,814                   100%
February     10,210,831                   102%
March        11,283,784                   113%
April        10,282,164                   103%
May          10,075,287                   101%
June         10,109,505                   101%
July         10,144,810                   101%
August       10,071,899                   101%
September    10,618,426                   106%
October      11,154,692                   111%
November     10,472,973                   105%
December     7,695,277                    77%

      This data is also updated daily. Suppose we need to predict volume for a
Wednesday, shift 2, in December. The equation to calculate the expected average
would be as follows:
(1,072,860 * .77) = 826,102
      At this point, we would make adjustments for holidays, or other unusually high
volume days (such as the first of every month). There will be a table storing these
dates, and the result will be shifted accordingly. However, since these are special
cases, and also since some mail types are not affected much by holidays, we will
ignore this particular aspect for the time being.
      Now we have the average amount of volume that should be expected for this
shift. However, since it is an average, half the time more volume will be received, and
half the time less volume will be received. This is unacceptable. As was stated above,
overestimates are much less problematic than underestimates.
      To solve this problem, we make the assumption that over long periods of time,
volume data is normally distributed. There is no data to suggest that this is an unfair
assumption. We then need to calculate the standard deviation. Once the standard
deviation has been obtained, we can calculate a confidence limit. Our requirements
state that our prediction must be accurate 95% of the time. Therefore, we apply the
calculation below:

Ơ2 = 40,300 (standard deviation)
μ = 826,102 (mean)
α = .05 (confidence level - .05 suggests 95% confidence)
N = 300 (sample size)
Z(α/2) = 1.960 (The “Z” value is a special value that is looked up in a table)

μ ± Z(α/2) Ơ2 / √N

826,102 ± 1.960 * (40,300 / √300)

=830,662

We can say that the true mean is less than 830,662 with 95% confidence. Now if we
add two standard deviations to this number we come up with the number of bins we
should prepare for:

830,662 + (2 * 40,300) = 911,262

        This allows us to state that for the given “worst case” mean, we can say with
95% confidence that less than 951,562 bins will be used.
        Now we have a number for the total number of bins we will need to stock in the
staging areas. The second task is to determine how we will allot these bins to different
stages areas. To do these, we simply allot the bins by the percentage of machines a
given staging area is responsible for. If a machine is responsible for a quarter of the
machines in the plant, then it receives a quarter of the total bins.
        This leads to the question of how we decide which machines each staging area
is responsible for. Each machine is fed by the closest staging area. “Closest” means
the staging area with the shortest overall walking path. Since there could exist
obstacles in the way, we need some algorithm to determine shortest path length.
Algorithms such as the A* algorithm efficiently calculate this. However, this particular
path is sufficiently large that we can assume there are no major obstacles, and the
shortest path to a staging area is a straight line to that staging area. For all practical
purposes, this will be a fair assumption. The task of assigning machines to different
staging areas is now straightforward. Using this method, it is now possible to predict
the number of bins each staging area should be stocked with for each shift of every
day.



15.    Risk Assessment
A design risk assessment is the act of determining potential risks in a design process,
either in a concept design or a detailed design. It provides a broader evaluation of
your design and will enable you to eliminate possible failures and reduce the impact of
potential failures.

1.     At the moment, the lack of experience of some team members with the target
       languages and platform is the greatest threat to the scheduled completion of
       this project.

The risks mentioned above will be used to formulate our implementation strategy and
the goals / deliverables for this project.



16.    Implementation Details

  Platform – The application will be fully cross platform. The only limitation will be
   that the client machine must have a web browser.
 Form Factor - The application will be developed as a web application because of
   the need for the information to be readily available to individuals in multiple
   locations. By utilizing a server side programming platform, PHP, we can maintain
   full control over the software’s environment without the problems associated with
   desktop application deployment.
 Language – HTML will provide the structure and presentation level aspects of the
   application. PHP will be used to add polymorphic attributes to the UI, and handle all
   user based interaction with the database and non-static members of the
   application.
 Database – MySQL 4.1 INNODB will be used in our development but the end
   product will be able to interface to any database server. We will pay close respect
   to the abilities of Oracle 10i and Oracle 10g as we develop and test our code.
 Constraints
        3. The client software should not require any specialized hardware or software
           requirements other then application itself. (not including web browser)
        4. The application must be compatible with MS Internet Explorer 5+, Firefox
           1.0+, and Netscape 5+
a. Integration
           d. PMRE must be able to co-exist with the current way of managing
               equipment.
           e. Deployment will be staggered to mitigate integration and migration
               woes.



17.    Function Point Analysis

Internal Database Files (F):
    o Database: The database holds information users, bin types, loading areas and
       historical data.
   o   This data file is of average complexity and receives a weight of 10.

External Interfaces (N):
   o The application has no external interfaces. An external interface to RFID
       tracking technology is an evolutionary requirement and not considered herein.
   o There are no significant external interfaces (use of open source) – weight 0

Inputs (I):
   o User account administration: A user administrator is able to manipulate account
       data.
   o Local User interaction: A typical user is able to enter historical data, adjust
       shifts, loading areas, and other components of the application.
   o Remove User interaction: A remote user must login and may only view data.
   o These inputs are complex and receive weights of 6.

Outputs (O):
   o Loading Area Recommendation: The application produces a loading area
      recommendation per shift per bin type.
   o This output is simple and receives a weight of 4.

Internal Inquiries (Q):
    o Recommendation calculation: This involves polling many database tables to
       compute the recommended values. The database is not changed in these
       operations, so this is an inquiry.
    o This is a complex inquiry and receives a weight of 6.

Component                Count                Complexity          Product
Inputs                   3                    6                   18
Outputs                  1                    4                   4
Internal Data Files      1                    10                  10
External Interfaces      0                    0                   0
Inquires                 1                    6                   6
Total UFPs                                                        38

Data Communications              5                       SSL communications
Distributed Functions            0                     No distributed processing
Performance                      4             Users should have feel of quick response
Heavily Used Configuration       1                       Simple configuration
Transaction Rate                 4      Built to handle large amounts of simultaneous users
On-line Data Entry               5                      Complex Web Interface
End-User Efficiency              5              Interface must be efficient for user use
Online Update                    2            Some components require online updating
Complex Processing               3                    Recommendation algorithm
                                        Must be maintained for RFID and other evolutionary
Reusability                       5                          requirements
Installation Ease                 5              Must be easy to configure and install
Operational ease                  3           Database backup and recovery important
Multiple Sites                    5           Must perform identically from many sites.
Facilitation of Change            1                      Static historical data
VAF                              48
AFP=UFP(.65+.01*VAF)
AFP=38*(.65+.01*48)= 42.94

PHP is most similar to PERL, for which Quantitative Software Management reports
SLOC/FP of 60.

LOC = 43 * 60 = 2580


                                       Net LOC per Staff Month

                       2500
   Net LOC per Month




                       2000
                       1500
                       1000
                       500
                         0
                              1   10       100     1000   10000 100000 1000000


                                          Size of Program in LOC



Productivity:
2580LOC -> 750 LOC per month
Effort:
2580 / 750 = 3.44 Staff Months

Give a staff of 10 personnel for 5 month, working half time with a fifty percent
reduction in productivity due to added communications costs yields a total of
10*5*(1/4)*(1/2) = 6.25 effective staff months, nearly 2 times the necessary project
staffing. When we factor in the possible overruns and increased likelihood of down
time for students the project is reasonably staffed for success.
18.        sQFD and ICED-T Metrics

This section contains the sQFD, Ease of Implementation vs. Feature Importance, and
ICED-T Metrics for the project at its current point of development.

                                                                                     QFD - House of Quality Matrix




                                                                                                                             ●



                                                                                               ○                                              ●



                                                                         Web User Interphase




                                                                                                                           Database (mySQL)




                                                                                                                                                                                        Internet Application
                                                                                                   Web Administrator
                                                     Priority (weight)




                                                                                                                                                  Language [PHP]
                                                                                                                                                  Programming



                                                                                                                                                                       Web Server
                                                                                                   Interphase                                                                                                            Customer Rating
                                                                                                                                                                                                                   Poor               Good
                                                                                                                                                                                                                   1    2     3    4     5
System makes recommendations on quantity
and location of bins                                    6                   ●                                                ●                        ○                                    ●                                                 √
All users able to view a read-only snapshot of
the facility                                            5                   ○                                                ●                        ●                 ●                                                             √
All users able to view historical read-only
snapshots of the facility                               6                   ○                                                                         ●                                    ●                                                 √
System users are able to log-in and administer
the PMRE system                                         9                   ○                            ●                                                              ●                                                             √
System users are able to configure staging
areas                                                   6                   ○                                                                         ●                                    ●                                      √
System users are able o configure shifts and
equipment                                               7                   ○                            ●                   ●                        ●                                                                                      √
System users are able to generate predictions
for bin use in sorting facility                         5                                                                    ●                        ○                                    ●                                                 √
System users are able to configure system
prediction algorithm                                    5                                                                    ●                        ○                                                                               √
System users are able to view and post mail
volume data.                                            4                   ●                                                ●                        ○                                                                               √
System compares recommendations vs. actual
measured activity.                                      5                                                                    ●                                                                                                                   √

                       Importance                                                              1                       2                      3                    4                5                          6
                        Difficulty                                                             3                       4                      2                    1                5                          6



Priority measured on 1 to 9 scale, 9 being the most important.                                                                                                                                                     ●   Strong Relationship
                                                                                                                                                                                                                   ○   Weak Relationship
                                                                                                                                                                                                                   X   Conflict
                                    Generate
                                    Staging
                                      Area    Administr
                        View Shift Prediction   ating      PMRE     Authentic
 Goals + Features       Predictions    s       PMRE         Help      ation
   Easy to use /
     navigate               5            7           6       5          8
Configuring staging
       areas                7            6          N/A      6         N/A
   Reading Shift
  Prediction Data           7            7          N/A      5         N/A
   User log-in &
  administration           N/A          N/A          8       7          7

Making staging area
 predictions easier          8            6           6       6          5
       Total                27           26          20      29         20

Scale: 1 to 10 (where
     1 is week)




                 Implementation Ease vs. Feature Importance

                                    Generating Administrating Configuring
                                   and Viewing      the       the equipment Facility read-
                                   Predictions users/system      & shifts    only snapshots    Total
Fast user interface                           7             5              5               3           20
Reliable application                          9             5              7               5           26
Correct data generation                       9             3              9               7           28
Availability of the data                      7             7              7               5           26
Totals                                       32            20             28             20

                                   1   Weak
                                   3   Moderate
                                   5   Strong
                                   7   Very Strong
                                   9   Extremely Strong
                                            ICED-T Metric
       ICED-T Model Rating System
(1) Worst I have ever seen
(2) Worst than average
(3) Same as other applications I have used
(4) Better than average
(5) Best I have ever seen
                                                                            ICED-T Rating

                                                Intuitive
   1    The application UI is easy to use                                        4
   2    Modifying Shift / Equipment                                              4
   3    Generating resoults                                                      5

                                              Consistent
   1    Predictions made are consistent from day to day                          3
   2    Administrator can control and modify the users                           5

                                                  Efficient
   1    The time to generate a report                                            4
   2    The overall snapshot of the fecility is available on the home pae        4

                                                 Durable
   1    The application is available from mulitiple locations                    5
   2    Supports multiple users and protects againsts modifications.             4

                                             Thoughtful
   1    The user doesn't need extensive training to use the product              4
   2    Normal user actions and task can be easily performed                     5
19.   Gantt Chart and COCOMO
COCOMO is a model designed by Barry Boehm to give an estimate of the number of
programmer-months it will take to develop a software product.

                          Person Months = E = b*(KLOC) c

   Function Points = AFP=38*(.65+.01*48) = 42.94

   PHP is most similar to PERL, for which Quantitative Software Management reports
   SLOC/FP of 60.

   Total lines of code (TLC) = 43 * 60 = 2580

   We are using a organic model where a = 2.4 and b = 1.05. This project is
   classified in this category because the project itself is not very extensive, however
   it does require that a team people that have various experiences in the languages
   used to develop all aspects of the project.

                    Person Months = 2.4 * (2.58) ^1.05 = 6.49

With 6.49 staff-months of required effort for this project we can estimate that a
student month of work will be about a quarter (1/4) of a normal full time developer
working at least 40hrs a week. With this assumption we equate 1 student month to 4
staff months. Therefore our project will take 25.96 student months.

                         Student Months = 4 * 6.49 = 25.96

Since our team has a total of 10 members using COCOMO we can estimate that this
project will take approximately 2.6 months. We have to however take into
consideration the fact that not all members will do an equal amount of development
which means that the number of moths it will take to complete this project might be a
little higher than 2.59 months, it should however come below the time frame set for
this project.

                          Project Time = 25.96 / 10 = 2.59



20.    Test Plan

Test plan and integration overview
Testing of the PMRE will be done throughout the development and implementation
phase of the project. Testing of individual functions will by done as part of unit testing.
Unit testing will also involve the testing of the UI as well as the database. Integration
testing will cover the implementation of all of the aspects of PMRE and overall
workings of the application. End user testing will be done once a working project can
be presented to end users and once the final project is completed focus groups as well
as end users will take a major part in testing the application.


Test planning (Pass/Fail Criteria)
Software test planning performed prior to software design included the establishment
of acceptance and not passed criteria for all aspects of the PMRE application parts as
well as the overall product itself.
Acceptance criteria
Approved: No major problems identified (major problems are identified below). There
are possibilities of minor problems existing due to problems with the design or
integration with other aspects of the application.
Fix of minor problem will be done with the help of a review by PMRE testing manager
and architect. Based on the recommendations from that review the product will be
resubmitted for changes and improvements.

Not passed criteria
   1. Frequent abnormal program exits through multiple event sequences (e.g.,
       memory limits, bad input).
   2. Non-standard, illogical Windows GUIs.
   3. Non-functioning icons or menu items (e.g., PRINT doesn't work; inactive
       options aren't ghosted).
   4. Installation problems (some typical examples):
           a. Insufficient or incorrect installation procedure.
           b. Application files placed into wrong directories.
           c. Software modifies the configuration or system files without warning or
              backing up originals.
   5. Unit testing of functions producing erroneous output or not generating
       executables.
   6. Application generating faulty data.
           a. Predictions are not accurate
           b. Changes done by the administrator are not reflected in the predictions.

Fix of not passed problems will be done as follows. All problems will be handled by the
developer(s) responsible for that aspect of the application, after the appropriate
changes have been put into place additional rounds of testing will be performed until
accepted criteria outlined above are met.



Testing timeframe
   - Unit testing will occur during development and will test the working of each
      function and function ability of the PMRE application. (December 15 – January
      24)
   - Integration testing will be done after the initial development has been
      concluded and we have all of the functions working and can be integrated with
      the UI
   - End user testing will be done once the interface is working and can be
      navigated by a trained as well as a novice user.
   - Hardware testing of the RFID tracking kit is being done while it is being
      implemented. (December 20 – January 24)


Hardware and Software specifications for testing
All unit testing of functions as well as of the UI has been done on the PMRE server. The
specifications of the server are as follows:
        Server Configuration
        Hardware:
                2 x Intel Xeon 3.0 Ghz HT 1MB L2 Cache 800Mhz FSB
                2 x 512MB DDR2 400 ECC RAM
                250GB SATA-150 NTFS HD
          Software:
                Windows 2003 Advanced Server SP 4
                Apache 2.0 Web Server (port 9000)
                PHP 4.3 Apache Module
                MySQL 4.1 SQL Server
                G6 FTP Server

Testing is performed according to the constraints specified in Architecture Specification
document which outlines that:
   1. The client software should not require any specialized hardware or software
         requirements other then application itself. (not including web browser)
   2. The application must be compatible with MS Internet Explorer 5+, Firefox 1.0+,
        and Netscape 5+

Unit testing
Unit testing was done during development and performed for each function that was
coded. Below is a sample of some of the unit testing preformed, a record of all testing
is available upon request.

Function Name: get_eqInfo($rf_id, $DLINK);
Test Performed:
$result = get_eqInfo(10, $DLINK);

Results:
equ_id type_id status_id rf_id loc_id
    10        1        1 10        1



Function Name: get_eqInfo($rf_id, $DLINK);
Test Performed:
$result = get_eqInfo(“240ASDF”, $DLINK);

Result:
equ_id type_id status_id rf_id      loc_id
    15        1        1 240ASDF        1



Function Name: get_eqInfo($rf_id, $DLINK);
Test Performed:
$result = get_eqInfo(11, $DLINK);
//an rfid not in the system

Result:
returns an empty table


Function Name: add_eq($type_id, $status_id, $rf_id, $location_id, $DLINK)
Test Performed:
add_eq(3, 3, 19, 2);

Result:
equ_id type_id status_id rf_id loc_id
   201       3         3 19        2



Function Name: add_eq($type_id, $status_id, $rf_id, $location_id, $DLINK)
Test Performed:
add_eq(1, 3, "ABC433", 4, $DLINK);

Result:
equ_id type_id status_id rf_id     loc_id
   203       1         3 ABC433         4



Function Name: add_eq(10, 2, 1233123, 3, $DLINK);
Result:
return failure

Function Name: modify_eq($equ_id, $type_id, $status_id, $rf_id, $location_id, $DLINK)
Test Performed: modify_eq(202, 4, -1, 5, -1, $DLINK);

Result:
equ_id type_id status_id rf_id loc_id
   202       4         35          2



Function Name: modify_eq($equ_id, $type_id, $status_id, $rf_id, $location_id, $DLINK)
Test Performed:
modify_eq(300, 4,-1,5,-2,$DLINK);

Result:
return failure

Function Name: remove_eq($equ_id, $DLINK)
Test Performed:
remove_eq(202, $DLINK);

Result:
return success, data was removed

Function Name: remove_eq($equ_id, $DLINK)
Test Performed:
remove_eq(300, $DLINK);
Result:
return success

Comment:
If you attempt to remove an equipment id that does not exist the function will return a
success.

Function Name: get_shiftInfo($shift_id, $DLINK)
Test Performed:
get_shiftInfo(1, $DLINK);

Result:
shift_id      start end    description
            1 NULL NULL Shift 1

Function Name: get_shiftInfo($shift_id, $DLINK);
Test Performed:
get_shiftInfo(10, $DLINK);

Result:
returns an empty table

Function Name: add_shift($start, $end, $description, $DLINK)
Test Performed:
add_shift('12:00','05:00', “shift 5”, $DLINK)

Result:
shift_id        start     end    description
            7 12:00:00 05:00:00 shift 5

Comments:
The format for the start and end attributes of the shift table needs to be changed from
DATE to TIME.

Function Name: add_shift($start, $end, $description, $DLINK)
Test Performed:
add_shift("12:20:00", NULL, "NOTHING", $DLINK);

Result:
shift_id        start     end    description
           10 12:20:00 00:00:00 NOTHING

Comment:
When adding a NULL value for either start time or end time 00:00:00 is displayed instead
of NULL.
Function Name: add_shift($start, $end, $description, $DLINK)
Test Performed:
add_shift("AA:BB:CC", NULL, "SHIFT 12", $DLINK);

Result:
shift_id     start     end       description
       12 00:00:00 00:00:00 SHIFT 12



Function Name: modify_shift($shift_id, $start, $end, $description, $DLINK)
Test Performed:
modify_shift(5, '08:00:00', '12:00:00', 'modifiedshift', $DLINK)

Test Result:
shift_id     start     end       description
           5 08:00:00 12:00:00 modifiedshift

Function Name: modify_shift($shift_id, $start, $end, $description, $DLINK);
Test Performed:
modify_shift(5,-1,-1, "onlydescriptionmodified", $DLINK)

Test Result:
shift_id     start     end       description
           5 08:00:00 12:00:00 onlydescriptionmodified

Function Name: modify_shift($shift_id, $start, $end, $description, $DLINK)
Test Performed:
modify_shift(1, -1, -1, ‘first shift’, $DLINK);

Test Result:
shift_id     start     end       description
           1 00:00:00 00:00:00 first shift

Comments:
When a shift start or end value is NULL, and one of the attributes that is not the start or end
is modified the start and end values are set to 00:00:00

Function Name: remove_shift($shift_id, $DLINK)
Test Performed:
remove_shift(4, $DLINK);

Result:
return success, shift attributes are removed
Function Name: remove_shift($shift_id, $DLINK)
Test Performed:
remove_shift(500, $DLINK);

Result:
return success

Comments:
When you remove an invalid shift, the function returns success.

Function Name: list_shifts($DLINK)
Test Performed:
list_shifts($DLINK);

Result:
shift_id     start     end       description
           1 00:00:00 00:00:00 first shift
           2 NULL      NULL      Shift 2
           3 NULL      NULL      Shift 3
           5 08:00:00 12:00:00 onlydescriptionmodified
           6 08:00:00 12:00:00 modifiedshift
           7 12:00:00 05:00:00 shift 5
           8 00:00:00 00:00:00 ‘NOTHING’
           9 00:00:00 00:00:00 NOTHING
       10 12:20:00 00:00:00 NOTHING
       11 00:00:00 00:00:00 NOTHING
       12 00:00:00 00:00:00 SHIFT 12




Function Name: get_binTypeInfo
Tests performed:
       (If you ran php scripts to test the function put the code of the script here)
                $DLINK = mysql_connect('njnetserv002.no-ip.info', 'usps', '1928A!')
                       or die('Could not connect: ' . mysql_error());
                echo 'Connected successfully', "<br>";
                mysql_select_db('usps_ems') or die('Could not select database');
                $type_id = 1;
                $row = mysql_fetch_array(get_binTypeInfo($type_id, $DLINK));
                echo $row[0], $row[1], $row[2];
                mysql_close($DLINK);
Testing results on specific inputs or scripts. (can be in table format)

                      Input (type_id)                       Output
                             1               1 100 Used to carry small packages
                        3           3 10000 Used to carry large packages
                        6           * No output *


Function Name: add_binType
Tests performed:
       (If you ran php scripts to test the function put the code of the script here)
                $DLINK = mysql_connect('njnetserv002.no-ip.info', 'usps', '1928A!')
                       or die('Could not connect: ' . mysql_error());
                echo 'Connected successfully', "<br>";
                mysql_select_db('usps_ems') or die('Could not select database');
                $volume = 999999;
                $description = “Used to carry very large packages”;
                $add_binType($volume, $description, $DLINK);
                mysql_close($DLINK);
Testing results on specific inputs or scripts. (can be in table format)

           Input(volume, description)                            Output
  999999, “Used to carry very large packages”     New bin type added to the system.



Function Name: modify_binType
Tests performed:
       (If you ran php scripts to test the function put the code of the script here)
                $DLINK = mysql_connect('njnetserv002.no-ip.info', 'usps', '1928A!')
                       or die('Could not connect: ' . mysql_error());
                echo 'Connected successfully', "<br>";
                mysql_select_db('usps_ems') or die('Could not select database');
                $type_id = 1;
                $volume = -1;
                $description = “whatever”;
                modify_binType($type_id, $volume, $description, $DLINK);
                mysql_close($DLINK);
Testing results on specific inputs or scripts. (can be in table format)

       Input(type_id, volume, description)                     Output
     1, -1, “whatever”                         Modifies first bin type, volume does
                                               not change, description changes to
                                               “whatever”

Function Name: delete_binType
Tests performed:
       (If you ran php scripts to test the function put the code of the script here)
               $DLINK = mysql_connect('njnetserv002.no-ip.info', 'usps', '1928A!')
                      or die('Could not connect: ' . mysql_error());
                echo 'Connected successfully', "<br>";
                mysql_select_db('usps_ems') or die('Could not select database');
                $type_id = 5;
                delete_binType($type_id, $DLINK);
                mysql_close($DLINK);
Testing results on specific inputs or scripts. (can be in table format)

                  Input(type_id)                   Output
                 5                   Remove bin type with type id is 5

List any issues that may have come up, including errors and warnings that you were not
able to fix and need to be reviewed by the project architect/manager.
                The database already has 4 type_id, but I can’t delete any of them.
                However, I can only delete those that I can create with add_binType.

Function Name: list_binTypes
Tests performed:
       (If you ran php scripts to test the function put the code of the script here)
                $DLINK = mysql_connect('njnetserv002.no-ip.info', 'usps', '1928A!')
                        or die('Could not connect: ' . mysql_error());
                echo 'Connected successfully', "<br>";
                mysql_select_db('usps_ems') or die('Could not select database');
                list_binTypes($DLINK);
                mysql_close($DLINK);
Testing results on specific inputs or scripts. (can be in table format)

                       Input                          Output
                None                Display all the bin types in the database

Function Name: add_travel_log
Tests performed:
       (If you ran php scripts to test the function put the code of the script here)
                $DLINK = mysql_connect('njnetserv002.no-ip.info', 'usps', '1928A!')
                        or die('Could not connect: ' . mysql_error());
                echo 'Connected successfully', "<br>";
                mysql_select_db('usps_ems') or die('Could not select database');
                $t_date = “2006-01-13”;
                $rf_id = 1;
                $loc_id = 1;
                add_travel_log($t_date, $rf_id, $loc_id, $DLINK);
                mysql_close($DLINK);
Testing results on specific inputs or scripts. (can be in table format)

     Input(t_date, rf_id, loc_id)                         Output
        “2006-01-13”, 1, 1          Add new record to the bin travel log in the database
Function Name: get_travel_log
Tests performed:
       (If you ran php scripts to test the function put the code of the script here)
                $DLINK = mysql_connect('njnetserv002.no-ip.info', 'usps', '1928A!')
                        or die('Could not connect: ' . mysql_error());
                echo 'Connected successfully', "<br>";
                mysql_select_db('usps_ems') or die('Could not select database');
                $rf_id = 1;
                $loc_id = 1;
                $row = mysql_fetch_array(get_travel_log($rf_id, $loc_id, $DLINK));
                echo $row[0], $row[1], $row[2], $row[3];
                mysql_close($DLINK);
Testing results on specific inputs or scripts. (can be in table format)

                    Input(rf_id, loc_id)                 Output
                            1,1               Display the travel log entries
                        -100, -100            * No output *

Function Name: get_rfid_location
Tests performed:
       (If you ran php scripts to test the function put the code of the script here)
                $DLINK = mysql_connect('njnetserv002.no-ip.info', 'usps', '1928A!')
                        or die('Could not connect: ' . mysql_error());
                echo 'Connected successfully', "<br>";
                mysql_select_db('usps_ems') or die('Could not select database');
                $rf_id = 1;
                echo get_rfid_location($rf_id, $DLINK);
                mysql_close($DLINK);
Testing results on specific inputs or scripts. (can be in table format)

                      Input(rf_id)                        Output
                           1                 Display the location of rf_id = 1
                         -100                * No output *


Function Name: get_rfid_history
Tests performed:
       (If you ran php scripts to test the function put the code of the script here)
               $DLINK = mysql_connect('njnetserv002.no-ip.info', 'usps', '1928A!')
                       or die('Could not connect: ' . mysql_error());
               echo 'Connected successfully', "<br>";
               mysql_select_db('usps_ems') or die('Could not select database');
               $rf_id = 1;
               $row = mysql_fetch_array(get_rfid_history($rf_id, $DLINK));
               echo $row[0], $row[1], $row[2], $row[3];
                mysql_close($DLINK);
Testing results on specific inputs or scripts. (can be in table format)

                   Input(rf_id)                             Output
                        1                  Display the location history of rf_id = 1
                      -100                 * No output *



Using the test.php file, and viewing the database via phpMyadmin, I was able to test my
portion of the code development very thoroughly. I started out by testing the Boolean
values of each function, and as they were proven correct, I moved on to view that each
function was individually working correctly.
For the userclass.php class, I first added a user, and checked the database. Then I queried
the users' info via get_userInfo. Then, next I changed the flag, and modified the current
user account. Once all of this was proven successful, I tested to make sure the delete
function removed the entry from the database completely. Furthermore, I moved onto to
the statusclass.php file. I repeated the same steps as listed in the user class testing. One
step at a time I tested all functions, starting with the add, and ending with the remove.

User interface usability testing checklist
At this point in the lifespan of this project the user interface is just starting to be
developed. We have created a home page template for the UI of the PMRE application
and from that template we can foresee what the UI will do and how it will have to be
done. In an effort to make a front end interface that will be uniform and pass receive
high ICED-T ratings we have come up with a checklist of items which have to be
followed for all aspects of UI development.

   1. Uses standard UI features such as dialog boxes, toolbar buttons and pull down
      menus. PMRE UI will follow generally accepted standards for its features and if
      something is created for the UI it will be implemented in a consistent way
      throughout the application.
   2. PMRE windows must have consistent look and feel.
   3. The same home page will appear every time the application is launched.
   4. The navigation flow has to be consistent and logical.
   5. The PMRE copyright disclaimer notice elements for the software have to appear
      on every page.
   6. Error messages and user information notices have to be accurate and useful to
      the user.
   7. Page controls must respond to Microsoft Windows standards (such as hot-keys,
      alt-keys, tab). The use of Tab for example should move the cursor from left to
      right and to the next line. This standard has to be followed on every page for
      consistency.
   8. The data formats have to be consistent throughout application windows.
   9. The interface has to recover from bad input and system errors, with minimal
      disruption to the user.


User interface testing (PMRE Team & End Users)
These questions will be answered by the PMRE team members as well as end users in
testing the user interface which interacts with the database as well as the RFID
tracking kit.
End user testing will be done by both technical as well as non-technical individuals.
The group of non-technical end users will include students from the Biz Tech
department who are also working on their own project with USPS.

Accessibility
   - Is all of the data, as stated in the PMRE Requirements Specification document,
      available through the UI?
   - Is the page content load time acceptable
   - Is the end user able to communicate with the administrator of PMRE?
   - Is help documentation readily available throughout the UI?
   - Are the staging areas, equipment, RFID tracking, algorithm and the database
      all accessible throughout the PMRE UI
Consistency & Navigation
   - Do all of the pages have the same consistency (colors, menus, icons, etc)?
   - Are all of the graphics visually consistent?
   - Is there a convenient, obvious way to maneuver among related pages, and
      between different sections?
   - Is the page visually consistent from day to day, and from visit to visit?
Design & Maintenance
   - Have you encounter any dead/broken links while going from page to page?
   - Are there any functionless forms and/or fields?
   - Is the page length and width appropriate for its content? As well as the viewing
      size of the screen?
   - Are the administrative messages visible and easily accessible through the UI?
Data Access
   - Is the home page snapshot of the sorting facility accurate and up-to-date?
   - Are the PMRE predictions for this shift accurate (checked against available
      historical data)?
   - Are changes to the algorithm reflected in the predictions?
   - Are the administrator and user access rights and restrictions implemented
      throughout the PMRE application?
   - Is the RFID tracking up to date and is it being updated when a tag is checked in

  -
PMRE Page navigation
     Page navigation testing will be done following the Use Cases document. Every
     tester should follow all of the paths shown in the document. Any discrepancies
     or problems in accessing or following the paths outlined should be noted and
     documented.

  - Accepted specifications are stated in the PMRE Requirements Specification
document.
  - Admin rights and user rights are specified in the PMRE Requirements Specification
document.
  - Testing to RFID will require access to the RFID Kit and the back end of the
database.


Database Testing
PMRE database testing was done in parallel with normalization. The database was
normalized to follow the 3rd normal form. We have created a separate table for each
group of data and we have eliminated duplicate columns. We have also remove
subsets of data that apply to multiple rows of a table and place them in separate
tables. All columns that are not dependent on primary keys were also removed.

The database testing is being set for accessing it through the use of a transaction profile for
web based application (PMRE UI) and a deployed application (Apache). A comparison of
data and accuracy for each entry will be compared between the two means of accessing the
database.



Database testing check list:
   1. The field size validation
   2. Check constraints
   3. The field size defined in the application is matching with that in the database
   4. UI predictions and input are reflected in the database. Example: new user
      added, daily prediction generation, RFID in/out scan, etc.
   5. Desktop application predictions and input are reflected in the database and
      match the UI entries.

Hardware testing (RFID Tracking KIT)
Testing of the RFID Tracking KIT involves testing of the hardware itself and
determining how accurate the reader and RFID labels are. With the RFID reader
interfaced with both the database as well as the UI, we can track all of the scans and
determine on a small scale how accurate the tracking will be.

Integration Testing
In integration testing we will test the workings of all aspects of PMRE application. This
testing will include the database, UI interface, RFID Tracking KIT. We will test the
connection and integration among all aspects of the PMRE. We will test the UI
integration with mySQL server and RFID KIT. We will also test the UI and SQL Server
from the back end.



21.    Glossary
API: An API is any interface that enables one program to use facilities provided by
another, whether by calling that program, or by being called by it. At a higher level
still, an API is a set of functionality delivered by a programming system, and as such
the mix of APIs in a particular system tells you what that system can do.

Bin: A container that holds mail parcels. These containers are of varying volume, and
physical dimension. Sorting machines store sorted mail in these bins for transport.

Cross-platform: The ability of an application to work across multiple hardware types
and/or operating systems without the need for recompilation.

Dynamic Link Library: This is a file containing either interpretable source code or
precompiled code for functions associated with an API. The idea is that other
applications can LINK to this file as needed in order to execute code to perform certain
actions associated with a separate component or independent system.

ICED-T: This is a methodology touting Intuitive, Consistent, Efficient, Durable, and
Thoughtful characteristic analysis throughout the development process.

Interface: A well-defined way of communicating and interacting with a system by
system calls or remote system calls. In some cases, like a database server, the
connection client and SQL language are an interface.

Not-For-Profit: This is an organization that is not permitted to net a profit from
operating transactions. The most common example of a not-for-profit organization
would be any charitable foundation.

Override: The user specified numerical value that will be used instead of the
application generated prediction for a specific task.

PMRE: Predictive Monitoring and Reporting Environment. This is the name given to the
system this document outlines. It will be used to predict mail patterns, monitor the
status of the facility and report on recommendations and events throughout the
sorting process.

Predictions: The system generated figure to anticipate the volume of mail (in bins)
based on historical data for a set attributes.

Proof-of-Concept: The idea that a project will be used to test the feasibility of a
concept or specific implementation of an algorithm. This is done to produce a cost or
benefit analysis before committing to a solution.

Recommendation: The system generated figure that suggests to the user the
number of bins and location to stage these bins.

Requirement: A need amount or item. In most cases this refers to the need for a
specific staging area to be supplied with a certain type and quantity of bins.

RFID: A Radio Frequency ID is a small, usually sticker like tag that can be adhered to
an object for the purposes of identification. These devices respond to radio frequencies
which endue a current in their circuitry allowing them to transmit a response.

Soap: This stands for ‘Simple Object Access Protocol’. The idea here is that
communication of HTTP or HTTPS will allow for RPC style system interaction without
the ability to make code level calls. Typically, XML is used as the return format for data
requested via SOAP style interactions.

Staging Area: A staging area is a location where bins can be stored based on the
usage of bins for that given floor area. They have specific dimensions associated with
them.

sQFD: An overall methodology that begins in the design process and attempts to map
the customer-defined expectation and definition of quality into the processes and
parameters that will fulfill them. It integrates customer interviews and market
research techniques with internal cross-functional evaluations of the requirements.
The organization of a facility: This refers to the placement of machines and staging
areas within the physical building. Imagine a grid laid out over the floor plan of the
building. The X and Y values of the location all pieces of equipment would constitute
the organization of the facility.

Travel Time: The amount of time it takes to travel between two points in a building.
For example, the time to walk between a machine and a staging area.

Web Based Application: This is an application that is served from a remote machine,
often over HTTP with the remote machine fulfilling much of the computational
resources.


22.     References
IEEE std. 830, IEEE Standard for Software Requirements and FRDs
       This document contains the standard guide as set forth by the IEEE for the creation of a software
        requirements document and functional requirement document.

IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
       Used to alleviate some of the miscommunications that occur during software requirement planning
        that stem from vague or misconstrued wording.

IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software.
       A guide to quantize the often abstract description of a problem solution in order to produce
        quantitative requirements specifications as opposed to qualitative ones.

IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions.
       This contained key practices in the software design process. Several articles on requirements
        gathering pitfalls proved useful. The most important concept was leveraging what a client says with
        what will work.

IEEE Std 1028-1997, IEEE Standard for Software Reviews.
       This article contained information on how to revisit a ‘DRAFT’ of software requirements to ensure
        the client understands and agrees with the outline of the project within the parameters of any
        assumptions that may have been made about the underlying infrastructure.

IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Planning.
       Standardized ways to translate requirements into a set of points or items to monitor using sQFD
        and ICE-T or similar metrics.

SOAP Version 1.1 Remote Procedure Call Framework
     http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
     This document contains the specifications for the SOAP Remote Procedure Call Communications
      Framework.

Trustworthy Systems Through Quantitative Software Engineering
      This book contains all aspects of the software design process and was used to setup our project’s
       WinWinModel of development. Also helpful was the Wideband Delphi approach to all aspects of
       design.



23.     Change Log

   Revision:        4             Description:
   January 25, 2006               Updated Document -> Development Plan 1
   Anthony Virtuoso
   Revision:        3             Description:
   November 21, 2005              Added Feature List and Use Cases. Updated certain
  Anthony Virtuoso      inconsistencies.
  Revision:        2    Description:
  November 10, 2005     Professor recommendations and Wideband Delphi group
  Anthony Virtuoso      discussion results.
  Revision:        1    Description:
  November 10, 2005     This is the 1st release of the requirements document. It
  Anthony Virtuoso      lacks the ‘use cases’ and initial metrics, both of which will
                        be added in the near future.
  Revision:       0.2   Description:
  November 9, 2005      2nd stage in the 1st release. Building on the previous topics
  Anthony Virtuoso      touched in the group discussion.
  Revision:       0.1   Description:
  November 4, 2005      1st stage in the 1st release. Handing off to the requirements
  Anthony Virtuoso      committee for completion.



22.   Team Composition

Team Mangers
Anthony Virtuoso        Development Manger                   avirtuos@stevens.edu

Paul Ballantyne         Document Manager                     pballant@stevens.edu


Special Agents
Ilya Chalyt             Configuration Manager                ichalyt@stevens.edu
Yuriy Stelmakh          Systems Architect                    ystelmak@stevens.edu
David Byrne             Statistician                         dbyrne@stevens.edu
Jacob Kosinski          Testing Manager                      jkosinsk@stevens.edu


Developers
Vedant Bhanderi         Developer                            vbhander@stevens.edu
ChunWing Lam            Developer                            clam2@stevens.edu
Steve Su                Developer                            psu@stevens.edu
Eric Frey               Developer                            efrey@stevens.edu


EM Contact
Eliot Dahood            Engineering Management               edahood@stevens.edu

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:28
posted:3/29/2013
language:English
pages:52