1. Systems Development I—Overview Ken PeffersUNLVMarch 2004

2. Responsibility of systems analysts and designers Technical quality of IS –timeliness –efficiency –accuracy Impact on the organization –effect on organizational conflict –effect on decision making

3. Responsibility of systems analysts and designers User interface –allows user to interact with system Process of design and implementation

4. Who is involved? Senior managers –strategic direction –funding –support/leadership Professionals –legal –procurement

5. Who is involved? Middle managers –access to people –support for analysis –Management control over the project team Supervisory –Process information –Decision making detail Workers –task detail

6. The management of development Corporate strategic planning group –Responsible for achievement of broad corporate objectives IT steering committee –Reviews and approves plans for IT projects, consistent with strategic plans Project team –Responsible for implementing system

7. The project team Systems analysts Functional analysts Application programmers DB specialists Communications specialists

8. The project team Also... Legal Behavioral Trainers Plant and Equipment Procurement

9. Steps in the SDLC Method Feasibility Study –Output: Project Proposal Systems Analysis –Output: Requirements Specifications Systems Design –Output: Coding, database, communications specifications, documentation, procedures

10. Steps in the SDLC Method Acceptance Testing –Output: testing documentation Conversion –Output: working production system Post implementation audit –Output: audit report

11. Waterfall Method System Request FeasibilityStudy Project Proposal SystemsAnalysis Requirements Document Design Coding, database, communications specifications, documentation, procedures Conversion Testing Working System Testing Documentation PostImplementationAudit Audit Report The SDLC is also called the Waterfall Method Why? Every stage has a definite output. Why? What is a sign off? Why is it done?

12. Feasibility study Problem definition –The nature of the problem –Scope –Objectives

13. Feasibility study Evaluation of feasibility –Technical—Can it be done? –Implementation—Can we do it? –Economic—Is it worth the cost? –Financial—Can we manage the cost? –Strategic—Is it what we should be doing? –Operational—Is it desirable within managerial/organizational framework?

14. Project Proposal Output from feasibility study Project overview Problem definition Findings, expected benefits, recommendations Costs, schedules, personnel

15. Systems Analysis Objectives Define Project Objectives Identify operation and problems of existing system Identify requirements and objectives of new system identify requirements for organizational change

16. Analysis Data gathering—what is done, how, data flows –documents –observation –questionnaires –interviews

17. Analysis Information Requirements Determination –Polling—assumes managers know –Data analysis of files, reports, etc... –Prototyping—develop requirements from system use –Object systems analysis from conceptual model Cost benefit analysis

18. Analysis-Data Data modeling--ER diagrams Activity modeling—Data flow diagrams –How data flows through the organization Flowcharts –Show the flow of decisions and actions through a process.

19. Flowchart an activity 1.The sales clerk inputs sales transaction data on a (POS) terminal. 2.The POS processor looks up the item prices from a locally held on- line inventory price file and prints a sales receipt. 3.The POS processor sends the transaction data over data communication lines to the central computer. Example from http://www.tld.jcu.edu.au/course/co1801/flowchart/examples/exam2.html

20. Flowchart example Example from http://www.tld.jcu.edu.au/course/co1801/flowchart/examples/exam2.html 2 1 3

21. Data Flow Diagram—University Registration

22. Data Flow Diagram Example — University Registration Next Level Example from http://www.umsl.edu/~sauter/analysis/dfd/dfd.htm

23. Data Flow Diagram—Process #4 Explosion

24. Entity Relationship Diagram Part of an entity relationship diagram to show the ordering of products from suppliers

25. Analysis—requirements Define inputs and outputs Define processing—functionally Storyboarding –Screen and reports –Consider every user action and consequence

26. Requirements document Project overview Problem definition Requirements Benefits Description of current system Cost, schedules, personnel

27. The Skills Required By Systems Analysts Interpersonal skills Communication skills Presentation skills Analytical and problem solving skills Business knowledge Technical skills

28. Systems Design Devise detailed system solution Deliver functions required by users Manage implementation

29. Systems Design Preliminary –Conceptual design—logical –Physical design—Specifications for hardware/software

30. Systems Design Detailed Design –Outputs –Inputs –Processing –Database –Procedures –Controls Role of users in design –Design should reflect business objectives, not biases of professionals

31. Acceptance Testing program testing system testing user testing auditor should check test documentation planning / test data design / what test data / results / actions taken as a result of errors /

32. Conversion (Implementation) Parallel—expensive Direct cutover—risky Pilot study—limit use to one area Phased approach—in stages by function or work unit

33. Post Implementation Audit Compare actual implementation time and cost to schedules and budgets Compare actual operating costs to estimates Review operations, documentation, security, controls Modify system as necessary

34. Dangers Of An Ad Hoc Approach The completed system is not what the users want The customers do not use the system. There is much conflict in the development of the system. Resources are wasted.

35. Dangers of an Ad Hoc Approach People may have to work harder than needed. The system does not produce the right information. The system is not finished on time. The developers get a bad reputation.