Com S 362 --- Object-Oriented Analysis and Design HOMEWORK 1: TEAM PROJECT VISION STATEMENT (File $Date: 2002/01/10 21:52:01 $) Due: by Jan. 23, 2002 at 11AM 20 points This homework is to get you started on the team project, which you will be doing this semester. In this project, you will describe what you want to do for your project in a "vision statement". In essence, this can be as simple as a paragraph describing what you want to do in your team's project this semester. But it may be worthwhile look at Larman's book (Applying UML and Patterns, 2nd ed.) sections 7.4-7.5 to see more about vision statements. You might, for example like to use the format shown in section 7.4 or at the top of page 94. But feel free to adapt the format as you see fit. Also, as part of your vision statement, be sure to list the names and email addresses of all the people in your team WHAT TO HAND IN As in all homeworks this semester, you will hand in two things. 1. The first is the vision statement and the list of names and email addresses , which is to be sent to the course staff (cs362s at cs.iastate.edu) by email before class on the due date. 2. The second is the course's "Certification of Individual Contribution and Understanding Form". You can find this form in 3 formats from the course web pages at the URI: http://www.cs.iastate.edu/~cs362/docs/ or on the department machines in the directory /home/course/cs362/public/docs/ The certification form must be printed and signed, you cannot turn that in by email. In the future we may neglect to mention the certification form, but you must do it for each homework anyway. MORE DETAIL ON THE PROJECTS You can decide to do a project of your own choosing. We have some suggested ideas below, but those are merely suggestions. Be creative! The project you select must satisfy various constraints, as described below. However, you do not need to know exactly how long, or how much effort it will take to build what you envision; we don't expect you to have enough information to estimate that yet, and the process we will use will try to take that into account. Also, it's okay if you haven't worked out all of what it is you want to build; indeed for this course, it's better if some of the requirements are unclear, provided that you can get feedback to clarify them by building small versions of the system. (See Larman's book, chapter 2 for more about iterative development.) Indeed the constraints we want to impose are all about keeping the project from being too well understood and too small! Constraints Our constraints are the following. Let's call the system you are proposing "the system" in what follows. 1. That the system not already be implemented as a computer program. In particular, you should not have access to a the design of the system, a working version of the system or source code that implements the system. (If you did, you could use the existing system to tell you what all the requirements are, or you could use the implementation as your project.) 2. That the system not just produce one output, but that its users engage in a series of interactions to accomplish various tasks. (If the system just produces one report, say, then object-oriented methods are probably not appropriate for its design.) 3. That there be some degree of change in the systems requirements or usage in the foreseeable future. If the system interacts heavily with humans this is almost guaranteed, but there may also be a lot of change due to changing technology. (If there is no likelihood of change, then again object-oriented methods are probably not appropriate for its design.) 4. Someone in your group should either have first-hand knowledge of what such a system should do. This person will be necessary to decide questions about usability and other questions about the requirements. 5. The system should not have real-time requirements. That is, there should not be deadlines after which system responses are invalid. (Such systems are orders of magnitude more difficult to implement than other systems.) 6. The system should not be safety critical, in that its implementation should not involve the potential to injure or kill humans. For example, Microsoft Word would not be appropriate as a system, because it violates constraint 1. The NextGen POS system described in Larmans's textbook also violates constraint 1. A program to sort existing records would violate constraints 2 and 3. A program to explore theoretical physics would violate constraint 4 unless one of your team members is a theoretical physicist. A program to do air traffic control would violate constraints 5 and 6. It's okay to have a database involved as part of the system, but don't implement a database management system (or an operating system or a compiler) as part of your project. We have other courses that explore those topics. If you have a project with a database system, someone in your group should know how to interface with them, or at least be interested in learning about it. (Our TA knows how to do this and can help.) It's okay to have concurrency and synchronization involved in the system, although this would make the implementation more complex. If necessary, you can implement a version of the system that artificially limits the concurrency (e.g., which only has one user). Sample ideas Here are some sample ideas for team projects. You don't have to use one of these. Also, don't worry if other teams are using the same idea. - An interactive game to play Monopoly. - A robotic control system for printed circuit board chip stuffing (i.e., a factory control system) - An airline (bus, train, ...) reservation system - An inventory system for a warehouse - A system to configure and manage vending machines (set prices, track inventory, etc.) - Delinquency collections (i.e., a system to help get money from people behind in paying their bills) If you are stuck for ideas, talk about what job experiences, hobbies, or interests you have, and see what could be automated that relates to them. Going on Once you have decided on your project idea, if you have time, try to think about what the system should do. This will be good preparation for the course's unit on requirements analysis. However, writing down the detailed requirements (e.g., use cases) is *not* part of this homework. You are just to write a vision of what the system will be like, and why it should be built.