Chapter 1 initial knowledge of software engineering (software engineering software quality)
1.2 software
Software=program+data+file Properties: complexity, consistency, variability, invisibility Field: embedded, stand-alone, network, cloud computing, big data AI Intellectualization
1.1 software VS. software engineering
Software is not only the research object of software engineering, but also the product form and objective existence of software engineering. Engineering is a science that applies theory and knowledge to practice. Its purpose is to solve practical problems economically and effectively and deliver good enough software.
1.3 emergence and development of software engineering
Prehistoric times: individual workshops >Waterfall model >Quality standard system: CMMI,ISO9000 Etc Agile model
1.4 basic concepts of software engineering
Software engineering is to apply systematic, standardized and quantitative methods to software development, operation and maintenance, that is, engineering to software; ② Study on the method described in ①.
Three basic elements of software engineering
-
Process: a series of development activities: problems, requirements, design, development, test + management
-
Methods: process oriented, object-oriented, component-oriented, service-oriented
-
tool
Four basic strategies of software development: software reuse, divide and rule, gradual evolution, optimization and compromise
1.5 software quality realization
-
Three perspectives: the functional quality concerned by users, the structural quality concerned by developers, and the process quality concerned by investors
-
Dimensions of quality evaluation ISO quality model
-
Good software is not perfect: the balance of quality, cost and efficiency.
Chapter 4 software development process
4.1 software process
-
Software development activities: manage the process to ensure effective results. McDonald's excellence
-
Process classification
Implementation process: Requirements & Design & Development & test
Management process: Project
To support process: configuration, etc
4.2 software process model
Waterfall model, prototype model, iterative model, convertible model (embedded scene)
4.3 agile development process
1. Agile Manifesto: Individuals and interactions are better than processes and tools Working software is better than comprehensive documentation Customer collaboration over contract negotiation Responding to change is better than following the plan 1. Scrum: Every sprint, Scrum Focus on project management 1. XP Emphasis on programming practice
Chapter 5 team development management
5.1 team organization and management
5.2 project communication management
5.3 software project plan
Problem description, top-level design WBS Allocation, initial plan
5.4 software project estimation
Estimation methods: expert judgment, parameter estimation, function point method, use case point estimation and machine learning method
Chapter 6 agile development and configuration management
6.1 Scrum framework for Agile Development
-
Team role
-
Scrum products
-
Activity meeting: iteration planning meeting, daily standing meeting, iteration review meeting and iteration review meeting
6.2 user stories and estimates
1. Formats: roles+activity+value 1. Features: independent, negotiable, valuable, estimable, short and testable 1. Product order: user story set
6.3 team collaboration tool Tower
6.4 configuration management
Configuration item, baseline, version control, branch management
6.5 configuration management tool Git
1. Version Library: remote version library local version Library Local Development 1. branch
6.6 continuous integration and delivery
Chapter 7 requirements acquisition
7.1 requirements engineer
7.2 requirements definition
- It covers the following contents
Why design the system
Who makes the system
What does the system do
What information does the system involve
Are there any additional restrictions on the settlement of the case
How to make the system
To what extent is the quality required
- Quality of individual requirement items
• accurate • Correct • non ambiguous • Feasible • Verifiable - Quality of the entire set of requirements
• Realistic • precise • Complete • Consistent
7.3 types of requirements
7.4 requirements engineering process
• requirement extraction • requirement Analysis • requirement Specification • requirement Management • requirement Validation
7.5 main sources of demand
7.6 requirements acquisition technology
7.7 writing requirements documents
Chapter 8 use case modeling
8.1 use case modeling concept
8.2 use case modeling process
8.3 use case modeling
System boundary definitions, relationships and use cases are definitely not functional decomposition
8.4 introduction to modeling tools
Chapter 10 behavior modeling
10.1 sequence diagram concept
10.2 sequence diagram modeling
10.3 sequence diagram style
10.4 state modeling
10.5 status diagram
10.6 style of state diagram
Chapter 11 software system design
11.1 software architecture concept
1. Factors affecting software complexity design: word frequency statistics program web Retrieval system. With the increase of complexity, the design and planning of the global structure of the system is much more important than the algorithm and data structure. 1. Software architecture ![Insert picture description here](https://img-blog.csdnimg.cn/e109ceffe5c3498791ea5232cc4e7705.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA6YC46JCM,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center) 1. Development of software architecture ![Insert picture description here](https://img-blog.csdnimg.cn/a33d3663e557438fb377ace98d2247cf.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA6YC46JCM,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center) 1. Architecture style(System organization mode) VS. Software framework (reusable design) VS. Design pattern(Observer mode) Architecture style is the guidance of specification and describes the customary mode of system organization in a specific application field; Software framework is semi-finished product reuse The whole application structure given by the framework; Design pattern is the solution to a single problem ![Insert picture description here](https://img-blog.csdnimg.cn/ced34517939445649439a466ae984b5e.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA6YC46JCM,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)
11.2 software design principles
1. Abstract encapsulation modularization hierarchical reuse
11.3 software architecture style
11.6 software design process
- Overall system design
Define system design objectives
Identify subsystems or modules
Select system deployment scheme
Define design policies: storage scheme, access control policy, global control flow?
Review system design scheme
11.7 Web system architecture design
11.8 database selection strategy
Chapter 12 software interaction design
12.1 overview of interaction design
12.2 interaction design objectives
12.3 GUI design principles
12.4 KLM efficiency model
12.5 Fitts Law
12.6 interaction design process
Chapter 9 object oriented analysis and design
9.1 object oriented analysis
1. Analysis steps: identify classes, identify class relationship structures (inheritance and composition), define topics, and define class properties and behaviors
9.2 CRC card sorting method
9.3 object oriented design
1. Separation of interface and implementation, service-oriented principles, environmental constraints 1. Principle: opening and closing, Dependence Inversion and interface separation
9.4 class diagram modeling
Chapter 2 writing high quality code
2.1 programming process and specification
2.2 good programming practice
- Look, ask and Practice
- Design
Modularity: horizontal division, vertical division, variability division, single responsibility (not single function)
Abstract oriented programming: defining interface errors and exception handling between modules
2.3 integrated development environment IDE
2.4 code static check
2.5 code performance analysis
Chapter 3 unit test
3.1 unit test overview
1. Principle: fast, independent, repeatable, self validating and timely 1. Method: static test/Dynamic test, black box test/White box test 1. Tools: xUnit,Mock
3.2 black box test method
1. Concept of test case 1. Requirements for test case design: equivalence class division+Boundary value analysis+robustness test +Error inference
3.3 white box test method
1. Basic concept: allows testers to design or select test cases to test all logical paths of the program by using the internal logical structure and relevant information of the program 1. Code coverage standard: statement coverage>Decision coverage>Conditional coverage>Decision condition coverage>Conditional combination coverage>Path coverage>Combining conditional combination and path coverage 1. How to treat the test coverage: the overall software coverage and test cost need to be considered; We should not blindly pursue code coverage, but find ways to design good test cases
Chapter 7 Huawei cloud DevOps practice
7.1 Huawei cloud DevOps and examples
7.2 new Scrum project
7.3 continuous planning and design
7.4 continuous development and integration
7.5 continuous testing and feedback
7.6 continuous deployment and release
Chapter 13 software system test
13.1 software testing concept
13.2 software test type
13.3 software function test
13.4 software performance test
- performance index
Number of users
• number of registered users: the number of all users registered in the system
• number of online users: the number of all users accessing the system (not necessarily doing operations)
• number of concurrent users: the number of users who perform session operations at a specific time in a given time
response time
• the time taken from the time the client makes a request to the time it receives a response
throughput
• throughput refers to the number of customer requests processed by the system per unit time, which directly reflects the performance and carrying capacity of the software system. - performance testing
Load test determines the maximum load that the system can bear when the performance index is met by gradually increasing the system load.
The stress test determines the failure state of system performance under what load conditions by gradually increasing the system load.