Faculty of economics business systems development ebs 2033
This presentation is the property of its rightful owner.
Sponsored Links
1 / 24

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


  • 62 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Faculty of Economics & Business (Systems Development : EBS 2033)

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


  • Login