This paper briefly describes the quality problems that software development may face in the course of project-based software development, while emphasizing the importance of software product quality. The author summarizes the problems he has encountered, grouping and sorting them by stage and type, and hopes to help the reader。
In the case of the software development corporation, there are a number of factors affecting the quality of software products in the course of project software development。
Because product quality problems often require additional time and cost to be invested by the software company, the client to repair the product quality, there is a serious risk that re-engineering development will need to be reversed if product quality problems are serious。
The importance of the quality of software products is therefore self-evident for the software development company。
In a software development company, the author also encountered problems with product quality in the face of limited development resources and tight project timelines. A summary of the problems encountered in the course of the project would be useful to readers who would be or were facing such problems。
Depending on the problems encountered, they are grouped into stages and problems as follows:
1. Pre-research period
Before conducting a needs study, the producer collects basic information from the client and interprets the information in order to follow up on the work of the user。
In practice, we have encountered three main problems:
(1) inadequate collection of client information
Question description: when researchers collect information from clients, they do not have a clear indication of the type and scope of information to be provided by clients, leading to insufficient analysis of pre-research information and to an impact on the efficiency of research interviews with subsequent users。
Reasons: this is mainly due to the lack of a standard and standardized client information list for the department, and guidance and reference for new entrants。
Solutions: based on previous projects, a client information list is drawn up to help product researchers identify the client information to be collected in the prior period。
2) irregular collection and archiving of customer data
Description of the problem: there is no clear information on both sides of the project to collect the docking personnel, which leads to information on the personnel of the different sections of the client to be provided to the different players in the project. At the same time, the project does not have a single location for the archiving of client information, which results in the collection of client information in the hands of different actors. First-time analysis of impact product personnel。
Reason for this: at the time the project was established, there was no clear project pair. When the information was archived, no single archive location was specified for the project file。
Solutions: at the start-up meeting of the project, the two parties identified the project leaders of both parties. At the same time, the head of the project assigns a single location for the customer information。
3) misunderstanding of client information
Question description: researchers analyse client information in such a way as to understand the length of time, the lack of thoroughness of the analysis, and the omission of the scope, affecting the conduct of subsequent user interviews。
Reason: insufficient knowledge of industry among researchers。
Solutions: in daily work, the knowledge of the industry is enhanced through book sharing, project wrap-up sharing and the invitation of experts in the industry to give lectures and training. The provision of websites, micro-credit public numbers, etc. That are commonly used in the industry, and the provision of relevant help and reference where trade terms, formulae, etc. Are not understandable. At the same time, it provides information on senior insider researchers and allows newers to find intracompany experts to solve problems。
2. Research process
At the time of the needs study, the product person went to the client site to conduct a user interview study and collected and documented the client's needs through the user study. At the same time, client information is gradually being collected and refined through needs-based analysis。
In practice, we have encountered two main problems:
Inadequate collection of needs
Description of the problem: the specific scene of an operational activity in the needs study describes only one of the common situations, with no other special circumstances being collected, documented and analysed. (c) to influence the design of subsequent products。
Reason: the needs of only one business person are collected when the needs are investigated, and the needs of the entire sector and other upstream and downstream sectors are not adequately captured。
Solutions: the department provides a checklist of needs for research and helps and alerts researchers to the matter. In addition, the results of the needs study should be aggregated and reconfirmed by relevant clients。
2. Lack of detail on needs
Problem description: the content of the client demand description is not sufficiently specific and clear, resulting in repeated communication and confirmation with clients at the product design stage。
The reason for this is that the researcher industry has little experience and is unable to conduct in-depth inquiries into client needs. The other is that clients are also not clear about the extent to which demand is appropriate. That's what happens when you don't ask me not to。
Solutions: in addition to enhancing the day-to-day knowledge of researchers, there is a habit for researchers to ask questions when they encounter a simple response from their clients。
Other
Client scheduling conflicts
Problem description: the time spent on research with clients is delayed and needs to be repeatedly confirmed。
Reason: insufficient attention by clients to projects or lack of time for urgent and important meetings has led to repeated postponements of research。
Solutions: determine project completion time and define project plans with clients. Both leaders are invited to participate in the project launch meetings, which will focus on the implementation of the project plan。
Ii. Product design 1. Functional design
Upon completion of the needs analysis, the functional structure of the product is planned on the basis of the results of the needs analysis and the list of product functions is drawn up on the basis of the functional structure。
In practice, there are two problems with functional design:
1) lack of detailed functional design
Question description: the function is designed to consider only positive processes, but not reverse or other special processes. This led to the re-engineering of functional design during later user testing。
Reasons for this: omissions during needs research analysis and failure to consider simulation scenarios during functional design。
Solutions: designers need to be careful to model the user's real scene on the basis of analysed information, and re-communicate with the user at the first opportunity if there are features that are not clear or missing。
2) general function is not abstract
Problem description: there is no abstraction of the generic modules in the system, leading to duplicate descriptions of the same functions, while at the same time posing risks for subsequent functional changes。
Reason: designers do not look at product functions from a global resolution, tend to look at them together and do not have a unified product planning function。
Solutions: strengthening the review of product functionality while enhancing product design capabilities。
2. Prototype design
When the function is designed, the prototype is designed using the prototype tool axure rp based on the functional list。
When the prototype was designed, we also faced the following three problems:
1) inadequate design of components
Problem description: the components are not uniform during the prototype design, for example, the text description of the same content is not consistent with the text of the different modules; the ranking of the lists is not uniform; the components of the date or time used are not uniform。
Reasons for this: department does not have a uniform normative description; at the same time, designer project experience is insufficient。
Solutions: standard modules are created (with mobile and web versions) and all project design prototypes are uniformly called from the libraries. The prototype design self-check list for the establishment of the sector makes the commonly used self-check list the mandatory content of the designer's design. Enhanced learning and understanding of standard components by designers。
2) not clear description
Question description: the description of the prototype is not clear or incomplete. There is no special focus on the logical description of the special or priority. For example, the length of the prototype field, the verification rules for the twist function, etc., are not indicated. These issues will be further identified and refined with experienced and responsible developers, and often ignored by newcomers. These problems are exposed at the test or user stage, affecting product quality and customer experience。
Reason: departments did not develop uniform labelling templates and requirements. This led to labelling according to their preferences。
Solutions: detailed demand design templates are developed, and detailed demand design templates are harmonized among sector members as final deliverables。
3) slow prototype design
Problem description: an interactive prototype design approach is used, but interaction requires a high degree of capability to build the prototype skills of the designer. At the same time, when the prototype design is confirmed, changes and optimizations of the prototype are required, the time taken to adjust the prototype becomes longer。
Reasons: departmental personnel are mostly new, prototypes are less skilled and interactive prototype designs add to their workload。
Solutions: use of prototype components in the standard assembly library and use of line diagrams, inter-component interaction and use of text description to reduce working time associated with interactive design。
3. Needs assessment
Poor needs assessment
Description of the issue: the evaluation information was not sent to the person concerned prior to the needs assessment, the needs assessment was conducted without the involvement of the needs and design experts, and the needs assessment was not recommended in a constructive manner。
Reasons for this: insufficient emphasis on demand assessment by companies and product workers and lack of internal expertise in the reserve industry。
Solutions: increased focus on needs assessment and early preparation for needs assessment. Training and reserve of professional staff, inviting experts from clients to participate in the needs assessment。
1. Detailed needs
Problem description: the detailed stage of demand, the lack of involvement of all relevant developers of the project and the poor performance of the participants led to a reinterpretation of the product's development process, which affected the progress and quality of product development。
Reason: the product was not delivered to the developers in advance and the developers were not informed in advance, resulting in poor detail。
Solutions: the former product person distributes the information to the project developer, prepares the questions for the developmenter, and during the detailed discussion the producer person will focus on clarifying the developmenter's doubts based on the list of issues。
Changes in requirements
Question description: when a product person makes a change in demand, it is not considered in detail that leads to the need to repeat a demand, and sometimes it is no longer needed after the design of the demand raised by the client has been completed. At the same time, the change in requirements was not synchronized with the relevant development and testing staff, resulting in the relevant personnel being developed before the content of the change was received。
Reasons for change in demand by product personnel, leading to change in demand and confusion in management。
Solutions: an evaluation system that increases demand, a change in external demand requires that the client submit a change in demand, avoids the client's one-word demand, and experimental or personal preference leads to the company's input to its members. Changes in internal requirements need to be reviewed by the head of the office, and the changes need to be synchronized with the relevant development and testing staff。
3. Version survey
Problem description: the systems submitted for testing, during which the process was found to be inadequate, the number of bugs developed was high, and the system produced did not correspond to the design prototype。
Reason: at the time of development, the modules were developed by different developers and at the time of submission of the tests, no system integration testing was performed. The developers identified problems in the development of the system, did not communicate with the producers in a timely manner and developed along lines that they understood。
Solutions: product personnel follow the progress of the development of the system in a timely manner from the time of its development, and daily stations with developers will be informed about the development and communication of the development process. Upon completion of the development, the system validation will be performed at the first opportunity to ensure smooth flow of system processes。
Summary
It's not easy to build a good product。
The product needs study shows that the end product is running online at multiple stages, each of which may involve different people, and that there is a risk that the transmission of information may be lost in layers。
Software development is therefore a project that requires management to ensure the progress and quality of software。
It is hoped that this will help and inform the reader。
