CS456 Software Engineering Workshop

1
CS456Software Engineering Workshop

• Keith Bennett
• Department of Computer Science
• Washington University in St. Louis

2
1st Class

• Review Class Handout
• Review Class Schedule
• Review Article List
• Review Other Resources
• Web Site

3
Class Lectures

• Introduction to Software Engineering
• Software Development Lifecycle
• Methods, Models, and Processes
• Software Requirements
• UML and Objectory Overview
• Software Design Issues
• Software Integration and Testing
• Software Project Management

4
Introduction to Software Engineering

• Intro to Software Engineering - What Is It?
• Intro to Software Engineering - Engineering?
• Intro to Software Engineering - Who Is It?
• Intro to Software Engineering - Why Is It
  Important?
• Intro to Software Engineering - Software Entropy
• Intro to Software Engineering - What are the Key
  Factors?

5
Intro to Software Engineering - What Is It?

• What is Software Engineering?
• How Does it Relate to Computer Science?
• How Does it Relate to Computer Programming?
• Is There One Definition of Software Engineering?
• Why Does Everyone Seem to Have a Different
  Opinion?

6
Intro to Software Engineering - Engineering?

• What is Engineering?
• Is Software Engineering Engineering?

7
Intro to Software Engineering - Who Is It?

• What is the Role of the Software Engineer?
• What is a Requirements Engineering?
• Who are the Customers?
• Who are the Users?
• Who Pays?
• Others?

8
Intro to Software Engineering - Why Is It
Important?

• What is the Software Crisis?
• What Causes Software Failures

9
Intro to Software Engineering - Software Entropy

• The 2nd Law of Thermodynamics, in princple,
  states that a closed systems disorder cannot be
  reduced, it can only increase or possibly remain
  unchanged. A measure of this disorder is
  entropy.
• Software Entropy is the application of this
  concept to software, I.e. a systems disorder, or
  entropy, always increases.
• Fundemental Software Concept
• A program that is used will be modified.
• When a program is modified, its complexity will
  increase provided that one does not actively work
  against this.

10
Intro to Software Engineering - What are the Key
Factors?

• How Does Cost and Schedule Effect Software?
• What is Software Quality?

11
Software Development Lifecycle

• Software Development Lifecycle
• S/W Development Lifecycle - Issues driving
  software
• S/W Development Lifecycle - Types of Software
• S/W Development Lifecycle - System vs.. Software
• S/W Development Lifecycle - Confusion of Terms
• S/W Development Lifecycle - Development
• S/W Development Lifecycle - Development Details
• S/W Development Lifecycle - Development Terms

12
Software Development Lifecycle
13
S/W Development Lifecycle - Issues driving
software

• Time/Schedule
• Changing technology
• Safety
• Reliability
• Cost
• Platforms
• Methods

14
S/W Development Lifecycle - Issues driving
software (cont)

• Silverbullet Concepts
• Moving target syndrom
• Issues with time in development
• Terminology Problems

15
S/W Development Lifecycle - Types of Software

• Technical Applications
• Examples
• Tactical Command and Control Systems
• Process Control Systems
• Telecommunication Systems
• Embedded Control Systems
• Control Driven
• Administrative Applications
• Examples
• Order-Entry Systems
• Reservation Systems
• Enterprise or Business Driven
• Many System a Combination of Both

16
S/W Development Lifecycle - System vs. Software

• How Does System relate to Software?
• Why use the term Software System?

17
S/W Development Lifecycle - Confusion of Terms

• How Does Requirements relate to Design
• Requirements are relative, I.e. a Point of View
• System Requirements vs. Software Requirements
• Depends on type of system
• Software-Driven vs. Embedded
• Activity vs. Phase
• Early methods equated activity to phase
• Later methods (including Objectivity) divorces
  activity from phase requirements and design
  activities occur in most phases.
• Requirements vs. Requirements Analysis vs.
  Analysis

18
S/W Development Lifecycle - Development
19
S/W Development Lifecycle - Development Details
20
S/W Development Lifecycle - Development Terms

• Problem Identification and Domain
  Analysis/Modeling
• Purpose is to understand the customers problem
  domain.
• Understanding should include both the current
  domain (if one exists) and the change that a new
  system will make to this domain.
• Documentation Requirements Definition Document
  (RDD) or SSRS

21
S/W Development Lifecycle - Development Terms

• Requirements Analysis
• Purpose Understand Requirements
• May include prototyping or trade-studies to
  insure that the end product meets real user
  needs.
• Requirement specification and analysis often
  combined into a single activity/phase.

22
S/W Development Lifecycle - Development Terms
(cont)

• System Architectural Design
• Purpose Establish high-level hardware and
  software design.
• Establish high-level software components
  (subsystems, packages, or objects) and their
  interfaces.
• Investigate critical design issues which may
  include prototype and feasibility studies.
• Different methods use this phase/activity
  differently - some focus on hardware/software
  architectures, others focus on environment-indepen
  dent software architectures and only introduce
  environment details later.
• Sometimes called analysis
• (not to be confused with requirements analysis)

23
S/W Development Lifecycle - Development Terms
(cont)

• Software Design
• Purpose Establish design details.
• Decompose high-level components into lower-level
  components.
• Refine interfaces, component behaviors, and
  internal component structures
• Implementation Unit Testing
• Purpose Implement design components and perform
  individual component testing.

24
S/W Development Lifecycle - Development Terms
(cont)

• Integration Informal Testing
• Purpose Integrated tested lower-level components
  into higher-level components, subsystems, and
  system.
• Perform informal testing on integrated
  components, subsystems, and system.
• Formal Testing VV
• Formal or Qualification Testing
• Verification and Validation of Product

25
S/W Development Lifecycle - Development Terms
(cont)

• Different Models/Methods Use Terms Differently!

26
Methods, Modeling, and Processes

• Intro to System/Software Methods, Modeling, and
  Processes
• Methods, Modeling, and Processes - General
  Modeling Types
• Methods, Modeling, and Processes - Methods
• Methods, Modeling, and Processes - Development
  Processes
• Methods, Modeling, and Processes - Maintenance
  Processes
• Methods, Modeling, and Processes - A Model View
  of Development
• Methods, Modeling, and Processes - Documentation

27
Intro to System/Software Methods, Modeling, and
Processes

• What is modeling?
• Way of describing something.
• Example Weather model
• What are methods?
• Collection of ordered activites to develop a set
  of models
• Example Activities involved in developing a
  weather model
• What is a Process?
• Combination of methods to achive goal
• Example Total collection of steps to provide
  weather forecasting
• These terms are not exact - different authors use
  different definitions
• Particularly for Processes vs. Methods

28
Methods, Modeling, and Processes - General
Modeling Types

• Functional Modeling
• Structured Analysis
• Data-Oriented Modeling
• ER Diagraming
• Object-Oriented Modeling
• Booch
• OMT/Rumbaugh
• UML

29
Methods, Modeling, and Processes - Methods

• Activity vs. Phases
• System vs. Software
• Requirements vs. Design
• Incremental vs. Waterfall
• Traditional Strong Divisions between System and
  Software and between requirements and design.

30
Methods, Modeling, and Processes - Development
Processes - Traditional Waterfall

• Waterfall
• Modified Waterfall (Waterfall With Feedback)

31
Methods, Modeling, and Processes - Development
Processes - ETVX

• ETVX Entry/Task/VV/Exit Model
• More of a Process Construction Approach than a
  complete process

32
Methods, Modeling, and Processes - Development
Processes - Spiral
33
Methods, Modeling, and Processes - Development
Processes - Incremental

• Software First
• Software Growing
• Objectory/Incremental

34
Methods, Modeling, and Processes - Maintenance
Processes

• Mini-Development
• Bug-Driven

35
Methods, Modeling, and Processes - A Model View
of Development

• S/W Development consisits of a series of
  Products Intermediate Product or Models
• For Example
• Requirements
• Design
• Code
• Tests
• Products or Models can be captured in
• Formal Documents (ala DoD Specs)
• Informal Models
• Configuration management must be applyied to all
  intermediate products

36
Methods, Modeling, and Processes - Documentation

• Documentation Captures Models
• Document Types
• Problem Identification
• Requirements Definition Document
• System Requirements Specification
• System Design Document
• Software Requirements Document
• Software Design Documents
• Architectural
• Top-Level
• Detailed

37
Software Requirements Overview

• System/Software Requirements Specification
  Analysis
• Requirements - Types
• Requirements - Specification Methods
• Requirements - Analysis and Verification Issues
• Requirements - Informal Specification Techniques
• Requirements - Other Rqmts Activities/Issues
• Requirements - Requirements vs... Design
• Requirements - Documentation

38
System/Software Requirements Specification
Analysis

• Requiments Activities
• Rqmts Elicitation
• Process whereby customers, users, developers
  discover, review, articulate, and understand
  users needs and the contraints on the software
  and development activitiyWho? - Customer,
  Marketing, S/W Development Team
• Rqmts Specification
• The development of a document that clearly and
  precisely records each of the requirements
• Rqmts Validation
• Process of analysing the requirements as
  specified to ensure that they meet user needs.
  Are we building the right system?
• Rqmts Verification
• Process of analysing the requirements as
  specified meet developer needs. This includes
  that they are in compliance with the system
  requirements, conforms to document standards of
  the rqmts phase, and is an adequate basis for the
  architectural (preliminary) design phase. (This
  sometimes is called analysis) Will the system be
  build right?

39
Requirements - Types

• Functional vs. Non-Functional
• External vs. Internal
• User Interface

40
Requirements - Specification Methods

• Purpose Interface between S/W Development and
  Others
• Contractual
• Narrative good structure and user manuals can
  be very effective
• Semi-formal techniques involving graphical or
  structured text
• Data flow diagrams, state-charts, object-oriented
  analysis, ER charts
• Formal methods
• Finite state, set theory, event algebras, logic

41
Requirements - Analysis and Verification Issues

• Completeness
• Consistancy
• Testability
• Traceability

42
Requirements - Informal Specification Techniques

• ER Diagrams
• Functional or Dataflow Diagrams
• State Diagrams
• Object Diagrams

43
Requirements - Other Rqmts Activities/Issues

• Trade-Studies
• Feasibility Studies
• Prototyping

44
Requirements - Requirements vs. Design

• Rqmts/Design depends on point of view
• Requirements focus on External Needs
• Design focus on Internal Structures
• Example External view of Automoble vs. Internal
• (note overlap)
• Requirements focus on what not how
• (This is not always possible)
• Should be a process for understanding the problem
• Architectural/System Design vs. Requirements -
• Depends on Point of View

45
Requirements - Documentation

• System/Software Requirements Specification (SSRS)

46
Objectory and UML

• Introduction to Objectory and UML
• Objectory and UML - This Class
• Objectory and UML - Generic Object-Oriented
  Concepts
• Objectory and UML - Universal Modeling Language
• Objectory and UML - Modified Objectory Process
• Objectory and UML - Models and Documentation
• Objectory and UML - Models and Documentation -
  Requirements Model
• Objectory and UML - Models and Documentation -
  Analysis Model
• Objectory and UML - Models and Documentation -
  Risk Model
• Objectory and UML - Models and Documentation -
  Design Model
• Objectory and UML - Models and Documentation -
  Implementation Model
• Objectory and UML - Models and Documentation -
  Test Model
• Objectory and UML - Diagram Perspectives

47
Introduction to Objectory and UML

• UML or Universal Modeling Language
• Evolved From Rumbaughs OMT, Boochs OO Method,
  and Jacobsons OOSE
• Objectory - A methods using UML
• Developed by Ivar Jacobson
• Refinement of Method Described in Object-Oriented
  Software Engineering

48
Objectory and UML - This Class

• We will use UML and a modified version of
  Objectory for Class
• Focus is on SSRS and SSDD

49
Objectory and UML - Generic Object-Oriented
Concepts

• What is an Object?
• Object Classification
• Active vs. Passive
• Physical vs. Conceptual
• Temporary vs. Permanent vs. Persistent
• Private vs. Public
• Shared vs. Non-Shared

50
Objectory and UML - Generic Object-Oriented
Concepts

• Object-Oriented Analysis
• Finding the Objects (Or Defining)
• Organizing the Objects
• Describing How the Object Interact
• Defining the Operations of the Objects
• Defining the Objects Internally

51
Objectory and UML - Diagram Perspectives

• Conceptual
• Domain Analysis
• Specification
• Software Analysis and Top-Level Design
• Implementation
• Software Detailed Design
• Diagrams as a Visual Code Description
• ?Least Useful Diagrams?

52
Objectory and UML - Universal Modeling Language

• Use Case Diagrams
• Class Diagrams
• Interaction Diagrams
• Sequence Diagrams
• Collaboration Diagrams

• Package Diagrams
• State Diagrams
• Activity Diagrams
• Deployment Diagrams

53
Objectory and UML - Modified Objectory Process
54
Objectory and UML - Models and Documentation

• Requirements Model - System/Software Requirements
  Specification (SSRS)
• Risk Model (Risk Management Plan)
• Design Model - System/Software Design Document
  (SSDD)
• Implementation Model - Code and Code
  Documentation
• Test Model - Test Documenation

55
Objectory and UML - Models and Documentation -
Requirements Model

• Problem Identification
• Pre-System Domain Model
• Post-System Domain Model
• Requirements List
• Use Cases
• Documented in the System/Software Requirements
  Spec (SSRS)

56
Objectory and UML - Models and Documentation -
Analysis Model

• Implementation-Independent System Architecture
  (Optional)
• Bridge Between Requirements and Design
• Documented in the System/Software Design Document
  (SSDD)

57
Objectory and UML - Models and Documentation -
Risk Model

• Risk Identification and Risk Management Plan
• Requirement Risks
• Technology Risks
• Skills Risks
• Political Risks
• Documented in the Risk Management Plan

58
Objectory and UML - Models and Documentation -
Design Model

• Implementation Dependent System Architecture
• Documented in the System/Software Design Document
  (SSDD)

59
Objectory and UML - Models and Documentation -
Implementation Model

• Code
• Code Description (aka Version Description)
• Compiler and Tools

60
Objectory and UML - Models and Documentation -
Test Model

• Test Plan
• Developed During Elaboration
• Updated During Analysis and Design
• Test Procedures
• Developed/Updated During Analysis and Design
• Test Cases
• Developed/Updated During Analysis and Design
• Test Results
• Generated During Testing

61
Software Design Overview

• Software design
• Design - Good Software Engineering Concepts
• Design - Architectures
• Design - Other Views
• Design - Documentation
• Design - Software Design Issues - Real
  Time/Safety Critical software
• Design - Software Design Issues - Real
  Time/Safety Critical software
• Design - Software Design Issues - Human Interface
  Issues

62
Software design

• Purpose
• Approaches
• System or Architectural Design
• Software/Component Design
• Detailed Design

63
Design - Good Software Engineering Concepts

• Modularity / Decomposition
• Basic Structure of Program
• Coupling
• Interaction between Two Modules
• Loosely vs. Tightly Coupled
• Information or Data Hiding
• Limiting Access to Internal Data Structure
  Details
• Stong Data Typing

64
Design - Architectures - Functional Abstraction

• Traditional Main Program and Subroutines
• Functional Abstration
• Batch Sequential
• Function/Data Approach Treats Functions and Data
  as Separate Elements
• Functions Are Active and Have Behavior
• Data is Passive
• System is Typically Broken Down as Functions with
  Data Passed Between

65
Design - Architectures - Data Abstraction/Object-
Oriented

• Current Best Practice or Design Method of the
  Month
• Major Problem
• In order to interact with another object, an
  object must know it exists
• Can be overcome by using event registration
• Why Object-Oriented over Functional? - Tendency
  for Change
• Object From Application - Low
• Long-Lived Information Structures - Low
• Passive Objects Attributes - Medium
• Sequences of Behavior - Medium
• Interfaces with the Outside World - High
• Functionality - High

66
Design - Architectures - Pipes and Filters
67
Design - Architectures - Layered Systems

• Example
• Communication Protocals

68
Design - Archtectures - Process Control
69
Design - Architectures - Repositories or Data
Pools
70
Design - Architectures - Distributed Systems

• Most Common is Client Server

71
Design - Other Views

• Architectural Design
• Structural View
• OOD vs. Functional
• Object diagrams
• Structured Design
• Dynamic View
• Purpose Identify major tasks/executables,
  databases, external interfaces. Often associated
  with hardware designs.
• System Design Diagrams
• Tasks
• Databases
• Interfaces
• Communication Devices
• Data/Data Repositories View
• ER Diagrams
• S/W Architectures

72
Design - Documentation

• System/Software Design Document (SSDD)

73
Design - Software Design Issues - Real
Time/Safety Critical software

• Why study real-time/safety critical software
  issues?
• Issues
• What is event driven?
• What is real-time?
• Safety Considerations
• Security Considerations
• Distribution/Communication Considerations
• State vs. Stateless
• Connection types

74
Design - Software Design Issues - Real
Time/Safety Critical software

• Typical real-time control concepts
• Concurency
• Event Driven
• Communications Issues
• Event Lag
• System Design Impacts
• System level assumptions
• individual hardware components
• communication structure
• data allocation
• processing elements

75
Design - Software Design Issues - Concurrency

• What is concurrency?
• Issues
• Language Support
• O/S Support
• Testing/Debugging Issues
• Concurrency Hiding within Objects
• Active vs Passive vs Evolving Objects

76
Design - Software Design Issues - Human Interface
Issues

• More than GUI
• Key Issues
• Who Drives the System?
• Who Adapts? The System or the User?
• Replacing Existing Process or Introducing New
  Process?

77
Testing Overview

• Integration, Testing, Verification, and
  Validation
• IT, VV - Testing Concepts
• IT, VV - Testing Process
• IT, VV - Testing Stages
• IT, VV - Verification and Validation

78
Integration, Testing, Verification, and Validation

• Purpose
• Integration
• Information Testing
• Formal Testing
• VV

79
IT, VV - Testing Concepts

• Black Box Testing
• White Box Testing
• Regression Testing

80
IT, VV - Testing Process

• Test Plan
• Test Cases
• Test Procedures
• Testing
• Test Reporting/Logging

81
IT, VV - Testing Stages

• Module Testing
• Object Integration Test
• System Integration
• Informal Testing
• Formal Testing
• Verification Validation
• Problem Reporting Tracking

82
IT, VV - Verfication and Validation

• VV - The process of determining whether the
  requirements for a system or component are
  complete and correct, the product of each
  development phase fullfill the requirements or
  conditions imposed by the previous phase, and the
  final system or complenent complies with
  specified requirements.
• Verification The process of determining whether
  or not the products of a given phase of the s/w
  development cycle fulfill the requirements
  established for them at the end of the previous
  phase - Answers the question Are we building
  the system right?
• Validation The determination of correctness of
  the final program or software produced from a
  development project with respect to the users
  needs and requirements Answers the question
  Are we building the right system?Done at all
  stages of development.

83
CS456 Seminar Productivity

• What is Software Productivity?
• How is it Measured?
• What Effects Software Productivity?

84
CS456 Seminar Quality

• What is Software Quality?
• How is it Measured?
• What Effects Software Quality?

85
CS456 Seminar Ethics

• What is Software Engineering Ethics?
• Should there be ethical standards?
• What should constitute ethical standards?

86
CS456 Seminar Safety Critical Software

• What is safety-critical software?
• Is it different than other software?
• What is the impact?
• Direct - failures of software
• Indirect - failures of interfaces
• User interface failures