Review 1 Chapters 1 - 4

Systems definition example System: An interrelated set of components, with an identifiable boundary, working together for some purpose

General System Depiction Environment: Everything external to a system that interacts with the system.

General System Depiction Boundary: The line that marks the inside and outside of a system and that sets off the system from its environment.

General System Depiction Components: An irreducible part or aggregation of parts that make up a system, also called a subsystem..

General System Depiction Interrelationship: Dependence of one subsystem on one or more subsystems.

General System Depiction Input: Whatever a system takes from its environment in order to fulfill its purpose.

General System Depiction Output: Whatever a system returns to its environment in order to fulfill its purpose.

General System Depiction Interfaces: Point of contact where a system meets its environment or where subsystems meet each other.

Information Systems Defined An information system is a well-coordinated collection of resources that gather and transform data into information products and services that help the enterprise perform its designed functions An information system hierarchy associates different classifications of information systems with different audiences 10

11 Information System Hierarchy

The Systems Development Life Cycle 12 The systems development life cycle (SDLC) consists of five major phases: Analysis Design Development Implementation Maintenance

The Circular SDLC 13

Information System Components 14 There are six major information system components: People Procedures Software Hardware Networks Data Reference Figure 1-7: Information System Components

The Role of the Analyst 15 An agent of change A problem-solving strategist A group facilitator Four Sets of Analytical Skills –Systems Thinking –Organizational Knowledge –Problem Identification –Problem Analyzing and Solving

Basic Information-Processing Requirements Information must be: Relevant Accurate Timely Usable Affordable Adaptable Accessible 16 Reference Figure 2-1: Basic Information Processing Requirements

17 Figure 2-2: Symptom, Problem, Solution Summary (1/3) Basic RequirementSymptomProblemSolution Relevancy The system is not usedUser needs have changedInvolve the user in the redesign process Accuracy Reports are incomplete or erroneous The data input procedures are confusing or too demanding Simplify data capture through source document redesign or the use of input automation Timeliness Response time to user requests for information is increasing Input and/or output demands exceed the capabilities of the system Automate input, upgrade the output and disk storage devices and/or processor speed

18 Figure 2-2: Symptom, Problem, Solution Summary (2/3) Basic RequirementSymptomProblemSolution Usability Users are confused about how to use the system Outputs are inappropriately designed or they are poorly documented Redesign the outputs and/or improve the documentation, then retrain the users Affordability System costs are increasing more than user productivity One or more of the system elements are mismatched Evaluate the system mismatches to see if they can be minimized or commence a new SDLC

19 Figure 2-2: Symptom, Problem, Solution Summary (3/3) Basic RequirementSymptomProblemSolution Adaptability Users have abandoned some parts of the system The system is approaching functional obsolescence Upgrade to a more powerful computer platform to allow for software upgrades Accessibility Users must alter work patterns to retrieve information The information delivery system does not match work patterns Redesign the distribution and retrieval system to include online and on- demand access

Feasibility Analysis 20 Given the project objectives, cost constraints, and delivery date, is there a practical solution to the problem? Build strategies –Develop your own programs –Customize horizontal software Buy strategies –Purchase vertical software –Purchase a turnkey system

Feasibility Analysis 21 Vertical Software Advantages: Available immediately Verifiable track record Generally tailored to the enterprise Fixed price Disadvantages: Difficult to modify Must rely on long-distance assistance May not address all the user’s problems May include features the user doesn’t need Reference Figure 2-6: Advantages and Disadvantages of Vertical Software

Feasibility Analysis 22 The project contract consists of: 1.Problem Summary 2.Scope 3.Constraints 4.Objectives Reference Figure 2-7: The Initial Project Contract

Process Modeling Graphically represent the processes that capture, manipulate, store and distribute data between a system and its environment and among system components Data flow diagrams (DFD) –Graphically illustrate movement of data between external entities and the processes and data stores within a system Modeling a system’s process –Utilize information gathered during requirements determination –Structure of the data is also modeled in addition to the processes

Process Modeling Deliverables and Outcomes –Set of coherent, interrelated data flow diagrams –Context data flow diagram (DFD) Scope of system –DFDs of current system Enables analysts to understand current system –DFDs of new logical system Technology independent Show data flows, structure and functional requirements of new system –Project dictionary and CASE repository

Symbol Standards Activity or function – verb Collection of data – noun External entity – noun Logical “collection” of information in motion - noun

Context DFD - Food Ordering System

Level 0 DFD

Level 0 Diagram ‘Decomposition’ of Context Diagram Represents the major functions of a system Answers question – “What does the system fundamentally do”? Highest level of detail Each process is numbered ‘n’ or ‘n.0’ May show data stores

Continuing the Functional Decomposition

Continue the Functional Decomposition Further ‘Decompose’ each process: –Level 1 to Level 2 –Level 2 to Level 3 etc Decompose Level 0 Process 1.0, number Level 1 Processes as 1.1, 1.2, 1.3, 1.4 etc. Decompose Level 1 Process 1.1, number Level 2 Processes as 1.1.1, 1.1.2, 1.1.3, etc. No fixed number of processes at each level Goal is to make the diagram readable and meaningful

Data Flow Diagramming Mechanics Data Flow –Depicts data that are in motion and moving as a unit from one place to another in the system. –Drawn as an arrow –Select a meaningful name to represent the data Data Store –Depicts data at rest –May represent data in File folder Computer-based file Notebook –The name of the store as well as the number are recorded in between lines

Data Flow Diagramming Mechanics Process –Depicts work or action performed on data so that they are transformed, stored or distributed –Number of process as well as name are recorded Source/Sink –Depicts the origin and/or destination of the data –Sometimes referred to as an external entity –Drawn as a square symbol –Name states what the external agent is –Because they are external, many characteristics are not of interest to us

Data Flow Diagramming Definitions Context Diagram –A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system Level-O Diagram –A data flow diagram (DFD) that represents a system’s major processes, data flows and data stores at a high level of detail

Decomposition of DFDs Functional decomposition –Act of going from one single system to many component processes –Repetitive procedure –Lowest level is called a primitive DFD Level-N Diagrams –A DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram

Four Different Types of DFDS Current Physical –Process label includes an identification of the technology (people or systems) used to process the data –Data flows and data stores are labeled with the actual name of the physical media on which data flow or in which data are stored New Physical –Represents the physical implementation of the new system

Four Different Types of DFDS Current Logical –Physical aspects of system are removed as much as possible –Current system is reduced to data and processes that transform them New Logical –Includes additional functions –Obsolete functions are removed –Inefficient data flows are reorganized

Guidelines for Drawing DFDs Completeness –DFD must include all components necessary for system –Each component must be fully described in the project dictionary or CASE repository Consistency –The extent to which information contained on one level of a set of nested DFDs is also included on other levels

Guidelines for Drawing DFDs Timing –Time is not represented well on DFDs –Best to draw DFDs as if the system has never started and will never stop. Iterative Development –Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled

Guidelines for Drawing DFDs Primitive DFDs –Lowest logical level of decomposition –Decision has to be made when to stop decomposition

Guidelines for Drawing DFDs Rules for stopping decomposition –When each process has been reduced to a single decision, calculation or database operation –When each data store represents data about a single entity –When the system user does not care to see any more detail

Guidelines for Drawing DFDs Rules for stopping decomposition (continued) –When every data flow does not need to be split further to show that data are handled in various ways –When you believe that you have shown each business form or transaction, on-line display and report as a single data flow –When you believe that there is a separate process for each choice on all lowest-level menu options

Using DFDs as Analysis Tools Gap Analysis –The process of discovering discrepancies between two or more sets of data flow diagrams or discrepancies within a single DFD Inefficiencies in a system can often be identified through DFDs

Data Fundamentals Data Definition and Structure: Data is defined by three attributes: name, size, and type –Data names provide unique and descriptive labels –Data size determines the amount of space required to store the data –Data type specifies how the computer stores the data and restricts how the data can be used Data elements are organized into structures –a record is a collection of related data elements or fields –a data file is a collection of related records

File Processing Fundamentals Data File Types: One way to classify files is to consider how file content correlates to events or activities within the enterprise –A master files is a collection of data that represents an identifiable person or thing –A transaction file is a collection of data that represents a particular event or activity of the enterprise

File Processing Fundamentals Database Structure: A relational database is a collection of data files that are tied together by common fields The records in each data file are distinguished from one another by key fields A key field may contain a unique value, known as a primary key value.

Entity Relationship Diagrams The entity-relationship diagram (ERD) presents the data model The data stores of the DFD become the entities of the ERD Entities are related to one another when they share a common field Cardinality is the term used to describe the nature of the entity relationship, which may be: –one-to-one –one-to-many –many-to-many

Three Normal Forms Formal database design theory outlines a process that ensures file efficiency, referred to as normalcy. First normal (1NF) eliminates repeating groups Second normal form (2NF) requires every field to be dependent on or determined by the key field Third normal form (3NF) requires that all of the dependencies be contained within the file