Project development process specification document

1. Overview purpose and overview

This document is the development specification document of XX Company and provides development standards and specifications to the development team.

Overall description

There are two parts in the Development specifications. The first part is the project development process specification, which mainly describes the specifications of each stage in the project development process. The second part is the Coding development specification. The Coding development specification describes the development specifications of each layer in a framework.

(Note: The first version does not include the specification for workflow development)

Intended audience

1. Project Management Personnel

2. system designers

3. system developers

References

Omitted

 2. project development process specifications

2.1 business Demand Survey Phase

LObjectives

System level: the customer's system operating environment

Business level: Understand what systems the customer needs, specific business objectives, business logic, business data, customer operation habits, and page style habits.

LPreparations for the survey:

Preparation of industry knowledge:

Understand the customer's industry background, business terms and meanings in the industry field. Understand the customer's business knowledge based on the customer's industry background.

Business expert requirements:

In the case of low complexity in the industry field, business analysts can directly collect and learn industry knowledge, but the preparation of industry knowledge is still required.

In the case of high business complexity in the industry, business experts are required to sort out the customer's business.

LSurvey process:

Step 1: Understand the customer's IT environment in the project startup phase.

Step 2: discuss and determine the scope of the customer system and obtain the original documents of the customer's business function points. Prepare a document and a document to record the business information discussed in this process.

Step 3: sort out business information and original forms, extract valid business information, sort and classify ambiguous business information, and make a questionnaire for further research.

Step 4: issue a survey questionnaire and conduct another business survey (go directly to Step 3)

Step 5: Write the survey questionnaire and conduct internal review

Step 6: Review and confirm the questionnaire.

 

 

LDeliverables in the survey phase (configurable)

Software Requirement Specification

 

Directory of the Software Requirement Specification:

1. Customer background

2. Significance of the customer System

3. operating environment of the customer's System

4 business function description (business purpose, business logic, business data, priority, usage frequency, etc)

5. users' operation habits and page style habits.

2.2 outline design phase

The outline design stage consists of two steps: 1. Framework Design 2. Business module overview design. The two steps are described as follows:

2.2.1Framework Design

(Note: The Framework Design here is described according to the traditional development method, and the platform-based development method is to be supplemented)

LFramework Design goals:

Design the background architecture, front-end interface framework, and data model of the system as needed. Before design, consider the customer's business characteristics, performance requirements, existing IT environment, and future business growth to ensure the scalability of the system.

 

LContent of the Framework Design:

Background framework:Function division at each layer, technical implementation, interaction rules between layers, exception handling rules, directory definition rules

Interface framework:Operation Interface Definition

Definition of the overall page style, page circulation relationship, etc.

Data Model:Basic System Data (organization structure, permission settings, Dictionary parameter settings)

Business Data

 

LFramework Design Phase deliverables:

Document: System Architecture

Interface framework

Data Model

Note: The three documents can be integrated into one document.

 

 

2.2.2Business module overview Design

 

The system designer provides a brief design based on the business requirements documents of the business analysts. Three key points in the Outline Design Process

1) page display content of the business module: information display content, display method, interaction interface definition, etc.

Example: Query personnel information module

Operation instructions, query conditions, display fields, sorting and display methods.

 

2) business logic description

Describes the business logic in detail.

 

3) business data items

Description of data involved in the business module.

The specific description includes

Data item name,Display Mode,Required,Input mode,Related Logic

 

LDeliverables in the Outline Design Phase

Summary design document

 

2.3 Business Requirement understanding stage

2.3.1 system designers understand requirements

Before the system designer understands the requirements, the business analysts must provide the customer requirements documents of the relevant modules. System Designers read and understand the customer requirements documents.

LUnderstand the delivery results of the requirement document (configurable)

What are the purposes, problems, and significance of business needs for customers?

What is the execution logic of a specific business?

What are the business data during the business flow?

 

LRequirement understanding time requirements:

Simple requirement, which can be understood as 2-3 hours

Complex requirements: 4-8 hours

 

LComplex business requirements must be confirmed by the requirement analysis personnel.

Complex business requirements are determined by the complexity of the involved business.

 

2.4 detailed design phase

The detailed design phase consists of two steps

L step 1: The system designer designs the business module in detail and provides detailed design documents based on the understanding of the business needs.

L step 2: The Core designer reviews the detailed design documents of the system designer.

2.4.1 detailed design phase

System designers design modules in detail based on business needs.

LDetailed design stage delivery results (configurable)

Detailed design documents:

Business Interface Definition

Definition of data items in the database

Web pages and Js interface definitions

 

Note: complex modules can contain UML class diagrams and sequence diagrams in detailed design documents to further describe the design content.

LDetailed design time requirements:

Simple business needs: 2-4 hours

Complex business needs: 4-12 hours

 

LDetailed design document writing principles:

In this document, the system designer can describe the detailed design of the business module, regardless of the format.

 

2.4.2 Technical Review Stage

LTechnical Review Process:

1) system designers distribute their detailed design documents to technical reviewers before technical review.

2) during the technical review, the system designer first describes the detailed design documents.

3) The reviewers inquire and confirm all the steps in the detailed design and propose the modification plan.

4) The Project Technical Director confirms the adjusted design scheme.

LTechnical delivery results (configurable)

Detailed design document for business determination.

Note: This document is one of the criteria for delivery validation.

2.5 Coding stage

System developers design documents based on detailed business projects to perform the actual Coding process.

Considerations during Coding

1) strictly follow the Coding development specifications during the Coding process.

2) in the Coding process, to find serious defects in the detailed design documents, you need to confirm with the project designer, if very complex, you need to review the technical.

3) when the detailed design changes, the detailed design documents should be updated in a timely manner.

 

2.6 business module validation delivery phase

The project technical owner and business analysis personnel jointly inspect and accept the business module.

 

Acceptance steps:

1) business analysts confirm that the function module achieves the same functions as the customer's requirements.

2) The Technical Director confirms the functional modules technically.

3) testing report of testers

 

Note: The third step focuses on the company's specific situation and business complexity,

The process for completing step 3 is as follows:

1) Prepare the test team to set up a business environment and write the test script according to the business requirements,

2) the test phase is carried out according to the test environment and business needs.

3) generate a test report based on the test results.

 

 

2.7 System Integration Test

Based on the customer's business needs, the tester sets a test environment, writes test scripts, and deploys the system on the test server. Perform functional tests based on test cases.

 

Tester preparation list:

Test Cases

Test script

Current implementation module

 

Hardware:

Customer operating environment with equivalent conditions

 

System integration test phase deliverables (configurable ):

System integration test report

 

System integration test report format

Function Point Tester test Script test result exception cause

 

2.8 package and deploy the system

The customer service installer packs the system into an installation file for you to deploy the system in your system environment.

System integration test phase deliverables (configurable ):

System Installation File

 

Note: The webpage is not too clear,
The following is the document connection. You can download it directly.
/Files/macroxu-1982/project development documents. Doc Xu wenbing