1. Information System IS: a set of related components working together in some environment to perform functions that achieve some objective.

2. Process Standard operating procedures Organizational policies InputOutput Customers Competitors Government Regulations Shippers

3. IS Functions –Input, Processing, Output, Storage, Controls IS Components –People, Procedures, Data, Software, Hardware Alternative: Object-oriented view of a system

4. Object-Oriented Systems Object –Attributes - characterize an object –Methods - the object’s behavior DOG Name Sex Breed fetch DOG OWNER Name Address Throw MakePayment VET Name Speciality GiveTreatment BillCustomer

5. Object class –set of objects with common attributes and functions Object Instance –has specific values for attributes –can perform all methods of the class

6. O-O systems: Inheritance Vet Dog Owner People.. CathyFred People VetDogOwner Cathy Fred

7. O-O systems: Inheritance Vet Dog Owner People.. Cathy Fred People VetDogOwner CathyFred Multiple inheritance

8. Systems Development: the process System lifecycle: –development phase * –production phase Systems approach –divide and conquer conversion

9. System Analysis –study business problem domain, existing system –identify requirements –specify characteristics of new system System decomposition –by functions performed –in terms of objects Systems Development: the process

10. System Design –evaluate alternative solutions, design a chosen solution –design document: basis for implementation Systems Development: the process

11. Two system development approaches Functional Decomposition –identify major activities, break up into composite steps (structured analysis and design) –focus on verbs (what a system does) Objects that comprise the system and how they act and relate –object structure and behavior analysis –focus on nouns (objects performing functions)

12. SDLC System development methodology –activities to solve a problem A methodology uses certain techniques (used to model a system) Model –representation of real world –used in analyzing and communicating what we understand DATA MODELS, PROCESS MODELS, OBJECT MODELS, etc.

13. System development catalysts User demand problems in current system, need for enhancements, improved efficiency Technology push new technology as catalysts Strategic pull system to support new business strategies/ products to stay competitive

14. Projects of varying complexity Upto 1000 lines –trivial, single person, few days/week 1000-10,000 lines –simple, 3/4 progr/analyst, 6-12 months –often formal analysis and design not used, but could be - leads to more maintainable system 10,000-100,000 lines –difficult, 6-12 people, 2-3 years –formal analysis and design essential –requirements/users change over time 100,000 - 1 million lines –complex. 50-100 people, 3-5 years –diverse community of users 1-10 million lines –nearly impossible > 10 million –absurd??

15. Why do IS projects fail? Did not support business strategy & objectives poor planning, project management failure to understand user requirements –user involvement in system development inadequate cost vs. benefit analysis –escalating costs, intangible benefits myriad of design defects/ errors installation of incompatible or inadequate technology no adequate controls implemented unstructured, un-maintainable software

16. Successful systems development Informal, sloppy art structured, engineered and managed approach (SDLC) stress user involvement in system development system planning and project management evaluate alternate designs before committing clean, complete and up-to-date documentation design for growth and change

17. Bugs! software errors cost U.S. users $59.5 billion each year. (National Institute of Standards and Technology (NIST) –just the cost of routine work-arounds and corrections by users, along with the added cost of buggy software that had to be fixed late in the development process. The real cost of bugs is much higher. –$22.2 billion of that $59.5 billion, or 37%, could be saved through "feasible improvements" in software testing. –“We indulge ourselves with the idea that all software has bugs, so trying harder to get rid of them is pointless perfectionism. Intellectually we should know better” !

18. Software: the product Software: a strategic business issue, not just a low-level support activity Can software be “manufactured” like physical products? (software “factories”) –Costs are concentrated on engineering (design) and support –“mythical man-month” Adding people to a project that is late will only worsen the situation. Why? Efficiency through re-use

19. Time Failure Rate Hardware Software Infant mortality Wear out Ideal Changes Failure Curves Actual

20. The Systems Analyst Roles –as a CONSULTANT (external) provide a fresh perspective disadvantage: organizational culture may not be known –as a SUPPORTING EXPERT –as a CATALYST FOR CHANGE interact with management excellent with people and machines analyze need for change, design change with consensus, implement change

21. The Systems Analyst Qualities –problem solver good analysis skills tools and techniques for analysis –communicator –computer skills –knowledge of business processes –self-disciplined and self-motivated

22. IS Building Blocks People Data Activities Networks Technology

23. IS Building Blocks: PEOPLE System Owners –sponsors, advocates –budgeting, time and money –responsible for ultimate acceptance System users –need for communication with users during A&D –different user groups with diff. info. Needs System designers –translate business/user requirements and constraints into technical solutions System builders –implement system based on design specifications

24. IS building blocks: DATA System owners’ view –info. on business resources –avoid details, focus on business entities of interest System users’ view –data experts, how data is used –identify data requirements, independent of implementation (entities, attributes, and rules) System designers’ view –files and databases System builders’ view –implement files, DBs, etc.

25. IS building blocks: ACTIVITIES System owners view –“big picture” System users view –distinct processes and their detail –SA elicits processing requirements from users [NOTE:users often biased by current system] System designers view –technology constraints –specifications [DFDs, structure charts, E/R, etc] System builders view –application programs

26. IS building blocks: NETWORKS (distributed people, processes, data) System owners view –geographic scope, locations System users view –details, data flow between locations, local data storage System designers view –system architecture, sharing/duplication of data, communication between machines System builders view –network control programs