Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building an Information System


Published on

7 STEPS FOR BUILDING AN INFORMATION SYSTEM By: David Chilcott Outformations, Inc

Published in: Education, Technology, Business
  • Be the first to comment

Building an Information System

  1. 1. STEPS FOR BUILDING AN INFORMATION SYSTEM By: David Chilcott Outformations, Inc By : Sheryle Domingo DM 216 - Information Technology Management Masters in Development Management PSU-Urdaneta Graduate School
  2. 2. DEFINITION OF TERMS Actor – Description of the ROLE with which a stakeholder interacts with the system. An object representing an external agent, human or mechanical, with which the system must interact. Analysis – An act of exploring the problem domain to gain a better understanding of the problem
  3. 3. Controller (MVC) – The goal of the MVC design pattern is to separate the application object (model) from the way it is represented to the user (view) from the way in which the user controls it (controller) Design – The mapping of an analysis onto a selected architecture to create a software solution to a problem. Domain – A coherent body of knowledge, rules, and definitions, related to a particular subject.
  4. 4. Domain Model – The collection of “objects” (classes) that represent the real-world things and concepts related to the problem domain that the system is being designed to solve. Functional Interface Prototypes – An interface mockup that displays the functional components/objects but not necessarily using the final “look and feel” or esthetic design. Used to capture business rules and other design information such as the order and validation of fields or the interface behavior required to fulfill a particular use case.
  5. 5. Interface – The point of an interaction or communication between a computer and any other entity, such as a printer or human operator. Interoperability – The ability of two or more systems or components to exchange information and to use the information that has been exchanged. Use Case – Describes a particular, observable, system behavior from the perspective of the Actor using the system. A complete “unit” of system functionality which describes the user’s interaction with the system with a defined beginning and end.
  6. 6. INTRODUCTION: The Outformations 7-Step Development Process originated out of a desire to create a simple, clear, and understandable way for project teams to work together to build information systems that actually solve the problems they are supposed to address. Originally it was based, in large part on thinking done by a former partner, Kenneth Tyler. At the time we were exploring the use of CRC cards as a tool for uncovering and exploring system requirements. Kenneth’s key insight was the step-wise fashion that information at each level informs the steps above and below it. In addition, some of the text below comes from early drafts of this document.
  7. 7. CONTEXT: The following concept and assumptions are important to understanding our development process. It is believed that any methodology that integrates these ideas substantially improves the likelihood of building a successful Information System. • Assumption/Definitions – Make them as explicit as possible • Projects – Organize work into chunks to help you manage them. One of the most important issues is setting the boundaries of these “chunks”. This is also known as defining and agreeing on the project’s scope.
  8. 8. •Discovery – Should be encouraged and supported throughout the life of a project. It is simply not possible to foresee all possibilities because of the complexities involved. • Process/Iteration – A process is defined as a series of actions, changes, or functions bringing about a result. An iteration is a process or procedure in which the desired result is approached through a repeated cycle of operations, each
  9. 9. SCOPE OF PROJECT: 1. Extent of perception, knowledge, experience, or ability. (Does the project team have what’s necessary to complete the work?) 2. The area or sphere in which an activity takes place. 3. The full extent covered: within range of possibilities. (Do we understand enough about the domain in which the system will operate) (Will the design of our system adequately resolve the issues or problems?)
  10. 10. Assumptions • Hard Work – IS are hard to build and maintain. Modern software development is a complex, expensive, and levels of sophistication. • Different Points-of-View – people come to the task of building an IS w/ different perspectives, interests, and levels of sophistication. •Models – Use diagrams, charts, maps, and other artifacts to help understand the world and each other.
  11. 11. •Communication, Shared Understanding, and Agreement – most IS project problem errors are the result of failures of communication or a lack of shared understanding or agreement. • Conversation – People already have a very effective mechanism for developing shared understanding and agreement.
  13. 13. STEP 1: IDENTIFY AND LIST STAKEHOLDERS The persons, entities, or systems that participates in THIS system. Include all the people who have the power over the system and all the people whose power and position are affected by the system. Include the people who will use the system. Example of Information to capture using CRC card model. Example of Information to capture using CRC card model.
  14. 14. One of the other important early work products that should be developed here, after identifying stakeholders is the Problem Statement. This is a statement of the motivation for developing the system from the stakeholders’ perspective(s). The Problem Statement provides the reasons for creating the application, as opposed to what the application must do functionally. The discussion fostered by reaching for agreement about the Problem Statement among stakeholders is useful for uncovering missing pieces or hidden assumptions about the system in question.
  15. 15. STEP 2: IDENTIFY AND LIST ACTORS Actors are abstractions that allow you to gather the system’s stakeholders into convenient groups. Each group is modeled as wanting to use the system in certain ways. One way of looking at ACTORS is as a way of describing a set of expectations of the system. Once you have modeled the Actors and their Use Cases you can compare these descriptions to what the actual stakeholders say they want. Building the model of a set of Actors lets you present to those stakeholders your idea of exactly what the system will do for them. It also lets you identify new expectations rapidly when they arise during the course of development. One value of having an explicit model of the system’s uses is that it forces many of the unconscious demands out of hiding.
  16. 16. Complete list of Actors would be a concordance of all roles played by all of the stakeholders who interact directly with the system. Example CRC card
  17. 17. STEP 3: IDENTIFY AND LIST USE CASES Description of a complete interaction that an Actor makes with the system, from start to finish. Each Actor can have one or more uses they make of the system. A Use Case is a model of a one complete cycle of interaction between an Actor and the System, that has a defined beginning and a defined end. Use cases are an organized way to think about what the system is expected to do for certain kind of users. It answers the question: “What useful services does a stakeholder reasonably expect the system to provide?” They present a complete view of a system in terms of the functionality it provides. The descriptions of the use case steps can be the basis for the user’s manual. Use cases can also be used to capture future ideas for a system as well as the functions that will be built into the current version. Use cases also provides a meaningful way to manage and organize the entire development effort.
  18. 18. THREE PHASES IN THE SYSTEM DEVELOPMENT LIFECYCLE DISCOVERING /SCOPING ANALYSIS The emphasis is on discovering all of the Stakeholders, Actors, and Use Cases. This early discovery and naming is extremely important. It sets the context and language used throughout the remaining development effort. Provides with the materials needed to develop our initial estimate of development schedule and cost. During the analysis pass we focus on defining and detailing the business and system functionality by listing the Scenarios and Steps in general. At this level we’re adding enough detail to the use cases to describe the necessary business rules and highlevel relationships between system components, but should be implemented independently DESIGN During the design pass we cross over into implementation details and decisions. Our use case details may include references to screen mockups, robustness analysis models, or links to any other design artifact that communicates important information. Our use case model can also be around each use case or set of related use cases (package).
  19. 19. STEP 4: IDENTIFY AND LIST SCENARIOS Description of the sequence of steps needed to complete a Use Case. Each use case can be broken down into a number of steps that the Actor goes through to execute it. Most use cases will have more than one pathway of steps that the Actor can follow to achieve their end. These different ways that the Use Case can play out are called “Scenarios”. Each use case should have a normal scenario defined that describes its execution when everything goes as intended. Any significant exceptions or variations should have their own scenarios as well. For example if the use case is creating an invoice for a sales transaction using a credit card, the if the customer fails the credit check the scenario may require that the payment be in cash.
  20. 20. DISCOVERING /SCOPING During the discovery/scoping pass we limit our focus to identifying the primary or “normal” scenarios and any obviously significant, important, or high risk scenarios for each use case. Our deliverable would include a scenario name and a short 1-3 sentences summary or overview descriptions of these important variations. ANALYSIS During the analysis pass we focus on providing more definition and details for our identified scenarios. We also add scenarios that have been identified during the course of our other discovery or analysis efforts. This would be the time to use refactoring to create reusable “abstract” or “utility” scenarios (and use case) DESIGN During the design pass we focus on defining and detailing the steps for all of the currently identified scenarios.
  21. 21. STEP 5: IDENTIFY AND LIST STEPS Detailed description of the steps needed to complete a Scenario. The user’s progress through each scenario is modeled as a series of steps. As we develop all the scenarios for each use case in detail we may find that we need to return to some of them to add, subtract, or change the order of steps. It is also possible for a particular step in one use case to call or invoke another use case.
  22. 22. DESIGN DISCOVERING /SCOPING During the discovery/scoping pass we create a preliminary list of steps for each scenario. One technique for validating these steps is to do a “walkthrough” of each scenario. ANALYSIS During the analysis pass we focus on defining and detailing the interaction between a user and the system. We recapture the sequence of user actions and system responses that together comprise the steps of the Use Case. During the design pass we focus on designing the functional interface prototypes and completing the Robustness Analysis for each step. T his is the activity of analyzing the narrative text of use case and identifying a first-guess set of objects that will participate in each USE CASE. 1.Boundary Object 2.Entity Object 3.Control Object
  23. 23. STEP 6: IDENTIFY AND CLASSES/OBJECTS Detailed description AND/OR MODELS OF THE DESIGN AND IMPLEMENTATION OF THE METHODS AND PROPERTIES NEEDED TO COMPLETE A STEP. Can be organized into Interface, Controller, and Entity Classes using diagramming notation. In order to execute each step in a Use Case the System requires the use of Internal objects. From the description of the steps and the Robustness Analysis conducted in the design pass of Step 5 we can derive the properties and methods of those objects necessary to complete each individual step. List only the objects necessary for that step and the methods and properties of those objects that must be revealed for that one step to be completed.
  24. 24. DISCOVERING /SCOPING During the discovery/scoping pass we focus on defining and detailing the Domain Model. This is the collection of “objects” that represent the real-world things and concepts related to the problem domain that the system is being designed to solve. It is important to distinguish this type of “object-model” from other more formal UML based object models. ANALYSIS During the analysis pass we focus on defining and detailing the objects identified during the Robustness Analysis in the design phase of the previous step. We focus on those objects that are required to actually implement the Use Cases identified during discovery. At this stage we should identify and begin the process of detailing a collection of general “Business Objects”. These are objects that can be used throughout the system DESIGN During the design pass we focus on defining and detailing the actual classes and objects for which we will actually be writing and implementing in code. At this stage in the development effort the design work passes almost exclusively into the developer’s purview. The rest of the project team will be for testing and validating the delivered implementations or prototypes.
  25. 25. STEP 6: MANAGE WORK PRODUCTS. A work product is any planned, concrete result of the development process; either a final deliverable or an intermediate one. Examples includes source codes, a design object model, an analysis state model, a Use Case Model, and a project schedule. The set of all project work products constitute the project workbook. Work products all have common structure providing names, dates, description, issues, status, and the like, as well as structure that is work product-specific, for example, an object model diagram. A project workbook is a logical book with a predetermined structure containing all the work products associated w/ a project from requirements gathering and project management through analysis, design, implementation, and testing.