CSDP Prep Notes - PowerPoint PPT Presentation

1 / 320
About This Presentation

CSDP Prep Notes


Software Requirements Engineering (Section 4) Software requirement: ... IEEE Standard 1233, Guide to Preparing System Requirements Specifications ... – PowerPoint PPT presentation

Number of Views:608
Avg rating:3.0/5.0
Slides: 321
Provided by: zifi
Tags: csdp | notes | prep


Transcript and Presenter's Notes

Title: CSDP Prep Notes

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

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.

Development Process
  • Contains the activities tasks of the
  • 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

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

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.

CASE Computer Aided Software Engineering
  • Layers
  • tools
  • methods
  • process
  • a quality focus

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

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

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

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

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

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.

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

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

The technical spectrum
  • Design principles
  • Data and the algorithms that manipulate data
    should be created as a set of interrelated
  • 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.

The technical spectrum
  • Design pyramid
  • (top)
  • procedural design
  • interface design
  • architectural design
  • data design

  • 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

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.

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

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.

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

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.

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

Artificial intelligence
  • www.sei.cmu.edu Report CMU/SEI-96-TR-004, 1996
    A Mature Profession of Software Engineering
  • Software Engineering Coordinating Committee
  • Software Engineering Body of knowledge
  • Software engineering code of ethics
  • 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
  • ACM http//www.acm.org/serving/se_policy.
  • University of Texass professional-ethics site

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
  • Vision 2000 integrating archecture of the SESC
    collection (see pg. 79, Fig. 1).

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)

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

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

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

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.

System and Software System Engineering
  • project stages
  • system analysis, system design (system
  • 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)

System and Software System Engineering
  • Software system engineering the application of
    the system engineering process to software
  • A system is a collection of elements related in a
    way that allows the accomplishment of a common
  • 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.

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

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.

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
  • Tools
  • Functional flow block diagrams
  • Structured charts (treelike representations of
  • 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.

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

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

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

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
  • Concept of Operations (ConOps)

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

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.

Software Requirements Engineering (Section 4)
  • Five major activities
  • Software requirements elicitation
  • Software requirements analysis
  • Software requirements specifications
  • Software requirements verification
  • Software requirements management

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
  • A software requirements specification
  • A project plan

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.

  • 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

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

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

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

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

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

  • 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

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

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

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

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

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

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

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.

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
  • Structure the system into two distributed
  • Structure the system (or subsystem) into
    concurrent tasks.
  • Structure the system into information hiding
  • Integrate the task and module views.
  • Develop an Ada-based architectural design.
  • Define component interface specifications for
    tasks and modules.
  • Develop the software incrementally.

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

  • 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

  • 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

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

Types of architectural models
  • Static structural model, shows the sub-systems or
  • 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

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

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.

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.

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

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

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.

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
  • Reliability How well the system performs its
  • Safety The system functions do not lead to an
  • Security depends on reliability, and safety
    depends on security.

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

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.

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.

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
  • Usability tests with actual users, may be the
    only way to find many of the most severe design
  • It is possible to develop usability metrics.

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

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
  • A design entity attribute is a named
    characteristic or property of a design entity it
    provides a statement of fact about the entity.

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.

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
  • Detailed design description contains the
    internal details of each design entity these
    include the attribute descriptions for
    identification, processing, and data.

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

Writing use cases
  • Determine your audience managers, users,
    or developers. Use a separate document for each
  • 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
  • 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.

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.

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

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.

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.

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 may be data-oriented or task-oriented.
    Booch classifies objects as actors, agents, or
  • Functional cohesion groups actions pertaining
    to a single goal in processing units.
  • Coupling aims for low interdependence among
    system components.

Structured Systems Analysis and Design Method
  • Basic principles
  • Data-driven the application systems
    underlying, generic data structure is central in
  • 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)

Structured Systems Analysis and Design Method
  • Contains elements of both top-down (in early
    stages) and bottom-up (in logical design stage)
  • 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.

Structured Systems Analysis and Design Method
  • 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
  • Relational Data Analysis normalization.

Formal Methods
  • Formal methods involve the essential use of a
    formal language. Formal methods in software
    support formal reasoning about formulae in the
  • 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
  • Formal methods are used in rapid prototyping, the
    Cleanroom variant on the spiral model, and
    transformational paradigms.

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)

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.

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.

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.

Re-engineering and reuse of software
  • Another approach is the recognition of
    objects in the sense of object-oriented
  • The central ingredient for reuse is the
    component. These have interfaces (plugs and
  • 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.

  • 12207.0-1996, Coding and Unit Testing
  • The developer develops and documents the
  • 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
  • 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

  • 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
  • Feasibility of software integration and testing
  • Feasibility of operation and maintenance

  • 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

  • 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
  • Memory utilization.

  • 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

  • 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

  • Individually and collectively, requirements
    should have completeness, consistency, and
  • 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.

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

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

Detailed construction planning
  • The plan for the construction effort is based
  • 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

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

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

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

Detailed component design (internal design)
  • Specify the procedural interface Coupling
    (interfaces) between components inputs, outputs,
    global variables referenced, external I/O and
  • 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.

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
  • Used the item has been read
  • Killed the item was written to (defined) but
    the value is now undefined.

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
  • 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
  • Tuning for performance (performance
    optimization) Memory, time, accuracy.

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

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.

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

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.

Testing and Integration
  • Standard 12207.0-1996. Covers
  • Software integration
  • Software qualification testing
Write a Comment
User Comments (0)
About PowerShow.com