Software Design 3 Dr. Pedro Meja Alvarez Departamento de Computacion CINVESTAV-IPN - PowerPoint PPT Presentation

About This Presentation

Software Design 3 Dr. Pedro Meja Alvarez Departamento de Computacion CINVESTAV-IPN


Software Design 3 Dr. Pedro Meja Alvarez Departamento de Computacion CINVESTAV-IPN – PowerPoint PPT presentation

Number of Views:364
Avg rating:3.0/5.0
Slides: 100
Provided by: UHCL4


Transcript and Presenter's Notes

Title: Software Design 3 Dr. Pedro Meja Alvarez Departamento de Computacion CINVESTAV-IPN

Software Design 3Dr. Pedro Meja
AlvarezDepartamento de ComputacionCINVESTAV-IPN
  • The exam specific topics covered in this module
    are listed below, and are the basis for the
    outline of its content
  • Software Design Concepts
  • Software Architecture
  • Software Design Quality Analysis and Evaluation
  • Software Design Notations and Documentation
  • Software Design Strategies and Methods
  • Human Factors in Software Design
  • Software and System Safety

  • After completing this module, you should be able
  • To describe the efforts and thoughts behind
    software design
  • To develop an understanding of the software
    design process
  • To describe software design approaches
  • To describe several software design techniques
  • To contrast architectural design with detailed

  • The organization of information for each
    specification topic is as follows
  • Topic Content Slides - detail the important
    issues concerning each topic and support the
    module objectives
  • Topic Reference Slides - detail the sources for
    the topical content and provides additional
    references for review
  • Topic Quiz Slides - allow students to prepare for
    the exam

  • The main goal of the software engineering process
    is the production of software that
  • Functions properly
  • On time
  • Within budget
  • Meets end-users needs
  • Software Design is a key piece of of this process

Characteristics of design (1)
  • Design situations start with a need and require
  • A need so identified acts as the initial
    motivational force that provides the basis for
    starting design work.
  • Design situations involve transformation
  • Design is the restructuring of a current
    situation to achieve some preferred situation
  • Generation of new ideas is fundamental to design
  • Design occurs whenever there is an imaginative
    jump from present facts to future possibilities.
  • The precise manner in which new ideas are
    generated cannot be codified.

Characteristics of design (2)
  • Constraint satisfaction
  • An initial need determines the most basic
    constraints and requirements on a design
  • In general, more constraints are eventually
    discovered during the design work itself.
  • The constraints that apply both to the designed
    artifact and to the processes and participants
    involved during the design activity.
  • Problem solving or decision making
  • The solution space for design problems is very
    large and its sheer size eliminates exhaustive
    search as a possible problem solving technique
  • design is characterized by a series of
    decisions between various design alternatives
  • Each divergent perspective may influence the
    progress of the design in different and
    unpredictable ways.

Characteristics of design (3)
  • Design results in a scheme for implementing an
  • Design is essentially the formulation of a
    prescription or model for a finished work in
    advance of its embodiment
  • Design representation serves as the basis to
    conceptualize and compare various design
  • Sometimes, a design does not result in a distinct
    plan-then-implement situation.
  • Often the design output occurs incrementally
    while the design and the artifact evolve together.

Characteristics of design (4)
  • Diversity and evolution
  • Any particular design situation could be drawn in
    many different directions.
  • The designers act of making decisions among the
    various identified design alternatives ties
    together this evolution of the design.
  • The evolution of a design is often closely linked
    to the consolidation of the constraints and
    requirements applied in a particular design

Characteristics of design (5)
  • Design situations start with a need and require
  • RE is needed before software design
  • Finding the problems, defining the requirements
  • Design situations involve transformation
  • Software changes the world
  • Designing base on limited objects (shared
    phenomenon) and fixed rules (domain

So, Requirements, Shared Phenomenon and Domain
Characteristics comprising the basis of software
design, that is Analysis Model
Analysis Model -gt Design Model
Characteristics of design (6)
A. Software Design Concepts
  • Definition of Software Design
  • A problem solving process in which the designer
    applies knowledge and experience to produce a
    conceptualization that defines and describes a
    solution to a problem
  • Software Design
  • Produces a description of the softwares internal
  • Describes the softwares architecture
  • Bridges the gap between software requirements and
    software code

A. Software Design Concepts - 2
  • Software Design Description (SDD)
  • A Software Design Description (SDD) is a
    representation of software created to facilitate
    analysis, planning, implementation, and
  • An SDD is
  • Used as a medium for communicating software
    design information
  • Like a blueprint or model of the system

A. Software Design Concepts - 3
  • The Problem with Software Design
  • Software requirements are frequently incomplete,
    incorrect, and inconsistent
  • Requirements change over time during development
  • Is a "Wicked Problem
  • Cannot be easily defined so that all stakeholders
    agree on the problem to solve
  • Require complex judgements about the level of
    abstraction at which to define the problem
  • Have no clear stopping rules
  • Have better or worse solutions, not right and
    wrong ones
  • Have no objective measure of success
  • Require iteration-every trial counts
  • Have no given alternative solutions-these must be
  • Often have strong moral, political or
    professional dimensions

A. Software Design Concepts - 4
  • Software Design
  • Functional and nonfunctional
  • Visible and invisible
  • Software Design Guidelines
  • A design should exhibit an architecture
  • A design should be modular
  • A design should contain distinct representations
  • A design should lead to data structures that are
  • A design should lead to components that exhibit
    independent functional characteristics.
  • A design should lead to interfaces that reduce
    the complexity.
  • A design should be derived using a repeatable
  • A design should be represented using a notation
    that effectively communicates its meaning.

A. Software Design Concepts - 5
  • Preliminary Design Creates representation of
    the data and architecture
  • Detailed Design A design activity that focuses
    on the creation of an algorithm
  • Object-Oriented An approach to software
    development that makes use of a classification
    approach and packages data and processing
  • Prototyping The creation of a model and the
    simulation of all aspects of a product.
  • Formal Methods A software engineering approach
    in which specification and design are described
    using mathematically-based formal notation

A. Software Design Concepts - 7
  • The Design Process
  • Review - Definition of Design
  • A problem solving process in which the designer
    applies knowledge and experience to produce a
    conceptualization that defines and describes a
    solution to a problem

Rational Unified Process (RUP) Analysis Design
A. Software Design Concepts - 8
  • Activities Associated with the RUP Analysis
    Design Discipline

A. Software Design Concepts - 9
  • Artifacts Associated with the RUP Analysis
    Design Discipline

A. Software Design Concepts - 10
  • Software Design can be represented in many ways
  • Examples
  • Flow Charts
  • Use-Case Realizations
  • Data Flow Diagrams
  • Pseudocode
  • State Diagrams
  • Activity Diagrams
  • Subsystem Diagrams
  • Text Documents
  • Any combination of these

A. Software Design Concepts - 11
  • Design Phases
  • Two Types of Design
  • Architecture
  • Detailed

Architecture Design Specify components, their
interfaces, and their interactions with other
Detailed Design Specify the internal structure
and behavior of each component
A. Software Design Concepts - 12
  • Several Approaches to Architectural Design
  • Top-Down
  • Starts with the highest level of abstraction and
    recursively fills in details of the subparts
  • Bottom-Up
  • Start with the lowest-level components and
    describe how these work together to accomplish
    the systems goals
  • Opportunistic
  • Some combination of the above two approaches

A. References
  • CD04 The Computer Dictionary http//, 2004
  • CE96 CERN, STING Software Engineering
    Glossary, http//
    ausler/web/glossary.html, 1996
  • DD88 Department of Defense, MIL-STD-2167A,
  • HR84 Rittel, H. J., and M. M. Webber (1984).
    "Planning problems are wicked problems", In N.
    Cross (Ed.), Developments in Design Methodology,
    Wiley, pp. 135-144.
  • HR84 Rittel, H. J., and M. M. Webber (1984).
    Planning problems are wicked problems, Wiley,
  • LB98 Bass, Len et al, p. 298, Software
    Architecture in Practice, Addison-Wesley, Boston,
  • RH97 Hubscher, Roland, LBD Conceptual Design
    Problems, http//
    l-defined-problems.html, June 11, 1997
  • RP03 Pressman, R.S. 2003, Software
    Engineering Resources, http//

A. References (cont.)
  • RS04 IBM Rational Software, The Rational
    Unified Process v2003.06.13, 2004
  • SB97 Buckingham Shum, S., "Representing
    Hard-to-Formalise, Contextualised,
    Multidisciplinary, Organisational Knowledge,
  • SD04, http//
    torials, 2004
  • SF03, http//cweb.sourceforge.n
    et/cgi-bin/moin.cgi/ObjectFlow, 2003

B. Software Architecture
  • Software architecture encompasses
  • Overall organization of the software system
  • Selection of the structural elements and
    specification of their
  • Interfaces
  • Behavior
  • Composition of these elements into progressively
    larger subsystems
  • The architectural style

B. Software Architecture - 2
  • Software architecture is also concerned with
  • Usage
  • Functionality
  • Performance
  • Resilience
  • Reuse
  • Comprehensibility
  • Economic and technology constraints and tradeoffs
  • Aesthetics

B. Software Architecture - 3
  • Architecture-Based Process
  • An example of an architecture-first approach
  • Create the business case for the system
  • Analyze the requirements
  • Decide on a software architecture
  • Specify the architecture
  • Communicate the architecture
  • Evaluate the architecture
  • Implement the system based on the architecture
  • Ensure the implementation conforms to the

B. References
  • LB98 Bass, Len et al, p. 298, Software
    Architecture in Practice, Addison-Wesley, Boston,
  • OG03 Object Management Group, Model Driven
    Architecture Guide, v1.0.1, http//
    , July 12, 2003
  • RS04 IBM Corporation, 2004, The Rational
    Unified Process v2003.06.13

C. Software Design Quality Analysis Evaluation
  • Many methods to analyze design quality
  • No single method, by itself, is sufficient
  • This module looks at quality programs in general
    and quality design attributes in particular

C. Software Design Quality Analysis Evaluation
- 2
  • What is Quality?
  • A measure of how good something is
  • Very natural concept in traditional manufacturing
  • Tolerance
  • Capacity
  • Strength
  • Size
  • Color
  • Weight
  • Not quite as natural for software

C. Software Design Quality Analysis Evaluation
- 3
  • Quality Concept
  • Meaning of quality has evolved over time
  • Conforming to the specification
  • Fitness for use
  • 2 dimensional model
  • must have vs.
  • nice to have

C. Software Design Quality Analysis Evaluation
- 4
  • Total Quality Management
  • Management strategy to embed quality awareness in
    all processes
  • Employs statistical methods
  • Goal to do things right the first time instead of
    fixing later
  • Metrics regarding failures are collected and
  • Then the process that caused the failure is fixed
  • Has roots in manufacturing
  • But applicable to software development also

C. Software Design Quality Analysis Evaluation
- 5
  • Quality Management System
  • Quality Management System (QMS) fathered by
    William Deming
  • Can be implemented with one of any number of
    quality management programs
  • Six Sigma
  • ISO 9000 Series
  • Total Quality Management (TQM)
  • Malcolm Baldrige National Quality Award
  • Recognizes high-quality U.S. companies

C. Software Design Quality Analysis Evaluation
  • Six Sigma
  • Quality management program
  • Six Sigma quality level goal
  • Pioneered by Motorola
  • Roughly fewer than 3.4 defects in one million
  • Very difficult to achieve in practice
  • Some market leaders have obtained six sigma

C. Software Design Quality Analysis Evaluation
- 7
  • ISO 9000 Series
  • Another instance of a Quality Management System
  • Guides the production of a product or service
  • A series of standards
  • ISO 9000 Basic language for the entire ISO 9000
  • ISO 9001 For organizations who design, develop,
    test, install, and service their product
  • ISO 9002 For organizations who test, install
    and service a product
  • ISO 9003 For organizations who test final
  • ISO 9004 Guidance for compliance and customer

C. Software Design Quality Analysis Evaluation
- 8
  • ISO 9000-3
  • Software related, specifically for companies that
  • Develop
  • Supply
  • Install
  • Maintain
  • End-to-end procedures to track products
  • Guidelines for the application of ISO 9001 to the
    development, supply, and maintenance of software

C. Software Design Quality Analysis Evaluation
- 9
  • Three Classifications of Quality
  • System quality attributes categories
  • Discernable by observing system execution
  • E.g. performance, functionality, reliability
  • Not discernable at runtime
  • E.g. modifiability, portability, reusability
  • Business qualities
  • E.g. Time to market, marketability

C. Software Design Quality Analysis Evaluation
- 10
  • Quality attributes that are discernable at system
  • Performance
  • Two Aspects of Performance
  • Response time
  • Number of transactions per some time interval
  • SecurityMeasure of the systems ability to
    resist unauthorized usage
  • Availability
  • Measure of the proportion of time a system is up
    and running
  • Functionality
  • Ability of the system to do the work for which it
    was intended
  • Usability
  • Extent to which a system is easy learn and use on
    an ongoing basis

C. Software Design Quality Analysis Evaluation
- 11
  • Quality attributes that are not discernable at
    system runtime
  • Modifiability
  • Ability of the system to be enhanced and
    maintained over time
  • Portability
  • Ability of the system to run in different
    operating environments
  • Reusability
  • Ability of the system, or parts thereof, to be
    used to construct other systems
  • Integrability
  • Ability of the various components of a system to
    be made to work together
  • Testability
  • Ability to objectively measure the system against
    its requirements

C. Software Design Quality Analysis Evaluation
- 12
  • Business Qualities
  • Qualities that are related to business aspects
  • Time to Market
  • Release before competition
  • Release while demand for product exists
  • Marketability
  • Cost
  • Competition
  • Target Market

C. Software Design Quality Analysis Evaluation
- 13
  • What is a Good Design?
  • Well Structured
  • Simple
  • Efficient
  • Adequate
  • Flexible
  • Practical
  • Implementable

C. Software Design Quality Analysis Evaluation
- 14
  • Design Quality
  • Techniques to assess design quality include
  • Design Verification
  • Design Analysis
  • Design Reviews
  • Design Audit
  • Informal Design Walkthrough
  • Formal Design Inspection

C. Software Design Quality Analysis Evaluation
- 15
  • Design Inspections
  • Step-by-step review
  • Roles involved
  • Moderator
  • Reviewer
  • Author
  • Scribe
  • Each step checked against a list of criteria such
  • Historical errors
  • Programming standards
  • Adherence to specifications
  • The developer is responsible for narrating the
  • Design inspections should occur for
  • Preliminary Design
  • Detailed Design
  • Implementation

C. Software Design Quality Analysis Evaluation
- 16
  • Design Walkthroughs
  • Similar to inspections but
  • Developer does not narrate the design
  • Team lead or architect leads the walkthrough
  • Manual simulation of the system
  • Intermediate results are recorded
  • Good for simulating discussion
  • Many errors are caught by the developer

C. Software Design Quality Analysis Evaluation
- 17
  • Quality Design Aspects
  • Fan-Out
  • The number of routines a given routine calls
  • Information Hiding
  • Abstraction technique that hides details behind
    and interface
  • Cohesion
  • Cohesion refers to the degree to which a modules
    instructions are functionally related
  • Coupling
  • Level of dependency that exists between modules

C. References
  • LB98 Bass, Len et al., Software Architecture
    in Practice, Addison-Wesley, 1998
  • DP87 Parnas, D.L, and D. M. Weiss, Activity
    Design Reviews Principles and Practices,
    Journal of Systems and Software, Vol. 7, 1987,
    pp. 259-265
  • IS96 IEEE Software, Keep It Simple, Vol. 13,
    No. 6, December, 1996
  • PR04 Praxiom Research Group Limited,
  • RP05 Pressman, Roger S., Software
    Engineering A Practitioners Approach, 6th
    Edition, McGraw-Hill, 2005
  • WA82 Adrion, W. Richards., Validation,
    Verification, and Testing of Computer Software,
    ACM Computing Surveys, Vol 14, No. 2, June, 1982

D. Software Design Notations and Documentation
  • Structural Description Examples
  • Class and object diagrams and their relationships
  • CRC cards
  • Entity-Relationship Diagrams (ERD) used to define
    conceptual models of data
  • Interface description language to deine the
    interfaces of software components
  • Structure charts to describe the calling
    structure of programs
  • Use case diagrams to model functional
    requirements form the perspective of the user

D. Software Design Notations and Documentation - 2
  • Why We Model
  • Top reasons for modeling software
  • Provide the blueprint for our system
  • Facilitate communication among project team
  • Assures architectural soundness
  • Attributes of an appropriate modeling language
  • Model elements
  • Notation
  • Guidelines

Model Elements
D. Software Design Notations and Documentation - 3
  • Functional vs. Object Oriented
  • Two fundamental approaches to software design
  • Functional
  • Object-Oriented
  • Functional (a.k.a Structured) takes the
    approach that high level functionality can be
    repeatedly broken down into smaller and smaller
    functions in order to reduce complexity.
  • Object-Oriented takes the approach that
    functionality belongs with objects, which are
    software elements that have identity and whose
    state and behavior is self-contained.

D. Software Design Notations and Documentation - 4
  • Five Aspects of Structured Design
  • Form of the problem guides the form of the
  • Reduces complexity by organizing the system into
    a hierarchy of black boxes
  • Uses graphical tools to render systems readily
  • Provides solution strategies based on a
    well-defined problem statement
  • Provides criteria for evaluating the quality of
    the design

D. Software Design Notations and Documentation - 5
  • Four goals of Structured Design
  • Each black box should solve well-defined piece of
    the problem
  • The system should be partitioned so that the
    function of each black box is easy to understand
  • Partitioning should be done so that any
    connection between black boxes is introduces only
    because of a connection between pieces of the
  • Partitioning should assure that the connections
    between black boxes are made as simple as possible

D. Software Design Notations and Documentation - 6
  • Key Structured Diagrams
  • Like any approach to software design, a
    structured approach prescribes certain diagrams
  • Data Flow Diagram
  • Shows the partitioning of the system into
    processes, data sources, data sinks, and data
  • Shows how data flows between these elements
  • Structure Chart
  • Shows the partitioning of a system into modules
    (black boxes)
  • Shows how modules communicate with each other

D. Software Design Notations and Documentation - 7
Data Flow Diagram Example
D. Software Design Notations and Documentation - 8
Structure Chart Example
D. Software Design Notations and Documentation - 9
  • Structured Transform Process by which Data Flow
    Diagrams (DFDs) are converted (transformed) into
    structure charts
  • DFDs are considered the analysis artifact
  • The resulting structure chart is the design

D. Software Design Notations and Documentation -
  • Unified Modeling Language
  • What is it?
  • The Unified Modeling Language (UML) is a language
    for specifying, visualizing, constructing, and
    documenting the artifacts of software systems, as
    well as for business modeling and other
    non-software systems. The UML represents a
    collection of the best engineering practices that
    have proven successful in the modeling of large
    and complex systems.
  • -- OMG Unified Modeling Language Specification

D. Software Design Notations and Documentation
  • History of the UML
  • In 1994 approximately 50 distinct, identifiable,
    object-oriented methods
  • Three popular methods
  • OOSE (Ivar Jacoboson)
  • OMT-2 (James Rumbaugh)
  • Booch 93 (Grady Booch)
  • Rational Software hires Rumbaugh to join Booch in
  • Booch 93 and OMT-2 melded to create Unified
    Method 0.8
  • Jacobson joins Rational Software in 1995
  • Use cases merged into Unified Method to create
    UML 0.9
  • Rational partners with industry leaders in 1996
    to respond to OMG RFP
  • UML 1.0 accepted by OMG in 1996

D. Software Design Notations and Documentation -
  • The primary design goals of the UML
  • Provide users with a ready-to-use, expressive
    visual modeling language to develop and exchange
    meaningful models
  • Furnish extensibility and specialization
    mechanisms to extend the core concepts
  • Support specifications that are independent of
    particular programming languages and development
  • Provide a formal basis for understanding the
    modeling language
  • Encourage the growth of the object tools market
  • Support higher-level development concepts such as
    components, collaborations, frameworks and
  • Integrate best practices

D. Software Design Notations and Documentation -
  • Scope of the UML
  • In scope
  • Model notation and semantics specification
  • Extensibility mechanisms
  • Model interchange mechanisms
  • Common repository interface specification
  • Out of scope
  • Programming languages
  • Tools
  • Process

D. Software Design Notations and Documentation -
  • Primary Artifacts of the UML
  • Use the ones appropriate for the task at hand
  • Dont have to use all artifacts
  • No single view is sufficient
  • Models can be expressed at different levels of
  • The best models reflect reality
  • Three categories of diagrams
  • Structure Diagrams
  • Behavior Diagrams
  • Implementation Diagrams

D. Software Design Notations and Documentation -
  • Diagrams in the UML
  • A diagram is the graphical presentation of a set
    of elements, most often rendered as a connected
    graph of vertices (things) and arcs
    (relationships) Grady Booch
  • Static Diagrams
  • Use Case
  • Class
  • Object
  • Component
  • Deployment
  • Dynamic Diagrams
  • Statechart
  • Activity
  • Sequence
  • Collaboration

D. Software Design Notations and Documentation -
Courtesy IBM Rational Software
D. Software Design Notations and Documentation -
  • Class Diagram
  • Contains classes, interfaces, collaborations, and
  • Models system vocabulary, collaborations,
    database schema

D. Software Design Notations and Documentation -
  • Object Diagram
  • Contains objects and links
  • Models objects structures and relationships

D. Software Design Notations and Documentation -
  • Use Case Diagram
  • Contains use cases, actors, and relationships
  • Models the context and requirements of a system

D. Software Design Notations and Documentation -
  • Sequence Diagram
  • Contains objects, links, and messages
  • Models flows of control by time ordering

D. Software Design Notations and Documentation -
  • Collaboration Diagrams
  • Contains objects, links, and messages
  • Models flows of control by logical organization

D. Software Design Notations and Documentation -
  • Statechart Diagram
  • Contains simple states, composite states,
  • Models reactive objects

D. Software Design Notations and Documentation -
  • Activity Diagram
  • Contains action and activity states, transitions,
    and objects
  • Models a workflow or operation

D. Software Design Notations and Documentation -
  • Component Diagram
  • Contains components, interfaces, and
  • Models source code, executables, and physical

D. Software Design Notations and Documentation -
  • Deployment Diagram
  • Contains nodes and relationships
  • Models details of various types of systems such
    as embedded, client/server, distributed

D. References
  • GB99 Grady Booch. The Unified Modeling
    Language User Guide, Addison Wesley, Reading, MA,
  • IE01 IEEE Computer Society, Guide to the
    Software Engineering Body of Knowledge (SWEBOK),
    IEEE Computer Society Press, Los Alamitos, CA
  • MP80 Page-Jones, Meilir. The Practical Guide
    to Structured Systems Design, Yourdon Press, NY,
    NY, 1980
  • OG03 Object Management Group (OMG), OMG Unified
    Modeling Language Specification, v1.5, March 2003

E. Software Design Strategies and Methods
  • Design methods guide the software designer
  • This section provides details on design
  • Fundamentals
  • Models
  • Historical background

E. Software Design Strategies and Methods - 2
  • Historical Perspective
  • Software design methodologies continue to evolve
  • Still a young, relatively immature science
  • Demands for new applications and major
    enhancements to existing ones have grown
  • Successful projects have been the exception, not
    the norm
  • Problems due to inability to sufficiently
  • Translate complex problems to workable software
  • Take end-user opinions and practical needs into
  • Take into account the organizational environment
  • Accurately estimate the development time and
    cost, and the operational costs
  • Review the project progress with the customers in
    a regular and consistent manner
  • Anticipate performance/technology tradeoffs

E. Software Design Strategies and Methods - 3
  • Historical Perspective (cont.)
  • Late 60s to early 70s many important software
    engineering concepts were introduced, including
  • Top-down design
  • Stepwise refinement
  • Modularity
  • Structure programming
  • These helped, but there was still a need for
    methodologies that
  • Were more complete
  • Were faster to use
  • Were suitable for fourth-generation languages and
    application generators
  • Solved maintenance issues
  • Were suitable for graphically-intensive

E. Software Design Strategies and Methods - 4
  • Historical Methods
  • Flow charts
  • Program Design Languages (PDL)
  • Forms
  • Data structures
  • Data flow

E. Software Design Strategies and Methods - 5
  • Object-Oriented Trend
  • Object-oriented is a proven approach to the
    analysis and design of large, complex computer
  • Focuses on objects, their state and behavior
  • As opposed to a functional decomposition approach
  • CASE tools, 4th Generation Languages (4GLs), and
    design languages supplement object-orientation,
  • Powerbuilder
  • Visual Basic
  • Unified Modeling Language

E. Software Design Strategies and Methods - 6
  • More on Object-Oriented
  • Origins in Smalltalk
  • By Xerox Palo Alto Research Center (PARC)
  • GUI-based IDE for O-O programming
  • Why Object Oriented has caught on
  • Higher level focus (analysis/design vs.
  • Underlying support platforms are capable
  • Proven for large, complex applications
  • Domain-oriented trends of modern applications
    well suited to object-orientation

E. Software Design Strategies and Methods - 7
  • Beyond Waterfall
  • The waterfall approaching to software development
    is not appropriate for most projects
  • Project on the road to failure frequently exhibit
    these symptoms
  • Extended integration periods
  • Late design breakage
  • Late risk resolution
  • Focus on documents and reviews

E. Software Design Strategies and Methods - 8
  • Design Fundamentals
  • Three aspects of all information systems
  • Data, structure, procedures
  • Each of these are addressed during software
  • Data Design
  • Architectural Design
  • a.k.a. high-level or preliminary
  • Procedural
  • a.k.a low-level or detailed

E. Software Design Strategies and Methods - 9
  • Design Fundamentals (cont.)
  • Proven methods help designers by providing
  • A mechanism translating the physical problem to
    its design representation
  • A notation for representing functional components
    and their interfaces
  • Heuristics for refinement and partitioning
  • Guidelines for quality assessment
  • Fundamental concepts of software engineering
  • Stepwise refinement
  • Architecture
  • Program structure
  • Data structure
  • Modularity
  • Abstraction
  • Information hiding

E. Software Design Strategies and Methods - 10
  • Fundamentals Defined
  • Stepwise Refinement
  • Abstraction
  • Software Architecture
  • Program Structure

E. Software Design Strategies and Methods - 11
  • Fundamentals Defined (cont.)
  • Data Structure
  • Modularity
  • Software Procedure
  • Information Hiding

E. References
  • RV95 Robert L. Vienneau and Roy Senn, A State
    of the Art Report Software Design Methods, Data
    Analysis Center for Software (DACS), March 1995
  • WR01 Walker Royce, Software Project
    Management, A Unified Framework, Addison-Wesley,
    Boston, MA, 2001

F. Human Factors in Software Design
  • What is Human Factors Design?
  • Specification of how users use a system
  • Considers
  • Working environment
  • Background
  • Ergonomics
  • Cognitive capabilities

F. Human Factors in Software Design - 2
  • User Interface Basics
  • What is the User Interface?
  • Menus
  • Windows
  • Keyboard
  • Mouse
  • Sounds

F. Human Factors in Software Design - 3
  • UI Design Overview
  • Interface must be match to the task
  • Specific guidelines
  • Menu design
  • Icon labels
  • Placement of screen elements

F. Human Factors in Software Design - 4
  • User Interface Design
  • Prototype User Interface
  • Screen mock-ups
  • Screen navigation
  • Intended to obtain feedback

F. Human Factors in Software Design - 5
  • Steps in defining the User Interface
  • Describe the characteristics of users
  • Define the navigation map
  • Detail the design of the user-interface elements
  • Design the user actions of the primary windows

F. Human Factors in Software Design - 6
  • DoD Mil Std 1472
  • This standard establishes general human
    engineering criteria for design and development
    of military systems, equipment and facilities.
    Its purpose is to present human engineering
    design criteria, principles and practices to be
    applied in the design of systems, equipment and
    facilities so as to
  • Achieve required performance by operator, control
    and maintenance personnel
  • Minimize skill and personnel requirements and
    training time
  • Achieve required reliability of
    personnel-equipment combinations
  • Foster design standardization within and among

F. References
  • CL94 Clayton Lewis and John Rieman,
    Task-Centered User Interface Design A Practical
    Introduction, ftp//
    tribs/clewis/HCI-Design-Book, 1994
  • DD89 DoD Military Standard 1472D Human
    Engineering Design Criteria for Military Systems
    Equipment and Facilities, March 14, 1989
  • RS04 IBM Rational Software, The Rational
    Unified Process v2003.06.13, 2004

G. Software and System Safety
  • Computers are pervasive
  • Automobiles
  • Consumer electronics
  • Medical devices
  • Avionics systems
  • Weapon systems
  • Virtually nothing manufactured in the U.S. today
    is not impacted by computers
  • Complexities are ever increasing
  • Safety has been and will continue to be a very
    important issue in software engineering

G. Software and System Safety - 2
  • Types of Errors
  • Algorithmic faults
  • Computational faults
  • Documentation faults
  • Stress or overload faults
  • Capacity and boundary faults

G. Software and System Safety - 3
  • More Types of Errors
  • Timing and coordination faults
  • Throughput and performance faults
  • Recovery faults
  • Hardware and system software faults
  • Standard and procedures faults

G. Software and System Safety - 4
  • Hazard Identification
  • Easiest way to identify hazards is after the
  • Obviously the hazard should be avoided
  • The only valid method therefore is to develop a
    list of potential hazards before the system is
  • Three techniques
  • Delphi
  • Joint Application Design (JAD)
  • Hazard and Operability Analysis

G. Software and System Safety - 5
  • Analyzing Hazards
  • The purpose of hazard analysis is to examin the
    system and determine which components of the
    system may lead to a mishap
  • Two basic strategies
  • Inductive techniques, e.g. an event tree analysis
    and failure modes and effects analysis
  • Deductive techniques, e.g. fault tree analysis

G. Software and System Safety - 6
  • Fault Tree Analysis
  • Starts with a particular undesirable event and
    provides an approach for analyzing the causes of
    this event
  • Once the undesirable event has been chosen, it is
    used as the top event of a fault tree diagram
  • The fault tree is a graphical representation of
    the various combinations of events that lead to
    the undesired event
  • The system is then analyzed to determine all the
    likely ways in which that undesired event could
  • The faults may be caused by component failures,
    human failures, or any other events that could
    lead to the undesired events

G. Software and System Safety - 7
  • Event Tree Analysis
  • Event tree analysis is to consider an initiating
    event in the system and consider all the
    consequences of the occurrence of that event,
    particularly those that lead to a mishap
  • Fault tree analysis is backward looking and
    considers knowledge of past problems
  • Event tree analysis is forward looking and
    considers potential future mishaps

G. References
  • PP92 Patrick R. Place and Xyo C. Kang,
    Safety-Critical Software Status Report and
    Annotated Bibliography, CMU/SEI-92-TR-5, Carnegie
    Mellon, Pittsburgh, PA 1992
Write a Comment
User Comments (0)