information systems best notes

371
Information Systems Analysis and Design Myriam Lewkowicz

Upload: elettersmail9384

Post on 09-Nov-2015

39 views

Category:

Documents


2 download

DESCRIPTION

IIS PPT

TRANSCRIPT

  • Information SystemsAnalysis and DesignMyriam Lewkowicz

    [email protected]

  • [email protected]*OutlineInformation Systems: the big pictureInformation Systems for competitive advantageOrganizational Information SystemsEntreprise-Wide Information SystemsInformation Systems Development & AcquisitionManaging the Information Systems ProjectSystems Planning Determining System RequirementsStructuring System Requirements: Process ModelingStructuring System Requirements: Conceptual Data ModelingObject Oriented Analysis and DesignDesigning the Human InterfaceSystems Implementation and Operation

    [email protected]

  • Chapter 1

    Information Systems:The Big Picture

    [email protected]

  • [email protected]*Chapter 1 ObjectivesUnderstand the term information systems (IS)Understand IS components:Technology, people, organizationsUnderstand IS career opportunitiesUnderstand types of information systemsUnderstand IS and organizational success or failureUnderstand the future of IS management

    [email protected]

  • [email protected]*Information Systems Defined Combinations of hardware, software, and telecommunications networks that people build and use to collect, create, and distribute useful data in organizations

    [email protected]

  • [email protected]*Key Elements of Information Systems

    [email protected]

  • [email protected]*DataData: raw material, unformatted informationInformation: processed data (meaningful)Knowledge: understanding relationships between pieces of informationWisdom: knowledge accumulated and applied

    [email protected]

  • [email protected]*Knowledge as a Business ResourceKnowledge WorkerA well-educated professional who creates, modifies, or synthesizes knowledge in ones professionKnowledge SocietyAlso called digital society, new economyWorking with brains instead of handsThe importance of educationDigital divide

    [email protected]

  • [email protected]*Technology and Information SystemsComputer-Based Information SystemsOne type of technologyTechnology any mechanical and/or electrical means to supplement, extend, or replace human activityInformation Technology (IT) machine technology controlled by or using information

    The goal of IS is to provide useful data to usersIS can be local or global, organizational or enterprise-wide

    [email protected]

  • [email protected]*IS Managerial PersonnelCIOIS directorAccount ExecutiveInfo Center ManagerDevelopment ManagerProject ManagerMaintenance ManagerSystems ManagerIS planning ManagerOperations ManagerProgramming Manager

    Systems Programming ManagerManager of Emerging TechnologiesTelecommunications ManagerNetwork ManagerDatabase AdministratorAuditing or Computer Security ManagerQuality Assurance ManagerWebmaster

    [email protected]

  • [email protected]*Integrating Skills and KnowledgeTechnologyhardware, software, networkingBusinessbusiness, management, social, communicationsSystemsIntegration, development methods, critical thinking, problem solving

    [email protected]

  • [email protected]*Hot Skills in IS WorkersOffice / E-mailLanguagesApplicationsRDBS AdministrationDevelopment ToolsInternetworkingOperating SystemsLAN AdministrationNetworking

    [email protected]

  • [email protected]*IS Within the FirmTraditionally a love/hate relationshipTechies vs. mere users (us vs. them)Poor service, lousy attitudesNow: progress toward better customer serviceBetter relationships within the companyCooperation, not rivalry

    [email protected]

  • [email protected]*The Spread of Technology in OrganizationsTechnology infiltrates business unitsDual role for IS workers:Work with IS technical groupWork with business unit (marketing, finance, etc.)

    [email protected]

  • [email protected]*The Spread of Technology in OrganizationsBenefits of centralized IS functionCoordinated planningConsistent managementSystems compatibility and connectivity

    [email protected]

  • [email protected]*QuestionsDefine and understand the term information systems (IS)Explain the technology, people, and organizational components of an information system.

    [email protected]

  • Chapter 2

    Information Systems for Competitive Advantage

    [email protected]

  • [email protected]*Chapter 2 ObjectivesUnderstand the IS in automation, organizational learning, and strategic supportUnderstand IS for strategic organizational successUnderstand the need for making an IS business caseUnderstand technological innovations to improve competitive advantage

    [email protected]

  • [email protected]*Why Use Information Systems?Automating: doing things fasterOrganizational learning: doing things betterSupporting Strategy: doing things smarter

    [email protected]

  • [email protected]*Automating: Doing Things FasterTechnology is used to automate a manual processDoing things faster, better, cheaperGreater accuracy and consistencyLoan application exampleManual processingTechnology-supported processCompletely automated

    [email protected]

  • [email protected]*Organizational Learning: Doing Things BetterGoing beyond automationInvolves learning to improve the day-to-day activities within the processLooking at patterns and trendsOrganizational LearningUsing acquired knowledge and insights to improve organizational behaviorTotal Quality Management (TQM)Monitoring an organization to improve quality of operations, products, and services

    [email protected]

  • [email protected]*Supporting Strategy: Doing Things SmarterStrategic PlanningCreate a vision: setting the directionCreate a standard: performance targetsCreate a strategy: reaching the goal

    [email protected]

  • [email protected]*QuestionNow, it should be fairly obvious why an IS professional should be able to make a business case for a given system. Why, however, is it just as important for non-IS professionals? How are they involved in this process? What is their role in information systems planning?

    [email protected]

  • Chapter 3OrganizationalInformation Systems

    [email protected]

  • [email protected]*Chapter ObjectivesUnderstand characteristics of operational, managerial, and executive information systemsUnderstand characteristics of transaction processing systems, management information systems, and executive information systemsUnderstand characteristics of information systems that span organizational boundaries

    [email protected]

  • [email protected]*Decision-Making Levels of an Organization

    [email protected]

  • [email protected]*Decision-Making Levels of an Organization Executive level (top)Long-term decisionsUnstructured decisionsManagerial level (middle)Decisions covering weeks and monthsSemistructured decisionsOperational level (bottom)Day-to-day decisionsStructured decisions

    [email protected]

  • [email protected]*General Types of Information Systems Transaction Processing Systems (TPSs)TransactionsUsed at Operational level of the organizationGoal: to automate repetitive information processing activitiesIncrease speedIncrease accuracyGreater efficiency

    [email protected]

  • [email protected]*General Types of Information SystemsData inputManual data entrySemiautomated data entryFully automated data entryExamples:PayrollSales and orderingInventoryPurchasing, receiving, shippingAccounts payable and receivable

    [email protected]

  • [email protected]*General Types of Information Systems Management Information Systems (MISs)Two Types:Management of IS in organizationsSpecific information systems for mid-level managersUsed at managerial level of the organization

    [email protected]

  • [email protected]*General Types of Information Systems Management Information SystemsTypes of reports:Scheduled reportKey-indicator reportException reportDrill-down reportAd hoc report

    [email protected]

  • [email protected]*General Types of Information Systems Management Information Systems (MISs)Examples:Sales forecastingFinancial management and forecastingManufacturing planning and schedulingInventory management and planningAdvertising and product pricing

    [email protected]

  • [email protected]*General Types of Information Systems Executive Information Systems (EISs)Used at executive level of the organizationHighly aggregated formData typesSoft data news and nonanalytical dataHard data facts and numbers

    [email protected]

  • [email protected]*General Types of Information Systems Executive Information Systems (EISs)Examples:Executive-level decision makingLong-range and strategic planningMonitoring internal and external eventsCrisis managementStaffing and labor relations

    [email protected]

  • [email protected]*1.*

    [email protected]

  • [email protected]*Information Systems that Span Organizational Boundaries

    [email protected]

  • [email protected]*Information Systems that Span Organizational BoundariesDecision Support Systems (DSSs)Designed to support organizational decision makingWhat-if analysisExample of a DSS tool: Microsoft ExcelText and graphsModels for each of the functional areasAccounting, finance, personnel, etc.

    [email protected]

  • [email protected]*Information Systems that Span Organizational BoundariesExpert Systems (ESs)Mimics human expertise by manipulating knowledgeRules (If-then)Inferencing

    [email protected]

  • [email protected]*Information Systems that Span Organizational BoundariesOffice Automation Systems (OASs)Examples:Communicating and schedulingDocument preparationAnalyzing dataConsolidating information

    [email protected]

  • [email protected]*Information Systems that Span Organizational BoundariesCollaboration TechnologiesVirtual teamsVideoconferencingGroupwareElectronic Meeting Systems (EMSs)

    [email protected]

  • [email protected]*Information Systems that Span Organizational BoundariesFunctional Area Information SystemsGeared toward specific areas in the company:Human ResourcesBenefitsMarketing

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Information Systems that Span Organizational BoundariesGlobal Information SystemsInternational ISTransnational ISMultinational ISGlobal IS

    [email protected]

  • Chapter 4Enterprise-WideInformation Systems

    [email protected]

  • [email protected]*Chapter ObjectivesUnderstand how information technology supports business activitiesUnderstand enterprise systems and how they evolvedUnderstand software applications that are internally or externally focusedUnderstand how to implement enterprise systems

    [email protected]

  • [email protected]*Enterprise SystemsEnterprise systemsAlso known as enterprise-wide information systemsInformation systems that allow companies to integrate information across operations on a company-wide basis

    [email protected]

  • [email protected]*Before an entreprise system

    [email protected]

  • [email protected]*With an entreprise sytem

    [email protected]

  • [email protected]*Types of Enterprise SystemsPackaged applicationsCustom applicationsStand-alone applications

    [email protected]

  • [email protected]*Types of Enterprise SystemsEnterprise Resource PlanningIntegrated applicationsERP systemsBaanOraclePeopleSoftSAP

    [email protected]

  • [email protected]*Types of Enterprise SystemsERP ImplementationModulesCustomizationsBest practicesBusiness process reengineering (BPR)

    [email protected]

  • [email protected]*Types of Enterprise SystemsCustomer Relationship Management (CRM)Sales Force Automation (SFA)New opportunities for competitive advantageExamples:MGMAmerican AirlinesMarriott International

    [email protected]

  • [email protected]*CRM system

    [email protected]

  • [email protected]*Types of Enterprise SystemsSupply Chain Management (SCM)Supply chain the producers of supplies that a company usesSupply networkWhat if supply chain does not collaborate?Two objectives of upstream information flow:Accelerate product developmentReduce costs associated with suppliers

    [email protected]

  • [email protected]*Supply chain management

    [email protected]

  • [email protected]*The Formula for Enterprise System SuccessSecure executive sponsorshipGet help from outside expertsThoroughly train usersTake a multidisciplinary approach to implementation

    [email protected]

  • [email protected]*QuestionsList the different classes of information systems described in this chapter. How do they differ from each other? Of the information systems listed in the chapter, how many do you have experience with? What systems would you like to work with? What types of systems do you encounter at the university you are attending? Consider an organization that you are familiar with, perhaps the one in which you work or one with which you have done business. Describe the type of information systems that organization uses and whether or not they are useful or up-to-date. List specific examples for updating or installing information systems that improve productivity or efficiency.

    [email protected]

  • Chapter 5Information SystemsDevelopment & Acquisition

    [email protected]

  • [email protected]*Chapter ObjectivesUnderstand the process of IS managementUnderstand the system development life cycle (SDLC)Understand alternative approaches to system developmentUnderstand in-house system developmentUnderstand external acquisition, outsourcing, and end-user development

    [email protected]

  • [email protected]*The Need for Structured Systems DevelopmentSystems analysis and design the process of designing, building, and maintaining information systemsSystems analystBlending technical and managerial expertise

    [email protected]

  • [email protected]*The Need for Structured Systems DevelopmentEvolution of IS developmentFrom art to a disciplineStandardized development methodsSoftware engineering

    [email protected]

  • [email protected]*The Need for Structured Systems DevelopmentOptions for Obtaining Information SystemsBuild your ownBuy a prepackaged systemOutsource development to a 3rd partyEnd user development

    [email protected]

  • [email protected]*The Need for Structured Systems DevelopmentInformation Systems Development in ActionBreaking large complex problems into manageable piecesDecomposing large, complex problems

    [email protected]

  • [email protected]*The Need for Structured Systems DevelopmentSystem Construction ProcessIdentify a large IT problem to solve Break the large problem into several smaller, more manageable piecesTranslate each piece (small problem) into computer programsPiece together each program into an overall comprehensive IS that solves the problem

    [email protected]

  • [email protected]*The Need for Structured Systems DevelopmentThe Role of Users in the Systems Development ProcessKnowledgeable of needsEffective partnership

    [email protected]

  • [email protected]*Information Systems Analysis and DesignSystems Analyst performs analysis and design based upon:Understanding of organizations objectives, structure and processesKnowledge of how to exploit information technology for advantage

    [email protected]

  • [email protected]*Systems Analysis and Design: Core ConceptsMajor goal: to improve organizational systems by developing or acquiring software and training employees in its useApplication software, or a system, supports organizational functions or processes

    [email protected]

  • [email protected]*Systems Analysis and Design: Core ConceptsSystem: Turns data into information and includes:Hardware and system softwareDocumentation and training materialsJob roles associated with the systemControls to prevent theft or fraudThe people who use the software to perform their jobs

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Software Engineering ProcessA process used to create an information systemConsists of:MethodologiesA sequence of step-by-step approaches that help develop the information systemTechniquesProcesses that the analyst follows to ensure thorough, complete and comprehensive analysis and designToolsComputer programs that aid in applying techniques

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*SystemA system is an interrelated set of business procedures used within one business unit working together for a purposeA system has nine characteristicsA system exists within an environmentA boundary separates a system from its environment

    [email protected]

  • [email protected]*Characteristics of a SystemComponentsInterrelated ComponentsBoundaryPurposeEnvironmentInterfacesConstraintsInputOutput

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Important System ConceptsDecompositionThe process of breaking down a system into smaller componentsAllows the systems analyst to:Break a system into small, manageable subsystemsFocus on one area at a timeConcentrate on component pertinent to one group of usersBuild different components at independent times

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Important System ConceptsModularityProcess of dividing a system into modules of a relatively uniform sizeModules simplify system designCouplingSubsystems that are dependent upon each other are coupledCohesionExtent to which a subsystem performs a single function

    [email protected]

  • [email protected]*A Modern Approach to Systems Analysis and DesignSystems IntegrationAllows hardware and software from different vendors to work togetherEnables procedural language systems to work with visual programming systemsVisual programming environment uses client/server model

    [email protected]

  • [email protected]*Data and ProcessesThree key components of an information systemDataData FlowsProcessing LogicData vs. InformationDataRaw factsInformationDerived from dataOrganized in a manner that humans can understand

    [email protected]

  • [email protected]*Data and ProcessesDataUnderstanding the source and use of data is key to good system designVarious techniques are used to describe data and the relationship amongst dataData FlowsGroups of data that move and flow through the systemInclude description of sources and destination for each data flowProcessing LogicDescribe steps that transform data and events that trigger the steps

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Approaches to Systems DevelopmentProcess-Oriented ApproachFocus is on flow, use and transformation of data in an information systemInvolves creating graphical representations such as data flow diagrams and chartsData are tracked from sources, through intermediate steps and to final destinationsNatural structure of data is not specifiedDisadvantage: data files are tied to specific applications

    [email protected]

  • [email protected]*Approaches to Systems Development (2)Data-Oriented ApproachDepicts ideal organization of data, independent of where and how data are usedData model describes kinds of data and business relationships among the dataBusiness rules depict how organization captures and processes the data

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Databases and Application IndependenceDatabaseShared collection of logically related dataOrganized to facilitate capture, storage and retrieval by multiple usersCentrally managedDesigned around subjectsCustomersSuppliersApplication IndependenceSeparation of data and definition of data from applications

    [email protected]

  • [email protected]*Role of the Systems AnalystStudy problems and needs of an organizationDetermine best approach to improving organization through use of:PeopleMethodsInformation technologyHelp system users and managers define their requirements for new or enhanced systems

    [email protected]

  • [email protected]*Role of the Systems AnalystAssess options for system implementationIn-house developmentOutsourced developmentOutsourced development and operationCommercial applicationFor in-house projects, work on a team of analysts and developers

    [email protected]

  • [email protected]*Skills of a Successful Systems AnalystAnalyticalUnderstanding of organizationsProblem-solving skillsSystem thinkingAbility to see organizations and information systems as systemsTechnicalUnderstanding of potential and limitations of technologyManagerialAbility to manage projects, resources, risk and changeInterpersonalEffective written and oral communication skills

    [email protected]

  • [email protected]*Systems Development Life CycleSystem Development MethodologyStandard process followed in an organizationConsists of:AnalysisDesignImplementationMaintenance

    [email protected]

  • [email protected]*Systems Development Life CycleSeries of steps used to manage the phases of development for an information systemConsists of four phases:Planning and SelectionAnalysisDesignImplementation and Operation

    [email protected]

  • [email protected]*Systems Development Life CyclePhases are not necessarily sequentialEach phase has a specific outcome and deliverableIndividual companies use customized life cycle

    [email protected]

  • [email protected]*Phases of the Systems Development Life CycleSystems Planning and SelectionTwo Main ActivitiesIdentification of needInvestigation and determination of scopeSystems AnalysisStudy of current procedures and information systemsDetermine requirementsGenerate alternative designsCompare alternativesRecommend best alternative

    [email protected]

  • [email protected]*Systems Development Life CycleSystem DesignLogical DesignConcentrates on business aspects of the systemPhysical DesignTechnical specificationsImplementation and OperationImplementationHardware and software installationProgrammingUser TrainingDocumentationOperationSystem changed to reflect changing conditionsSystem obsolescence

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Alternative approachesPrototypingBuilding a scaled-down working version of the systemAdvantages:Users are involved in designCaptures requirements in concrete formRapid Application Development (RAD)Utilizes prototyping to delay producing system design until after user requirements are clearJoint Application Design (JAD)Users, Managers and Analysts work together for several daysSystem requirements are reviewedStructured meetings

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*SummaryInformation systems analysis and designProcess of developing and maintaining an information systemModern approach to systems analysisProcess-OrientedData-Oriented

    [email protected]

  • [email protected]*SummarySystems Development Life Cycle (SDLC)Systems Planning and SelectionSystems AnalysisSystems DesignSystems ImplementationAlternatives to Systems Development Life CyclePrototypingRapid Application Development (RAD)Joint Application Design (JAD)

    [email protected]

  • [email protected]*QuestionsIn what way are organizations systems?List and explain the different phases in the systems development life cycle.Why is it important to use systems analysis and design methodologies when building a system? Why not just build the system in whatever way seems to be quick and easy? What value is provided by using an engineering approach? Explain the traditional application-based approach to systems development. How is this different from the data-based approach?What is prototyping?What is JAD? What is Participatory Design?

    [email protected]

  • Chapter 6 Managing the Information Systems Project

    [email protected]

  • [email protected]*Learning ObjectivesDiscuss skills required to be an effective project managerDescribe skills and activities of a project manager during project initiation, planning, execution and closedownExplain Gantt Charts and Network DiagramsReview commercial project management software packages

    [email protected]

  • [email protected]*Case of Pine Valley FurnitureManufacturing CompanyProduct: Wood FurnitureMarket: U.S.Organized into functional areasManufacturingSalesThree independent computer systems were converted to a database in 1990s

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Managing the Information Systems ProjectFocus of project managementTo ensure that information system projects meet customer expectationsDelivered in a timely mannerMeet constraints and requirements

    [email protected]

  • [email protected]*Project ManagerSystems Analyst responsible forProject initiationPlanningExecutionClosing downRequires diverse set of skillsManagementLeadershipTechnicalConflict managementCustomer relationsManaging the Information Systems Project

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Project Management ProcessProjectPlanned undertaking of related activities to reach an objective that has a beginning and an endFour PhasesInitiationPlanningExecutionClosing down

    [email protected]

  • [email protected]*Initiating the ProjectEstablish project initiation teamEstablish relationship with customerEstablish project initiation planEstablish management proceduresEstablish project management environment and workbook

    [email protected]

  • [email protected]*Planning the ProjectDescribe project scope, alternatives and feasibilityScope and FeasibilityUnderstand the projectWhat problem is addressedWhat results are to be achievedMeasures of successCompletion criteria

    [email protected]

  • [email protected]*Planning the ProjectDivide the project into manageable tasksWork breakdown structureGantt chartEstimate resources and create a resource planDevelop a preliminary scheduleUtilize Gantt Charts and Network DiagramsDevelop a communication planOutline communication processes among customers, team members and managementTypes of reportsFrequency of reports

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Planning the ProjectDetermine project standards and proceduresSpecify how deliverables are tested and producedIdentify and assess riskIdentify sources of riskEstimate consequences of riskCreate a preliminary budgetDevelop a statement of workDescribe what the project will deliverSet a baseline project planEstimate of projects tasks and resources

    [email protected]

  • [email protected]*Executing the ProjectExecute baseline project planAcquire and assign resourcesTrain new team membersKeep project on scheduleMonitor project progressAdjust resources, budget and/or activitiesManage changes to baseline project planSlipped completion datesChanges in personnelNew activitiesMaintain project workbookCommunicate project status

    [email protected]

  • [email protected]*Closing Down the ProjectTerminationTypes of terminationNaturalRequirements have been metUnnaturalProject stoppedDocumentationPersonnel AppraisalConduct post-project reviewsDetermine strengths and weaknesses of:Project deliverablesProject management processDevelopment processClose customer contract

    [email protected]

  • [email protected]*Representing and Scheduling Project PlansGantt ChartsUseful for depicting simple projects or parts of large projectsShow start and completion dates for individual tasksNetwork DiagramsShow order of activities

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*SummarySkills of an effective project managerActivities of project managerInitiationPlanningExecutionClosedownGantt Charts and Network DiagramsCommercial PM Software

    [email protected]

  • [email protected]*QuestionsList and describe the common skills and activities of a project manager. Which skill do you think is most important? Why?Describe the activities performed by the project manager during project initiation.Describe the activities performed by the project manager during project planning.Describe the activities performed by the project manager during project execution.

    [email protected]

  • Chapter 7 Systems Planning

    [email protected]

  • [email protected]*Learning ObjectivesDiscuss the content of and need for a Statement of Work and Baseline Project PlanDescribe a structured walkthrough

    [email protected]

  • [email protected]*First documentsBaseline Project Plan (BPP) : internal documentScopeBenefitsCostsRisksResourcesStatement of Work (SOW) : Outlines objectives and constraints of the project to the customerDescribes deliverablesOutlines work needed to be performed

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Building the Baseline Project PlanObjectivesAssures that customer and development group have a complete understanding of the proposed system and requirementsProvides sponsoring organization with a clear idea of scope, benefits and duration of projectFour SectionsIntroductionSystem DescriptionFeasibility AssessmentManagement Issues

    [email protected]

  • [email protected]*Building the Baseline Project PlanIntroductionBrief overviewRecommended course of actionProject scope definedUnits affectedInteraction with other systemsRange of system capabilities

    [email protected]

  • [email protected]*Building the Baseline Project PlanSystem DescriptionOutline of possible alternative solutionsNarrative formatFeasibility AssessmentProject costs and benefitsTechnical difficultiesHigh-level project schedule

    [email protected]

  • [email protected]*Building the Baseline Project PlanManagement IssuesOutlines concerns that management may have about the projectTeam compositionCommunication planProject standards and procedures

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Reviewing the Baseline Project PlanObjectivesAssure conformity to organizational standardsAll parties agree to continue with project

    [email protected]

  • [email protected]*Reviewing the Baseline Project PlanWalkthroughPeer group reviewParticipantsCoordinatorPresenterUserSecretaryStandards BearerMaintenance OracleActivitiesWalkthrough review formIndividuals polledWalkthrough action listAdvantagesAssures that review occurs during project

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*SummaryBaseline Project Plan (BPP)Created during project initiation and planningContains:IntroductionHigh-Level description of systemOutline of feasibilityOverview of Management IssuesStatement of Work (SOW)Describes what project will deliverLists all work to be performed

    [email protected]

  • [email protected]*QuestionsWhat is contained in a Baseline Project Plan? Are the content and format of all baseline plans the same? Why or why not?Describe the structured walkthrough process. What roles need to be performed during a walkthrough?

    [email protected]

  • Chapter 8 Determining System Requirements

    [email protected]

  • [email protected]*Learning ObjectivesDescribe options for designing and conducting interviewsDiscuss planning an interviewDiscuss using questionnaires to determine system requirementsExplain advantages and disadvantages of observing workers and analyzing business documents to determine requirements

    [email protected]

  • [email protected]*Learning ObjectivesLearn about Joint Application Design (JAD) and PrototypingDiscuss appropriate methods to elicit system requestsExamine requirements determination for Internet applications

    [email protected]

  • *Activities in Requirement Gathering1.0Identify the right Stakeholders &Artefacts0.0Outline information to be sought2.0Use most appropriate investigation techniques4.0Document the requirementsObjective: determine the functions & information that must be provided by the information system3.0Determine duration

  • [email protected]*Performing Requirements DeterminationGather information on what the system should do from many sourcesUsersReportsFormsProcedures

    [email protected]

  • [email protected]*Performing Requirements DeterminationCharacteristics for gathering requirementsImpertinenceQuestion everythingImpartialityFind the best organizational solutionRelaxation of constraintsAttention to detailReframingView the organization in new ways

    [email protected]

  • [email protected]*Deliverables and OutcomesTypes of deliverables:Information collected from usersExisting documents and filesComputer-based informationUnderstanding of organizational componentsBusiness objectiveInformation needsRules of data processingKey events

    [email protected]

  • [email protected]*Deliverables and Outcomes

    [email protected]

  • [email protected]*Traditional Methods for Determining Requirements

    [email protected]

  • [email protected]*Traditional Methods for Determining RequirementsInterviewing and ListeningGather facts, opinions and speculationsObserve body language and emotionsGuidelinesPlanChecklistAppointmentBe neutralListenSeek a diverse viewInterview QuestionsOpen-EndedNo prespecified answersClose-EndedRespondent is asked to choose from a set of specified responses

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Traditional Methods for Determining RequirementsAdministering QuestionnairesMore cost-effective than interviewsChoosing respondentsShould be representative of all usersTypes of samplesConvenientRandom samplePurposeful sampleStratified sampleDesignMostly closed-ended questionsCan be administered over the phone, in person or over the Internet or company intranet

    [email protected]

  • [email protected]*Traditional Methods for Determining RequirementsQuestionnaires Vs. InterviewsInterviews cost more but yield more informationQuestionnaires are more cost-effective

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Traditional Methods for Determining RequirementsDirectly Observing UsersServes as a good method to supplement interviewsOften difficult to obtain unbiased dataPeople often work differently when being observed

    [email protected]

  • [email protected]*Analyzing Procedures and Other DocumentsTypes of information to be discovered:Problems with existing systemOpportunity to meet new needOrganizational directionNames of key individualsValues of organizationSpecial information processing circumstancesRules for processing data

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Modern Methods for Determining RequirementsJoint Application Design (JAD)Brings together key users, managers and systems analystsPurpose: collect system requirements simultaneously from key peopleConducted off-sitePrototypingRepetitive processRudimentary version of system is builtReplaces or augments SDLCGoal: to develop concrete specifications for ultimate system

    [email protected]

  • [email protected]*Joint Application Design (JAD)ParticipantsSession LeaderUsersManagersSponsorSystems AnalystsScribeIS StaffEnd ResultDocumentation detailing existing systemFeatures of proposed system

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*PrototypingQuickly converts requirements to working version of systemOnce the user sees requirements converted to system, will ask for modifications or will generate additional requestsMost useful when:User requests are not clearFew users are involved in the systemDesigns are complex and require concrete formHistory of communication problems between analysts and usersTools are readily available to build prototype

    [email protected]

  • [email protected]*PrototypingDrawbacksTendency to avoid formal documentationDifficult to adapt to more general user audienceSharing data with other systems is often not consideredSystems Development Life Cycle (SDLC) checks are often bypassed

    [email protected]

  • [email protected]*SummaryInterviewsOpen-ended and close-ended questionsPreparation is keyQuestionnairesMust be carefully designedCan contain close-ended as well as open-ended questions

    [email protected]

  • [email protected]*SummaryOther means of gathering requirementsObserving workersAnalyzing business documentsJoint Application Design (JAD)Prototyping

    [email protected]

  • [email protected]*Questions (1)Describe systems analysis and the major activities that occur during this phase of the systems development life cycle.What are some useful character traits for an analyst involved in requirements determination?Describe four traditional techniques for collecting information during analysis. When might one be better than another?What are the general guidelines for conducting interviews?What are the general guidelines for designing questionnaires?Compare collecting information by interview and by questionnaire. Describe a hypothetical situation in which each of these methods would be an effective way to collect information system requirements.

    [email protected]

  • [email protected]*Questions (2)What are the general guidelines for collecting data through observing workers?What are the general guidelines for collecting data through analyzing documents?Describe how prototyping can be used during requirements determination. How is it better or worse than traditional methods?

    [email protected]

  • Chapter 9 Structuring System Requirements:Process Modeling

    [email protected]

  • [email protected]*Learning ObjectivesUnderstand the logical modeling of processes through studying data flow diagramsHow to draw data flow diagrams using rules and guidelinesHow to decompose data flow diagrams into lower-level diagramsBalancing of data flow diagrams

    [email protected]

  • [email protected]*Learning ObjectivesDiscuss the use of data flow diagrams as analysis tools Discuss process modeling for Internet Applications

    [email protected]

  • [email protected]*Process ModelingGraphically represent the processes that capture, manipulate, store and distribute data between a system and its environment and among system componentsData flow diagrams (DFD)Graphically illustrate movement of data between external entities and the processes and data stores within a system

    [email protected]

  • [email protected]*Process ModelingModeling a systems processUtilize information gathered during requirements determinationStructure of the data is also modeled in addition to the processesDeliverables and OutcomesSet of coherent, interrelated data flow diagrams

    [email protected]

  • [email protected]*Process ModelingDeliverables and outcomes (continued)Context data flow diagram (DFD)Scope of systemDFDs of current systemEnables analysts to understand current systemDFDs of new logical systemTechnology independentShow data flows, structure and functional requirements of new system

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Data Flow Diagramming MechanicsData FlowDepicts data that are in motion and moving as a unit from one place to another in the systemDrawn as an arrowSelect a meaningful name to represent the data

    [email protected]

  • [email protected]*Data Flow Diagramming MechanicsData StoreDepicts data at restMay represent data in:File folderComputer-based fileNotebookDrawn as a rectangle with the right hand vertical line missingLabel includes name of the store as well as the number

    [email protected]

  • [email protected]*Data Flow Diagramming MechanicsProcessDepicts work or action performed on data so that they are transformed, stored or distributedDrawn as a rectangle with rounded cornersNumber of process as well as name are recorded

    [email protected]

  • [email protected]*Data Flow Diagramming MechanicsSource/SinkDepicts the origin and/or destination of the dataSometimes referred to as an external entityDrawn as a square symbolName states what the external agent isBecause they are external, many characteristics are not of interest to us

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Data Flow Diagramming DefinitionsContext DiagramA data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the systemLevel-O DiagramA data flow diagrams (DFD) that represents a systems major processes, data flows and data stores at a higher level

    [email protected]

  • [email protected]*Developing DFDs: An ExampleHoosier Burgers automated food ordering systemContext Diagram contains no data stores

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Developing DFDs: An ExampleNext step is to expand the context diagram to show the breakdown of processes

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Data Flow Diagramming RulesBasic rules that apply to all DFDsInputs to a process are always different than outputsObjects always have a unique nameIn order to keep the diagram uncluttered, you can repeat data stores and data flows on a diagram

    [email protected]

  • [email protected]*Data Flow Diagramming RulesProcessNo process can have only outputs (a miracle)No process can have only inputs (black hole)A process has a verb phrase labelData StoreData cannot be moved from one store to anotherData cannot move from an outside source to a data storeData cannot move directly from a data store to a data sinkData store has a noun phrase label

    [email protected]

  • [email protected]*Data Flow Diagramming RulesSource/SinkData cannot move directly from a source to a sinkA source/sink has a noun phrase labelData FlowA data flow has only one direction of flow between symbolsA fork means that exactly the same data go from a common location to two or more processes, data stores or sources/sinks

    [email protected]

  • [email protected]*Data Flow Diagramming RulesData Flow (Continued)A join means that exactly the same data come from any two or more different processes, data stores or sources/sinks to a common locationA data flow cannot go directly back to the same process it leavesA data flow to a data store means updateA data flow from a data store means retrieve or useA data flow has a noun phrase label

    [email protected]

  • [email protected]*Decomposition of DFDsFunctional decompositionAct of going from one single system to many component processesRepetitive procedureLowest level is called a primitive DFDLevel-N DiagramsA DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram

    [email protected]

  • [email protected]*Balancing DFDsWhen decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decompositionThis is called balancingExample: Hoosier BurgersIn Figure 5-4, notice that there is one input to the system, the customer orderThree outputs: Customer receiptFood orderManagement reports

    [email protected]

  • [email protected]*Balancing DFDsExample (Continued)Notice Figure 5-5. We have the same inputs and outputsNo new inputs or outputs have been introducedWe can say that the context diagram and level-0 DFD are balanced

    [email protected]

  • [email protected]*Balancing DFDs:An Unbalanced ExampleIn context diagram, we have one input to the system, A and one output, BLevel-0 diagram has one additional data flow, CThese DFDs are not balanced

    [email protected]

  • [email protected]*Balancing DFDsWe can split a data flow into separate data flows on a lower-level diagram

    [email protected]

  • [email protected]*Balancing DFDs:Four Additional Advanced Rules

    [email protected]

  • [email protected]*Guidelines for Drawing DFDsCompletenessDFD must include all components necessary for systemEach component must be fully described in the project dictionary or CASE repositoryConsistencyThe extent to which information contained on one level of a set of nested DFDs is also included on other levels

    [email protected]

  • [email protected]*Guidelines for Drawing DFDsTimingTime is not represented well on DFDsBest to draw DFDs as if the system has never started and will never stopIterative DevelopmentAnalyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeledPrimitive DFDsLowest logical level of decompositionDecision has to be made when to stop decomposition

    [email protected]

  • [email protected]*Using DFDs as Analysis ToolsGap AnalysisThe process of discovering discrepancies between two or more sets of data flow diagrams or discrepancies within a single DFDInefficiencies in a system can often be identified through DFDs

    [email protected]

  • [email protected]*Using DFDs in Business Process ReengineeringExample: IBM CreditCredit approval process required six days before Business Process Reengineering (see Fig 5-12)

    [email protected]

  • [email protected]*Using DFDs in Business Process ReengineeringAfter Business Reprocess Engineering, IBM was able to process 100 times the number of transactions in the same amount of time

    [email protected]

  • [email protected]*SummaryData flow diagrams (DFD)SymbolsRules for creatingDecompositionBalancingDFDs for AnalysisDFDs for Business Process Reengineering (BPR)

    [email protected]

  • [email protected]*QuestionsWhat is a data flow diagram? Why do systems analysts use data flow diagrams?What is decomposition? What is balancing? How can you determine if DFDs are not balanced?Explain the convention for naming different levels of data flow diagrams.How can data flow diagrams be used as analysis tools?

    [email protected]

  • Chapter 10Structuring System Requirements:Conceptual Data Modeling

    [email protected]

  • [email protected]*Learning ObjectivesDefine key data-modeling termsConceptual data modelEntity-Relationship (E-R) diagram Entity typeEntity instanceAttributeCandidate keyMultivalued attributesRelationshipDegreeCardinalityAssociative entity

    [email protected]

  • [email protected]*Learning ObjectivesAsk the right kinds of questions to determine data requirements for an ISLearn to draw entity-relationship diagrams (ERD)Review the role of conceptual data modeling in overall design and analysis of an information systemDiscuss relationships and associative entitiesDiscuss relationship between data modeling and process modeling

    [email protected]

  • [email protected]*Conceptual Data ModelingRepresentation of organizational dataPurpose is to show rules about the meaning and interrelationships among dataEntity-Relationship (E-R) diagrams are commonly used to show how data are organizedMain goal of conceptual data modeling is to create accurate E-R diagramsMethods such as interviewing, questionnaires and JAD are used to collect informationConsistency must be maintained between process flow, decision logic and data modeling descriptions

    [email protected]

  • [email protected]*Process of Conceptual Data ModelingFirst step is to develop a data model for the system being replacedNext, a new conceptual data model is built that includes all the requirements of the new systemIn the design stage, the conceptual data model is translated into a physical designProject repository links all design and data modeling steps performed during SDLC

    [email protected]

  • [email protected]*Deliverables and OutcomesPrimary deliverable is the entity-relationship diagramThere may be as many as 4 E-R diagrams produced and analyzed during conceptual data modelingCovers just data needed in the projects applicationE-R diagram for system being replacedAn E-R diagram for the whole database from which the new applications data are extractedAn E-R diagram for the whole database from which data for the application system being replaced are drawn

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Deliverables and OutcomesSecond deliverable is a set of entries about data objects to be stored in repository or project dictionaryRepository links data, process and logic models of an information systemData elements that are included in the DFD must appear in the data model and converselyEach data store in a process model must relate to business objects represented in the data model

    [email protected]

  • [email protected]*Gathering Information for Conceptual Data ModelingTwo perspectivesTop-downData model is derived from an intimate understanding of the businessBottom-upData model is derived by reviewing specifications and business documents

    [email protected]

  • [email protected]*Introduction to Entity-Relationship (E-R) ModelingNotation uses three main constructsData entitiesRelationshipsAttributesEntity-Relationship (E-R) DiagramA detailed, logical and graphical representation of the entities, associations and data elements for an organization or business

    [email protected]

  • [email protected]*Entity-Relationship (E-R) ModelingKey TermsEntityA person, place, object, event or concept in the user environment about which the organization wishes to maintain dataRepresented by a rectangle in E-R diagramsEntity TypeA collection of entities that share common properties or characteristicsAttributeA named property or characteristic of an entity that is of interest to an organization

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Entity-Relationship (E-R) ModelingKey TermsCandidate keys and identifiersEach entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same typeCandidate keyAttribute (or combination of attributes) that uniquely identifies each instance of an entity type

    [email protected]

  • [email protected]*Entity-Relationship (E-R) ModelingKey TermsIdentifierA candidate key that has been selected as the unique identifying characteristic for an entity typeSelection rules for an identifierChoose a candidate key that will not change its valueChoose a candidate key that will never be nullAvoid using intelligent keysConsider substituting single value surrogate keys for large composite keys

    [email protected]

  • [email protected]*Entity-Relationship (E-R) ModelingKey TermsMultivalued AttributeAn attribute that may take on more than one value for each entity instanceRepresented on E-R Diagram in two ways:Double-lined ellipseWeak entity

    [email protected]

  • [email protected]*Entity-Relationship (E-R) ModelingKey TermsRelationshipAn association between the instances of one or more entity types that is of interest to the organizationAssociation indicates that an event has occurred or that there is a natural link between entity typesRelationships are always labeled with verb phrases

    [email protected]

  • [email protected]*Conceptual Data Modeling and the E-R Diagram GoalCapture as much of the meaning of the data as possible Result A better design that is easier to maintain

    [email protected]

  • [email protected]*Degree of RelationshipDegreeNumber of entity types that participate in a relationshipThree casesUnaryA relationship between the instances of one entity typeBinaryA relationship between the instances of two entity typesTernaryA simultaneous relationship among the instances of three entity typesNot the same as three binary relationships

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Cardinality

    The number of instances of entity B that can be associated with each instance of entity AMinimum CardinalityThe minimum number of instances of entity B that may be associated with each instance of entity AMaximum CardinalityThe maximum number of instances of entity B that may be associated with each instance of entity A

    [email protected]

  • [email protected]*Electronic Commerce Development: Conceptual Data ModelConceptual data modeling for Internet applications is no different than the processed followed for other types of applicationsPine Valley Furniture WebStoreFour entity types definedCustomerInventoryOrderShopping cart

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • ER diagram for Pine Valley furniture

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*SummaryProcess of conceptual data modelingDeliverablesGathering informationEntity-Relationship ModelingEntitiesAttributesCandidate keys and identifiersMultivalued attributesDegree of relationship

    [email protected]

  • [email protected]*SummaryCardinalityAssociative entitiesConceptual data modeling and Internet development

    [email protected]

  • [email protected]*QuestionsList the four types of E-R diagrams produced and analyzed during conceptual data modeling.What elements of a data flow diagram should be analyzed as part of data modeling?What is the degree of a relationship? Give an example of each of the relationship degrees illustrated in this chapter.Explain why a ternary relationship is not the same as three binary relationships.Which of the following types of relationships can have attributes associated with them: one-to-one, one-to-many, many-to-many?Give an example of a ternary relationship (different from any example in this chapter.)

    [email protected]

  • Chapter 11Object-Oriented Analysis and Design

    [email protected]

  • [email protected]*Learning ObjectivesDiscuss the concepts and principles underlying the object-oriented approachLearn to develop requirements models using use-case diagramsLearn to develop requirements models using state and sequence diagramsLearn to use class diagrams to develop object models of the problem domain

    [email protected]

  • [email protected]*The Object-Oriented Modeling Approach BenefitsThe ability to tackle more challenging problem domainsImproved communication among users, analysts, designers and programmersReusability of analysis, design and programming resultsIncreased consistency among the models developed during object-oriented analysis, design, and programmingExplicit representation of commonality among system components

    [email protected]

  • [email protected]*The Object-Oriented Modeling ApproachObject-Oriented systems development life cycle:Process of progressively developing representation of a system component (or object) through the phases of analysis, design and implementationThe model is abstract in the early stagesAs the model evolves, it becomes more and more detailed

    [email protected]

  • [email protected]*The Object-Oriented Systems Development Life CycleAnalysis PhaseModel of the real-world application is developed showing its important propertiesModel specifies the functional behavior of the system independent of implementation detailsDesign PhaseAnalysis model is refined and adapted to the environmentImplementation PhaseDesign is implemented using a programming language or database management system

    [email protected]

  • [email protected]*The Object-Oriented Systems Development Life CycleUnified Modeling Language (UML)A notation that allows the modeler to specify, visualize and construct the artifacts of software systems, as well as business modelsTechniques and notationsUse casesSequence diagrams Activity diagramsClass diagramsState diagrams

    [email protected]

  • [email protected]*Components ViewAn architecture-based visionDeployment ViewProcess ViewLogical ViewUse Case ViewFunctional needsMajor classescodingSystem performancesServers and network organization

    [email protected]

  • [email protected]*

    Use Cases diagramsFunctional modellingSequence Diagrams Dynamic modelling of scenariosClass DiagramsStatic modellingSystems structureCollaboration diagramDynamic modelling, focusing on spatial relationships between objectsStatecharts DiagramsDynamic modelling, focusing on an object. Activities done in each state correspond to operationsActivity DiagramsDynamic modelling, focusing on an activityObjects DiagramsStatic modellingContext1

    [email protected]

  • [email protected]*Use-Case ModelingApplied to analyze functional requirements of the systemPerformed during the analysis phase to help developers understand functional requirements of the system without regard for implementation detailsUse CaseA complete sequence of related actions initiated by an actorActorAn external entity that interacts with the system

    [email protected]

  • [email protected]*Use-Case ModelingUse cases are always initiated by an actorUse cases represent complete functionality of the systemUse cases may participate in relationships with other use-casesUse cases may also use other use cases

    [email protected]

  • [email protected]*Use cases diagramUse cases diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how.Use cases diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system. Here is a scenario for a medical clinic: A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slotA use case is a summary of scenarios for a single task or goal. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play

    [email protected]

  • [email protected]*A use case and his actor

    [email protected]

  • [email protected]*A use case diagram

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*ExplanationA system boundary rectangle separates the clinic system from the external actors.A use case generalization shows that one use case is simply a special kind of another. Pay Bill is a parent use case and Bill Insurance is the child. A child can be substituted for its parent whenever necessary. Generalization appears as a line with a triangular arrow head toward the parent use case.Include relationships factor use cases into additional ones. Includes are especially helpful when the same use case can be factored out of two different use cases. Both Make Appointment and Request Medication include Check Patient Record as a subtask. In the diagram, include notation is a dotted line beginning at base use case ending with an arrows pointing to the include use case. The dotted line is labeled .An extend relationship indicates that one use case is a variation of another. Extend notation is a dotted line, labeled , and with an arrow toward the base case. The extension point, which determines when the extended case is appropriate, is written inside the base case.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Use case diagrams are helpful in three areasDetermining features (requirements). New use cases often generate new requirements as the system is analyzed and the design takes shape. Communicating with clients. Their notational simplicity makes use case diagrams a good way for developers to communicate with clients. Generating test cases. The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

    [email protected]

  • Use case exampleOnline HR system

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Update Benefits description

    [email protected]

  • [email protected]*Dynamic Modeling:Sequence DiagramsSequence DiagramA depiction of the interaction among objects during certain periods of timeActivationThe time period during which an object performs an operationMessagesMeans by which objects communicate with each other

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*ExplanationThe Reservation window sends a makeReservation() message to a HotelChain. The HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation.Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a message call. An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline. The activation bar represents the duration of execution of the message.In our diagram, the Hotel issues a self call to determine if a room is available. If so, then the Hotel creates a Reservation and a Confirmation. The asterisk on the self call means iteration (to make sure there is available room for each day of the stay in the hotel). The expression in square brackets, [ ], is a condition.The diagram has a clarifying note, which is text inside a dog-eared rectangle. Notes can be put into any kind of UML diagram.

    [email protected]

  • [email protected]*Collaboration diagramCollaboration diagrams are also interaction diagrams. They convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a sequence diagram, object roles are the vertices and messages are the connecting links.The object-role rectangles are labeled with either class or object names (or both). Class names are preceded by colons ( : ).Each message in a collaboration diagram has a sequence number. The top-level message is numbered 1. Messages at the same level (sent during the same call) have the same decimal prefix but suffixes of 1, 2, etc. according to when they occur.

    [email protected]

  • [email protected]*Collaboration diagram

    [email protected]

  • [email protected]*Activity diagramAn activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are relatedWhile a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another.For our example, we used the following process."Withdraw money from a bank account through an ATM."The three involved classes (people, etc.) of the activity are Customer, ATM, and Bank. The process begins at the black start circle at the top and ends at the concentric white/black stop circles at the bottom. The activities are rounded rectangles.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Class diagramsA Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static: they display what interacts but not what happens when they do interact

    [email protected]

  • [email protected]*Class notations

    [email protected]

  • [email protected]*Class stereotypes

    [email protected]

  • [email protected]*ExampleThe following class diagram models a customer order from a retail catalog. The central class is the Order. Associated with it are the Customer making the purchase and the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each with its associated Item.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Representing AssociationsAssociationA relationship between object classesDegree may be unary, binary, ternary or higherDepicted as a solid line between participating classesAssociation RoleThe end of an association where it connects to a classEach role has multiplicity, which indicates how many objects participate in a given association relationship

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Representing GeneralizationGeneralizationAbstraction of common features among multiple classes, as well as their relationships, into a more general classSubclassA class that has been generalizedSuperclassA class that is composed of several generalized subclasses

    [email protected]

  • [email protected]*Representing GeneralizationDiscriminatorShows which property of an object class is being abstracted by a generalization relationshipInheritanceA property that a subclass inherits the features from its superclassAbstract ClassA class that has no direct instances, but whose descendents may have direct instancesConcrete ClassA class that can have direct instances

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Representing AggregationAggregationA part-of relationship between a component object and an aggregate objectExample: Personal computerComposed of CPU, Monitor, Keyboard, etc

    [email protected]

  • [email protected]*Composition and AggregationAssociations in which an object is part of a whole are aggregations. Composition is a strong association in which the part can belong to only one whole The part cannot exist without the whole. Composition is denoted by a filled diamond at the whole end.The following diagram shows that a BoxOffice belongs to exactly one MovieTheater. Destroy the MovieTheater and the BoxOffice goes away! The collection of Movies is not so closely bound to the MovieTheater.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Dependencies and constraintsA dependency is a relation between two classes in which a change in one may force changes in the other. Dependencies are drawn as dotted lines. In the class diagram below, Co_op depends on Company. If you decide to modify Company, you may have to change Co_op too.A constraint is a condition that every implementation of the design must satisfy. Constraints are written in curly braces { }. The constraint on our diagram indicates that a Section can be part of a CourseSchedule only if it is not canceled.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*PackagesTo simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements. Packages appear as rectangles with small tabs at the top. The package name is on the tab or inside the rectangle. The dotted arrows are dependencies: One package depends on another if changes in the other could possibly force changes in the first.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Object diagramsObject diagrams show instances instead of classes. They are useful for explaining small pieces with complicated relationships, especially recursive relationships.This small class diagram shows that a university Department can contain lots of other Departments.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Object ModelingObject DiagramsObject Diagramalso called an instance diagramObject is represented as a rectangle with two compartmentsOperationA function or service that is provided by all the instances of a classEncapsulationThe technique of hiding the internal implementation details of an object from its external view

    [email protected]

  • [email protected]*Objects notations

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Statecharts diagramObjects have behaviors and state. The state of an object depends on its current activity or condition. A statechart diagram shows the possible states of the object and the transitions that cause a change in state.StateA condition during the life of an object during which it satisfies some conditions, performs some actions or waits for some eventsShown as a rectangle with rounded cornersState TransitionThe changes in the attribute of an object or in the links an object has with other objectsShown as a solid arrowDiagrammed with a guard condition and actionEventSomething that takes place at a certain point in time

    [email protected]

  • [email protected]*ExampleOur example diagram models the login part of an online banking system. Logging in consists of entering a valid social security number and personal id number, then submitting the information for validation.Logging in can be factored into four non-overlapping states: Getting SSN, Getting PIN, Validating, and Rejecting. From each state comes a complete set of transitions that determine the subsequent state.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*ExplanationOur diagram has two self-transition, one on Getting SSN and another on Getting PIN.The initial state (black circle) is a dummy to start the action. Final states are also dummy states that terminate the action.The action that occurs as a result of an event or condition is expressed in the form /action. While in its Validating state, the object does not wait for an outside event to trigger a transition. Instead, it performs an activity. The result of that activity determines its subsequent state.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Moving to DesignStart with existing set of analysis modelProgressively add technical detailsDesign model must be more detailed than analysis modelComponent DiagramA diagram that shows the software components or modules and their dependenciesDeployment DiagramA diagram that shows how the software components, process and objects are deployed into the physical architecture of the system

    [email protected]

  • [email protected]*Component and deployment diagramsA component is a code module. Component diagrams are physical analogs of class diagram. Deployment diagrams show the physical configurations of software and hardware.The following deployment diagram shows the relationships among software and hardware components involved in real estate transactions.The physical hardware is made up of nodes. Each component belongs on a node. Components are shown as rectangles with two tabs at the upper left.

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*SummaryObject-Oriented modeling approachBenefitsUnified Modeling LanguageUse casesClass diagramsState diagramsSequence diagramsUse-case modeling

    [email protected]

  • [email protected]*SummaryObject Modeling: Class DiagramsAssociationsGeneralizationsAggregationDynamic Modeling: State DiagramsDynamic Modeling: Sequence DiagramsMoving to Design

    [email protected]

  • Chapter 12Designing the Human Interface

    [email protected]

  • [email protected]*Learning ObjectivesExplain the process of designing forms and reports and the deliverables for their creationDiscuss general guidelines for formatting text, tables and listsLearn how to effectively format text, tables and listsExplain the process of designing interfaces and dialogues and the deliverables for their creation

    [email protected]

  • [email protected]*Learning ObjectivesDiscuss the general guidelines for interface design including:Layout and designStructuring data entry fieldsProviding feedbackSystem helpDiscuss the design of human-computer dialogues and the use of dialogue diagrammingExplain interface design guidelines unique to the design of Internet-based electronic commerce systems

    [email protected]

  • [email protected]*Designing Forms and Reports

    System inputs and outputs are produced at the end of the analysis phasePrecise appearance was not defined during this phaseForms and reports are integrally related to DFD and E-R diagrams

    [email protected]

  • [email protected]*Designing Forms and Reports:Key ConceptsFormA business document that contains some predefined data and may include some areas where additional data are to be filled inAn instance of a form is typically based on one database recordReportA business document that contains only predefined dataA passive document for reading or viewing dataTypically contains data from many database records or transactions

    [email protected]

  • [email protected]*The Process of Designing Forms and ReportsUser-focused activityFollows a prototyping approachRequirements determinationWho will use the form or report?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?

    [email protected]

  • [email protected]*The Process of Designing Forms and ReportsPrototypingInitial prototype is designed from requirementsUsers review prototype design and either accept the design or request changesIf changes are requested, the construction-evaluation-request cycle is repeated until the design is accepted

    [email protected]

  • [email protected]*Deliverables and OutcomesDesign specifications are major deliverable and contain three sectionsNarrativeScreen DesignTesting and usability assessment

    [email protected]

  • [email protected]*General Formatting Guidelines for Forms and ReportsHighlightingUse sparingly to draw user to or away from certain informationBlinking and audible tones should only be used to highlight critical information requiring users immediate attentionMethods should be consistently selected and used based upon level of importance of emphasized information

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*General Formatting Guidelines for Forms and ReportsDisplaying TextDisplay text in mixed upper- and lowercase and use conventional punctuationUse double spacing if space permits. If not, place a blank line between paragraphsLeft-justify text and leave a ragged right marginDo not hyphenate words between linesUse abbreviations and acronyms only when they are widely understood by users and are significantly shorter than the full text

    [email protected]

  • [email protected]*General Formatting Guidelines for Forms and ReportsDisplaying tables and listsLabelsAll columns and rows should have meaningful labelsLabels should be separated from other information by using highlightingRedisplay labels when the data extend beyond a single screen or page

    [email protected]

  • [email protected]*General Formatting Guidelines for Forms and ReportsDisplaying tables and lists (continued)Formatting columns, rows and textSort in a meaningful orderPlace a blank line between every 5 rows in long columnsSimilar information displayed in multiple columns should be sorted verticallyColumns should have at least two spaces between themAllow white space on printed reports for user to write notesUse a single typeface, except for emphasisUse same family of typefaces within and across displays and reportsAvoid overly fancy fonts

    [email protected]

  • [email protected]*General Formatting Guidelines for Forms and ReportsDisplaying tables and lists (continued)Formatting numeric, textual and alphanumeric dataRight-justify numeric data and align columns by decimal points or other delimiterLeft-justify textual data. Use short line length, usually 30 to 40 characters per lineBreak long sequences of alphanumeric data into small groups of three to four characters each

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Designing Interfaces and DialoguesFocus on how information is provided to and captured from usersDialogues are analogous to a conversation between two peopleA good human-computer interface provides a unifying structure for finding, viewing and invoking the different components of a system

    [email protected]

  • [email protected]*Designing InterfacesDesigning LayoutsStandard formats similar to paper-based forms and reports should be usedScreen navigation on data entry screens should be left-to-right, top-to-bottom as on paper forms

    [email protected]

  • [email protected]*Designing LayoutsFlexibility and consistency are primary design goalsUsers should be able to move freely between fieldsData should not be permanently saved until the user explicitly requests thisEach key and command should be assigned to one function

    [email protected]

  • [email protected]*Structuring Data Entry

    EntryNever require data that are already online or that can be computedDefaultsAlways provide default values when appropriateUnitsMake clear the type of data units requested for entryReplacementUse character replacement when appropriateCaptioningAlways place a caption adjacent to fieldsFormatProvide formatting examplesJustifyAutomatically justify data entriesHelpProvide context-sensitive help when appropriate

    [email protected]

  • [email protected]*Controlling Data InputOne objective of interface design is to reduce data entry errorsRole of systems analyst is to anticipate user errors and design features into the systems interfaces to avoid, detect, and correct data entry mistakesTable 8-9 describes types of data entry errorsTable 8-10 lists techniques used by system designers to detect errors

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Providing FeedbackStatus InformationKeeps users informed of what is going on in systemDisplaying status information is especially important if the operation takes longer than a second or twoPrompting CuesBest to keep as specific as possibleError and Warning MessagesMessages should be specific and free of error codes and jargonUser should be guided toward a result rather than scoldedUse terms familiar to userBe consistent in format and placement of messages

    [email protected]

  • [email protected]*Providing HelpPlace yourself in users place when designing helpGuidelinesSimplicityHelp messages should be short and to the pointOrganizationInformation in help messages should be easily absorbed by usersDemonstrateIt is useful to explicitly show users how to perform an operation

    [email protected]

  • [email protected]*Providing HelpContext-Sensitive HelpEnables user to get field-specific helpUsers should always be returned to where they were when requesting help

    [email protected]

  • [email protected]*Designing DialoguesDialogueSequence in which information is displayed to and obtained from a userPrimary design guideline is consistency in sequence of actions, keystrokes, and terminologyThree-step process1.Design dialogue sequence2.Build a prototype3.Assess usability

    [email protected]

  • [email protected]*Designing the Dialogue SequenceDefine the sequenceHave a clear understanding of the user, task, technological and environmental characteristicsDialogue DiagramA formal method for designing and representing human-computer dialogues using box and line diagramsConsists of a box with three sectionsTop: Unique display reference number used by other displays for referencing dialogueMiddle: Contains the name or description of the displayBottom: Contains display reference numbers that can be accessed from the current display

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Designing Dialogues:Building Prototypes and Assessing UsabilityOften optional activitiesTask is simplified by using graphical design environment

    [email protected]

  • [email protected]*

    [email protected]

  • [email protected]*Web-based Application:Designing Interfaces and Dialogues for Pine Valley Furnitures WebstoreGeneral GuidelinesSeveral factors have contributed to poor design of Web interfacesWebs single click-to-act method of loading static hypertext documentsLimited capabilities of most Web-browsers to support finely grained user interactivityLimited agreed-upon standards for encoding Web content and control mechanismsLack of maturity in Web scripting and programming languages

    [email protected]

  • [email protected]*Web-based Application:Designing the Human Interface at Pine Valley FurnitureDesign GuidelinesNavigation via cookie crumbsA technique that uses a series of tabs on a Web page to show users where they are and where they have been in the siteTabs are hyperlinks to allow users to move backward easily within the siteTwo important purposesAllows users to navigate to a point previously visitedShows users where they have been and how far they have gone from point of entry into site

    [email protected]

  • [email protected]*Web-based Application: Design GuidelinesLightweight GraphicsThe use of small images to allow a Web page to be displayed more quicklyForms and Data IntegrityAll forms that record information should be clearly labeled and provide room for inputClear examples of input should be provided to reduce data errorsSite must clearly designate which fields are required, which are optional and which have a range of values

    [email protected]

  • [email protected]*SummaryDesigning Forms and ReportsGeneral guidelines for designing forms and reportsFormatting text, tables and listsDesign guidelines for interfacesLayout designStructuring data entry fieldsProviding feedbackDesigning help

    [email protected]

  • [email protected]*QuestionsTo which initial questions must the analyst gain answers in order to build an initial prototype of a system output?Describe the process of designing interfaces and dialogues. What deliverables are produced from this process? Are these deliverables the same for all types of system projects? Why or why not?

    [email protected]

  • Chapter 13Systems Implementation and Operation

    [email protected]

  • [email protected]*Learning ObjectivesDescribe the process of coding, testing and converting an organizational information systemDiscuss four inst