This action might not be possible to undo. Are you sure you want to continue?
Wesley Williams, Devon M. Simmonds Department of Computer Science University of North Carolina Wilmington
terminal for taking orders and a terminal for generating reports and managing changes to employee records. Abstract Teaching software engineering at the undergraduate level is an exciting and challenging undertaking. Students come to software engineering with a variety of technical and sift skills which have to be strengthened, honed and channeled to produce desirable results. This paper reports on the development of a restaurant management system as part of a first course in software engineering. Results and lessons learned are presented. 1. Introduction At the undergraduate level, software engineering is taught as both one-semester and two-semester course sequences. In either format, teams of students create software with a level of complexity commensurate with the course sequence format. A familiar strategy to aid the teaching and learning process is to have students develop software in application domains to which can relate or are familiar. Restaurant management is one such domain. In the experience of the authors, some restaurant management software while having reasonable utility features geared towards tracking money and profits, seem to have a significant lack where intuitiveness and usability are concerned. Some restaurant management software has weak or non-existent security, and in some cases, functionality needed for day to day operations are only available to managers. This results in the undesirable situation where access to manager-level functions are granted to lower-level employees. These problems may have resulted from the designer’s lack of domain knowledge, or from a lack of user involvement in the design process. This paper reports on the design of a restaurant management software created as a team project in an undergraduate software engineering course. The overall goal of the project was to create an application where both utility and usability are addressed. In particular, the software should be easy to navigate and use while providing basic restaurant management and security features. In addition, the software should grant each employee a level of access that is commensurate with the duties and responsibilities required in performing duties. When deployed, the application will serve as a single working “point of management” system that acts as both a 2. Project Plan The main focus of the project was to create a single working “point of management” restaurant system that acts as both a terminal for taking orders and a terminal for generating reports and making changes to employees or items on the menu. Project planning was done to define the scope of the project, assess risks, and estimate and schedule project activities and thereby lay the foundation for the execution, monitoring and control of the project.
Sign In Access Database Employee Manage Order
Generate Report Manager
Figure 1: Use Case Diagram 2.1. Project Scope 2.2. The overall scope of the software is reflected in the use case diagram shown in Figure 1. Major software functions of the restaurant management system include managing orders, inventory, and employee records, and generating reports. Order management includes creating and deleting orders, adding and removing items from an order and closing orders. Orders should also be stored in the database to be
This risk has a higher probability of occurring during the first weeks of the semester and diminishes as the semester progresses. For example. with implementation and testing consuming slightly more time than design. and deleted from the menu item database. As such. all the members were given opportunity to modify and perfect artifacts and tasks assigned to other team members. In addition.3.used to calculate total sales. All employees must be able to clock in and clock out. deleting products and updating products and resources. Managers should be able to do what all employees do and be able to edit item and employee information and generate reports. Orders should also be stored in the database to be used to calculate total sales. tasks were assigned to members of the development team as shown in Table 2. The result is shown in Figure 3. Hardware breaking down 4 2 10 Task takes longer than expected 3 3 2 Table 1: Risk Assessment Restaurant Management Project Project Management Requirements System Design Implement ation Testing/ Deployment Monitor Progress Analyze Functional Requirements User Interface Estimate Resources Asses Risks Analyze nonfunctional requirement s Database Work Breakdown Structure (The First 2 Layers) Evaluate Results Figure 2: Work Breakdown Structure . However. Risk Losing a project member Prob. The other two risks are more likely to occur and may occur at any time. To achieve these goals the project should make menus effortlessly navigable and group user interface (UI) components in a manner that makes them easy to find. The first of these risks is that of losing a member of the development team. Servers must be able to do what all employees do as well as take orders. The software is responsible for a number of other functions. soft copies of all documents were stored by all members of the development team to mitigate against loss of project artifacts. The non-functional requirements of the project included creating an intuitive. testing and software design were the major project tasks. and remove employees from the employee database. Make sure every team member has updated copies of work done by all team members. Risk Plan Table 1 shows three risks that were identified for the project. Menu items must be added. 2 Impact 9 Priority 10 Actions Make sure every team member has updated copies of work done by all team members. Our software must be able to add employees. it was the opinion of the development team that giving each employee the appropriate level of access to resources was imperative for usability and security. The first two layers of the WBS is shown in Figure 2.4. risk prevention strategies were developed and enacted. Based on the WBS. Inventory management includes adding new products. simple application that performs consistently. A schedule of tasks for the project was developed. For a complete look at desired functionality see page six. The table identifies the persons who had primary responsibility for the development of a specific artifact or the management of a project task. Project Estimates and Schedule Estimates for time and resources were calculated based on a developed work breakdown structure (WBS) for the project. 2. 2. Items that can be ordered must be able to be added and removed from an order. edited. Reports that should be generated include sales reports showing sales by food category and the total sales from the start of the day. The chart shows that implementation. edit their information. Trey will be free for helping other members once the initial setup of the database is complete.
in our experience.9].2w 6. The architecture of software defines the major software subsystems and the dependencies and interrelationships among subsystems [1. the design of the software included both architectural and subsystem design.2w 1. For this project. each software development team was required to design the software using two architectural. The architectural styles chosen by the restaurant management team were the three-tiered layered architectural style and the shared-repository style.2w 2. Management was partially done via electronic means such as email and phone calls since many of the members have different and often conflicting schedules. In this course.4.6.2w 3. Examples of well known architectural styles include pipe-and-filter.4w 3.7. X X X X X X Inventory X X X X X X X X X X X X CheckIn-CheckOut Database Orders Employees Items Figure 4: Shared Repository Architecture .4w 7w 1.8w 2. Most had experience programming in JAVA and . Architectural styles define a vocabulary for different classes of architectures [5. Software Design While it is acknowledged that design is not always rational  and while we do not expect any silver bullet .2w Figure 3: Schedule of Activities 3.4w 3.NET and most team members had a good grasp on the problem domain as many of them had worked in the restaurant industry at some point in their lives. The project manager scheduled one meeting per week for face-to-face communication and to verify the project status gain consensus and review completed individual tasks. shared repository and event driven.2.10].The project team was compromised of a group of individuals with diverse programming and technical backgrounds. software design becomes better with practice and experience. Task Project Planning Resource List Work Breakdown Structure Resource Estimation GANTT Chart PERT Chart Responsibility Matrix Risk Plan Control Mechanisms Requirements Analysis Use Case Design Activity Diagrams Class Model Requirements Dictionary Limitations Non-functional requirements Software Design Accept Payment Taking Orders Modify Orders Canceling Orders Sales Reports Labor Report Inventory Report Implementation Database Check In/Out System Sales System Reporting System Software Configuration Herbert Kyle X X X X X X X X Jacob Wesley Table 2: Responsibility Matrix ID 1 2 3 4 5 6 7 8 9 10 Task Name Group Formation and Project Selection Report Due Requirements Engineering Report Due Create Use Cases and Models Software Design Report Due Create Program Database Prototyping Implement Sales Implement Manager Functions Testing Software Implementation and Testing Report Due Start 1/7/2009 1/16/2009 2/9/2009 2/9/2009 3/2/2009 3/5/2009 3/16/2009 3/16/2009 4/6/2009 3/16/2009 Finish 1/15/2009 2/9/2009 3/3/2009 3/27/2009 3/9/2009 3/24/2009 3/30/2009 3/23/2009 4/27/2009 4/27/2009 Duration 1.
Options that appear grayed out are not available for the user that has logged in. The design shows five major subsystems interacting with a shared data store. The user interface design in Figure 8 is the JAVA Swing equivalent of the earlier design. we have added the clock functionality to every screen in the program so that no matter which screen an employee is viewing. In addition. User Interface Employees CheckIn-CheckOut Inventory Orders Items Employees Database Management Items Orders Figure 5: Layered 3-Tier Architecture 1. User Interface Design Because of the nature of our project. it constraints the evolution of the data base as well as the data formats on the individual subsystems.* DatabaseManagement Inventory MainSystem 1 1 Clock Figure 8: First user screen The next screen (Figure 9) is where the employee can choose which tasks he or she wants to do. There are a few alterations that had to be made. Managers have all options..* Employe SignIn 1 Order Item * 1 1 * 1 OrderManagement 1 1. Below are three screenshots that show this (Figures 10. he or she will be able to keep track of time. A layered architecture is shown in Figure 5. The functionality that was originally on this particular screen has been moved to subsequent menus and screens.1. servers have all options except the management button. All orders that are currently “owned” by this particular employee are listed in the list above the “add” and “edit” buttons. Figure 7: Edit item Sequence Diagram 3. an intuitive graphical user interface was required. While this design is ideal for data driven applications that share a common database schema. and finally normal employee are only granted access to system to log in and log out. Figure 6: Class Diagram Login Menu Management Menu Edit Item Menu Item Database Login() loop [Done=false] SelectItemAndHitEditbutton() alt [Choice=cancel] Cancel() [Choice=enter] EnterChangesAndPressOK() OK() Done() ..The shared repository architectural style is shown in Figure 4. 11. & 12). On the first screen visible to the user we have removed all buttons except the sign in button. The buttons on the far right side on each screen have been removed and put onto a single menu accessible after login.
The figure below is the ordering screen. Figure 10: Ordering menu .Figure 9: Employee Task Menu Figure 11: Edit Item Menu Management menu functions include the ability to add and remove employees as well as items. When the screen is exited. entrée. report generation would be completed from the management menu. pressing the add button below the list adds the item to a fifth list which is the actual customer order. the information is stored in the database. appetizer. Although our group did not implement report generation. When the item is selected. Figure 12: Item Type Selection The ordering screen allows a server or manager to create an order by selecting from four lists that represent the four types of food: beverage. or dessert. Below are screenshots of the management menu and the various submenus for editing employees and items. All the screens are periodically updated with the current contents of the database.
Devon.35. the intended results. and usability.35.35. John. Hernan.68. Rather. 21. 1245) Intended result Employee(1 .12. Specifically these test cases make certain that employee and items are stored and retrieved from the database correctly. 3245) Add new employee (0. Usability testing. Another issue that cropped up was knowledge of the Java programming language.45. 12.55. 3245) MANAGER Employee(2. 1245) SERVER 7 Shatner. 378) Add new employee(0. Scheduling project meetings around individual group member’s schedules creates many difficulties.3. however. 54. 5. Test cases were also generated to perform boundary testing on how many entries could be successfully added or updated.35. Due to the time constraints of the project we were unable to perform any formal usability testing using persons external to the development team.55. John. 23.68. 12. Dan. 234) NORMAL Error 4 5 Error 6 Error Error . The table of test cases listed on the following page shows what kinds of tests were performed on the “add new employee” function. Dan.68. Reliability and security testing was accommodated by constructing test cases and comparing expected and actual results. 1245) SERVER Employee(3 . 13. 21. 14. Cortez. -1532) Add new employee(0. coordinating activities and tracking continuous improvement and overall success. One way to address this problem for institutions with only one software engineering undergraduate course is to introduce architectural concepts in the programming courses that precede software engineering. Test cases were created to test adding. design rationality evolves as designers gain greater visibility into the artifact being designed and greater experience.John. Smith. Dan. Simmonds. and the actual results. which is Java’s primary user interface package The team identified the responsibility matrix as the management construct most useful for managing the project. Simmonds. 5.55. Hugh. and editing both items and employees. 27. deleting. 23. 14. which is used to validate input. 234) Add new employee(0. Implementation takes an extraordinary amount of time and a large amount of coordination. 54. Hernan. 378) NORMAL Error Actual result Employee(1. 14. At least two of the four group members were unfamiliar with Java’s Swing API. As Parnas has noted . In addition. 546) Add new employee(0. Test Planning Three goals were identified for the test plan: reliability. This is especially true of novice designers who have little grasp of core design principles. 45. 21.2. Students reported that their biggest challenge was time constraints. 10) Error Employee(0.35. 45. Devon. 10) Table 3: Sample Test Cases 4. Simmonds. Usability testing would require some domain experts to use the software and perhaps even deploy the software in a restaurant environment. Rather. 3245) MANAGER Employee(2 . Devon. Employee(3.12. 2 3 Add new employee (0. Discussion and Lessons Learned Students had some difficulty translating the architectures into design. A second approach would be to introduce architectures very early in the software engineering course using problems and solutions from the earlier courses. Both the former and the latter problem may be more of an issue in the academic environment where priorities of the different group members are skewed in a variety of directions. Test Case # 1 Description Add new employee (0. Smith. 12. Rather. 378) NORMAL Employee(0. and everyone was held accountable for the completion of their assigned tasks. Laurie. All team members were assigned tasks. The responsibility matrix also allowed the team to track tasks that need to be done. Cortez. is completely different. test cases where created to verify the function of the compare class. security. William. Many of the group members were unable to devote the amount of focus that the implementation stage required.35. Smith.
91-101. 7. Bass.cs. On the criteria to be used in decomposing systems into modules. D. CA.1145/361598. Mary. IEEE Computer Society. Shaw. 1996. 6. 8. Grady. 0018-9162 . D.l.org. Architectual Blueprints -. p. IEEE SOftware 12. Software Architecture: a Roadmap. ACM. L.pdf] Pittsburgh. s. : Prentice-Hall Inc. Parnas. 42-50. : Addison-Wesley. 2. 12. PA : Carnegie Mellon University. IEEE Press 1986. 2001. Los Alamitos. Garlan.. Philippe. CMU-CS-94-166. Parnas and P C Clements. Jr. IEEE . 2006.References 1. L. Garlan. USA : IEEE Computer Society Press . Garlan. 10531058.” IEEE Transactions on Software Engineering. Software Architecture in Practice (Second Edition).edu/afs/cs/project/vit/ftp/pdf/intro_so ftarch. ACM. Mary. pp. 4.uncwil. s. 1987. Brooks. 5. 3. “A rational design process: how and why to fake it.l. : Commun. Booch. David. 15.The "4+1" View Model of Software Architecture. Clements. 1994. Dec 1972.acm. [http://www. 2000. M. David and Shaw.edu/10. The Coming-of-Age of Software Architecture Research.361 623]. .cmu. Kruchten. On Architecture. 656664. 12(2):251-257. Len. Software Architecture Perspective on an Emerging Dicipline. 9. No Silver Bullet Essence and Accidents of Software Engineering. An Introduction to Software Architecture.l. Vol. [DOI= http://0doi. 10. s. 1995. 2008. Rick. pp.coast.. Frederick P. Paul and Kazman. Shaw.uncclc.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.