Final review of software engineering (super detailed!!!)

Software engineering

One: Overview of Software Engineering

The existence value of software engineering: to promote the success of software projects.

The concept of
software: software: software is another part of a computer system that is interdependent with hardware. It includes a complete collection of programs, data and related documents.
(1) Executable instructions (program) that can complete predetermined functions and performance
(2) Data structure (data) that enables the program to appropriately manipulate information
(3) Documents describing the operation and use of the program
Software crisis:
software Crisis definition: A series of serious problems encountered during software development and maintenance.
The software crisis has two meanings:
how to develop software.
How to maintain the ever-expanding amount of existing software.
Software Engineering (Software Engineering): It
is the research and application of how to develop, operate and maintain software in a systematic, standardized, and measurable way, that is, to apply engineering to software.
Software life cycle:
refers to the entire process of a software product from considering its concept to the software product's delivery and use until its final retirement. Generally include planning, analysis, design, implementation, testing, integration, delivery, maintenance and other stages.

The planning stage
determines the overall goals and scope of the system to be developed.
Study the feasibility of the system and possible solutions, and make reasonable estimates of resources, costs and schedules.
Analysis phase
Analyze, sort and refine the collected user requirements, establish a complete analysis model, and compile it into a software requirement specification and a preliminary user manual.
Design phase (overall design and detailed design)
The goal of the design phase is to decide how to do the software.
Software design mainly focuses onSoftware architecture, data structure, user interface and algorithmetc.
Implementation stage (coding) The
implementation stage is to write the designed modules into computer-acceptable program codes.
Test phase:
Design test cases, test the software, find errors, and make corrections.
During the operation and maintenance phase,
the software’s development should be fully considered in the software design and implementation phase.Maintainability.
During the maintenance phase, it is necessary to test whether the required modifications are correctly implemented, and to ensure that no other irrelevant changes are made during the product modification process.
Maintenance is often the most challenging stage in the software life cycle, and its cost is quite expensive.
Three elements of software engineering: tools, methods, and development process
waterfall model:
problem definition, feasibility study, demand analysis, outline design, detailed design, coding, testing, operation and maintenance.
Features:
1. A fixed sequence from top to bottom, connected to each other, like a waterfall, falling gradually.
2. The transformation result of the previous stage is the input of the next stage transformation, and two adjacent stages have a causal relationship.
Problems:
1. The division of each stage is completely fixed, and a large number of documents are generated between the stages, which greatly increases the workload.
2. The development model is linear. Users can only see the development results until the end of the whole process, which increases the risk.
3. Early errors may not be discovered until the later testing stage of development, which may bring serious consequences.
RUP unified software process (Rational Unified Process)
The central idea of RUP is: use case-driven, architecture-centric, iteration and increment.
Scrum agile process:

The person in charge of the product establishes the product pending development items of the entry, and prioritizes them.
At the iteration planning meeting, the product owner explains the items to be developed in this iteration, and the team estimates and puts it in the next iteration.
The team completes the listed requirements within the iteration, and holds daily "stand-up" meetings every day to communicate progress and problems.
At the iteration review meeting at the end of the iteration, the team presents the development results to the product owner.

2. Embark on the road of ICONIX software engineering

Requirements are the foundation of software engineering.
Requirement engineering: systematically describe the system to be developed and its behavior characteristics and related constraints through appropriate tools and notation to form a requirement document and support the evolution of users' changing requirements.
Requirements engineering structure diagram:

ICONIX process: The
extended ICONIX process can be divided into: vision, business modeling, demand analysis, robustness analysis, key design, final design, and realization.
Two big parts: the requirements phase and the system design and implementation phase.
Four stages: requirements analysis stage, preliminary design stage, detailed design stage, and deployment stage.
Defining the vision (trilogy):

Find the "boss" of the software project.
Get the "boss" expectation (vision) of the project;
Describe the metrics for the vision.

Three: business modeling, accurate understanding of your customers

Significance and considerations of business modeling

Business modeling requires us to shift our perspective from software systems to customer organizations, and look at problems from the customer's perspective to achieve a clear and accurate "diagnosis" and "prescription" for the symptoms.

Be clear about who you are serving-identify customers and their visions, remember not to make a system for yourself.
What is the current state of the organization to be improved-what are the pain points and shortcomings.
How to improve – The value of the new system is to solve customer pain and improve customer deficiencies. This is the motivation for customers to pay for it.
In the business modeling and requirements analysis stage, forget your identity as a technical expert.

The steps of
business modeling Business modeling is to locate the value that the system should provide from the perspective of the organization.
1. Make it clear who we serve (choose an organization whose vision needs to be improved).
2. What is the current status of the organization to be improved (business use case diagram, current business sequence diagram).
From the outside: an organization is a collection of values, modeled by business use case diagrams.
From the inside: an organization is a collection of systems (people are an intelligent system), modeled by business sequence diagrams.
5. How do we improve (improve the business sequence diagram).

Business use case diagram
Composition: business executor, business organization, business use case
business executor: people or organizations that interact with the organization outside the organization.
Business use case: the value that the organization provides to business executives.
Business sequence diagram: The business sequence diagram describes in detail how business executors, business workers, and business entities interact to complete the realization process of a business use case.
Business workers: People who are located in the organization and are responsible for certain tasks in the business process. For example, bank staff, hospital doctors.
Business entity: The "system" used by business workers in the realization process of a business use case. For example, bank teller machines, money counters, school campus card systems.
The role of business sequence diagram:
1. Identify business objects: business executors, business workers, business entities;
2. Determine the relationship between business objectsResponsibilities, collaboration and interaction sequence;
3. Understand the status quo through sequence diagrams and provide a basis for business optimization.
How to use improved business sequence diagrams to improve existing business processes?
1. Take the "new system" as a business entity for overall design;
2. Introduce the "new system" into the organization's existing business processes;
3. View the processes that can be improved;
4. Evaluate the improvement results;

Four: demand analysis, use case analysis

Domain modeling:
Create a belonging table for the project. Ensure that everyone in the project can understand and communicate the problem area in clear and consistent terms.
The advantage of domain modeling over ordinary project glossary is that it clearly shows the relationship between different terms in a diagram (to reduce understanding deviation).
Describe the entities involved in the business and their relationships with each other. Tools to help system analysts and users understand real business.
The domain model diagram will gradually evolve into the final static class diagram through continuous revision and improvement.
Steps of domain modeling:

Read the requirements document carefully and extract nouns and noun phrases.
Exclude duplicate and similar terms in the list
Exclude terms outside the system
Draw the first version of the domain model diagram
Organize the first version of the domain model

The relationship between domain models:
generalization: the relationship between general elements and special elements.
Association: There is a semantic connection between the two classes.
Significance of system use case modeling:

The purpose of system requirements analysis is to shift the perspective from the business organization to the new system, looking at the problem from the perspective of the end user and other stakeholders.
A system use case is a modeling of the value the system provides to the system executor.

System use case modeling steps:
6. Draw the system use case Figure
7. Write the system use case description
8. Update the relationship between the domain model
use cases:

Generalization relationship: The child use case is similar to the parent use case, but exhibits more specific behavior; the child use case will inherit all the structure, behavior, and relationships of the parent use case.
Containment relationship: Use containment use cases to encapsulate a group of similar actions (behavior fragments) that span multiple use cases so that multiple base use cases can be reused
Extension relationship: encapsulate a relatively independent and optional action in the base use case with an extension use case, and then let it extend from the extension points declared in the base use case, so that the behavior of the base use case is more concise and the target is more focused.

The basic composition of the use case description:
Stakeholder interest
Base path
Extension path
Business Rules

Typical non-functional requirements of software products:

reliability
Availability
performance
Supportability

Five: The bridge between demand and design: robustness analysis

Three elements in robustness analysis:

Boundary class: the object interacting with the user, the interface between the system and the external world, such as windows, dialog boxes, etc.
Entity class: It is an entity object that exists in the real world, a class in the domain model, it often corresponds to database tables and files.
Controller class: The "glue" between the boundary and the entity, which associates the boundary object with the entity object. It contains most of the application logic and builds a bridge between the user and the object. The control object contains frequently modified business rules and policies.

The interaction rules of the three elements in the robustness analysis: the
executor can only talk to the boundary object; the
boundary object and the controller can talk to each other; the
controller can talk to another controller; the
controller and the entity object can talk to each other;

Six: key design

The main significance of the key design
is to find the interaction between the objects, and then carry out the method (operation or behavior) allocation.

Seven: detailed design

Technical architecture and related considerations:

Choose development language
Network topology and security
Architecture
Hardware support environment
Software support environment

Eight: Agile Development

Agile software development model:

The core idea of agile development is based on the evolution of user needs as the core, and software development using an iterative and gradual approach.
Developed from the traditional iterative software development model, emphasizing product value, teamwork, customer participation, early verification, simplifying processes, and embracing change.
Summarize and absorb the best practices of successful software project research and development; complement each other with modern management thinking.
Agile = idea + good practice + specific application

Idea (Core Idea of Agile)
Good Practice (Accumulation of Agile Experience)
Specific application (it is truly agile to be able to combine its own flexible application)

Nine: Scrum Agile Process

Scrum is an incremental and iterative agile development process.
Scrum agile development process:
The entire development cycle of the project includes several small iteration cycles. Each iteration cycle becomes a Sprint. The recommended length of each Sprint is 2 to 6 weeks.
Use product Backlog to manage project requirements. Product Backlog is a list of requirements sorted by business value, usually in the form of UserStory.
The team selects the most commercially valuable requirements from the product Backlog, and obtains the task list after analysis, discussion and estimation in the Sprint planning meeting, which becomes the Sprint Backlog.
At the end of each iteration, the Scrum team will deliver potentially deliverable product increments.
Agile team The
agile team consists of 3 core roles:
PO (Product Owner),
Scrum Master (Scrum Coach),
Team (Development Team)
Scrum composition:
Three roles: Product Owner, Agile Coach, Team
Four meetings:
Three products of iteration planning meeting, daily stand-up meeting, iteration review meeting, and iteration review meeting : Product Backlog, Sprint Backlog, and
Burndown Chart
Scrum Features:
It is suitable for developing complex products in an environment with high uncertainty.
Concise but effective
Project information is highly transparent to all stakeholders
It is easy to find problems quickly, and promote continuous improvement of the team and organization.

Eleven: Agile Engineering Practice

User story: A
user story is a short description used to identify users and user needs. Contains three elements: role, function, and value.
Example: As a xxx customer, I need xxx functions to bring xxx benefits.
User story INVEST standard:

Independent: The stories are loosely coupled and independent. Should not rely on other user stories.
Negotiable: It is only used as a placeholder at the beginning and gradually refined.
Valuable: User stories are valuable to the end user, so they should be written from the user's perspective.
Estimable: The design, development, and testing teams can recalculate the workload and cost. (Unestimable reasons: too large to be broken down, or incomplete information requires further exploration)
Small (Small): The story should be as short as possible (such as a two-week sprint, the story is generally within two days)
Testable (Test): There are corresponding test acceptance standards.
Pair programming:
Two programmers work in front of a computer, one is responsible for typing in the code, and the other is for real-time inspection of each line of the entered code;
the programmer who operates the keyboard and mouse is called the "driver" and is responsible for real-time review The programmer who assists is called the "navigator"; the
navigator must also be responsible for considering the next work direction, such as possible problems and improvements, while reviewing.
Test-Driven Development:
TDD takes testing as the center of programming. It requires that before writing any code, first write test cases that define the function of the code. The written code must pass the use cases and be refactored and optimized continuously ;
Continuous Integration:
Continuous integration (CI) is a software development practice in which team members often integrate their work, usually at least once a day, and each time the integration is completed automatically.
Code Review