The trial topic is a cutting of the main paragraphs from the book from the first chapter. The volume is compressed 4 times, the sequence of presentation and the meaning, if possible, are preserved. Feedback is very welcome.

Why paragraphs from the book, and not in your own words? Because in many cases it is very difficult to say better. And then, it’s boring to read pure abstracts - it bothers you on the second page.
If the topic is like it, I’m ready to try to describe the whole book in the articles, each time reducing the volume and increasing the density of information.

Software engineering

What is software engineering?

Software development is a complex process that can include many components. Here are the components of software development that scientists have identified over the past 25 years:
- definition of the problem;
- development of requirements;
- creating a design plan;
- software architecture development, or high-level design;
- detailed design;
- coding and debugging;
- block testing;
- integration testing;
- integration;
- system testing;
- corrective maintenance.
')
Sometimes construction is called "coding" or "programming."
“Coding” seems to me not to be the best term in this case, since it
implies a mechanical translation of the developed plan into programming language commands, whereas the design is not at all a mechanical process and is often associated with creativity and analysis. The meaning of the words “programming” and “design” seems to me similar, and I will use them as equal rights.

Here are some specific tasks related to the design:
- verification of compliance with the conditions necessary for successful design;
- determination of methods for subsequent testing of the code;
- designing and writing classes and methods;
- creation and naming of variables and named constants;
- selection of control structures and organization of blocks of teams;
- block testing, integration testing and debugging of own code;
- mutual review of code and low-level program structures by members of the group;
- “polishing” the code by carefully formatting and commenting it;
- integration of software components created separately;
- code optimization, aimed at improving its speed, and reducing
extent of resource utilization.

Why software engineering is so important?

“ Design is a big part of the software development process.” Depending on the size of the project, it usually takes 30-80% of the total time to design.

- Design is central to the software development process. Application requirements and its architecture are developed prior to the design stage to ensure its effectiveness. Testing of the system (in the strict sense) is performed after construction and serves to verify its correctness.

- Increased attention to design can greatly increase the productivity of individual programmers.

- The result of the design - the source code - is often the only one correct and relevant description of the program.

- Construction is the only process that is performed.
in all cases.

Ultimately, your software engineering competency determines
how good are you programmer.

Metaphors for better understanding software development

Computer science terminology is one of the most colorful. Really,
in what other area are sterile rooms with carefully controlled temperature, filled with viruses, Trojan horses, worms, bugs and other living creatures and scum?

The importance of metaphors

Making analogies often leads to important discoveries. Comparing not really
understandable phenomenon with something similar, but more understandable, you can guess
how to deal with the problem. This use of metaphors is called modeling. ”
The history of science is full of discoveries made by metaphors. So, the chemist Kekule once in a dream saw a snake clutching itself by the tail. Waking up, he realized that the properties of benzene would be explained by a molecular structure having a similar ring shape. Further experiments confirmed his hypothesis (Barbour, 1966).

In general, the effectiveness of models is explained by their brightness and conceptual
integrity. Models suggest properties, attitudes and perspectives to scientists
research areas. Sometimes models are misleading; as a rule, this leads to an excessive generalization of metaphor. The search for the ether is a good example of excessive generalization of the model.

Sometimes people simplify the essence of metaphors. For each of the examples described so and
pulls answer: “Of course, the correct metaphor is more useful. Another metaphor
it was wrong! ”That's the way it is, but it’s too simplistic. The history of science is not a series of transitions from “wrong” metaphors to “true”. This is a series
transitions from "less good" metaphors to "best."

Software development is a relatively young field of science. She is not enough
mature to have a set of standard metaphors. Therefore, it includes mass
secondary and contradictory metaphors. Some of them are better than others - worse.
Because how well you understand metaphors, your understanding also depends
software development.

How to use metaphors?

The metaphor for software development looks more like a spotlight than a road map. She does not say where to find the answer - she says how to find it. Metaphor is more a heuristic approach than an algorithm.

The differences between algorithm and heuristics are subtle, and in some ways these two concepts overlap. The main difference between them, I will consider the degree of indirection of the decision. The algorithm gives you the commands themselves. Heuristics tell you how to find commands yourself or at least where to find them.

Next, consider the popular metaphors that characterize software development.

Literary metaphor: writing code

The most primitive metaphor describing software development, originates in the expression "writing code." According to the literary metaphor, the development of a program is similar to writing a letter: you sit down at the table, take paper, pen, and write a letter from beginning to end. This does not require any formal planning, and the thoughts expressed in the letter are formulated by the author along the way.

Such an approach can be practical if you write a banal letter to your aunt. However, the extension of the metaphor of "writing" software up to the ejection of the first
a copy of the program is not the best advice in the world of software development, where a large system is already on a par with the 10-story office building or ocean liner.

Agricultural metaphor: growing system

Some developers state that software development should be considered
analogies with growing crops. You design a separate block, encode it, test it and add it to the system, slightly expanding with
each time its functionality. Such a division of the task into many small actions allows minimizing the problems that can be encountered at each stage.

The weakness of this metaphor lies in the assumption that you do not have a direct
control over the development of software. You simply sow the seeds of the code in the spring and, if so
It will be the will of the Great Pumpkin, in the fall will receive an unprecedented harvest code.

Pearl Metaphor: slow increment system

Sometimes, speaking of growing software, they actually mean increment, or
accretion (accretion). These two metaphors are closely related, but the second is more convincing. The increment characterizes the process of pearl formation due to the deposition of small amounts of calcium carbonate. In geology and jurisprudence, accretion is understood as an increase in the land area through the deposition of rocks contained in water.

This does not mean that you should master the creation of code from sedimentary rocks; This means that you must learn to add to software systems by a small fragment at a time. In other words, who therefore come to
mind, are the terms "incremental", "iterative", "adaptive" and "evolutionary." Incremental design, engineering and testing are among the most effective software development concepts.

The advantage of an incremental metaphor is that it does not make excessive promises. Moreover, it is not as easily amenable to undue expansion as an agricultural metaphor. A shell forming a pearl is a good way to render incremental development, or accretion.

Construction metaphor: building software

The metaphor of “building” software is more useful than the metaphors of “writing” or “growing” software, because it is consistent with the idea of ​​software accretion and provides more detailed guidance. Building software implies the presence of planning, preparation and execution stages, the type and severity of which depend on the specific project. In studying this metaphor, you will find other parallels.

To build a meter tower requires a solid hand, a flat surface and
10 beer cans, for a tower 100 times higher is not enough to have
100 times more beer cans. Such a project requires a completely different planning and design.

Combining Metaphors

Metaphors have a heuristic, not an algorithmic nature, therefore
they are not mutually exclusive. You can use both the accretion metaphor and the construction metaphor. If you want, you can think of software development as writing a letter, combining this metaphor with driving a car, hunting werewolves, or a dinosaur image stuck in a resin pool. Use any metaphors or combinations of them that stimulate your thinking or help you communicate with other members of the group.

Using metaphors is a delicate matter. To metaphor led you to valuable
heuristic guesses, you should expand it. But if it is expanded too much or in the wrong direction, it can be misleading. Like any
powerful tools, metaphors can be used in the wrong way, however
thanks to their power, they can become a valuable component of your intellectual toolkit.

Important points:
- Comparison of software design with the construction of the building indicates the need for thorough preparation for the project and clarifies the distinction between large and small projects.
- The analogy between software development methods and tools in a programmer’s intelligent toolkit suggests that
Programmers have many different tools and that no tool is universal. Choosing the right tool is one of the conditions for effective programming.
- Metaphors do not exclude each other. Use a combination of metaphors,
most effective in your case.

Measure seven times, cut once: prerequisites

Before construction begins, builders look at the drawings, check whether all permits have been obtained, and examine the foundation. For the construction of a skyscraper, a dwelling house and a dog kennel, the builders would prepare differently, but whatever the project, before the start of the design they would conduct a fair preparation taking into account all the features of the project.

In this chapter, we will look at the components of software design preparation. how
and in construction, the ultimate success of a software project is largely determined before construction begins. If the foundation is unreliable or planning is done carelessly, at best you can
only minimize harm

Importance of prerequisites

A common feature of all programmers who create high-quality software is the use of high-quality methods that emphasize software quality in
beginning, middle and end of the project.

Design is the middle stage of work, so by the time construction began, the success of the project was already partially predetermined. And yet during construction, you should at least be able to determine how well your situation is, and go back if black clouds of failure appear on the horizon.

The most compelling argument in favor of fulfilling preconditions before construction begins.

Let's say you have already climbed the mountain to identify the problem, walked a mile along the way
requirements, dropped dirty clothes at the fountain of architecture and
bathed in clear waters of preparedness. Consequently, you know that before
the implementation of the system you need to understand what and how it will do.

Creating a software system is like any other project that requires
human and financial resources. Building a house does not start with clogging
nails, and with the creation, analysis and approval of drawings. When developing software, having a technical plan means nothing less.

Preparation for the project is one of the main conditions for effective programming, and this is logical. The amount of planning depends on the scale of the project. From a managerial point of view, planning involves determining the timing, number of people and computers needed to complete the work. From the technical - planning implies getting an idea about the system being created, which allows not to spend money on creating the wrong system. Sometimes users do not clearly know what they want to receive, and it may take more effort than they would like to determine their requirements. Anyway, it’s cheaper than to create something that’s not necessary, to deliver the result and start all over again. Before starting to create a system, it is equally important to think about how you are going to create it. No one wants to spend time and money on fruitless wanderings through the maze.

Scientists from companies Hewlett-Packard, IBM, Hughes Aircraft, TRW and others
organizations found that fixing an error at the beginning of construction costs 10-100 times less than eliminating it at the end of the project, during testing of the application or after its release (Fagan, 1976; Humphrey, Snyder, and Willis, 1991; Leffingwell 1997 ; Willis et al., 1998; Grady, 1999; Shull et al., 2002; Boehm and Turner, 2004).

Determine the type of software you are working on

What are you developing?
- Embedded systems on which people's lives depend
- Business Systems
- Target systems

When developing business systems, it is preferable to use high-iterative approaches in which the planning, development of requirements and design architecture are interspersed with the design, testing of the system and quality assurance. Systems on which people's lives depend require more consistent approaches, since stability of requirements is one of the conditions for the highest system reliability.

The impact of iterative approaches on preconditions

Some people argue that when using iterative methods, there is no need to bother with preliminary conditions, but this point of view is incorrect. Iterative approaches weaken the consequences of inadequate training, but not
eliminate them.

Iterative project with a reduced program of preliminary
conditions or without it differs from a similar sequential project by two
aspects. First, with an iterative approach, the cost of fixing defects is usually lower, because defects are detected earlier.

Secondly, with iterative approaches, costs are distributed throughout the project,
rather than grouped at its end. In the end, with both iterative and sequential approaches, the total cost will be similar, but in the first case
it will not seem so big because it will be paid in parts.

One popular rule of thumb is to determine about 80% of the requirements in advance, allow time for defining additional requirements later and perform systematic change control as you work, accepting only the most important requirements. Another option is possible: you can define in advance 20% of only the most important requirements and develop the rest of the software in small fragments, defining additional requirements and refining them - modifying the application draft as you progress.

You can choose a more consistent approach (where issues are resolved in advance) if:
- requirements are fairly stable;
- the project of the application is simple and relatively clear;
- the development team is familiar with the application area;
- the project is not associated with a special risk;
- long-term predictability of the project is important;
- the cost of changing the requirements, the project application and the code is likely
prove to be high.

A more iterative approach (in which questions are solved as work progresses) can be preferred if:
- the requirements are relatively incomprehensible or it seems to you that they may be unstable for other reasons;
- the project of the application is complicated, not entirely clear, or both;
- the development team is unfamiliar with the application area;
- the project is associated with high risk;
- the long-term predictability of the project does not play a special role;
- the cost of changing the requirements, the project application and the code is likely
will be low.

Be that as it may, iterative approaches are more effective than consistent ones. You can adapt the prerequisites to your specific project as you see fit, making them more or less formal or complete.

Problem Prerequisites

The first precondition that needs to be fulfilled before construction is a clear statement of the problem that the system must solve.

The definition of a problem is simply a statement of the essence of the problem without any
or hints of its possible solutions. It may take a couple of pages, but
must necessarily sound like a problem. The phrase “our Gigatron system cannot handle order processing” sounds like a problem and is a good definition. However, the phrase “we need to optimize the automated data entry module for the Gigatron system to handle order processing” -
poor definition of the problem. It does not seem to be a problem, but a solution.
The definition of the problem precedes the elaboration of detailed requirements, which
is a deeper investigation of the problem.

The problem should be formulated in a language understandable to the user, and the problem itself should be described from a user point of view. Usually a problem
should not be formulated in computer terms, because the optimal
her decision may not be a computer program. Let's say you need to calculate the annual profit. Calculating quarterly earnings you already
computerized. If you get stuck on programming, decide that
in the existing application you just need to add the function to calculate the annual
profits with all the ensuing consequences: labor costs
developers, etc. If you think a little, then just raise a little
salary to a secretary who will, once a year, sum up four numbers on
calculator.

Exceptions to this rule are valid if the problem is related to computers: programs compile too slowly, or programming tools are full of errors. In such cases, the problem can be formulated in computer terms that are familiar to programmers.

Without having a good definition of a problem, you can spend efforts on solving the wrong problem.

Requirements Prerequisites

The importance of an explicit set of requirements is due to several reasons:
- Explicit requirements help to ensure that the functionality of the system is determined by the user, not the programmer. If requirements are formulated
obviously, the user can analyze and approve them.

- Having explicit requirements helps to avoid disputes.

- Attention to requirements helps to minimize system changes after starting development. Finding an error in the code when encoding, you change a few lines and the work will continue. If during coding you find an error in the requirements, you will have to change the design of the program to match the changed requirements.

Software Stability Myth

Perhaps you think the Pontiac Aztec is the most magnificent car
ever created, are members of the Society of Believers in the Flat Earth
and every four years you make a pilgrimage to Roswell, New Mexico, on
aliens landing site. If so, you can continue to believe that
Requirements in your projects will not change. If you have already ceased to believe
in Santa Claus or at least stopped admit it, you can have something
undertake to reduce dependency on changes in minimum requirements.

What to do when requirements change during program design?

Assess the quality of the requirements using the checklist
given at the end of the section. If the requirements are not good enough, stop working, go back and correct them.

- Make sure everyone knows the price of changing requirements . Thinking about new
features, customers are excited. Their blood liquefies, overwhelms the medulla, and they euphoric, forgetting about all meetings devoted to the discussion of requirements, about the signing ceremony and all documents. To calm down such drugged people with new functions is easiest, saying: “Wow, this is a really great idea! But it’s not in the requirements document, so I have to revise the work schedule and budget so that you can decide whether you want to implement it right now or later. ” The words "schedule" and "estimate" sober much better than coffee and cold shower, and many requirements quickly turn into wishes.

- Set the change control procedure

- Use development approaches that adapt to change.

- Leave the project if the requirements are especially unsuccessful.

- Remember the business model of the project

Checklist: Requirements

The following checklist contains questions to determine the quality of the requirements. Neither the book nor this list will teach you to correctly develop requirements. Use it during construction to determine how solid the land you are standing on is.

Not all questions will be relevant for your project. If you are working on
informal project, on some issues do not even need to think. Other questions are important, but do not require formal answers. However, if you are working on a large formal project, you should probably answer each question.

Specific functional requirements

- Have all methods of data entry into the system been determined, indicating the source, accuracy, range of values ​​and frequency of input?
- Are all methods of data output defined by the system, indicating the purpose, accuracy, range of values, frequency and format?
- Are all output formats defined for Web pages, reports, etc.?
- Are all external hardware and software interfaces defined?
- Are all external communication interfaces defined with connection protocols, error checking and communication?
- Are all the tasks that the user needs to be done?
- Are the data used in each task and the data resulting from each task determined?

Specific non-functional requirements (quality requirements)

- Is the user expected response time for all necessary operations?
- Are other time parameters defined, such as data processing time, their transfer rate and system capacity?
- Is the level of system security determined?
- Has the reliability of the system been determined, including such aspects as consequences of failures in its operation, information that should be protected from failures, and an error detection and correction strategy?
- Are the minimum requirements of the program for the amount of memory and
free disk space?
- Are the aspects of system maintenance convenience defined, including the ability of the system to adapt to changes in specific functions, operating systems and interfaces with other applications?
- Is the definition of success included in the requirements? Or failure?

Quality requirements

- Are the requirements written in a language understandable to users? Do users agree with this?
- Are there any conflicts between the requirements?
- Has an acceptable balance been established between antagonist parameters, such as resistance to abnormality of initial prerequisites and correctness?
- Are there any design elements in the requirements?
- Is the level of detail requirements agreed? Should there be any requirement to define in more detail? Less detail?
- Are the requirements sufficiently clear and understandable so that they can be transferred to an independent design team? Do developers agree with that?
- Is every requirement relevant to the problem and its solution? Is it possible to trace every requirement to its source in the problem environment?
- Is it possible to test every requirement? Will it be possible to conduct independent testing, which will tell whether all requirements are met?
- Are all possible changes in requirements and probability of each change determined?

Completeness of requirements

- Are the missing requirements indicated that cannot be determined before the start of development?
- Are the requirements complete in the sense that if the application meets all the requirements, it will be acceptable?
- Do you have any requirements for discomfort? Have you excluded requirements that are not amenable to implementation and were included only to calm the client or the boss?

Steve mcconnell