1. Требования
1.1. Основы требований
1.1.1. Определение требований
1.1.1.1. в данном случае подразумевается не процесс определения (извлечения, сбора, формирования, формулирования) требований, а дается само понятие “требования”, как такового, и отмечаются его основные характеристики, например, верифицируемость (проверяемость) требования.
1.1.2. Требования к продукту и процессору
1.1.2.1. проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться. Отмечается, что ряд требований может быть заложен неявно и программные требования могут порождать требования к процессу, например: работа в режиме 24x7 (как бизнес-требование) наверняка приведет к ограничению выбора тех или иных программных средств, платформ развертывания и архитектурных решений. В свою очередь, выбор платформы J2EE (Java 2 Enterprise Edition) и ее реализации в виде конкретного сервера приложений практически наверняка потребует применения модульного тестирования (Unit testing) как практики процесса разработки и JUnit, как инструмента реализации этой практики.
1.1.3. Функциональные и не функциональные требования
1.1.3.1. функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.
1.1.4. Независимые свойства
1.1.4.1. эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть соотнесены с отдельнымы ее элементами. Т.е. данные требования относятся к тому синергетическому эффекту, которым может обладать такая система («целое больше, чем сумма его частей»). Примером может служить требования к «пропускной способности» коллцентра, которая будут зависеть от того, каким образом будут взаимодействовать коммуникационное оборудование, оператор и программное обеспечение в конкретных условиях.
1.1.5. Количественные требования
1.1.5.1. требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост пропускной способности” без указания конкретных количественных характеристик является просто некорректно определенным требованием.
1.1.6. Системные и программные требования
1.1.6.1. данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов <созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”.
1.2. Процесс работы с требованиями
1.2.1. Модель процесса определения требований
1.2.1.1. Не является дискретным; это постоянно действующий процесс на всех этапах жизненного цикла программного обеспечения. Процесс работы с требованиями инициируется в начале проекта и продолжается на протяжении всего жизненного цикла, в плоть до завершения проекта.
1.2.1.2. Идентифицирует программные требования как элементы конфигурации (в терминах конфигурационного обеспечения) и контролирует их с использованием тех же практик конфигурационного управления, что и для других активов программных проектов (например, файлов или запросов на изменения).
1.2.1.3. Требует адаптации к проектному и/или организационному контексту, в рамках которого ведется соответствующий программный проект.
1.2.2. Участники процессов
1.2.2.1. Пользователь
1.2.2.1.1. группа, охватывающая тех людей, кто будет непосредственно использовать программное обеспечение
1.2.2.2. Заказчик
1.2.2.2.1. те, кто отвечают за заказ программного обеспечения или, в общем случае, являются целевой аудиторией на рынке программного обеспечения
1.2.2.3. Аналитик
1.2.2.3.1. продукты массового рынка программного обеспечения (как и других массовых рынков, например, бытовой техники) не обладают “заказчиками” в понимании персонификации тех, кто “заказывает разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в идентификации потребностей и обращению к тем, кто может играть роль <квалифицированных> “представителей” потребителей;
1.2.2.4. Регуляторы
1.2.2.4.1. многие области применения (“домены”) являются регулируемыми, например, телекоммуникации или банковский сектор. Программное обеспечение для ряда целевых рынков (в первую очередь, корпоративного сектора) требует соответствия руководящим документам и прохождения процедур, определяемых уполномоченными органами.
1.2.2.5. Инженеры по программному обеспечению
1.2.2.5.1. иженеры-программисты (Software Enginner): лица, обладающие обоснованным интересом к разработке программного обеспечения, например, повторному использованию тех или иных компонент, библиотек, средств и инструментов. Именно инженеры ответственны за техническую оценку путей решения поставленных задач и последующую реализацию требований заказчиков.
1.2.3. Управление и поддержка процессов
1.2.3.1. обеспечение связи между процессами и деятельностью, “модели процесса определения требований” и вопросами использования проектных ресурсов – стоимостью, человеческими ресурсами, инструментами и т.п.
1.2.4. Качество и улучшение процессов
1.2.4.1. Эта тема связана с оценкой качества процессов работы с программными требованиями и улучшением этих процессов. Особое значение данной темы заключается в подчеркивании значимости работы с требованиями, ключевой роли этих процессов для определения стоимостных и временных ресурсов, необходимых для реализации программного проекта, в целом.
1.3. Извлечение требований
1.3.1. Источники требований
1.3.1.1. Целях
1.3.1.2. Знании предметной области
1.3.1.3. Заинтересованных лицах
1.3.1.4. Операционном окружении
1.3.1.5. Организационной среде
1.3.2. Техники извлечения требований
1.3.2.1. Интервьюрирование
1.3.2.1.1. традиционный подход извлечения требований; получение информации от пользователя “не равно” получению требований; информация должна быть проанализирована и трансформирована в требования, таким образом, информация от пользователя является “входом” в процессы сбора требований, а сами требования – “выходом” этих процессов.
1.3.2.2. Сценарии
1.3.2.2.1. контекст для сбора пользовательских требований, определяющий ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями;
1.3.2.3. Прототипы
1.3.2.3.1. отличный инструмент для уточнения и/или детализации требований; существуют разные подходы к прототипированию – от “бумажных” моделей до пилотных подсистем, реализуемых как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов; часто прототипы постепенно трансформируются в результаты проекта и используются для проверки и утверждения требований.
1.3.2.4. Наблюдение
1.3.2.4.1. подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов
1.4. Анализ требований
1.4.1. Классификация требований
1.4.1.1. Функциональные и нефункциональные требования
1.4.1.2. Внутренние (с другими требованиями) или внешние зависимости
1.4.1.3. Требования к процессу или продукту
1.4.1.4. Приоритет требований
1.4.1.5. Содержание требований в отношении конкретных подсистем создаваемого программного обеспечения
1.4.1.6. Изменяемость/стабильность требований
1.4.2. Концептуальное моделирование
1.4.2.1. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы.
1.4.3. Архитектурное проектирование и распределение требований
1.5. Спецификация требований
1.5.1. Определение системы
1.5.1.1. Сборник документов , который описывает требования, возможности, ограничения, проектирование, эксплуатацию и поддержание системы.
1.5.2. Спецификация системных требований
1.5.2.1. представляет собой структурированный набор информации , которая воплощает в себе требование к системе.
1.5.3. Спецификация программных требований
1.5.3.1. устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать.
1.6. Утверждения требований
1.6.1. Обзор требований
1.6.1.1. Суть его заключается в том, что ряд лиц, вовлеченных в проект (для крупных проектов – специально выделенные специалисты), “вычитывают” требования в поисках необоснованных предположений, описаний требований, допускающих множественные интерпретации, противоречий, несогласованности, недостаточной степени детализации, отклонений от принятых стандартов и т.п.
1.6.2. Прототипирование
1.6.2.1. подразумевает проверку инженерной интерпретации программных требований и извлечение новых требований, неопределенных или неясных на ранних итерациях сбора требований. Наиболее часто прототипы создаются для оценки способа реализации пользовательского интерфейса и проверки архитектурных подходов и решений.
1.6.3. Утверждение модели
1.6.3.1. Утверждение или аттестация модели связана с вопросами обеспечения приемлемого качества продукта. Уверенность в соответствии модели заданным требованиям может быть закреплена формально со стороны пользователей/заказчика. В то же время, проверка и аттестация модели, например, объектно-ориентированного представления бизнес-сущностей и связей между ними может быть проверена с той или иной степенью использования формальных методов.
1.6.4. Приемочные тесты
1.6.4.1. Смысл приемочного теста — показать, что произойдет с системой в конкретном сценарии. Для этого в сценарии должно быть описано, как выглядит система в начале теста, затем описывается какое-то действие, которое эту систему меняет. Это может быть воздействие снаружи, а может быть и какой-то внутренний триггер. В результате система немного меняет свое состояние, что и является критерием успешности. Важный момент: система рассматривается как черный ящик. Другими словами, формулируя тест, мы не знаем, как система устроена внутри и с чем она взаимодействует снаружи.
2. Проектирование
2.1. Основы проектирования
2.1.1. Общие концепции проектирования
2.1.1.1. Улучшение и повышение продуктивности бизнес-процессов
2.1.1.2. Уменьшение затрат
2.1.1.3. Улучшение операционной бизнес-деятельности
2.1.1.4. Повышение эффективности управления
2.1.1.5. Уменьшение рисков
2.1.1.6. Повышение эффективности ИТ-организации
2.1.1.7. Повышение продуктивности работы пользователей
2.1.1.8. Повышение интероперабельности (возможности и прозрачности взаимодействия)
2.1.1.9. Уменьшение стоимости <поддержки> жизненного цикла
2.1.1.10. Улучшение характеристик безопасности
2.1.1.11. Повышение управляемости
2.1.2. Контекст проектирования
2.1.2.1. Осуществляется проектирование и используются его результаты. В качестве такого контекста выступает жизненный цикл программной инженерии, а проектирование напрямую связано с результатами анализа требований, конструированием программных систем и их тестированием.
2.1.3. Процесс проектирования
2.1.3.1. Архитектурное проектирование
2.1.3.1.1. декомпозиция структуры (статической) и организации (динамической) компонент;
2.1.3.2. Детализация архитектуры
2.1.3.2.1. описывает специфическое поведение и характеристики отдельных компонент.
2.1.4. Техники применения
2.1.4.1. Абстракция
2.1.4.1.1. В контексте проектирования программных систем существует два механизма абстракции – параметризация и специфицирование (может интерпретироваться как детализация). При этом, абстракция через специфицирование бывает трех видов: процедурная абстракция (динамическая, то есть в отношении поведения), абстракция данных (статическая, то есть в отношении информации) и абстракция контроля (то есть управления системой и обрабатываемой ею информацией).
2.1.4.2. Связанность и соединение
2.1.4.2.1. Определяет силу связи (часто, взаимного влияния) между модулями.Соединение (Cohesion)– определяет как тот или иной элемент обеспечивает связь внутри модуля, внутреннюю связь.Связанность (Coupling)– определяет силу связи (часто, взаимного влияния) между модулями.Соединение (Cohesion)– определяет как тот или иной элемент обеспечивает связь внутри модуля, внутреннюю связь.
2.1.4.3. Декомпозиция и разбиение на модули
2.1.4.3.1. Декомпозиция и разбиение на модули сложных программных систем производится с целью получения более мелких и относительно независимых программных компонентов, каждый из которых несет различную функциональность (логически связанные группы функциональности).
2.1.4.4. Инкапсуляция/сокрытие информации
2.1.4.4.1. Данная концепция предполагает группировку и упаковку (с точки зрения подготовки к развертыванию и эксплуатации) элементов и внутренних деталей абстракции (то есть модели) в отношении реализации с тем, чтобы эти детали (как малозначимые для использования компонента или по другим причинам) были недоступны пользователям элементов (компонент).
2.1.4.5. Разделение интерфейса и реализации
2.1.4.5.1. Данная техника предполагает определение компонента через специфицирование интерфейса, известного (описанного) и доступного клиентам (или другим компонентам), от непосредственных деталей реализации.
2.1.4.6. Достаточность, полнота и простота
2.1.4.6.1. Этот подход подразумевает, что создаваемые программные компоненты обладают всеми необходимыми характеристиками, определенными абстракцией (моделью), но не более того. То есть не включают функциональность, отсутствующую в модели.
2.2. Ключевые вопросы проектирования
2.2.1. Параллелизм в проектировании
2.2.1.1. Эта тема охватывает вопросы, подходы и методы организации процессов, задач и потоков для обеспечения эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.
2.2.2. Контроль и обработка событий
2.2.2.1. В самом названии данной темы заложен комплекс обсуждаемых вопросов. В частности, данная тема касается и неявных методов обработки событий, часто реализуемых в виде функции обратного вызова (call-back), как одной из фундаментальных концепций обработки событий.
2.2.3. Распределение компонентов
2.2.3.1. Распределение (и выполнение) по различным узлам обработки в терминах аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших вопросов данной темы – использование связующего программного обеспечения (middleware*)
2.2.4. Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости
2.2.4.1. Вопрос темы, как ни странно, формулируется достаточно просто – как предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее функционирование системы.
2.2.5. Взаимодействие и представление
2.2.5.1. Тема касается вопросов представления информации пользователям и взаимодействия пользователей с системой, с точки зрения реакции системы на действия пользователей. Речь в этой теме идет о реакции системы в ответ на действия пользователей и организации ее отклика с точки зрения внутренней организации взаимодействия.
2.3. Структура и архитектура
2.3.1. Архитектурные структуры и точки зрения
2.3.1.1. Любая система может рассматриваться с разных точек зрения – например, поведенческой (динамической), структурной (статической), логической (удовлетворение функциональным требованиям), физической (распределенность), реализации (как детали архитектуры представляются в коде) и т.п. В результате, мы получаем различные архитектурные представления (view). Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы. В свою очередь, дизайн системы – комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения требований, предъявляемых к системе.
2.3.2. Архитектурные стили(макроархитектурные шаблоны)
2.3.2.1. набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям.
2.3.3. Шаблоны проектирования(микроархитектурные шаблоны)
2.3.3.1. общее решение общей проблемы в заданном контексте. Если мы хотим организовать системы таким образом, чтобы существовал один и только один экземпляр заданного ее компонента в процессе работы с данной системой – мы можем использовать шаблон проектирования “Singleton”, описывающий такое общее поведение.
2.3.4. Семейства программ и фреймворков
2.3.4.1. Один из возможных подходов к повторному использованию архитектурных решений и компонент заключается в формировании линий продуктов (product lines) на основе общего дизайна. В объектно-ориентированном программировании аналогичную смысловую нагрузку несут “фреймворки”, обеспечивающие решение одних и тех же задач – например, внутренней организации компонентов пользовательского интерфейса или общей логики работы распределенных систем.
2.4. Анализ качества и оценка дизайна
2.4.1. Атрибуты качества
2.4.1.1. Существует целый спектр различных атрибутов, помогающих оценить и добиться качественного дизайна. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна как такового – “тестируемость”, “переносимость”, “модифицируемость”, “производительность”, “безопасность” и т.п. Важно понимать, что обсуждаемые атрибуты касаются только дизайна (как результата), но не проектирования (как процесса). В принципе, все эти атрибуты можно разбить на несколько групп:
2.4.1.1.1. применимые к run-time
2.4.1.1.2. ориентированные на design-time
2.4.1.1.3. атрибуты качества архитектурного дизайна
2.4.2. Анализ качества и техники оценки
2.4.2.1. В индустрии распространены многие инструменты, техники и практики, помогающие добиться качественного дизайна:
2.4.2.1.1. обзор дизайна
2.4.2.1.2. статический анализ
2.4.2.1.3. симуляция и прототипирование
2.4.3. Измерения
2.4.3.1. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера <проекта>, структуры (ее сложности) или качества (например, в контексте требований, предъявляемых к производительности). Чаще всего, все метрики разделяют по двум категориям:
2.4.3.1.1. функционально-ориентированные
2.4.3.1.2. объектно-ориентированные
2.5. Нотации проектирования
2.5.1. Структурные описания(статическое представление)
2.5.1.1. как правило, графические, используются для представления структурных аспектов проекта — компонентов и их взаимосвязей, элементов архитектуры и их интерфейсов. К ним относятся формальные языки спецификаций и проектирования: ADL (Architecture Description Language), UML (Unified Modeling Language), IDL (Interface Description Language), диаграммы «сущность — связь» — ERD (Entity-Relation Diagrams), диаграммы классов и компонентов, диаграммы Джексона, структуры и схемы классов (CRC Cards) и др.
2.5.2. Поведенческие описания(динамическое представление)
2.5.2.1. используются для описания динамических аспектов функционирования систем и их компонентов. К ним относятся диаграммы потоков данных, диаграммы действий (потоков управления), диаграммы взаимодействия объектов, диаграммы переходов состояний, таблицы решений, блок-схемы, формальные языки спецификации, псевдокод, язык проектирования PDL и др.
2.6. Стратегии и методы проектирования
2.6.1. Общие стратегии
2.6.1.1. относятся: «разделяй и властвуй», «пошаговое уточнение», «снизу вверх», «сверху вниз», «абстракция данных», «применение паттернов и языков паттернов», «применение итеративного и инкрементного подходов» и др.
2.6.2. Функционально-ориентированный (структурный) дизайн
2.6.2.1. базируются на структурном анализе, структурных картах, диаграммах потоков данных и др. Они ориентированы на идентификацию функций и их уточнение сверху вниз и последующую разработку диаграмм потоков данных и описание процессов.
2.6.3. Проектирование на основе структур данных
2.6.3.1. В данном подходе фокус сконцентрирован в большей степени на структурах данных, которыми управляет система, чем на функциях системы. Инженеры по программному обеспечению часто вначале описывают структуры данных входов (inputs) и выходов (outputs), а, затем, разрабатывают структуру управления этими данными (или, например, их трансформации).
2.6.4. Компонентное проектирование
2.6.4.1. Программные компоненты являются независимыми единицами, которые обладают однозначно-определенными (well-defined) интерфейсами и зависимостями (связями) и могут собираться и развертываться независимо друг от друга. Данный подход призван решить задачи использования, разработки и интеграции таких компонент с целью повышения повторного использования активов (как архитектурных, так и в форме кода).
2.6.5. Другие методы
2.6.5.1. Другие интересные, но менее распространенные подходы, в основном, представляют собой формальные и точные (строгие) методы, а также, методы трансформации.
3. Конструирование
3.1. Основы конструирования
3.1.1. Минимизация сложности
3.1.1.1. Уменьшение сложности достигается через акцентирование создания кода, который был бы простым и читаемым, а не искусным. Минимизация сложности получается путём использования стандартов и посредством многочисленных специфических методов написания кода.
3.1.2. Ожидание изменений
3.1.2.1. Большинство программных систем изменяются с течением времени. Ожидание изменений является одной из движущих сил конструирования программного обеспечения
3.1.3. Конструирование с возможностью проверки
3.1.3.1. Оценка кода
3.1.3.2. Модульное тестирование
3.1.3.3. Структурирование кода
3.1.3.4. Ограниченное применение сложных для понимания языковых структур
3.1.4. Стандарты в конструировании
3.1.4.1. Коммуникационные методы
3.1.4.1.1. например, стандарты форматов документов и оформления содержания
3.1.4.2. Языки программирования
3.1.4.3. Платформы
3.1.4.3.1. например, стандарты программных интерфейсов для вызовов функций операционной среды, такие как прикладные программные интерфейсы платформы Windows — Win 32 API, Application Programming Interface или .NET Framework SDK
3.1.4.4. Инструменты
3.1.4.4.1. например, UML как один из стандартов для определения нотаций для диаграмм, представляющих структура кода и его элементов или некоторых аспектов поведения кода
3.1.4.5. Использование внешних стандартов
3.1.4.5.1. Конструирование зависит от внешних стандартов, связанных с языками программирования, используемым инструментальным обеспечением, техническими интерфейсами и взаимным влиянием Конструирования программного обеспечения и других областей знаний программной инженерии. Стандарты создаются разными источниками, например, консорциумом OMG – Object Management Group (в частности, стандарты CORBA, UML, MDA, …), международными организациями по стандартизации, такими как ISO/IEC, IEEE, TMF, …, производителями платформ, операционных сред и т.д. (например, Microsoft, Sun Microsystems, CISCO, NOKIA, …), производителями инструментов, систем управления базами данных и т.п. (Borland, IBM, Microsoft, Sun, Oracle, ..). Понимание этого факта позволяет определить достаточный и полный набор стандартов, применяемых в проектной команде или организации в целом.
3.1.4.6. Использование внутренних стандартов
3.1.4.6.1. Определенные стандарты, соглашения и процедуры могут быть также созданы внутри организации или даже проектной команды. Эти стандарты поддерживают координацию между определенными видами деятельности, группами операций, минимизируют сложность, могут быть связаны с вопросами ожидания и обработки изменений, рисков и вопросами конструирования для проверки и дальнейшего тестирования. В сочетании со внешними стандартами, внутренние стандарты призваны определить общие правила игры для всех членов проектной команды, договорившись о терминах, процедурах и других значимых соглашениях, вне зависимости от степени формализации процессов конструирования, в частности, и процессов жизненного цикла, в общем случае.
3.2. Управление конструированием
3.2.1. Модели конструирования
3.2.1.1. определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. В большинстве случаев, модели конструирования определяются используемым стандартом жизненного цикла, применяемыми методологиями и практиками.
3.2.2. Планирование конструирования
3.2.2.1. Используемый подход к конструированию влияет на возможность уменьшения (в идеале - минимизации) сложности, готовности к изменениям и конструировании с возможностью проверки.
3.2.3. Измерения в конструировании
3.2.3.1. Большая часть результатов, да и самой деятельности по конструированию программного обеспечения, может быть измерена, в том числе - количественно. Это и исходный разработанный код, и модифицированный объем кода, и степень повторного использования, и многие другие характеристики. Эти измерения, или как их еще принято называть – результаты аудита кода и метрики кода, несут большую пользу как для оценки рисков и качества, а также, для управления конструированием и программными проектами, в целом.
3.3. Практические соображения
3.3.1. Проектирование в конструировании
3.3.2. Языки конструирования
3.3.2.1. конфигурационный язык
3.3.2.1.1. позволяющий задавать параметры выполнения программной системы.
3.3.2.2. Инструментальный язык
3.3.2.2.1. язык конструирования из повторно-используемых элементов; обычно строится как сценарный язык (script), выполняемый в соответствующей среде.
3.3.2.3. Язык программирования
3.3.2.3.1. наиболее гибкий тип языков конструирования. Содержит минимальный объем информации о конкретных областях приложения и процессе разработки, требуя больше всего усилий на изучение и наработку опыта для эффективного применения при решении конкретных задач.
3.3.3. Кодирование
3.3.3.1. техники создания легко понимаемого исходного кода на основе использования соглашений об именовании, форматирования и структурирования кода;
3.3.3.2. использование классов, перечисляемых типов, переменных, именованных констант и других выразительных сущностей
3.3.3.3. организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и другие структуры)
3.3.3.4. использование структур управления
3.3.3.5. бработка ошибочных условий и исключительных ситуаций
3.3.3.6. предотвращение возможных брешей в безопасности (например, переполнение буфера или выход за пределы индекса в массиве)
3.3.3.7. использование ресурсов на основе применения механизмов исключения (из рассмотрения) и порядка доступа к параллельно используемым ресурсам (например, на основе блокировки данных, использования потоков и их синхронизации и т.п.)
3.3.3.8. документирование кода
3.3.3.9. тонкая “настройка” кода
3.3.4. Тестирование
3.3.4.1. модульное тестирование
3.3.4.1.1. процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки.
3.3.4.2. интеграционное тестирование
3.3.4.2.1. дна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
3.3.5. Повторное исползование
3.3.6. Качество
3.3.6.1. Деятельность по обеспечению качества в конструировании отличается от других операций по обеспечению качества. Основное отличие заключается в фокусе на программном (исходном) коде и других артефактах (активах), тесно связанных с кодом, в частности, детальных моделях.
3.3.7. Интеграция
3.3.7.1. Одна из ключевых деятельностей, осуществляемых в процессе конструирования, - интеграция отдельно сконструированных операций (процедур), классов, компонентов и подсистем (модулей). В дополнение к этому, некоторые программные системы нуждаются в специальной интеграции с другим программным и аппаратным обеспечением.
4. Тестирование
4.1. Основы тестирования
4.1.1. Терминология тестирования
4.1.2. Ключевые вопросы
4.1.3. Связь тестирования с другой деятельностью
4.2. Уровни тестирования
4.2.1. Над чем производятся тесты
4.2.2. Цели тестирования
4.3. Техники тестирования
4.3.1. Техники, базирующиеся на интуиции и опыте
4.3.2. Техники, базирующиеся на спецификации
4.3.3. Тестирование, ориентированное на дефекты
4.3.4. Техники, базирующиеся на условиях использования
4.3.5. Техники, базирующиеся на природе приложения
4.3.6. Выбор и комбинация различных техник
4.4. Метрики, связанные с тестированием
4.4.1. Оценка программ в процессе тестирования
4.4.2. Оценка выполненных тестов
4.5. Процесс тестирования
4.5.1. Практические соображения
4.5.2. Тестовые работы