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?