Shulou(Shulou.com)06/03 Report--

Hello everyone, I am National Day holiday, today we have a detailed explanation on the software life cycle. Let everyone have an overall understanding of the "growth process" of software.

What is the software life cycle?

Software life cycle is the whole process of software from generation to abandonment, during which there are problem definition, feasibility analysis, requirements analysis, system design, coding, debugging and testing, deployment / release, maintenance and upgrade to abandonment and so on.

So what are the various stages of the software life cycle?

Let's take a look at the shopping map (my eyes are going to be useless for this picture, too).

The picture above is a complete map of the customized shopping process on Taobao, so what does the shopping process have to do with our software? Can you compare the whole process with the software life cycle diagram in "A brief talk on Software Development"?

Let's think about it first. (come on, close your eyes and think about it.)

All right, I'll find out the answer, and let's see if you're right!

First of all, find a protagonist for the story, call the heart for a while, and customize the demand, then communicate with the customer service whether it can be done (demand feasibility analysis), and then choose the style and size you like to place the order. after getting the order, the merchant sends out the design drawing (prototype design) according to the order requirement, communicates with the heart to see if it is what he wants (demand confirmation), and puts into production (development) after getting the affirmative reply. After the completion of the production, the internal quality inspector checked (tested), and after the check was correct, it was delivered to Xin Xin (online / distribution plate), and the Xin Xin got the clothes to try on and check if there were any quality problems (testing). He was very satisfied with the purchase, so he gave satisfactory praise, the order was closed, and the whole shopping process was completed.

You may say that the support and maintenance is not reflected?

What if the heart wears it for a week and finds that there are some quality problems such as discoloration / pattern washing and so on? Is it time to find customer service? after communicating with customer service, merchants will deal with it, exchange / return / repair, and so on. This is support and maintenance.

Note: the "merchant gives the design drawing style according to the request" in the shopping diagram is not the same thing as the design in the software flow chart!

The merchant gives the design drawing style according to the requirements: it is the prototype design, that is, to make a static and similar finished product to show to the customer, so that the customer can confirm whether it is what he wants and belongs to the requirement confirmation.

The design in the software flow chart: is the development design, designing the language, framework, technology, etc., which are needed to realize the product; corresponding to the production part of the merchant in the shopping diagram, the merchant needs to decide what kind of cloth, thread, sewing method, matching material / method and so on before production.

In fact, the whole process above is more appropriate to the whole process of the actual software product. Do you know? I have drawn a complete software flow chart for your reference.

Let's introduce each stage according to the above picture. Focus on the concept of each stage and the participants.

Requirements definition (Ruquest for Proposal):

Description: define what needs to be done and what to look like for this task (for example, the buyer tells the seller what kind of clothes I want, and then the two sides begin to negotiate and finally reach an agreement, which is the definition of requirements).

Participants: product managers, requirements, customers

Feasibility analysis:

Description: it is up to the relevant members of the project team to study whether the requirements are feasible and whether they can be done (for example, merchants take the order requirements to the designers and factories and ask whether the design drawings or styles can be made; ask the factory whether it is possible to make design style clothes on the corresponding fabric, this process is feasibility analysis)

Participants: product manager, project manager, developer, architect

Requirements Analysis / user requirements (Requirements Analysis):

Description: requirement analysis is actually doing requirements refinement, detailing each point according to the task content and indicators in the task specification, to the style of each button in each box, input and output and other values (for example, the designer and the factory do material analysis on this clothing respectively, and analyze how much fabric the clothing needs, what style and color the buttons are, how much different fabrics are used, and so on. This process is called requirements analysis) Uniformly compiled into the "requirements specification / requirements specification".

Participants: product managers, project managers, test / quality managers (collectively referred to as QA by many companies), developers, architects

Review: (as can be seen from the figure, almost all stages need to be reviewed, which are described uniformly here)

Description: review is to review the work at this stage to see if there are any deviations or omissions (for example, there are relevant reviews in all aspects of the design and the factory, review of whether the material is up to standard, whether the design meets the regulations, whether the material requirements according to the worker / designed material requirements are adequate or redundant, etc.); the review is generally attended by the appropriate staff

Participants: the review of each stage is generally an internal audit of each functional department, and you can also apply for other related personnel to review, such as requirements review, which is generally reviewed by product manager, project manager, test and development; system design is generally project manager and development review; test strategy review is generally internal review of test team, etc.

Development line

Design (Design):

Description:

The architect determines the scenario and characteristics of the product or project according to the requirements, selects the appropriate framework, and the technology optimizes the project. On this basis, the system is briefly designed, including the overall data structure, database structure, module structure and the relationship between them. The developer designs the specific module in detail according to the outline design, including interface parameters, parameters and so on. The design here forms a summary design document and a detailed design document.

Participants: project manager, architect, development, testing

Coding (Coding):

Description: the developer modularizes the system according to the detailed design document, in the case of determining the parameters and interface, carries on the method-level design and coding and self-test within the module according to the requirements, and realizes the product function one by one.

Participants: development

Mention and test:

Description: the developer completes a small iteration / small function and completes the self-test (after the development and coding is completed, he usually tests it himself), so he initiates the test to the test department, and generally informs the test department that the xxx module / function can be tested by email or task management tool task flow.

Participants: task responsibility (developer), testing

Test line

Test strategy:

Description: the test team leader should decide the idea / category of this test (functional test / performance test / documentation test or several combinations), test method, flag (task index, degree of achievement) and so on according to the "task statement" and "requirement statement". There are also many companies that use testing strategies as part of their testing solutions.

Participants: test team Leader / Test engineer testing leader/ itself

Test Plan (Testing plan):

Description: the test team leader should start to write a "test plan" according to the "task statement" and "requirements statement", including personnel, software and hardware resources, test points, integration sequence, schedule and risk identification.

Participants: test team leader / test leader

Test scenario:

Description: the test scheme is generally designed by senior test engineers who are familiar with the requirements, and the test scheme is designed according to each requirement point in the requirements specification, including a brief introduction of the requirement points, test ideas and detailed test methods.

Participants: test engineer

Test design:

Description: mainly focuses on the design of test cases and procedures. Test cases are written according to the "test scenario". Test cases need to include test items, use case levels, preset conditions, operating procedures, and expected results. Similarly, test cases need to be reviewed.

Participant: relevant test engineer

Test execution (Testing):

Description:

According to the test case, the test part of the development is carried out, the passed mark is passed, and the failed Bug is submitted with quality (problem defect). Here, to talk about bug, the part of the test that has a problem is submitted to the bug to the relevant development engineer, and the developer will revise it according to the description of the problem. After the revision is completed, the bug will be transferred to the relevant testers (through defect management tool assignment / email to notify the relevant testers that the bug revision is complete and testable). Testing requires test regression of bug and bug related modules.

Participants: relevant test engineers, responsible development engineers

Test report:

Description: the final test completed (all test cases passed / suspended) will produce a test report to summarize the above tests.

Participant: relevant test engineer

Deployment / release (Deploy):

Description: after the previous stages, the product is ready for sale or available to the public; the smoke test is conducted by the test. after passing the smoke test, the configuration manager will seal the version, make the version (for the product) / deploy it online (for the project application).

Participants: configuration managers, testing

Support maintenance (Production Support):

Description: support maintenance is similar to our daily after-sales, mainly for daily maintenance of sold products / online projects. It includes two aspects: error correction maintenance and improvement maintenance.

Participants: support maintenance staff / after-sales engineer

The above is the introduction of the whole software process, the content is a bit much, but I hope you can read it carefully and understand it into your own knowledge.

Note: the above software development process is only the most basic template, but the company has its own organizational structure, which can be adjusted according to the project. As long as the project is suitable for you, then it is right and good.

All right, this is the end of today's content, welcome to join the group and communicate with me! I'll see you next time.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.