| Russian | English |
| восходящее тестирование: последовательный подход к интеграционному тестированию, при котором компоненты нижнего уровня тестируются первыми и затем используются для облегчения тестирования компонентов более высокого уровня. этот процесс повторяется до тех пор, пока компонент на самом верху иерархии не будет протестирован | bottom-up testing: An incremental approach to integration testing where the lowest level components are tested first, and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested (см. Standard glossary of terms used in Software Testing) |
| всё сказанное означает, что разработчик ПО должен быть готов создавать ПО, которое можно приспосабливать к изменениям. этого требует сама природа ПО. Программное обеспечение должно быть приемлемым понятным, обслуживаемым и расширяемым | this said, a software engineer must be prepared to build software that can accommodate change. That is the demanded nature of software. Software must be supportable understandable, maintainable and scalable (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| как было сказано выше, пакеты могут быть сгруппированы и структурированы в иерархические уровни, подходящие для выбранной структуры ПО. Так как пакет может содержать другие пакеты, уровень сам является пакетом. В UML пакет уровня может быть обозначен как "layer" | as stated before, packages can be grouped and structured into hierarchical layers supportive of the chosen software architecture. Since a package may contain other packages, a layer is a package itself. In the UML a layer package can be stereotyped as "layer" (уровень; см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering) |
| ключевое слово C++, означающее, что член класса доступен только из функций-членов или друзей самого класса и наследующих ему | protected (члены класса с этим спецификатором доступа называют защищёнными) |
| лучшая и самая передовая технология | superior technology (ssn) |
| лучший и самый передовой | superior (ssn) |
| многочисленные механизмы синхронизации и взаимодействия, обеспечивающие удовлетворение самых разнообразных запросов | numerous synchronization and communication mechanisms tailored for different requirements (ssn) |
| можно сказать, что практика управляемой тестированием разработки раздел 12.2 является частичной заменой рефакторинга. Действительно, управляемая тестированием разработка использует разновидность рефакторинга – разновидность, которая применяется для улучшения скорее самого проекта, а не кода. Управляемая тестированием разработка – итеративный и пошаговый процесс, объединённый с написанием прикладного кода. Рефакторинг может предугадать "дурно пахнущий код" и устранить его до того, как это случится | it can be argued that the practice of test-driven development Section 12.2 is a partial substitution for refactoring. In reality, test-driven development uses a variation of refactoring – a variation that applies to cleaning up the design rather than the code. Test-driven development is an iterative and incremental process intermixed with writing the application code. Refactoring can anticipate "bad smells in code" and eliminate them before they happen (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| Одно популярное практическое правило состоит в том, чтобы заблаговременно определить около 80% требований, предусмотреть время для более позднего определения дополнительных требований и выполнять по мере работы систематичный контроль изменений, принимая только самые важные требования | one common rule of thumb is to plan to specify about 80 percent of the requirements up front, allocate time for additional requirements to be specified later, and then practice systematic change control to accept only the most valuable new requirements as the project progresses (см. Code Complete / Steve McConnell.-2nd ed. 2004) |
| самые важные требования и архитектурные элементы | the most critical requirements and architectural elements (ssn) |
| так как детали доступа к объектам приложения в значительной мере зависят от самого приложения и его реализации, мы не станем останавливаться на этом вопросе | Because the details of accessing application objects depend heavily on the application and its implementation, we shall not pursue them here (см. Introduction to Algorithms Second Edition by Thomas H. Cormen et al. 2001) |
| тестирование "сверху вниз": инкрементальный подход к интеграционному тестированию, в котором компоненты из верхнего уровня иерархии объектов тестируются в первую очередь, с использованием заглушек вместо компонентов более низкого уровня. Протестированные компоненты используются для тестирования компонентов более низкого уровня и данный процесс повторяется до тех пор, пока не будут протестированы компоненты самого низшего уровня | top-down testing: An incremental approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested (см. Standard glossary of terms used in Software Testing ssn) |
| чтобы сделать главный шаг в направлении абстракции данных, нужно стать на противоположную точку зрения: забыть на некоторое время о конкретном представлении и взять в качестве определения структуры данных операции сами по себе | the key step towards data abstraction is to reverse the viewpoint: forget for the moment about the representation, take the operations themselves as defining the data structure (см. Object-Oriented Software Construction second edition by Bertrand Meyer) |
