Systems Development

1. Systems Development Infsy 570 Dr. Ocker

2. What we Mean by Software Quality Software Quality Effective- ness Maintain- ability Usability Efficiency Reliability Understand ability Modifiability Testability

3. Techniques for Information Gatheringin Systems Analysis Information Gathering Techniques Deriving from the Analysis of the Business Area Experimenting with the System under Dev. Asking the Users Deriving from an Existing System Interviewing Questionnaires Group Decision-Making Processes Data Analysis Document Analysis Observation Participation Business Systems Planning Critical Success Factors Decision Analysis “Throwaway” Prototyping Evolutionary Development

4. Systems Development Methods • Systems development - refers to all the activities that go into producing an information systems solution to an organizational problem or opportunity

5. Various methods for building information systems • I. traditional - systems development life cycle • II. prototyping • III. application software packages • IV. outsourcing

6. I. systems development life cycle (SDLC) • oldest method for building systems • assumes that system has a life cycle with a beginning, middle, and end • structured type of problem solving with distinct stages, activities, and deliverables • each stage consists of activities which must be completed before next stage begins

7. Systems Development Life Cycle Tasks Development Stages Deliverables Recommendation to Proceed and System Proposal or Recommendation to Abandon Feasibility Study Systems Analysis Requirements Analysis Requirements Specifications Logical Design Conceptual Design or Programs and Databases Systems Design Detailed Design of System Modules and Databases Specification of System Hardware and Software Physical Design Coding and Testing Programming (Construction) Accepted System with Complete Documentation Conversion Installed Operational System Installation Postimplemen- tation Review (System Operation and Maintenance) Recom. for Enhancement of the System and of the Dev. Method Recom. for Org. Adjustment

8. Systems Analysis • Determine what the system will do (as opposed to how ) • 2 stages • 1. Feasibility study (preliminary investigation) • 2. Requirements Analysis

9. Feasibility Study • Objective is to establish whether the proposed system is feasible/desirable before resources are committed • systems analyst perform a preliminary investigation of the business problem/opportunity • takes about 5-10% of project’s resources (time & money)

10. Feasibility Study Tasks • Define problem/opportunity • establish overall objectives of system • identify users of system • establish scope of system

11. Outcome of Feasibility Study • Recommendation to proceed or to abandon the project

12. Requirements Analysis • Objective is to produce the requirements specifications for the system • details about what the system will do

13. Requirements Analysis establishes • Outputs of system • inputs to system • processing steps needed to transform inputs into outputs • files and databases needed to store data

14. Requirements Analysis establishes • The volumes of data to be handled • numbers of users • file and database capacities

15. Information gathering techniques • 1. Ask users • 2. Derive from existing system • 3. Derive from analysis of business area • 4. Experimenting (i.e., prototype)

16. Systems Design • details how the system will meet the requirements as determined by the systems analysis • like a blueprint for a house - details all the specifications that give the system its form and structure

17. Systems Design • Must look at: • Hardware & Software • Program & Modules • Specifications of the modules • Design the Data base • Design the USER interface • Develop the system procedures

18. Systems Design • 2 types of design • logical • physical

19. Logical Design • A more macro level design • conceptual • activities include • devising alternative solutions to problem and choosing an alternative • user interface design • logical/conceptual design of database

20. Physical Design • Objective is • to produce a complete specification of all system modules and of interfaces between them • to perform the physical design of the database

21. Physical Design • When the physical design is complete, the following aspects will be specified: • system outputs (e.g., report layouts, screen designs) • system inputs • user interface • platforms (HW, SW) • program design • detailed test plan • database • conversion plan

22. Programming • programming and documenting code

23. Testing • System pieces and later, the entire system, are run for purpose of finding errors

24. Conversion • Plan to move from old system to new system • parallel - old and new systems run together • direct - turn off old, turn on new • phased - convert new system in increments by function • pilot - introduce system to one organizational area before proceeding to the remainder of the org.

25. Post-implementation Review • evaluating system after it is in production (i.e. after installed and in use for awhile) • post-implementation audit • Did we do what we said we would do?

26. Cyclical nature of SDLC • when an analyst finishes one phase and proceeds to the next, the discovery of a problem may force the analyst to go back to the previous phase

27. Limitations of SDLC • appropriate for building large transaction processing and management information systems where requirements are highly structured and well-defined • also used for complex technical systems (e.g. air traffic control) where formal and rigorous requirements are needed, along with tight controls

28. Drawbacks • 1. resource intensive - takes lots of time to gather detailed information and prepare volumes of specifications

29. Drawbacks • 2. approach is inflexible and inhibits change - • to make changes/ correct errors - repeat appropriate life cycle activities, but must generate more documents - substantially increase development time and costs • encouraged to freeze system specifications early in development process - so changes not encouraged

30. Drawbacks • 3. approach not suited for decision making applications • decision making tends to be unstructured; • requirements change/uncertain so difficult to specify requirements

31. II. Prototyping • building an experimental system rapidly and inexpensively for users to evaluate • working version of an IS or part of the system • preliminary model

32. Prototyping • iterative process of development • build preliminary design • try it out • refine it • try it out etc.

33. Prototyping • prototyping much more iterative than SDLC • promotes design changes • less formal approach than SDLC • quickly generate working model of system • no detailed specifications

34. Steps in prototyping • 1. identify users’ basic requirements • designer works with user only long enough to capture • basic needs • 2. develop working prototype • designer creates prototype quickly

35. Steps in prototyping • 3. use prototype • user works with prototype to determine how well it • meets his/her needs • user suggests improvements

36. Steps in prototyping • 4. revise and enhance prototype • designer refines prototype based on users’ input • repeat steps 3-4 until user satisfied

37. Prototyping • Approved prototype becomes basis for final specifications of the system • more rapid, iterative and informal than SDLC

38. Advantages of prototyping • useful when uncertainty about information requirements or design solutions • e.g. requirements for decision-oriented systems can be vague -- difficult to specify

39. Advantages of prototyping • good for design of user interface (part of system that end-users interact with) • encourages user involvement throughout systems development

40. Disadvantages of Prototyping • should not substitute for careful requirements analysis • better suited for smaller applications

41. III. Application software packages • develop a system by purchasing an application software package • application software package - set of prewritten, precoded application software programs that are commercially available • packages available for common functions such as payroll, accounts receivable, inventory control, etc.

42. Choose packages when • 1. functions common to many companies • 2. information systems resources for in-house development in short supply • 3. developing desktop applications for end-users

43. Advantages of packages • buying completed, working system • require less internal resources - upgrades received from software supplier • reduce bottlenecks in systems development

44. Disadvantages of Packages • can lack sophistication • lack of integration of several functions • may require customization - modify package to meet specific needs

45. IV. Outsourcing • hire external organization to build and/or operate systems • can outsource all or some of systems function • advantages and disadvantages

46. Advantages of Outsourcing • economy - less costly • service quality - may get better service than from internal development • predictability - outsourcing contract with fixed price • flexibility - growth without making major changes in IT infrastructure

47. Advantages of Outsourcing • making fixed costs variable - pay only for amount of services used rather than for maintaining internal system • freeing human resources for other projects • freeing financial capital - can sell technology to vendor

48. Disadvantages of Outsourcing • loss of control over IS function • vulnerability of strategic information - trade secrets, proprietary information • dependency on viability of vender - i.e. financial, quality of services provided • loss of knowledge and expertise