Home > Industries > Software
1. Software Engineering: To study a framework that contains a series of methods and tools, and to study Theories, Methods, and tools in the Process of Software Generation, development, application, and maintenance.
2. Software
L a set of commands. By executing these commands, you can meet the expected features, functions, and performance requirements.
L data structure, allowing the program to make full use of information
L documents describing program operations and usage
3. Legacy Software
L adjustment to meet the needs of new computing environments or technologies
L improvement to meet new business needs
L extension enables it to interact with other more modern systems or databases
L re-architecture makes it feasible in the new network environment
Process OverviewQuality focus (Purpose)-process (constraints, Framework)-method (guidance, assurance)-tool (means)
Communication-planning-modeling (Demand Analysis and Design)-Building (coding and testing)-deployment
L as a continuous model, each process domain is strictly evaluated based on specific objectives and practice requirements
L as a stage model, define five maturity levels to achieve the desired level.
A template is provided to describe the consistency of important features in the software process.
Process ModelCommunication-planning-modeling-building-deployment
The first increment is usually a core product that meets basic requirements.
Is a high-speed variant of the waterfall model, focusing on the incremental software process model for a short development cycle
The prototype serves the definition requirement.
5. Evolutionary Process Model-spiral model
Prototype iteration + systematic and controllable waterfall model. Gradually deepen system definition and implementation in a circular manner while reducing risks, and identify a series of milestones to ensure that all stakeholders support solutions
Defines a series of events that trigger state conversion of Se activities, actions, or tasks.
7. Dedicated Process Model
Component-based development-commercialized finished software components. Formal method model-generate a mathematical specification for the formal computer software. AOSD oriented software development.
A Case-driven, architecture-oriented, iterative and incremental software process. Starting from-refining-building-transformation-Production
Agile DevelopmentL customer satisfaction and early release of software
L small and highly independent project team
L informal methods
L minimal software engineering products and overall simplified development
L effective response to changes
L effective communication between stakeholders
L pull customers into the team
L organize a team for the current tasks
L driven by customer requirements
L identifying a plan is short-term
L iterative software development with emphasis on building behavior
L delivery of multiple software increments
L adapt to changes at any time
4. Extreme Programming
L XP Planning
L XP Design
L XP Programming
L XP Testing
L thinking-start the software project and complete the adaptive loop plan
L collaboration-collaboration, trust
L learning-when developing components, focus on learning as many things as possible to complete the loop
L Feasibility Study
L Business Research
L function model Iteration
L design and component Iteration
L Implementation
L emphasize defining features (features are the release functions of small pieces that users can easily describe)
L create a feature list and execute a feature-oriented plan
L design and construction are integrated in FDD
System Engineering1. Elements of a computer-based system
L Software
L hardware
L people
L Database
L documentation
L procedures
2. System Architecture
L data architecture: provides a framework for information requirements of business or business functions
L application architecture: contains system elements that are converted within the scope of the data architecture for certain business purposes
L technical infrastructure: providing the foundation for data architecture and application architecture
Demand EngineeringStart-export-refinement-negotiation-Specification Description-confirmation-requirement Management
Build Analysis Model Requirement AnalysisL specification for generating software Operation Features
L Interface specifying software and other system elements
L constraints that must be met to establish software
Domain AnalysisIdentifies, analyzes, and details public requirements from a specific application field, especially those that are repeatedly used by multiple projects in the application field.
L define the fields to be analyzed
L collect representative samples of applications in this field
L each application in the analysis sample
L development and analysis models for objects
Data ModelingL process-independent data object check
L focus on the data field
L create a model at the abstract level of the customer
L shows how data objects are correlated.
Data ObjectRepresentation of almost any compound information that must be understood by the software. Composite information refers to things with different features or attributes.
L each instance of the object must be uniquely identified
L each data object is indispensable in the system, that is, the system functions of the Instance cannot be implemented without accessing the object.
L each data object is described by attributes in the form of data items
LinkL a fact that must be remembered by the system and cannot be calculated or deduced
L multiple instances with one link
L objects can be associated in multiple ways
CRC modelResponsibilities: Class encapsulation attributes and operations (what the class knows or can do)
Collaboration: classes that provide the information required to fulfill a specific role (collaboration means information requests or action requests)
Entity class: Model and business class, which are directly extracted from the Problem description. These classes generally represent the things stored in the database and throughout the application.
Border class: this class is used to create user-visible and interactive interfaces. It is designed to manage different ways for object objects to users.
Control class: manages work units, including creating and updating object classes.
System statusL state-a group of observed features describing system behavior at a given time
L state transition-transfer from one State to another
L event-causes the system to show predictable behavior patterns
L action-the process of status transfer results
Guiding principles of Design Engineering QualityL The design should display the following data structures: (a recognizable architecture or pattern has been used for creation, which consists of components displaying good design features and can be implemented in an evolutionary manner)
L design should be modeled
L The design should contain clear representation of data, architecture, interfaces and components
L design the data structure to be exported, which is applicable to the classes to be implemented
L components that display independent functional features should be exported in the Design
L design export interfaces that reduce the complexity of connecting components and components to the external environment
L design export should be carried out according to the information obtained during the software requirement analysis using reusable methods
Basic ConceptsL abstraction-process abstraction and data abstraction
L architecture-overall software structure
L model-essential expression of a verified Solution
L modularization-data and function division
L hide-each module hides its own design decisions from all other modules
L independent functions-specific functions and low coupling
L refinement-Gradually refine all abstractions
L restructuring-a re-organization technique that simplifies component design or code without changing its functions and Behavior
Software StructureL structure model-an organized set of architecture Components
L framework model-can improve the design Abstraction Level
L Dynamic Model-focuses on the behavior of the program architecture, specifying how the structure or system configuration will change as a function of external events
L Process Model-focuses on the business design or technical process design required by the system
L functional model-can be used to represent the functional hierarchy of the system
Message hidingL it is unlikely that errors will be inadvertently introduced and transmitted to other parts of the software.
L limits the global impact of local design decisions
L emphasize interaction through control Interfaces
L global data is not encouraged
L leads to encapsulation-a property of high-quality design
L in order to design high-quality software
ReconstructionA reorganizing technique that simplifies the design or code of components without changing their functions and actions.
During refactoring, you need to check the following aspects:
L Redundancy
L unused design elements
L inefficient or unnecessary design algorithms
L poor or inappropriate Data Structure
L and other design deficiencies, which cannot be modified to achieve better design
Design Pattern ElementsL data design elements (data structure and database architecture)
L architecture design elements (application domains, analysis classes, models, and types)
L Interface Design Elements (user interface, external interface with other system equipment, internal interface between various design components)
L component-level design elements
L deployment-level design elements
Architecture DesignArchitecture is an expression that enables software engineers
L effectiveness of analysis design in meeting the specified demand
L when design changes are relatively easy, consider the possible architecture Selection Scheme
L reduce risks associated with software structures
Architecture StyleL data-centric Architecture
L data stream architecture
L call return Architecture
L object-oriented Architecture
L Hierarchical Architecture
Architecture ModelL concurrency-many application systems must operate multiple tasks in a simulated parallel manner.
L persistence-if the data has existed since the execution of the process that created it, the data is persistent.
L distribution-the way in which system or system components communicate with each other in a distributed environment (inter-entity connection mode and inter-entity Communication)
Component-level designComponent: a fixed, configurable, and replaceable component in the system. This component encapsulates implementation and exposes a series of interfaces.
Design principlesL switch principle: the module should be open to extension and closed to Modification
L replacement principle: subclasses can replace their base classes.
L Dependency inversion principle: dependent on abstraction rather than concrete implementation
L Interface separation principle: multiple user-specific interfaces are better than one common interface.
L Equivalence Principle of release reuse: the granularity of reuse is the granularity of release.
L principle of joint encapsulation: Classes changed together should be combined
L principle of joint reuse: classes that cannot be reused together cannot be grouped into a group.
CohesionThe integrity of the component means that the component or class only encapsulates attributes and operations that are closely related to the component or class itself.
L function cohesion
L hierarchical cohesion
L Communication cohesion
L sequential cohesion
L process cohesion
L temporary cohesion
L practical cohesion
CouplingA qualitative measurement of the degree of interconnectivity between classes
L content Coupling
L shared Coupling
L control coupling
L mark Coupling
L data Coupling
L routine call Coupling
L Type Coupling
L include or import Coupling
L external Coupling
Software testing strategyTesting is a process in which the end user is delivered to drill the program with a specific intent of looking for errors.
Policy:
L unit test: test interface, local data structure, boundary condition, independent path, and error handling path
L integration testing: One-step incremental integration
L validation test
L System Test
OOT PolicyClass testing is equivalent to unit testing (testing class internal operations, checking class state behaviors)
Three different policy integration tests:
L thread-based testing-a set of classes required for an input or event of the Integrated Response System
L use-based testing-integration responds to a group of classes required for a use case
L cluster test-integration displays a group of classes required for collaboration
Smoke testA common integration method is a step-by-step mechanism for time-critical projects, allowing software teams to Frequently evaluate projects.
L integrate software components that have been converted into code into a build
L design a series of tests to expose errors that affect build's correct completion of its functions
L The build is integrated with other builds and the entire software product for Smoke Testing every day
Debugging strategy: brute force, backtracking, and reason exclusion
Testing tactical TestabilityL operability-the better the running, the more effective the test
L observability-what you see is what you test
L controllability-the better the software control, the more automatically the test can be executed and reproduced.
L destructibility-by controlling the scope of the test, the problem can be decomposed faster and the retest can be completed more smartly.
L simplicity-simplify testing by reducing complex architectures and logic
L stability-fewer changes, less damage to testing
L comprehension-understanding of Design
White box testingComputing ring complexity: the number of simple decisions + 1 or the number of closed areas + 1. The higher the complexity of the ring, the higher the possibility of errors
Project management factorsL personnel-the most important factor in a successful project
L product-software to be constructed
L process-to complete a set of framework activities and software engineering tasks for Software Construction
L project-all work required to implement the product
MoI ModelL incentive-the ability to encourage technicians to maximize their talents through pushing or pulling
L organization-ability to form an existing process that converts initial concepts into final products
L thinking and innovation-even if you must work under the constraints of a specific software product or application, it can encourage people to create and make people feel creative.
Organization ModelL closed model-organize teams at the traditional right level
L random model-the team is loosely organized and the team work depends on the individual initiative of the team members.
L open model-an innovative way to organize a team with both closed and random model control
L synchronous model-depending on the natural division of the problem, the team members of the organization solve a part of the problem and there is no active communication between them.
Process and project measurement process measurementL quality-Focus on measurement of work products and deliverables
L productivity-production of work products related to the amount of work consumed
L statistical software quality assurance data-error classification and analysis
L defects compromise efficiency-errors in the process are transmitted from one behavior to another
L data reuse-number of components produced and their degree of reuse
Project MeasurementReduce development time by making necessary adjustments to avoid delays and mitigate potential problems and risks
L input-metrics of resources required for job completion
L outputs-measurements of deliverables or work products created during Software Engineering
L result-a measurement can indicate the deliverables.
Scale-oriented MeasurementL number of errors per thousand lines of code
L number of defects per thousand lines of code
L cost per thousand lines of code
L Number of documents per thousand lines of code
L number of errors per month
L number of errors per inspection hour
L thousands of code lines per person per month
L document cost per page
Function-oriented MeasurementL number of errors for each function point
L number of defects per function point
L cost of each function point
L number of document pages for each function point
L number of function points per month
Object-oriented MeasurementL number of scenario scripts (Use Cases)
L number of key classes and core of the problem domain
L number of supported classes (which is required by the implementation system but not directly related to the problem domain)
L average number of support classes for each key class (analysis class)
L number of subsystems. A subsystem is a set of classes that implement a function.
Measurement qualityL correctness-degree of functionality required by the program
L maintainability-the degree to which the program can be modified when an error occurs, and the degree to which the program can adapt when the environment changes
L integrity-measure a system's ability to defend against security attacks
L availability-ease of use of Programs
Defect elimination rate: it is better to set the defect elimination rate to a value close to 1 by using the algorithm.
E-number of errors discovered before the software is delivered to the end user, and number of defects discovered after the D-software is delivered to the end user
Software Project EstimationThe overall goal of a project plan is to control, track and monitor a complex technical project and establish a practical strategy.
Estimation TechnologyL past similar project experience
L Traditional Estimation Technology (Task breakdown, workload estimation, and scale estimation)
L empirical model
L automatic tools
Project schedule PrincipleL division-projects must be divided into multiple manageable activities
L dependency-define dependencies between tasks
L time allocation-each task with a schedule must be assigned a certain number of work units
L workload Validation-each project is attended by a scheduled person
L confirm responsibility-specific members should be specified for each task with a schedule
L clear results-each task with a schedule should have a clear output result
L determine milestones-each task or task group should be associated with a project milestone
Risk Management Risk IdentificationL product scale-risks related to the overall scale of the software to be developed or modified
L commercial impact-risks related to the constraints imposed by managers or the market
L customer characteristics-risks related to customer quality and the ability of developers and customers to communicate regularly
L process definition-risks related to the degree of software engineering definition and the degree to which the process is observed by the Development Organization
L development environment-risks related to the availability and quality of tools used for product development
L development technology-risks related to the complexity of the software to be developed and the novelty of the technologies included in the System
L personnel skills and experience-risks related to the overall technical level and project experience of software engineers
Risk FactorsL performance risk-the degree of uncertainty that the product can meet its needs and meet its purpose
L cost risk-can maintain the uncertainty of the project budget
L support risks-uncertainty in the development of software that is easy to correct, modify, and upgrade
L progress risk-the uncertainty of the product that maintains the project progress and delivers the product on time
Quality ManagementSoftware Quality: Compliance with clearly stated functional and performance requirements, clear records of development standards, and the expected recessive characteristics of all professionally developed software
Software Reliability: simple measurement of reliability and average failure interval.
Software availability: the efficiency at which a program can run at a given point in time as required.
Change managementBaseline)
Specifications or products that have been officially reviewed and approved can be used as the basis for further development and can be changed only through formal change control procedures
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
