"Light" method and satisfactory quality - market-driven software engineering practice Create software alliance (this article reprinted from software engineering expert network www.21cmm.com) With the rapid development of information technology, today's IT practitioners are in such a In terms of refund; on the one hand, according to the past pain development experience, they know if they use a mixed workshop model to develop complex, high-quality information systems have too much risk; on the other hand, they also know, formalization Software engineering methods (typically related to ISO9000 and SEI-CMM) are often bureaucratic and time-consuming, it is impossible to meet the progress of progress in the "Internet Age" environment in the "Internet Times" environment. Challenge requirement. Obviously, how to make the company guarantees the quality of the software, it is undoubtedly the focus of the industry's attention to the market demand for rapid changes. To this end, this paper starts from the market-driven IT development characteristic analysis, discusses the connotation and operation of the "light" method and satisfactory quality of the current internationally increasingly mature, and introduces specific operations and precautions with fast application development. Further, further understanding the practice of modern software engineering practices for readers. I. Market-driven IT development work today is in an unprecedented competitive environment, whether as independent software suppliers or proliferator, whether developing direct market-oriented software such as games, tools, Multimedia, etc., or for users to customize software such as e-commerce applications, MIS, etc., there is everywhere, IT development work is forced to carry out the market-driven state, with the following typical features: fast evolution of the basic technology, must Timely track the innovation and adjustment strategy of basic technology. Sustained competition must constantly encourage new to meet user needs. Time is money - need to reach a compromise between time, quality and cost. The employees are smart and the degree of education can be self-managed within a certain range. The past is popular in the IT industry - the review - the construction model is outdated. The latest technology and tools for IT have changed the logical order that the previous project run must follow. For example: Now some tools allow "instant" to create screens, making long-term design - review - constructor no longer applicable, and requires a more difficult prototype-auditing-constructor-recruiting-re-constructed process. Role overlap: Modern technology and tools make the original design, analysis, and coding people's rigorous distinction. Conventional IT developers have at least the following advantages relative to developers under current market-driven developers: control their application development technology. In traditional enterprise application development, machine configuration and other system elements are specified during the implementation phase. Now, this advantage does not exist, and few systems are implemented as isolation applications on their dedicated machines. Instead, they are often another application on enterprise user machines, which must be used in combination with other commercial applications, which makes IT developers have to be consistent with Corba, Internet, or database standards. At the same time, sustained competition, urgency progress and strict budgets make IT development managers to adjust development work often according to the requirements of salespersons or customers. Obviously, the new environment of the market-driven has brought new challenges to IT development. If the moving sleeve is used in the past successful experience and development model, it is not wise to move, and must adapt to the requirements of the new situation, rethink and position. Second, "Light" method surfaces surface with the continuous development of software industries, and various models continue to emerge or withdraw from the historical stage. Early design representation methods proposed in different angles (naming the names of the inventors) currently seem to have aggregated to become a widely accepted standard, structured design method is also more subject to object-oriented design. Welcome methodology, this change is also carried out in higher levels of global development methods.
The traditional software methodology description usually "can" process any size project, and actually truly difficulties come from how these methods are cropped to suit smaller items. In response to this theoretical and actual outset phenomenon, some famous software engineering experts put forward the so-called "Heavy" method and "light" method, trying to explore more practical for rapidly developing software industries Solution. The so-called "heavy" method is to refer to the formal, and strict software engineering methodology - not only refer to the weight of these methods, but also means that the management resource input, the extent of the QA review and the strict development personnel are required to comply. Process. Relatively, such as rapid application development (Rapid Application Development, a discounted RAD) and prototype method, can be referred to as "light" method - not only because these methods tend to generate a minimum number of paper documents, but also Management resource investment minimizes. Unfortunately, many RAD projects in the 1990 have taken "light" processing in the methodology to almost no way, these projects often degraded into a miscarriage development, and there is no documentation at all. Obviously, a balance point is required between the two extreme methods. The light method represents a conscious risk protection method, which is put into corresponding time, funds and resources in various activities related to the development of different risks. For example, how many demand analysis work is too much, interacting too little? For a few hundred demand development projects, a requirement analysis "light" method may be composed of behavior of each requirement, a need for a simple sentence, a requirement analysis "Requirements-Medium Approach may require documentation to each demand through a descriptive text, and a demand analysis" heavy "method may require detailed UML model, data element definition, and each The formal description of an object method. The "light" method of choosing the demand analysis is also a "heavy" method is largely affected by the company's product launch time or contractual pressure. At the same time, the company's employees' flow rate is also an influencing factor: one of the reasons for formal development processes, it is believed that if there is a detailed document to record demand, design and encoding, then once the key development member is left in the project The confusion will be minimal as possible. However, although the 1970s and 1980s system life cycle is expected to be ten or twenty years, We may be more willing to formally promise that its e-commerce applications continue for only one year and then abandoned or overwritten. If this is the case, and if the next generation is expected to exist with the current application, then just in order to achieve the SCM-CMM level, it is really meaningful to follow the needs analysis "heavy" method? Similarly, what kind of formation and strict levels use for design and testing work is appropriate? How to report, progress, state meetings, and other common activities related to project management - especially for projects that only last week or two weeks? These problems are always associated with each other, but some traditionally accepted answers need to be re-examined at least in a few years, because cost - income parameters are changing with commercial environment, technology and software developers. The light method also re-examines the hypothesis of investment resources in demand analysis, as well as the assumption of investment resources in process improvement. In 1981, Barry Boehm pointed out an amazing discovery in his classic book "Software Engineering Economics" (Software Engineering Economics), that is, if we introduce a defect in the project's systematic analysis phase, then discovered this in the analysis phase of the project. Defects are more than 10 times resource than allowing this error until the design phase is entered.
But Boehm has made a basic assumption that the new millennium is not necessarily correct in the first decade: only when the defect can be identified in some way in a certain stage of life cycle, then this order-level growth relationship is related. In today's environment, this premise assumes that it is not established under many business conditions. For example, when Bill Gates clarifies the demand for the browser IE, he will say "just like Netscape Navigator, but it is better", maybe Netscape's Marc Andresen will think so: "I hope that Navigator is like MOSAIC." But it is better. "But when Tim Bernerslee considers the initial version of the WWW and the first sketch of the browser? What is the meaning of him to write detailed demand? At the same time, the advocator of the weight is argued that if a defect is found during the development phase, then the individual who introduces the defect should not be reciprocated, and the process itself allowing the defect should be itself. But there is a basic assumption here, that is, we deserve to invest resources in identifying a potential defect in a process is that we want to use the same process again - because our next project will be enough to follow the previous item. Similarly, it is natural to use the same process. But now the changes are so fast, so that the N 1 project will have any similarities with the nth item at all. Therefore, yesterday's process may have to have substantial changes in the demand tomorrow, in other words, maybe only an important drawback in the process is worthwhile, because some details are only for a particular project. Of course, there are still some environments that we continue to rely on old, basic software engineering principles, and the mid-term method is confirmed correctly. But we should ask yourself, and hide the premise behind these principles assume that it is still reasonable. For many today's projects, some fundamental premise assumes to change, and the light method will be a method with the optimal performance ratio. It can be seen that the basic idea of light methods is to try to achieve a balance between project scope, cost, time, and quality. The key is to complete work in sufficient management visibility, sufficient flexibility and fast enough development speed to complete work. This balance is found, and you must strictly review the value of the control means you want to join or delete the project. Although we can cut a public development method as a basis, you must understand the reason for each step you want to perform, especially in the initial planning phase of the project, you should clearly define the development method to ensure project team members. Participation and recognition and to meet the business needs of the project. Third, satisfactory quality frame satisfaction quality (good enough Quality, a new idea that echoes "light" method, is also a conceptual concept of controversial and misunderstanding, more and more The concern, its theoretical foundation is constantly moving, this section is discussed in depth. Satisfactory quality prophet initially originated from the direct participants of the software project, rather than those who develop software processes or consultants, are lack of related research in software engineering academics. This situation has led to the abuse of the relevant concept. Satisfaction quality is often used to smell the defects in the software, and even some people think that software suppliers retain missem in software products is a deliberate behavior or even smart strategies. This undoubtedly causes a lot of misunderstandings. To this end, the famous software engineering expert James Bach made a systematic definition of satisfactory quality based on the principles of satisfactory quality and theoretical basis for many years, and made a satisfactory quality framework, clarifying many blurred knowledge.
The satisfactory quality framework is based on the following assumptions: 1) Software development is forced to face a complex 2) oscillate, unknown, restriction, error, and not 3) perfect world; 4) As of the current personality is the most volatile and most Important elements; 5) Anything brought costs, 6) and 7) What we want always exceeds us to pay; 8) Quality is essentially conditional and subjective; 9) In the software Aspects to perfect, 10) We do not 11) Do not 12) Solve many difficult problems, reaching a lot of compromise and solving the value of mutual conflicts, 13) Perfect not 14) will be easy or mechanically realized; 15) software engineering method only It is useful under its design range and assumption. Based on the above assumption, the satisfactory quality is defined as follows: (1) A sufficient interest; (2) there is no fatal problem; (3) The benefits of the benefits exceed the problem; (4) under current conditions After integrated all factors, the damage caused by further improvements is greater than the help it brought. At the same time, a framework for evaluating GEQ, including four GEQ elements and six Geq perspectives, which constitute a prompt group set, can be used to communicate with each other, or help product development, product improvement, and more Good practical activities, etc. For example, when someone says "satisfaction is not necessarily satisfactory", you can use the beneficiary and key purpose to understand the true meaning of the paradox and discuss it. It can cope with "satisfaction with you is not necessarily ", Or" satisfaction with the purpose of survival is not necessarily the target ", this problem does not function, and which goal is to be realized, which is truly achieved, and then explore the feasible solution. The following is a summary description of the GEQ framework: GEQ element (Factor) The four elements given here are expanded as the basis of GEQ, not strict formulas. These elements are designed to remind those software people who are busy, overloaded work should think about the quality of the software product quality.
1. Assess the interests of the product - What is known interest or potential benefit? For the beneficiary of the product? Possibility - Suppose the product is as designed, how many of the beneficiaries will recognize each benefit? Impact - What is the expectation of each benefit? Individual importance - from individual considerations, which benefits are completely irreplaceable? Overall interest - As a whole and assumes there is no problem, is there sufficient benefits to meet the beneficiary? 2. Assess product problem identification - What is known or potential for product beneficiaries? Possibility - How many probants can find each problem? Impact - What is the destruction of each problem? Can you continue to work? Individual importance - from individual considerations, which issues are completely unacceptable? Overall problem - What will all be superimposed together? Is there too many non-key issues? 3. Evaluate the quality of product quality - According to the perspective of the GEQ, whether the interest seems to be worth the problem? Safety / Perfect Marginal Value - If you need or want to make your interest value on a problem, then how much is it takes? 4. Assess the logistics policy strategy for improved products - What strategies can be used to improve products? Ability - Does the ability to implement these strategies? Do you know how to do it? Cost - How much cost or what is needed for improvement? Do you make full use of resources? Progress - Can I start now or later? Can I achieve improvement work within an acceptable time range? Benefits - Is the improvement effect? Is there an additional interest (such as better morale)? Question - How much may be improved in improvement work (eg, introducing missem, injury, occupying other project resources)? The GEQ Perspective (Perspective) The above GEQ element is a necessary condition rather than sufficient conditions. In order to perform a reliable assessment, you must also check each element from six critical perspectives: 1. What is the beneficiary - Who will work about quality? (For example, 2. Project team, customer, chamber of commerce, court, etc.) 3. Key purpose - what must be achieved? (Eg, 4. Instant survival, profits, market share, customer satisfaction, etc.) 5. How is the time-sensitivity of quality improvement results? (For example, 6. Immediately, recently, long-term, after a key event, etc.) 7. Alternative - This product is compared with alternatives? (Eg, 8. Competitors' products, service 9. service or solution) 10. Failure results - if the mass is slightly 11. What happens? Do you need to plan an emergency? 12. Evaluation Quality - How is the credibility of the assessment itself? Is it satisfactory? Obviously, satisfactory quality is not equal to mediocrity, it emphasizes rational choices, not mandatory behavior. If a software has achieved satisfactory quality after analyzing the GEQ framework, then further improvements will mean that resource investment is not enough. If we find that he is in such a situation, we should carefully find the mandatory reasons behind it.
For the powerful promotion of the GEQ method, the explosive growth of the market-driven software is from the embarrassment of huge stock market, leading the company to find the shortest path to launch better, cheaper software, they are willing to take risks, and It is difficult to embrace the so-called good practice in the traditional sense, and many traditional software management perspectives often do not apply or look too much when applying to market-driven software projects. It can be seen that the GEQ method is equivalent to the "light" method, whether it is software development of high reliability requirements or software development of high entertainment requirements, can be used to guide development. No matter whether it is GEQ, or other pronouns, such as economical, pragmatism, utilitarianism, etc., the basic thinking is consistent, that is, our behavior should be accepted, not forced. With the sustainable development of Geq thought, we think the quality, rather than following the quality of the formal method, will become a problem, and the authority behind the form and its authority will be re-examined, which is also a lot of authority to see GEQ as a dangerous The reason for thought. Fourth, the fast application development is discussed from the basic principles to the emerging "light" method and satisfactory quality framework. This section is discussed as a specific example in recent years in recent years. Help for these new ideas. The RAD method has a lot of similarities with prototype methods. Prototype development allows users to see different design of the system, especially when user needs are uncertain. In general, the prototype is only used to provide a presentation. However, once the final version prototype function is correct, the document is complete, and it is properly constructed, it can be used as the final product. When the prototype is used as a product, all legacy issues must have been resolved, and the software should meet the requirements of the description, design documentation and test documentation. Unlike prototyping, RAD is delivered each time the user applied in the actual business, not just a demo model. After accepting the project order, the product is quickly transferred by reaching a trade-off between product development time, cost and quality. The RAD method uses incremental product delivery, and the next loop is determined by the user in each development cycle cycle. Since market demand is difficult to expect, the RAD loop will continue until the system is eliminated. A typical RAD development cycle cycle is a new version of a system in a month, sometimes shortened to even every week. However, the shorter the development cycle, the more unstable development process, the easier it is to be out of control. The RAD method is often built on the following: All targets are clearly defined (what needs to do) and the guidance instructions for the solution (how to do). The task of solving the specific problem (how to do) is handed over to the individual. Project leaders replace detail management in the coach method, from the beginning, make employees to take great responsibility (only if there is indication that employees cannot be resolved on time when they are delivered on time). Each role in the team should be pre-explicit, so that every task is completed at least with a responsibility of an employee. But in the middle of the project development, when the actual workload is higher or lower than the expected workload, the employee role or task can be changed. The leader itself has programming capabilities but can work without coding. Customers actively participate: Does customers support the results, design, etc. of the project? You need to make sure who is a customer: Who affects and makes a decision? The development team actively participates in: Team members recognize the needs and time limit? Range Control: Estimate the estimate of the current and subsequent phases will not be too detained. In practical applications, the RAD method generally adjusts the strategy as a stand-alone parameter in progress and fees, steps below: 1. Customers determine the longest development time and fees they can withstand. 2. Developers estimate that the development time and fees needed to meet all functions.
