Software Engineering Exercises-part01-Software Engineering Overview and Software Process

Course Introduction

The "Software Engineering" course is the core course of the software engineering major. It is a comprehensive course that uses engineering methods to guide software development, maintenance and management. The content involves the theory and technology related to software analysis, design, implementation, maintenance and project management. , methods and CASE tools.

Exam syllabus

⚫Software 重点掌握engineering 基本概念and 基本原理;
⚫Based on the current needs of China's software companies for software development, master and be able to 运用software engineering, 基本原理practical 软件开发技术and basic 管理技术;
⚫Software 了解engineering discipline 知识结构.

⚫(1) Software engineering concepts and basic elements of software engineering
⚫(2) Software process
⚫(3) Software requirements and software requirements specifications
⚫(4) System specifications and software design
⚫(5) Software testing
⚫(6) Software engineering Management⚫
(7) Software Quality, Quality Characteristics and Software Quality Assurance⚫
(8) Computer Aided Software Engineering CASE Tools and Environment

Software Engineering Concepts and Basic Elements of Software Engineering

waterfall model

Software product model:

Software Process Model:

The software process model is traditionally also called the software development model, which is the structural framework of the entire process, activities and tasks of software development. Typical software processes include waterfall model, incremental model, evolution model (prototype model, spiral model), fountain model, component-based development model and formal method model, etc.

Software Project Model:
Software Testing Model:

V Model W Model X Model H Model Agile Model

CMM Support Software Quality Elements

CMM believes that the elements supporting software quality include three aspects: process, product and personnel.
Product, process, and people
For example,
the process requires developers to develop software according to the established process,
the product requires developers to produce products that meet the specifications,
and the personnel requires developers to have sufficient skills and experience.
The organic combination of these elements can ensure the high quality of software.

The quality of software engineering mainly depends on three factors: methods, tools, and processes, referred to as the three elements of software engineering.
Method is a technical method for completing various tasks of software development, and provides "how to do" technology for software development.
A tool is an automatic or semi-automatic software engineering support environment provided for the application of a method.
The process is the framework of a series of tasks that need to be completed in order to obtain high-quality software. It specifies the work steps to complete each task, how to combine software engineering methods with software tools, and develop software reasonably and timely.

A statement about the incremental development model

Integrating the basic components of the waterfall model and the iterative features of prototype implementation, multiple available versions can be released, and the core functions are often completed first. On this basis, there will be new incremental releases in each round of iterations, and the core functions can be obtained. Fully tested. Emphasize that each increment releases an operational product.
As a variant of the waterfall model, the incremental model has all the advantages of the waterfall model. In addition, it has the following advantages:

The cost and time required for the first deliverable version is small; the risk taken to develop a small system represented by an increment is small;
because the first version is released quickly, there are fewer changes in user requirements; Quantitative investment, that is, at the beginning of the project, you can only invest in one or two increments.

The incremental model has the following disadvantages:

If there is no planning for the user's change requirements, the initial increment may cause the instability of the subsequent increment;
if the requirements are not as stable and complete as the early thinking, then some increments may need to be redeveloped and re-released ;
Managing the incurred cost, schedule, and configuration complexities may exceed the organization's capabilities.

The incorrect description of the software process model feels like it should be B

The difference between the waterfall model and the fountain model

Software Engineering Activities:

Waterfall model: It stipulates various software engineering activities and their fixed sequence of top-down and mutual connection, just like a waterfall of water falling step by step. Feasibility study, requirement analysis, overall design, detailed design, coding, unit test system, test acceptance, test operation and maintenance,

fountain model: the fountain model is mainly used to describe the object-oriented development process, and the word "fountain" reflects the iterative and seamless process of object-oriented development feature. Iteration means that the development activities in the model often need to be repeated several times, each repetition adding or clarifying some properties of the target system, but not substantially changing the results of previous work. Uninterrupted implicit means that there is no clear boundary between development activities (such as analysis, design, programming), but each development activity is allowed to cross and iteratively proceed.

Software Development Model:

First of all, there are several main classifications of development models: prototype model, structured model, object-oriented model, Jackson model, etc. These are vague classification concepts without clear division standards.
It is important to be able to distinguish between the prototype model and the structured model, because the two are complementary, and others only need to grasp their specific characteristics, so I won’t go into details here.

Reference: https://blog.csdn.net/Biu_Destiny/article/details/116893974

The basic processes of the life cycle include

The activities that may be performed during the software life cycle are divided into

There are 5 basic processes,
9 supporting processes
and 7 organizational processes.
Each life cycle process is divided into a group of activities, and each activity is further divided into a group of tasks.

Basic process
Activities directly related to production
1. Acquisition process: activities defined for the demand side, start-up, bidding, contract, supervision of suppliers, acceptance, etc.; 2. Supply
process: activities defined for the supplier, start-up, preparation Bidding, contract signing, planning, execution, delivery and completion;
3. Development process: activities defined for the developer: requirements, design, coding, testing, installation, acceptance;
4. Operation process: defined for the operator Activities: test operation, system operation, user support;
5. Maintenance process: activities defined for the maintenance party: problem and modification analysis, modification implementation, maintenance review/acceptance, migration, software decommissioning
support process

organization process

What level of CMMI does budget and schedule preparation belong to?

Editing budgets and schedules is a dedicated practice of the CMMI Managed-level "Project Planning" process area√

Definition of the five levels of CMM

1) Initial level (Initial): Occasionally, there will be confusion in the software development process, only a few work processes are strictly defined, and the success of development often depends on the wisdom and efforts of a certain person.
2) Repeatable level (Repeatable): The basic project management process has been established. Design features step by step, track costs, and develop against project schedules. For similar projects, parts that have been successfully developed before can be reused.
3) Defined level (Defined): The engineering activities and management activities of software development are documented and standardized, and it is integrated into an organization's standard development process. The development and maintenance of all projects are customized on the basis of this standard.
4) Managed level (Managed): The software development process and product quality testing details are well summarized, and both the product and development process can be decomposed and controlled quantitatively.
5) Optimizing level (Optimizing): Through the establishment of a quantitative feedback mechanism in the development process, new ideas are constantly generated, and new technologies are used to optimize the development process.

Refer to the following in this article: Expansion 4.CMMI

Technologies not used by RUP

Reference: Unified Software Development Process (RUP)
RUP is the unified development process of Rational Unified Process. The technologies used are:

Iterative and incremental use-case-driven
RUP is a use-case-driven, architecture-centric, iterative and incremental software process framework that provides an evolutionary feature.

The unused techniques are:

Test-Driven Development
Test-Driven Development, English full name Test-Driven Development, referred to as TDD, is a new development method different from the traditional software development process. It requires to write the test code before writing the code of a certain function, and then only write the function code that makes the test pass, and promote the whole development through the test. This helps to write clean, usable and high-quality code and speeds up the development process.

what is software

Software is the research object of software engineering, and it is also the product form and objective existence of software engineering.
Engineering is the science of applying theory and technology to practice, with the aim of solving practical problems cost-effectively.

Software = program + data + document

Program: A computer that accepts a sequence of instructions that, when run, provide the required functionality and performance.
Data: A data structure that enables a program to manipulate information appropriately.
Documentation: Graphical materials describing the development process, methods and use of the program.

Software has complexity, consistency, variability, and invisibility, etc.

What is CMMI, and in the CMMI continuous expression, which levels are the ability levels divided into?

The full name of CMMI is Capability Maturity Model Integration, that is, Capability Maturity Model Integration. CMMI is the latest version of the CMM model.
The full name of CMMI is Capability Maturity Model Integration. There are five levels of CMMI certification:
CMMI level 1, completion level; CMMI level 2, management level; CMMI level 3, definition level; CMMI level 4, quantitative management level; CMMI level 5, optimization level.

In CMMI models, to support the use of continuous representation, all CMMI models reflect capability levels in their design and content . The four capability levels of CMMI are designated as level 0 to level 3, and each level is a level, which serves as the basis for continuous process improvement.

CMMI level 0. Incomplete level
CMMI level 1. Executed level
CMMI level 2. Managed level
CMMI level 3. Defined level
CMMI level 4. Quantitative management level
CMMI level 5. Optimization level

The CMMI based on the continuous expression has a total of 6 (0-5) capability levels, corresponding to the unfinished level, the executed level, the managed level, the defined level, the quantified management level, and the optimized level. Each capability level corresponds to a general goal and a set of general and specific means of implementation. Capability level 0 means that the process is not performed, indicating that one or more specific objectives of the process area have not been met; capability level 1 means that the process produces identifiable output work products by transforming identifiable input work products, focusing on the specific objectives of the process area. Completion of objectives; capability level 2 refers to the institutionalization of the process as a managed process, targeting the capability of a single process instance; capability level 3 refers to the institutionalization of the process as a defined process, focusing on the organization-level standardization and deployment of the process; capability level 4 refers to The process is institutionalized as a quantitative management process; capability level 5 refers to the process as an optimized process institutionalized, indicating that the process is well executed and continuously improved.

What is open source software, with examples

The so-called open source, "source" refers to its source code, open source means that the writer of the software provides the source code to the user for free, and requires the user to follow certain open source specifications. For example, linux is open source software

Design 6 core engineering workflows and 3 core support workflows in each iteration cycle of RUP, describe the names and main goals of the 6 core workflows

Reference: In-depth understanding of the 6 core process workflows and 3 core support workflows of the iterative two-dimensional development model.

business modeling business modeling: business modeling describes how to develop a vision for a new target organization and based on this vision define the organization's process roles and responsibilities in a business use case model and a business object model requirements analysis requirements: requirements workflow
goals It is a description of what the system should do, and developers and users have not reached a consensus on this description. To achieve this goal, the functionality and constraints of the requirements are extracted, organized, and documented; most importantly, the definition and scope of the problem to be solved by the system is understood.Define system functions and user interface, the main result of this workflow is the software requirements specification.
Analysis and design Analysis&design: The analysis and design workflow is to transform the requirements into the design of the future system, develop a robust structure for the system and adjust the design to make the rest of the implementation environment match each other and optimize its performance. The analysis design results are a design model and an optional analysis model.
Implementation: The purpose of implementing the workflow is to define the organizational structure of the code in the form of hierarchical subsystems, implement classes and objects, conduct unit tests on the developed components, and integrate the components of a single developer to make it an executable system .Define the organizational structure of the code, implement the code, unit test, and system integration.
Test Test: After completing the development of requirements capture, analysis, design, implementation and other stages, and getting the source code, it is necessary to start looking for possible errors and defects in the software product.Verify that all requirements are implemented correctly, ensuring that all errors and defects are found before release.
Deployment: The purpose is to generate a version and distribute the software to end users. The deployment workflow describes: packaging the software, producing products other than the software itself, installing the software, and providing assistance to users.

Configuration and change management: The configuration and change management workflow describes how to control a large number of artifacts in a multi-member project. Configuration and change workflows provide guidelines to manage multiple traversals in an evolving system, following multiple releases in the software process. Workflow describes how to develop in parallel, distributed development, and how to automatically create projects. At the same time, it also explains the reason, time and personnel of product modification to maintain audit records.

Project management: Objectives include providing a framework for project management and guidelines for planning, staffing, and execution.

Environment: The purpose of the environment workflow is to provide a software development environment, including processes and tools, to a software development organization

The activities that may be performed in the software life cycle are divided into 5 basic processes, what are the 5 basic processes, and which side of the software project each basic process is related to.

5 basic processes:

1. Acquisition process: activities defined for the demand side, start-up, bidding, contract, supplier supervision, acceptance, etc. 2.
Supply process: activities defined for the supplier, start-up, preparation of bids, signing of contracts, preparation of plans, Execution, delivery and completion
3. Development process: activities defined for the developer: requirements, design, coding, testing, installation, acceptance
4. Operation process: activities defined for the operator: running test, system operation, user support
5. Maintenance process: activities defined for the maintenance party: problem and modification analysis, modification implementation, maintenance review/acceptance, migration, software decommissioning

9 supporting processes:

1. Documentation process
2. Configuration management process
3. Quality assurance process
4. Verification process: The process of determining whether software products meet the requirements and conditions imposed on them in previous activities. Contract Verification, Process Verification, Requirements Verification, Design Verification, Coding Verification, Integration Verification, Document Verification
5. Verification Process: The process of determining whether the requirements and the final, built system or software product meet the specific intended use. This process includes the following tasks:

1. Prepare selected test requirements, test cases, and test specifications for analysis of test results
2. Ensure that these test requirements, test cases, and test specifications reflect specific requirements for a particular intended use
3. Testing includes strength, boundary, and exception input testing

6. Joint review process: evaluate the status and products of an activity of a project, project management review, technical review
7. Review process: determine compliance with requirements, plans and contracts, as appropriate
8. Problem solving process
9. usability process

7 Organizational Processes

1. Management process: the basic activities defined for management in the life cycle process including project management
2. Infrastructure process: the basic activities defined for establishing the life cycle process infrastructure
3. Improvement process
4. Human resource process
5. Assets Management process
6. Reuse program management process: activities defined for the organization's reuse program director, initiation, domain evaluation, reuse evaluation, planning, execution and control, review and evaluation 7. Domain engineering process: activities and tasks of domain engineers
, domain analysis, domain design, asset provisioning, asset maintenance

expand

1. Briefly describe the conceptual differences among software process, software life cycle, and software process model (software life cycle model).

Software process: is the activity involved in a series of related processes in the software life cycle. A process is a collection of activities; an activity is a collection of tasks; a task is an operation that transforms input into output.
Software life cycle: the process of software from birth to death. It can be divided into three cycles of definition, development and operation, including the stages of feasibility analysis, project planning, demand analysis, software design, coding and testing, operation and maintenance.
Software process model: It is an abstract representation of a software process; it expresses a process from a specific perspective, and generally uses intuitive graphics to represent the complex process of software development. The software process model is mainly established according to various factors such as the type and scale of the software, especially the software development method and development environment.

Difference:
The software life cycle is a process, the main body is software;
the software process is the process from the birth of software and its life cycle, and it is a series of activities involved in this process; the
software process model is the series of activities ( Abstract representation of a software process).

2. Is the software process the software development process? Why?

no. The software development process is only a stage in the software process. The software process is divided into three categories according to the main body undertaking the software development work: basic process, support process, and organizational process. The basic process is divided into acquisition process, supply process, and supply process according to different subjects in the process. Process, development process, operation process, maintenance process, so the software development process is only a part of the software development process.

3. Software testing model

Reference: https://blog.csdn.net/WeirdoGiraffe/article/details/124883325
Like the development model, software testing can adopt different The testing model implements testing activities to guide the arrangement of software testing activities.
Common models in the industry:

1. V model
2. W model (double V model)
3. X model
4. H model
5. Agile model

V model

The V model is the most well-known model of all software testing models. It is a test model evolved from the waterfall R&D model, as shown in the figure.

The V-model process is from top to bottom, from left to right
① Test engineers perform unit tests on the generated code functions during the programming process of R&D personnel
② Integration tests are performed after unit tests are passed
③ System tests and acceptance are performed after integration tests are passed test

V model disadvantages:

Defects early in the project are discovered later

W model

The W model is evolved on the basis of the V model, and is generally called the double V model. In the V model, when the R&D activities are not completed and there is no output, the test engineers cannot carry out the test work, relatively speaking, the test activities are seriously lagging behind. In order to solve the shortcomings of the V model, the W model puts forward the concept of parallel testing activities and R&D activities, and increases the verification and confirmation activities during the evolution of the production process.

The W model begins with user requirements. The R&D team conducts activities such as requirement analysis, outline design, detailed design, and coding development according to user requirements. The testing team conducts acceptance testing, system testing, integration testing, and unit testing design based on user requirements. Testing work is separated from R&D activities, enabling parallel operations. Testing activities are accompanied by the entire R&D process, not only after the R&D results are output.
The W model emphasizes that testing activities not only include software source codes produced by R&D activities, but also consider various documents, such as requirements documents, general design documents, detailed design documents, codes, etc.
The W model requires testing activities to be involved from the stage of user requirements, which is conducive to finding problems as early as possible. During the model implementation process, validation and verification activities are always carried out

X model

The background of the X model is also related to the V model. The disadvantage of the V model is that the testing activities lag behind the research and development activities, and the testing activities cannot be carried out as early as possible. The X model, like the W model, was originally proposed to solve the shortcomings of the V model.
The basic idea of ​​the X model was proposed by Marick and improved by Robin F.Goldsmith. The X model is shown in the figure.

The left side of the X model indicates independent coding and testing activities for individual program fragments n, taking this as the basic process, continuous iteration, and finally becoming executable programs through integration activities, and then testing these executable programs. The finished product that passes the integration test can be packaged and submitted to the system test link or directly to the user. Multiple parallel curves indicate that changes can occur in various parts.
The X-model presents the concept of exploratory testing. Exploratory testing is different from conventional testing methods. It does not need to make a test plan or design in advance. Experienced test engineers can find more software errors outside the test plan according to their own thinking activities and understanding of the tested object. However, exploratory testing is usually only used as a supplement to other testing methods. Because it consumes more testing resources and is subject to the experience of test engineers, it cannot be an independent testing method.

H model

The H model separates test activities from other R&D processes. Test activities are divided into two parts: test preparation and test execution, which facilitates the definition of test design and test execution activities, as shown in the figure. Test preparation activities include test requirements analysis, test planning, test design, test coding, test verification, etc. Test execution includes test run, test report, test result analysis, confirmation regression test, etc.

Like the W model, the H model reveals that the software testing activity should be an independent software production process throughout the entire software life cycle. The testing activity should be prepared and executed as early as possible. Test execution activities can be carried out without being subject to research and development activities.

agile testing model

Emphasize testing from the perspective of customers;
focus on iterative testing of new features, de-emphasize the testing phase
Test as early as possible, test continuously, and test when conditions are met Emphasize
continuous feedback
Preventing defects is more important than discovering them

Evolutionary Models and Prototype Models

The evolutionary model is also a prototyping development method, which is slightly different from the rapid prototyping model.

In the rapid prototyping model, the purpose of the prototype is to know the real needs of the users. Once the needs are deficient, the prototype is discarded.
The evolutionary model development process is a gradual process from the initial model to the final software product.

That is to say, the rapid prototyping model is a "disposable" prototyping method, while the evolutionary model is a "gradual" prototyping method.

4.CMMI

Reference: https://deepmind.t-salon.cc/article/6396
A detailed explanation of the 5 levels and 22 process areas of the CMMI Capability Maturity Model, bookmark and learn the
basics of software engineering and recommend
the relationship between CMM and CMMI
Fanfeng information CMMI-DEV (Development View)

The full name of CMMI is Capability Maturity Model Integration, that is, Capability Maturity Model Integration. CMMI is the latest version of the CMM model.
The full name of CMMI is Capability Maturity Model Integration. There are 5 levels of CMMI certification:

CMMI1 level, completion level; CMMI2 level, management level; CMMI3 level, definition level; CMMI4 level, quantitative management level; CMMI5 level, optimization level.

In CMMI, each CMMI subject model has two representations:

Staged representation and continuous representation.
Models of different representations have different structures. The continuous notation emphasizes the capability of a single process area, and the improvement of the baseline and measurement results is examined from the perspective of the process area. The key term is "capability"; while the staged notation emphasizes the maturity of the organization
. The collective perspective examines the process maturity stages of the entire organization, with the key term being "maturity".

CMMI process area

CMMI V1.3 has a total of 22 process areas, process area (PA): describes the problem of a certain aspect that should be focused on or improved in the whole process improvement activities, sets goals for each process, and practices according to the goals. Each process area has clear goals (Goal) and practice (Practice), goals and practices include:

GG (Generic Goals), the Chinese name is the general goal, corresponding to GP (Generic Practices), the Chinese name is the general practice, and it is applied to the capability dimension, so it is applicable to all key process areas.

SG (Specific Goals), the Chinese name is specific goals, corresponding to SP (Specific Practices), the Chinese name is specific practices, applied to the process dimension, and can only be applied to a specific key process area.

The CMMI levels, process areas, objectives, and practices are related as follows:

CMMI practice domain

Practice domain is an important concept in the CMMI (Capability Maturity Model Integration) framework, which refers to a set of reusable standard practices that have been proven to be effective in a specific field.
Practice domains used to be called "process domains", eg configuration management, are now called "practice domains". For version 2.0, there are 25 applicable practice areas. As with previous versions of the CMMI model, "Domains of Practice" introduce the requirements and descriptions of the key activities that define the intent of the practice.

The practice domain of CMMI is divided into two levels: general practice domain and specific practice domain. Generic practice areas include project management, engineering, process and product support, and these practices are designed to support process improvement and project management across the organization. Specific practice domains are some specific practices formulated according to different business fields and industries to better respond to various special needs.

For example, for the field of software development, specific practice areas in CMMI include requirements management, design management, test management, and so on. These practices can help software development organizations establish better requirements management, design management, and test management mechanisms, improve software development productivity, and optimize software development processes.

Summarize

This series of blogs is related to software engineering. This article is the first part of software engineering overview and software process exercises.