This is the 11th day of my participation in the August More Text Challenge. For details, see:August is more challenging

🌻 Software engineering foundation

1.1 Capability maturity Model

1.1.1 Software Engineering Principles

Strict management with a phased life cycle plan, adherence to phased reviews, strict product control, use of modern programming techniques, results should be clearly reviewed, development teams should be small but refined, and the need for continuous improvement in software engineering practices should be recognized.

1.1.2 Basic elements of software engineering

Methods, tools, processes. Information system life cycle

1.1.3 Information system Life Cycle

1. System planning stage: the task is to the organization environment, objectives and the status of the current system of the preliminary investigation, according to the organizational goals and determine the development strategy of information system development strategy, the demand for construction of the new system to make analysis and forecast, at the same time considering building a new system of various constraints, studies the necessity and possibility of building a new system. According to the need and possibility, give the alternative plan of the construction system.

Output: feasibility study report, system design assignment.

2. System analysis stage: the task is to investigate the current system in detail according to the scope determined by the system design task book, describe the business process of the current system, point out the limitations and shortcomings of the current system, determine the basic objectives and logical functional requirements of the new system, that is, put forward the logical model of the new system. The system analysis phase is also called the logical design phase. This stage is the key stage of the whole system construction, and it is also the important difference between information system construction and general engineering projects.

Output: system specification.

3. System design phase: The task of the system analysis phase is to answer the “what” question of the system, while the system design phase is to answer the “how” question. The task of this stage is to design and implement the technical scheme of the logical model according to the functional requirements specified in the system specification, that is, to design the physical model of the new system. This stage, also known as the physical design stage, can be divided into two sub-stages: overall design (outline design) and detailed design.

Output: system design specification (outline design, detailed design specification).

4. System implementation stage: it is the stage to put the designed system into practice. The tasks in this stage include the acquisition, installation and debugging of equipment such as computers, the compilation and debugging of programs, personnel training, data file conversion, system debugging and conversion, etc. This stage is characterized by several interrelated, mutually restricted tasks at the same time, must be carefully arranged, reasonable organization. The implementation of the system is completed in stages according to the implementation plan, and the implementation progress report should be written for each stage. Write system test analysis report after system test.

Output: implementation progress report, system test analysis report.

5. System operation and maintenance phase: after the system is put into operation, maintenance and evaluation should be carried out frequently, the operation situation of the system should be recorded, necessary modifications should be made to the system according to certain rules, and the working quality and economic benefits of the system should be evaluated.

1.1.4 Software life cycle

Feasibility analysis and project development plan, requirement analysis, outline design (select system solution, plan subsystem), detailed design (design subsystem internal concrete implementation), coding, testing, maintenance.

1.1.5 Capability maturity Model (CMM)

A description of the phases of software organization through which the capability of a software organization increases as it defines, implements, measures, controls, and improves its software processes. For software development and testing stage. It is divided into the following five levels:

1.1.6 Capability Maturity Model integration CMMI

It is the synthesis and improvement of several process models, not only software, but also a systematic and consistent process improvement framework that supports multiple engineering disciplines and fields. It can adapt to the characteristics and needs of modern engineering, and improve the quality and efficiency of the process. CMMI can be expressed in two ways:

1. Staged model: Similar to the CMM, it focuses on the maturity of the organization. The five maturity models are:
2. Continuous model: Focusing on the capabilities of each process area, an organization can achieve different levels of process area capabilities for different process areas.

1.2 Software process model

1.2.1 Waterfall Model

The model in the structured method is structured development, and the development process is like a waterfall, which goes on step by step until the final project development is completed. It is only applicable to clear requirements or secondary development (stable requirements). When the requirements are not clear, the final project will make mistakes and have big defects.

1.2.2 prototype

, in contrast to the waterfall model, prototype in the presence of demand is not clear, the first rapid construct a function model, presentation to the user, and in a timely manner to modify according to the requirements of customers, through constant communication with the user, demonstration among the final design project, will not appear to the user request is not in conformity with the situation, USES the iterative thinking. Not suitable for mega project development.

1.2.3 Incremental model

First develop core modules, and then confirm with users, and then develop the function of the core modules, where each part development capabilities, and confirm with the user demand, in the end to complete the project development, service the first delivery of the highest priority, but as a result not from the Angle of system as a whole planning modules, thus for module partition. The challenge is to break down customer requirements into increments. In contrast to prototypes, where prototypes are constructed for demonstration purposes, each incremental version of an incremental model is a stand-alone, actionable work.

1.2.4 Spiral model

It is a mix of models for projects with unclear requirements, similar to prototypes but with increased risk analysis, which is also its biggest characteristic. Suitable for large-scale project development.

1.2.5 v model

It is characterized by the addition of many rounds of testing, and these tests throughout the software development stage, unlike other models are software development after testing, to a large extent to ensure the accuracy of the project. V Model development and test levels correspond to the following figure:

1.2.6 Fountain model

It is characterized by an object-oriented model, while the other models mentioned above are structured models that use iterative thinking and seamless development. CBSD: The component-based development model is characterized by enhanced reusability. During the system development process, a component library is built for reuse by other systems, thus improving reliability and saving time and cost.

1.2.7 Formal method model

A software development method based on strict mathematics in which the primary activity is the generation of formal mathematical specifications for computer software.

1.3 Software development methods

The above software process models can be basically attributed to the following development methods

1.3.1 Main features of the structured method

Structure refers to the framework of the interrelation and interaction among the components of the system. Structured Analysis (SA), StructuredDesign (SD) and Structured Programming (Programming) are traditional methods of information system development. SP) is an organic combination of three parts, the essence of which is top-down, step-by-step refinement and modular design.

1. Clarity of development goals. A structured approach to system development follows the “user first” principle.

2. Development work is phased. After the completion of each phase of the work, according to the phase of the work objectives and requirements to review, so that the work of each stage in an orderly manner, facilitate project management and control.

3. Development document standardization. After the completion of each phase of the structured method, the corresponding documents should be completed according to the requirements to ensure the connection of each phase of the work and the traversal of the system maintenance work.

4. The design method is structured. In the system analysis and design, from the whole and global consideration, top-down decomposition; In the system implementation, according to the design requirements, first write each specific function modules, and then gradually from the bottom to the realization of the whole system.

1.3.2 Deficiencies and limitations of the structured approach

1. Long development cycle: Go through the phases in sequence until the implementation phase is complete before users can use the system.

2. Difficulty adapting to changing requirements: Not suitable for projects where requirements are unclear or change frequently.

3. Little consideration for data structures: A structured approach is a data-flow-oriented development approach that gives little consideration to data structures.

1.3.3 Common tools for structured methods

Structured methods generally use graphics to express user needs, and the common tools include data flow diagram, data dictionary, structured language, decision table and decision tree.

1.3.4 Features of object-oriented methods

Object-oriented (oO) method believes that the objective world is composed of a variety of objects, everything is an Object, each Object has its own laws of motion and internal state, all belong to an Object class, is an element of the Object class. Complex objects can be composed of relatively simple objects in a certain way, and the combination and interaction of different objects constitute a system.

1. The key to better reuse of systems constructed using OO approaches is to establish a comprehensive, rational, and unified model (use case model and analysis model).

2. The OO approach is also divided into phases, but there is no “gap” between the three phases of system analysis, system design, and system implementation. In other words, the boundaries between the three stages become unclear, and a certain work can be completed in either the former or the latter stage; The work in the previous phase was not detailed enough and could be supplemented in the later phase.

3. The object-oriented method can be applied to the development of all kinds of information systems.

1.3.5 Shortcomings of the object-oriented approach

Must rely on certain object oriented technology support, in the development of large projects have certain limitations, can not get involved in the system analysis before the development link.

Currently, the development of large information systems often combines structured and oO approaches. First, the top-down division is made using a structured approach. Then, the o0 approach is developed from the bottom up. Therefore, structured approach and OO approach remain two interdependent and irreplaceable approaches in the system development domain.

1.3.6 Characteristics of the prototype method

It’s called rapid prototyping, or simply prototyping. It is a kind of according to the user’s initial demand, the use of system development tools, quickly establish a system model to show to the user, on this basis and user communication, and finally realize the user needs of information system rapid development method. \n Classified by function implementation: divided into horizontal prototype (behavior prototype, function navigation), vertical prototype (structured prototype, part of the function implementation). . According to the final results, it can be classified into discarding prototype and evolutionary prototype.

• The prototype method can shorten the cycle of system development, reduce the cost and risk, accelerate the speed, and obtain higher comprehensive development benefits.

• Prototype method is user-centered to develop the system, the degree of user participation is greatly improved, the development of the system in line with the needs of users, thus increasing user satisfaction, improve the success rate of system development.

• As users participate in the whole process of system development, it is easy to understand and accept the function and structure of the system, which is conducive to the transfer of the system and the operation and maintenance of the system.

1.3.7 Shortcomings of the prototype method

• The environment for development is demanding.
• The management level is high.

As can be seen from the above analysis, the advantages of the prototype method mainly lie in the more effective confirmation of user needs. Intuitively, prototyping works well for systems where requirements are unclear. In fact, for the analysis level of difficult, technical level is not difficult system, suitable for prototype development.

Strictly speaking, the current prototyping method is not an independent system development method, but a development idea that only supports rapid prototyping of systems in the early stages of system development, and does not specify which method must be used during the prototyping process. Therefore, it is not a methodological system in the complete sense. This means that the prototype method must be used in combination with other information system development methods.

1.3.8 Service-oriented approach

Service Oriented (SO) approach: Further decoupling the definition and implementation of interfaces leads to the emergence of Service and Service Oriented (SO) development approach.

From the perspective of application, the communication and interoperability of various application systems within and between organizations directly affect the organization’s mastery of information and processing speed. How to make the information system respond quickly to the needs and environmental changes, improve the reusability of the system, information resource sharing and interoperability between systems, has become a key issue that affects the efficiency of information construction, and the thinking mode of SO just meets this need.

1.3.9 Jackson (Data structure-oriented) method

A data structure-oriented development method, suitable for small scale projects.

1.3.10 Agile development

For small and medium-sized projects, the main purpose is to reduce the programmer’s burden, eliminate some unnecessary meetings and documents. Refers to a set of models (EXTREME programming, adaptive development, the Crystal approach…) , these models share the same principles and values, as shown below (requires familiarity and mastery of important concepts):

Development manifesto: Individuals and interactions over processes and tools, working software over exhaustive documentation, customer collaboration over contract negotiation, responsiveness to change over adherence to a plan.

A Introduction to important concepts

1. Pair programming: one programmer develops the code while the other programs observe and review the code, which can effectively improve the quality of the code.

2. Adaptive development: Emphasis on the Adaptive development method. Unlike other approaches, which have many specific practices, it focuses on providing the most fundamental basis for the importance of software and on explaining why development methods should be adaptable from a higher organizational and management level.

3. The Crystal approach: Every different project requires a different set of strategies, conventions, and methodologies.

4. Feature-driven development: a set of development models for small – and medium-sized software development projects. Is a rapid, model-driven iterative development process that emphasizes simplicity, utility, ease of adoption by development teams, and is suitable for projects with changing requirements.

5. Extreme Programming XP: The core is communication, simplicity, feedback, and courage. XP doesn’t require developers to document a lot of software early on, knowing that plans never catch up with changes. XP advocates testing first in order to minimize the chance of bugs later on.

6. SCRUM: An iterative scaling process in which each period (30 days) of iteration is called a “sprint” and the product is implemented according to the priority of requirements, with multiple self-organizing and autonomous teams incrementing the product in parallel.

1.3.11 Unified Process (RUP)

Provides a disciplined approach to delegating tasks and responsibilities within a development organization. Its goal is to ensure a high quality product that meets the end user’s needs on a predictable schedule and budget.

A three salient features

Use case driven, architecture centric, iterative, and incremental.

B 4 processes:

1. The initial stage
2. elaboration
3. The build phase and the delivery phase
4. A technical review is scheduled at the end of each phase to determine whether the objectives of the phase have been met.

A common process framework that can be applied to a wide variety of software systems, different application domains, different organizational types, different performance levels, and different project sizes.

1.4 Software Product Line

A software product line is a collection of products that share a common, manageable set of features that meet the specific needs of a specific domain. Software product line is a software development method suitable for professional development organizations, which can effectively improve software productivity and quality, shorten the development time and reduce the total development cost.

Core resources: include the common software architecture, common components, documents, etc.

Product collection: various products in the product line.

How the product line is established

1.5 Reverse Engineering

Software reuse is the use of knowledge about existing software to build new software in order to reduce the cost of software development and maintenance. Software reuse is an important technology to improve software productivity and quality. Early software reuse was primarily code level reuse, and the knowledge being reused was specific to the program. Later, it expanded to include domain knowledge, development experience, design decisions, architecture, requirements, design, code, and documentation.

Reverse engineering: Reverse engineering of software is the process of analyzing programs and trying to establish the representation of programs at a higher level of abstraction than source code. Reverse engineering is the process of restoring design.

1.5.1 Four levels of reverse engineering:

1. Implementation level: including abstract syntax tree, symbol table, process design representation.

2. Structure level: Includes information that reflects the interdependencies between program components, such as call diagrams, structure diagrams, programs, and data structures.

3. Function level: includes information, such as data and control flow models, that reflects the functions of segments and the relationships between segments.

4. Domain level: includes information reflecting the correspondence between program components or program entities and application domain concepts, such as e-R model. Among them, the domain level abstraction level is the highest and the completeness is the lowest, and the implementation level abstraction level is the lowest and the completeness is the highest.

1.5.2 Related Concepts

The concepts associated with reverse engineering are reconstruction, design recovery, reengineering and forward engineering.

• Refactoring refers to transforming the system description at the same level of abstraction.

• Design recovery refers to the abstraction of information about data design, overall structure design and process design from existing programs with tools.

• Reengineering refers to the modification or reconstruction of the existing system based on the information obtained from reverse engineering to produce a new version of the system. Reengineering is a process of redeveloping existing systems, including three steps: reverse engineering, consideration of new requirements and forward engineering. It not only retrieves design information from existing programs, but also uses this information to refactor existing systems to improve their overall quality. When reengineering an existing system, new requirements are usually added, including adding new functions and improving the performance of the system.

• Forward engineering is not only the recovery of design information from existing systems, but also the use of that information to change or reconstruct existing systems to improve their overall quality.

1.6 Software System Tools

Software tools are divided into software process activities

• Software development tools: requirements analysis tools, design tools, coding and troubleshooting tools.

• Software maintenance tools: version control tools, document analysis tools, development information base tools, reverse engineering tools, reengineering tools.

• Software management and software support tools: evaluation and selection of project management tools, configuration management tools, software evaluation tools, software development tools.

2 🌿 Demand engineering

2.1 Software Requirements

User expectations of a system in terms of function, behavior, performance, and design constraints. It refers to the conditions or capabilities required by users to solve problems or achieve goals, the conditions or capabilities required by systems or system components to meet contracts, standards, specifications or other formally specified documents, as well as the documentation reflecting these conditions or capabilities.

It is divided into requirements development and requirements management, as shown below:

2.1.1 Layers of requirements

• Business needs: reflect the high-level goals and requirements of the enterprise or customers on the system, usually from project investors, customers, Marketing Department or product planning department. The project view and scope can be determined by the business requirements.

• User requirements: Describes the specific goals of the user, or the tasks that the user requires the system to accomplish. It describes what users can do with the system. User interviews and questionnaire surveys are usually adopted to sort out user usage scenarios, so as to establish user needs.

• System requirements: Describes software requirements from a system perspective, including functional requirements, non-functional requirements, and design constraints.

1. Functional requirements: Also known as behavioral requirements, define the software functions that developers must implement in the system and that users can use to complete tasks and meet business needs.

2. Non-functional requirements: Attributes or qualities that a system must have, which can be subdivided into software quality attributes (such as maintainability, reliability, efficiency, etc.) and other non-functional requirements.

3. Design constraints: Also known as constraints or supplementary specifications, usually some constraints on the system, such as the database system must be owned by the state intellectual property, must run under UNIX operating systems, etc.

2.1.2 Quality Function Deployment

Quality Function deployment (QFD) is a technology that converts user requirements into software requirements with the aim of maximizing user satisfaction during software engineering. To achieve this, QFD divides software requirements into three categories.

1. Conventional requirements. The more functions or performance users think the system should achieve, the more satisfied the users will be.

2. Expected demand. Users think the system should have functionality or performance, but do not correctly describe the desired functionality or performance requirements. If the expected requirements are not met, users will feel dissatisfied.

3. Unexpected demand. Unexpected requirements, also known as exciting requirements, are features or capabilities that are outside the scope of user requirements (but are usually technical features that software developers are happy to ascribe to a system) that users will be happier if implemented, but that are not implemented and do not affect their purchase decision.

2.2 Obtaining Requirements

It is the process of identifying and understanding the needs and constraints of different stakeholders. Common requirements acquisition methods include:

1. User interviews :1 to 1-3, representative users. Its form includes structured and unstructured two kinds.

2. Questionnaire survey: there are too many users to interview one by one.

3. Sampling: The process of systematically selecting a representative sample set from a population. Number of samples =0.25*(confidence factor/error rate) 2

4. Storyboard: A series of images through which a story is told.

5. Joint Requirements Planning (JRP): Requirements are discussed in organized meetings by bringing together key user representatives, system analysts, and development team representatives.

6. Requirements recording techniques: task cards, scenario descriptions, user stories, Volere white cards.

2.3 Requirement Analysis

A good requirement should have no ambiguity, integrity, consistency, testability, certainty, traceability, correctness, necessity and other characteristics, therefore, the need for analysts to chaotic user requirements and expectations into user requirements, this is the work of requirements analysis.

2.3.1 Task of requirement analysis

1. Draw the system context scope diagram
2. Create user interface prototype battles
3. Analyze the feasibility of requirements
4. Prioritize requirements
5. Model requirements
6. Creating a data dictionary
7. Using QFD (Quality Function Deployment)

2.3.2 Structured requirement analysis

Structural characteristics: : Top-down, step-by-step decomposition, data-oriented.The three models: Functional model (data flow diagram), behavior model (state transition diagram), data model (E-R diagram), and data dictionary.

2.4 Requirement Definition

Software Requirements Specification (SRS): a product of requirements development activities, this document is designed to provide stakeholders and the development team with a common understanding of the system’s initial specifications, which serve as the basis for the entire development effort. SRS is one of the most important documents in the software development process and should not be lacking for any software project of any size and nature.

2.4.1 Requirements definition method

1. Strict definitions, also known as pre-definitions, are based on the basic assumption that all requirements can be pre-defined. Developers and users can communicate accurately and clearly. Using graphics (or text) can fully reflect the final system.

2. The prototype approach, an iterative, circular development approach, is a problem to note: not all requirements can be accurately stated prior to system development. Prototypes provide a means to overcome the communication difficulties that often arise between project stakeholders. Characteristics: A realistic, participatory system model is required. Have the right system development environment. Repetition is fully needed and advocated, and once requirements are identified, a rigorous approach should be followed.

2.5 Requirement Verification

Also known as requirements validation, the purpose is to confirm requirements with users, requirements specification SAS review and test, including two steps:

• Requirements review: formal and informal.
• Requirements testing: Design concept test cases.

After the requirement is verified, the user should sign for confirmation as one of the acceptance criteria. At this time, the requirement specification is the requirement baseline and can not be updated at will. If the requirement needs to be changed, it must go through the requirement change process.

2.6 Requirement Management

2.6.1 Defining the requirement baseline

The requirements statement that passes the review is the requirements baseline, and the next time the requirements need to be changed, the process needs to be followed step by step. The process and status of requirements are shown in the figure below:

2.6.2 Requirement changes and risks

It is mainly concerned with the risk management of requirements in the process of requirements change, with risks such as insufficient user participation, ignoring user classification, increasing user requirements, ambiguous requirements, unnecessary features, too concise SRS, and inaccurate estimates.

The reasons for the change: the change of external environment, the incompleteness of requirements and design, the emergence of new technology, the restructuring of the company caused by the change of business process.

Change Control Board (CCB) : Also known as the configuration control Board, its task is to evaluate and approve proposed changes to configuration items, and to oversee the implementation of approved changes.

2.6.3 Requirement tracing: two-way tracing with two levels, as shown in the figure below:

The forward tracking indicates whether all the original requirements of users have been realized, and the reverse tracking indicates whether all the requirements of users have been realized by the software, no more or less, which can be represented by the original requirements and the use case table (requirement tracking matrix).

If there is a correspondence between the original requirement and the use case, check the corresponding column. If there is no check in any line, the original requirement is not realized, and the problem is found through forward tracking. If there is no checkmark in a column, it indicates that there are redundant function use cases, the software has implemented redundant function, and the problem is found by reverse tracking.

3 🌵 System design

3.1 Process design

3.1.1 Business process modeling

• Benchmarking: take industry-leading benchmarking enterprises as the target, and analyze and model the situation of the enterprise.
• IDEF (a collection of modeling, analysis, and simulation methods)
• DEMO(Organization Dynamic Essence Modeling method)
• Petri net
• Business Process Modeling Language :BPEL, BPML, BPMN, XPDL.
• Service-oriented BPM: Modeling business processes based on the idea of Web services.

3.1.2 Process presentation tools

• Program Flow Diagram (PFD) with some boxes to represent a variety of operations, it is independent of any programming language, more intuitive, clear, easy to learn and master. Any complex program flow chart should be composed of a combination or nest of sequence, selection, and loop structures.

• The IPO diagram is also a process description tool that describes the inputs, outputs, and data processing of each module that makes up a software system.

• N-s diagrams are easy to represent nesting and hierarchical relationships and have strong structural characteristics. But when the problem is very complex, the N-S diagram may be large and therefore not suitable for the design of complex programs.

• Problem Analysis Diagram (PAD) is a graphical tool that supports structured programming. PAD has the advantages of clear logical structure, standardized graphics, and more importantly, it guides designers to use structured programming methods to improve the quality of programs.

3.1.3 Business process reengineering BPR

BPR is a fundamental rethinking and radical redesign of an enterprise’s business processes to achieve significant achievements that can be measured in terms of performance in areas such as cost, quality, service, and speed. BPR design principles, system planning and steps are shown in the figure below:

3.1.4 Business process management BPM

BPM is a systematic approach centered on the standardized construction of end-to-end business processes of excellence with the aim of continuously improving an organization’s business performance.

The fundamental difference between BPM and BPR management thinking is that process management does not require reengineering of all processes. The construction of excellent business process is not process reengineering, but according to the specific situation of the existing process, the design process management of process standardization includes three levels: standard process, optimization process and reengineering process

3.2 System Design

3.2.1 Main Objectives

• Develop a blueprint for the system
• Weigh advantages and disadvantages among various techniques and implementation methods
• Elaborate design, rational use of various resources, and finally delineate the detailed design method of the new system.

3.2.2 method

• Structured design approach,
• Object oriented design approach.

3.2.3 Main Content

• Summary design: also known as the overall structure design of the system, is to allocate the functional requirements of the system to the software module, determine the function and call relationship of each module, and form the module structure diagram of the software, that is, the system structure diagram.

• Detailed design: detailed algorithm design in the module, data structure design in the module, physical design of the database, other design (code, input/output format, user interface), writing detailed design specification, review.

3.2.4 Basic principles of system design

• Abstract;
• From top to bottom, refinement step by step: micro clothing information concealment;
• Module independence (high cohesion, low coupling).

3.2.5 System Design Principles

• Keep the module size moderate; Minimize the depth of the call; Fan in more, fan out less;
• Single entrance, single exit;
• The scope of a module should be within the module;
• Functionality should be predictable.

3.3 Man-machine interface design

3.3.1 Three Principles

1. Put under user control

• Define interactions in a way that does not force the user into unnecessary or undesirable actions;
• Provide flexible interaction;
• Allows user interactions to be interrupted and cancelled;
• Streamlines interactions and allows customized interactions as skill levels increase;
• User isolation of internal technical details;
• The design should allow the user to interact directly with the objects that appear on the screen.

2. Reduce the memory burden of users

• Reduced short-term memory requirements;
• Create meaningful defaults;
• Define intuitive shortcuts;
• The visual layout of the interface should be based on real-world metaphors;
• Reveal information in a progressive manner.

3. Ensure interface consistency.

• Allows the user to put the current task into a meaningful context
• Maintain consistency across the application series
• If past interaction models have established user expectations, don’t change them unless you have a compelling reason to do so.

4 🍔 Test basics

4.1 Test Basis

4.1.1 Test Principles

• Tests should be conducted early and continuously;
• Testing should be avoided by the meta-developer or team;
• When designing the test scheme, not only the input data should be determined, but also the expected output results should be determined according to the system function.
• It contains both valid and reasonable test cases and irrational and invalid test cases.
• Verify that the program does what it should and does what it should not;
• Strictly follow the test plan;
• Properly store test plans and test cases;
• Test cases can be reused or appended to tests.

4.1.2 Dynamic Test type

Program runtime tests, divided into

• Black box testing: functional testing, not knowing the structure of software code, design use cases according to the function, test the software function.
• White box testing: structural testing, clear code flow, design use cases according to code logic, use case coverage.
• Grey box test: there are both black and white boxes.

4.1.3 Static test: Type

When the program is static, the manual review of the code is divided into

• Desk check: Programmers check their programs after they compile them, but before unit testing.
• Code review: Review by a panel of programmers and testers by holding program review meetings.
• Code walkthrough: Also using meetings to review code, but not simply to review the code. Instead, testers provide test cases and programmers play the role of computers, manually running the test cases and reviewing the code logic.

4.1.4 Test Policy

• Bottom up: the test starts from the bottom module, the driver needs to be written, and then begins to merge modules one by one, and finally completes the whole system test. The advantage is early validation of the underlying module.

• Top down: test the whole system first, need to write the pile program, and then step down until the final test of the bottom module. The advantage is the early verification of the main control and judgment points of the system.

• Sandwich: There are both bottom-up and top-down testing methods, including both. Both the advantages of the two, the disadvantages are large testing workload.

4.2 Test Phase

1. Unit testing: Also known as module testing, tests program modules, software components, or classes in OO software (collectively called modules) that can be compiled or assembled independently, based on the detailed software design specification.

2. Integration testing: The purpose is to check the interface relationship between modules and between modules and integrated software, and verify that the integrated software meets the design requirements. Testing is based on the software outline design document.

3. Validation tests: They are used to verify that the functionality, performance, and other features of the software are consistent with user requirements. Depending on the user’s level of participation, it usually includes the following types:

• Internal validation testing: Testing against THE SRS is conducted primarily within the software development organization.
• Alpha testing: User testing in the development environment.
• Beta testing: users test the product in the actual environment, and the product is delivered to users after passing the test.
• Acceptance testing: User-focused pre-delivery testing for SRS. The test object is a complete and integrated computer system. The purpose of acceptance testing is to verify that the software system meets the development technology contract or SRS in a real user’s work environment. The conclusion of the acceptance test is the main basis for the user to determine whether to accept the software. In addition to meeting the access conditions for general testing, it shall be confirmed that the software system under test has passed the system test prior to acceptance testing.

4. System test: test object is a complete, integrated computer system; The purpose of the test is to verify that the completed software configuration items are properly connected to the system and meet the requirements specified in the system/subsystem design document and the software development contract under the real system working environment. Testing is based on user requirements or development contracts.

The main content includes functional test, robustness test, performance test, user interface test, security test, installation and reverse installation test, etc., among which, the most important work is functional test and performance test. Functional test mainly adopts black box test method; Performance testing.

The key indicators include response time, throughput, number of concurrent users, and resource utilization.

5. Configuration item test: The test object is software configuration items. The test purpose is to verify the consistency between software configuration items and SRS. The test is based on SRS. In between, verify that the software configuration item under test has passed the unit and integration tests.

6. Regression test: The purpose of the test is to test the correctness of the changed parts and the conformity of the changed requirements after the software is changed, as well as the original, correct function, performance and other specified requirements of the software without damage.

4.3 Design of Test cases

4.3.1 Black Box Test Cases

Think of the program as a black box, knowing only the input and output, but not the internal code. From this design test cases are divided into the following categories:

1. Equivalence classification: classify all the data according to certain characteristics, and then select one of the data in each category. Design principle of equivalence class test case: design a new test case to cover as many valid equivalence classes that have not been covered as possible. Repeat this step until all valid equivalence classes are covered. Count up a new test case that covers only one invalid equivalence class that has not been covered, and repeat this step until all invalid equivalence classes are covered.

2. Boundary value division: The boundary value of each class is taken as a test case. The boundary value is generally the two ends of the range and the two values outside the range with the smallest interval from the range. For example, the age range is 0-150, the boundary value is 0,150, and the boundary value is -1,151.

3. Miscalculation: There is no set way, empirically speaking, to predict where problems are likely to arise and test them as test cases.

4. Cause-and-effect diagram: A method of deducing causes from an effect. There is no fixed method for analyzing specific results.

4.3.2 White box Test Cases

Know the code logic of the program, according to the code statement of the program, to design the test case covering the branch of the code, the coverage level is divided into the following from the lowest to the highest:

1. Statement override SC: All statements in the logical code must be executed once, the lowest level of override, because executing all statements does not mean executing all conditions.

2. Determination override DC: All true and false branches of the condition of the determination statement in the logic code must be overridden once.

3. Condition override CC: Perform one-pass true and false for each independent condition within each judgment condition.

4. Conditional determination combination coverage CDC: Both determination coverage and conditional coverage are satisfied.

5. Path coverage: All feasible paths in the logical code are covered, with the highest level of coverage.

4.4 debugging

Testing is about finding errors, debugging is about finding the code that’s wrong and why. Debugging requires determining the exact location of errors; Determine the cause of the problem and try to correct it; Regression tests should be performed after correction.

4.4.1 Debugging methods

• Brute force: Also known as the exhaustive method or enumeration method, enumerating all possible methods to try one by one.

• Backtracking: also known as the heuristic method, it searches forward according to the optimal conditions to reach the goal. When it is found that the original choice is not optimal or can not reach the goal, it will take a step back to choose again. This technique is backtracking.

• Deduction: a method of reasoning from the general to the particular, which, in contrast to induction, starts from general premises. The process of arriving at specific statements or individual conclusions.

• Induction: from special to general reasoning method, starting from the problems exposed by the test, collect all correct or incorrect data, analyze the relationship between them, put forward the reason for the hypothetical error, and use these data to prove or refute, so as to find out the error.

4.4.2 Software Metrics

McCabe metric: also known as loop complexity. Assuming that the number of directed edges in a directed graph is m and the number of nodes is N, the loop complexity of this directed graph is m-N +2.

Note that the meanings of m and n should not be confused. The simplest loop can be used to remember this formula. In addition, for a program flow chart, each branch edge (line) is a directed edge, and each statement (statement box) is a vertex.

4.4.3 Two properties of software

• External propertiesAttributes for managers and users that can be directly measured, usually as performance indicators.
• Internal propertiesProperties of a software product, such as reliability, that can only be measured indirectly.

V 🍖 System operation and maintenance

5.1 Legacy System

Refers to any information system that is essentially incapable of modification and evolution to meet new and changing business requirements and usually has the following characteristics:

1. Although the system completes a lot of important business management work in the enterprise, it still cannot fully meet the requirements. – Generally achieve electronic business processing and part of the enterprise management functions, rarely involving business decisions.

2. The system has fallen behind in performance and the technology used is outdated. For example, most mainframe/terminal or minicomputer systems are used, and the software is developed in assembly language or early versions of third-generation programming languages, using file systems rather than databases.

3. It is usually a large software system, has been integrated into the business operation and decision-making management mechanism of the enterprise, the maintenance work is very difficult.

4. Without the use of modern information system construction methods for management and development, there is basically no documentation now, it is difficult to understand.

5.2 System Conversion

System transformation refers to the process in which the new system is developed and put into operation to replace the existing system. Various problems need to be considered to realize the handover with the old system. There are three conversion plans as follows:

1. Direct conversion: the direct replacement of an existing system by a new system, a high risk, suitable for situations where the new system is not complex, or the existing system is no longer usable. The advantage is cost savings.

2. Parallel conversion: the new system and the old system work in parallel — for a period of time, the new system will be replaced after trial operation. If the new system has problems in the trial operation process, the operation of the existing system will not be affected, and the risk is minimal. In the trial operation process, the performance of the new and old systems can be compared, which is suitable for large systems. The disadvantage is that it takes manpower and time resources to control the data conversion between the two systems.

3. Segmented transformation: A set of direct and parallel transformations that divide a large system into multiple subsystems, test each subsystem in turn, and mature each subsystem to convert one subsystem. The same applies to large projects, but it’s more time consuming, and there’s a mix of existing and new systems, interfaces, and so on.

Data transformation and migration: Migrate data from the old database to the new database. In order to reduce the difficulty of migration, it is necessary to preserve the reasonable data structure of the old system in the new system as much as possible. There are also three methods: tool migration before the system switch, manual input before the system switch, and generation after the system switch through the new system.

5.3 Overview of System Maintenance

The maintainability of the system can be defined as how easy it is for maintenance personnel to understand, correct, change and improve the software. Its evaluation indicators are as follows:

1. Analyzability. The ability of a software product to diagnose the causes of defects or failures in software or to identify parts to be modified.
2. Variability. The ability of a software product to enable specified modifications to be implemented, including changes to coding, design, and documentation.
3. Stability. The ability of a software product to avoid unintended results due to software modifications.
4. Testability. The ability of a software product to enable modified software to be recognized.
5. Maintainability compliance. The ability of a software product to comply with standards or conventions related to maintainability.

System maintenance includes hardware maintenance, software maintenance, and data maintenance. The types of software maintenance are as follows:

1. Correctness maintenance: modifications made when bugs are found.
2. Adaptive maintenance: Software modifications and upgrades that are carried out passively as the external environment changes.
3. Improvement maintenance: Based on the users’ initiative to put forward more requirements for the software, the software is modified and more functions are added to make it higher and more perfect than the previous software in function and performance.
4. Preventive maintenance: Make preventive modifications to future bugs.

5.4 Classification of system evaluation

1. Project evaluation: pre-evaluation before system development, analyze whether project development is approved, and make feasibility evaluation.
2. Mid-term evaluation: A stage review of each stage in the middle of the project development. Or the project in the development of a major change, the evaluation of whether to continue.
3. Conclusion evaluation: after the system is put into formal operation, the comprehensive evaluation is carried out on the system to understand whether the system achieves the expected purpose and requirements.

5.5 Indicators of the system evaluation

1. Starting from the components of information system, information system is a system composed of man and machine, so it can be constructed according to the operation effect and user demand (human), system quality and technical conditions (machine) these two clues.
2. Starting from the evaluation object of information system, for the developers, they are concerned about the system quality and technical level; For users, they are concerned about user needs and operation quality, while the external environment of the system is mainly reflected by social benefit indicators.
3. From the point of view of economics, three indicators are established according to the system cost, system benefit and financial indicators.