The Systems Development Environment

The Systems Development Environment
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 1 The Systems Development Environment 1.1 1

Learning Objectives Define information systems analysis and design
Discuss the modern approach to systems analysis and design Describe the organizational roles involved in information systems development Describe different types of information systems: Describe the information systems development life cycle (SDLC) Discuss alternatives to the systems development life cycle Discuss the role of computer-aided software engineering (CASE) tools in systems development 1.2 2

Introduction Information Systems Analysis and Design
Complex process whereby computer-based information systems are developed and maintained Main goal is to improve employee efficiency by applying software solutions to key business tasks A structured approach must be used in order to ensure success Application Software Result of systems analysis and design Designed to support specific organizational functions or processes Systems Analyst performs analysis and design based upon: Understanding of organization’s objectives, structure and processes Knowledge of how to exploit information technology for advantage 1.4 3

Software Engineering Process
A process used to create an information system Consists of: Methodologies A sequence of step-by-step approaches that help develop the information system Techniques Processes that the analyst follows to ensure thorough, complete and comprehensive analysis and design Tools Computer programs that aid in applying techniques 1.7 4

Data and Processes Data Data Flows Processing Logic
Three key components of an information system Data Data Flows Processing Logic Data vs. Information Raw facts about people, objects, and events in an organization such as customer’s account number Information Data that have been processed and presented in a form that humans can understand 1.5 5

Data and Processes Data Data Flow Processing Logic
Understanding the source and kind of data a system uses is key to good system design Various techniques are used to describe data and the relationship among data Data Flow Groups of data that move and flow through the system from one place to another Include description of sources and destination for each data flow Processing Logic Describe steps in the transformation of data and events that trigger these steps 1.6 6

Approaches to Systems Development
Process-Oriented Approach Focus is on how and when data are moved and transformation of data in an information system Involves creating graphical representations such as data flow diagrams and charts Data are tracked from sources, through intermediate steps and to final destinations Natural structure of data is not specified Disadvantage: existence of several data files each locked within different applications. To change a single data element all files has to be updated 1.7 7

Approaches to Systems Development
Data-Oriented Approach Depicts ideal organization of data, independent of where and how data are used Data model describes kinds of data and business relationships among the data Business rules depict how organization captures and processes the data 1.8 8

Databases and Application Independence
Shared collection of logically related data Organized to facilitate capture, storage and retrieval by multiple users in an organization Centrally managed Designed around subjects Customers Suppliers Application Independence Separation of data and definition of data from applications that use these data 1.9 9

Organizational Responsibilities in Systems Development
Systems development is a team effort Systems Analysts work in a team Project Based Includes IS Manager Programmers Users Other specialists Characteristics of Successful Teams Diversity of backgrounds Tolerance of diversity Clear and complete communication Trust Mutual Respect Reward structure that promotes shared responsibility 1.10 10

IS Manager May have a direct role in systems development if the organization is small Typically involved in allocating resources to and overseeing system development projects. May prescribe what methodologies, techniques and tools to be used Systems Analyst Key individuals in the systems development process 11

Skills of a Successful Systems Analyst Analytical Understanding of organizations Problem solving skills System thinking Ability to see organizations and information systems as systems Technical Understanding of potential and limitations of technology Management Ability to manage projects, resources, risk and change Interpersonal Effective written and oral communication skills 1.12 12

Programmers Convert specifications into instructions that the computer understands Write program documentation and programs for testing systems Business Managers Have power to fund projects and allocate resources Set general requirements and constraints for projects 1.13 13

Other IS Managers / Technicians Database Administrator Involved in design, development and maintenance of databases Network and telecommunications experts Develop systems involving data and/or voice communications Human Factors Specialists Involved in training users and writing documentation Internal Auditors Ensure that required controls are built into the system 1.14 14

Types of Information Systems and Systems Development
Transaction Processing Systems (TPS) Automate handling of data about business activities (transactions) Management Information Systems (MIS) Converts raw data from transaction processing system into meaningful form Decision Support Systems (DSS) Composed of database designed to help decision makers Provides interactive environment for decision makers to manipulate data and models Expert Systems (ES) Codifies and manipulate knowledge instead of information Users communicate with an ES through interactive dialogue 1.15 15

Systems Development Life Cycle
System Development Methodology Standard process followed in an organization Consists of: Analysis Design Implementation Maintenance of information systems 1.16 16

Systems Development Life Cycle (SDLC)
SDLC – traditional methodology used to develop, maintain, and replace information systems Consists of six phases: Project Identification and Selection Project Initiation and Planning Analysis Design Implementation Maintenance 1.17 17

Phases are not necessarily sequential Each phase has a specific outcome and deliverable It is possible to complete some activities in one phase in parallel with some activities of another phase Sometimes life cycle is iterative – phases are repeated as required until acceptable system is found Sometimes life cycle is spiral – constantly cycle through the phases at different levels Individual companies use customized life cycles 1.18 18

Phases of the Systems Development Life Cycle
Project Identification and Selection Two Main Activities Identify and analyze organizations information system needs Prioritization and translation of need into a development schedule Helps organization to determine whether or not resources should be dedicated to a project. Project Initiation and Planning Two Activities Formal preliminary investigation of the problem at hand Presentation of reasons why system should or should not be developed by the organization Determining scope of the proposed system 1.19 19

Analysis Study of current procedures and information systems Sub phases Determine requirements Study current system Structure requirements and eliminate redundancies Generate alternative designs Compare alternatives Recommend best alternative 1.20 20

Design – convert the description into logical and then physical system specifications Logical Design Concentrates on business aspects of the system Independent of any specific hardware or software platform Physical Design Logical specifications are transformed into technical specifications 1.21 21

Implementation Information system is Coded – programmers write programs Tested – programmers and analysts test individual programs and entire system to find errors and correct Installed – application software is installed on hardware Supported – documentation and training programs are provided Maintenance Information system is systematically repaired and improved depending on organization’s needs over time Programmers modify the system to reflect changing business conditions It is a repetition of other life cycle phases and is not a separate phase 1.22 22

Approaches to Development
Prototyping Designing and Building a scaled-down working version of the system with any computer language (4GLs) or development tools (CASE) Advantages: Users are involved in design Captures requirements in concrete form Rapid Application Development (RAD) Utilizes prototyping to delay producing system design until after user requirements are clear 1.23 23

Approaches to Development
Joint Application Design (JAD) Users, Managers and Analysts work together for several days System requirements are reviewed Structured meetings Computer-aided software engineering (CASE) tools Facilitate creation of a central repository for system descriptions and specifications 1.24 24

Summary Information systems analysis and design
Process of developing and maintaining an information system Modern approach to systems analysis Process-Oriented Data-Oriented Four types of information systems Transaction Processing (TPS) Management Information Systems (MIS) Decision Support (DSS) Expert Systems (ES) 1.25 25

Summary Systems Development Life Cycle (SDLC)
Project Identification and Selection Project Initiation and Planning Analysis Design Implementation Maintenance Alternatives to Systems Development Life Cycle Prototyping Rapid Application Development (RAD) Joint Application Design (JAD) Computer-aided software engineering (CASE) tools 1.26 26

Succeeding as a Systems Analyst
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 2 Succeeding as a Systems Analyst 2.1 27

Learning Objectives Discuss the analytical skills, including systems thinking, needed for a systems analyst to be successful Describe the technical skills required of a systems analyst Discuss the management skills required of a systems analyst Identify the interpersonal skills required of a systems analyst Describe the systems analysis profession 2.28 28

Relationship between systems analyst’s skills and the SDLC cycle

Analytical Skills for Systems Analysis
Four Sets of Analytical Skills Systems Thinking Organizational Knowledge Problem Identification Problem Analyzing and Solving Systems Thinking System A system is an interrelated set of components, with an identifiable boundary, working together for a purpose A system has nine characteristics A system exists within an environment A boundary separates a system from its environment 2.30 30

Systems Thinking Characteristics of a System Components
An irreducible part or aggregation of parts that make up a system, also called a subsystem Interrelated Components Dependence of one subsystem on one or more subsystems A Boundary The line that marks the inside and outside of a system and that separates the system from its environment A Purpose The overall goal or function of a system An Environment Everything outside the system’s boundary that interacts with the system 2.31 31

Systems Thinking Interfaces Input Output Constraints
Point of contact at which the system meets its environment or where subsystems meet each other Input Whatever a system takes from its environment in order to fulfill its purpose Output Whatever a system returns to its environment in order to fulfill its purpose Constraints Limits to what it can do and how it can achieve its purpose within an environment (capacity, speed or capabilities)

Systems Thinking Important System Concepts
Open Systems Interact freely with their environments, taking in input and returning output As environment changes, systems much adapt to changes or suffer consequences Closed Systems Does not interact with environments Adaptability are not issues for closed systems Business Information Systems are open Systems

Systems Thinking Important System Concepts (Continued) Decomposition
The process of breaking down a system into smaller components which can be further broken down Allows the systems analyst to: Break a system into small, manageable subsystems Focus on one area at a time Concentrate on component relating to one group of users Build different components at independent times 2.35 35

Systems Thinking Important System Concepts (Continued) Modularity
Process of dividing a system into modules of a relatively uniform size Direct result of decomposition Modules simplify system design Coupling The extent to which the subsystems depend on each other Subsystems should be as independent as possible else failure of one subsystem fails the entire system. Cohesion Extent to which a system or a subsystem performs a single function 2.36 36

Systems Thinking Important System Concepts (Continued)
Logical System Description Portrays the purpose and function of the system Does not tie the description to a specific physical implementation Physical System Description Focuses on how the system will be materially constructed 2.37 37

Systems Thinking Benefits Able to identify something as a system
Recognizing each of the system’s characteristics Identifying boundaries Relevant inputs Identification of a system leads to abstraction From abstraction you can think about essential characteristics of specific system Abstraction allows analyst to gain insights into specific system, to question assumptions, provide documentation and manipulate the system without disrupting the real situation 2.38 38

Systems Thinking Applying Systems Thinking to Information Systems
Information systems are subsystems in larger organizational systems Taking input from, and returning output to, their organizational environments Data flow diagrams represent information systems as systems (clearly illustrate) Inputs Outputs System boundaries Environment Subsystems Interrelationships 2.39 39

Organizational Knowledge
Understanding of how organizations work Knowledge of specific functions and procedures of organization and department How work officially gets done How departments operates, its purpose, its relationships with other departments, its relationships with customers and suppliers Internal policies Competitive and Regulatory Environment Organizational Strategies and Tactics 2.40 40

Problem Identification
Problem: Difference between an existing situation and a desired situation Problem solving: the process of finding a way to reduce differences Identification is process of defining differences Differences are defined by comparing the current situation to the output of a model that predicts what the output should be 2.41 41

Problem Analyzing and Solving
Must analyze the problem and determine how to solve it Four Phases Intelligence All relevant information is collected Design Alternatives are formulated Choice Best alternative solution is chosen Implementation Solution is put into practice 2.42 42

Technical Skills for Systems Analysis
Constant re-education is necessary as technology changes rapidly Activities to keep skills up-to-date Trade publications Professional societies Attend classes or teach at a local college Attend courses sponsored by organization Conferences and trade shows Browse Websites Participate in new groups and conferences 2.43 43

Technical Skills for Systems Analysis
Understanding of a wide variety of technologies is required (requires continuous learning) Microcomputers, workstations, minicomputers and mainframe computers Programming languages Operating systems Database and file management systems Data communication standards Systems development tools and environments Web development languages and tools Decision support system generators 2.44 44

Management Skills for Systems Analysis
Know how to manage your work and use organizational resources in the most productive way Four categories Resource Management Project Management Risk Management Change Management 2.45 45

Resource Management Systems analyst needs to know how to get the most out of the resources of an organization, including team members Includes the following capabilities Predicting resource usage Tracking resource consumption Effective use of resources Evaluation of resource quality Securing resources from abusive use Relinquishing resources when no longer needed 2.46 46

Project Management Two Goals
Prevent projects from coming in late Prevent projects from going over budget Assists management in keeping track of project’s progress Consists of several steps Decomposing project into independent tasks Determining relationships between tasks Assigning resources and personnel to tasks Independent contractors Contracts Relationship managers (liaisons) 2.47 47

Risk Management Change Management
Ability to anticipate what might go wrong in a project Minimize risk and/or minimize damage that might result Placement of resources Prioritization of activities to achieve greatest gain Change Management Ability to assist people in making transition to new system Ability to deal with technical issues related to change Obsolescence Reusability 2.48 48

Interpersonal Skills for Systems Analysis
Mastery of interpersonal skills is paramount to success as a Systems Analyst Four types of skills: Communication skills Working alone and with a team Facilitating groups Managing expectations 2.49 49

Communication Skills Effective communication helps to establish and maintain good working relationships with clients and colleagues Clearly and Effectively communicate with others Three types used by Systems Analyst Interviewing and Listening Questionnaires Written and Oral Presentations Skills improve with experience 2.50 50

Interviewing and Listening
Means to gather information about a project Listening to answers is just as important as asking questions Effective listening leads to understanding of problem and generates additional questions Expensive and time-consuming Questionnaires Advantages: Less costly than interviews Results are less biased due to standardization Disadvantages Less effective than interviews due to lack of follow-up 2.51 51

Written and Oral Presentations
Used to document progress of project and communicate this to others Communication takes several forms: Meeting agenda Meeting minutes Interview summaries Project schedules and descriptions Memoranda requesting information Requests for proposals from vendors and contractors Oral presentations 2.52 52

Working Alone and with a Team
Working alone on aspects of project involves managing: Time Commitments Deadlines Team work involves establishing standards of cooperation and coordination Know when to trust judgment of others and when to question it Understand strengths and weakness of team members Table 2-2 presents characteristics of a high-performance team 2.53 53

Characteristics of High-Performance Team
Must have motivation and a vision

Managing Expectations
Facilitating Groups Involves guiding a group without being a part of the group Must work to keep the effort on track Useful skill for sessions such as Joint Application Development (JAD) Managing Expectations Managing expectations is directly related to successful system implementation Skills for successful expectation management Understanding of technology and workflows Ability to communicate a realistic picture of new system to users Effective education of management and users throughout systems development life cycle 2.55 55

Systems Analysis as a Profession
Standards have been established for education, training, certification and practice Standard ways of analyzing, designing, and implementing systems Society for Information Management Association of Information Technology Professionals Association for Computing Machinery (ACM) Certified Computing Professional (CCP) exam Several aspects: Standards of Practice Ethics Career Paths 2.56 56

Standards of Practice Endorsed Development Methodology
Specific procedures and techniques to be used during development process Promote consistency and reliability across all of an organization’s development projects Approved Development Platforms Organizations standardize around a specific platform, sometimes tied to development methodology Standardization of Roles Roles are becoming better defined across organizations Development of a Common Language Common programming languages Common modeling languages, such as Unified Modeling Language (UML) 2.57 57

Ethics Professional Ethics ACM Code of Ethics – See Figure 2-10
Business Ethics Stockholder approach Any action taken by a business is acceptable as long as it is legal and maximizes stockholder profit Stakeholder approach Any action that violates rights of stakeholder must be rejected Social Contract approach Any action that is deceptive, can dehumanize employees or that could discriminate is rejected 2.58 58

Career Paths Consulting Information Systems within a large corporation
Software vendors Other opportunities outside of systems analysis 2.59 59

Summary Skills of Successful Systems Analyst Analytical Technical
Systems Thinking Technical Change over time Programming Languages Operating Systems Database Management Systems Data Communications Systems Development Techniques 2.60 60

Summary Skills of a Successful Systems Analyst (Continued) Management
Resources Projects Risk Change 2.61 61

Summary Skills of a Successful Systems Analyst (Continued)
Interpersonal Interviews and Questionnaires Written and Oral Presentations Facilitating Groups Systems Analysis as a Career Standards of Practice Ethics Career Paths 2.62 62

Managing the Information Systems Project
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 3 Managing the Information Systems Project 3.1 Copyright 2002 Prentice-Hall, Inc. 63

Learning Objectives Explain the process of managing an information systems project Discuss skills required to be an effective project manager Describe skills and activities of a project manager during project initiation, planning, execution and closedown Explain Gantt and Pert charts Review commercial project management software packages 3.2 64

Focus of project management To ensure that information system projects meet customer expectations Delivered in a timely manner Meet time constraints and requirements Project Manager is a Systems Analyst responsible for Project: Initiation Planning Execution Closing down 3.65 65

Project Manager skills include: Management Leadership Technical Problem solving Conflict management Customer relations Team management Risk and change management 66

Project Management Process
Planned undertaking of related activities to reach an objective that has a beginning and an end Deliverable An end product in a phase of the SDLC Feasibility Study Determines if the information system makes sense for the organization from an economic and operational standpoint The study takes place before the system is constructed Project Management Process involves Four Phases Initiation Planning Execution Closing down 3.67 67

Initiating the Project
Project Initiation: The first phase of the project management process in which activities are performed to assess the size, scope, and complexity of the project and to establish procedures to support later project activities Establish project initiation team Establish relationship with customer Establish project initiation plan Establish management procedures Establish project management environment and workbook Project workbook: An on-line or hard-copy repository for all project correspondence, inputs, outputs, deliverables, procedures, and standards used by all team members useful for project audits, orientation of new team members and performing post project reviews. 3.68 68

Planning the Project Project Planning – defining clear, discrete activities Requires making assumptions about availability of resources Short-term activities are easier to plan Describe project scope, alternatives and feasibility Scope and Feasibility Understand the project What problem is addressed What results are to be achieved Measures of success Completion criteria Divide the project into manageable tasks Work breakdown structure: The process of dividing the project into manageable tasks and logically ordering them to ensure a smooth evolution between tasks Some tasks may be performed in parallel whereas others must follow one another sequentially. 3.69 69

Planning the Project How to define tasks? A task Has a known method, can be done by one-person or well-defined group, has accepted predecessor and successor steps, is measurable so that percent complete can be determined Divide the project into manageable tasks Gantt chart: A graphical representing of a project showing each task as a horizontal bar whose length is proportional to its time for completion. Gantt charts do not show how tasks must be ordered but simply shows when an activity must begin and end. Different colors, shades, shapes can be used to highlight each kind of task Estimate resources and create a resource plan Estimate resource requirements for each project activity Resource plan helps assemble and deploy resources in most effective way People are most important and expensive part of resource planning Assign tasks to people that suit their skills and allows to learn new skills 3.70 70

Planning the Project Develop a preliminary schedule
Assign time estimates to each activity in work breakdown structure time estimates allows creating target starting and ending dates for project Utilize Gantt and PERT charts Program Evaluation Review Technique (PERT) Chart A diagram that shows project tasks and their relationships Ordering of tasks is shown by connecting tasks with its predecessor and successor tasks Only individual tasks are drawn and no summary tasks

Planning the Project Develop a communication plan
Outline communication procedures among customers, team members and management Communication plan includes when and how written and oral reports will be provided by the team, how team members will coordinate work, what messages will be sent. Determine project standards and procedures Specify how deliverables are tested and produced Identify and assess risk Identify sources of risk Estimate consequences of risk Create a preliminary budget Outline planned expenses and revenues of the project to study cost-benefit analysis 3.72 72

Planning the Project Develop a statement of work
Occurs near the end of the project planning phase Developed primarily for the customer Outlines work that will be done and describe what the project will deliver and duration Set a Baseline Project Plan Estimate of project’s tasks and resource requirements that guides the next project phase – execution. 3.73 73

Executing the Project Project Execution – plans created in prior phases are put into action Occurs during analysis, design, implementation phases of SDLC Execute Baseline Project Plan Acquire and assign resources Train new team members Keep project on schedule - as tasks are completed, mark them as completed by percent Monitor project progress Adjust resources, budget and/or activities if project gets ahead or behind schedule Can result in modifications to current plan 3.74 74

Executing the Project Manage changes to Baseline Project Plan
Slipped completion dates Changes in personnel New activities found later Bungled activities to be redone Maintain project workbook to maintain complete records of all project events Communicate project status with entire project team 3.75 75

Closing Down the Project
Project closedown – bring project to an end Occurs after implementation phase of SDLC Termination Types of termination Natural Requirements have been met – project is completed successfully Unnatural Project stopped before completion – due to running out of time or money Documentation Personnel Appraisal – job and assignment changes, job termination, praising team members 3.76 76

Closing Down the Project
Conduct post-project reviews Determine strengths and weaknesses of: Project deliverables Project management process Development process Close customer contract 3.77 77

Representing and Scheduling Project Plans
Gantt Charts Useful for depicting simple projects or parts of large projects Show start and completion dates for individual tasks PERT Charts Show order of activities Comparison of Gantt and PERT Charts Gantt Visually shows duration of tasks Visually shows time overlap between tasks Visually shows slack time PERT Visually shows dependencies between tasks Visually shows which tasks can be done in parallel Shows slack time by data in rectangles 3.78 78

Figure 3-16 Graphical diagrams that depict project plans (a) A Gantt Chart (b) A PERT chart
3.79 79

Project Management Software
Many systems are available Three activities required to use: Establish project start or end date Enter tasks and assign task relationships Select scheduling method to review project reports 3.80 80

Summary Skills of an effective project manager
Activities of project manager Initiation Planning Execution Closedown Gantt and PERT Charts Commercial Project Management Software 3.81 81

Automated Tools for Systems Development
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 4 Automated Tools for Systems Development 4.82 Copyright 2002 Prentice-Hall, Inc. 82

Learning Objectives Identify the trade-offs when using CASE
Describe organizational forces for and against adoption of CASE tools Describe the role of CASE tools and how they are used to support the SDLC List and describe the typical components of a comprehensive CASE environment Describe the general functions of upper CASE tools, lower CASE tools, cross life-cycle CASE tools and the CASE repository Describe visual and emerging development tools and how they are being used 4.83 83

Introduction Computer-Aided Software Engineering (CASE)
Lack of consistency in technique and methodology made development of systems difficult – error-ridden, over budget, late Goal – To develop common techniques, standard methodologies, automated tools Computer-Aided Software Engineering (CASE) Automated software tools used by systems analysts to develop information systems Used to support or automate activities throughout the systems development life cycle (SDLC) Increase productivity Improve overall quality of systems 4.84 84

The Use of CASE in Organizations
Purpose of CASE is to facilitate a single design philosophy within an organization with many projects, systems, people. CASE tools runs on variety of mini and mainframe systems, recent advances made PC predominant CASE workstation. Objectives of CASE Improve quality of systems developed Increase speed of development and design Ease and improve testing process through automated checking Improve integration of development activities via common methodologies Improve quality and completeness of documentation Help standardize the development process Improve project management Simplify program maintenance Promote reusability of modules and documentation Improve software portability 4.85 85

CASE and System Quality
Majority of organizations adopt CASE to improve speed and quality of systems development projects Widespread deployment has been slower than expected Several factors that inhibit widespread deployment Cost Between $5,000 and $15,000 per year to provide CASE tools to one systems analyst Return on Investment Biggest benefits of CASE come in late stages of SDLC – testing, implementation and maintenance Long duration for early stages – planning, analysis, design – leads to frustration by managers and users Productivity Bottlenecks Inability of some tools to share information Difficulty in providing tools for all stages of SDLC 4.86 86

The Outlook for CASE Functionality is increasing Cost is decreasing
Expose CASE technology earlier in education and career Reverse Engineering Process of creating design specifications for a system or program module from program code and data definition Automated tools that read program source code as input and create graphical and textual representations of program design-level information such as program control structures, data structures, logical flow, and data flow Reengineering Similar to reverse engineering but includes analysis features Automated tools that reads program source code as input, perform an analysis of the program’s data and logic, and automatically or interactively alters an existing system to improve quality and/or performance 4.87 87

Components of CASE Upper CASE Lower CASE Cross life-cycle CASE
CASE tools designed to support the information planning and the project identification and selection, project initiation and planning, analysis and design phases of the systems development life cycle Lower CASE CASE tools designed to support the implementation and maintenance phases of the systems development life cycle Cross life-cycle CASE CASE tools designed to support activities that occur across multiple phases of the systems development life cycle Most CASE tools utilize a repository to store all diagrams, forms, models and report definitions 4.88 88

Components of CASE Types of CASE tools CASE tools also provides
Diagramming tools Computer display and report generators Analysis tools used to check for incomplete, inconsistent or incorrect specifications A central repository Documentation generators Code generators CASE tools also provides Security Features Version Control Import/Export Backup and Recovery 4.89 89

CASE versus Traditional Systems Development
Traditional approach does not offer support for integration of specification documents Often, documentation is done after coding is completed in traditional systems development Traditional approach often leads to out- of-date documentation 4.90 90

CASE versus Traditional Systems Development
CASE-Based Systems Development Emphasis on analysis and design Rapid interactive prototyping Automated code generation Automated documentation generation Automated design checking Maintain design specifications Traditional Systems Development Emphasis on coding and testing Paper-based specifications Manual coding of programs Manual documenting Intensive software testing Maintain code and documentation 4.91 91

CASE Diagramming Tools
Enable representation of a system and components visually Effective for representing process flows, data structures and program structures Several types of diagrams Data Flow Diagrams (DFD) (Figure 4-4) Functional Hierarchy Diagrams(Figure 4-5) Entity-Relationship Diagrams (Figure 4-6) 4.92 92

CASE Form and Report Generator Tools
CASE tools that support the creation of system forms and reports in order to prototype how systems will look and feel to users Two Purposes Create, modify and test prototypes of computer display forms and reports Identify which data items to display or collect for each form or report CASE Analysis Tools Enable automatic checking for incomplete, inconsistent or incorrect specifications in diagrams, forms and reports. Types of analyses vary depending on the organization’s development methodology and features of CASE environment 4.93 93

CASE Repository Integrated CASE (I-CASE)
Integration of various CASE tools and their data I-CASE tools use common terminology, notations and methods for system development across all tools All I-CASE tools have a common user interface Automated systems development environment that provides numerous tools to create diagrams, forms and reports Provides analysis, reporting and code generation facilities Seamlessly shares and integrates data across and between tools Repository is centralized database containing all diagrams, forms and report definitions, data structure, data definitions, process flow and logic Holds complete information needed to create, modify and evolve a software system from project initiation and planning to code generation and maintenance 4.94 94

CASE Repository Two Primary Segments Information Repository
Data Dictionary Combines information about an organization’s business information and its application portfolio Provides automated tools to manage and control access to repository Business Information Data stored in corporate databases Application Portfolio Application programs used to manage business 4.95 95

CASE Repository Data Dictionary
Computer software tool used to manage and control access to the information repository Contains all data definitions for all organizational applications Cross referencing Enables one description of a data item to be stored and accessed by all individuals Single definition for a data item is established and used Entries have a standard definition Element name and alias Textual description of the element List of related elements Element type and format Range of acceptable values Other information unique to the proper processing of this element 4.96 96

CASE Repository CASE Repository and the SDLC Additional Advantages
During project initiation and planning phase, all information related to the problem being solved is stored in the repository Problem domain, project resources, history and organizational context During analysis and design phases, store graphical diagrams and prototype forms and reports Data stored in repository are used for basis to generate code and documentation Additional Advantages Assistance with project management tasks Aids in software reusability The ability to design software modules in a manner so that they can be used again and again in different systems without significant modification 4.97 97

CASE Documentation Generator Tools CASE Code Generation Tools
Enable the easy production of both technical and user documentation Allow creation of master templates used to verify that documentation conforms to all stages of SDLC CASE Code Generation Tools Enable the automatic generation of program and database definition code directly from the design documents, diagrams, forms and reports stored in the repository 4.98 98

Visual and Emerging Development Tools
Object-Oriented Development Tools Object A chunk of program and data that is built to perform common functions within a system Easily reused Encapsulation Process of grouping data and instructions together Development environment includes pre-defined objects and facilitates reuse of code 4.99 99

Visual and Emerging Development Tools
Visual Development Tools Enable developers to quickly create user interfaces Popular tools include: Microsoft Visual Studio Delphi Powerbuilder ColdFusion 100

Summary Use of CASE in Organizations Categories of CASE Tools
Reverse Engineering Re-engineering Components of CASE Upper CASE Diagramming tools Form and report generators Analysis tools Lower CASE Code generators Cross Life-cycle CASE Project management tools Repository and Data Dictionary Visual and Emerging Development Tools 101

Identifying and Selecting Systems Development Projects
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 5 Identifying and Selecting Systems Development Projects Copyright 2002 Prentice-Hall, Inc. 102

Learning Objectives Describe the project identification and selection process Describe the corporate strategic planning and information systems planning process Explain the relationship between corporate strategic planning and information systems planning Describe how information systems planning can be used to assist in identifying and selecting systems development projects Analyze information systems planning matrices to determine affinity between information systems and IS projects and to forecast the impact of IS projects on business objectives Describe the three classes of Internet electronic commerce applications: Internet, Intranets and Extranets 103

Identifying and Selecting IS Development Projects
Sources of projects Management and business units – for replacing or extending an existing system to gain needed information or to provide new service to customers Managers who want to make a system more efficient or less costly or to move to new operating environment Formal planning groups – identifies projects for improvement to help organization objectives Project Identification and Selection consists of: Identifying potential development projects Classifying and ranking projects Selecting projects for development 104

Identifying Potential Development Projects
Projects are identified by Top management – either CEO of small or medium-sized organization or senior executives of large organizations Steering committee – composed of cross section of managers User departments – head or committee of requesting departments Development group or senior IS staff Top-Down Identification Senior management or steering committee Focus is on broader needs of organization Bottom-up Identification Functional manager, Business unit or IS development group Designed for a particular business need and don’t reflect overall goals of the organization 105

Identifying Potential Development Projects
Top Management Greater strategic focus, largest project size, longest project duration Steering Committee Cross-functional focus, greater organizational change, formal cost-benefit analysis, larger and riskier projects User Department Narrower non-strategic focus, faster development, fewer users and business functions Development group Fewer development delays, less concern on cost-benefit analysis

Classifying and Ranking IS Development Projects
Focuses on assessing the relative merit of potential projects Can be performed by top managers, steering committee, business units, or IS development groups Criteria for assigning merit may vary and one or more than one criteria may be used Value chain analysis is often used Method to analyze an organization’s activities for making products and/or services to determine where value is added and costs are incurred First understand each activity, function, and process where value is or should be added Next determine the costs within each of these areas. 107

Classifying and Ranking IS Development Projects
Value Chain Analysis Extent to which activities add value and costs when developing products and/or services Strategic Alignment Extent to which project is seen as helping the organization achieve its objectives and goals Potential Benefits Extent to which project is seen as improving profits, customer service and duration of these benefits Resource Availability Amount and type of resources the project requires and their availability Project Size/Duration Number of persons and length of time needed to complete project

Selecting IS Development Projects
Actual selection of projects for further development Process of considering short and long-term projects Projects most likely to achieve business objectives are selected Is very important and ongoing activity as business conditions change over time changing the importance of any single project Decision requires consideration of: Perceived and real needs Potential and ongoing projects Current organizational environment Existing and available resources Evaluation criteria 109

Selecting IS Development Projects
Outcomes Project Acceptance Project Rejection Delay Refocus End-User Development Proof of Concept 110

Identifying and Selecting IS Development Projects
Deliverables and Outcomes Primary Deliverable Schedule of specific IS development projects Outcomes Assurance that careful consideration was given to project selection Clear understanding of project’s relation to organizational objectives Incremental commitment A strategy in systems analysis and design in which the project is reviewed after each phase and continuation of project is re justified in each of these reviews 111

Corporate and Information Systems Planning
Need for planning Improperly planned projects result in systems that cannot be shared across an organization As business processes change, lack of integration will hamper strategy and business process changes Corporate Strategic Planning Process of developing and refining models of the current and future enterprise as well as a transition strategy Planning results in several outcomes Mission Statement Objective Statement Competitive Strategy 112

Corporate Strategic Planning Mission Statement A statement that makes it clear what business a company is in Objective Statement A series of statements that express an organization’s qualitative and quantitative goals for reaching a desired future position Objectives are critical success factors Competitive Strategy The method by which an organization attempts to achieve its mission and objectives 113

Information Systems Planning (ISP) An orderly means of assessing the information needs of an organization and defining the systems, databases and technologies that will best satisfy those needs Three key activities: Describe the Current Situation Describe the Target (or Future) Situation Develop a Transition Plan and Strategy 114

1. Describing the Current Situation Top-down Planning Generic methodology that attempts to gain a broad understanding of the information system needs of the entire organization Bottom-up Planning Generic methodology that identifies and defines IS development projects based upon solving operational business problems or taking advantage of some business opportunities 115

1. Describing the Current Situation (Continued) Planning team is chartered to model existing situation Identification of Organizational: Locations Units Functions Processes Data Information Systems 116

1. Describing the Current Situation (Continued) Matrices are developed to cross-reference units Location-to-Function Location-to-Unit Unit-to-Function Function-to-Objective Function-to-Process Function-to-Data Entity Process-to-Data Entity Process-to-Information System Data Entity-to-Information System Information System-to-Objective 117

2. Describing the Target Situation Update list of organizational locations, functions, etc. to reflect desired locations, functions, etc. Matrices are updated to reflect future states Planners focus on differences between current lists and matrices and future lists and matrices 3. Developing a Transition Strategy and Plans Broad, comprehensive document that looks at both short and long-term organizational development needs Consists of a series of projects 118

Electronic Commerce Applications
Development process for Internet projects is no different than other projects Special issues need to be taken into account Electronic Commerce (EC) Internet based communication designed to support business activities 119

Internet Development Internet Intranet Extranet
Worldwide network of networks used for electronic commerce Intranet Internet-based communication to support business activities within a single organization Extranet Internet-based communication to support business-to- business activities 120

Internet Development Electronic Data Interchange (EDI)
The use of telecommunications technologies to transfer business documents directly between organizations Internet vs. Intranet/Extranet Apps Intranet/Extranet – Developer knows how application will be run and used Internet – Developer faces various unknowns 121

Summary Project Identification and Selection
Identifying Potential Development Projects Classifying and Ranking Projects Selecting Projects for Development Top-down and Bottom-up identification process Corporate strategic planning Process of identifying the mission, objectives and strategies of an organization 122

Summary Information Systems Planning Electronic Commerce
Orderly means for assessing the information needs of an organization and defining the systems and databases that will best satisfy those needs Top-down process Electronic Commerce Internet Intranets Extranets Electronic Data Interchange 123

Initiating and Planning Systems Development Projects
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 6 Initiating and Planning Systems Development Projects Copyright 2002 Prentice-Hall, Inc. 124

Learning Objectives Describe steps involved in the project initiation and planning process Explain the need for and the contents of a Statement of Work and Baseline Project Plan List and describe various methods for accessing project feasibility Describe the differences between intangible and tangible costs and benefits and between recurring and one-time benefits and costs Detail various methods of cost/benefit analysis Describe the general rules for evaluating the technical risks associated with a systems development project Describe the activities and participant roles within a structured walkthrough 125

Initiating and Planning System Development Projects
Project Initiation Establishment of project team Development of relationship with customer Project Initiation Plan Establishment of Management Procedures Establishment of Project Workbook and Project Management Environment Project Planning Defining clear, discrete activities and the work needed to complete each activity 126

Initiating and Planning System Development Projects
Deliverables and Outcomes Baseline Project Plan (BPP) Scope Benefits Costs Risks Resources Statement of Work (SOW) Describes deliverables Outlines work needed to be performed 127

Assessing Project Feasibility
Six Categories Economic Technical Operational Schedule Legal and contractual Political 128

Assessing Economic Feasibility
Cost – Benefit Analysis Determine Benefits Tangible Benefits Can be measured easily Examples Cost reduction and avoidance Error reduction Increased flexibility Increased speed of activity Improved management planning and control Opening new markets and increasing sales opportunities 129

Intangible Benefits Cannot be measured easily Examples Increased employee morale Competitive necessity More timely information Promotion of organizational learning and understanding Determine Costs Tangible Costs Can easily be measured in dollars Example: Hardware Intangible Costs Cannot be easily measured in dollars Examples: Loss of customer goodwill Loss of employee morale 130

One-Time Costs Associated with project startup, initiation and development Includes System Development New hardware and software purchases User training Site preparation Data or system conversion 131

Recurring Costs Associated with ongoing use of the system Includes: Application software maintenance Incremental data storage expense New software and hardware releases Consumable supplies Incremental communications Time value of money (TVM) The process of comparing present cash outlays to future expected returns 132

Assessing Technical Feasibility
Assessment of the development organization’s ability to construct a proposed system Project risk can be assessed based upon: Project size Project structure Development group’s experience with the application User group’s experience with development projects and the application area 133

Assessing Other Project Feasibility Concerns
Operational Feasibility Assessment of how a proposed system solves business problems or takes advantage of opportunities Schedule Feasibility Assessment of time frame and project completion dates with respect to organization constraints for affecting change Legal and Contractual Feasibility Assessment of legal and contractual ramifications of new system Political Feasibility Assessment of key stakeholders in organization’s view toward proposed system 134

Building the Baseline Project Plan
Objectives Assures that customer and development group have a complete understanding of the proposed system and requirements Provides sponsoring organization with a clear idea of scope, benefits and duration of project Four Sections Introduction System Description Feasibility Assessment Management Issues 135

Introduction Brief overview Recommended course of action Project scope defined Units affected Who inside and outside the organization would be involved Interaction with other systems Range of system capabilities System Description Outline of possible alternative solutions Narrative format 136

Feasibility Assessment Project costs and benefits Technical difficulties High-level project schedules Management Issues Outlines concerns that management may have about the project Team composition Communication plan Objectives Assure conformity to organizational standards All parties agree to continue with project 137

Reviewing the Baseline Project Plan
Walkthrough Peer group review Participants Coordinator Presenter User Secretary Standards Bearer Maintenance Oracle Activities Walkthrough Review Form Individuals polled Walkthrough Action List Advantages Assures that review occurs during project 138

Summary Feasibility Benefits Costs Economic Operational Technical
Schedule Legal Contractual Political Benefits Tangible vs. Intangible Costs One-time vs. Recurring 139

Determining System Requirements
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining System Requirements Copyright 2002 Prentice-Hall, Inc. 140

Learning Objectives Describe options for designing and conducting interviews and develop a plan for conducting an interview to determine system requirements Design, distribute, and analyze questionnaires to determine system requirements Explain advantages and pitfalls of observing workers and analyzing business documents to determine requirements Explain how computing can provide support for requirements determination Learn about Joint Application Design (JAD) Use prototyping during requirements determination Select the appropriate methods to elicit system requirements Apply requirements determination to Internet applications 141

Performing Requirements Determination
System Analysis phase has three sub phases Requirements determination Requirements structuring Generating alternative design and selecting best one Gather information on what system should do from many sources Users Reports Forms Procedures

Performing Requirements Determination
Characteristics for gathering requirements Impertinence Question everything Impartiality Find the best organizational solution Relaxation of constraints assuming anything is possible Attention to detail Reframing View the organization in new ways 143

Deliverables and Outcomes
Types of deliverables: Information collected from users interview transcripts, questionnaire responses, notes of observation Existing written information sample business forms and reports, procedure manuals, training manuals Computer-based information CASE repository contents and reports of existing system Understanding of organizational components Business objective Information people needs Data handled and when, how and who moves data Rules of data processing Key events 144

Traditional Methods for Determining Requirements
Individually interview people who knows current system Survey people via questionnaires Interview group of people with different needs Observe workers at selected times to see how data is handled Study business documents Interviewing and Listening Guidelines for Effective Interviewing Prepare interviewee: set up appointment time and duration convenient for interviewee Prepare checklist, agenda and questions: to know the sequence and duration of questions to ask Listen carefully and take notes Review notes within 2 days of interview Be neutral and seek diverse views 145

Choosing Interview Questions Open-Ended questions No pre-specified answers like what you think about …? Advantages: give interviewees more sense of involvement; put interviewee at ease as they respond in their own words Disadvantages: takes long time to answer; difficult to summarize Close-Ended questions Respondent is asked to choose from a set of specified responses Examples: True or False, Multiple choice, rating a response Advantages: takes less time to answer and more topics covered Disadvantages: useful information may be overlooked Additional Guidelines Do not phrase questions in ways that imply a wrong or right answer Listen very carefully to what is being said – take notes or record Type up notes within 48 hours Do not set expectations about the new system 146

Administering Questionnaires Questionnaires Vs Interviews Interviews are very expensive and time-consuming Questionnaires are not expensive and can gather information from many people simultaneously in a relatively short time Interviews can have limited number of questions and limited number of people contacted Questionnaires give less depth of understanding as they provide no direct means to ask follow-up questions Interviews provide the opportunity to judge the truthfulness of responses by the words or voice tone or the body language of the respondent Questionnaires do not provide the opportunity to judge the accuracy of responses 147

Choosing Questionnaire respondents – if more people to survey decide which set of people to send questionnaire to or which questionnaire to send to which group of people Convenient: people at a local site or willing to get surveyed Random sample: select any person from a list Purposeful sample: select people who satisfy certain criteria Stratified sample: select random set from each of many categories Designing Questionnaires Questionnaires are most useful when used for specific purpose and not for general information gathering Questionnaires typically include closed-ended questions Questionnaires must be extremely clear in meaning and logical in sequence as any doubts cannot be cleared How often(?) do you backup your computer files (C: or hard disk)? a) frequently b) sometimes c) hardly at all d) never 148

Interviewing Groups – interview several key people at once by several analysts, one asks questions other takes notes Advantages More effective use of time Enables people to hear opinions of others and to agree or disagree Disadvantages Difficulty in scheduling convenient time as many people are involved Nominal Group Technique Facilitated process to support idea generation by groups Individuals work alone to generate ideas which are pooled under guidance of a trained facilitator which are then discussed and then number of ideas are reduced and carry forward Directly Observing Users People cannot always be trusted to reliably report their own actions Often difficult to obtain unbiased data People often work differently when being observed 149

Analyzing Procedures and Other Documents
Types of information to be discovered in a document: Problems with existing system Opportunity to meet new need Organizational direction Titles and names of key individuals Values of organization Special information processing circumstances Reasons for current system design Rules for processing data 150

Analyzing Procedures and Other Documents
Four types of useful documents Written work procedure for an individual or a work group Describes how a job is performed Includes data and information used and created in the process of performing the job or task Formal systems: official way a system works as described in the organizational documentation. Informal system: the way a system actually works Business form Explicitly indicate what data flow in or out of a system and which are necessary for the system to work Report generated by current systems Enables the analyst to work backwards from the report to the data that generated it – company’s performance in past years Description of current information system If the current system is computer based 151

Modern Methods for Determining Requirements
Joint Application Design (JAD) Similar to group interview as it brings together key users, managers and systems analysts Purpose: collect system requirements simultaneously from key people Particular structure of roles and agenda is followed and analysts control the sequence of questions answered by users Conducted off-site to keep participants away from distractions may last from four hours to an entire week and may consist of many weeks Prototyping Repetitive process Rudimentary version of system is built Replaces or augments SDLC Goal: to develop concrete specifications for ultimate system 152

Joint Application Design (JAD)
Participants Session Leader – organizes and runs the JAD Users – key users of the current system Managers of the workgroups who use the current system Sponsor – needed to cover expenses Systems Analysts – to learn from users and managers Scribe – takes notes IS Staff – other IS staff like programmers, database analysts JAD sessions are usually held in special-purpose rooms where participants sit in a horse-shoe shaped tables. rooms have whiteboards, audio-visual tools like overhead projectors, flip charts, transparencies 153

Joint Application Design (JAD)
End Result Documentation detailing existing system Features of proposed system CASE Tools During JAD Upper CASE tools are used Enables analysts to enter system models directly into CASE during the JAD session Screen designs and prototyping can be done during JAD and shown to users 154

Prototyping Quickly converts requirements to working version of system
Once the user sees requirements converted to system, will ask for modifications or will generate additional requests Most useful when: User requests are not clear Few users are involved in the system Designs are complex and require concrete form History of communication problems between analysts and users Tools are readily available to build prototype Drawbacks Tendency to avoid formal documentation Difficult to adapt to more general user audience Sharing data with other systems is often not considered Systems Development Life Cycle (SDLC) checks are often bypassed 155

Summary Interviews Questionnaires Other means of gather requirements
Open-ended and close-ended questions Preparation is key Questionnaires Must be carefully designed Can contain close-ended as well as open-ended questions Other means of gather requirements Observing workers Analyzing business documents Joint Application Design (JAD) Prototyping 156

Structuring System Requirements:
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 8 Structuring System Requirements: Process Modeling Copyright 2002 Prentice-Hall, Inc. 157

Learning Objectives Understand the logical modeling of processes through studying data flow diagrams How to draw data flow diagrams using rules and guidelines How to decompose data flow diagrams into lower-level diagrams Balancing of data flow diagrams Explain the differences among four types of DFDs: current physical, current logical, new physical and new logical Discuss the use of data flow diagrams as analysis tools Compare and contrast data flow diagrams with Oracle’s process modeling tool and with functional hierarchy diagrams Discuss process modeling for Internet applications 8.2 158

Process Modeling Modeling a system’s process Data flow diagrams (DFD)
Process modeling involves graphically representing the functions, or processes that capture, manipulate, store and distribute data between a system and its environment and among system components Data flow diagrams (DFD) A common and traditional form of process modeling technique 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 Processing logic and timing of events in system are also modeled (chapter 9) Structure of the data is also modeled in addition to the processes (chapter 10) 159

Process Modeling Deliverables and Outcomes
Deliverables are simply stating what you learned during requirements determination Primary deliverables from process modeling are a set of coherent, interrelated data flow diagrams Context data flow diagram (DFD) Shows scope of system indicating which elements are inside and which are outside the system DFDs of current physical system Specify which people and technologies are used in which processes to move and transform data, accepting inputs and producing outputs DFDs of current logical system Showing what data processing functions are performed DFDs of new logical system Data movement, or flow, structure, and functional requirements of new system Project dictionary and CASE repository Entries of all objects included in all diagrams 160

Data Flow Diagramming Mechanics
DFD’s are not as good as flowcharts to depict details of physical systems Flowcharts are not very useful for depicting purely logical information flows Four symbols are used to represent both physical and logical information systems Definitions and Symbols Two different standard sets of DFD symbols with each set consisting of four symbols that represent same things: data flow, data store, processes, sources/sinks (external) DeMarco and Yourdan Gane and Sarson (used in the book) 161

Data Flow Diagramming Symbols
process data store source/sink data flow Gane & Sarson Symbols DeMarco & Yourdon Symbols

Depicts data in motion and moving from one place to another in the system. Example: results of query of database, contents of printed report Data flow is data that move together Data flow can be composed of many individual pieces of data that are generated at the same time and flows together Data Store Depicts data at rest May represent one of many different physical locations for data: File folder Computer-based file Notebook Might contain data about customers, students, customer orders 163

Process Depicts work or action performed on data so that they are transformed, stored or distributed Source/Sink Depicts the origin and/or destination of the data Sometimes referred to as an external entity so they are outside system and define boundaries of system Because they are external, many characteristics are not of interest to us Data must originate from outside a system from one or more sources and system must produce information to one or more sinks consist of – another organization, a person inside or outside business, another information system 164

Data Flow Diagramming Symbols
Data flow is shown as an arrow labeled with a meaningful name for data (all elements of data moving as part of one packet) in motion – sales receipt, customer order. Source/Sink is shown as a square and has a name that states what external agent is – customer, teller. Data store is shown as rectangle without its right vertical side and left side has a small box used to number the data store and inside the main part of rectangle is a meaningful label – student file. Process is shown as a rectangle with rounded corners with a line dividing it into two parts – upper part has the number of process and lower part has name of process

Data Flow Diagramming Definitions
Context Diagram The highest-level view 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 All context diagrams have only one process labeled “0” No data stores appear on a context diagram Level-0 Diagram A data flow diagram (DFD) that represents a system’s major processes, data flows and data stores at a high level of detail Each process has a number that ends in .0 DFD hides many physical characteristics of system We do not know timing of when data flow is produced, how frequently it is produced, what volume of data is sent 166

Developing DFDs: An Example
Process names should be clear yet concise begin with an action verb, such as receive, generate, calculate are same as verbs used in many computer programming languages – merge, sort, read, write should capture essential action of the process in just few words yet describe the process’ action so that reading its name explains what process does An Example Hoosier Burger’s automated food ordering system Context Diagram (Figure 8-4) contains no data stores Next step is to expand the context diagram to show the breakdown of processes (Figure 8-5) 167

Figure 8-4 Context diagram of Hoosier Burger’s food ordering system
Single process “0” represents entire system Conceptually data stores are inside one process only one process no data store four data flows three source/sinks 168

Figure 8-5 Level-0 DFD of Hoosier Burger’s food ordering system
coupled together (ready to accept) decoupled by placing a buffer (data store) 169

Data Flow Diagramming Rules
Basic rules that apply to all DFDs Inputs to a process are always different than its outputs – purpose of a process is to transform inputs to outputs Objects on a DFD always have a unique name In order to keep the diagram uncluttered, you can repeat data stores and sources/sinks on a diagram Process: A. No process can have only outputs ( we can’t make data from nothing). Having only outputs means it must be a source. B. No process can have only inputs. Having only inputs means it must be a sink. C. A process has a verb phrase label 170

Data store: D. Data must be moved by a process and cannot move directly from one data store to another data store E. Data cannot move directly from an outside source to a data store. Data must be moved by a process that receives data from the source and places data into data store. F. Data cannot move directly to an outside sink from a data store. Data must be moved by a process. G. A data store has a noun phrase label Source/Sink: H. Data cannot move directly from source to sink and has to be moved by a process else data flow is not shown on the DFD. I. A source/sink has a noun phrase label 171

J. A data flow has only one direction of flow between symbols. It may flow in both directions between a process and a data store usually indicated by two separate arrows as this happens at separate times K. A fork in a data flow means that exactly the same data goes from a common location two or more different processes, data stores, or sources/sinks. L. A join in a data flow means that exactly the same data comes from any two or more different processes, data stores, or sources/sinks to a common location M. A data flow cannot go directly back to the same process it leaves. N. A data flow to a data store means update (delete or change) O. A data flow from a data store means retrieve or use. P. A data flow has a noun phrase label.

Decomposition of DFDs Functional decomposition Balancing DFDs
An iterative process of breaking one single system to many component processes with finer and finer detail creating a set of charts in which one process on a given chart is explained in greater detail on another chart creating a set of hierarchically related charts Each sub-process may again be broken down into smaller units Lowest level of DFD 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 Balancing DFDs When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decomposition This conservation of inputs and outputs is called balancing 173

Decomposition of DFDs Level-1 Diagrams
no sources/sinks are represented, though may be included Level-1, -2, or -n DFDs represents one process on a level-n-1 DFD Each DFD should be on a separate page No DFD should have more than seven processes

Figure 8-10 An unbalanced set of data flow diagrams (a) Context diagram (b) Level-0 diagram
175

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 name of the actual physical media on which data flow or in which data are stored such as file folders, or computer tapes Current Logical physical aspects of system are removed as much as possible Current system reduced to data and processes that transform them New Logical Includes additional functions Obsolete functions are removed Inefficient data flows are reorganized New Physical Represents the physical implementation of the new system 176

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 (most CASE tools link project dictionary to diagram so that when a new process, data store, data flow, source/sink is defined an entry is automatically created for that element) Incomplete DFDs – data flows not leading anywhere, data stores, processes, or external entities not connected to anything else Consistency The extent to which information contained on one level of a set of nested DFDs is also included on other levels Inconsistent DFDs – level-1 diagram with no level-0 diagram; data flow attached to different objects in two different levels; data flow appearing in higher level but not on lower levels 177

Timing Time is not represented well on DFDs No indication of whether a data flow occurs constantly in real time, once a week, once a year, no indication of when system would run Best to draw DFDs as if the system has never started and will never stop. Iterative Development First DFD drawn is not perfect Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled Primitive DFDs Lowest logical level of decomposition Decision has to be made when to stop decomposition 178

Rules for stopping decomposition When each process has been reduced to a single decision, calculation or database operation like update, create When each data store represents data about a single entity like customer, employee When the system user does not care to see any more detail 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 179

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 Some inefficiencies relate to violations of DFD drawing rules Some inefficiencies are due to excessive processing steps Comparison of DFDs of current logical system with new logical system leads to determine which processes needs to be added or revised while building new system 180

Summary Data flow diagrams (DFD) Symbols Rules for creating
Decomposition Balancing Four different kinds of DFDs Current Physical Current Logical New Logical New Physical DFDs for Analysis DFDs for Business Process Reengineering (BPR) Oracle’s Process Modeler Functional Hierarchy Diagrams 181

Structuring System Requirements:
Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 9 Structuring System Requirements: Logic Modeling 182

Learning Objectives Use Structured English as a tool for representing steps in logical processes in data flow diagrams. Use decision tables and decision trees to represent logical choice in conditional statements. Select among Structured English, decision tables, and decision trees. 183

Logic Modeling Data flow diagrams do not show the logic inside the processes – what occurs within a process? How input data is converted into output information Logic modeling involves representing internal structure and functionality of processes depicted on a DFD. Processes must be clearly described before translating them into programming language. Logic modeling can also be used to show when processes on a DFD occur. Logic modeling will be generic without taking syntax of a particular programming language 184

Logic Modeling Deliverables and Outcomes
Each process on the lowest level DFD will be represented by one or more of the following: Structured English Decision Tables Decision Trees State-transition diagrams Sequence diagrams Activity diagrams 185

Modeling Logic with Structured English
Structured English is a modified form of English used to specify the logic of information processes Uses a subset of English vocabulary to express process procedures Action verbs – read, write, print, move, merge, add, sort Noun phrases – name, address No adjectives or adverbs No specific standards – each analyst will have his own way File and variable names are CAPITALIZED Logical comparisons are spelled out and symbols are not used Structured English is used to represent processes in a shorthand manner that is relatively easy for users and programmers to read and understand 186

Modeling Logic with Structured English
It is possible to represent all three processes used in structured programming: sequence, conditional, repetition Sequence – no special structure but one statement following another Conditional – IF THEN ELSE statement; CASE statement Repetition – DO-UNTIL loops or DO-WHILE loops Format of Structured English uses indentation used in programming languages Structured English does not initialize variables, open and close files, or find related records in separate files – all are done in later design process

Structured English is used here to describe input and output.

Structured English is used here to describe arithmetic operations.

Structured English is used here to describe repetition.

Structured English is used here to describe decisions.

Structured English is used here to describe invoking other processes.

Modeling Logic with Decision Tables
Structured English is not good to represent complicated logic (having several different conditions) as it becomes difficult to understand Decision table: A matrix representation of the logic of a decision Specifies all the possible conditions and the resulting actions in a tabular form Best used for complicated decision logic 3 Parts of a Decision Table Condition stubs Lists condition relevant to decision Action stubs Actions that result from a given set of conditions Rules Specify which actions are to be followed for a given set of conditions Indifferent Condition Condition whose value does not affect which action is taken for two or more rules 194

Procedure for Creating Decision Tables
Name the conditions and values each condition can assume some conditions values will be just “yes” or “no” and some may have many values (called an extended entry) Name all possible actions that can occur List all possible rules Create exhaustive set of rules – every possible combination of conditions must be represented Some rules may be redundant or make no sense that can be altered later Number of rules = number of values for condition 1 X number of values for condition 2 X …..X number of values for condition n Define the actions for each rule If an action doesn’t make sense create an “impossible” row for that action If the action is not known place a ? for that rule Simplify the table Remove any rules with impossible actions 195

Decision Table Note: for salaried employees the action stub chosen will always be the same…therefore hours worked is an indifferent condition 196

Reduced Decision Table
Because of indifferent condition, the complete decision table can be reduced to one with fewer rules 197

Procedure for Creating Decision Tables
Decision tables can also be used to specify additional decision-related information: If actions for a rule are more complicated and can’t be conveyed in one or two lines of text (or) If some conditions depend on other conditions (nested conditions) use separate, linked decision table by writing “Perform Table B” as action in the action stub Table B could contain an action stub that returns to the original table Use numbers to indicate sequence rather than just Xs where rules and action stub intersect Decision tables are compact – pack a lot of information into a small table Decision tables allow you to check for the completeness, consistency, and redundancy of logic

Modeling Logic with Decision Trees
A decision tree is a graphical representation of a decision situation Decision situation points (nodes) are connected together by arcs and terminate in ovals Main components Decision points represented by nodes Actions represented by ovals Particular choices from a decision point represented by arcs To read a decision tree – begin at root node on far left Each node is numbered and each number corresponds to a choice Choices are spelled out in a legend From each node there are at least two paths leading to next step – another decision point or an action All possible actions are listed on the far right in leaf nodes Each rule is represented by tracing a series of paths from root node to the next node and so on until an action oval is reached 199

Decision tree representation of salary decision
200

Alternative decision tree representation of salary decision
201

Deciding Among Structured English, Decision Tables, and Decision Trees
Criteria Structured English Decision Tables Decision Trees Determining Conditions and Actions Second Best Third Best Best Transforming Conditions and Actions into Sequence Checking Consistency and Completeness 202

Deciding Between Decision Tables and Decision Trees
Criteria Decision Tables Decision Trees Portraying complex logic Best Worst Portraying simple rules Making decisions More compact Easier to manipulate 203

Summary In this chapter you learned how to:
Use structured English as a tool for representing steps in logical processes in data flow diagrams. Use decision tables and decision trees to represent logical choice in conditional statements. Select among structured English, decision tables, and decision trees.

Structuring System Requirements: Conceptual Data Modeling
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring System Requirements: Conceptual Data Modeling Copyright 2002 Prentice-Hall, Inc. 205

Learning Objectives Define key data modeling terms Entity type
Attribute Multivalued attribute Relationship Degree Cardinality Business Rule Associative entity Trigger Supertype Subtype 206

Learning Objectives Learn to draw Entity-Relationship (E-R) Diagrams
Review the role of conceptual data modeling in overall design and analysis of an information system Distinguish between unary, binary, and ternary relationships, and give an example of each Define four basic types of business rules in an E-R diagram Explain the role of CASE technology in the analysis and documentation of data required in an information system Relate data modeling to process and logic modeling as different views describing an information system 207

Conceptual Data Modeling
Process and logic modeling does not show the definition, structure and relationships within the data but show how, where, and when data are used or changed Data model is most important part of information system requirements as: The characteristics of data captured during the data modeling are crucial in design of databases, program, computer screens, and printed reports – data element is numeric, a name is limited to a specified set, an item on a customer order can’t be moved to another customer order Data rather than processes are most complex aspects (validating data, coordinating movement of data) of many modern information systems like MIS, DSS, ESS Characteristics about data(length, format, relationships with other data) are reasonably permanent whereas paths of data flow are dynamic Most common format used for data modeling is entity-relationship (E-R) diagramming

Conceptual Data Modeling
Conceptual data model is a representation of organizational data Purpose is to show as many rules about the meaning and interrelationships among data as are possible Entity-Relationship (E-R) diagrams are commonly used to show how data are organized Main goal of conceptual data modeling is to create accurate E-R diagrams Methods such as interviewing, questionnaires and JAD are used to collect information Consistency and completeness must be maintained between process flow, decision logic and data modeling descriptions 209

Process of Conceptual Data Modeling
First step is to develop a data model for the system being replaced, if a system exists Next, a new conceptual data model is built that includes all the requirements of the new system Conceptual data modeling is carried out throughout the systems development process In the design stage, the E-R model developed is translated into a format from which physical data storage decisions can be made In implementation files and databases are defined as system is coded Project repository links all design and data modeling steps performed during SDLC 210

Primary deliverable is the entity-relationship diagram There may be as many as four E-R diagrams produced and analyzed during conceptual data modeling An E-R diagram that covers just the data needed in the project’s application An E-R diagram for system being replaced An E-R diagram for the whole database from which the new application’s data is extracted An E-R diagram for the whole database from which data for the application system being replaced is drawn 211

Deliverables and Outcome
Second deliverable is a set of entries about data objects to be stored in repository or project dictionary Repository links data, process and logic models of an information system Data elements that are included in the DFD must appear in the data model and visa versa Each data store in a process model must relate to business objects represented in the data model

Figure 10-3 Sample conceptual data model diagram
213

Gathering Information for Conceptual Data Modeling
Two perspectives Top-down Data model is derived from an intimate understanding of the nature of business Bottom-up Data model is derived by reviewing specific business documents – computer displays, reports, business forms 10.214 214

Requirements Determination Questions for Data Modeling What are the subjects/objects of business? What type of people, places, things, events, etc., are used or interact in business whose data must be maintained? How many instances of each object might exist? – data entities and their descriptions What unique characteristic (or characteristics) distinguishes each object from other objects of same type? Does this distinguish character change over time or is it permanent? – primary key What characteristics describe each object? On what basis are objects referenced, selected, sorted and categorized? – attributes and secondary keys How do you use this data? Are you the source of data, do you modify it or just refer it? Who is not permitted to use it? – security controls

Over what period of time are you interested in this data? Do you need historical trends, current snapshot values, or estimates? – cardinality and time dimensions of data Are all instances of each object the same? Are some objects summaries or combinations of more detailed objects – supertypes, subtypes, and aggregations What events occur that imply associations between various objects? – relationships and their cardinality and degree Is each activity or event always handled the same way or are there special circumstances? Can the associations between objects change over time (employee change departments)? – integrity rules, minimum and maximum cardinality

Introduction to Entity-Relationship (E-R) Modeling
The basic E-R modeling notation uses three main constructs Data entities Relationships Attributes Several different E-R notations exist but we use crow’s foot notations Entity-Relationship Data Model (E-R model) A detailed, logical representation of the data for an organization or for a business area E-R model is expressed in terms of entities in business environment, the relationships or associations among those entities, and attributes or properties of both the entities and their relationships Entity-Relationship Diagram (E-R diagram) A graphical representation of an E-R model 10.217 217

Entity-Relationship (E-R) Modeling Key Terms
A person, place, object, event or concept in the user environment about which the organization maintains data It has its own identity that distinguishes it from other entity Examples – Person: EMPLOYEE, STUDENT, PATIENT Event: SALE, RENEWAL, REGISTRATION Object: MACHINE, AUTOMOBILE, BUILDING Represented by a rectangle in E-R diagrams Distinction between entity types and entity instances Entity Type or Entity Class A collection of entities that share common properties or characteristics Each entity type is given a name – represents a set hence singular Use a simple noun to name an entity type – use capital letters Name is placed inside rectangle representing entity Entity Instance It is a single occurrence of an entity type An entity type can have many instances of that entity type represented by data stored in the database 10.218 218

Attribute A named property or characteristic of an entity that is of interest to an organization Examples of entities and their associated attributes STUDENT: Student_ID, Student_Name, Student_Address, Major AUTOMOBILE: Vehicle_ID, Color, Weight, Power, Wheels Attribute names are nouns with initial capital letter, followed by lowercase letters Attributes are represented in E-R diagrams by an ellipse with name inside and a line connecting it to the associated entity

Candidate keys and Identifiers Each entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type Candidate key Attribute (or combination of attributes) that uniquely identifies each instance of an entity type Candidate key for STUDENT entity type may be Student_ID Sometimes more than one attribute is needed to identify a unique entity Some entities may have more than one candidate key EMPLOYEE may have one candidate key Employee_ID or a combination of Employee_Name and Address 10.220 220

Identifier A candidate key that has been selected as the unique identifying characteristic for an entity type Selection rules for an identifier Choose a candidate key that will not change its value like Employee_Address Choose a candidate key that will never be null Avoid using intelligent keys whose structure indicates classifications, locations, and so on like first 2 digits of a key for a STUDENT entity might indicate college name Consider substituting single value surrogate keys for large composite keys The name of the identifier is underlined on an E-R diagram 10.221 221

Multivalued Attribute An attribute that may take on more than one value for each entity instance A STUDENT can attend more than one class – multivalued attribute Represented on E-R Diagram in two ways: double-lined ellipse weak entity – separate repeating data into another entity and then using relationship link it to its associated regular entity Repeating group – several attributes that repeat together like EMPLOYEE Dependents – name, age, relation (spouse, child) Relationships An association between the instances of one or more entity types that is of interest to the organization Association indicates that an event has occurred or that there is a natural link between entity types Relationships are always labeled with verb phrase 10.222 222

Degree of Relationship
Number of entity types that participate in a relationship Three cases Unary A relationship between two instances of one entity type (also called recursive relationship) Binary A relationship between the instances of two entity types Ternary A simultaneous relationship among the instances of three entity types Not the same as three binary relationships It is recommended that all ternary and higher relationships be represented as associative entities 10.223 223

Figure 10-6 Example relationships of different degrees
10.224 224

Cardinality Associative Entity
The number of instances of entity B that can be associated with each instance of entity A Minimum Cardinality The minimum number of instances of entity B that may be associated with each instance of entity A If minimum cardinality of an entity is 0, then that entity is optional participant in relationship If minimum cardinality of an entity is 1, then that entity is mandatory participant in relationship Maximum Cardinality The maximum number of instances of entity B that may be associated with each instance of entity A An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances (also called gerund) Associative Entity 10.225 225

Naming and Defining Relationships
Relationship name is a verb phrase Avoid vague names Guidelines for defining relationships Definition explains what action is being taken and why it is important Give examples to clarify the action Optional participation should be explained Explain reasons for any explicit maximum cardinality Explain any restrictions on participation in the relationship Explain extent of the history that is kept in the relationship Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance 10.226 226

Representing Supertypes and Subtypes
Often two or more entity types share common properties but also have one or more distinct attributes or relationships Subtype – a subgrouping of the entities in an entity types meaningful to an organization. Example – STUDENT is an entity type that has two subtypes GRADUATE STUDENT and UNDERGRADUATE STUDENT Supertype – a generic entity type that has a relationship with one or more subtypes Total specialization rule – each entity instance of the supertype must be a member of some subtype in the relationship (shown by double line) Partial specialization rule – an entity instance of the supertype is allowed not to belong to any subtype in the reationship (shown by single line) Disjoint rule – if an entity instance of the supertype is a member of one subtype, it cannot simultaneously be a member of any other subtype Overlap rule – an entity instance can simultaneously be a member of two or more subtypes. Disjoint is shown by a “d” and overlap is shown by a “o” in the circle

Business Rules Domains
The specifications that preserve the integrity of logical data model Four basic types of business rules: Entity integrity – each instance of an entity type must have unique identifier that is not null Referential integrity constraints – rules concerning the relationships between entity types Domains – constraints on valid values for attributes Triggering operations – other business rules to protect validity of attribute values Domains The set of all data types and ranges of values that an attribute can assume – data type, length, format, range, allowable values, meaning Several advantages Verify that the values for an attribute are valid Ensure that various data manipulation operations are logical Help conserve effort in describing attribute characteristics 10.228 228

Triggering Operations
An assertion or rule that governs the validity of data manipulation operations such as insert, update and delete Scope of triggering operations may be limited to attributes with one entity or attributes of two or more entities Includes the following components: User rule Statement of the business rule to be enforced by the trigger Event Data manipulation operation that initiates the operation Entity Name Name of entity being accessed or modified Condition Condition that causes the operation to be triggered Action Action taken when the operation is triggered 10.229 229

The Role of CASE in Conceptual Data
Responsibility for data integrity lies within scope of database management system, not individual applications Business rules should be documented in CASE repository so that rules would be checked automatically by database software CASE tools provide two important functions: Maintain E-R diagrams as a visual depiction of structured data requirements Link objects on E-R diagrams to corresponding descriptions in a repository The Role of CASE in Conceptual Data 10.230 230

Summary Process of conceptual data modeling Deliverables
Gathering information Entity-Relationship Modeling Entities Attributes Candidate keys and identifiers Multivalued attributes Degree of relationship Cardinality Naming and defining relationships Associative entities Domains Triggering Operations Role of CASE 10.231 231

Selecting the Best Alternative Design Strategy
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 11 Selecting the Best Alternative Design Strategy Copyright 2002 Prentice-Hall, Inc. 232

Learning Objectives Describe different sources of software
Learn to assemble the various pieces of an alternative design strategy Learn how to generate at least three alternative design strategies Discuss selecting the best design strategy using both qualitative and quantitative methods 233

Learning Objectives Learn how to use the results of the analysis phase to update a Baseline Project Plan (BPP) Discuss design strategies and how they are applied to the Internet 234

Two basic steps Generate a comprehensive set of alternative design strategies Select the one design strategy that is most likely to result in the desired information system Process Divide requirements into different sets of capabilities Enumerate different potential implementation environments that could be used to deliver the different sets of capabilities Propose different ways to source or acquire the various sets of capabilities for the different implementation environments 235

Deliverables At least three substantially different system design strategies for building the replacement information system A design strategy judged most likely to lead to the most desirable information system A Baseline Project Plan (BPP) for turning the most likely design strategy into a working information system 236

Generating Alternative Design Strategies
Best to generate three alternatives Low-end Provides all required functionality users demand with a system that is minimally different from the current system High-end Solves problem in question and provides many extra features users desire Midrange Compromise of features of high-end alternative with frugality of low-end alternative 237

Drawing Bounds on Alternative Designs
Minimum Requirements Mandatory features versus desired features Forms of features Data Outputs Analyses User expectations on accessibility,response time and turnaround time 238

Drawing Bounds on Alternative Designs
Constraints on System Development Date when system is needed Financial and human resources Elements of the system that cannot change Legal and contractual considerations Dynamics of the problem 239

Issues to Consider in Generating Alternatives
Outsourcing The practice of turning over responsibility of some to all of an organization’s information systems applications and operations to an outside firm Can provide a cost effective solution 240

Issues to Consider in Generating Alternatives
Sources of Software Hardware manufacturers Packaged software producers Custom software producers Enterprise solution software Application Service Providers In-house development 241

11.242 242

Criteria for Choosing Off-the-Shelf Software
Cost In-House versus purchased Functionality Mandatory, essential and desired features Vendor Support Installation Training Technical Support Viability of Vendor 11.243 243

Criteria for Choosing Off-the-Shelf Software
Flexibility Ease of customization Documentation User documentation Technical documentation Response Time Ease of Installation 244

Validating Purchased Software Information
Information from vendor Request for proposal A document provided to vendors to ask them to propose hardware and system software that will meet the requirements of your new system Software evaluation period Customer references from vendor Independent software testing service Trade publications 245

Hardware and Software Issues
Existing Platform Lower costs Information system staff is familiar with operation and maintenance Increased odds of successfully integrating system with existing applications No added costs of converting old systems to new platform or transferring data New Hardware and System Software Some software components will only run on new platform Developing system for new platform gives organization opportunity to upgrade technology holdings New requirements may allow organization to radically change its computing operations 246

Implementation and Organizational Issues
Implementation Issues Technical and social aspects of implementation need to be addressed Training Disruption of work Organizational Issues Overall cost and availability of funding Management support User acceptance 247

Hoosier Burger’s New Inventory Control System
Replacement for existing system Figure 11-2 ranks system requirements and constraints Figure 11-3 shows steps of current system When proposing alternatives, the requirements and constraints must be considered 248

Figure 11-4 lists 3 alternatives Alternative A is a low-end proposal Alternative C is a high-end proposal Alternative B is a midrange proposal 249

Selecting the most likely alternative Weighted approach can be used to compare the three alternatives Figure 11-5 shows a weighted approach for Hoosier Burger Left hand side of table contains decision criteria Constants and requirements Weights are arrived at by discussion with analysis team, users and managers Each requirement and constraint is ranked 1 indicates that the alternative does not match the request well or that it violates the constraint 5 indicates that the alternative meets or exceeds requirements or clearly abides by the constraint 250

Selecting the most likely alternative According to the weights used, alternative C appears to be the best choice 251

Updating the Baseline Project Plan (BPP)
The Baseline Project Plan (BPP) was developed during project initiation and planning Baseline Project Plan (BPP) can be used as an outline of a status report at analysis phase Schedule will be updated to reflect actual activities and durations An oral presentation of project status is typically made at this phase 252

Internet Development: Selecting the Best Alternative Design Strategy
Pine Valley Furniture WebStore Requirements and constraints were compiled by consultant and team (see Table 11-8) 253

Internet Development: Selecting the Best Alternative Design Strategy
Proposed system is a scalable, three-tier approach Scalable The ability to seamlessly upgrade the system through either hardware upgrades, software upgrades or both Three-tier Web Server Provides connection to the internet and presentation of HTML page Applications Server Middle layer of software and hardware that lies between Web server and corporate network Corporate network Existing organizational computing infrastructure 254

Summary Sources of Software Identifying requirements and constraints
Generating alternative design strategies Selecting the best design strategy Updating a Baseline Project Plan (BPP) Selecting the best design strategy for Internet applications 255

Copyright 2002 Prentice-Hall, Inc.
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 12 Designing Databases Copyright 2002 Prentice-Hall, Inc. 256

Learning Objectives Define each of the following database terms
Relation Primary key Normalization Functional dependency Foreign key Referential integrity Field Data type Null value Denormalization File organization Index Secondary key 257

Learning Objectives Discuss the role of designing databases in the analysis and design of an information system Learn how to transform an Entity-Relationship (ER) Diagram into an equivalent set of well-structured relations Learn how to merge normalized relations from separate user views into a consolidated set of well-structured relations Explain choices of storage formats for database fields Learn how to transform well-structured relations into efficient database tables Discuss use of different types of file organizations to store database files Discuss indexes and their purpose 258

Purpose of Database Design
Structure the data in stable structures, called normalized tables Not likely to change over time Minimal redundancy Develop a logical database design that reflects actual data requirements that exists in forms and reports Develop a logical database design from which a physical database design can be developed Translate a relational database model into a technical file and database design that balances several performance factors Choose data storage technologies that will efficiently, accurately and securely process database activities 259

Process of Database Design
Logical Design Based upon the conceptual data model Four key steps Develop a logical data model for each known user interface for the application using normalization principles Combine normalized data requirements from all user interfaces into one consolidated logical database model Translate the conceptual E-R data model for the application into normalized data requirements Compare the consolidated logical database design with the translated E-R model and produce one final logical database model for the application 260

Process of Database Design
Physical Design Based upon results of logical database design Key decisions Choosing storage format for each attribute from the logical database model Grouping attributes from the logical database model into physical records Arranging related records in secondary memory (hard disks and magnetic tapes) so that records can be stored, retrieved and updated rapidly Selecting media and structures for storing data to make access more efficient 261

Logical database design must account for every data element on a system input or output Normalized relations are the primary deliverable Physical database design results in converting relations into files 262

Relational Database Model
Data represented as a set of related tables or relations Relation A named, two-dimensional table of data. Each relation consists of a set of named columns and an arbitrary number of unnamed rows; column – attribute; row – entity instance (record) Properties of relations Entries in cells are simple Entries in columns are from the same set of values Each row is unique The sequence of columns can be interchanged without changing the meaning or use of the relation The rows may be interchanged or stored in any sequence Well-Structured Relation A relation that contains a minimum amount of redundancy and allows users to insert, modify and delete the rows without errors or inconsistencies 12.263 263

Normalization The process of converting complex data structures into simple, stable data structures Normalization is based on well-accepted principles and rules There are many rules and two such rules are: Second Normal Form (2NF) Each nonprimary key attribute is identified by the whole key (called full functional dependency) Third Normal Form (3NF) Nonprimary key attributes do not depend on each other (called transitive dependencies) The result of normalization is that every nonprimary key attribute depends upon the whole primary key 12.264 264

Functional Dependencies and Primary Keys
Functional Dependency A particular relationship between two attributes. For a given relation, attribute B is functionally dependent on attribute A if, for every valid value of A, that value of A uniquely determines the value of B; represented as AB Functional dependence of B on A means that there can be only one value of B for each value of A Instances (or sample data) in a relation do not prove the existence of a functional dependency Knowledge of problem domain is most reliable method for identifying functional dependency Primary Key An attribute whose value is unique across all occurrences of a relation 12.265 265

Second Normal Form (2NF) A relation is in second normal form (2NF) if any of the following conditions apply: The primary key consists of only one attribute No nonprimary key attributes exist in the relation Every nonprimary key attribute is functionally dependent on the full set of primary key attributes Conversion to second normal form (2NF) To convert a relation into 2NF, decompose the relation into new relations using the attributes, called determinants, that determine other attributes The determinants become the primary key of the new relation 12.266 266

Third Normal Form (3NF) A relation is in third normal form (3NF) if it is in second normal form (2NF) and there are no functional (transitive) dependencies between two (or more) nonprimary key attributes Foreign Key An attribute that appears as a nonprimary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation Referential Integrity An integrity constraint specifying that the value (or existence) of an attribute in one relation depends on the value (or existence) of the same attribute in another relation 12.267 267

Transforming E-R Diagrams into Relations
It is useful to transform the conceptual data model into a set of normalized relations Steps Represent entities Represent relationships Normalize the relations Merge the relations Represent Entities Each regular entity type in E-R diagram is transformed into a relation The identifier of the entity type becomes the primary key of the corresponding relation The primary key must satisfy the following two conditions The value of the key must uniquely identify every row in the relation The key should be nonredundant 12.268 268

Represent Relationships Binary one-to-many (1:N) Relationships Add the primary key attribute (or attributes) of the entity on the one side of the relationship as a foreign key in the relation on the right side The one side migrates to the many side Binary or Unary one-to-one (1:1) Relationship Three possible options Add the primary key of A as a foreign key of B Add the primary key of B as a foreign key of A Both of the above 12.269 269

Binary and Higher M:N relationships Create another relation and include primary keys of all relations as primary key of new relation Unary 1:N Relationships Relationship between instances of a single entity type Utilize a recursive foreign key A foreign key in a relation that references the primary key values of that same relation Unary M:N Relationships Create a separate relation Primary key of new relation is a composite of two attributes that both take their values from the same primary key 12.270 270

12.271 271

Merging Relations (View Integration) Purpose is to remove redundant relations View Integration Problems Synonyms Two different names used for the same attribute When merging, get agreement from users on a single, standard name Homonyms A single attribute name that is used for two or more different attributes Resolved by creating a new name Dependencies between nonkeys Dependencies may be created as a result of view integration In order to resolve, the new relation must be normalized 12.272 272

Physical File and Database Design
The following information is required Normalized relations, including volume estimates Definitions of each attribute Descriptions of where and when data are used, entered, retrieved, deleted and updated (including frequencies) Expectations or requirements for response time and data integrity Descriptions of the technologies used for implementing the files and database 12.273 273

Designing Fields Field
The smallest unit of named application data recognized by system software Each attribute from each relation will be represented as one or more fields Choosing data types Data Type A coding scheme recognized by system software for representing organizational data Four objectives Minimize storage space Represent all possible values of the field Improve data integrity of the field Support all data manipulations desired on the field Calculated (or computed or derived) fields A field that can be derived from other database fields 12.274 274

Methods of Controlling Data Integrity
Default Value A value a field will assume unless an explicit value is entered for that field Range Control Limits range of values which can be entered into field Referential Integrity An integrity constraint specifying that the value (or existence) of an attribute in one relation depends on the value (or existence) of the same attribute in another relation Null Value A special field value, distinct from 0, blank, or any other value, that indicates that the value for the field is missing or otherwise unknown 12.275 275

Designing Physical Tables
Relational database is a set of related tables Physical Table A named set of rows and columns that specifies the fields in each row of the table Design Goals Efficient use of secondary storage (disk space) Disks are divided into units that can be read in one machine operation Space is used most efficiently when the physical length of a table row divides close to evenly with storage unit Efficient data processing Data are most efficiently processed when stored next to each other in secondary memory 12.276 276

Denormalization The process of splitting or combining normalized relations into physical tables based on affinity of use of rows and fields Partitioning Capability to split a table into separate sections Oracle 8i implements three types Range – partitions defined by non overlapping range of values Hash – table row assigned to partition by an algorithm Composite – combines range and hash partitioning Optimizes certain operations at the expense of others Three common situations where denormalization may be used Two entities with a one-to-one relationship A many-to-many relationship with nonkey attributes Reference data 12.277 277

Arranging Table Rows Physical File A named set of table rows stored in a contiguous section of secondary memory Each table may be a physical file or whole database may be one file, depending on database management software utilized File Organization A technique for physically arranging the records of a file Objectives for choosing file organization Fast data retrieval High throughput for processing transactions Efficient use of storage space Protection from failures or data loss Minimizing need for reorganization Accommodating growth Security from unauthorized use 12.278 278

Types of File Organization Sequential The rows in the file are stored in sequence according to a primary key value Updating and adding records may require rewriting the file Deleting records results in wasted space Indexed The rows are stored either sequentially or nonsequentially and an index is created that allows software to locate individual rows Index A table used to determine the location of rows in a file that satisfy some condition Secondary Index Index based upon a combination of fields for which more than one row may have same combination of values 12.279 279

Guidelines for choosing indexes Specify a unique index for the primary key of each table Specify an index for foreign keys Specify an index for nonkey fields that are referenced in qualification, sorting and grouping commands for the purpose of retrieving data Hashed File Organization The address for each row is determined using an algorithm 12.280 280

12.281 281

Designing Controls for Files
Backup Techniques Periodic backup of files Transaction log or audit trail Change log Data Security Techniques Coding or encrypting User account management Prohibiting users from working directly with the data. Users work with a copy which updates the files only after validation checks 12.282 282

Summary Key Terms Relation Primary key Normalization
Functional dependency Foreign key Referential integrity Field Data type Denormalization File organization Index Secondary key 12.283 283

Summary Transforming E-R diagram into well-structured relations
View integration Storage formats for database fields Efficient database table design Efficient use of secondary storage Data processing speed File organization Indexes 12.284 284

Designing Forms and Reports
Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 13 Designing Forms and Reports Copyright 2002 Prentice-Hall, Inc. 285

Learning Objectives Explain the process of designing forms and reports and the deliverables for their creation Discuss general guidelines for formatting forms and reports Use color and know when color improves the usability of information Learn how to effectively format text, tables and lists Explain how to assess usability Explain interface design guidelines unique to the design of Internet-based electronic commerce systems 286

Designing Forms and Reports
Forms are used to present or collect information on a single item – customer, product, event Forms can be used for both input and output Reports are used to convey information on a collection of items Quality of a system depends on the quality of its input and output methods – design of forms and reports is an important activity System inputs and outputs (forms and reports) are formed at the end of the analysis phase Precise appearance was not defined during this phase Only which ones needed and what their contents were Forms and reports are integrally related to DFD and E-R diagrams Contents of form or report correspond to the data elements contained in the associated data flow 287

Designing Forms and Reports Key Concepts
A business document that contains some predefined data and often include some areas where additional data are to be filled in A form contains data from only one database record Examples – product order forms, employment applications, class registration forms, electronic spreadsheet Previously forms were displayed on paper medium, now forms can be displayed on video display terminal for data entry Most forms have stylized format and not simple row/columns Report A business document that contains only predefined data A passive document for reading or viewing data Typically contains data from many unrelated database records or transactions Examples – weekly sales summaries, pie chart of population 288

The Process of Designing Forms and Reports
User-focused activity Follows a prototyping approach Requirements determination Who will use the form or report? (experienced or new users, their educational and business background and knowledge) What is the purpose of the form or report? When is the report needed or used? Where does the form or report need to be delivered and used? How many people need to use or view the form or report? Prototyping Initial prototype is designed from requirements Users review prototype design and either accept the design or request changes If changes are requested, the construction-evaluation-refinement cycle is repeated until the design is accepted 289

Deliverables and Outcome
Design specifications are major deliverable and contain three sections Narrative overview – general overview of characteristics of target users, tasks, system, environmental factors where form or report will be used to explain to those who will actually develop the final form Sample design – hand-drawn or using CASE tools Testing and usability assessment 290

General Guidelines for Forms and Reports
Meaningful Titles: Clear and specific titles describing content and use of form and report Revision date or code to distinguish a form or report from prior versions Current date to identify when the form or report was generated Valid date which identifies on what date (or time) the data were accurate Meaningful Information: Only needed information should be displayed Information should be provided that is usable without modification Balance the Layout: Information should be balanced on the screen or page Adequate spacing and margins should be used All data and entry fields should be clearly labeled Design Easy Navigation System: Clearly show how to move forward and backward Clearly show where you are (e.g., page 1 of 3) and notify last page

General Formatting Guidelines for Forms and Reports
Highlighting Use sparingly to draw user to or away from certain information and to group together related information Blinking and audible tones should only be used to highlight critical information requiring user’s immediate attention Methods should be consistently selected and used based upon level of importance of emphasized information Situations when highlighting can be a valuable technique: Notifying users of errors in data entry or processing Providing warnings to users about possible problems Drawing attention to keywords, commands, high priority messages 292

General Formatting Guidelines for Forms and Reports Color versus No-Color
Benefits from Using Color Greater understanding from a display or chart Soothes or strikes the eye Accents an uninteresting display Facilitates subtle discriminations in complex displays Emphasizes the logical organization of information Draws attention to warnings Evokes more emotional reactions Problems from Using Color Color pairings may wash out or cause problems for some users Resolution may degrade with different displays Color fidelity may degrade on different displays Printing or conversion to other media may not easily translate 293

Displaying Text Case: Display text in mixed upper and lower case and use conventional punctuation Spacing: Use double spacing if space permits. If not, place a blank line between paragraphs Justification: Left-justify text and leave a ragged right margin Hyphenation: Do not hyphenate words between lines Abbreviations: Use abbreviations and acronyms only when they are widely understood by users and are significantly shorter than the full text 294

Designing tables and lists Labels All columns and rows should have meaningful labels Labels should be separated from other information by using highlighting Re-display labels when the data extend beyond a single screen or page Formatting columns, rows and text Sort in a meaningful order Place a blank line between every five rows in long columns Similar information displayed in multiple columns should be sorted vertically Columns should have at least two spaces between them Allow white space on printed reports for user to write notes Use a single typeface, except for emphasis Use same family of typefaces within and across displays and reports Avoid overly fancy fonts 295

Formatting numeric, textual and alphanumeric data Right-justify numeric data and align columns by decimal points or other delimiter Left-justify textual data. Use short line length, usually 30 to 40 characters per line Break long sequences of alphanumeric data into small groups of three to four characters each Paper versus Electronic Reports Printer used for producing paper report needs to be considered in design Use a prototyping process similar to designing a form 296

Assessing Usability Overall evaluation of how a system performs in supporting a particular user for a particular task Three characteristics Speed Accuracy Satisfaction 297

Assessing Usability Success Factors Consistency
Design elements all appear in the same place on all forms and reports Table 13-8 presents usability factors and associated guidelines Context Users Tasks Environment Table 13-9 presents several characteristics that may influence the usability of a design 298

Assessing Usability Measures of Usability Considerations Time to learn
Speed of performance Rate of errors Retention over time Subjective satisfaction Collection methods Observation Interviews Keystroke capturing Questionnaires 299

Summary Designing Forms and Reports
General guidelines for designing forms and reports Formatting text, tables and lists Assessing Usability Interface design guidelines unique to the Internet 300

The Systems Development Environment

Similar presentations

Presentation on theme: "The Systems Development Environment"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The Systems Development Environment

Similar presentations

Presentation on theme: "The Systems Development Environment"— Presentation transcript:

Similar presentations

About project

Feedback