Chapter 2 think twice: Preparations (Code 7)

Source: Internet
Author: User
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)

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.