Part III technical process specification
In this specification, the entire technical process of software development is divided into five sequential workflows, respectively, of demand, analysis, design, implementation, and testing. During an iterative process, these five workflows are overall, but there is cross and overlap between each other. 9 demand
9.1 Management Demand Enforcement Role System Analyst Event Description Collect user needs by interviewing, questionnaire, review contract, etc.; collecting results in informal forms such as informal form, ensuring no need to repeat, inconsistency, unclear; * For demand Change request, the change request at this time should have passed the change control and the project review committee, which can be directly used as a formal demand; establish a traceable link between model elements and needs; establish demand attributes; product demand; 9.2 look Participants and Use Accurators Execute Role System Analyst Event Description Named and Briefly describe the protagonist discovered; named and briefly describe the discovered use case, outline the event stream and collect non-functional demand (recorded in "Supplemental Demand); Model (describe the relationship between the use case and package participants and use cases); product use case model (summary); "Supplemental Demand"; 9.3 Arrangement Example Priority Sequential Executive Role Architecture Designer Event Description General According to the importance of use case, risk Determining the use case priority; the priority can be represented by the number indicating that the use case is implemented in that iteration; the priority can also be represented by a key, important, auxiliary level; product use case model (updated); 9.4 Detailed description Role Use Example Engineer Activity Description Modeling An Example of Activity With Other Use Cases, Use Examples and Participants; Detailed Description Event Flow; Product Use Example (Detailed); "SRS"; 9.5 Protocol User Interface Enforcement Role User Interface Designer Event Describe the use of various interface elements to form a user interface origin; product user interface origin; 9.6 Organizer model model Execute a role system analyst activity Description Description Example of relationship (including, extended, generalized), optimized the use case model; product usage model (structure) -...9.7 Recurrently 9.8 Trial Demand Executive Role Review Review Activity Description The official verification needs Results in line with the customer's views on the system, it is recommended to hold a review meeting, review the following: affect the change request of existing requirements; Use case and its chart review (suitable for each use case); product "review record"; 10 analysis
10.1 Architecture Executive Role Software Designer Event Description Writing Software Overview, adopt a large number of informal forms of a large number of pictures, dedicated panels, or icon graphics to outline the frame, which is usually only carried out in the early stage of the project; High-level organizations, usually focus on two high-level levels in architecture analysis, namely, application layers, and business dedicated layers; formation of analyzing packages in accordance with this hierarchy, and assign some of the close contacts to a specific package, then implement it in the package The corresponding function, determine the service package, the analysis class in the same service package is used for the same service; determine the obvious entity class; determine special needs, such as distribution and concurrent, permanent mechanism, security mechanism, etc. Summary); physical classes (summary); analysis model; 10.2 use case analysis Enforcement role use case engineer activity Description Determines boundary class, physical classes, and control classes; determine a major boundary for each participant acting as a person or other system Class; collecting the analysis class participating in an exemplary implementation to a class diagram; describing interactions between analytical classes (mainly using collaboration map implementation); determine all requirements (non-functional requirements) of each use case; product analysis class (Summary); use case implementation - analysis; 10.3 Formation Analysis Executive Role Designer Event Description Determining the duties of the analysis class, can be represented by the members of the class, but only conceptual; determine the properties of the analysis class, you can use The member variable of the class is expressed, but it is only conceptual; determines the relationship between the analysis class; determine the specific needs of the analysis class; product analysis (complete) 10.4 Formation analysis package enforcement role description activities describe the correlation The analysis class is packaged into an analytical package; the package should follow the principle of high polymerization and low coupling; the product analysis package (complete) 10.5 analysis 50.6 does not require formal review, but should check the analytical process to inspect the implementation role recommendation Architecture designer performs an activity description inspection or review analysis, analysis package, use case implementation - analysis, analysis model; product no 11 design
11.1 Architecture Design Enforcement Role Software Designer Event Description Identification Node and Network Configuration, map these elements to the implementation model; identify subsystems and their interfaces (generally a subsystem mapped to one analysis package, the subsystem corresponds to an executable Component); Identify the class with important meaning of the architecture (do not design details, the number is not too much), identify the active class (process and thread), consider concurrency requirements, distribute these active classes to specific nodes; product subsystem ( Summary); interface (summary); design class (summary); implement model (summary); architectural description (design model and implementation model view); 11.2 Case Design Enforcement Role Example Engineer Activity Description Identification Design Class, Use Class The figure shows the class participating in a certain type of class; describes the interaction between the design object (can be used to indicate the inter-phase interaction); the participating subsystem and interface; describe the interaction between subsystems (with a sequence diagram); Capture real demand (non-functional demand); product subsystem (summary); interface (summary); design class (summary); use case implementation - design; 11.3 Forming design class executive role designer activity Description According to analysis Or interface to sketch a design class: border class à user interface class; physical class à database management class; control class à one or set class; identification operation (tracking analysis class responsibilities, analytical non-functional demand and interface) Identify attributes; the relationship between the identification class; describes the method, in particular, the complex method will be described in detail, and can be described by natural language or pseudo code, or the state diagram can be described; for state control design Objects, can be described by state diagrams; product design classes (complete); 11.4 Forming design subsystem executing role designer activity Description Forming design subsystem; forming an interface of design subsystems; product subsystem (complete); interface ( Complete); 11.5 Database Design Enforcement Role Database Designer Activity Description Create a database model in the component view; create a scheme in the logical view, assign the scheme to the database; create an object model view in this scheme; create a table in the scenario , View, etc., create columns in the table; create a table between tables in the data model view; assign a stored procedure, trigger, trigger, etc .; product data model; 11.6 complex 11.7 design execution role design review review The design model is generally, in the early stage of the first phase and the essential to review the overall structure of the detection model, especially the hierarchical and interface; review each use case implementation; review each subsystem (and its content) or class If the system is small); the product is not; 11.8 Recurrently 11.9 Precursor Executive Role Architecture Recurrent Activity Description The best time for software architecture evaluation is the end of the refining phase. This phase is mainly focused on demand, and the baseline of the architecture is established. The architecture review is determined by the process of milestones at this stage. In this case, a wide range of architectural quality checks can be performed. Products are not;
12 Implementation 12.1 Architecture Executive Role Software Designer Activity Description Determines a component that has important meaning in the early life cycle, to start implementation; establish a model; to map the executable member to the node; product implementation model; component (summary , May be mapped to nodes); architectural description (view of model and implementation model); 12.2 Developing Integrated Construction Scheme Executive Role Any Role Activity Description Plan should implement which subsystems, and what order in the current iteration System; implement the components to be implemented according to a complete use case, and assign different constructs; products implementation model; "Integrated Construction Plan"; 12.3 Implementing a subsystem execution role programmer activity Describe the current constructed subsystem required Each class should be implemented by the components in the subsystem; each interface of the subsystem required for the current constructor should also be implemented by the subsystem; the product is realized subsystem (design); interface; 12.4 implement a class Execute a role programmer activity Description Implement member functions; product components (complete); 12.5 unit test slightly. 12.6 Integrated System Performs Role Any Role Event Description Verification Work Version and promotes baseline; product work version (Updated); 12.7 Review Code Execute Role code review (can be used by Technical Supervision Group) Event Description Test / Review Code Whether it meets the "Code Specification", make changes / rework opinions; products are not; 13 test 13.1 Develop test plan Executive role tester activity Description determine test requirements, including functional requirements (use cases of participation) and performance requirements; determine test priority order Generally, it is divided into: h - Must test M - should test, only test L - may test after testing all H items, but only after testing all H and M items; formulate test strategies; Determine the test resources, including personnel, test environment, etc .; formulate test progress; form "test plan"; product "test plan"; 13.2 Design test execution role tester activity Description Determine and explain test cases, test cases should consider branch; The user explains how to perform test cases (if the test case is sufficiently detailed, the test procedure can be omitted); product test case; "Test Procedures"; 13.3 Implementation Test Enforcement Role Programmer Event Description This section is mainly used to generate test components Test automation; this part is often used to generate test data, display test results, etc .; this step is not required; product testing member; 13.4 Execute an integrated test execution role tester Event Description Each use case for the current constructor performs test procedures, or run test The component automatically performs test procedures; compares test results with expected results; record and submit defects; product defects; 13.5 Execution system test execution role tester activity Description is similar; product defects; 13.6 Evaluation test Executive role tester activity description analysis Test results and submit a change request; assess the demand-based test coverage; assess the code-based test overlay; determine if the test is achieved; the test evaluation summary; product "test evaluation summary";
