Chapter 2 think twice: Preparations (Code 7)

Chapter 2 Measure twice, cut once: upstream prerequisities: Preparations

• 3.1 importance of preparations
• 3.2 identify the types of software you are engaged in
• 3.3 prerequisites for problem definition

3.1 importance of prerequisites pre-preparation importance if you emphasize quality at the end of the project, then you will emphasize system testing. However, testing is only part of a complete quality assurance policy and is not the most influential part. Tests cannot detect defects such as "Creating a wrong product" or "using wrong methods to make the right product. Such defects are resolved before testing-more specifically between building activities. If you emphasize quality in the middle of the project, you will emphasize building practices. These practices are the focus of most sections in this book. If you emphasize quality at the beginning of the project, you plan, demand, and design a high-quality product.

• Do prerequisites apply to modern software projects

Are preparations applicable to modern software projects? Some people assert that preliminary work such as architecture, design, and project planning is useless for software projects. In general, no research (whether in the past or in the fairy world) supports this asserted, and recent data does not support this asserted. The central goal of preparation is to reduce risks: a good project planner can clear major risks as early as possible so that most of the work can be carried out as smoothly as possible. Currently, the most common project risks in software development are poor requirement analysis and poor project planning, so preparation tends to focus on improving demand analysis and project planning.

• Causes of incompletepreparation

One common cause of inadequate preparation is that developers assigned to prepare for the event do not have the skills to complete the task. When developers do not know how to do these preliminary work, it is completely useless to "do more preliminary work". If you cannot do this well first, it makes no sense to do more! Some programmers do know how to do their preliminary work, but they do not, because they cannot resist the desire to "start coding as soon as possible. If so, I have two suggestions: first, read the arguments in the next section, which may tell you some questions you didn't think of before. Second, pay attention to the problems you have experienced. You only need to do a few big projects, and you will be able to understand that planning in advance can avoid a lot of pressure. The last reason programmers do not prepare for their work is that the indifference of managers to the "programmers who prepare for building activities in the early stage" has reached the level of public anger. You can expect that management should have begun to understand that software development is not just about writing code.

• Utterly compelling and foolproof argument for doing prerequisites before construction

Strong and concise arguments about preparations before building Appeal to logic resort to logicOne of the essentials of effective programming is that preparation is very important. It makes sense to make plans for a large project before you start. From a management perspective, planning means determining the time, number of people, and number of computers required by the project. Technically speaking, planning means figuring out what you want to build to avoid wasting money on building wrong things. Sometimes users do not fully understand what they want at the beginning, so it is worth spending more effort than ideal to find what they really want. However, this is at least cheaper than the cost of "first making a wrong thing out, then throwing it away, and starting from scratch". Before you start to make the system, you should first think about how to do it, this is also very important. Your headquarters wants to spend a lot of time and money, but it does not have to go into a dead end (especially when doing so will increase the cost) Appeal to analogy appeals to analogyProgrammers are the last part of the software food chain. Architects eat demand, designers eat architecture, while programmers digest design. Appeal to data resort to dataThe research over the past 25 years has proved that it is the most cost-effective to do things well at the beginning. The cost of making unnecessary changes is high. Boss-readiness test "boss ready" TestIf your boss understands the importance of preparing for building, try the following tests to make sure that he understands. Which of the following statements are self-implemented languages (SEL-fulfilling prophecies)

• We 'd better start coding immediately because there will be a lot of debugging work to do.
• We didn't schedule too much time for testing, because we won't find many defects in the future.
• We have carefully studied the requirements and design, and I don't know what problems will happen during coding and debugging.

All of the above statements are self-fulfilling languages, which should be aimed at the last one. 3.2 determine the kind of software you're working on identifies the type of software you are engaged in

Software category
	Business System	Mission-critical systems	Embedded Systems at critical risk
Typical applications	Internet site Intranet site Inventory management Games Games Management Information System (MIS) Wage System	Embedded Software Games Internet site Boxed Software Software Tools Web Service	Aviation Software Embedded Software Medical Equipment Operating System Boxed Software
Lifecycle Model	Agile development (eXtreme Programming, srum, time-box, development, etc) Prototyping)	Delivery in stages Progressive delivery Spiral development	Delivery in stages Spiral development Progressive delivery
Planning and Management	Incremental Project Plan On-demand testing and QA plan Informal Change Control	Basic pre-plan Basic test plan On-demand QA plan Formal Change Control	Adequate pre-plan Adequate test plan Adequate QA plan Strict Change Control
Requirement	Non-formal requirement specification	Semi-formal requirements On-Demand Review	Formal Requirement Specification Formal requirement check
Design	Designed and encoded in combination	Architecture Design Non-formal detailed design On-demand design reviews	Architecture Design Formal architecture check Detailed Formal Design Formal detailed design check
Build	Pair programming or independent coding Informal check-in procedures or no check-in procedures	Pair programming or independent coding Informal check-in On-demand code review	Pair programming or independent coding Formal check-in procedures Formal code check
Testing and QA	Developers test their own code Test Development first Few or no tests (conducted by a separate test Team)	Developers can test their own code. Test Development first Independent Test team	Developers test their own code Test Development first Independent Test team Separate QA Team
Deployment	Informal deployment process	Formal deployment process	Formal deployment process

• Iterative approaches 'effect on prerequisites

The impact of iterative development on preparations the iterative method can often reduce the negative impact caused by insufficient preparation, but it cannot completely eliminate the secondary impact.

• Choosing between iterative and sequential approaches

You may choose a more serialized method for the following reasons:

• Requirement equivalent document
• Straightforward design and thorough understanding
• The development team is very familiar with this application field
• Low project risks
• "Long-term predictability" is important
• It may be expensive to change requirements, design, and coding later.

You may choose a more iterative method for the following reasons

• The requirement is not fully understood, or you think it is unstable for other reasons.
• The design is complex, challenging, or both.
• The development team is not familiar with this application field
• Project contains many risks
• "Long-term predictability" is not important
• The design and coding costs are likely to be low when requirements are changed later

In fact, in software development, iterative development is much more suitable than sequential development. You should first determine which preparations are suitable for your project. Some projects took too little time to prepare for the project. As a result, a large number of unnecessary revisions were encountered during the construction activities, which hindered the steady development of the project. Some projects have done too much in advance and persistently stick to the original requirements and plans. Later, facts have proved that these requirements and plans are ineffective, which also prevents the smooth development of the building activities. 3.3 problem-definition a prerequisite for prerequisite problem definition to be met before building, the definition of the problem to be solved by the system should be clearly stated in the customer's language, and the problem should be described from the customer's perspective. Generally, it should not be described in computer terminology. This rule also has an exception, that is, it solves problems related to the computer itself: the compilation time is too long, or there are too many bugs in development tools. In this case, it is appropriate to use computer or programmer terms to describe the problem. The penalty for "failing to define a problem" is that you waste a lot of time solving the problem. This is a double penalty, because you have not solved the correct problem.

Chapter 2 think twice: Preparations (Code 7)