This is the 25th day of my participation in Gwen Challenge

preface

This paper mainly introduces the system architect – software engineering – software development methods.

Software development methods

This section focuses on software development methods and models

A structured method

  • User needs first
  • Strictly distinguish the work stages, each stage has tasks and results
  • Emphasize the integrity and global nature of the system development process
  • System development process engineering: documentation standardization
  • Top down: Progressive decomposition (refinement)

prototyping

Suitable for development where requirements are not clear (make a simple version and let the user address the deficiencies first) include both throwback prototypes and evolutionary prototypes

Object-oriented approach

The key to better reusability is to establish a comprehensive, reasonable, unified model analysis, design, implementation of three stages: no clear boundaries

A service-oriented approach

SO method has three main levels of abstraction: operation, service, business process SOAD is divided into three levels: basic design (the underlying service component), the structure of the application layer (interface between services and service level agreements), and business organization layer (business process modeling and service process choreographer) modeling: divided into service discovery, service specifications and service implementation stages

Software development model

The waterfall model

Status: A classic model that provides the basic framework for software development. Top-down, like a waterfall, that’s why it’s called waterfall mode. Advantages:

  1. The stages are clearly divided
  2. Emphasis on planning and requirements analysis (a strong product is needed to clean up requirements analysis)
  3. Suitable for product development with stable demand (which is impossible in reality)

Disadvantages:

  1. Single process, irreversible
  2. Risks are revealed late and corrections are limited (too many times when the product is not what it thought it was)
  3. Testing is just one phase and lacks the whole process of testing (so testing needs to intervene in advance and communicate test cases with product development during development)

Evolution model

The development mode is similar to the repeated execution of multiple waterfall models. Each developed function will become the new function of the prototype of the product. After user experience, new optimization points will be proposed.

The spiral model

Spiral mode is a combination of waterfall and evolution, which not only embodies the advantages of both, but also emphasizes risk analysis. The spiral model emphasizes risk analysis, enabling developers and users to understand and react to the risks that arise at each evolutionary layer. Therefore, spiral model is especially suitable for large and complex systems with high risks. For these systems, risk is a potential and non-negligible adverse factor of software development, which may damage the software development process and affect the quality of software products to varying degrees. The goal of reducing software risk is to identify and analyze the risk in time before causing harm, and decide what countermeasures to take, so as to eliminate or reduce the damage of risk.

The spiral model goes through several iterations along the spiral, and the four quadrants in the figure represent the following activities:

  1. Make a plan: determine the software objectives, select the implementation plan, clarify the constraints of project development;
  2. Risk analysis: Analyze and evaluate options, consider how to identify and eliminate risks;
  3. Implementation engineering: software development and validation;
  4. Customer evaluation: evaluate the development work, propose amendments and make next steps.

The spiral model is risk-driven, supports software reuse by emphasizing alternatives and constraints, and helps integrate software quality as a specific goal into product development. However, the screw model also has certain restrictions, which are as follows:

  1. The spiral model emphasizes risk analysis, but it is not easy for many customers to accept, believe and respond to such analysis, so it is often suitable for internal large-scale software development.
  2. There is no point in performing risk analysis if it will significantly affect the profitability of the project, so the spiral model is only suitable for large-scale software projects.
  3. Software developers need to have considerable experience and expertise in risk assessment to accurately analyze risks, or they will incur greater losses

The incremental model

Each increment is delivered as a working product, and the high-risk and important part of the initial delivery is that the interface must be well defined each time, because every new increment breaks the product under development, and if it is poorly designed it becomes a model as it goes along.

Building an assembly model

It is similar to building blocks. In the construction of the assembly model, after defining software functions through demand analysis, the assembly structure of components will be designed, the system will be divided into a set of components, and the relationship between components will be defined. Personally, I think it’s a bit of a microservice. Advantages:

  1. The self-containment of components makes it easier to expand the system
  2. Well-designed components are easier to reuse and reduce software development costs
  3. The granularity of components is smaller than that of the entire system, so development tasks are more flexible and development teams can be divided into several groups to independently develop components in parallel.

You can’t have your cake and eat it, and component assembly models also have obvious disadvantages:

  1. Experienced architects are needed to design components. Poorly designed components are difficult to realize the advantages of components and reduce the reuse degree of component assembly models.
  2. When considering the degree of reuse of software, other aspects, such as performance, are often compromised.
  3. When using components to assemble applications, programmers are required to master components proficiently, which increases the learning cost of developers.
  4. The quality of third-party component libraries will ultimately affect the quality of software, and the quality of third-party component libraries is often beyond the control of the development team.

Unified process (rup)

The initial

The most important task at this point is to define the scope and purpose of the system. In this phase, business modeling and requirements work becomes the focus

  • Define project scope and boundaries
  • Identify key use cases for the system
  • Demonstrate the candidate architecture of the system
  • Estimate project cost and time
  • Assess project risk

elaboration

The developer needs to abstract the logical model of the software and design the architecture of the software. In this stage, the analysis and design work is the most important engineering activity.

  • Analyze the system problem domain
  • Establish the software architecture foundation
  • Eliminate the highest risk elements

build

Developers need to basically build the system into a complete entity, and test and deploy it. In this phase, implementation and testing are the most important activities

  • Develop the remaining artifacts
  • Component assembly and testing

delivery

Software system requirements have been fully mature or transitioned or moved to the next release. In this phase, software systems are inevitably refactored, modified, tested, and deployed.

  • Beta testing
  • Making a release
  • User documentation finalized
  • Confirm the new system
  • Training and adjusting products

Extreme programming (xp)

The main differences between Agile and other methodologies are shorter cycles, earlier feedback, extensive automated testing, reduced communication costs, and close collaboration within the development team.