1 / 24

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. Discuss the need for system design specifications Define quality requirements and write quality requirements statements

gil
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Faculty of Economics & Business (Systems Development : EBS 2033) Chapter 7 Finalizing Design Specifications Puan Asleena Helmi

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. Radical Methods: eXtreme Programming • Planning game • Players • Business • Development • Story cards • Description of procedure or system feature 15.18

  19. 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

  20. 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

  21. Radical Methods: RAD • Four life-cycle phases • Planning • Design • Construction • Cutover • Iteration between design and construction 15.21

  22. Electronic Commerce Application • Microsoft FrontPage used to build throwaway prototype • Template based HTML 15.22

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

  24. Summary • Radical Methods • eXtreme Programming • RAD • Electronic Commerce Application • Throwaway prototyping 15.24

More Related