1 / 67

Final Exam Review

Final Exam Review. IDS 306 Spring 1999 Vicki Murphy. 5/11/99. Norman Ch 1 Introduction. 4-5 What is a system 5-6 What is an information system 7 What is an automated information system 10 -12 Both systems analysis and design sections 14 -17 Three sections on systems analysts

faris
Télécharger la présentation

Final Exam Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Final Exam Review IDS 306 Spring 1999 Vicki Murphy 5/11/99

  2. Norman Ch 1 Introduction • 4-5 What is a system • 5-6 What is an information system • 7 What is an automated information system • 10 -12 Both systems analysis and design sections • 14 -17 Three sections on systems analysts • 23-24 IS Requirements Specification • 24-25 IS Life Cycle & Information SDLC • 26-27 Principles to guide SA&D

  3. SYSTEM processing boundary controls inputs outputs feedback A Generic System Model (with Six Components) • Examples: • Automobile • Student Registration System • Others...

  4. An INFORMATION SYSTEM is: • a type of fabricated system • used by one or more persons • to help them accomplish some task or assignment they have • An Information System: • supports policies & procedures • has three components - data, • people, procedures - in addition to • the six general system components data people procedures (input, output, processing, control, feedback and boundary)

  5. An AUTOMATED INFORMATION SYSTEM IS: • a type of fabricated system • used by one or more persons • to help them accomplish some task or assignment they have • utilizes hardware and software data people procedures software hardware

  6. What makes Systems Analysis and Design a difficult activity? • Initially, problem domains (areas) tend to have poorly defined BOUNDARIES • Problem domain SOLUTIONS are artificial • Problem domains are DYNAMIC • Problem domain solutions usually require INTERDISCIPLINARY knowledge and skills • Systems Analyst’s KNOWLEDGEBASE is continually expanding • Systems Analysis and Design is a highly COGNITIVE activity • Working with PEOPLE

  7. What does a Systems Analyst do? Studies the problems and needs of an organization looking for improvement opportunities for: • increasing revenue/profit • decreasing costs • improving quality of service

  8. What is a Systems Analyst responsible for? Effective and efficient: • CAPTURE of input data • PROCESSING & STORAGE of data • DELIVERY of timely and accurate information

  9. General Model of Information Systems Development (“Partnership”) Stakeholder Information System (6) Requirements (1) Continued Involvement (5) Design and Implementation Requirements Specification (3) Analysis Problem Definition Skills (2) Problem Solution Skills (4) Information Technology Staff

  10. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) Analysis • Planning • Feasibility Study (optional) • Requirements Determination • Conceptual Design • Physical Design • Construction and/or Purchase (prototype) • Conversion - old to new • Training • Implementation • Evolution - maintenance & enhancements Design

  11. Norman Ch 2 Feasibility & RD • 30-33 Feasibility Analysis • 33-35 Requirements Determination • 36-37 Problem Domain • 37-38 Frameworks for RD • 40-44 Kozar’s Requirements Model • 44-45 Object-Oriented RD • 46, 47, 50, 51

  12. FEASIBILITY ANALYSIS • FEASIBILITY (in information systems development) is the measure of how beneficial the development or enhancement of an information system will be to the business • FEASIBILITY ANALYSIS is the process by which feasibility is measured

  13. FEASIBILITY TYPES • OPERATIONAL FEASIBILITY is the measure of how well a particular information system will work in a given environment • TECHNICAL FEASIBILITY is the measure of the practicality of a specific technical information system solution and the availability of technical resources • ECONOMIC FEASIBILITY is the measure of the cost-effectiveness of an information system solution

  14. 1. Systems Development Costs(one-time; representative only) • Personnel: • 2 Systems Analysts (450 hours/each @ $45/hour) $40,500 • 5 Software Developers (275 hours/each @ $36/hour) 49,500 • 1 Data Communications Specialist (60 hours @ $40/hour) 2,400 • 1 Database Administrator (30 hours @ $42/hour) 1,260 • 2 Technical Writers (120 hours/each @ $25/hour) 6,000 • 1 Secretary (160 hours @ $15/hour) 2,400 • 2 Data Entry clerks during conversion (40 hrs/ea @ $12/hr) 960 • Training: • 3 day in-house course for developers 7,000 • User 3 day in-house course for 30 users 10,000 • Supplies: • Duplication 500 • Disks, tapes, paper, etc. 650 • Purchased Hardware & Software: • Windows for 20 workstations 1,000 • Memory upgrades in 20 workstations 8,000 • Mouse for 20 workstations 2,500 • Network Software 15,000 • Office Productivity Software for 20 workstations 20,000 • TOTAL SYSTEMS DEVELOPMENT COSTS: $161,670

  15. 2. Annual Operating Costs(on-going each year) • Personnel: • Maintenance Programmer/Analyst (250 hrs/year @ $42/hr) $10,500 • Network Supervisor (300 hrs/year @ $50/hr) 15,000 • Purchased Hardware & Software Upgrades: • Hardware 5,000 • Software 6,000 • Supplies and Miscellaneous items 3,500 • TOTAL ANNUAL OPERATING COSTS: 40,000 • ----------------------------------------------------------------------------------------------------------- • TOTAL COST TO DEVELOP AND OPERATE THE SYSTEM: $201,670 ==========

  16. What are Requirements? Three (3) alternative ways to think about Requirements: • Requirements are criteria that are necessary, needed, or demanded. • Requirements are implicit or explicit criteria that must, should, or might be met. • Requirements equal the wants and needs of the user(s).

  17. Observations about Requirements • Requirements are not supposed to dictate any details regarding the implementation of a solution. • We commonly define differing levels of necessity for our requirements, such as “absolutely must be satisfied”, “nice to have”, and “optional”. • Some requirements may apply to an entire system, while others apply only to part of the system. • Compromise is often necessary for conflicting requirements from different user(s). • Some requirements are static, while others are dynamic and evolve or emerge over time. • Requirements are not always easy to explain (communicate), understand, or document.

  18. Types of Requirements There are three major types of requirements: • User-Driven • not desirable • User-Reviewed • user and analyst working together • User-Independent • software product vendors

  19. Be Suspicious of the Quality of Requirements Requirements usually have one or more of the following 8 problems: • Omissions • Contradictions • Ambiguities • Duplications • Inaccuracies • Introduced elements • Too much design • Irrelevant information

  20. Framework: Requirements Model (Kozar)* A strategy that links information systems activities with established business activities. PREMISE: Information systems support business activities; therefore, associating information systems activities with business activities should be possible. Provides verification and validation (V & V) traceability * Adapted from Kozar, K.A., Humanized Information Systems Analysis and Design, McGraw-Hill Inc., 1989, pp. 61-62 and personal communication with the author.

  21. Kozar’s Requirements Model Hired a marketing consultant Recommends better tracking of where sales orders come from Mkt. code on each promo. piece mailed out Develop mkt. codes Track sales based on mkt. codes Reports showing promo. piece effectiveness Modify Sales Order Fulfillment Sys (about 2 dozen changes) STIMULI BUSINESS OBJECTIVES BUSINESS TACTICS INFO. SYS. OBJECTIVES INFO. SYS. TACTICS A change of some type forces changed enterprise needs causing changed user behaviors requiring changed information needs requiring changed I.S. activities BENEFITS COSTS BENEFITS COSTS

  22. AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION METHODOLOGY The preceeding four (4) activities are performed for each of four (4) Object Model Components: • Problem Domain component (PD) • Human Interaction component (HI) • Data Management component (DM) • System Interaction component (SI)

  23. AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION METHODOLOGY Four Activities: 1. Identify the purpose and features of the information system 2. Identify objects and patterns 3. Establish object responsibilities - attributes, relationships, and services 4. Work out the information system’s dynamics using scenarios

  24. Some Final Thoughts Regarding Requirements Determination • People ARE Different! (Thinking & Behaviors) • Each Software Development Project Is Different! • Requirements Determination Is an Iterative Process • Some Sub-Processes May Be Accomplished Concurrently • The Requirements Determination Effort May Be Accomplished At More Than One Point In the Life-Cycle • The Requirements Determination Effort May Be Driven By External or Uncontrollable Circumstances • Requirements Determination Should Not Be Driven By Low-Level Issues • Verification, Validation, and Quality Assurance Are Always Important for Requirements Determination • Corrections and changes to Requirements late in the SDLC may cost between 30 and 70 times their cost if done initially

  25. Norman Ch 3 O-O Model • 55-56 Methodologies • 60-66 Key Characteristics of O-O • 68-71 Coad’s OO A&D Methodology • 73 component definitions • 73-82 An Object-Oriented Model

  26. METHODOLOGY OVERVIEW • Classifications of Methodologies • Traditional • Structured Analysis and Design • Information Modeling/Engineering • Object-Oriented • Prototyping is a technique - (some say that it is a methodology)

  27. Object Technology Principles • Abstraction • Encapsulation (Information Hiding) • Inheritance • Message Communication • Associations • Polymorphism • Common Methods of Organization • Reuse

  28. Abstraction A mental ability that permits people to view real-world problem domains with varying degrees of detail depending on the current context of the problem. • Helps people to think about what they are doing • Functional and Data abstraction

  29. cake • Encapsulation (Information Hiding) A technique in which data are packaged together with their corresponding procedures. • In Object-Oriented Technology the “package” is called an OBJECT • The interface to each object is defined in such a way as to reveal as little as possible about its inner workings • Encapsulation allows [software] changes to be reliably made with limited effort [Gannon, Hamlet, & Mills, 1987] One cake please! Ingredients 2 eggs 4 cups flour 1 cup milk 1 cup sugar etc....... Directions Pre-heat oven to 350; Put milk, eggs, and sugar in 2 quart mixing bowl...

  30. Inheritance A mechanism for expressing similarity between things thus simplifying their definition. Inheritance Person Student Faculty Staff • looks • behavior • attitudes • etc...

  31. Message Communication Objects communicate via messages OBJECT OBJECT OBJECT OBJECT

  32. Associations The union or connection of ideas or things. (Objects need to interact with each other) • same point in time • under similar circumstances crime scene #2 crime scene #1 Advertisement #2 Advertisement #1 Billing Statement crime scene #n

  33. Polymorphism (“many forms”) • The ability to hide different implementations behind a common interface. • The ability for two or more objects to respond to the same request, each in its own way. • H O = water, ice, steam (liquid, solid, vapor) • Eating 2 Door #1 #2 #3 Door #1 Door #2 Door #3 versus

  34. Polymorphism • Two examples PRINT TEXT object PRINT GRAPH object PRINT IMAGE object PO object = add a line item to the PO Add Object #1 = increase $ Amount Balance Account object Object #2 Add Department object = hire a new employee Object #3 Add

  35. O-O Systems Analysis & Design Methodology Classification Theory (Common Methods of Organization) • Objects and their characteristics • Wholes and Parts • Groups (Classes) and Members

  36. Common Methods of Organization People are accustomed to thinking in terms of... Objects & Attributes • color • price • weight • engine • options... Wholes and Parts Groups & Members • number of doors • number of wheels • number of windows • number of lights • number of bolt type 1 • number of bolt type 2 • etc.... • VANS: • light utility • utility • passenger • etc...

  37. Reuse The ability to reuse objects • Varying Degrees of Reuse: • complete or sharing • copy, purchase or cloning • partial or adjusting • none • Software: • “Chips” • Components • Controls • Models

  38. Model Components • Problem domain -- directly correspond to the problem being modeled • Human interaction -- provide interface between the PD objects and people • Data management -- provide interface between PD objects and a database or file management system • System interaction -- provide interface between PD objects and other systems or devices

  39. Coad’s Object Model Notation model component class with objects class

  40. Coad’s Object Model Notation Expanded view of a class or class with objects into its three sections: top: Class Name middle: attributes bottom: services Member { memberNumber firstName lastName telephone address city etc... Attributes { checkOutVideo checkInVideo buyItem etc... Services

  41. Coad’s Object Model Notation whole-part object connection generalization-specialization connection n-n 1 object connection message n n n

  42. Norman Ch 4 Objects & Classes • 87-88 Objects & Classes • 89 Figure 4.2 • 89-91 Class Attributes & Services Defined • 92 Finding Objects • 95-96 (challenging objects)

  43. Defining Objects An OBJECT is an abstraction of a person, place, thing, or concept within the problem domain that the information system must be aware of. ...Objects are “instantiated” (created) ...the term “instance” is interchangeable with “object”

  44. Objects • Objects have three responsibilities: • What they know about themselves - Attributes • What they know about other objects - Relationships • What they do - Operations

  45. A CLASS with no objects is oftenreferred to as an ABSTRACT CLASS Person Faculty Administrator Student

  46. 1. Objects must always belong to a class. 2. The first letter of class names and the first letter of each word in the class name should be capitalized. Examples: Student, Bicycle, DataEntryClerk. 3. All names of classes, attributes and services should be singular. Examples: Student instead of Students; Bicycle instead of Bicycles; DataEntryClerk instead of DataEntryClerks. 4. All names of classes, attributes and services should be meaningful. Examples: SalesDept, AccountsPayable, Cashier, SaleLineItem. 5. The class notation symbol is partitioned into 3 parts: Name, attributes and services. 6. Attribute and service names should start with a lower case letter; each additional word used in the name should begin with a capital letter. Example: studentIdNumber, inventoryControlNumber, gradePointAverage, requestTranscript, calculateSalesTax. Rules and Guidelines for the Object Model Notation

  47. CHALLENGE CLASSES/OBJECTS BASED ON: • More than one Attribute • Needed services • Needed remembrance • More than one Object • Avoid derived (computed) results

  48. Norman Ch 5 Attributes • 103-106 Attributes • 107-108 Attribute Types • 109-112 Both sections on OO Strategy • be sure to check your errata sheet

  49. Student studentName studentIDNumber eyeColor height weight dateOfBirth etc... services studentName studentIDNumber eyeColor height weight dateOfBirth MIchael W Smith Amy Grant 559-46-0912 371-38-7640 Blue Brown 5ft 9in 5ft 6in 155 118 4-12-74 12-2-73 Single Value Attributes Example

More Related