Download
1 / 6
60 likes | 167 Views
CS 111 – Dec. 3. Lab recap Problem solving approach for systems analysts 8 phases Just understand the flow/process/sequence of the steps, not specifically how many there are or what they are called. Important to understand the order of the steps is not arbitrary.
E N D
CS 111 – Dec. 3 • Lab recap • Problem solving approach for systems analysts • 8 phases • Just understand the flow/process/sequence of the steps, not specifically how many there are or what they are called. Important to understand the order of the steps is not arbitrary. • Similar to problem solving approach for small programs we would do in this class • Much more emphasis on pre-design aspects • The overall technique can be applied in other areas like planning a vacation. • Commitment • Review PIECES framework to prepare for in-class activity.
Approach • Survey phase • Define the scope, budget, staff, schedule Scope: Is this a quick fix … or major overhaul? • Is the project worth our time & money? • Look over PIECES framework for ideas. • Should be done in 2-3 days. • Study phase • Okay, let’s do the project. What are the relevant business issues? (Technical issues come later) • How beneficial will it be to do it? How much time/money should we invest? • List all the objectives you hope to accomplish. • Understand the problem – are the objectives specific enough? • External deadline?
Approach (2) • Definition phase • Critically important. At end of this phase, the definition document is like a contract that should not change. • What are the business requirements for a solution? • Need to know specific requirements for: data, geography, interface, process • Build a prototype, and get it approved before continuing. • Configuration phase • Evaluate possible solution strategies. Look at various options. • Should we outsource; how much should we do ourselves? • For each candidate solution, find out, for example: • Can we afford it? • Will it actually work? • Can we get it done on time?
Approach (3) • Procurement phase • What should we buy? • Do we need new or different kind of equipment, software? • Get proposals from vendors; negotiate. • Note there are fixed + variable costs. • Design phase • Tell how to solve the problem in technical terms. This is like step 2 from our original procedure. • Decide in what order the components need to be implemented. • Come up with an evaluation (testing) plan so that you’ll know the implementation matches the design.
Approach (4) • Construction phase • Implement and test the solution, or an interim benchmark if it’s a long-term project • Test the individual components in isolation; test entire system when ready. • Most work is done by programmers, overseen by project managers, etc. • Caution: many “testers” are entry-level workers and may need extra help/supervision. • Delivery phase • Install the HW and SW • Train people on the new system • Put it into daily use. • Put together a plan for regular support and maintenance.
Activity • Next time: Let’s divide into 3 groups. • Each group will address an aspect of a problem • Let’s examine Furman’s class registration system • 3 tasks (1 per group) • Critically examine and evaluate the current system of pre-registration and drop/add. Do you like it? Does it work? How could it be improved? Cover all aspects such as technology, I/O, ease of performing tasks, performance, red tape. • What are the requirements of a good class registration system? • How should the Web interface be designed? What feedback and information should be available to users online?
