Managaement Information Systems classes presentation

Presentation

1. MIS326 Object oriented modelıng

2. outline Overview of Object Oriented Modeling Overview of Systems Development Methods Overview of Requirements Collection Overview of Requirements Modeling Basics of Object Oriented Modeling

3. Structure of the slıdes – sample slıde External Events Events that occur outside the system, usually initiated by an external agent or actor (a person or organizational unit that supplies or receives data from the system) External Event Checklist External agent wants something resulting in a transaction External agent wants some information Data changed needs to be updated Management wants some information

4. Simple behavioural Model How do you prepare lunch for your child /nephew ? Hint: Assume a peanut-butter jelly fan As a < type of user >, I want < some goal > so that < some reason >. “As a user, I can backup my entire hard drive.” Examples: https://www.mountaingoatsoftware.com/agile/user-stories Dennis et al.p.6

5. Overview of Systems Development Methods A system development process is a set of activities, methods, best practices, deliverables, and automated tools that stakeholders use to develop and maintain information systems and software. It is often known as system development life cycle (SDLC) because every IS system is ‘born’ and eventually ‘dies’. “the process of understanding how an information system (IS) can support business needs by designing a system, building it, and delivering it to users” (Dennis et al.) Success rates?

6. Overview of Systems Development Methods Success Completion Standish Group (1996) - 42% of all corporate IS projects were abandoned before completion General Accounting Office (1996) - 53% of all U.S. government IS projects were abandoned Iron Triangle IAG Consulting - 80% of the projects were over time, 72% were over budget, and 55% contained less than the full functionality Panorama Consulting Solutions - 54% of the ERP projects were over time, 56% were over budget, and 48% delivered less than 50 percent of the initial benefits IBM - 59% of the projects missed one or more of on time, within budget, and quality constraints

7. Overview of Systems Development Methods System Analyst "The key person in the SDLC is the systems analyst, who analyzes the business situation, identifies opportunities for improvements, and designs an information system to implement them.“ (Dennis et al., p.2) Designs a system to add value Must understand the business processes Job is rewarding, yet challenging Requires specific skill sets

8. Overview of Systems Development Methods SDLC The process consists of four phases Planning, Analysis, Design, and Implementation Each phase consists of a series of steps Each phase is documented (deliverables) Phases are executed sequentially, incrementally, iteratively or in some other pattern Satzinger et al.

9. Overview of Systems Development Methods SDLC Planning phase Why should we build this system? What value does it provide? How long will it take to build? Analysis phase Who will use it? What should the system do for us? Where & when will it be used? Design phase How should we build it? Implementation phase Dennis et al.

10. Overview of Systems Development Methods Systems Development Approaches The systems development life cycle (SDLC) provides an overall framework for the process of system development, but the developer relies on many more concepts for help, including methodologies, models, tools, and techniques leading to different approaches.

11. Overview of Systems Development Methods Systems Development Approaches Methodology : Comprehensive guidelines to follow for completing every activity in the system development life cycle, including specific models, tools and techniques Model : A representation of some important aspect of the real world (abstraction). Most models are graphical – diagrams and charts Tool : Supportive software that helps create models or other components required in the project Technique : A collection of guidelines that help the analyst complete a system development activity or task

12. Overview of Systems Development Methods Systems Development Approaches Relationship among the components of a methodology Satzinger et al. Satzinger et al.

13. Overview of Systems Development Methods Systems Development Approaches Structured Method Object Oriented (OO) Method Agile Methods Other Methods

14. Overview of Systems Development Methods Systems Development Approaches - Structured Method Represents the system in terms of data and the processes that act upon that data. System development is organized into phases, with deliverables and milestones to measure progress. The waterfall model typically consists of four phases: planning, analysis, design, implementation . Iteration is possible among the phases. Data flow diagrams (DFDs) and process descriptions are used for modeling . Satzinger et al.

15. Overview of Systems Development Methods Systems Development Approaches - Structured Method Satzinger et al. Dennis et al. p. 8

16. Overview of Systems Development Methods Systems Development Approaches - OO Method Views the system in terms of objects that combine data and processes. The objects represent actual people, things, transactions, and events. Compared to structural analysis, O-O phases tend to be more interactive. Can use the waterfall model or a model that stresses greater iteration. Various object-oriented diagrams depict system actors, methods, and messages are used for modeling .

17. Overview of Systems Development Methods Systems Development Approaches - Agile Methods Stresses intense team-based effort. Breaks development into cycles, or iterations, that add functionality. Each cycle is designed, built, and tested in an ongoing process. Attempts to reduce major risks by incremental steps in short time intervals. Tools that enhance communication, such as collaborative software, brainstorming, and whiteboards are used for modeling . “Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan” https://agilemanifesto.org/

18. Overview of Systems Development Methods Systems Development Approaches - Other Methods IT professionals know that the key to success is user input before, during, and after a system is developed. Hence, they start to include IT staff, users, and managers systems in their development teams to complete their work more rapidly and produce better results. Two methodologies became popular: joint application development (JAD) and rapid application development (RAD). The difference is that JAD focuses on team-based fact-finding, which is only one phase of the development process, whereas RAD is more like a compressed version of the entire process.

19. Overview of Requirements Collection Requirements collection is the process of determining and managing stakeholder needs & requirements to meet IS project objectives. Mostly used requirements collection techniques are; Sampling of existing documentation and forms Research and site visits Observation of the work environment Questionnaires Interviews Prototyping Joint requirements planning

20. Overview of Requirements Collection Sampling of Existing Documentation & Forms The best way to analyse the existing system is to collect facts from existing documentation rather than from human sources. There are various kinds of documents to collect facts from existing documents. These include: e-mails, customer complaints, suggestion box notes and reports that document the problem area problem performance reviews, samples of completed manual forms and reports and samples of completed computerized forms and reports

21. Overview of Requirements Collection Research and Site Visits Research and site visits is the process of examining the problems which were previously solved by other sources that can be either human or documents. To solve the requirements of problem, the analyst visits to other organization that had previously experienced for similar problems . In addition, the analyst can also find the information from database, reference books, case studies and Internet.

22. Overview of Requirements Collection Observation of the Work Environment In this technique, system analyst participates in the organization, studies the flow of documents, applies the existing system, and interacts with the users. Observation can be a useful technique when the system analyst have user point of view . By using this technique, system analyst can know how employees spend their days.

23. Overview of Requirements Collection Questionnaires Questionnaires are useful fact-finding technique to collect information from large number of users. Users fill up the questions which are given by the system analyst and then give the answers back to the system analyst. Questionnaires can save time because system analyst does not need to interview each of users and if the time of interview is short, questionnaires are more useful. To fulfil the requirements of the system objective, system analyst should have the ability to clearly define the design and frame of questionnaires. Preliminary insight into business Not well suited for gathering detailed information

24. Overview of Requirements Collection Interviews Interview is the most commonly used technique to collect information from the face-to-face interviews. The purpose of interview is to find, verify, clarify facts, motivate end-users involved, identify requirements and gather ideas and opinions . The role of interview includes interviewer who is system analyst and interviewee who are system owner or user. Interviewing technique needs good communication skills for interaction between system analyst and user.

25. Overview of Requirements Collection Interviews Satzinger et al.. P.53

26. Overview of Requirements Collection Prototyping Prototyping is sampling a small working model and it is more related to pre-design of the information system. The implementation of prototyping can be developed in earlier stage of system development life cycle when analyzing the facts. The process of prototyping facts in order to specify the users’ requirements is also known as discovery prototyping.

27. Overview of Requirements Collection Joint Requirements Planning (JRP) JRP is the structured group work meeting to identify, analyze problems and define the requirements of system. JRP can tabulate the facts efficiently in a short time and it can also replace in the place of numerous and separate interviews. JRP contains different participants with each specialized roles to perform structured meeting. JRP participants include sponsor, facilitator, users and managers, scribes and IT staff.

28. Overview of Requirements Modeling Requirements modeling involves graphical methods and nontechnical language that represent the system at various stages of development. A requirements model is a set of diagrams, each of which focuses on a different aspect of the users' needs. Modeling is important to Learn during the modeling process Reduce complexity by abstraction Remember all of the details Communicate with other development team members Communicate with a variety of users and stakeholders Document for future maintenance / enhancement

29. Overview of Requirements Modeling Models Used in Structured Approach and OO Approach Events Event Table Things

30. Overview of Requirements Modeling Events Event is an occurrence at a specific time and place, that can be described and is worth remembering. Events drive or trigger all processing that a system does. Focusing on events gives a way to compose the system requirements. Types of events: External event Temporal event State event

31. Overview of Requirements Modeling External Events Events that occur outside the system, usually initiated by an external agent or actor (a person or organizational unit that supplies or receives data from the system) External Event Checklist External agent wants something resulting in a transaction External agent wants some informatiom Data changed needs to be updated Management wants some information

32. Overview of Requirements Modeling Temporal Events Events that occur as a result of a reaching a point in time. Based on system deadlines Temporal Event Checklist Internal outputs needed Management reports Operational reports Statements, status reports External outputs needed Statements, status reports, bills, reminders

33. Overview of Requirements Modeling State Events Events that occur when something happens inside the system that triggers the need for processing. State Event Checklist Consequence of external events Example: Walmart

34. Overview of Requirements Modeling Event Table : A table that lists events in rows and key pieces of information about each event in columns Event : The event that causes the system to do something Trigger : An occurrence that tells the system that an event has occurred, either the arrival of data needing processing or a point in time Source : An external agent or actor that supplies data to the system Activity : Behaviour that the system performs when an event occurs Response : An output, produced by the system, that goes to destination Destination : An external agent or actor that receives data from the system Event Trigger Source Activity Response Destination

35. Overview of Requirements Modeling Things Things are what the system needs to store information about. In traditional approach, these things make up the data which the system stores information about. In the object-oriented approach these things are objects. Types of things: The analyst can identify types of things by thinking about each event in the event list and asking what types of things are affected that the system needs to know about. Tangible things Roles played Organizational units Devices Incidents, events, or interactions Sites/locations

36. Overview of Requirements Modeling Things Things are what the system needs to store information about. In traditional approach, these things make up the data which the system stores information about, in the object-oriented approach these things are objects. Types of things: The analyst can identify types of things by thinking about each event in the event list and asking what types of things are affected that the system needs to know about. Tangible things Roles played Organizational units Devices Incidents, events, or interactions Sites/locations Satzinger et al.. P.

37. Overview of Requirements Modeling Procedure for Developing an Initial List of Things Step 1: Using the event table and information about each use case, identify all nouns Step 2: Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed Step 3: Refine list and record assumptions or issues to explore Satzinger et al.. P.

38. Basics of Object Oriented Modeling OO approach considers an IS as a set of objects that work together to carry out the function. OO approach involves two steps: Defining the set of objects that will make up the system and describing the interactions or communications among the various objects. Describing the internal processes that go on within each object to respond to messages from other objects, and to initiate messages to other objects Unified Modeling Language (UML) notation is used for modeling system requirements in OO approach. Class diagram, Use case diagrams, Interaction diagrams and statechart diagrams are the diagrams used in OO analysis

39. Basics of Object Oriented Modeling Object-Oriented Approach to Systems “Create an order for Susan Franks for an executive desk and a very comfortable chair” Satzinger et al.. P.

40. Basics of Object Oriented Modeling Object-Oriented Approach Object-oriented analysis (OOA)‏ Defines types of objects users deal with Shows use cases (behaviour of a system – focus on business process) are required to complete tasks Object-oriented design (OOD)‏ Defines object types needed to communicate with people and devices in system Shows how objects interact to complete tasks Refines each type of object for implementation with specific language of environment Satzinger et al.. P.

41. Basics of Object Oriented Modeling Object-Oriented Approach Object-oriented programming (OOP)‏ Writing statements in programming language to define what each type of object does Satzinger et al.. P.

42. Basics of Object Oriented Modeling Characteristics of Object-Oriented Systems Classes & Objects Object (instance): instantiation of a class Attributes: information that describes the class State: describes its values and relationships at a point in time Methods & Messages Methods: the behaviour of a class Messages: information sent to an object to trigger a method (procedure call) Encapsulation & information hiding Encapsulation: combination of process & data Information hiding: functionality is hidden Inheritance General classes are created ( superclasses ) Subclasses can inherit data and methods from a superclass Polymorphism & dynamic binding Polymorphism: the same message can have different meanings Dynamic binding: type of object is not determined until run-time Contrast with static binding Dennis et al.. P.

43. Basics of Object Oriented Modeling Class Diagram identifies and classifies the objects that will make up the new system and the relationships between them. Class: A general template we use to define and create specific instances , or objects

44. Basics of Object Oriented Modeling Use Case Diagram is a diagram to show the various user roles and how they will use the system. It is an extension of the event table. It is a convenient way to document the function that the system must support. Use Case 1 Use Case 2 Use Case 3

45. Basics of Object Oriented Modeling Package Diagram is a high-level diagram that identifies the major components of a system and developed from decision how to best partition the system

46. Basics of Object Oriented Modeling Interaction Diagrams The sequence diagram shows sequence of messages between objects during a use case. It shows also the interaction or messages, that are sent between the objects to carry out this function. The collaborative diagram shows which object should “collaborate” to realize a given business function. It is another view of the same information contained in the sequence diagram.

47. Basics of Object Oriented Modeling Activity Diagram focuses on modeling the flow of control through a processing activity as it moves among people, organizations, computer programs, and specific processing steps. The diagram directly models the sequence of processing activities and uses some symbols from flow charts. 

48. Basics of Object Oriented Modeling Statechart diagram describes the states and behaviour of each object.

49. Basics of Object Oriented Modeling The following formula helps so remember the relation of these diagrams: OO Requirements = Event Table + Things + Class Diagram + Use Case Diagrams + Package Diagrams + Interaction Diagrams (sequence and/or collaboration diagrams) + Activity Diagrams + Statechart Diagrams

50. SDLC SDLC Variations Many variations of SDLC in practice Based on variation of names for phases No matter which one, activities/tasks are similar Some increase emphasis on people User- centered design, participatory design Sociotechnical systems Some increase speed of development Rapid application development (RAD)‏ Prototyping Satzinger et al.. P. Modified Waterfall Approach Overlapping Phases The Spiral Life Cycle Model Iteration of System Development Activities

51. SDLC Current Trends in Development More adaptive approaches The Unified Process (UP)‏ Extreme Programming (XP)‏ Scrum Satzinger et al.. P.

52. SDLC The Unified Process (UP) Object-oriented development approach Offered by IBM / Rational Booch , Rumbaugh, Jacobson Unified Modeling Language (UML) used primarily for modeling UML can be used with any OO methodology UP defines four life cycle phases Inception, elaboration, construction, transition Satzinger et al.. P.

53. SDLC The Unified Process (UP) Reinforces six best practices Develop iteratively Define and manage system requirements Use component architectures Create visual models Verify quality Control changes Satzinger et al.. P.

54. SDLC Extreme Programming (XP)‏ Recent, lightweight, development approach to keep process simple and efficient Describes system support needed and required system functionality through informal user stories Has users describe acceptance tests to demonstrate defined outcomes Relies on continuous testing and integration, heavy user involvement, programming done by small teams Satzinger et al.. P. “Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan” https://agilemanifesto.org/

55. SDLC Scrum For highly adaptive project needs Respond to situation as rapidly as possible Scrum refers to rugby game Both are quick, agile, and self-organizing Team retains control over project Values individuals over processes Satzinger et al.. P. “Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan” https://agilemanifesto.org/

56. Summary Overview of Object Oriented Modeling Overview of Systems Development Methods Overview of Requirements Collection Overview of Requirements Modeling Basics of Object Oriented Modeling

57. Summary System development projects are organized around the systems development life cycle (SDLC) Some projects use a predictive approach to the SDLC, and others use a more adaptive approach to the SDLC SDLC phases include project planning, analysis, design, implementation, and support In practice, phases overlap, and projects contain many iterations of analysis, design, and implementation Models, techniques, and tools make up a system development methodology System development methodology provides guidelines to complete every activity in the SDLC System development methodologies are based on traditional approach or object-oriented approach Current trends include: Extreme Programming (XP), Unified Process (UP), and Scrum Visual Modeling tools are designed to help analysts complete system development tasks