| English | Russian |
| accessed later via alias names | доступный по псевдонимам (англ. термин взят из кн.: Shukla A. Building Web Apps with Spring 5 and Angular Alex_Odeychuk) |
| accessed later via alias names | доступный по альтернативным именам (англ. термин взят из кн.: Shukla A. Building Web Apps with Spring 5 and Angular Alex_Odeychuk) |
| additional requirements to be specified later | более позднее определение дополнительных требований (ssn) |
| allocate time for additional requirements to be specified later | предусматривать время для более позднего определения дополнительных требований (ssn) |
| can be executed later | может быть выполнен позже (ssn) |
| capture/playback tool: A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that can be executed later i.e. replayed. These tools are often used to support automated regression testing | средство захвата / воспроизведения: тип инструмента выполнения тестов, в котором входная информация записывается во время ручного тестирования с целью создания автоматизированных тестовых сценариев, которые могут быть выполнены позже т.е. повторены. Эти средства часто используют для поддержки автоматизированного регрессионного тестирования (см. Standard glossary of terms used in Software Testing) |
| changes in requirements in the later stages of the project | изменение требований на поздней стадии выполнения проекта (ssn) |
| finish no later than | закончить не позже чем (негибкое ограничение ssn) |
| for later use | для последующего использования (ssn) |
| in C# 8.0 and later | в языке программирования C# 8.0 и выше |
| later expansion | последующее расширение (ssn) |
| later processing | дальнейшая обработка (ssn) |
| Like all software production, architectural design is a continuing, iterative and incremental, effort. Early architectural decisions take a broad view on the software architecture. One of the first decisions to be taken relates to structuring the system into layers of modules and establishing principles of inter-module communication. This is the concern of this chapter. More detailed architectural solutions, such as intra-module communication, are discussed in relevant places later in the book | как и всё производство ПО, структурное проектирование – непрерывная, итерационная и пошаговая работа. Первоначально структурные решения принимаются на основе широкого взгляда на структуру ПО. Одно из первых принятых решений касается структурирования системы на уровни модулей и установления принципов связи между модулями. это тема данной главы. Более детальные структурные решения, типа связи внутри модуля, рассматриваются позже в соответствующих местах книги (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| 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 | Одно популярное практическое правило состоит в том, чтобы заблаговременно определить около 80% требований, предусмотреть время для более позднего определения дополнительных требований и выполнять по мере работы систематичный контроль изменений, принимая только самые важные требования (см. Code Complete / Steve McConnell.-2nd ed. 2004) |
| shelf the feature for a later time | отложить развёртывание функциональности на более поздний срок (Alex_Odeychuk) |
| start no later than | начать не позже чем (негибкое ограничение ssn) |
