关于软件工程:软件工程期末总结

Software Engineering

Chapter1:intro

• software=computer programs + associated documentation

• software we need methods to develope high-qualified software:

  • standard
  • systematic
  • efficient
  • dependable
  • easy-to-use
• software engineering is an discipline that is concerned with all aspects of software production from initial conception to operation and maintenance.
• History of software engineering:

• SE’s composition:

  • software development(needs methods, techniques and tools to support)

    • requirements engineering
    • software design
    • coding
    • testing
    • maintenance
  • project management
• structured and object-oriented

• software engineering ethics

  • confidentiality
  • competence
  • intellectual property rights
  • computer misuse

Chapter2:software process model

Organization of processes and activities

Key points in this chapter:

1. What is software process?
2. What is software process model?
3. What are the software process models and what’s their advantages and disadvantages and implementation area?
4. Difference between plan-driven and agile?
5. What is agile method?
6. What are the steps of software process?

• Software process

  fundamental activities (all processes involve the following steps)

  • Specification:what the system should do
  • Design and implementation:the organization of system
  • Validation:checking if it does what the customer wants
  • Evolution:changing in response to customer need

• Process descriptions

  • Products
  • Roles
  • Pre- and Post- conditions
• software process:a sequence of activities leading to the production of a software product.
• software process model/aka product life cycle : abstract representation of software process.

• process description of software process model

  • products
  • roles
  • Pre and post conditions

• software process model(des and where)

  • Plan-driven processes:Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.
  • Agile processes:In agile processes, planning is incremental and it is easier to change the plan and the software to reflect changing customer requirements.

• Kinds of software process models:

  • Waterfall model:Plan-dirven strict order

    • requirements definition
    • system and software design
    • implementation and unit testing
    • integration and system testing
    • operation and maintenance

    Advantages:

    • ​

    Disadvantages: difficult to deal with changing requirements

    Application domain:

    • Large system
    • requirements that are well-understood and unlikely to change radically

  • Incremental model

    interleaving activities

    Advantages:

    • dealing with change
    • repid delivery
    • effective feedbacks

    Disadvantages:

    • invisible processes
    • degrading system structure

    application condition:

    • limited time and budget
    • changing requirements

    Incremental model:

    • Extreme programming
    • Scrum
    • Crystal
    • Adaptive software development
    • DSDM
    • Feature driven development

    Scaling agile mothods：

    • Scaling up
    • Scaling out(pipeline)

  • Reuse-oriented model

    conponent search and configuration

    Key points of re-use oriented model:

    • Component selection
    • Component filtering
    • Component-dependent requirements development

    Advantages:

    • Reduce cost and risk
    • faster delivery

    Disadvantages:(用的是他人的 component 那必定会有一些毛病)

    • inevitable requirements compromises
    • different from real needs
    • components out of control
  • Agile methods

    Agile 不是一个 software process model

Chapter 3:requirements engineering

requirements engineering 是为了失去好的 requirement

what should the system do?

key points in this capter:

Requirement

• Functional requirement
• Non-functional requirement

What is not in requirements:

• design or implementation details
• project planning information
• testing information

Requirements Engineering Composition

• Requirements Elicitation(找到有哪些 requirements)

  Process of identifying the needs and constraint of stakeholdes for a software system.

  Requirements elicitation is a complex process that consists of gathering, researching, defining, structuring, and clarifying a product’s requirements. As a result of elicitation, a BA creates a set of project objectives.

• Requirements Analysis（剖析找到的需要）

  • Use analysis model as graphical representation
• Requirements Specification

  The product’s detailed functional and non-functional requirements reside in a software requirements specification.(SRS)

• Requirements Validation

Feasibility study

• Purpose
• Mission

Requirements Analysis Models

• State-Transition Diagram (STD)

  Describes how the system transferred among different states.

  Usage:

  • Useful for specification review or test case generation
  • Not suitable for data-intensive systems

• Data Flow Diagram (DFD)

  How data flows among different system modules.

  Process: must get inputs and then produce outputs (immediately)(compare with CDFD)

  DFD 可能会有很多层级 Hierachy:interface of high level should be consistent with the low one

  Usage of DFD:

  • Useful for transaction-intensive systems.
  • Lack of explicit data relationships.
  • Cannot demonstrate temporal features.
  • Not appropriate for control systems.
• Entity-Relationship Diagram (ERD)

  Commonly used data model.

• Dialog Map
• Decision Table
• Decision Tree
• Use Case Diagram
• Class Diagram
• Activity Diagram

Requirements Specification

• The product’s detailed functional and nonfunctional requirements reside in a software requirements specification (SRS).

• Who need SRS:

  • User
  • Customer
  • Project manager
  • Analyst
  • Developer
  • Tester

• Attributes of good SRS

  • Well-structured
  • Abstract
  • Complete
  • Easy to understand
  • Unambiguous
  • Verifiable

Requirements Specification

• Natural language
• Graphical models

• Formal specification

  • Data definition in formal specification

    1. Primitive data elements(No further decomposition is possible or necessary)
    2. Composition(Multiple data items)
    3. Iteration(Multiple instances of one item)
    4. Selection(Limited number of discrete values)

  • Formal specification(methods?)

    1. B,Z,VDM
    2. SOFL(Structured Object-oriented Formal Language)

Requirements Validation

Does the specification satisfy user’s requirement?

3 main parts: prototype,review and testing

• Software prototype

  • Pros of software prototype:

    1. Making it alive.
    2. Easy to be understood by non-experts.
    3. Fast.
    4. Closes gaps in customer’s understanding of the requirements.
    5. Stimulates customer’s thinking.
    6. Early feedbacks.
    7. Deals with variability.

  • Types of software prototype:

    1. 依据 description 分类：

       • Horizontal

         Does Not dive into all the layers or into system details

         Demonstrate how the user interacts with the target system

       • Vertical

         Touches on all levels of the system implementation

         Looks like a subsystem of the target software

    2. 依据 purpose 分类：

       • Throwaway

         For answering questions and resolving uncertainties

         Discard or being integrated into the final system

       • Evolutionary

         A solid architectural foundation

         Must be built with robust, production quality code

         Takes longer time

  • Building tools of software prototype

    1. Paper:Cheap,Fast,Anytime,Hardly any interaction,Throw away
    2. Software:Tool selection,Interactive behaviors,Maybe used as part of the real system
  • Animation:Evolutionary prototype

• Software review(another kind of documentation)

  • peer deskcheck: ask one colleague to look over my work.
  • passround:invite several colleagues to examine a deliverable concurrently.
  • walkthrough:author describes a deliverable and solicits comments.

    The 3 types(peer,passround and walkthrough) lack engineering guidelines and controllable processes

  • inspection

    Best-estabilished type of formal peer review.

    Inspection Roles:

    • Author
    • Moderator
    • Reader
    • Recorder

  • defect checklist(在 review 里还是独自的一个局部？)

    • Organization and Completeness
    • Correctness
    • Quality attributes
    • Special Issues

  • challenges in review

    • Large requirements documents
    • Large inspection teams
    • Geographical separation of inspectors

• Testing(validation of software)

  • For detecting missing, erroneous, or unnecessary requirements
  • Generate test cases
  • Walkthrough the specification with the test cases
  • Result analysis

Chapter 4:software design

requirements specification: what

design specification:how

software design definition:

A description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used.

Software design：

• Architectural design: Design Patterns and Priciples
• Detailed Design:Strategy, Methods and Tools

Architectural design

Designing the overall structure of the system.

A model that describes how the system is organized as a set of communicating components

• Design Patterns

  Each pattern provides a solution for a kind of design problems under certain conditions

  Knowledge reuse o Written in natural language

  • MVC pattern

• Application architectures

  • Design principles

    • Abstraction
    • Refinement
    • Information hide
    • Modulization
    • Module independence

    • Cohesion:operation in one module(deep degree)

      • Coincidental Cohesion
      • Logical Cohesion
      • Temporal Cohesion
      • Procedural Cohesion
      • Communicational Cohesion
      • Functional Cohesion
      • Informational Cohesion

    • Coupling:different modules(light degree)

      • Content Coupling
      • Common Coupling
      • Control Coupling
      • Stamp Coupling
      • Data Coupling
    • Good design has high cohesion and low coupling.

• Tools for architectural design

  • Hierarchy chart
  • HIPO(Hierachy plus Input-Process-Output)

Detailed design

• Flowchart
• Problem Analysis Diagram(PAD)

Chapter 5:software testing

Software testing definition

A set of activities for identifying failures in a software or system to obtain user satisfaction.

Definitions

1. Test case：A set of input values + execution pre-conditions + expected output + execution post-conditions
2. Test case instantiation：(ppt 是不是错了？)

3. Test oracle：

   • Mechanism
   • Matamorphic

Testing levels

• Unit/Component testing

  Features:

  • Testing on components
  • Applicable to a piece of independent program
  • Usually with source code
  • Identified defects are directly fixed
  • Discovering errors at an early stage
  • Diver:
  • Stub:

• Integration testing

  • Big Bang integration
  • Top-Down integration
  • Bottom-up integration
  • Sandwich integration

• Acceptance testing:Obtain customer or user acceptance of the software

  • User acceptance
  • Operational acceptance
  • Contractual acceptance
  • Regulatory acceptance
  • Alpha test
  • Beta test
• Test Case + Test Oracle
• Metamorphic Testing F(x)=sinx 的 example
• Test case extantiation

• Different testing levels:

  • Unit/Component testing

    • Driver 和 Stub 越简略越好

  • Integration testing

    • Big Bang integration

    • Top-Down integration

      • Low-level components not fully tested
      • Problem: defensive programming
    • Bottom-Top intergration

  • Acceptance testing

    • User acceptance
    • Operational acceptance
    • Contractual acceptance
    • Regulatory acceptance

Software testing methods

• White-box testing

  Can access source code/inner structure of program, base the test cases on the inner structure of the software program.

  • Static analysis: Test without executing

    • NULL pointers
    • Use of uninitialized data
    • Incorrect usage of APIs
    • Buffer overruns
    • Error handling issues
    • Unreachable code

  • Dynamic analysis: Test while running (Usually used for unit testing)

    • Statement coverage: Designing test cases that enable the execution of each statement at least once.
    • Branch coverage: Designing test cases that enable the execution of each branch of each decision at least once.
    • Clause coverage: Designing test cases that enable each clause to evaluate to each possible value.
    • Combinatorial coverage: Designing test cases that enable the coverage of each possible combination of the clauses of each decision.
    • Active clause coverage(Same as MCDC)
    • Path coverage:

    • Graph coverage:

      • Node coverage
      • Edge coverage

• Black-box testing

  • Input space partitioning

    • IDM(Input Domain Modeling) approach
    • Interface-based
    • Functionality-based
  • Boundary value analysis

  • Different techniques for different specification languages

    • Finite state machine
    • UML
    • Scenario-based
    • Z,B,SOFL

  • Tool support for black-box testing

    • Test case generation
    • Expected result generation
• Grey-box (不深刻探讨)

Chapter 6:object oriented software development

Object oriented

1. Object(对象)

   An entity with a well-defined boundary

   and identity that encapsulates state and behavior.

2. Class(类)

   A set of objects that share the same properties and behaviors.

3. Inheritance(继承)

4. Message

   A specification of a communication between objects that conveys information with the expectation that activity will ensue.

5. Abstraction(形象)

   • Emphasizes relevant characteristics
   • Suppresses other characteristics

6. Encapsulation(封装)

7. Polymorphism(多态)

   Different implementation behind a single interface.

Object-oriented analysis and design

UML(Unified Modeling Language)

• Class diagram

• Use-case diagram

  The context of the system to be built and the functionality provided by that system.

• Sequence diagram

Object-oriented testing:

• Individual class testing

  • Random
  • Partition testing(state,attribute,function)
• Integration testing