PowerPoint PresentationChapter Twelve Systems DesignChapter MapSlide 4System DesignModern Structured DesignStructure ChartInformation EngineeringPhysical Entity Relationship DiagramPrototypingSlide 11Prototype screenModel-Driven Approaches – Object-Oriented DesignContext Of In-House Development Projects (Build)Design Phase Tasks For In-House Development5.1 Application ArchitectureSample Physical Data Flow Diagram5.2 Design Databases5.3 Design System Interfaces5.4 Package Design SpecificationsContext Of System Design For “CTOS” ProjectsDesign Phase Tasks For “CTOS” Solutions4.1 Technical and Business Research Sources4.2 Solicit ProposalsTypical Outline for Request For Proposal (RFP)5A.1 Validate Vendor Claims and Performance5A.2 Evaluate and Rank ProposalsRemaining StepsImpact of Buy Decision on Remaining PhasesSlide 30Systems Analysis Design Methods 6th EdC H A P T E R12SYSTEMS DESIGNChapter Twelve Systems DesignChapter Twelve Systems DesignDescribe the design phase in terms of your information building blocks. Identify and differentiate between several systems design strategies. Describe the design phase tasks in terms of a computer-based solution for an in-house development project. Describe the design phase in terms of a computer-based solution involving procurement of a commercial systems software solution.Chapter MapChapter MapChapter MapChapter MapSystem DesignSystem DesignInformation systems design is defined as those tasks that focus on the specification of a detailed computer-based solution. It is also called physical design. Systems analysis emphasis on the business problem Systems design emphasis on the technical or implementationconcerns of the systemMore than design, code implement – NIH mentality More computer systems purchased than writtenWhy reinvent the wheel?Modern Structured DesignModern Structured DesignModern Structured Design process-oriented techniquehierarchy of modules –programs easier to implement and maintain (change). Software model derived from structured design –a structure chartCohesiveLoosely CoupledCompleteSpan of ControlStructure ChartStructure ChartInformation EngineeringInformation EngineeringInformation Engineeringdata-centered, but process-sensitive Primary tool is a data model diagram.Physical Entity Relationship DiagramPhysical Entity Relationship DiagramPrototypingPrototypingThe prototyping approach is an iterative process involving a close working relationship between the designer and the users.Key Benefits:Requires active end-user participation–Morale and ownershipIteration and changes are a natural consequenceUsers will know it when they see itAn active, not passive, model that end-users can see, touch, feel, and experience. A working equivalent to a paper design specification –errors can be detected much earlier. Increases creativity –quicker user feedback, which can lead to better solutions. Accelerates several phases of the life cycle–possibly bypassing the programmer.PrototypingPrototypingDisadvantages:Encourages code, implement, repair mentalityDanger of by passing critical System Analysis steps–May solve the wrong problemShould complement other methodologiesSome design issues may not be addressedPremature commitment to a solutionMay stifle creativity –quicker user feedback, which can lead to better solutions. Creeping ScopePoor PerformancePrototype screenPrototype screenModel-Driven Approaches – Object-Oriented Design Model-Driven Approaches – Object-Oriented Design Object-oriented design (OOD) techniques are used to refine the object requirements definitions identified earlier during analysis, and to define design specific objects. Extension of object-oriented analysisAttempt to eliminate the separation of concerns about data and process.Context Of In-House Development Projects (Build)Context Of In-House Development Projects (Build)Design Phase Tasks For In-House DevelopmentDesign Phase Tasks For In-House Development5.1 Application Architecture5.1 Application ArchitectureTechnological issuesNetworkProcessing strategies –Central vs DistributedDBMSProgram development environmentOS PlatformDocumented by Physical Data Flow DiagramDeliverable the Application Architecture is a blueprint for the remaining stepsSample Physical Data Flow DiagramSample Physical Data Flow Diagram5.2 Design Databases5.2 Design DatabasesDatabase must be adaptableProgram performanceIndexes ViewsStorage requirementsSecurityDatabase IntegrityTransaction integrityDisaster RecoveryDeliverable DBMS Schema – revised ERD5.3 Design System Interfaces5.3 Design System InterfacesInputsPhysical implementationOutputsScreensReportsDialoguesUser menusData controlsData CaptureEase of inputHelp SystemAnticipate user actions5.4 Package Design Specifications5.4 Package Design SpecificationsRole of Designer vs ProgrammerComplete design of program structure vs accelerated systems development techniquesWalkthroughsSystems AuditFinal FeasibilityContext Of System Design For “CTOS” ProjectsContext Of System Design For “CTOS” ProjectsDesign Phase Tasks For “CTOS” SolutionsDesign Phase Tasks For “CTOS” Solutions4.1 Technical and Business Research Sources4.1 Technical and Business Research SourcesHardware / Software selectionMagazines and journalsInternal standardsInformation services Trade newspapers and periodicalsSpecifications–Functionality–Features–PerformanceIdentify potential vendors4.2 Solicit Proposals4.2 Solicit ProposalsRFQ – Request for QuotationHave already decided on a specific productSimply need quotes from different suppliers–Pricing–Configuration–Vendor supplied services–Modification limitations–Licensing issuesRFP – Request for ProposalSpecifications–Mandatory–Extremely Important –DesirableRequest for Proposals (RFP) I. Introduction A. Background B. Brief summary of needs C. Explanation of RFP document D. Call for action on part of vendor II. Standards and instructions A. Schedule of events leading to contract B. Ground rules that will govern selection decision 1. Who may talk with whom and when 2. Who pays for what 3. Required format for a proposal 4. Demonstration expectations 5. Contractual expectations 6. References expected 7. Documentation expectations III. Requirements and features A. Hardware 1. Mandatory requirements,