CSDP Prep Notes

1
CSDP Prep Notes

• Software Engineering by Sommerville (recommended)
• Emphasis V V, Design

2
CSDP Notes

• IEEE/EIA Standard 12207-1996
• 12207.0-1996 Standard for Information
  Technology, Software Life Cycle Processes.
• Basic concepts, compliance, Life cycle process
  objectives, Life cycle data objectives,
  relationships, errata.
• IEEE/EIA Standard 12207.1-1997
• Provides additional guidance on recording life
  cycle data.
• IEEE/EIA Standard 12207.2-1997
• Additions, alternatives, and clarifications to
  life cycle processes as derived from U.S.
  practices.

3
Development Process

• Contains the activities tasks of the
  developer.
• Activities
• Process Implementation.
• System Requirements Analysis
• System Architectural Design
• Software requirements analysis
• Software architectural design
• Software detailed design
• Software coding testing
• Software integration
• Software qualification testing
• System integration
• System qualification testing
• Software installation
• Software acceptance support

4
Supporting Life Cycle Processes

• Documentation process
• Configuration management process
• Quality assurance process joint reviews,
  audits, verification, and validation.
• Verification
• Validation
• Audit
• Problem resolution

5
Organizational Life Cycle Processes

• Management
• Infrastructure
• Improvement
• Training
• First use of term Software Engineering -
  Professor Freidrich L. Bauer, 1967.
• Software Engineering is the establishment and use
  of sound engineering principles in order to
  obtain economically software that is reliable and
  works efficiently on real machines.

6
CASE Computer Aided Software Engineering

• Layers
• tools
• methods
• process
• a quality focus

7
Process Models

• 4 classes
• Linear, sequential analysis -gt design -gt code
  -gt test
• Prototyping listen to customer -gt build mock-up
  -gt customer test-drives mock-up (repeat)
• Evolutionary (spiral model) 6 task regions
  customer communication, planning, risk
  assessment, engineering, construction release,
  customer evaluation.
• Formal methods model formal mathematical
  specification of software (example, Cleanroom
  software engineering).
• 3.0 pg. 13
• 1.25 hr. 7/6/04

8
The Management Spectrum

• People
• SEI People Management Maturity Model
• Problem
• Joint Application Design (JAD)
• Project definition, research, preparation, the
  JAD meeting, document preparation.
• Process
• SEI CMM
• Initial
• Repeatable
• Defined
• Managed
• Optimizing

9
The Management Spectrum

• 18 Key Process Areas, defined by a set of key
  practices.
• goals
• commitments
• abilities
• activities
• methods for monitoring implementation
• methods for verifying implementation

10
Software Project Management

• measurement metrics
• project estimating
• effort estimation techniques
• size-oriented estimation
• empirical models
• risk analysis
• scheduling
• tracking control

11
Software Quality Management

• quality Conformance to explicitly stated
  functional and performance requirements,
  explicitly documented development standards, and
  implicit characteristics that are expected of all
  professionally developed software.
• Quality factors correctness, reliability,
  efficiency, integrity, usability,
  maintainability, flexibility, testability,
  portability, reusability, interoperatiliby
• Software configuration management the art of
  coordinating software development to minimize
  confusion

12
The technical spectrum

• Software engineering methods 4 major activities
• definition of the problem to be solved
• design of a solution that will meet the
  customers needs
• construction of the solution
• testing of the implemented solution to uncover
  latent errors and provide an indication that
  customer requirements have been achieved.

13
The technical spectrum

• approaches
• conventional software-engineering methods
• object-oriented approaches
• formal methods
• Problem definition either create a prototype or
  a detailed set of analysis models

14
The technical spectrum

• Analysis principles
• The data domain of the problem must be modeled.
• The functional domain of the problem must be
  modeled.
• The behavior of the system must be represented.
• Models of data, function, and behavior must be
  partitioned.
• The overriding trend in analysis is from essence
  toward implementation.

15
The technical spectrum

• Design principles
• Data and the algorithms that manipulate data
  should be created as a set of interrelated
  abstractions.
• The internal design detail of data structures and
  algorithms should be hidden from other software
  components that make use of the data structures
  and algorithms.
• Modules should exhibit independence.
• Algorithms should be designed using a constrained
  set of logical constructs.

16
The technical spectrum

• Design pyramid
• (top)
• procedural design
• interface design
• architectural design
• data design

17
Testing

• Test to discover errors
• Black box testing Knowing the specified
  function that a product has been designed to
  perform, tests can be conducted that demonstrate
  each function is fully operational.
• White box testing Knowing the internal workings
  of the product, tests can be conducted to ensure
  that all gears mesh that is, internal
  operation performs according to specification and
  all internal components have been adequately
  exercised.

18
major advances in computing

• The first major advance in computing was the
  introduction of higher level languages like
  FORTRAN and COBOL. Another advance was the
  software engineer who thinks in algorithms but
  expresses them in a higher-level language. Also
  invention of spreadsheet and word processor.
• Other major advances
• Implementation of time-sharing to improve
  productivity of programmers and the quality of
  their products.
• Unified programming environments.

19
Engineering and Society

• Approx. 75 of all software developers do not
  use formal process, productivity, or quality
  metrics.
• Code of conduct
• 8 areas Public, Client employer, Product,
  Judgement, Management, Profession, Colleagues,
  Self.

20
Cleanroom approach

• Cleanroom approach attempts to meld formal
  notations, correctness proofs and statistical
  quality control with an evolutionary approach to
  software development. Grow systems one function
  at a time certify the quality of each unit
  before integrating it into the architecture.
• Testing assign a probability to each possible
  path, design test cases so that
  higher-probability paths are tested more
  thoroughly. Then run through each test case and
  time how long it takes to fail. This model is
  used to calculate how reliable the program is.

21
The essence of a software entity

• The essence of a software entity is a construct
  of interlocking concepts data sets,
  relationships among data items, algorithms, and
  invocations of functions. The inherent
  properties of this essence are complexity,
  conformity, changeability, and invisibility.
• 3 important breakthroughs high-level languages,
  time-sharing, unified programming environments
  (UNIX, Interlisp).

22
Object-oriented concepts

• abstract data type (hiding) an objects type
  should be defined by a name, a set of proper
  values, and a set of proper operations rather
  than by its storage structure, which should be
  hidden examples Ada packages with private
  type, Modulas modules.
• hierarchical types allow one to define general
  interfaces that can be further refined by
  providing subordinate types examples
  Simula-67s classes.

23
Artificial intelligence

• 1) The use of computers to solve problems
  that previously could only be solved by applying
  human intelligence.
• 2) The use of a specific set of programming
  techniques known as heuristic or rule-based
  programming (expert system). In this approach
  human experts are studied to determine what
  heuristics or rules of thumb they use in solving
  problems the program is designed to solve a
  problem the way that humans seem to solve it.
• Software Engineering the application of a
  systematic, disciplined, quantitifiable approach
  to the development, operation, and maintenance of
  software (IEEE Standard 610.12).

24
Artificial intelligence

• www.sei.cmu.edu Report CMU/SEI-96-TR-004, 1996
  A Mature Profession of Software Engineering
• Software Engineering Coordinating Committee
  http//computer.org/tab/swecc.
• Software Engineering Body of knowledge
  http//www.swebok.org.
• Software engineering code of ethics
  http//computer.org/tab/swecc/code.htm.
• Association of Professional Engineers and
  Geoscientists of British Columbia, Software
  Engineering http//www.apeg.bc.ca/cse/cse.htm.
• Texas Board of Professional Engineers software
  engineering licensing page http//www.main.org/p
  eboard/sofupdt.htm.
• ACM http//www.acm.org/serving/se_policy.
• University of Texass professional-ethics site
  http//www.cs.texas.edu/users/ethics/professional
  .html.

25
standards sources

• International standards sources International
  Organization for Standardization, International
  Electrotechnical Commission, and the
  International Telecommunications Union.
• U.Sgt standards sources Electronic Industries
  Alliance (EIA), and IEEE Software Engineering
  Standards Committee (SESC) of the Computer
  Society.
• Vision 2000 integrating archecture of the SESC
  collection (see pg. 79, Fig. 1).

26
standards sources

• 3 organizing criteria
• Standards
• 1. Normative Levels Standards for resources
  (definitions, taxonomies, or other reference
  material that can be used in other standards
  IEEE std. 610.12
• 2. Documents that serve as an overall guide to
  the remainder of the collection.
• 3. Standards providing policies or principles to
  a user.
• 4. Conformance requirements documents (contains
  most of the SESC collections standards)
• 5. Application guides.
• 6. Toolbox of detailed techniques (subroutines)

27
standards sources

• Objects of Software Engineering Customer,
  Process, Product, Resources - these are also the
  4 volumes of the standards set.
• Relationships to other disciplines System
  disciplines, Software engineering, Quality
  management, Terminology
• http//www.pmi.org.publictn/pmboktoc.htm

28
standards sources

• Umbrella standard IEEE/EIA 12207
• 3 categories Primary processes business
  (acquisition and supply) and technical roles
  (development, operation, and maintenance.
• Supporting processes documentation,
  configuration management, quality assurance, v
  v, joint review, audit, problem resolution.
• Organizational processes management,
  infrastructure, improvement, training

29
standards sources

• 12207.0 adds a foreward and some annexes to
  the text of the international standard.
• 12207.1 guidance on the data produced by the
  life cycle processes cross-referenced to 12207.0
• 12207.2 guidance on implementing processes by
  quoting the complete text of 12207.0 and
  interspersing guidance notes.
• Available as 4-volume set http//standards.iee
  e.org/catelog

30
System and Software System Engineering

• 5 major system activities
• 1. Problem definition
• 2. solution analysis
• 3. process planning
• 4. process control
• 5. product evaluation
• System requirements analysis 12207.0-1996,
  paragraph 5.3.2.
• System architectural design paragraph 5.3.3.

31
System and Software System Engineering

• project stages
• system analysis, system design (system
  engineering)
• software requirements analysis, architectural sw
  design (sw system engineering)
• detailed sw design, code unit test, sw
  subsystem testing (sw engineering)
• sw integration testing, sw system testing (sw
  system engineering)
• system integration testing, system testing
  (system engineering)

32
System and Software System Engineering

• Software system engineering the application of
  the system engineering process to software
  development
• A system is a collection of elements related in a
  way that allows the accomplishment of a common
  objective.
• A software system is a man-made system consisting
  of a collection of programs and documents that
  work together, creating a set of requirements
  with the specified software.
• System Engineering the practical application of
  scientific, engineering, and management skills
  necessary to transform a users need into a
  system configuration description that most
  effectively and efficiently satisfies the need
  SE produces documents, not artifacts.

33
System and Software System Engineering

• Environment and processes IEEE Standard
  1220-1998.
• Software System Engineering Functions include
  problem definition, solution analysis, process
  planning, process control (methods for
  controlling the project and process), product
  evaluation.
• Project Management functions planning,
  organizing, staffing, directing, controlling.
• Software Engineering functions software
  design, coding, unit testing, software subsystem
  integration.

34
System and Software System Engineering

• Concept of operations (ConOps) document records
  the results of the concept analysis provides a
  bridge from user needs to the system and software
  development process. Concept of analysis process
  identifies the overall system characteristics
  from an operational (users) viewpoint. ConOps
  document contains scenario or use case.
• Verify compliance matrix A representation
  method for displaying which methods will be used
  to verify (test) each software requirement.
• Software Design the process of selecting and
  documenting the most effective and efficient
  system elements that together will implement the
  software system requirements.

35
System and Software System Engineering

• Architectural design (top level design or
  preliminary design) equiv. to system design.
  It can illustrate the final product to users and
  customers.
• Tools
• Functional flow block diagrams
• Structured charts (treelike representations of
  structure)
• dataflow diagrams
• object-oriented design and object diagrams
• use cases
• Planning specifying the goals and objectives of
  a project, and the strategies, policies, plans,
  and procedures for achieving them.

36
System and Software System Engineering

• Work Breakdown Structure (WBS) a method of
  representing, hierarchically, the parts of a
  process or product.
• Risk the chance of something undesirable
  occurring, such as a schedule overrun, project
  exceeding budget, or delivering an unsuitable
  product.
• Characterized by
• uncertainty (0 lt P lt 1)
• an associated loss
• the fact that it is at least partially unknown
• change over time.
• A PROBLEM is a risk that has materialized

37
System and Software System Engineering

• Software Quality Assurance (SQA) a planned and
  systematic pattern of all actions necessary to
  provide adequate confidence that the item or
  product conforms to established technical
  requirements.
• Software configuration management (SCM) a
  method of controlling and reporting software
  status. Identifies system configuration at
  discrete points in time.
• Verification am I building the product right?
• Validation am I building the right product?

38
System and Software System Engineering

• Systems Engineering A logical process of
  activities which transforms a set of requirements
  arising from a specific mission objective into a
  full description of a system which fulfills the
  objective in an optimum way. It ensures that all
  aspects of a project have been considered and
  integrated into a consistent whole.
• Assumptions behind systems engineering
• A product should be designed to fulfil the
  customers actual needs requires sufficient
  customer input.
• The system as a whole must be carefully planned
  out to minimize redesign.
• Specifications for the system as a whole, as well
  as for the details of individual components,
  should direct the design process

39
System and Software System Engineering

• Quality Functional Deployment (QFD) a technique
  for ranking product attributes in order of their
  importance to the customer through a series of
  matrices.
• Concept of Operations (ConOps)

40
System and Software System Engineering

• Concept Analysis the process of analyzing a
  problem domain and an operational environment for
  the purpose of specifying the characteristics of
  a proposed system from the users perspective.
  It emphasizes an integrated view of a system and
  its operational characteristics, rather than
  focusing on individual functions or pieces of a
  system. It should (ideally) be the first step in
  the development process. Prioritized user needs.
  Iterative process. Include representatives from
  the user, buyer, and developer organizations,
  plus other appropriate parties training and
  operational support.
• The document should say everything about the
  system that the users and buyer need to
  communicate to those who will develop the system.
  Should be repeatedly reviewed / revised until
  all involved parties agree on the resulting
  document (iterative process). It should be a
  living document that is updated and maintained
  throughout the entire life cycle (development
  process and operational life) of the software
  product.

41
Software Requirements Engineering (Section 4)

• Software requirement
• A software capability needed by a user to solve a
  problem or achieve an objective.
• A software capability that must be met or
  possessed by a system or system component to
  satisfy a contract, specification, standard, or
  other formally imposed document.

42
Software Requirements Engineering (Section 4)

• Five major activities
• Software requirements elicitation
• Software requirements analysis
• Software requirements specifications
• Software requirements verification
• Software requirements management

43
Software Requirements Engineering (Section 4)

• standards
• IEEE Standard 830-1998 Recommended Practice for
  Software Requirements Specifications.
• IEEE Standard 1233, Guide to Preparing System
  Requirements Specifications
• IEEE Standard 1362, Standard for Information
  Technology System Definition Concept of
  Operations Document
• Software Engineering project foundation
  documents
• A software requirements specification
• A project plan

44
Software Requirements Engineering (Section 4)

• Types of software requirements
• Functional
• Performance
• External interface
• Design constraints
• Quality attributes
• Four levels of testing unit, integration,
  system, and acceptance.
• Errors made first are discovered last.

45
Traceability

• Traceability should be both forward and backward
  to verify that the requirements of one phase
  translate to the outcome of that phase, which
  becomes the requirements of the next phase, etc.
• Traceability matrix Links requirements by
  number from System Requirements Document, System
  Specification, System Segment specifications, and
  Interface Control Document (provides linkages for
  all messages that occur within and across
  segments.

46
Ideal traceability process

• identification of requirements at the system
  level
• architecture selection
• classification schema
• allocations in accordance with the selected
  schema
• flow down to design, code, and test
• classification schemas functional aspects,
  performance and security, stakeholder
  organization, etc.

47
Steps to accomplish traceability

• receipt of requirements documents
• select architecture form to be followed
• select classification schema
• parse document and assign unique numbers
• allocate according to classification scheme
• establish linkages across all requirements
• generate traceability matrices
• maintain traceability linkages in database
• maintain traceability links across entire project

48
Requirements analysis

• iterations each include
• documenting the requirements a system must
  provide
• refining these requirements
• analysis for omissions, contradictions, and
  ambiguities
• review with consideration for a balance between
  customer concerns and desires, and profit and
  timeliness of a solution

49
Requirements analysis

• Requirements analysis often feeds the next
  iteration of requirements elicitation.
• 5 classes of scenario
• operational
• failure
• invalid input, software failure, interface
  failure
• performance
• refinement
• learning

50
Prototyping

• Prototyping is a model of the final system, where
  only parts of the system are developed, with a
  key emphasis on user interfaces. The emphasis is
  on user involvement in the software development
  process. It produces an information system
  faster than using the traditional life-cycle
  approach.
• 2 types Iterative prototype is progressively
  enhanced and becomes the final system.
  Throw-away a 4GL model is used to develop the
  final system in a 3GL.
• Downside of the throwaway approach the
  prototype may not be exactly like the final
  system

51
Prototyping

• 4 phases
• 1. Determination of key aspects of system to be
  prototyped (user interface, uncertain or vague
  system functions, time and memory requirements)
• 2. Building the prototype
• 3. Testing the prototype
• 4. Using the prototype as a model

52
Software design

• 2 phases
• Architectural (preliminary) design
• components, interfaces, database, user
  documentation (preliminary), test (preliminary),
  integration schedule
• Detailed (critical) design
• detailed versions of architectural design
  elements, update doc. and test plans

53
Design viewpoints

• Behavioral viewpoint, describing the causal links
  between external events and system activities
  during program execution state transition
  diagrams, statechart (system-wide model)
• Functional viewpoint, describing what the system
  does data-flow diagram, structure chart,
  structure diagram (Jackson), pseudocode
• Structural viewpoint, describing the
  interdependencies of the constructional
  components of the system, such as subprograms,
  modules, and packages structure chart
• Data modeling viewpoint, describing the
  relationships that exist between the data objects
  used in the system entity-relationship diagram

54
Design strategies

• 3 principal forms of description text,
  diagrams, and mathematical expressions.
• Design strategies
• top-down
• compositional identifying a set of entities,
  then assembling them
• organizational facilitates transfer of team
  members (ex. SSADM)
• template used for compiler design

55
Jackson Structured Programming

• Jackson Structured Programming method-based
  approach is an algorithm design method.
  Representation part uses Jackson Structure
  Diagrams. Process part
• Draw structure diagrams for inputs and outputs
  (elaboration)
• Merge these to create the program Structure
  Diagram (transformation)
• List the operations and allocate to program
  elements (elaboration)
• Convert program to text (elaboration)
• Add conditions (elaboration)

56
Software design

• Module A function or procedure OR an
  information hiding module that contains the
  hidden information as well as the access
  procedures to it. Modules have well-defined
  interfaces between them.
• Cohesion identifies the strength or unity
  within a module.
• Coupling a measure of the connectivity between
  modules.
• Structured Design want strong cohesion and low
  coupling. It is weak in task structuring and
  information hiding, so is considered inadequate
  for designing real-time systems.

57
Software design

• Design methods for concurrent real-time systems
  should have
• the capability of structuring a system into
  concurrent tasks
• the development of modifiable and potentially
  reusable software through the use of information
  hiding
• definition of the behavioral aspects of a
  real-time system using finite state machines
• the ability to analyze the performance of a
  design to determine that it will meet its
  performance requirements

58
Software design

• DARTS Design Approach for Real-Time Systems
  emphasizes the decomposition of a real-time
  system into concurrent tasks and defining the
  interfaces between these tasks.
• Jackson System Development the design should
  model reality first before considering the
  functions of the system.
• 3 phases modeling, network,implementation.

59
Software design

• ADARTS (Ada-based Design Approach for Real-Time
  Systems) and CODARTS (Concurrent Design Approach
  for Real-Time Systems), build on above methods by
  emphasizing both information hiding module
  structuring and task structuring.
• Develop Environmental and Behavioral Model of
  System.
• Structure the system into two distributed
  subsystems.
• Structure the system (or subsystem) into
  concurrent tasks.
• Structure the system into information hiding
  modules.
• Integrate the task and module views.
• Develop an Ada-based architectural design.
• Define component interface specifications for
  tasks and modules.
• Develop the software incrementally.

60
Patterns

• A pattern is the abstraction from a concrete form
  which keeps recurring in specific non-arbitrary
  contexts. Also (design) a solution to a
  recurring problem in a context.
• The form of a pattern consists of a finite number
  of visible and distinguishable components and
  their relationships. Pattern instances appear
  only in specific contexts which raise and
  constrain the forces that give birth to the
  concrete form. The form of a pattern is finite,
  but the form of its instances need not to be
  finite the context is potentially infinite.
• As a consequence, a pattern can only be
  understood and properly used with respect to the
  background of experience and reflection in the
  domain of its context. As another consequence,
  the form describing a pattern can be formalized,
  but not its context. A pattern should be
  presented in a way that it can be understood and
  properly used by others in their work and
  professional language.

61
Patterns

• A conceptual pattern is a pattern whose form is
  described by means of the terms and concepts from
  an application domain. Conceptual patterns should
  be based on metaphors rooted in the application
  domain. Conceptual patterns should be geared
  towards a restricted application domain.
• A design pattern is a pattern whose form is
  described by means of software design constructs,
  for example objects, classes, inheritance,
  aggregation and use-relationship. Design
  patterns should fit or complement the conceptual
  space opened by the conceptual patterns.
• A programming pattern is a pattern whose form is
  described by means of programming language
  constructs.

62
Patterns

• We order patterns as nodes of a directed
  graph. For textual presentation, we linearize
  the graph breadth first. Each pattern/context
  pair is preceded by all pattern/context pairs
  that are needed to understand it. Conceptual
  patterns logically precede design patterns which
  logically precede programming patterns.
• Contracts specifications of behavioral
  compositions

63
Architecture

• Sub-system operation does not depend on the
  services provided by other sub-systems composed
  of modules, has defined interfaces.
• Module a system component that provides one or
  more services to other modules not an
  independent system. Composed from a number of
  simpler system components.

64
Types of architectural models

• Static structural model, shows the sub-systems or
  components
• Dynamic process model, shows how the system is
  organized into processes
• Interface model, defines the services offered by
  each sub-system
• Relationship models, show relationships such as
  data flow between sub-systems

65
System Structuring

• The repository model
• All shared data is held in a central database
  that can be accessed by all sub-systems OR
• Each sub-system maintains its own database.
• Client-server model
• A set of stand-alone servers, which offer
  services to other sub-systems
• A set of clients that call on the services
  offered by servers
• A network which allows the clients to access
  these services

66
System Structuring

• Abstract machine model organizes a system into
  a series of layers, each of which provides a set
  of services each layer defines an abstract
  machine whose services are used to implement the
  next level of the abstract machine.

67
Control models

• Centralized control types
• The call-return model (top-down subroutine model)
• The manager model concurrent systems one
  system component is a manager and controls
  starting, stopping, and coordination of other
  system processes.
• Event-driven systems
• Broadcast models an event is broadcast to all
  sub-systems, which can handle and respond to it
• Interrupt-driven models used in real-time
  systems, have interrupt handler.

68
Control models

• Modular decomposition decompose sub-systems
  into modules.
• Object-oriented model system is decomposed into
  a set of communicating objects.
• Data-flow model System is decomposed into
  functional modules which accept input data and
  transform it to output data (pipeline or
  pipe-filter approach).
• Domain-specific architectures
• Generic models abstractions from a number of
  real systems.
• Reference models more abstract, describe a
  larger class of systems (e.g. OSI model).

69
Control models

• OMT Object Modeling Technique
• Architectural styles can be viewed as pattern
  languages, that provide architects with a
  vocabulary and framework from which they can
  build useful design patterns to solve specific
  problems.
• Software reliability engineering is the applied
  science of predicting, measuring, and managing
  the reliability of software-based systems to
  maximize customer satisfaction.
• Software failure some behavior of the executing
  program that does not meet the customers
  operational requirements.
• Software fault a defect in the code that may
  cause a failure.
• Software reliability the probability of
  failure-free operation for a specified time
  duration.

70
Control models

• Failure intensity the number of failures
  experienced per time period.
• Fault density faults per 1000 SLOC
• Operational profile the set of the functions
  the software can perform with their probabilities
  of occurrence.
• Validation the primary thrust is to certify
  that the product meets customer requirements and
  is suitable for customer use. Product validation
  for software generally includes system tests and
  field tests.
• The most important activity that you can
  conduct near the end of the life cycle is a
  root-cause analysis of faults.

71
Safety-critical software

• It is desirable to minimize the number of
  safety-critical components in a system, because
  these have more stringent requirements these
  often conflict with other concerns, such as
  performance or cost. Safety must be considered
  in terms of the entire system, not individual
  components.
• Reliability How well the system performs its
  function.
• Safety The system functions do not lead to an
  accident.
• Security depends on reliability, and safety
  depends on security.

72
Safety-critical software

• Software should not replace hardware hardware
  obeys certain physical laws that may make certain
  unsafe behaviors impossible, and hardware fails
  in more predictable ways than software and a
  failure may be foreseen by examining the
  hardware.
• Delphi technique send out questionnaires to all
  group members they express their opinions on the
  discussion topic. A coordinator reproduces the
  opinions such that the originators identity is
  hidden, and sends them back out. This is
  repeated until a consensus is reached.
• Joint Application Design a meeting is led by a
  neutral facilitator, who captures and displays
  the ideas presented.

73
Safety-critical software

• Hazard analysis purpose is to examine the
  system and determine which components may lead to
  a mishap. Two strategies
• Inductive event tree analysis, failure modes
  and effects analysis consider a particular fault
  in some component of the system and then attempt
  to reason what the consequences will be.
• Deductive fault tree analysis consider a
  system failure, then attempt to reason about the
  system or component states that contribute to it.

74
Safety-critical software

• Fault tree analysis Start with a particular
  undesirable event this becomes the top event in
  the diagram. Then graphically represent all the
  various combinations of events by which that
  event may occur.
• Event tree analysis (opposite direction of fault
  tree analysis) Starts with an initiating event
  and considers all the consequences, particularly
  those that lead to a mishap.
• Failure Mode and Effects Analysis Create a
  table with columns for component, failure mode,
  effect of failure, cause of failure, occurrence
  severity, probability of detection, risk priority
  number, and corrective action. 1 is least
  likely, 10 most likely. Risk priority number is
  the product of the other 3.

75
Computer-Human Interface design

• Design-implementation-evaluation cycle.
  Influences include experience with other systems,
  guidelines, and standards based upon human
  factors research, the results of evaluating
  previous versions, and requirements derived from
  task analysis.
• Three pillars of successful user interface
  development design guidelines, user interface
  rapid prototyping, and usability laboratories for
  iterative testing on a foundation of theories
  and experimental research.
• A key principle is the value of maintaining
  consistency in both the look and feel of the user
  interface.
• Usability tests with actual users, may be the
  only way to find many of the most severe design
  flaws.
• It is possible to develop usability metrics.

76
Safety-critical software

• IEEE Standard 1016-1998 Recommended
  Practice for Software Design Description
• Software Design Description (SDD) is a
  representation of a software system that is used
  as a medium for communicating software design
  information.
• The SDD is a required product defined in IEEE Std
  730-1998 it records the result of the design
  processes that are carried out during the design
  phase.

77
Safety-critical software

• The SDD shows how the software system will be
  structured to satisfy the requirements identified
  in the software requirements specification IEEE
  Std 830-1998. It is a translation of
  requirements into a description of the software
  structure, components, interfaces, and data
  necessary for the implementation phase. Each
  requirement must be traceable to one or more
  design entities. The SDD represents a
  partitioning of the system into design entities
  and describes the important properties and
  relationships among those entities. The
  properties and relationships of each design
  entity are described by a standard set of
  attributes.
• A design entity attribute is a named
  characteristic or property of a design entity it
  provides a statement of fact about the entity.

78
Safety-critical software

• Attributes include
• Identification The name of the entity.
• Type A description of the kind of entity.
• Purpose A description of why the entity exists.
• Function A statement of what the entity does.
• Subordinates The identification of all entities
  composing this entity.
• Dependencies A description of the relationships
  of this entity with other entities.
• Interface A description of how other entities
  interact with this entity.
• Resources A description of the elements used by
  the entity that are external to the design.
• Processing A description of the rules used by
  the entity to achieve its function.
• Data A description of data elements internal to
  the entity.

79
Safety-critical software

• A design view is a subset of design entity
  attribute information that is specifically suited
  to the needs of a software project activity.
  Views include
• Decomposition description records the division
  of the software system into design entities.
• Dependency description specifies the
  relationships among entities it identifies the
  dependent entities, describes their coupling, and
  identifies the required resources.
• Interface description provides everything
  designers, programmers, and testers need to know
  to correctly use the functions provided by an
  entity.
• Detailed design description contains the
  internal details of each design entity these
  include the attribute descriptions for
  identification, processing, and data.

80
Safety-critical software

• A use case is a complete sequence of steps that
  provides a result of value to an actor.
• An actor is the system user does not have to be
  human.
• A system is the thing under development could be
  software or a business process.
• Object-oriented model systems are viewed as
  cooperative objects that encapsulate structure
  and behavior.

81
Writing use cases

• Determine your audience managers, users,
  or developers. Use a separate document for each
  one.
• Each use case must include details outlining
  what must be done to accomplish functionality.
  Use cases include the following
• Flow of events
• The basic path no errors, every use case has
  one.
• Alternative paths alternatives and error
  conditions. May be documented in the basic path
  for simpler use cases, or separately for more
  complex ones. Alternatives may just list single
  events (ex. wrong password entered in step n).
• Pre-and-post conditions the postcondition must
  be true regardless of which branch was followed.
  may contain compound conditions.
• Who initiates the use case (usually an actor or
  the system).
• Non-functional requirements timing,
  sizing, performance, security, etc.

82
Object-Oriented Development

• Objects are more stable than functions they
  support information hiding, data abstraction, and
  encapsulation. It extends the lifecycle due to a
  more consistent approach, and spawns prototypes
  that support rapid application development. It
  supports concurrency, hierarchy, and complexity.
• All functionality is achieved by messages that
  are passed to and from objects.
• In object-oriented programming, programs are
  organized as cooperating collections of objects,
  each of which is an instance of some class and
  whose classes are all members of a hierarchy of
  classes united via inheritance relations.
• Characteristics of object-oriented languages
  object creation facility, message-passing
  capability, class capability, and inheritance.

83
Safety-critical software

• Multiple inheritance a class inherits from more
  than one superclass.
• Polymorphism Results from dynamic binding a
  given message sent to an object will be
  interpreted differently at execution based upon
  subclass determination.
• Abstract classes dont have an instance, are
  just used to create subclasses.
• Four branches of object-oriented languages (all
  descended from Simula) Smalltalk-based,
  C-based, LISP-based, and Pascal-based.
• Object-based languages dont have inheritance
  capability.

84
Safety-critical software

• Waterfall life cycle Analysis, Specification,
  Design, Implementation, Testing, System
  Integration, Maintenance
• Water fountain life cycle (stages overlap and
  blend in to each other) Analysis, Design, Code,
  Test, Integrate, followed by evolution and back
  to previous stages.
• Iterative/Incremental life cycle Macro stages
  of Analysis, Design, Implementation the micro
  stages are the iteration.
• Scenario a sequence of actions that take place
  in the problem domain.

85
Object-Oriented Development

• A framework is a skeleton of an application or
  application subsystem implemented by concrete and
  abstract classes it is a specialization
  hierarchy with abstract superclasses that depicts
  a given problem domain.
• Object-oriented design encompasses the process
  depicting both logical and physical, static and
  dynamic models of the system under design.

86
Object-oriented systems development

• Objects are an abstraction of parts of real-word
  systems and model composite units of structures
  and activity.
• Encapsulation the concept that objects should
  hide their internal contents from other system
  components to improve maintainability.
• Objects should have generic properties, i.e.
  support reusability by property inheritance from
  superclass to subclass.
• Polymorphism results from multiple inheritance
  one component has different properties in several
  new locations, as it is specialized in child
  objects.
• Objects may be data-oriented or task-oriented.
  Booch classifies objects as actors, agents, or
  servers.
• Functional cohesion groups actions pertaining
  to a single goal in processing units.
• Coupling aims for low interdependence among
  system components.

87
Structured Systems Analysis and Design Method
(SSADM)

• Basic principles
• Data-driven the application systems
  underlying, generic data structure is central in
  development.
• Separates logical design from physical design.
• Three system views
• underlying structure of the systems data (the
  logical data structure)
• how data flows into and out of the system and is
  transformed within the system (data flow diagram)
• how the system data is changed by events over
  time (entity life histories)

88
Structured Systems Analysis and Design Method
(SSADM)

• Contains elements of both top-down (in early
  stages) and bottom-up (in logical design stage)
  approaches.
• Ensures that the specification and design match
  the users requirements at each stage.
• Use of informal quality-assurance reviews and
  walkthroughs is encouraged throughout the method.
• The products of each SSADM step form the project
  documentation and are used in subsequent steps.

89
Structured Systems Analysis and Design Method
(SSADM)

• Stages include
• Analysis system operation and current problems
  current system, new requirements.
• Specification of requirements start with
  existing system, add Business System Options
• Selection of technical options.
• Logical Data Design
• Physical Process Design
• Physical Design detailed program
  specifications, documentation.
• Entity Life History model of how the systems
  data is changed over time by events acting on
  entities.
• Relational Data Analysis normalization.

90
Formal Methods

• Formal methods involve the essential use of a
  formal language. Formal methods in software
  support formal reasoning about formulae in the
  language.
• A formal method in software development is a
  method that provides a formal language for
  describing a software artifact (for instance,
  specifications, designs, or source code) SUCH
  THAT FORMAL PROOFS ARE POSSIBLE, IN PRINCIPLE,
  ABOUT PROPERTIES OF THE ARTIFACT SO EXPRESSED.
• Formal methods are used in rapid prototyping, the
  Cleanroom variant on the spiral model, and
  transformational paradigms.

91
Formal Methods

• Formal methods which have a specification
  language for recording a systems functionality
• Z (pronounced Zed)
• Communicating Sequential Processes (CSP)
• Vienna Development Method (VDM)
• Larch
• Formal Development Methodology (FDM)

92
Formal Methods

• Usable formal methods provide a variety of
  techniques for reasoning about specifications and
  drawing implications.
• Limitations You cant go from the informal to
  the formal by formal means F.M.s can be used
  to verify, but not to validate.
• F.M.s can verify that an implementation
  satisfies a specification when run on an
  idealized abstract machine, but not when run on
  any physical machine.
• Distinction A specification method states what
  a specification just say a language determines
  in detail how the concepts in a specification can
  be expressed.

93
Formal Methods

• 3 major classes of semantic domains
• Abstract Data Type specification languages
• Process specification languages
• Programming languages
• Cleanroom methodology Combines formal methods
  and structured programming with Statistical
  Process Control, the spiral lifecycle and
  incremental releases, inspections, and software
  reliability modeling.

94
Re-engineering and reuse of software

• Reuse can include program components,
  redeployment of designs and ideas, or the skills
  and experience of people.
• Re-engineering improve on a complete system and
  then redeploy it.
• Domain analysis the activity of understanding
  an application area. Domain models range from
  application-specific to generic.
• Reverse engineering recognizing higher-level
  domain concepts One method is matching patterns
  (schemas, templates, clichés, or plans) against
  the code.

95
Re-engineering and reuse of software

• Another approach is the recognition of
  objects in the sense of object-oriented
  programming.
• The central ingredient for reuse is the
  component. These have interfaces (plugs and
  sockets).
• White-box reuse modifying source code to adapt
  it used as a last resort, because it may
  compromise quality.
• Framework a collection of interconnect objects
  (abstract classes) which defines the overall
  architecture of the system.
• Basilis approach full reuse of requirements,
  design, and code characterizes reuse objects by
  descriptors consists of transforming existing
  reuse candidates into required objects.
  Activities identification, evaluation,
  modification, integration.

96
Standards

• 12207.0-1996, Coding and Unit Testing
• The developer develops and documents the
  following
• Each software unit and database
• Test procedures and data for testing each
  software unit and database
• The developer tests each software unit and
  database, ensuring that it satisfies its
  requirements. The tests results are documented.
• The developer updates the user documentation as
  necessary.
• The developer updates the test requirements and
  the schedule for software integration.
• The developer evaluates software code and test
  results in consideration of the criteria listed
  below

97
Standards

• The results of the evaluations are documented as
• Traceability to the requirements and design of
  the software item
• External consistency with the requirements and
  design of the software item
• Internal consistency between unit requirements
• Test coverage of units
• Appropriateness of coding methods and standards
  used
• Feasibility of software integration and testing
• Feasibility of operation and maintenance

98
Standards

• Implementation the activities of design, code,
  unit test and integration.
• Construction excludes the architectural level
  of design.
• Types of software products / environments
• Classical information systems
• Embedded systems
• Desktop and local network applications
• Internet and wireless applications

99
Standards

• Selecting a language and toolset Factors
  include those that are intrinsic to the language,
  and those that are artifacts of a particular
  implementation of the tool set. Factors impacted
  by both include
• The available development and execution
  environments.
• Memory utilization.

100
Standards

• Next the development team is brought
  together and evaluates the requirements and the
  architectural description this way they can
  become familiar with the intent (requirements) of
  the product and the architecture into which their
  individual components will fit.
• Individual requirements should be
• necessary
• unambiguous
• testable
• traceable
• measurable

101
Standards

• Taken together, the requirements should be
• ranked for importance (to the customer)
• ranked for stability (or the likelihood of change
• modifiable (that is, the amount of change induced
  into one requirement by changing another)
• complete
• consistent

102
Standards

• Individually and collectively, requirements
  should have completeness, consistency, and
  conciseness.
• After the construction team gains an
  understanding of the requirements, they need to
  evaluate the architecture.
• IEEE Standard 1471-2000 IEEE Recommended
  Practice for Architectural Description of
  Software-Intensive Systems defines the
  architecture of a software system as
• The fundamental organization of a system embodied
  in its components, their relationships to each
  other and to the environment,, and the principles
  guiding its design and evolution.

103
Standards

• Uses of an architectural description include
• input to subsequent system design and development
  activities
• input to system generation and analysis tools

104
Standards

• Cohesion how closely related two things are
  they must both come from within a single item
  (package, data type, individual component,
  class).
• Coupling measures how two items depend on each
  other.

105
Detailed construction planning

• The plan for the construction effort is based
  on
• The requirements that the product must satisfy
  documented in designs, requirements
• Other requirements that the project must satisfy
  in the contract or SOW, etc.
• The approach to integration and deployment
• The available staff, methods, and productivity

106
Detailed construction planning

• The detailed construction plan should contain
• A detailed schedule
• A description of the methods and procedures that
  will be used to perform the technical work
• A staffing and labor expenditure plan
• A listing of what resources are required and
  when.

107
Detailed construction planning

• Estimating effort and duration
• Look at historical cost and schedule data
  (project history database) for similar projects.
• Use parametric models, which predict cost and
  schedule based on some parameter, such as lines
  of code
• Rules of thumb, which are based on informal,
  undocumented actuals

108
Detailed component design (internal design)

• Name the components name should reflect if a
  component is a function (returns a value) or a
  procedure. Should be descriptive, reasonably
  short but not cryptic.
• Design the data Algorithms data structures
  programs. Use information hiding (localizing the
  data to only those design structures that need
  access to it) and abstraction (use the language
  semantics (fields of records or structures) to
  express and access data in a natural manner,
  instead of forcing the developers to know all the
  details of how the data is stored).

109
Detailed component design (internal design)

• Specify the procedural interface Coupling
  (interfaces) between components inputs, outputs,
  global variables referenced, external I/O and
  communications.
• Design the internals often with Program Design
  Language (PDL) abbreviated English, communicate
  unambiguously what the code is to do.
• Document the routines design.
• Review the design.
• Code and unit test.
• Flow of control Can be sequential, conditional,
  or looping.
• Any problem that can be solved by recursion can
  be solved by iteration.

110
Detailed component design (internal design)

• Design the unit test cases tests an individual
  unit (component) of code. There should be one
  test case for each function the code performs,
  and one for each branch of a simple if or case
  statement, and separate test cases to exercise
  the individual conditions of a compound if
  condition (if A and B, etc.).
• Additionally, test cases should be designed
  that place the data used by the component into
  the states it can assume. These include
• Defined the item was written to but has not yet
  been read this is sometimes known as setting the
  variable.
• Used the item has been read
• Killed the item was written to (defined) but
  the value is now undefined.

111
Review the code and test cases

• Integration 3 approaches
• Top down the top-level components are completed
  first and tested using stub routines to simulate
  the lower-level routines they will invoke.
• Bottom up the bottom-level components are
  completed first and tested using drivers to
  simulate the higher-level routines that invoke
  them.
• Flow a flow or thread of execution is traced
  through the system and the components needed to
  be completed first. The actual thread could be
  integrated using a top-down or bottom-up
  approach.
• Tuning for performance (performance
  optimization) Memory, time, accuracy.

112
Structured programming

• Dijkstra restricts program control logic to
  sequence, selection, and iteration.
• Early use IBM New York Times project used
  chief-programmer team organization, top-down
  development by stepwise refinement, hierarchical
  modularity, and functional verification of
  programs.
• The lines of a structured program can be written
  chronologically so that every line can be
  verified by reference only to lines that have
  already been written. A structured program
  defines a natural hierarchy among its
  instructions, which are repeatedly nested into
  larger and larger parts of the program by
  sequence, selection, and iteration structures.

113
Structured programming

• Since programs define mathematical functions,
  which thereby abstract out all details of
  execution, it is possible to discuss the
  correctness of a program with respect to its
  specification as a purely mathematical question.
• Axiomatic verification (theoretical) proves
  correctness by reasoning about the effect of
  programs on data.
• Functional verification (used in industry) is
  based on function theory.
• Use queues and stacks instead of arrays.
• Cleanroom development the combined discipline
  of no unit debugging and statistical testing.

114
Programming Languages

• High-level COBOL, FORTRAN, ADA
• Low-level assembler
• Systems Implementation Language or high-level
  assembler C.
• Language syntax should be consistent, natural,
  and promote the readability of programs.
• A language for software engineering must provide
  a small but powerful set of control structures to
  describe the flow of execution within a program
  unit. These should consist of
• Sequence to group together a related set of
  program statements.
• Selection to select whether a group of
  statements should be evaluated or not based on
  the value of some condition.
• Repetition to repeatedly execute a group of
  statements.

115
Programming Languages

• A language is said to be STRONGLY TYPED if it can
  be determined at compile-time whether or not each
  operation performed on an object is consistent
  with the type of that object.
• Static Typing the type of a variable is fixed.
• Dynamic Typing the type of a variable can be
  changed at run-time.
• Variant records or Discriminated unions use a
  tag to determine structure of the record.
• Procedural abstraction procedures and functions
  abstract WHAT should be done before specifying
  HOW it should be done.

116
Testing and Integration

• Standard 12207.0-1996. Covers
• Software integration
• Software qualification testing