Overall Evaluation

Part A: The Design Process

Part B: Evaluation of the Test Plan

Part C: The Management Structure

Part D: The Project Summary

Part E: The Demo Script

Part A:The Design Process

1.What we set out to do:

The general goal of this development project was to implement a system that would simplify some of the major operations of a supermarket, specifically the stores of the Collective Supermarket Owners. This consisted mainly of operations that had to do with inventory. In addition to this, the system would also be able to handle the functions of keeping track of employees. The CSO Inventory System was designed to incorporate all these functions along with a strict security system. The design of the system was divided into two major parts. First there were the databases that were needed to store all information necessary to keep track of inventory and employees. Second was the design of a user friendly graphical interface.

The databases that were needed would be the inventory database and the employee database. For the inventory database, it was necessary to keep track of the current stock and also the amount that was on order. Along with this, each record in the database would also contain a unique item code, bar code, price, description, location, department, and the minimum stock number that has to be in stock at all times. The minimum stock number was used here to allow the system to automatically put an item on the order list when the current stock of the item reaches this number. The second database needed was the employee data- base. Each record in this would contain the usual information such as the name of the employee, the department of work, and the position of the job. For the security of the system, the records also contained a unique employee number, an authorization level, and a unique password. These fields allowed the system to prevent unauthorized access to the system. In addition to these two databases, there was a need to also have a database to keep track of all changes to the databases, especially the inventory. This was designed to be implemented using an audit file. Each entry in the file would contain a record of transactions that had been performed using the system. This was one of the ways to keep the system more secure.

The design of the user interface was developed as an MS-Windows interface. This made it easier to train employees to use the system because of the user friendly environment. Each job had its own window that would be setup for that specific job. For the managers, a more functional window would be displayed with the functions necessary to keep the store running normally. It would contain a choice of the primary functions of a manager. These functions were determined to be: keeping track of inventory, managing employee records, accessing the other job windows, and accessing the archive database. For security reasons, only the head manager would have access to the archive database, while the department managers would only have access to the information in their departments. The other jobs required a different interface, since each job had a specific duty. For the cashiers, they would only be able to access the cashier window. This window consists of the functions necessary for everyday operations of a cashier, such as making a sale and giving a refund. For the stockers, their window would consist of the functions to check on the arrival of orders and to change the inventory when needed. All these windows however, would not be accessed until going through a login process. This security measure will protect the system and the store from damage.

A separate interface was also developed for the warehouse. This was to be a simple system that had only a few specific functions. It consisted of a way to receive orders, print a lading form, receive confirmation, and to print an invoice for a received shipment. We had assumed that the orders would be received by a physical order form, and that all transactions between the stores and the warehouse were in paper form. However, we had explained that in the future we would be able to implement an electronic system where paper is not needed.

The whole CSO Inventory System was a software package designed for the use of the Collective Supermarket Owners chain of stores and its warehouse. Many of the features that were specified had been designed into the system along with many other features. Some of the important features covered in the system was a user friendly environment, management of employee records, automatic inventory management, and security measures. These security measures consisted of record keeping of all changes to inventory, record keeping of system usage, and the use of the system based on the employee's position. All of these features had been planned to be incorporated into the overall CSO Inventory System.

2.What We Achieved:

Our CSO Inventory System will provide all the necessary functionality for a grocery store. The system will allow the management to select the security access level for each employee from a set of defined choices.

The CSO Inventory System has a login/logout process and a freeze terminal function that are performed by every user of the system. Then each type of employees has their own set of functions. Only those functions that have been assigned to that employee can be used by that particular employee. The other functions will be greyed out and not accessible.

We have implemented two main functions for the cashiers to use. One is the sales function and the other is a refund function. There are some sub-functions in the sales function: deleting an inputted item and printing the receipt. The manager can assign either one or both of these functions to a cashier.

We have implemented a function for the stockers which allows them to enter the order number. After this number is entered, all of the information for the order will be displayed. The primary duty of the stocker is to check the correct number of items received, so if the number of items received is different from the order form, the stocker can then change the amount received. This updated information will be saved in the database.

There are two main sections for the manager which include personnel and inventory. In the personnel section, there are functions for the manager to select, create, and delete a department. There is also a function to view all of the employees in a particular department. Furthermore, there are functions which allow the manager to view, change, delete, or add the employee's information. The employee information includes first name, last name , ID, login, and password. There is a function in this section to assign different security access levels to the employee.

In the inventory section, the manager can make changes or inspect the inventory. The inventory window provides functions to add, change and delete items from the CSO Inventory System. The head manager has access to a function to change between departments or to see the inventory for the entire grocery store. The manager can also view, change and add items' information (e.g. item name, product code, barcode, price, amount, amount on hand, amount on order, minimum/maximum in stock and the location of the item). There are functions that allow the manager to view, create, authorize, add items to and delete items from an order form.

The CSO Inventory System has the ability to open multiple Employee Duty Menus. We have also implemented an audit file which will record all the transactions of the system.

We have also implemented some functions for the warehouse to receive order forms from the CSO Inventory System.

3.Reason for the Differences:

Basically, we have met everything in the origin specification from the customer group except for the security issue. In the beginning we just allowed one security level for each specific job, e.g. cashiers only have access to the sales function. Then we changed this so that the everyone except the head manager would have certain functions assigned to them by the head manager. For example, a cashier can have access to the sales and refund functions, or is just allowed access to the sales function but not the refund function. As another example, a manager can have all functions of a head manager or all functions but the order function, or access to all functions except the change employee records function.

The reason for these differences is due to the fact that our interpretation of the customer's specifications was different from the customer's. However, our representatives have spoken to the customer group and we have come to some compromises, and this issue was resolved.

B Evaluation of the Test Plan

Management:

The management plan for testing was complete and sensible. A commitment to that plan would have led to a high quality version for demo to the customer and final product approval. However, management did not involve itself with the programming team and the programming team implemented the test plan itself. A few items of consideration: the implementation of SourceSafe did not occur, as this Software was not within the resource base of the programming team, and the testing team leader did perform final acceptance testing and the demo of the product as specified. The product was tentatively approved as it satisfied customers specifications and expectations.

Three Stages:

The three stages of program testing were completed as implementation of the project turned out the different modules. The test plan for the particular modules did test the basic functionality, but did not cover the full range of issues with each module. In one instance, the test plan was in conflict with the specifications and implementation requirements of the project. Overall the three stages were a useful developement tool, but did not lend themselves to stamping the modules as complete in every case.

Personel Window and Login Interface

The first stage of testing was performed upon completion of the interfaces and the addition of functionality behind them. The Personel window performed everything required, but concerns were raised over the stability of the interface. That is, incorrect dialog with the could lead to unwanted data base manipulation and data integrity break downs. The login window passed the tests without issue.

Inventory Window Interface

This interface was implemented by a member of the programming team and then submitted upon completion to the core members of the team. The team then performed the required testing and discovered different areas of concern. The interface manipulated the data base as required successfully and with integrity, but the window itself did not display or communicate certain cases, such as a department with no products attached to it or the deletion of the last product in the list. These issues were immediatly dealt with by a member of the programming team core.

Stockers and Sales Interfaces

These two interfaces were implemented and tested accordingly. Orders created via the batch order system or manually created in the inventory window could be accessed and all tests required for the Stockers window performed and passed. The Sales interface also passed all given test without issue or concerns, product stock level changes could be verified in the inventory window, and were found to be correct. Exceptions to this were the tracking of bill numbers, as the specificatons from the customer did not require each bill to be stored as a data entity, test specified to test the existence of the bill number were not performed. However, the refund option was tested by product number or name with either manual entry or scroll bar access.

Integration Testing

The integration test plan really followed as a development plan as well. The integration plan was designed to ensure the itegration of a module would fit in seamlessly with existing modules in an order such that different data entities needed by later modules were already managed by previous modules. The integration plan was therefore intrumental in the development of the project and was followed to the letter. All modules did integrate and pass the required test. However, in the creation of modules and individual programmer testing, data integrity was corrupted in the data base as a result of a bad run. This occasional event interfered with integration testing as data entities needed to be complete and correct for the system to run. The core program team acknoledged this and decided on using the Access platform underneath the Visual Basic they were using, as Access would provide data integration monitoring, although the final product would not need this support as it itself would not allow the corruption of data itegrity.

Functional Testing

Functional test plan seemed to be an iteration of the three stages gone through earlier. This was accepted however, and the testing was performed on the demo version. With confidence that the tests would be satisfied, we proceeded, only to discover that we had lost source code for a module within the project. The core programming team surmised this as a lack of procedure for backing up data and our failure to aquire SourceSafe and implement it. After much laughter it was pointed out that we should not be finding humour in the situation, and a member of the core programing team proceeded to re-program the module. Upon completion, the functional testing was completed, and regression tests were repeated from integration testing specifications. These tests were passed.

Performance Testing

The resources needed for most performance tests were not available to us, notibly a local area network. However the performance tests that relied largely on a heavy data load such as the ordering and the stockers window were executed as scaled down versions on a single workstation. Performance testing was unproductive, as it gave us no new results or insight. However, we believe that given the resources needed, the performance test would have been meaningful.

Acceptance Testing

The programming team engineered the system to satisfy the state of the system required. The test team leader then executed the acceptance testing. The creation of new Employees, Departments and Products are essential, and the system dealt with this as expected. The core of the system of course is product Sales and generating Orders, which also worked flawlessly. Modification of existing data also performed admirably, without loss of integrity. Fianlly the security of the system was found to be complete and intact. The acceptance test plan was thourough as to test the entire system and to ensure customer satifaction with the product. It was with dismay that the demo version executable system, was not the executable that made its way to the demo, leading to a somewhat poor presentation of the system, although the customers did acknowledge that outside of the defficiancies of whatever version was at work, we met their specifications and requirements.

C Management Structure

Our original goal in developing a management structure was to increase the productivity of the group as a whole. We realized that some people had different skills and qualities than other people, and we thought it best to use these to determine each person's optimal position in the structure. In the beginning, it was difficult to know what each person possessed in the order of skills, and abilities, so we used our good judgment, and organized our group as best as possible.

1.Initial Management Structure

The initial management structure for 10th Level solutions was decided in quite an adhoc manner. After the first week of meetings we came to an agreement that Zach would be the leader, and for each of the projects, the leader was responsible for setting, and enforcing internal deadlines, as well as assigning positions of assistant management to various group members. The assistant managers were responsible for the organization of individual groups assigned to do a single task, and to correspond with the leader. This was done in an attempt to make the organization of the whole group more manageable for the leader. Also, for each of the projects a flow of organization was determined, in order to ensure that the documentation would be done in time for the editors to edit the document, and forward this to the HTML consultants, who would then publish the documentation on the Web. This structure worked for the most part, other than the odd expected flaw.

2.The Evolution of the Management Structure

Some may say that half way through this project, the management structure took a turn for the worst. When looked at carefully we thought it actually took a turn for the best. Although the original leader was eager, and personable, he did not possess the management skills equivalent of the newly emerging leader, Gabriele. It was the organizational skills, combined with the drive, and determination of the new leader that convinced Zach that the best solution for the group would be for him to step aside, and allow the new leader to take over. Unfortunately it took some time for this new arrangement to become comfortable for the group. Gabriele was much more of a dedicated manager, and thus was on top of everything so to speak. This made the projects go more smoothly. Gabriele also used assistant managers to organize some of the smaller groups, which as a whole is an excellent way to know what events are taking place in these groups.

D Project Summary

1. CUSTOMER / SUPPLIER INTERACTION:

To meet the needs of the customers, the quality and quantity of interaction between the software designers and the customers is critical. Inadequate or insufficient interaction between the customers and suppliers can lead to the production of software that fails to meet its objectives. Furthermore, poor customer / supplier interaction can result in unhappy customers. Dissatisfied customers may refuse to sign the contract, or worse yet, refuse to pay the full price of the product on delivery.

An ideal relationship, on the other hand, can result in the successful completion of a project, on time - on budget. Proper communication will help the software designers to accurately gather customer specifications early in the process, assist in the evolution of the system as the product is developed, and ensure that the final product meets the customers expectations. However, maintaining quality communication throughout the design process is not simple task. The software designers, being the suppliers in this business relationship are accountable for the quality of this interaction.

  • Ensuring Constant Communication:

    Throughout the design process, the supplier must maintain constant communication with the customer to maintain customer confidence, to ensure customer needs are being satisfied, and to help find missing components of the product as early as possible. For the production of the CSO Inventory System communication was satisfied through the use of several different mediums.

    The use of the use of the world wide web provided a convenient method of exchanging documentation at all stages of the process. In particular, the "web" provided easy access for members of both groups to up-to-date information. By keeping track of the state of the project, each member of the design team could verify the relevance of their current work and adjust the direction of their assignments accordingly. Furthermore, customer input was always relevant to the stage and condition of the system.

    Although the "web" provided a common pool of information and a standard for the exchange of documentation, further communication methods were necessary to solve misunderstandings and to address critical issues. For simple issues E-mail memorandums between the two groups proved to be adequate. For more critical issues, namely the issue of security, meetings were arranged to resolve the problems since memorandums complicated the issue and often created further misunderstanding. These meetings involved only a few members of each group dedicated to solving the problem. From the viewpoint of the suppliers, it was extremely important to prepare for these meetings. Customers attending these meetings had extremely strong viewpoints, there own ideas as to exactly how security should be implemented. Although some members of the supplier group argued that it was unrealistic to have customers with a sophisticated knowledge of programming, it was, indeed, quite realistic to deal with customers with strong - preconceived notions.

  • Keeping the Customer Involved:

    As recommended early in the course, the best way to encourage a positive customer / supplier relationship is to keep the customers involved in the project. During the earlier stages of the development of the CSO Inventory system the customers repeated many of the same complaints. From the Customers point of view the suppliers were failing to address these concerns. Yet 10th Level Solutions had dedicated a great deal of effort trying to meet the needs of their customers.

    To convince the CSO that their concerns were being addressed, the specially arranged customer / supplier meetings focused on the recurring issues such as security. While these meetings were being conducted, the remaining members of the design team were considering how the system might have to change to accommodate any possible compromises. However, the compromises reached during the special meetings did not always resolve the issues. Many of these issues were brought up again. Perhaps the most important result obtained through these meetings was achieved by providing the customer some evidence that the supplier was involving them in the evolution of the product at every stage of the design process.

  • When the Customer Doesn't Really Know What Will Serve Them Best:

    When conflicting issues arise between the customer and supplier, the supplier must proceed with the development of the project and tactfully confront the customer with fixed solutions to the problem. Too much time can be wasted by negotiating deadlocked issues, the successful completion of the project can be put at risk. However, the exact route to proceed in such situations cannot be suggested by a simple formula. One solution might be for the supplier to continue to produce the software according to what they believe is best. This runs the risk of damaging a positive relationship. Another solution might be to provide the customer the product that they want, even if it is not the best solution. Although this option minimises the possibility of the final product being rejected, it may compromise the suppliers desire to produce the best quality. If circumstances were ideal, both models could be prototyped, but this can not be done for each and every issue that causes conflict.

    During the production of the CSO Inventory System, a number of issues left the customer and supplier in disagreement. For the example mentioned earlier concerning security, the software designers halted production of the software to leave enough time to negotiate a compromise. The terms of this negotiation were critical to the whole structure of the proposed inventory system. Although 10th Level Solutions might have been more productive by continuing software production according to an assumed compromise, the time taken to negotiate the problem proved to be fundamental in developing a better customer relationship.

  • Obtaining Customer Satisfaction: Customer satisfaction is possibly the most important part of the business relationship, yet it is often completely skipped during the production of software. By dedicating a reasonable amount of effort to promote the final product, the supplier can determine possible problems with the system to minimise the cost of future maintenance. This interaction can also permit the customer an opportunity to bring out issues that they were not addressed adequately. By directly consulting the customer for satisfaction the supplier expresses that they are actually interested in customer input.

    For the development of the CSO inventory system the two project presentations provided 10th Level Solutions the opportunity to consult the customers for satisfaction. The first presentation brought to light the significance of certain issues to the customers. Prior to the presentation the design team were unaware as to the significance of the issue of security.

    2. HOW USEFUL THE DESIGN PROCESS WAS:

  • The Informal System Requirements / The Functional Specification and Management Plan:

    The initial stage of the design process involved assessing the customers informal system requirements. Although it is argued that there was not enough time for the customers to determine what they want from the system, the effect of time constraints in this course created a rather realistic set of informal system requirements. The requirements were, indeed, informal in nature.

    Although the initial set of system requirements contained a reasonable amount of detail, there was not a great deal of cohesion in the customers requests. With hindsight, there were details mentioned that proved to be more important than first realised. However, not only was the design team required to present their initial concepts of the CSO Inventory System, but they had to develop team structure to tackle the project.

  • The Customers Response to The Functional Specification Document:

    What the design team initially interpreted from the informal requirements proved to be quite different from what the customer was really asking. The next few stages of the design process needed to bring about significant changes from the initial concept of the system. For this project the customers indicated several ways the system failed to meet their initial requirements. At this point it became evident that the customer had developed more as a team and were able to more clearly specify their requirements.

  • The Overall Design Document:

    At this point in the design process the general structure of the system was beginning to develop, though the exact technologies were not certain. The system structure was presented using high level data flow diagrams, entity relationship diagrams, and proposing the general concepts of the system interface.

  • Customer Response To The Overall Design Document:

    This stage of the project gave the customer the greatest opportunity to comment on the direction of the project. A number of missing requirements were noted and a number of improvements were suggested. However, the most significant lesson learned from the customer comments was the fact that customer / supplier communication had to be improved urgently. Although several meetings ironed out critical issues at this point already, the customers were still able to conclude that 10th level solutions was eliminating one of the sub systems of the CSO Inventory System, a direct violation of the initial system specifications. A communication breakdown was declared by the design team, and immediate action was taken to correct the misunderstanding.

  • The Detailed Design Document: / Initial System Presentation:

    There was nowhere near enough time to fully exercise the advantages of this stage of the design process. More time for comprehensive presentations may have found problems with the system early enough to save work in the final coding of the product. For purposes of this course, however, the value of exchanging ideas between customer and supplier as early as possible was clearly demonstrated.

  • The User Manual:

    Constructing the user manual at the same time the system is being coded is one way of checking that the usability and functionality of the system as early as possible. One drawback was noted by the design team, however. While the user manual documentation team was suggesting one proposed method of using the system, the system designers were implementing something quite different. Even such simple inconsistencies as describing the clicking of a CLEAR button in the user manual when the button was actually called NEW, caused confusion for the customer.

  • Customer Response to the User Manual:

    Though inconsistencies between the user manual and the system caused some confusion for the customer, a number of important problems were discovered from this process. For example, a customer reminded the design team that it would be necessary to include the amount ordered in the listbox for the stockerUs window to make the stockerUs job more efficient.

  • Final Presentation/ / Evaluations:

    The final stages of competing the production of a software product were accelerated drastically for this course. It must be noted here that the software development process should be more iterative than the process exercised in this course. The Inventory System developed by the supplier group was only just beginning to look like a reasonable product before the course came to a halt.

  • In conclusion:

    Although the realism of the whole software design process in this course was arguably lacking, the process provided a reasonable learning situation for coping with team project dynamics, a sample of the customer / supplier relationship, and a small experience in the iterative process of software design.

    3. Lessons learned from this Project

    a) Problems encountered and possible Solutions

    Throughout the life of this project our team encountered numerous problems that arose primarily due to not recognizing the amount of work this project needed, and due to the organizational and managerial inadequacies. This section lists most of the problems we had to face, and proposes possible solutions for future projects.

    One of our biggest problems came from the lack of communication between subgroups (such as the documentation team and the Manager, or the documentation team and the coding team). During meetings or even at random gatherings the content of this project was discussed, many times to extreme lengths. However, the communication broke down on a short term or emergency basis. For example, if the project leader needed to get a hold of all members in the group, email was usually sent. If a response was needed within 24 hours or less a response always came either only partially or not at all. Team members did not read their email on a frequent basis to ensure that all news or notices were properly received and attended to. It is vital that any email should be responded to, so that the sender can make a decision accordingly. Furthermore, it is important that all members read their mail at least once a day, or leave a number where he/she can be reached in case it is needed. Peer communication must also be maintained at a constant rate. It is important that the documentation team knows how the coding team follows the design specs, while the coding team needs to know what must be implemented in the system. The lack of peer communication only resulted in inconsistencies and misunderstandings, which is best avoided.

    Proper managerial division was another big problem in our group. We basically split up the team in the following way: one project leader, two editors, one html formatter, and the remaining people first into functional and interface teams, and later into documentation and coding teams. This breakdown in itself is not a bad one, as tasks were well defined in this way. However, within each subgroup there was no further hierarchy, i.e.. no group leader, no secretary etc. This lead to confusion and wasting time during subgroup meetings and complete group meetings. Many times several people tried to take the floor at once, or a discussion was held longer than necessary because the group could not decide on which action to follow. A strong group leader, accepted by all within the group or subgroup, could have controlled outbursts or lengthy discussions, and could have made the final decision on an issue. Thus it is not only important that a firm hierarchy exists, but that members within the group follow this hierarchy and accept final decisions made by the leader.

    A group can only follow their leader if this person is respected, trusted, and dedicated to the job. Our group had a problem with this as well. We moved to fast in deciding who our group leader should be, not checking on whether he had enough time for this enormous task, whether he understood his responsibilities to the full extent, or whether he felt he was up to that much more work. Before any breakdown within the group occurs a discussion should be held on each position that needs to be assigned. Each member must be aware of all responsibilities, and then make an honest statement as to which position is suitable for that person or not. After that a preliminary discussion can be made, and a trial period should reveal if the choices made were ok or not. Do not hesitate to change the internal structure of the team as the quality of work depends on it.

    A minor problem were deadlines of subsections of the project. Deadlines must be assigned internally, and team members must adhere to them. Our group experienced documents that were missing whole sections or small parts due to the lack of enforcing the assigned deadline. Furthermore, the team should agree upon one document format before writing even one line of text. A predefined format eliminates inconsistencies in layout, something the customer group will harp on, if not avoided right away.

    b) Time Constraints

    The time allotted for this project is too short. A group of roughly twelve people cannot be expected to produce quality work in the current time frame given. The reasons are as follows. Each student within a group has at least three or four other courses, or works full time. The amount of documentation that had to be produced in an almost overnight fashion caused many students to study less in other courses. Thus the marks of students in other courses suffered in various degrees. The short time frame caused our group to rush the work we had to get done. Virtually no time was allotted to determine the best internal structure of the group, as we had to rush to get the first document produced by the deadline. All team members feel that the quality of their work was substandard to their norm, as little time was given to properly discuss and decide on the content and the design of the project. Documents had to be written on the fly, while editing was often just a quick glance at the final document before it went on the web.

    A solution to this dilemma would be to either extend the course to two semester, leaving the same work load, or reduce the project size to fit the current time frame. A third solution would be to eliminate the customer groups within the class while bringing in outsiders who "play" the customer during the time of the project.

    c) Differences between the Class Project and a Real Life Project

    There is no doubt that a real life project of the same size would have a longer time frame allotted for the work. A company must avoid rush jobs, as it would only produce a faulty, substandard system that the customer could not use.

    Team members of a real life project have no other worries, most of the time, than the current project. A company would have their individual groups which each took care of a project or a problem.

    Managers have to do nothing but manage and supervise. They are not obliged to write documentation or even code. They just have to worry about meeting deadlines and standards asked for. The breakdown of a team in a real life project is far better determined, laid out, and carried out. People know their responsibilities and can rely on other team member to get their parts done.

    A team in real life does not have to be a customer group at the same time while worrying about the successful completion of the projects. Customers come to them from another company or industry. In short a real life team has one focus only: the project. Thus it can produce a quality product and not just a half finished simulation.

    4. KNOWN SYSTEM BUGS (OPPORTUNITIES)

    10th Level Solutions would like to thank the members of the Collective Supermarket Owners for their valuable input into the design of the CSO Inventory System. Due to the cooperative effort between our two organisations we are discovering the system bugs (or OPPORTUNITIES for computer professionals) early on in the project. The following list of system OPPORTUNITIES are currently under investigation as a result of the presentation of the product on March 26, 1996 in Science Theatre 141.

    1) A missing column in the Stocker Window should show the amount initially placed on order by the grocery store to make the StockerUs duties more efficient.

    2) Take care of values in the product list under current number on stock

    3) Unexpected system crash when trying to place a special order

    4) Unable to add new items to the product database under certain circumstances (during the presentation the product RFancyS was not added to the system database)

    5) Warehouse system must be demonstrated as soon as possible to provide opportunity for customer input

    6) Duplicate names in the Personel window prevent Managers from editing the employeeUs details

    Should members of the Collective Supermarket Owners find additional OPPORTUNITIES, or wish other concerns to be addressed, please contact 10th Level Solutions as soon as possible.

    The Demo Script

    1) Log in as different people 
        - show failed login, security measures
        - change password, show working after login again
        - show different priorities of logging in (between different 
          security levels)
        - logout


2) Log in as Head Manager 
       a) goto personnel
        - change department, show different employees
        - create new dept in the store
        - add new employee to new department (cashier)
        - show error on security level if not selected while create/modify
        - change security level, show its updated
                - use pcamb in health foods,
                  log out, log back in again.
        - delete an employee
        - use cashier created to log back in with
          and show cashier functions.

       b) goto inventory
        - bring up order       
        - show different depts
        - add item to order
        - delete item from order
        - add new item
        - modify item information
        - delete an item


3) Login as Bill, Department Manager [bswaney]
        - goto personnel, show dept restrictions
        
       a) go into cashier
        - make grocery bill
        - explain choosing by name & code
        - explain 'Hot Key' [F6]
        - show how refund works
        - shoe how delete works
        - show before/after refund and delete
        - show finished button
        - show freeze terminal
        - delete from order
        - select finish 


4) Login as stocker [jsmith]
        - select an order
        - confirm an order
        - change amount that arrived


5) Login to Inventory window (as Head Manager)
        - bring up an order previously made
        - show different departments of store
        - add items to an order
        - illustrate different amounts of additons

    Go to the Customer's Reaction.