software engineering

CMM (Capability Maturity Model)
- five levels
  - Initial level (disorganized and chaotic, no clearly defined steps, completion depends on the role of a heroic core character)
  - Repeatable level (establish basic project management processes and practices to track project cost, schedule, and features)
  - Defined level (software processes in both management and engineering aspects have been documented, standardized, and integrated into standard software processes)
  - Managed level (the product quality of the software process is understood and controlled by members of the development organization)
  - Optimal level (received process quality feedback, new concepts, new technologies, continuous improvement)
CMMI (Capability Maturity Model Collection)
- staged model
  - The initial process is unpredictable and lacks control
  - The managed process serves the project
  - The defined process serves the organization
  - Quantitative management process is measured and controlled
  - Optimized focus on process improvement
- continuous model
  - Incomplete process areas were not executed or did not receive
  - Executed identifiable input work products transformed into outputs
  - Institutionalization of Managed Centralized Managed Processes
  - Centralized defined process institutionalization at defined levels
  - Institutionalization of Quantitatively Manageable Processes for Quantitative Management
  - Optimization uses quantitative means to change and optimize the process area
software process model
- Structural framework for all processes, activities and tasks of software development
- waterfall model
  - Requirements analysis, design, coding, testing, operation and maintenance
  - The fixed order of interconnection from front to back, at a certain stage, you don’t need to care about the previous stages, and if you have to, you need to look back and the cost is very high
  - Advantages: easy to understand, low management cost, emphasizing the phased early planning of development, demand investigation and product testing
  - Disadvantages: Customers must fully and clearly express their needs, and they need to demonstrate before the end of the project. Problems in the early stage can only be found later, and the risk control ability is weak
- The V-model is a variant of the waterfall model that describes the relationship between quality assurance activities and communication, modeling-related activities, and early build-related activities
  - Provides a method for applying verification validation activities to early software engineering work. There are a series of tests
- incremental mode
  - Segment requirements into a series of incremental products, each of which can be developed separately
  - The first increment is often the core product 1.0, and new functions 2.0 3.0 will be added in the future
  - Advantages: With all the advantages of the waterfall model, the cost and time required for the first deliverable version are very small; the risk is small; the change of user requirements is reduced
  - Disadvantages: no planning for user's change requirements, unstable for later increments; unlike early thought stability, some increments may need to be redeveloped; may exceed organizational capabilities
- Evolutionary Models (Prototype Model and Spiral Model)
  - It is an iterative process model that enables software developers to gradually develop more complete software versions. Applicable when there is a lack of accurate knowledge of software requirements
  - prototype model
    - It is more suitable for situations where user requirements are unclear and needs to change frequently. It is not suitable for large-scale software.
    - The purpose is to build prototypes quickly and at low cost, quickly show users a system framework, and put forward requirements
    - Communication = "Quick Planning =" Rapid Design Modeling = "Building Prototypes =" Deployment Delivery and Feedback
  - Spiral model added to risk analysis
    - Applicable to large, complex and high-risk systems; support dynamic changes in user needs
    - Requires extensive evaluation experience and expertise from developers, excessive number of iterations increases cost, delays submission time
    - The four steps of the spiral cycle
      - Make a plan: determine the goals of the software, select an implementation plan, and clarify the constraints of project development
      - Risk Analysis: Analyze the selected options, identify risks, and eliminate risks
      - Implementation engineering: implement software development, verify phased products
      - User evaluation: Evaluate the development work, propose revision suggestions, and establish a development plan for the next cycle
  - fountain model
    - Driven by user needs and driven by objects, it is suitable for object-oriented development methods
    - The development process is iterative (often repeated many times) and seamless (no sharp boundaries)
    - Allow development activities to intersect and iteratively
    - Advantages: Improve the development efficiency of software projects and save development time. Disadvantages: It requires a large number of personnel, which is not conducive to project management, requires strict management of documents, and makes auditing more difficult
Unified Process (UP) Model
- Use-case and stake-driven, architecture-centric, iterative (5 core workflows) and incremental development process, supported by UML methodologies and tools
- Pocket projects: planning, analysis and design, construction, integration and testing, and internal and external releases
- 4 technical stages
  - Initiation Phase: Lifecycle Goals
  - Elaboration Phase: Lifecycle Architecture
  - Construction Phase: Initial Functionality
  - Handover Phase: Product Release
- A typical representative of the unified process is RUP. RUP is a commercial extension of UP, fully compatible with UP, but more complete and detailed than UP
agile method
- Continually deliver valuable software as early as possible Satisfy customers Each approach is based on a set of principles (Agile Manifesto)
- Extreme Programming XP
  - 4 parts: Values, Principles, Practices and Behaviors
- Crystal method Crystal
  - Crystal Legal requires a different set of strategies, conventions and methodologies for each different project
- Parallel quest method Scrum
  - Call every 30-day iteration a sprint
- Adaptive Software Development ASD
- Agile Unified Process AUP
  - Use the principle of continuous large-scale and iterative small-scale to build software systems
  - Iterative execution activities: modeling, implementation, testing, deployment, configuration and project management, environment management
Software Requirements
system design
- The result of system design is a series of system design documents, which is an important basis for realizing information system
- Outline Design Phase
  - Design software system structure: Divide a complex system into modules according to function: determine the function of each module; call the calling relationship between modules; determine the interface between modules and the information transmitted between modules; evaluate the quality of module structure . It is a key step in the outline design and directly affects the work of detailed design and coding in the next stage
  - Data Structures and Database Design Database Design: Conceptual, Logical, Physical Design
  - Write summary design documents: documents include summary design specifications, database design books, user manuals, and modified test plans
  - Review: Realize the functions and performance specified in the requirements, the feasibility of the design method, and review the correctness of the internal and external interface definitions
- detailed design
  - Detailed algorithm design for each module
  - Design the data structure in the module
  - Physical design of the database means determining the physical structure of the database
  - Other Design: Code Design Input/Output Format Design User Interface Design
  - Write a detailed design specification
  - Review: review both the processing algorithm and the physical structure of the database
System test
- Meaning: The process of executing a program in order to find bugs, a successful test discovers hitherto undiscovered bugs
- Purpose: Hope to find potential errors and defects with the least amount of manpower and time. Generally, software testing
- The key step to ensure the quality and reliability of the system, the final review of the system analysis system design follows the following principles
  - Test early and constantly
  - The testing work should be carried out by specialized personnel, which will be more objective and effective
  - When designing a test plan, comparing the actual output results with the expected results can reveal whether the test object is correct
  - When designing test cases, both reasonable and unreasonable ones must be entered into the test
  - When testing a program, check for redundant work
  - Strictly follow the test plan
  - Properly save the test plan and test cases as an integral part of the software documentation to facilitate maintenance
  - Test cases are carefully designed to facilitate retesting or additional testing
  - The test objectives of the system testing phase come from the requirement analysis phase
software test
- Unit testing (module testing)
  - White-box testing can be performed after the module is written and there are no compilation errors
  - Test content: The unit test mainly checks the following five characteristics of the module
    - Module interface: ensure that the data flow of the test module flows in and out correctly
    - local data structure
      - Whether the description of the variable is appropriate
      - Whether to use unassigned or uninitialized variables
      - Whether the initial value or default value of the variable is correct
      - Is the variable name wrong?
    - Important Execution Path
    - error handling
    - Boundary conditions
  - unit testing process
    - Modules do not run independently, and there is a call-to-call relationship between modules. When testing modules, two modules need to be developed
      - Driver module: Receive the data of the test example, send it to the test module, and output the test result
      - Stub module: A small amount of data processing can be performed internally, the purpose is to check the entry, output call and return information
- Integration Testing
  - Top-Down Integration Testing
    - An incremental method for constructing software architecture; the top is the driver module (main control module), which is replaced by a stub module (abstract to concrete), and gradually descends in a depth- or breadth-first manner.
    - No need to write a driver module, you need to write a stub module
  - Bottom-up integration testing
    - No need to write stub module, need to write driver module
    - Connect the stub module at the bottom to become a cluster; write the driver module; test the cluster; remove the driver module and continue to connect to the cluster
  - Regression Testing
    - Re-execute some subset of what has already been done, to ensure that changes do not propagate undesired side effects
    - Ensure that changes do not introduce unintentional behavior or additional errors
  - smoke test
- confirmation test
- System test
Test Methods
- Static tests: do not run on the machine
  - manual detection
  - Computer Aided Static Analysis
- Dynamic Testing
  - black box testing
    - Equivalence class division: valid equivalence class 50 and invalid equivalence class 101 0-100
    - Boundary value analysis: 0-100 input 0 -1 100 101
    - Miscalculation: Based on feeling
    - Cause and Effect Diagram Converted to Decision Table
    - ps: When both inputs are unreasonable, it is an unreasonable test case
    - McCabe measure
      - The formula for the number of loops: V(g)=m-n+2 m is the directed arc in G and n is the number of nodes or the closed area+1
  - white box testing
    - Principle: All independent paths are executed at least once; both cases of true or false can be executed at least once; loops are executed once at the boundary and general conditions; test the validity of the internal data structure of the program
    - logic coverage
      - statement coverage
        
        Selecting enough test data so that each statement in the program under test is executed at least once is weak logical coverage
      - Decision coverage (branch coverage)
        
        Both the true branch and the false branch must be executed once
      - condition coverage
        
        Each possible value of each logical condition in each statement is satisfied at least once (the true and false value of each condition in the judgment statement must be)
      - Judgment/Condition Override
        
        Combination of the above two
      - Condition combination coverage
        
        All combinations of possible values for the decision condition occur at least once
      - path coverage
        
        Strong logical coverage covering all possible paths in the program under test
    - Loop coverage: Enough test cases are executed such that every condition in the loop is verified
    - basic path test
System Maintenance Overview
- Software maintenance is the last phase of the software life cycle and is not part of the system development process
- system maintainability concept
  - How easy it is for maintainers to understand, correct, change, and improve the software.
  - maintainability index
    - Understandability, testability, modifiability
  - Hardware maintenance, software maintenance, data maintenance
- Software maintenance
  - Documentation is a determinant of software maintainability and is very important
  - The maintenance period is usually much longer than the development, and the investment is also more
  - Maintainability is a characteristic that every software should have. It is necessary to ensure that the software is maintainable during the development stage, and each stage should consider improving maintainability
  - Conducting quality assurance reviews can improve the maintainability of software products, an important characteristic for measuring software quality
  - maintenance content
    - Correctness maintenance: Correct errors 17-21%
    - Adaptive maintenance: 18-25% of modifications to adapt to changes in information technology and management needs
    - Perfection maintenance: 50-60% of modifications are made to expand functions and improve performance
    - Preventive Maintenance: Proactively add preventative new features 4%
- software documentation
  - Documentation is also a part of software products, and software without documentation cannot be called software
  - Writing high-quality documentation improves the quality of software development
  - The preparation of software documentation accounts for a prominent address and a considerable workload in software development work
  - High-quality documentation is of great significance to the benefits of software products
  - In general, the software documentation has to be good, and the option to say that the software documentation is not good is wrong
- quality attributes of software
- communication path
  - Master programmer: n-1 No master programmer: n(n-1)/2
Software Project Estimation
- COCOMO model: is an accurate and easy-to-use cost estimation model
  - The base COCOMO model is a static univariate model
  - Intermediate COCOMO models are static multivariate models, divided into systems and components
  - Detailed COCOMO model, divided into systems, subsystems and modules
- COCOMOII model (selection for size estimation)
  - Apply Assembly Model (Object Point)
  - Early Design Phase Models (Function Points)
  - Architecture Phase Model (Line of Code)
schedule management
- Gantt chart (Gantt chart)
  - Clearly describe when each task starts and where it ends, the progress of the task, and the parallelism between each task
  - Cannot clearly reflect the dependencies between tasks, it is difficult to determine the key points of the project, and it cannot reflect the potential part of the plan
- PERT Chart (Project Plan Review Technical Chart)
  - Directed graph, the arrow indicates the task, and the time required for the task can be marked; it cannot reflect the parallel relationship of the task, and can rely on
  - The task that flows into the node is the end, the task that flows out of the node is the start, and the node is the event; only when it is over can it start
  - Start node: there is no task pointing to it, the earliest time is 0, there can be multiple,
  - End node: There is no task pointing out, the latest time is the same day as the earliest time, and there is only one
  - Earliest time: It is impossible to start the task at this time before this time. The earliest time of the previous one plus the task time is the earliest time. If there are more than one, take the earliest time of the maximum value.
  - The latest time: the departure task starts at this time at the latest, otherwise the project cannot be completed as scheduled; the previous latest time subtracts the task time, and when multiple minimum values are encountered
  - Slack time = the latest moment - the earliest moment, and multiple items should be calculated separately
  - Critical path: the path whose slack time is 0
- Project Activity Diagram
  - The vertices are project milestones, the edges connecting the vertices represent activities, and the values on the edges represent the time required to complete the activities
  - The length of the critical path is equal to the latest moment of the ending vertex
Software Configuration Management
- Configuration database: development repository, controlled repository, production repository
Software Risk Management
- uncertainty and loss
  - Project risk: Threat to the project plan, uncertain project complexity, size and structure also belong to
  - Technical risk: Threats to the quality and delivery time of the developed software. The reason is that the problem is more difficult to solve than we think
  - Business risk: Threats to the viability of developing software and often jeopardizes the project or product; five project risks: marketing, strategy, sales, management, budget
- Risk Identification
  - Systematically point out the threats to the project plan (estimation, schedule, resource allocation, etc.), avoid them as much as possible after identification, and control the risks. If it is impossible to avoid them completely, avoid them if you can. If it is impossible, you can only intervene to reduce risks
  - The Risk Entry Checklist identifies the following types of risks:
  - Risk factors include performance, cost, support and schedule
- Risk Prediction (Risk Estimation): Assess risk in terms of both risk probability and consequence; build risk table severity high to low 1 2 3 4
  - Assess risk impact: The nature, scope, and timing of the risk will affect the consequences of the risk
  - Risk Exposure RE=P*CP Probability C Consequence
- risk assessment
  - Techniques useful for risk assessment Define risk reference levels (cost, schedule, performance are typical risk reference levels) triplets (risk, probability, consequence)
- risk control
  - Assist the project team in establishing strategies to deal with risks;
  - The best way to deal with risk is to actively avoid it;
  - Risk monitoring: Project managers monitor certain factors
  - RMMM plan (Risk Management Strategy): can be included in the software project plan; try to find the origin
software quality
- ISO/IEC9126 software model: the first layer of quality characteristics, the second layer of quality sub-characteristics, and the third layer of metrics

Please add a picture description

Mc Call software quality model:
software review
- The specification of the design meets the requirements of the user is called design quality
  - Evaluate whether the software specifications meet the user's requirements
  - Reliability: Whether it is possible to avoid failures caused by input abnormalities, one failure and software failure
  - Review software for reusability, testability, modifiability, scalability, interchangeability, and portability
  - Review performance, security measures, implementation of operational features
- The correct execution of the program according to the design specification is called the program quality
  - Review activities based on the structure of the software itself, the interface of the operating environment, and the impact of changes
  - Structure: functional structure, generality of functions, hierarchy of modules (static), module structure, structure of processing
    - Module structure: direct correspondence between control class structure, data flow structure, module structure and function structure
  - and the structure of the operating environment
    - Interface with hardware, interface with user
  - The goal of a formal technical review is to find bugs in the software
Software Fault Tolerance Technology
- The main means to achieve fault tolerance is redundancy: structural redundancy (static dynamic redundancy, hybrid redundancy), information redundancy, time redundancy, and redundant additional technology
software tools
- Software used to assist activities in the process of software development, operation, maintenance, management and support
- software development tools
  - Requirements analysis tools, design tools, coding and debugging tools, testing tools
- Software Maintenance Tool
  - Version control tools, document analysis tools, development repository tools, reverse engineering tools, reengineering tools
expand
- Object-oriented methods include: Booch method, Coad method, OMT method
- Software Complexity Metrics: Size, Structure, Difficulty, Intelligence
- Basic elements of software engineering: methods, tools, processes

Software Designer (Software Engineering)

software engineering

Guess you like