Introduction to Software Engineering

Chapter 1: Introduction to Software Engineering
I. software engineering is an engineering discipline that guides computer software development and maintenance.
Ii. seven basic principles of the component project:
1. Use a phased-out life cycle plan for strict management
2. Adhere to the stage review
3. Implement strict product control
4. Adopting Modern Programming Technology
5. Results should be clearly reviewed
6. Developers should be less refined
7. acknowledge the necessity of constantly improving software engineering practices
3. Software Engineering methodology includes three elements: methods, tools, and processes.
The method is the technical method for completing various tasks of software development, and the answer is "How to do it"
Tools are automated or semi-automatic software provided for use.
Engineering Support Environment; the process is required to obtain high-quality software
The framework of a series of tasks, which specifies the steps to complete each task.

Iv. Software Engineering Methodology: traditional methodology and object-oriented methodology.

5. software life cycle: Software Definition, software development and operation maintenance (also known
Software maintenance.
　　

1. Major Tasks of Software Definition: problem definition, feasibility study, and Requirement Analysis

2 main tasks during development: overall design, detailed design, coding and Unit
Test and comprehensive test (the first two are system designs, and the last two are system implementations)

3 main tasks in maintenance period: Make the system persistent through various maintenance activities
To meet users' needs, there are usually four types of maintenance: 1. corrective maintenance, that is
Is to diagnose and correct software errors found during use;, 2 Adaptive Dimension
Protection, that is, modifying the software to adapt to changes in the environment; 3. Perfect Maintenance, that is, Root
Improvement based on user needs if the expanded software makes it more perfect, 4. Preventive Maintenance,
Modify the software to prepare for future maintenance activities.

　
// ① The key question that must be answered during the definition stage is: "the problem to be solved
What is it? "② Feasibility study ~ : Problems identified in the previous stage
Is there a solution that works? ③ Requirement Analysis: Determine the target system must have
Backup engineers ④ overall design: In summary, how should we achieve the target system?
Unified? ⑤ Detailed design: How should we implement this system? Coding
And unit test: write out the correct easy-to-understand and easy-to-maintain program module 7
Comprehensive Testing: various types of tests (and corresponding debugging) are used to pre-test the software.
The most basic test is integration test and acceptance test.
According to the design software structure, the module tested by unit test is
The selected policies are assembled to perform necessary tests on the program during the assembly process.
Test; the acceptance test is based on the specifications, the user on the target system
Acceptance
　

6. Various Models of software processes:
1) Waterfall Model (1. The stages have sequential rows and dependencies. 2. The implementation is postponed.
Current Opinion, 3. Quality assurance opinion)

2) Quick prototype model (a quickly established model can be run on a computer
Line program, the function it can accomplish is often the final product can complete
A subset of Functions)
3) Incremental Model (using software products as a series of incremental Components
Integration and testing. Each component consists of multiple modules that interact with each other.
Constitute and can complete specific functions)
4) spiral model (using prototype and other methods to minimize risks,
Risk-driven)
　
5) fountain model
　
　
Chapter 2 Feasibility Study

I. Feasibility study task
Objective: To determine whether the problem is solved in the shortest time with the minimum cost
Yes.

Analyze the advantages and disadvantages of several major possible solutions to determine the original system Scale
And whether the target is realistic, and whether the benefits brought by the system after completion are even more worthwhile
Degree of investment in developing this system

Ii. Feasibility
(1) Is it feasible to use the existing technology to implement this system?
(2) economic feasibility the economic benefits of this system can exceed its development
Cost?
(3) The operating method of the operating feasibility system is within the user's organization.
Does it work?
(4) If necessary, it is necessary to study laws and social benefits. (Optional)

Iii. Feasibility study process
1. Review system scale and objectives; 2. Study the systems currently in use
3. Export the high-level logic model of the new system. 4. further define the problem.
5. Export and evaluate the solution for selection; 6. Recommend the Action Policy
7. Draft the development plan and 8. Write documents for review

4. system flowchart: a traditional tool that outlines physical systems.

Data Flow Diagram: depicts the process of information flow and data moving from input to output.
Transformation in the process. A data flow chart is a graphical representation of system logic functions.
　
Data Dictionary: a data dictionary is a collection of data information, that is
A set of definitions for all elements contained in a data flow diagram.

Generally, a data dictionary consists of the following four types of elements:
(1) Data Stream
(2) data flow component (that is, data element)
(3) Data Storage
(4) Processing

 

Chapter 3 Requirement Analysis
Demand analysis is the last phase of the Software Definition period, and its basic tasks
Is to answer the question accurately "what must the system do. (Optional)

I. The task of requirement analysis is not determining how the system completes its work,
It is just to determine what the system must do, that is, the target
The system provides complete, accurate, clear, and specific requirements.

Ii. 3.1.1 determine comprehensive system requirements
1. Functional requirements, 2. Performance Requirements, 3. reliability and availability requirements
4. error handling requirements, 5. interface requirements, and 6. Constraints
7. Reverse demands, 8. Possible future requirements

Iii. 3.1.2 data requirements of the Analysis System
Data requirements of the analysis system usually adopt the data model method.
3.1.3 export the logical model of the system
The detailed logical model of the system can be exported based on the results of the above two analyses.
Data Flow Diagram, entity-contact diagram, State Conversion Diagram, and data word are usually used.
And the main processing algorithm to describe this logical model.

 

Iv. Methods for obtaining requirements
3.2.1 interview
3.2.2 top-down refinement for data streams
3.2.3 simple application specifications
3.2.4 quickly build software prototypes

 

V. 3.3.1 Analysis and Modeling
Three models should be created in the requirement analysis process: data models and functions.
Ability Model and behavior model.

Section 3.4 describes the object-contact graph to describe the relationship between data objects and data objects.
Is used to create a data model.
The data flow diagram described in section 2.4 depicts
The logical process of transformation indicates the function of the system to transform data. Therefore,
A data flow chart is the basis for building a functional model.

Section 3.6 describes the state transition diagram (hereinafter referred to as the state chart), specifying
System behavior of the event result. Therefore, the state transition diagram depicts
Behavior mode (called "state") and transition mode between different States. Status
Conversion graphs are the basis of behavior modeling.

3.4 entity-contact diagram (Data Objects, attributes, and contacts)
3.6 Status transition diagram (status, events, symbols)
3.7 other graphic tools and 3.7.1 layered Block Diagram
3.7.2 warnier diagram and 3.7.3 IPO Diagram

6. Verify software requirements (optional)
(1) consistency all requirements must be consistent, and any requirement cannot match
Other requirements conflict with each other.
(2) integrity requirements must be complete, and the specification should include the user
Every function or performance required.
(3) The purpose of reality should be to use existing hardware and software technologies.
It can basically be achieved. We can make some predictions on the progress of hardware technology.
It is difficult to predict the progress of software technology.
Judge the reality of the demand.
(4) The validity must prove that the requirement is correct and valid, and can solve the problem
Problems.

Chapter 1 Formal Description of technology (not tested)
Finite State Machine, Petri Net, Z language

Chapter 1 Overall Design
1. The overall design is also called a summary design or preliminary design. Its basic purpose is
Answer: "In general, how should the system be implemented? "This problem. (Yes
Select)

Divides the physical elements that constitute the system (Black Box-level)-programs, files,
Databases, manual processes, and documents

2. The overall design process is usually composed of two main stages: System Design Level
Segment, determine the specific implementation scheme of the system; structure design stage, determine the software
Structure. (Optional)

3. Design the software structure
1. Determine which modules are used by each program in the system.
2. Relationship between these modules
　　　
2. the design process consists of nine steps:

Plan for selection, select a reasonable plan, and recommend the best solution
Function Decomposition, software structure design, and database design
Develop test plans, document writing, review and review

Iii. Design Principle: modularization, abstraction, gradual refinement of information hiding and Bureau
Modularization and module independence

Iv. Measurement of module independence:
Two qualitative standard measurements: cohesion and Coupling
Coupling: measure the closeness between different modules (connections ).
Cohesion: measure the closeness of each element in a module.

V. Coupling
Data coupling (low coupling)
Feature Coupling
Control Coupling)
Common Coupling)
Content coupling (high coupling)

Vi. Design Principles
Coupling is an important factor affecting software complexity.
Try to use data coupling, less control coupling and feature coupling, and limit
Scope of public environment Coupling, no need for content coupling.

VII. module cohesion

8. design principles. If you rate the advantages and disadvantages of the above seven cohesion types
Result:
Function cohesion: 10 minutes, 9 minutes
Communication cohesion: 7 minutes; 5 minutes
Time cohesion: 3 minutes logical cohesion: 1 minute
Accidental cohesion: 0 Points
Strive to achieve high cohesion, identify and improve low cohesion modules

9. Inspiration rules:
1. Improve the software structure to improve the module Independence 2. The module scale should be moderate
3. The depth, width, fan-out, and fan-in should be appropriate. 4. The module scope should be
Within the control domain 5. strive to reduce the complexity of the Module Interface
6. Design a module with a single portal and a single exit 7. The module functions should be predictable

10. graphical tools for describing software structures (optional)
Hierarchy chart hipo diagram Structure
Data Stream-oriented design method: information stream type: Transform stream, transaction stream
Analysis steps:
Step 1 review the basic system model, step 2 review and refine the data flow diagram
Step 2: Determine whether the data flow chart has the conversion or transaction characteristics.
Step 2: Determine the border between the input stream and the output stream to isolate the transformation center.
Step 1: complete "Level 1 decomposition ". The transformed data flow diagram is mapped into
The information processing process of input, transform, and output.
Step 2: complete "Level 2 decomposition ". Map each process in the data flow diagram
Into an appropriate module in the software structure.
Step 2 Use design metrics and heuristic rules to obtain the soft
The component structure is further refined.

Chapter 2 Detailed Design

6.1 objective: to implement the system.
6.1.1 precise description of the target system should be obtained, so that the encoding phase can
To translate the description directly into a program written in a programming language.
6.1.2 The classic definition of structural programming is as follows: "If a program's
The code block is only controlled by the sequence, selection, and loop.
Structure, and each code block has only one entry and one output
The program is structured. "
6.13 if only the sequence, if-then-else branch, and
The three basic control structures of do-while loop are called classic
Structural program design;
6.1.4 In addition to the above three basic control structures
Do-case multi-branch structure and do-until cycle structure,
It is called the extended structure program design;
6.1.5 if the leave (or break) structure is added
Revised structure program design.

6.2 man-machine interface design: 1. system response time; 2. user help facilities
3. error information processing, 4. Command Interaction

6.3 process design tools:
Program flowchart, box diagram (N-S diagram), pad diagram, Decision Table
Decision tree and process design language

 

6.4 Data Structure-oriented design method:
6.4.1 The Jackson method and the warnier method are the two most famous data-oriented methods.
Structure design method.
The data structure-oriented design method must be analyzed first.
Define the data structure and use appropriate tools to clearly describe the data structure.
Jackson method:

(1) analyze and determine
Logical structure, which is illustrated by the Jackson diagram.
 
(2) Find the ing between the input and output data structures
. A corresponding relationship refers to a direct causal relationship,
Data units that can be processed simultaneously in the Program (for the number of repeated occurrences
Only when the order and frequency of data units must be the same can there be a corresponding correlation
System ).
(3) Use the following three rules to export from the Jackson diagram that depicts the data structure
The Jackson diagram that depicts the program structure:
First, there is a correspondence between each pair.
According to their hierarchy in the Data Structure
The corresponding layers of the structure chart draw a processing box (Note that if this pair of data
The level of a unit in the input and output data structures is not
In the same way, the layers corresponding to the processing boxes in the program structure
And the lower layers in the data structure );
Second, based on the remaining data units in the input data structure
In the corresponding layers of the program structure, respectively draw a pair
Handling box;
Third, based on the remaining data units in the output data structure
In the corresponding layers of the program structure, respectively draw a pair
Handling box.
The improved Jackson Diagram
The elements in the order structure cannot be repeated or selected
Therefore, you may need to add a processing box at the intermediate level.
(4) list all operations and conditions (including Branch Conditions and loop termination items)
And assign them to the appropriate location of the program structure.
(5) use the pseudo code to represent the program

6.5 quantitative measurement of Program Complexity: McCabe method and Halstead Method

 

Chapter 2 Implementation
7.1 coding and testing are generally referred to as implementation.

7.2 The so-called code is to translate the software design results into a program design.
Programming language.

7.3 The purpose of the test is to try
Discover software errors in multiple locations.

Unit Test and Comprehensive Test

7.4 goals of software testing: (1) testing aims to discover errors in the program
The process of executing the program; (2) a good test plan is very likely to be found so far
An undiscovered error test plan; (3) a successful test is found till now
Tests that have not been found so far.
Test method:
N black box testing: If you already know what functions the product should have, you can
Test to check whether each function can be used normally;
N white box test: If you know the internal working process of the product, you can pass
Test to check whether the internal actions of the product comply with the specifications
Normal.

7.5 Test Procedure: (important)
1 module test, 2 subsystem test, 3. System Test
4. Acceptance Test and 5. Parallel Operation

7.6 integration test:
1. Top-Down integration 2. Bottom-up integration
 
7.7 white-box testing technical logic coverage:

1. Statement overwrite 2. Decision overwrite 3. Condition overwrite 4. Decision/condition Overwrite
5. Condition combination coverage 6. Point Coverage 7. Edge coverage 8. Path coverage

Control structure test:
1. Test the basic path:
Step 1: Draw a flow chart based on the process design results.
Step 2: Calculate the annular complexity of a flow chart.
Step 3: determine the basic set of linear independent paths.
Step 4: design a test case that enforces each path in the basic set.

 

7.8 black box testing technology:

Equivalence division, boundary value analysis, and incorrect estimation
Software Reliability: basic concepts and methods for estimating the average no-fault time
4. methods to estimate the total number of errors:
1) implant error method 2) separate Test Method
 
Chapter 4 Maintenance

8.1 definitions of software maintenance:
After the software has been delivered for use, to correct errors or meet new requirements
The process of modifying the software.
　　
Corrective maintenance: during the use of any large program, the user will inevitably issue
Current program error, and report the problems they encountered to the maintenance personnel.
Adaptive maintenance: that is, to properly cooperate with the changed environment
Software modification activities are both necessary and regular maintenance activities.
Perfection maintenance: users often propose new functions when using software.
Suggestions for modifying or modifying existing functions may also provide general improvement suggestions.
Preventive Maintenance: When to improve future maintainability or reliability, or
To lay a better foundation for future improvement and modify the software.