faculty of economics business systems development ebs 2033
Download
Skip this Video
Download Presentation
Faculty of Economics & Business (Systems Development : EBS 2033)

Loading in 2 Seconds...

play fullscreen
1 / 24

Faculty of Economics & Business (Systems Development : EBS 2033) - PowerPoint PPT Presentation


  • 94 Views
  • Uploaded on

Faculty of Economics & Business (Systems Development : EBS 2033). Chapter 7 Finalizing Design Specifications. Puan Asleena Helmi. Learning Objectives. Discuss the need for system design specifications Define quality requirements and write quality requirements statements

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Faculty of Economics & Business (Systems Development : EBS 2033)' - gil


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
faculty of economics business systems development ebs 2033
Faculty of Economics & Business (Systems Development : EBS 2033)

Chapter 7

Finalizing Design Specifications

Puan Asleena Helmi

learning objectives
Learning Objectives
  • Discuss the need for system design specifications
  • Define quality requirements and write quality requirements statements
  • Read and understand a structure chart
  • Distinguish between evolutionary and throwaway prototyping
  • Explain the role of CASE tools in capturing design specifications
  • Demonstrate how design specifications can be declared for Web-based applications

15.2

introduction
Introduction
  • Need for systems to be developed more quickly today
  • The lines between analysis and design and design and implementation are blurring
    • Traditional approaches allowed for a break between design and implementation
    • Other approaches, such as CASE and prototyping, have caused overlap between the two phases

15.3

the process of finalizing design specifications
The Process of Finalizing Design Specifications
  • Less costly to correct and detect errors during the design phase
  • Two sets of guidelines
    • Writing quality specification statements
    • The quality of the specifications themselves
  • Quality requirement statements
    • Correct
    • Feasible
    • Necessary
    • Prioritized
    • Unambiguous
    • Verifiable

15.4

the process of finalizing design specifications1
The Process of Finalizing Design Specifications
  • Quality requirements
    • Completely described
    • Do not conflict with other requirements
    • Easily changed without adversely affecting other requirements
    • Traceable back to origin

15.5

the process of finalizing design specifications2
The Process of Finalizing Design Specifications
  • Deliverables and Outcome
    • Set of physical design specifications
      • Contains detailed specifications for each part of the system

15.6

representing design specifications
Representing Design Specifications
  • Traditional Methods
    • Pre-CASE
    • Documents written natural language and augmented with graphical models
    • Specification documents
      • Several methods for streamlining
        • Computer-based requirements tools
        • Prototyping
        • Visual development environments

15.7

representing design specifications1
Representing Design Specifications
  • Structure Charts
    • Shows how an information system is organized in hierarchical models
    • Shows how parts of a system are related to one another
    • Shows breakdown of a system into programs and internal structures of programs written in third and fourth generation languages

15.8

representing design specifications2
Representing Design Specifications
  • Structure Charts
    • Module
      • A self-contained component of a system, defined by a function
      • One single coordinating module at the root of structure chart
      • Single point of entry and exit
      • Communicate with each other by passing parameters
        • Data couple
          • A diagrammatic representation of the data exchanged between two modules in a structure chart
        • Flag
          • A diagrammatic representation of a message passed between two modules

15.9

representing design specifications3
Representing Design Specifications
  • Structure Charts
    • Module
      • Special Symbols
        • Diamond
          • Only one subordinate will be called
        • Curved Line
          • Subordinates are called repeatedly until terminating condition is met
        • Predefined modules
        • Hat
          • Subordinate module is important logically but code is contained in superior module

15.10

representing design specifications4
Representing Design Specifications
  • Structure Charts
    • Pseudocode
      • Method used for representing the instructions inside a module
      • Language similar to computer programming code
      • Two functions
        • Helps analyst think in a structured way about the task a module is designed to perform
        • Acts as a communication tool between analyst and programmer

15.11

representing design specifications5
Representing Design Specifications
  • Prototyping
    • Construction of the model of a system
    • Allows developers and users to
      • Test aspects of the overall design
      • Check for functionality and usability
    • Iterative process
    • Two types
      • Evolutionary Prototyping
      • Throwaway Prototyping

15.12

representing design specifications6
Representing Design Specifications
  • Prototyping
    • Evolutionary Prototyping
      • Begin by modeling parts of the target system
      • If successful, evolve rest of the system from the prototype
      • Prototype becomes actual production system
      • Often, difficult parts of the system are prototyped first
      • Exception handling must be added to prototype

15.13

representing design specifications7
Representing Design Specifications
  • Prototyping
    • Throwaway Prototyping
      • Prototype is not preserved
      • Developed quickly to demonstrate unclear aspect of system design
      • Fast, easy to use development environment aids this approach

15.14

representing design specifications8
Representing Design Specifications
  • Prototyping
    • Oracle Designer: An Example
      • Transforming and Generating the Database
        • Entity-Relationship Diagramming Tool
        • Database Design Transformer Tool
        • Server Model Diagram
        • End Result
          • Generation of Data Definition Language (DDL) scripts
        • Create database by running scripts

15.15

representing design specifications9
Representing Design Specifications
  • Prototyping
    • Oracle Designer: An Example
      • Transforming and Generating Software Modules
        • Data Flow Diagram
        • Functional Hierarchy Diagram
        • Application Design Transformer
          • Transforms diagrams into software modules which can be used to generate forms or reports
        • Generate form or report in Design Editor

15.16

radical methods extreme programming
Radical Methods: eXtreme Programming
  • Short cycles
  • Incremental planning approach
  • Automated tests
  • Utilizes two-person programming team
  • Planning, analysis, design and construction are fused together into one phase
  • Requirements and specifications are uniquely captured

15.17

radical methods extreme programming1
Radical Methods: eXtreme Programming
  • Planning game
    • Players
      • Business
      • Development
    • Story cards
      • Description of procedure or system feature

15.18

radical methods extreme programming2
Radical Methods: eXtreme Programming
  • Planning game
    • Three phases
      • Exploration
        • Business creates a story card
        • Development responds with time estimate
      • Commitment
        • Business sorts story cards into three stacks
        • Development sorts story cards according to risk
        • Business selects cards to include in next release of product
      • Steering
        • Business monitors development activity

15.19

radical methods extreme programming3
Radical Methods: eXtreme Programming
  • Iteration Planning Game
    • Played by programmers
    • Task Cards
      • Several task cards generated for each story card
      • Three phases
        • Exploration
          • Story cards converted to task cards
        • Commitment
          • Programmers accept responsibility for tasks
        • Steering
          • Programmers write code, test it and integrate it
      • Game takes place during time between intervals of planning game steering phase meetings

15.20

radical methods rad
Radical Methods: RAD
  • Four life-cycle phases
    • Planning
    • Design
    • Construction
    • Cutover
  • Iteration between design and construction

15.21

electronic commerce application
Electronic Commerce Application
  • Microsoft FrontPage used to build throwaway prototype
  • Template based HTML

15.22

summary
Summary
  • Types of Design Specifications
    • Written document augmented by various diagrams
    • Structure chart
    • Computer-based requirements management tool
    • Prototypes
      • Throwaway versus Evolutionary

15.23

summary1
Summary
  • Radical Methods
    • eXtreme Programming
    • RAD
  • Electronic Commerce Application
    • Throwaway prototyping

15.24

ad