Chapter 9
1. Space size of the system: Size is an integral part of the software system product user cost, the developer must set the scale of the scale, control the scale, and consider the reduction in size. Like any overhead, the scale itself is not a bad thing, but unnecessary scale is not advisable.
2. For project managers, scale control is both part of technical work and part of management. Users and their applications must be studied to set the size of the system. Next, these systems are divided into several parts and set the scale target of each portion. Due to the large-scale performance of the scale - speed weighing, the scale of scale is a quite skill, which requires a deep understanding of each available scheme. Smart project managers will also reserve some spaces and allocate when work is implemented.
It is not enough to set the scale of the core program, and all aspects must be budget.
While indicating how much the module is, the function is defined in defining the module.
Developing developers from the entire system, facing the user's attitude.
3. In the case of the constant speed, more features mean more space. One of these techniques is to use functional exchange sizes. Designers must determine the extent of the user selectable items.
4. Consider space - time compromise. For a given function, the more space, the faster the speed.
The project manager can do two things to help his team have achieved good space - time compromise. One is to ensure that they are trained in programming skills, not just the knowledge and previous experiences that they have mastered. Especially when using new languages or new machines, training is particularly important. Another way is to recognize that programming requires technological accumulation, and many common unit components are required.
5. The strategic breakthrough often comes from the re-expression of data or tables - this is the core of the program. The root of the program is based on the form of data.
Chapter 10 Outline
1. Tracking and maintenance of documents is the mechanism of project supervision and early warning. The document itself can be used as an inspection list, status control, or as a reported data foundation.
2. Software project documentation:
the goal. Targets to be completed, urgently needed resources, constraints, and priority.
Product technical description.
Schedule.
Capital budget.
Work space allocation.
Personal organization.
3. Why do you have a formal document?
First, written record decisions are necessary. People can get clear and determined decisions from a confusing phenomenon.
Second, the document can be used as a channel to communicate with others. The basic responsibility of the project manager is to enable everyone to advance in the same direction, so his work is mainly communicating, not a decision. Documents can greatly reduce his burden.
Finally, the document can be used as a data basis and a list of inspections. Through periodic review, he can clear the status of the project and which needs to focus on changes and adjustments.
The project manager's task is to develop a plan and implement it according to the plan. Only written plans are precise and can communicate. By following documents work, project managers can set their own directions clearer and quickly.
The eleventh chapter is pre-raining
1. For most items, the first development system is not used. It may be too slow, too big, and it is difficult to use, or the three are both. To solve all the problems, in addition to restarting, there is no other way - develop a more destacious or better system. The discarding and redesign of the system can be done in one step or implement a block. The experience of all large systems shows that this is the steps that must be completed. - Build a test system and discard it.
2. Once the experimental system must be constructed and discarded, the redesign of change ideas is inevitable.
3. To change design systems, including detailed modular, scalable functions, accurate and complete module inter-interface design, complete documents. In addition, it is also possible to adopt a queue and table driven technology.
The most important measure is to use advanced languages and self-document technology to reduce changes caused by changes. Using compiled operations to integrate standard descriptions to a large extent, the change is greatly helped.
The stage of change is a necessary technology. Each product should have a digital version number, each version should have its own schedule and freezing date. The change after this is a category of the next version. 4. Organize architecture and teams for the Change Plan.
5. One of the basic issues in program maintenance is that the defect repair will introduce new bugs with (20% - 50%). The entire process is two steps forward, and then take a step. As a consequence of introducing new bugs, the system testing of each statement of each statement is much more programmed than other programming, and the cost is very high.
The cause of defects cannot be completely repaired:
First, it seems to be very slightly mistaken, it seems to be just the failure of local operation, but it is actually the system level problem. Second, maintenance staff is usually not a developer who writes code.
5. Use can be eliminated, at least the programming method that can specify side effects will have a lot of rewards on maintenance costs. The less staff, the less interface, the less the incorrect, the less error.
6. Maintaining the structure of the system, increasing the degree of chaos of the system. As time goes by, the system becomes more and more disorder, and it is unable to become the basis for the next progress. At this time, the system's redesign is exactly necessary.
System software development is a process of reducing chaos. Software maintenance is a process of improving chaos, even the most skilled software maintenance, but only slows the process of degradation of the system.
