Class Notes Chapters 1-8 for Enterprise Business Process Analysis (MIS 322)
Class Notes Chapters 1-8 for Enterprise Business Process Analysis (MIS 322) MIS 322
Popular in Enterprise Business Process Development
Popular in Business, management
This 29 page Bundle was uploaded by Sarah on Thursday January 14, 2016. The Bundle belongs to MIS 322 at Washington State University taught by Terence Saldanha in Fall 2015. Since its upload, it has received 32 views. For similar materials see Enterprise Business Process Development in Business, management at Washington State University.
Reviews for Class Notes Chapters 1-8 for Enterprise Business Process Analysis (MIS 322)
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 01/14/16
Chapter 1 Software Development Information Systems Analysis and Design ● Complex organizational process ● Used to develop and maintain computer based information systems ● Used by a team of business and systems professionals ○ business need → info need → info systems need Methodology, Techniques, Tools An organizational approach to systems analysis and design is driven by methodologies: ● Methodology ○ what is to be done ○ a higher level approach ○ e.g. fender of a car ● Techniques ○ how it is done ○ different ways of doing things to achieve methodology ○ manually or automatically attach fender ● Tools ○ using what is to be done ○ manually weld, use robot to auto attach ■ Ex: car fender, wheels on bike, software methodology in a company Evolution of Systems Analysis & Design ● 1950s: efficient automation of existing processes ● 1969s: advent of 3GL, faster and more reliable computers ● 1970s: systems development becomes more like an engineering discipline ● 1980s: major breakthrough with 4GL, CASE tools, object oriented methods ● 1990s: focus on system integration, GUI apps, client/server platforms, internet ● 2000s and after: web application development, wireless PDAs. ● Application Software: computer software designed to support organizational functions or processes (ex: angel, bb) ● Firmware: embedded software & hardware: computers ● System Analyst: organizational role most responsible for analysis and design of information systems Developing Information Systems ● System Development Methodology: a standard process followed in an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems. Systems Development Life Cycle (SDLC) ● Traditional methodology used to develop, maintain, and replace info systems Phases of SDLC: ● Planning: Information needs are identified, candidate projects identified, analyzed, arranged, prioritization and selection of projects, determine scope of system, and outcome: baseline project plan ● Analysis: determine requirements, study and structure requirements, and outcome: description of solution ● Design: (end of project phase) ○ Logical design: functional specification of system and business functions are described independently of any computer platform. ○ Physical design: programming language, database, hardware platform, and outcome: design documents system prototypes ● Implementation: coding, testing, installation, doc, and user training for support in the organization ● Maintenance: it’s systematically repaired and improved. system change requests, and new releases of software. Advantages to this methodology? Problems to this methodology? ● Very structured approach & predictable ● You can’t go backwards easily once you’ve ● Clear roadmap of where you are in the already moved on to the next phase process ● Difficult to adapt the system ● Long process & there could be a change in business need before you finish depending on how timely the project is. ● User is only involved in initial phases, but not ending phases so their needs could change Agile Methods Different Approaches to Improving Development ● Computer Aided Software Engineering (CASE Tools): Diagramming tools, graphical representation ○ Computer displays and report generators help prototype how systems look and feel ○ Automatically check for consistency in diagrams, forms, and reports ○ A Central repository provides integrated storage of diagrams, reports, and project management specifications ○ Document generators standardize technical and user documentation ○ Code generators enable automatic generations of programs directly from design docs, diagrams, forms, and reports ● Rapid Application Development (RAD) ○ Methodology to radically decrease design and implementation time ○ Involves: ■ extensive user involvement: less focus on documentation and gets user involved continuously throughout the whole process ■ prototyping: smaller version of full model to get proof of concept ■ integrated CASE tools & code generators ○ Les structure, so things get done quicker ○ RAD Life cycle: ■ Requirement Planning ■ User Design ■ Construction ■ Cutover ● Service Oriented Architecture (SOA) ○ Assembling software components, each of which model generic business functions ● Agile Methodologies ○ Motivated by recognition of software develop as fluid, unpredictable, and dynamic ○ 3 Key Principles ■ adaptive rather than predictive ■ emphasize people rather than roles ■ selfadaptive processes ● eXtreme Programming ○ Short incremental development cycles ○ Automated tests ○ Twoperson programming teams ○ coding and testing operate together Advantages? Disadvantages? ● Quicker, easier to stay on the same page● Lack of structure could cause a software because you coordinate with less people different than the original one due to not ● Higher quality if monitoring each other following the process ● Less people means more room for error and less idea bouncing ● ObjectOriented Analysis and Design (OOAD) ○ Based on objects rather than data or processes ○ Object: a structure encapsulating attributes and behaviors of a real world entity ○ Object Class: a logical grouping of objects sharing the same attributes and behaviors (what all students should have) ○ Inheritance: hierarchical arrangement of classes enable subclasses to inherit properties of superclasses (graduate & undergraduate students) ○ A way of writing software that is more efficient Traditional SDLC Agile Methods Size of project: Large Small Criticality of projectHigh stakes (more steps Low stakes (less and structure) documentation & design) Changing/Dynamism of Better for steady Most adaptable method & environment: environments best for quick changing environments Personnel or other participants More specialized Well rounded and ability to needed (e.g. company work in different areas personnel, other participants: Culture of the organization: More structured Less hierarchical organization organization END QUIZ 1 Chapter 2 Software Design Outsourcing: Turning over responsibility of some or all of an organization’s information systems applications and operations to an outside firm. ● Reasons to Outsource: ○ cost effective ○ take advantage of economies of scale ○ free up internal resources ○ reduce time to market ○ increase process efficiencies ○ system development is a noncore activity for the organization Sources of Software: ● IT Service Firms ○ Help companies develop custom information systems for internal use ○ Develop, host, and run apps for customers ○ Provide other services ● Packaged Software Producers ○ Serve many market segments ○ Provide software ranging from broadbased packages (general ledger) to niche packages (day care management) ○ Software runs on all size computers, from microcomputers to large mainframes ○ Prepackaged software is off the shelf, turnkey software (not customizable) ○ Off the shelf software at best meets 70% of organizations’ needs ○ Ex: IBM (app server, web server), Microsoft (os), HP (system integration services, IT database consulting) ● Enterprise Solutions Software ○ Enterprise Resource Planning (ERP) systems integrate individual traditional business functions into modules enabling a single seamless transaction to cut across functional boundaries ○ E.g. SAP AG is one of the leading vendors of ERP systems ● Cloud Computing: The provision of computing resources, including applications, over the internet, so customers do not have to invest in the computing infrastructure needs to run and maintain the resources. ● Open Source Software ○ Freely available including source code ○ Developed by a community of interested people ○ Performs same functions as commercial software ○ EX: Linux, mySQL, Firefox ● InHouse Development ○ If sufficient system development expertise with the chosen platform exists in house, then some or all of the system can be developed by the organization’s own staff ○ Hybrid solutions involving some purchased and some in house components are common Selecting Off the shelf software ● Cost: comparing cost of developing the same system in house with the cost of purchasing or licensing the software package ● Functionality: the tasks that the software can perform and the mandatory, essential, and desired system features ● Vendor support: whether or how much support the vendor can provide and at what cost ● Viability of Vendor: can the software adapt to changes in systems software and hardware ● Flexibility: how easy it is to customize the software ● Documentation: is the user’s manual and technical documentation understandable and up to date ● Response time: how long it takes the software packages to respond to the users requests in interactive sessions ● Ease of installation: measure of the difficulty of loading the software and making it operational Validating purchased software information ● use a variety of information sources: ○ collect information from vendor ○ software documentation ○ technical marketing literature Request for Proposal (RFP) ● this is a document provided to vendors to ask them to propose hardware and system software that will meet the requirements of a new system. ● Sometimes called a Request For Quote (RFQ) ● use a variety of info sources ● based on vendor bids, analyst selects best candidates RFP Information Sources ● Vendor’s proposal ● Running software through a series of tests ● Feedback from other users of the vendor’s product ● Independent software testing services ● Articles in trade publications Reuse: the use of previously written software resources, especially object components, in software Characteristics: ● Abstraction ● Storage ● Recontextualization ● Procedural software languages ○ less potential for re use ○ Problem: repeated code, redundancy, more work ● Object Oriented Development Reuse ○ core principle is re use ○ Object class encapsulates data and behavior of common organizational entities ○ Object oriented development reuse is the use of object classes in more than one application ● Component Based Development Reuse ○ core principle is re use ○ Components can be as small as objects or as large as pieces of software that handle single business functions ○ Componentbased development reuse is the assembly of an application from many different components at many different levels of complexity and size (currency conversion) Approaches to Reuse: ● Adhoc: individuals are free to find or develop reusable assets on their own ● Facilitated: developers are encouraged to practice reuse ● Managed: the development, sharing, and adoption of reusable assets is mandated. ● Designed: assets mandated for reuse as they are being designed for specific applications Chapter 3 Managing the Information Systems Project Importance of Project Management ● project management may be the most important aspect of systems development ● Effective pm helps to ensure ○ customer expectations are met ○ budget and time constraints are satisfied ● PM skills are difficult and important to learn Why do we need project management? ● to keep big picture view ● stay on track and keep things organized Systems Services Request (SSR): a standard form for requesting or proposing systems development work within an organization. → see Pine Valley Application Project, figure 3-1 ← FOR PROJECT figure 32 use in project! Phases of Project Management Process ● Phase 1: Project Initiation ○ access size, scope and complexity, and establish procedures ○ Establish: ■ initiation team ■ relationship with customer ■ project initiation plan ■ management procedures ■ project management environment (using project software) ■ project workbook ● Phase 2: Project Planning ○ level of project planning detail should be high in the short term, with less detail as time goes on. ○ define clear discrete activities and the work needed to complete each activity ○ Tasks ■ define project scope, alternatives, feasibility ■ divide project into tasks ■ estimate resource requirements ■ develop preliminary schedule ■ develop communication plan ■ determine standards and procedures ■ identify and assess risk ■ create preliminary budget ■ develop a statement of work ■ set baseline project plan Some Components of Project Planning ● Statement of work (SOW) ○ contract between the IS staff and the customer regarding deliverables and time estimates for a system development project ● Baseline Project Plan (BPP) ○ contains estimates of scope, benefits, schedules, costs, risk, and resource requirements ● Preliminary Budget ○ cost benefit analysis of outlining planned expenses and revenues ● Work Breakdown Structure (WBS) ○ division of project into manageable and logically ordered tasks and subtasks ● Scheduling Diagrams ○ Gantt chart: horizontal bars represent task durations. Shows task duration, time overlap, and slack time in duration. ○ Network diagram: boxes and links represent task dependencies. Shows task dependencies, doesn’t show time overlap but shows parallelism, and shows slack time in boxes. ● Phase 3: Project Execution ○ Plans created in prior phases are put into action ○ Actions ■ execute baseline project plan ■ monitor progress against baseline plan ■ manage changes in baseline plan ■ maintain project workbook ■ communicate project status ● Phase 4: Project Closedown: Closedown the project, conduct post project reviews, and close the customer contract. ● Estimating Task Duration ○ PERT: Program Evaluation Review Technique ○ Technique that uses optimistic, pessimistic, and realistic time estimates to determine expected task duration ○ Formula to estimate time ■ ET = (o + 4r + p)/6 Critical Path: The shortest time in which a project can be completed. predecessor must come first. Contains no activities with slack time. Slack time: the time an activity can be delayed without delaying the project. (TETL) TE = exceeding event expected duration + expected duration. when moving forward, only add the LONGEST time TL = TE expected duration. When moving backwards, only add the SHORTEST time PERT analysis (ON EXAM) Program Evaluation Review Techniques to estimate time… ET = (o +4r +p)/6 optimistic, pessimistic, and realistic. Chapter 4 Identifying & Selecting IS Development Projects ✅ Project identification and selection process. Steps of Identifying & Selecting IS Development Projects 1. Identifying potential development projects. 1. topdown source: projects identified by top management or by a diverse steering committee 2. bottomup source: project initiatives stemming from managers, business units, or the development group 3. the process varies substantially across organizations. b. Classifying and ranking IS development projects. 1. using value chain analysis or other evaluation criteria 2. Value chain analysis: the process of analyzing an organization’s activities for making products and/or services to determine where value is added and costs are incurred. b. Selecting IS development projects 1. based on various factors 2. both short and long term projects considered 3. most likely to achieve business objectives selected 4. is a very important and ongoing activity 5. One method for deciding among different projects or alternative designs is the following: *see figure 44* 1. for each requirement or constraint… score = weight x rating 2. each alternative: sum scores across requirements/constraints 3. alternative with highest score wins Deliverables and Outcomes Schedule of specific IS development projects assurance that careful consideration was given to project selection and each project can help the organization reach its goals Incremental Commitment: project is reviewed after each phase and continuation of the project is rejustified Consequences of Poor Information Systems Planning cost of information systems systems may not handle applications that cross departments and organizational boundaries systems may not address business problems data redundancy & poor quality high maintenance costs frustrated users → create own systems → hodgepodge of systems, incompatible systems → systems analysis & design Systems Analysis & Design: business need → information need → info systems need → systems analysis & design ✅Describe corporate strategic planning & information systems planning. Corporate and Information Systems Planning To benefit from a planningbased approach for identifying and selecting projects, an organization must: o analyze its information needs thoroughly o plan its project carefully Corporate Strategic Planning Ongoing process that defines mission, objectives, and strategies of an organization Corporate strategy involves o mission statement: a statement that makes it clear what business a company is in o objective statement: a series of statements that express an organization’s qualitative and quantitative goals for reaching a desired future position o competitive strategy: the method by which an organization attempts to achieve its mission and objectives main types: low cost producer product differentiation product focus or niche Information Systems Planning (ISP) an orderly means of assessing the information needs of an organization and defining systems, databases, and technologies that will best meet those needs ISP must be done in accordance with the organization’s mission, objectives, and competitive strategy IS planning must be kept in line with corporate strategic planning ✅Explain the relationship between corporate strategic planning and IS planning. Top Down vs. Bottom Up IS Planning Top down planning: attempts to gain a broad understanding of the IS needs of the entire organization and offers. o broader perspective o improved integration o improved management support o better understanding Bottom up planning: identifies the IS development projects based on solving specific operational business problems or taking advantage of specific opportunities. o can be faster o less costly ✅Analyze IS planning matrices. Information Systems Planning Functional Decomposition: breaking high level abstract info into smaller units for more detailed planning Matrix Example: IS planning matrices describe relationships between pairs of organizational elements o location, function, business unit, objective, process, data, IS ✅Describe how IS planning can assist in system development project identification and selection. IS Plan Components Briefly describe Mission, objectives, and strategy of organization Provide summary of current and future processes, functions, data entities, and information needs of the enterprise. Describe primary role IS will play in the organization to transform enterprise from current to future state. Describe limitations imposed by technology and current levels of financial, technical, and personnel resources. Summarize overall information systems needs in the company and set longterm strategies for filling the needs. Show detailed inventory of present projects and systems and detailed plan for the current year. Describe unknown but likely events that can affect the plan, presently known business change elements and their impact on the plan. ✅Describe three classes of ECommerce ON EXAM come up with intangible costs/ benefits. examples? Chapter 5 Initiating & Planning Systems Development Projects ((Exam 2: Chapters 4 & 5 → 1 single page note sheet)) ✅ Steps involved in project initiation and planning Process of Initiating and Planning IS Development Projects Project initiation focuses on activities designed to assist in organizing a team to conduct project planning o Establishing the Project Initiation Team. o Establishing a Relationship with the Customer. o Establishing the Project Initiation Plan. o Establishing Management Procedures. o Establishing the Project Management Environment and Project Workbook. o Developing the Project Charter. The key activity of project initiation is the development of the project charter o a short document that is prepared for both internal and external stakeholders o provides a high level overview of the project o useful communication tool that helps to assure that the organizations and other stakeholders understand the initiation of a project A project charter typically contains: o Project title and date of authorization o Project manager name and contact information o Customer name and contact information o Projected start and completion dates o Key stakeholders, project role, and responsibilities o Project objectives and description o Key assumptions or approach o Signature section for key stakeholders The key activity of project planning: the process of defining clear, discrete activities and the work needed to complete each activity within a single project. The objective of the project planning: the development of a Baseline Project Plan (BPP) and the Project Scope Statement (PSS). ✅Need for Statement of Work and BPP Elements of Project Planning Describe project scope, alternatives, feasibility. Divide project into tasks. Estimate resource requirements and create resource plan. Develop preliminary schedule. Develop communication plan. Determine standards and procedures. Identify and assess risk. Create preliminary budget. Develop a statement of work. Set baseline project plan. Deliverables and Outcomes Business Case o Justification for an information system o Presented in terms of the tangible and intangible economic benefits and costs o The technical and organizational feasibility of the proposed system Baseline Project Plan (BPP): a document intended primarily to guide o A major outcome and deliverable from the PIP phase o Contains the best estimate of a project’s scope, benefits, costs, risks, and resource requirements o Sections: Intro, system description, feasibility assessment, management issues Building the Baseline Project Plan System description section outlines possible alternative solutions. Feasibility assessment section outlines issues related to project costs and benefits, technical difficulties, and other such concerns. Management issues section outlines a number of managerial concerns related to the project. Reviewing the Baseline Project Plan Structured Walkthroughs: a peergroup review of any product created during the system development process Roles: coordinator, presenter, user, secretary, standardbearer, maintenance oracle Can be applied to BPP, system specifications, logical and physical designs, program code, test procedures, manuals and documentation Project Scope Statement (PSS): is part of the BPP introduction o A document prepared for the customer o Describes what the project will deliver o Outlines at a high level all work required to complete the project Sections: o Problem statement o Problem objectives o Problem description o Problem benefits o Problem deliverables o Problem expected duration Factors Determining Scope: Organizational units affected by new system current systems that will interact with or change because of new system people who are affected by new system range of potential system capabilities ✅Tangible vs. intangible costs and benefits, and onetime vs. recurring costs. Determining Project Benefits Tangible benefits refer to items that can be measured in dollars and with certainty. o Most tangible benefits will fit within the following categories: Cost reduction and avoidance Error reduction Increased flexibility Increased speed of activity Improvement of management planning and control Opening new markets and increasing sales opportunities o Examples include: reduced personnel expenses, lower transaction costs, or higher profit margins. Intangible benefits are benefits derived from the creation of an information system that cannot be easily measured in dollars or with certainty. o May have direct organizational benefits, such as the improvement of employee morale. o May have broader societal implications, such as the reduction of waste creation or resource consumption. Determining Project Costs: Tangible & Intangible Costs Tangible cost: a cost associated with an information system that can be measured in dollars and with certainty IS development tangible costs include: o Hardware costs, o Labor costs, or o Operational costs including employee training and building renovations. Intangible cost: a cost associated with an information system that cannot be easily measured in terms of dollars or with certainty Intangible costs can include: o Loss of customer goodwill o Employee morale Project Costs One time vs. Recurring One time costs: a cost associated with project start up and development or system start up o These costs encompass activities such as: systems development new hardware and software purchases user training site preparation data or system conversion Recurring Cost: a cost resulting from ongoing evolution and use of a system o Examples of these costs include: application software maintenance incremental data storage expenses incremental communications new software and hardware leases supplies and other expenses (paper, forms, data center personnel) Project Costs Fixed vs. Variable Fixed costs are usually at a fixed rate. Variable costs are items that vary in relation to usage. o Note: Both onetime and recurring costs can consist of items that are fixed or variable in nature Other Types of Project Costs Procurement: Consulting, equipment, site preparation, capital, management Time Value of Money Concepts: Time Value of Money: the concept that money available today is worth more than the same amount in the future Discount rate: the rate of return used to compute the present value of future cash flows (the cost of capital) Present Value: the current value of a future cash flow. Net Present Value: use discount rate to determine present value of cash outlays and receipts ROI: ratio of cash receipts to cash outlays BEA: amount of time required for cumulative cash flow to equal initial and ongoing investment ✅Methods for assessing project feasibility. Assessing Project Feasibility economic, technical, operational, scheduling, legal and contractual, and political Economic Feasibility: a process of identifying the financial benefits and costs associated with a development project o often referred to as a cost benefit analysis o project is reviewed after each SDLC phase in order to decide whether to continue, redirect, or kill a project o See above terms Technical Feasibility: a process of assessing the development organization’s ability to construct a proposed system. o Potential consequences of not assessing and managing risks can include: failure to attain expected benefits of program Inaccurate project cost estimates, Inaccurate project duration estimates, Failure to achieve adequate system performance levels, and Failure to adequately integrate the new system with existing hardware, software, or organizational procedures. o 4 General rules as technical risk assessments: *See Figure 58* large projects are riskier than smaller projects system in which the requirements are easily obtained and highly structured will be less risky than one in which requirements are messy, ill structured, ill defined, or subject to the judgement of an individual development of a system employing commonly used or standard technology will be less risky than one employing novel or nonstandard technology A project is less risky when the user group is familiar with the systems development process and application area than if unfamiliar. Low Structure High Structure High familiarity with Technology Large low risk (very susceptible to low risk or application in use Project mismanagement) Small very low risk (very susceptible Very low risk Project mismanagement) Low familiarity with technology Large Very high risk Medium risk or application area Project Small High risk Mediumlow Project risk How can risks of IS projects be managed? o Risks can be managed on a project by changing the project plan to avoid risky factors assigning project team members to carefully manage the risky aspects setting up monitoring methods to determine whether or not the potential is….. Operational Feasibility: does the proposed system solve problems or take advantage of opportunities? Scheduling Feasibility: can the project time frame and completion dates meet organizational deadlines? Legal and contractual Feasibility: what are the legal contractual ramifications of the proposed system development project? Political Feasibility: how do key stakeholders view the proposed system? Project Risk Factors: Project Size: team size, organizational departments, project duration, programming effort Project structure: new vs. renovated system, resulting organizational changes, management commitment, user perceptions Development group: familiarity with platform, software, development method, application area, development of similar systems User Groups: familiarity with IS development process, application area, use of similar systems Chapter 6 Determining System Requirements The Process of Determining Requirements good systems analyst characteristics o impertinence question everything o impartiality consider all issues to find the best organizational solution o Relaxing constraints o attention to details every fact must fit o reframing challenge yourself to new ways Deliverables and Outcomes Deliverables for requirements determination o interviews and observations interview transcripts, observation notes, meeting minutes o existing written docs mission and strategy statements, business forms, procedure manuals, job descriptions, training manuals, system docs, flowcharts o computerized sources joint application design session results, CASE repositories, reports from existing systems, displays and reports from systems prototypes Traditional Methods for Determining Requirements interviewing individuals and/or groups observing workers studying business documents Interviewing & Listening One of the primary ways analysts gather info about an IS project Interview Guide is a document for developing, planning and conducting an interview Guidelines for Effective interviewing: o plan the interview prepare interviewee: appt, primary questions prepare agenda, checklist, questions o listen carefully and take notes o review notes within 48hrs o be neutral o seek diverse views Choosing Interview Questions: o each question in an interview guide can include both verbal and nonverbal information open ended questions: questions that have no prespecified answers close ended questions: ones that ask those responding to choose from among a set of specified responses Interviewing Groups: o Drawbacks to individual interviews: contradictions and inconsistencies between interviewees follow up discussions are time consuming new interviews may reveal new questions that require additional interviews with those interviewed earlier Interviewing several key people together: Advantages: more effective use of time, can hear agreements and disagreements at once, and opportunities for synergies Disadvantages: more difficult to schedule than individual interviews Nominal Group Techniques (NGT) a facilitated process that supports idea generation by groups the process: o members come together as a group, but initially work separately o group openly discusses the ideas for clarification o ideas are prioritized, combined, selected, and reduced NGT exercise used to complement group meetings or as part of JAD effort Directly Observing Users Direct observation: o watching users do their jobs o obtaining more firsthand and objective measures of employee interaction with IS o can cause people to change their normal operating behavior o time consuming and limited time to observe Analyzing Procedures & Other Documents Document analysis: review of existing business docs. Can give a historical and “Formal” view of system requirements Types of information to be discovered: o problems with existing system o opportunity to meet new need o organizational direction o names of key individuals o values of organization o special information processing circumstances o reasons for current system design o rules for processing data Useful document: written work procedures o for an individual or work group o describes how a particular job/task is performed o includes data and info used to create the process Potential problems with procedure documents: o may involve duplication of effort o may have missing procedures o may be out of date o may contradict info obtained through interviews Formal Systems: the official way a systemworks as described in organizational docs o Informal Systems: the way a system actually works Useful document: business form o used for all types of business functions o explicitly indicated what data flow in and out of a system and data necessary for the system to function o gives crucial information about the nature of the organization Useful document: report o primary output of current system o enables you to work backwards from the report to the data needed to generate it Useful document: description of current information system Contemporary Methods for Determining System Requirements Joint Application Design (JAD) o brings together key users, managers, and systems analysts o purpose: collect system requirements simultaneously from key people o conducted off site o intensive group oriented o team members meet in isolation for an extended period of time o highly focused, resource intensive o started by IBM in 1970 o Participants: Session Leader: facilitates group process users: active speaking participants managers: active speaking participants sponsor systems analysts scribe IS staff o End Result: documentation of existing system features of proposed system o CASE tools enable analysts to enter system models directly into CASE during the JAD session Group support system o facilitate sharing of ideas and voicing of opinions about systems requirements CASE tools o used to analyze existing systems o help discover requirements to meet changing business conditions System prototypes o iterative development process o rudimentary working version of system is built o refine understanding of system requirements in concrete terms Using Prototyping During Requirements Determination 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: o user requests are not clear o few users are involved in the system o designs are complex and require concrete form o there is a history of communication problems between analysts and users o tools are readily available to build prototype Drawbacks: o tendency to avoid formal documentation o difficult to adapt to more general user audience o sharing data with other systems is often not considered o SDLC checks are often bypassed Radical Methods for Determining Systems Requirements Business Process REengineering (BPR): search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services Goals: o reorganize complete flow of data in major sections of an organization o eliminate unnecessary steps o combine steps and become more responsive to future change Identification of processes to reengineer key business processes: Structured, measured set of activities designed to produce specific output for a particular customer or market Focused on customers and outcome Same techniques are used as for requirements determination Disruptive Technologies Information technologies must be applied to radically improve business processes Disruptive technologies are technologies that enable the breaking of longheld business rules that inhibit organizations from making radical business changes. Using Agile Methodologies During Requirements Determination Continual user involvement o replace traditional SDLC waterfall with iterative analyze design code test cycle Agile usagecentered design o focused on user goals, roles, and tasks o The Steps: The Planning Gameep through and modify the prototype.kteftr .each user role.tator. o based on eXtreme programming o exploration, steering, commitment Chapter 7 Structuring System Process Requirements Process Modeling Graphically represent the process that capture, manipulate, store, and distribute data between a system and its environment and among system components Utilize information gathered during requirements determination Process and data structures are modeled Deliverables & Outcomes context data flow diagrams (DFD) o scope of system DFDs of current and new system o adequate detail only o enables analysts to understand current system DFDs of new logical system o technology independent o show data flows, structure, and functional requirements of new system Thorough description of each DFD component Data Flow Diagramming Mechanics Represent both physical and logical information systems Only four symbols are used Useful for depicting purely logical information flows DFDs that detail physical systems differ from system flowcharts Definitions & Symbols Process: work or actions performed on data (inside the system) Data store: data at rest (inside the system) Source/sink: external entity that is origin or destination of data (outside the system) Data flow: arrows depicting movement of data Developing DFDs: Context Diagram Context diagram is an overview of an organizational system that shows: o the system boundaries o external entities that interact with the system o major information flows between the entities and the system Note: only one process symbol, and no data stores shown Developing DFDs: Level 0 Diagram Level 0 Diagram is a DfD that represents a system’s major processes, data flows, and data stores at a high level of detail ON EXAM : identify the rules and know errors in diagram DFD Rules THere are two DFD guidelines that apply: o the inputs to a process are different from the outputs of that process processes purpose is to transform inputs into output o objects on a DFD have unique names every process has a unique name Process: no process can have only outputs, it is making data from nothing. If an object has only outputs then it must be a source no process can have only inputs. if an object has ony inputs then it must be a sink a process has a verb phrase label Data Store: data cannot move directly from one datastore to another data store. Data must be moved by a process data cannot move directly from an outside source to a datastore. data must be moved by a process that receives data from the source and places the data into the data store data cannot move directly to an outside sink from a data store. Data must be moved by a process a data store has a noun phrase label Source/Sink data cannot move directly from a source to a sink. It must be moved by a process if the data are of any concern to our system. Otherwise, the data flow is not shown on the DFD a source/sink has a noun phrase label Data Flow: a data flow has only one direction of flow between symbols. It may flow in both directions between a process and a data store to show a read before an update. a fork in a dataflow means that exactly the same data goes from a common location to two or more different processes, data stores, or source/sinks. a join in a data flow means that exactly the same data come from any of two or more different processes, datastores, or source/sinks to a common location a data flow cannot go directly back to the same process it leaves. there must be at least one other process that handles the data flow, produces some other data flow, and returns the original data flow to the beginning process a data flow to a data store means update a data flow from a data store means retrieve or use a data flow has a noun phrase label. more than one data flow noun phrase can appear on a single arrow as long as all of the flows on the same arrow move together as one package. Decomposition of DFDs Functional decomposition is an iterative process of breaking a system description down into finer and finer detail o Creates a set of charts in which one process on a given chart is explained in greater detail on another chart. o Continues until no subprocess can logically be broken down any further. Primitive DFD is the lowest level of a DFD Level 1 (1.1) results from decomposition of Level 0 diagram Level n is a DFD diagram that is the result of n nested decomposition from a process on … Balancing DFDs: Conservation of inputs and outputs Conservation Principle: conserve inputs and outputs to a process at the next level of decomposition Balancing: conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a lower level Balanced means: o Number of inputs to lower level DFD equals number of inputs to associated process of higherlevel DFD o Number of outputs to lower level DFD equals number of outputs to associated process of higherlevel DFD Balancing DFDs: Data Flow Splitting Data flow splitting is when a composite data flow at a higher level is split and different parts go to different processes in the lower level DFD. The DFD remains balanced because the same data is involved, but split into two parts. Guidelines for Drawing DFDs Completeness o DFD must include all components necessary for system. o Each component must be fully described in the project dictionary or CASE repository. Consistency o The extent to which information contained on one level of a set of nested DFDs is also included on other levels Timing o Time is not represented well on DFDs. o Best to draw DFDs as if the system has never started and will never stop. Iterative Development o Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled. Primitive DFDs o Lowest logical level of decomposition o Decision has to be made when to stop decomposition Rules for stopping decomposition o When each process has been reduced to a single decision, calculation or database operation o When each data store represents data about a single entity o When the system user does not care to see any more detail o When every data flow does not need to be split further to show that data are handled in various ways o When you believe that you have shown each business form or transaction, online display and report as a single data flow o When you believe that there is a separate process for each choice on all lowest level menu options Using DFDs as Analysis Tools Gap Analysis is 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. Modeling Logic with Decision Tables Decision table: a matrix representation of the logic of a decision which specifies the possible conditions for the decision and the resulting actions Best used for complicated decision logic Condition stubs: that part of a decision table that lists the conditions relevant to the decision Action stubs: that part of a decision table that lists the actions that result for a given set of conditions Rules: that part of a decision table that specifies which actions are to be followed for a given set of conditions Indifferent condition: in a decision table, a condition whose value does not affect which actions are taken for two or more rules Procedure for Creating Decision Tables o Name the condition and the values that each condition can assume. o Name all possible actions that can occur. o List all possible rules. o Define the actions for each rule. o Simplify the table. Appendix A Chapter 8 Structuring System Data Requirements Conceptual Data Modeling Conceptual data modeling: a detailed model that captures the overall structure of data in an organization. o independent of any database management system (DBMS) or other implementation considerations The Conceptual Data Modeling Process: o develop a data model for the current system o develop a new conceptual data model that includes all requirements of the new system o in the design stage, the conceptual data model is translated into a physical design o project repository links all design and data modeling steps performed during SDLC. Deliverables & Outcome Primary deliverable is an entity relationship diagram or class diagram Several types of ER are produced and analyzed: o ER diagram that covers data needed in the project’s application o ER diagram for the application being replaced o ER diagram for the whole database from which the new application’s data are extracted o ER diagram diagram for the whole databases from which data for the application system being replaced is drawn Second deliverable is a set of entries about data objects to be stored in repository or project dictionary o Repository links data, process, and logic models of an IS o Data elements included in the DFD must appear in the data model and vice versa o Each data store in a process model must relate to business objects represented in the data model Gathering Information for Conceptual Data Modeling Two perspectives on data modeling: o Topdown approach for a data model is derived from an intimate understanding of the business. o Bottomup approach for a data model is derived by reviewing specifications and business documents. Requirements Determination Questions for Data Modeling: o What are subjects/objects of the business? Data entities and descriptions o What unique characteristics distinguish between subjects/objects of the same type? Primary keys o What characteristics describe each subject/object? Attributes and secondary keys o How do you use the data? Security controls and user access privileges o Over what period of time are you interested in the data? Cardinality and time dimensions o Are all instances of each object the same? Supertypes, subtypes, and aggregations o What events occur that imply associations between objects? Relationships and cardinalities o Are there special circumstances that affect the way events are handled? Integrity rules, cardinalities, time dimensions Introduction to ER Modeling Entity Relationship data model: a detailed, logical representation of the entities, associations, and data elements for an organization or business area Entity Relationship diagram: a graphical representation of an ER model The ER model is expressed in terms of: o data entities in the business environment o relationships or associations among those entities o attributes or properties of both the entities and their relationships o Entity: a person, place, object, event or concept in the user environment about which data is to be maintained o Entity type: collection of entities that share common properties or characteristics o Entity instance: single occurrence of an entity type o Relationship: an association between the instances of one or more entity types that is of interest to the organization Names and Defining Entity Types An entity type name should be: o A singular noun. o Descriptive and specific to the organization. o Concise. Event entity type should be named for the result of the event, not the activity or process of the event. An entity type definition should: o Include a statement of what the unique characteristic(s) is (are) for each instance. o Make clear what entity instances are included and not included in the entity type. o Often include a description of when an instance of the entity type is created or deleted. For some entity types the definition must specify: o When an instance might change into an instance of another entity type. o What history is to be kept about entity instances. Attributes Attribute: a named property or characteristic of an entity that is of interest to the organization o naming an attribute: ie Vehicle_ID An attribute name is a noun and should be unique to make an attribute name unique for clarity, each attribute name should follow a standard format similar attributes of different entity types should use similar but distinguishing names o place its name inside the rectangle for the associated entity in the ER diagram An attribute definition: o States what the attribute is and possibly why it is important. o Should make it clear what is included and what is not included. o Contain any aliases or alternative names.
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'