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

1
Software Design 3Dr. Pedro Meja
AlvarezDepartamento de ComputacionCINVESTAV-IPN
2
Specifications

• 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

3
Objectives

• After completing this module, you should be able
  to
• 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
  design

4
Organization

• 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

5
Introduction

• 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

6
Characteristics of design (1)

• Design situations start with a need and require
  intention
• 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
  situations
• 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.

7
Characteristics of design (2)

• Constraint satisfaction
• An initial need determines the most basic
  constraints and requirements on a design
  situation.
• 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.

8
Characteristics of design (3)

• Design results in a scheme for implementing an
  artifact
• 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
  decisions.
• 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.

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

10
Characteristics of design (5)

• Design situations start with a need and require
  intention
• 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
  characteristics)

So, Requirements, Shared Phenomenon and Domain
Characteristics comprising the basis of software
design, that is Analysis Model
11
Analysis Model -gt Design Model
Characteristics of design (6)
12
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
  construction
• Describes the softwares architecture
• Bridges the gap between software requirements and
  software code

13
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
  decision-making
• An SDD is
• Used as a medium for communicating software
  design information
• Like a blueprint or model of the system

14
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
  discovered
• Often have strong moral, political or
  professional dimensions

15
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
  appropriate.
• 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
  method.
• A design should be represented using a notation
  that effectively communicates its meaning.

16
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
  together
• 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

17
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
Workflow
18
A. Software Design Concepts - 8

• Activities Associated with the RUP Analysis
  Design Discipline

19
A. Software Design Concepts - 9

• Artifacts Associated with the RUP Analysis
  Design Discipline

20
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

21
A. Software Design Concepts - 11

• Design Phases
• Two Types of Design
• Architecture
• Detailed

Architecture Design Specify components, their
interfaces, and their interactions with other
components
Detailed Design Specify the internal structure
and behavior of each component
22
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

23
A. References

• CD04 The Computer Dictionary http//www.computer
  dictionary.info, 2004
• CE96 CERN, STING Software Engineering
  Glossary, http//www.apl.jhu.edu/Classes/Notes/H
  ausler/web/glossary.html, 1996
• DD88 Department of Defense, MIL-STD-2167A,
  1998
• 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,
  1984
• LB98 Bass, Len et al, p. 298, Software
  Architecture in Practice, Addison-Wesley, Boston,
  1998.
• RH97 Hubscher, Roland, LBD Conceptual Design
  Problems, http//www.cc.gatech.edu/edutech/LBD/il
  l-defined-problems.html, June 11, 1997
• RP03 Pressman, R.S. 2003, Software
  Engineering Resources, http//www.rspa.com/spi/gl
  ossary.html

24
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,
  1997
• SD04 SmartDraw.com, http//www.smartdraw.com/tu
  torials, 2004
• SF03 SourceForge.net, http//cweb.sourceforge.n
  et/cgi-bin/moin.cgi/ObjectFlow, 2003

25
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

26
B. Software Architecture - 2

• Software architecture is also concerned with
• Usage
• Functionality
• Performance
• Resilience
• Reuse
• Comprehensibility
• Economic and technology constraints and tradeoffs
• Aesthetics

27
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
  architecture

28
B. References

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

29
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

30
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

31
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

VS.
32
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
  analyzed
• Then the process that caused the failure is fixed
• Has roots in manufacturing
• But applicable to software development also

33
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

34
C. Software Design Quality Analysis Evaluation
6

• 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

35
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
  family
• 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
  products
• ISO 9004 Guidance for compliance and customer
  satisfaction

36
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

37
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

38
C. Software Design Quality Analysis Evaluation
- 10

• Quality attributes that are discernable at system
  runtime
• 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

39
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

40
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

41
C. Software Design Quality Analysis Evaluation
- 13

• What is a Good Design?
• Well Structured
• Simple
• Efficient
• Adequate
• Flexible
• Practical
• Implementable

42
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

43
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
  as
• Historical errors
• Programming standards
• Adherence to specifications
• The developer is responsible for narrating the
  design
• Design inspections should occur for
• Preliminary Design
• Detailed Design
• Implementation

44
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

45
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

46
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,
  http//praxiom.com/iso-9000-3b.htm
• 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

47
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

48
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
  members
• Assures architectural soundness
• Attributes of an appropriate modeling language
• Model elements
• Notation
• Guidelines

Guidelines
Model Elements
Notation
49
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.

50
D. Software Design Notations and Documentation - 4

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

51
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
  problem
• Partitioning should assure that the connections
  between black boxes are made as simple as possible

52
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
  stores
• 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

53
D. Software Design Notations and Documentation - 7
Data Flow Diagram Example
54
D. Software Design Notations and Documentation - 8
Structure Chart Example
55
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
  artifact

56
D. Software Design Notations and Documentation -
10

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

57
D. Software Design Notations and Documentation
11

• 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
  1994
• 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

58
D. Software Design Notations and Documentation -
12

• 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
  processes
• 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
  patterns
• Integrate best practices

59
D. Software Design Notations and Documentation -
13

• 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

60
D. Software Design Notations and Documentation -
14

• 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
  detail
• The best models reflect reality
• Three categories of diagrams
• Structure Diagrams
• Behavior Diagrams
• Implementation Diagrams

61
D. Software Design Notations and Documentation -
15

• 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

62
D. Software Design Notations and Documentation -
16
Courtesy IBM Rational Software
63
D. Software Design Notations and Documentation -
17

• Class Diagram
• Contains classes, interfaces, collaborations, and
  relationships
• Models system vocabulary, collaborations,
  database schema

64
D. Software Design Notations and Documentation -
18

• Object Diagram
• Contains objects and links
• Models objects structures and relationships

65
D. Software Design Notations and Documentation -
19

• Use Case Diagram
• Contains use cases, actors, and relationships
• Models the context and requirements of a system

66
D. Software Design Notations and Documentation -
20

• Sequence Diagram
• Contains objects, links, and messages
• Models flows of control by time ordering

67
D. Software Design Notations and Documentation -
21

• Collaboration Diagrams
• Contains objects, links, and messages
• Models flows of control by logical organization

68
D. Software Design Notations and Documentation -
22

• Statechart Diagram
• Contains simple states, composite states,
  transitions
• Models reactive objects

69
D. Software Design Notations and Documentation -
23

• Activity Diagram
• Contains action and activity states, transitions,
  and objects
• Models a workflow or operation

70
D. Software Design Notations and Documentation -
24

• Component Diagram
• Contains components, interfaces, and
  relationships
• Models source code, executables, and physical
  databases

71
D. Software Design Notations and Documentation -
25

• Deployment Diagram
• Contains nodes and relationships
• Models details of various types of systems such
  as embedded, client/server, distributed

72
D. References

• GB99 Grady Booch. The Unified Modeling
  Language User Guide, Addison Wesley, Reading, MA,
  1999
• IE01 IEEE Computer Society, Guide to the
  Software Engineering Body of Knowledge (SWEBOK),
  IEEE Computer Society Press, Los Alamitos, CA
  20001
• 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

73
E. Software Design Strategies and Methods

• Design methods guide the software designer
• This section provides details on design
• Fundamentals
• Models
• Historical background

74
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
  dramatically
• Successful projects have been the exception, not
  the norm
• Problems due to inability to sufficiently
• Translate complex problems to workable software
  solutions
• Take end-user opinions and practical needs into
  account
• 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

75
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
  applications

76
E. Software Design Strategies and Methods - 4

• Historical Methods
• Flow charts
• Program Design Languages (PDL)
• Forms
• Data structures
• Data flow

77
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
  systems
• 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,
  examples
• Powerbuilder
• Visual Basic
• Unified Modeling Language

78
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.
  programming)
• Underlying support platforms are capable
• Proven for large, complex applications
• Domain-oriented trends of modern applications
  well suited to object-orientation

79
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

80
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
  design
• Data Design
• Architectural Design
• a.k.a. high-level or preliminary
• Procedural
• a.k.a low-level or detailed

81
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

82
E. Software Design Strategies and Methods - 10

• Fundamentals Defined
• Stepwise Refinement
• Abstraction
• Software Architecture
• Program Structure

83
E. Software Design Strategies and Methods - 11

• Fundamentals Defined (cont.)
• Data Structure
• Modularity
• Software Procedure
• Information Hiding

84
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

85
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

86
F. Human Factors in Software Design - 2

• User Interface Basics
• What is the User Interface?
• Menus
• Windows
• Keyboard
• Mouse
• Sounds

87
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

88
F. Human Factors in Software Design - 4

• User Interface Design
• Prototype User Interface
• Screen mock-ups
• Screen navigation
• Intended to obtain feedback

89
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

90
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
  systems

91
F. References

• CL94 Clayton Lewis and John Rieman,
  Task-Centered User Interface Design A Practical
  Introduction, ftp//ftp.cs.colorado.edu/pub/cs/dis
  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

92
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

93
G. Software and System Safety - 2

• Types of Errors
• Algorithmic faults
• Computational faults
• Documentation faults
• Stress or overload faults
• Capacity and boundary faults

94
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

95
G. Software and System Safety - 4

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

96
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

97
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
  occur
• The faults may be caused by component failures,
  human failures, or any other events that could
  lead to the undesired events

98
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

99
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