System Development Environment - Modeling Systems - System Model is high level -> Helps you: Understand, Make decisions,

& Communicate -> A model is a representation of something - Example: ATM Machine (Purpose: to withdraw/deposit money, Components: keypad, card slot, cash box, receipt, cash dispenser, Boundary: between the ATM box/case and the user, Environment: users bank, Interface: menu, touch screen, key pad, bank network, Constraints: plug, size, U.S. currency, no coins, Input: money, ATM card, check, Output: money, receipt) - Purpose: The overall goal or function. Components: An irreducible part or aggregation of parts that makes up a system; also called a subsystem. Boundary: The line that marks the inside and outside of a system and that sets off the system from its environment. Environment: Everything external to a system that interacts with the system. Interface: Point of contact where a system meets its environment or where subsystems meet each other. Constraints: A limit to what a system can accomplish. Input: Inserted or enter into a system and which activate/modify a process. Output: Exit a system and which activate/modify a process o SDLC (Systems Development Life Cycle) - Basic concept: Gather information and think first, then plan, then do. o Phase 1: Systems Planning and Selection, Phase 2: Systems Analysis , Phase 3: Systems Design, Phase 4: Systems Implementation and Operation Managing Your Work Environment - Time Management - Multi-tasking, Step 1: WANT to be more efficient. - Human Behavior: Teamwork - Making teams work, its challenging, but thats how business is conducted, you dont always get to work with people you like, learn to be productive anyway - Set Ground Rules & use them: monitor/adjust your own behavior, basis of discussion with teammates who arent following them -> Use written to-do list (project plan): Assigned tasks and due dates, keep track: check in before things are due, help each other -> Tips: Do something social with your team, Procrastinate at your peril, Deal with problems promptly and directly - Meetings - What are your pet peeves? (clashing personalities, cancellations especially last minute, no agenda, no purpose, not following agenda/off topic discussions, people late, people multi-tasking Determining System Requirements - User Requirements - Determining Requirements: You must investigate and understand the current system, possibilities for the new system, & the operating environment - Current system -> Tells you what business functions are needed, data requirements, user expectations and mindset -> You find out by interviews (individual or group), Reviewing documentation, Map the current process (as is maps). Possibilities for the new system -> Looking at the old/current system wont tell you everything -> Possibilities opened by using technology: Old technology, new uses; New technology -> Possibilities opened by changing procedures. Operating Environment -> System must work in (ex: physical environment, type of users, e.g., the public or trained staff, Availability of IT support, Budget constraints, not only to build the system, but to operate it (Learn this through interview and observation) Use Cases - Structuring System Requirements: Use Cases - Use Cases -> Representing the goal of interactions with the system -> Key ideas: event-driven model-some event triggers system action, Consider all possible system actions in response to the trigger event, Represent the Use Case with a diagram and Use Case descriptions - Building Use Case -> Identify the users: Who will interact with the system (Can be people, other systems, organizations) Why they interact (goal) -> Use case diagrams (Identify and depict the goals of user interactions with the system) -> Use case descriptions (Represent user tasks) - Use Case Diagram (Fig. A-2. P. 364 Its a top level use case diagram) Actors are anything outside the system that interacts with the system. Actors could be people, other systems, devices, etc. - How is Use Case Diagram similar / different from a System Model? - Use Case Descriptions -> Describe exactly what happens when an Actor interacts with the system. (ex on D2L) - How does a Use Case Description relate to the Use Case Diagram? To flowcharts? Data Flow Diagrams & Decision Tables - Structuring System Requirements: Data Flow Diagrams & Logic Models - Process Modeling -> Data Flow Diagram (Model the processes: how data moves through an organization) Logic Modeling (Decision tables to represent process logic) - Data Flow Diagrams -> For the system you are modeling, show Stationary Data (Data sources/sink external, Data stores internal) Processes that transform data -> Know your boundaries & current purpose (Stay focused on the system you are building, Stay focused on the level of detail and aspect of the system you are currently working on (Layered diagrams More detail as you dig deeper, Built by successive refinement (iteration))) - Context level is the highest level. You get one process box, labeled 0, that is the entire system you are modeling (Fig 6-4, p. 158) - Level-0 is the next level from the context diagram. Show major processes, data flows and data stores (Fig 6-5, p. 159) - Logic Modeling -> Use Decision Table to lay out all the possible actions and the conditions that determine them -> Useful for complicated situations (Ex. Exercise 12 p.182, procedure p.173-174) Choosing a Strategy - System Acquisition Strategies -> What approach will you take to meet the system requirements -> Acquire (usually buy or rent) Packaged software or complete system (ERP), SaaS (Software as a Service/Cloud Computing) -> Build Hire someone to do it, Do it yourself - System Acquisition: Factors in Deciding -> User Requirements Does a system exist that does (most of) what is needed? (Include all required aspects of requirements: feature/function, performance, reliability, etc.) -> How will support and maintenance be handled? -> Total Cost of Ownership Designing the Human Interface - Focus on how people interact with systems -> Many ways to interact Forms/reports (online or paper) Dialogue/Navigation Help (System analysts develop specs, models, or a prototype to pass on to the implementer or, for packages and services, you both design AND implement) - Use your analysis -> User Requirements Features/functions Know your users -> Use Cases Describe general interaction between users and the system > Data Flow Diagram What information has to be transferred (Then dig deeper: purpose, audience, etc. for specific form, dialog) - Guidelines (Tables 8-1, 8-2, etc.) -> Help the user Avoid mistakes Fix it easily if they do make a mistake Know where they are and what is required Achieve their goal -> Design for your medium Projected, big display, small display, printed, etc. - Form Design Systems Implementation & Operation - Getting the system up and running -> Coding (or configuring), Testing, Installing (For all these, use your analysis & design documents as the basis) - Testing -> Testing occurs throughout the SDLC -> Goal is always to find problems early Create test plan, Create test cases, Select/create test data, Execute test cases, Fix problems, Retest - Support & Maintenance -> How these are handled can make the difference between success and failure! -> Using the system -> Reporting problems Bugs: the system doesnt work as planned The system works as planned, but users arent satisfied -> Handling enhancement requests (Consider documentation, training, ongoing support & maintenance)

- Hoosier Burger (Fig. 4-13; p. 101, p.24-25)