1. Процесс проектирования
1.1. Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде.
1.1.1. Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент.
1.1.2. Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент.
2. Измерения в конструировании
2.1. Большая часть результатов, да и самой деятельности по конструированию программного обеспечения, может быть измерена, в том числе - количественно. Это и исходный разработанный код, и модифицированный объем кода, и степень повторного использования, и многие другие характеристики. Эти измерения, или как их еще принято называть – результаты аудита кода и метрики кода, несут большую пользу как для оценки рисков и качества (приводящих к соответствующим операциям по снижению рисков и повышению качества), а также, для управления конструированием и программными проектами, в целом.
3. Проектирование
3.1. Основы проектирования
3.1.1. Вводит концепции, понятия и терминологию в качестве основы для понимания роли и содержания проектирования (как деятельности) и дизайна (архитектуры, как результата) программного обеспечения.
3.1.1.1. Общие концепции проектирования
3.1.1.1.1. Цель архитектуры
3.1.1.1.2. Ограничения
3.1.1.1.3. Возможные альтернативы
3.1.1.1.4. Используемые представления и решения
3.1.1.2. Контекст программного дизайна
3.1.1.2.1. Контекст, в котором осуществляется проектирование и используются его результаты. В качестве такого контекста выступает жизненный цикл программной инженерии, а проектирование напрямую связано с результатами анализа требований, конструированием программных систем и их тестированием.
3.1.1.3. Техники применения
3.1.1.3.1. Являются ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в различных методах и подходах к проектированию программного обеспечения.
3.2. Ключевые вопросы проектирования
3.2.1. Параллелизм в проектировании
3.2.1.1. Охватывает вопросы, подходы и методы организации процессов, задач и потоков для обеспечения эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.
3.2.2. Контроль и обработка событий
3.2.2.1. Данная тема касается и неявных методов обработки событий, часто реализуемых в виде функции обратного вызова (call-back), как одной из фундаментальных концепций обработки событий.
3.2.3. Распределение компонентов
3.2.3.1. Распределение (и выполнение) по различным узлам обработки в терминах аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших вопросов данной темы – использование связующего программного обеспечения.
3.2.4. Ошибки, обработка исключений и защищенность от сбоев
3.2.4.1. Как предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее функционирование системы.
3.2.5. Взаимодействие и представление
3.2.5.1. Касается вопросов представления информации пользователям и взаимодействия пользователей с системой, с точки зрения реакции системы на действия пользователей. Речь в этой теме идет о реакции системы в ответ на действия пользователей и организации ее отклика с точки зрения внутренней организации взаимодействия.
3.2.6. Сохраняемость данных
3.2.6.1. Тема касается не доступа к базам данных, как такового, а также не гарантий сохранности информации. Суть вопроса – как должны обрабатываться “долгоживущие” данные.
3.3. Структура и архитектура
3.3.1. Описание подсистем и компонент программной системы, а также связей между ними. Архитектура пытается определить внутреннюю структуру получаемой системы, задавая способ, которым система организована или конструируется.
3.3.1.1. Архитектурные структуры и точки зрения
3.3.1.1.1. Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы. В свою очередь, дизайн системы – комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения требований, предъявляемых к системе.
3.3.1.2. Архитектурные стили (макроархитектурные шаблоны)
3.3.1.2.1. Архитектурный стиль, по своей сути, шаблон проектирования макро-архитектуры - на уровне модулей, "крупноблочного" взгляда.
3.3.1.3. Шаблоны проектирования (микроархитектурные шаблоны)
3.3.1.3.1. Шаблон проектирования, может звучать так – “общее решение общей проблемы в заданном контексте”. В то время, как архитектурный стиль определяет макро-архитектуру системы, шаблоны проектирования задают микро-архитектуру, то есть определяют частные аспекты деталей архитектуры.
3.3.1.4. Семейства программ и фреймворков
3.3.1.4.1. Обеспечивают решение одних и тех же задач – например, внутренней организации компонентов пользовательского интерфейса или общей логики работы распределенных систем.
3.4. Стратегии и методы проектирования
3.4.1. Общие стратегии
3.4.1.1. Это обычно часто упоминаемые и общепринятые стратегии: 1. “разделяй-и-властвуй” и пошаговое уточнение 2. проектирование “сверху-вниз” и “снизу-вверх” 3. абстракция данных и сокрытие информации 4. итеративный и инкрементальный подход
3.4.2. Функционально-ориентированный (структурный) дизайн
3.4.2.1. Это один из классических методов проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций “сверху-вниз”.
3.4.3. Проектирование на основе структур данных
3.4.3.1. В данном подходе фокус сконцентрирован в большей степени на структурах данных, которыми управляет система, чем на функциях системы.
3.4.4. Компонентное проектирование
3.4.4.1. Программные компоненты являются независимыми единицами, которые обладают однозначно- определенными интерфейсами и зависимостями (связями) и могут собираться и развертываться независимо друг от друга. Данный подход призван решить задачи использования, разработки и интеграции таких компонент с целью повышения повторного использования активов
3.4.5. Другие методы
3.4.5.1. Другие интересные, но менее распространенные подходы, в основном, представляют собой формальные и точные (строгие) методы, а также, методы трансформации.
3.5. Нотации проектирования
3.5.1. Структурные описания (статическое представление)
3.5.1.1. Языки описания архитектуры (Architecture description language, ADL): текстовые языки, часто – формальные, используемые для описания программной архитектуры в терминах компонентов и коннекторов
3.5.1.2. Диаграммы классов и объектов (Class and object diagrams): используются для представления набора классов и <статических> связей между ними (например, наследования);
3.5.1.3. Диаграммы компонентов или компонентные диаграммы (Component diagrams): в определенной степени аналогичны диаграммам классов, однако, в силу специфики концепции или понятия компонента*, обычно, представляются в другой визуальной форме;
3.5.1.4. Карточки <функциональной> ответственности и связей класса (Class responsibility collaborator card, CRC): используются для обозначения имени класса, его ответственности (то есть, что он должен делать) и других сущностей с которыми он связан; часто их называют карточками “класс-обязанность-кооперация”;
3.5.1.5. Диаграммы развѐртывания (Deployment diagrams): используется для представления (физических) узлов, связей между ними и моделирования других физических аспектов системы;
3.5.1.6. Диаграммы сущность-связь (Entity-relationship diagram, ERD или ER): используется для представления концептуальной модели данных, сохраняемых в процессе работы информационной системы;
3.5.1.7. Языки описания/определения интерфейса (Interface Description Languages, IDL): языки, подобные языкам программирования, не включающие возможностей описания логики системы и предназначенные для определения интерфейсов программных компонентов (имѐн и типов экспортируемых или публикуемых операций);
3.5.1.8. Структурные диаграммы Джексона (Jackson structure diagrams): используются для описания структур данных в терминах последовательности, выбора и итераций (повторений);
3.5.1.9. Структурные схемы (Structure charts): описываю структуру вызовов в программах (какой модуль вызывает, кем и как вызываем).
3.5.2. Поведенческие описания (динамическое представление)
3.5.2.1. Диаграммы деятельности или операций (Activity diagrams): используются для описания потоков работ и управления;
3.5.2.2. Диаграммы сотрудничества (Collaboration diagrams): показывают динамическое взаимодействие, происходящее в группе объектов и уделяют особое внимание объектам, связям между ними и сообщениям, которыми обмениваются объекты посредством этих связей;
3.5.2.3. Диаграммы потоков данных (Data flow diagrams, DFD): описывают потоки данных внутри набора процессов
3.5.2.4. Таблицы и диаграммы <принятия> решений (Decision tables and diagrams): используются для представления сложных комбинаций условий и действий (операций);
3.5.2.5. Блок-схемы и структурированные блок-схемы (Flowcharts and structured flowcharts): применяются для представления потоков управления (контроля) и связанных операций;
3.5.2.6. Диаграммы последовательности (Sequence diagrams): используются для показа взаимодействий внутри группы объектов с акцентом на временной последовательности сообщений/вызовов;
3.5.2.7. Диаграммы перехода и карты состояний(State transition and statechart diagrams): применяются для описания потоков управления переходами между состояниями;
3.5.2.8. Формальные языки спецификации (Formal specification languages): текстовые языки, использующие основные понятия из математики (например, множества) для строгого и абстрактного определения интерфейсов и поведения программных компонентов, часто в терминах пред- и пост-условий;
3.5.2.9. Псевдокод и программные языки проектирования (Pseudocode and program design languages, PDL): языки, используемые для описания поведения процедур и методов, в основном на стадии детального проектирования; подобны структурным языкам программирования.
4. Конструирование
4.1. Основы конструирования
4.1.1. Минимизация сложности
4.1.1.1. Уменьшение сложности в конструировании программного обеспечения достигается при уделении особого внимания созданию простого и легко читаемого кода, пусть и в ущерб стремлению сделать его идеальным (например, с точки зрения гибкости или следования тем или иным представлениям о красоте, утончённости кода, ловкости тех или иных приемов, позволяющих его сократить в ущерб размерам и т.п.).
4.1.2. Ожидание изменений
4.1.2.1. Является одной из движущих сил конструирования программного обеспечения. Программное обеспечение не является изолированным от внешнего окружения (как системного, так и с точки зрения области деятельности, для автоматизации задач и проблем которого оно применяется). Более того, программные системы являются частью изменяющейся среды и должны меняться вместе с ней, а, иногда, и быть источником изменений самой среды.
4.1.3. Конструирование с возможностью проверки
4.1.3.1. Построение программных систем должно вестись таким образом, чтобы сама программная система помогала вести поиск причин сбоев, будучи прозрачной для применения различных методов проверки, как на стадии независимого тестирования (например, инженерами-тестировщиками), так и в процессе операционной деятельности - эксплуатации, когда особенно важна возможность быстрого обнаружения и исправления возникающих ошибок.
4.1.3.1.1. Обзор, оценка кода
4.1.3.1.2. Модульное тестирование
4.1.3.1.3. Структурирование кода для и совместно с применениям автоматизированных средств тестирования
4.1.3.1.4. Ограниченное применение сложных или тяжёлых для понимания языковых структур
4.1.4. Стандарты в конструировании
4.1.4.1. Стандарты, которые напрямую применяются при конструировании, включают: 1. коммуникационные методы (например, стандарты форматов документов и <оформления> содержания) 2. языки программирования и соответствующие стили кодирования 3. платформы 4. инструменты (не в терминах сред разработки, но возможных средств конструирования – например, UML как один из стандартов для определения нотаций для диаграмм, представляющих структура кода и его элементов или некоторых аспектов поведения кода)
4.2. Практические соображения
4.2.1. Проектирование в конструировании
4.2.1.1. Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования
4.2.2. Языки конструирования
4.2.2.1. Языки конструирования включают все формы коммуникаций, с помощью которых человек может задать решение проблемы, выполняемое на компьютере.
4.2.2.1.1. Конфигурационный язык (configuration language), позволяющий задавать параметры выполнения программной системы.
4.2.2.1.2. Инструментальный язык (toolkit language) – язык конструирования из повторно-используемых элементов; обычно строится как сценарный язык (script), выполняемый в соответствующей среде.
4.2.2.1.3. Язык программирования (programming language) – наиболее гибкий тип языков конструирования. Содержит минимальный объем информации о конкретных областях приложения и процессе разработки, требуя больше всего (по сравнению с другими типами языков конструирования) усилий на изучение и наработку опыта для эффективного применения при решении конкретных задач.
4.2.2.2. Определение языков программирования
4.2.2.2.1. Лингвистическая
4.2.2.2.2. Формальная
4.2.2.2.3. Визуальная
4.2.3. Кодирование
4.2.3.1. Техники создания легко понимаемого исходного кода на основе использования соглашений об именовании, форматирования и структурирования кода.
4.2.3.2. Использование классов, перечисляемых типов, переменных, именованных констант и других выразительных сущностей.
4.2.3.3. Организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и другие структуры).
4.2.3.4. Использование структур управления.
4.2.3.5. Обработка ошибочных условий и исключительных ситуаций.
4.2.3.6. Предотвращение возможных брешей в безопасности (например, переполнение буфера или выход за пределы индекса в массиве).
4.2.3.7. Использование ресурсов на основе применения механизмов исключения (из рассмотрения) и порядка доступа к параллельно используемым ресурсам (например, на основе блокировки данных, использования потоков и их синхронизации.
4.2.3.8. Документирование кода.
4.2.3.9. Тонкая “настройка” кода.
4.2.4. Тестирование в конструировании
4.2.4.1. Тестирование в конструировании обычно не включает системного тестирования, нагрузочного тестирования, usability-тестирования (оценки прозрачности использования) и других видов тестовой деятельности.
4.2.4.1.1. Виды тестирования
4.2.4.1.2. Задачи, связанные с повторным использованием в процессе конструирования и тестирования
4.2.5. Качество
4.2.5.1. Основные техники конструирования
4.2.5.1.1. Модульное (unit) и интеграционное (integration) тестирование
4.2.5.1.2. Разработка с первичностью тестов (test-first development - тесты пишутся до конструирования кода)
4.2.5.1.3. Пошаговое кодирование
4.2.5.1.4. Использование процедур утверждений
4.2.5.1.5. Отладка (в привычном понимании - debugging)
4.2.5.1.6. Технические обзоры и оценки
4.2.5.1.7. Статический анализ
4.2.5.2. Деятельность по обеспечению качества в конструировании отличается от других операций по обеспечению качества. Основное отличие заключается в фокусе на программном (исходном) коде и других артефактах (активах), тесно связанных с кодом, в частности, детальных моделях.
4.2.6. Повторное использование
4.2.6.1. Реализация повторного использования программного обеспечения подразумевает и влечѐт за собой нечто большее, чем просто создание и использование библиотек активов. Оно требует формализации практики повторного использования на основе интеграции процессов и деятельности по повторному использованию в сам жизненный цикл программного обеспечения.
4.2.7. Интеграция
4.2.7.1. Интеграция отдельно сконструированных операций (процедур), классов, компонентов и подсистем (модулей).
4.2.7.1.1. Планирование последовательности, в которой интегрируются компоненты.
4.2.7.1.2. Обеспечение поддержки создания промежуточных версий программного обеспечения.
4.2.7.1.3. Задание “глубины” тестирования (в частности, на основе критериев “приемлемого” качества).
4.3. Управление конструированием
4.3.1. Модели конструирования
4.3.1.1. Модели конструирования определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. В большинстве случаев, модели конструирования определяются используемым стандартом жизненного цикла, применяемыми методологиями и практиками.
4.3.2. Планирование конструирования
4.3.2.1. Выбор метода (методологии) конструирования является ключевым аспектом для планирования конструкторской деятельности. Такой выбор значим для всей конструкторской деятельности, а также необходимых условий еѐ осуществления, определяя порядок соответствующих операций и уровень выполнения заданных условий перед тем как начнется конструирование или составляющие его действия.
5. Тестирование
5.1. Основы тестирования
5.1.1. Терминология тестирования
5.1.2. Ключевые вопросы
5.1.3. Связь тестирования с другой деятельностью
5.2. Уровни тестирования
5.2.1. Над чем производятся тесты
5.2.2. Цели тестирования
5.3. Техники тестирования
5.3.1. Техники, базирующиеся на интуиции и опыте
5.3.2. Техники, базирующиеся на спецификации
5.3.3. Тестирование, ориентированное на дефекты
5.3.4. Техники, базирующиеся на условиях использования
5.3.5. Техники, базирующиеся на природе приложения
5.3.6. Выбор и комбинация различных техник
5.4. Метрики, связанные с тестированием
5.4.1. Оценка программ в процессе тестирования
5.4.2. Оценка выполненных тестов
5.5. Процесс тестирования
5.5.1. Практические соображения
5.5.2. Тестовые работы
6. Анализ требований
6.1. Эта секция посвящена процессам анализа требований, то есть трансформации информации, полученной от пользователей (и других заинтересованных лиц) в четко и однозначно определенные требования, передаваемые инженерам для реализации в программном коде.
6.1.1. Классификация требований
6.1.1.1. 1. Функциональные и нефункциональные требования 2. Внутренние или внешние зависимости 3. Требования к процессу или продукту 4. Приоритет требований 5. Содержание требований в отношении конкретных подсистем создаваемого программного обеспечения 6. Изменяемость/стабильность требований
6.1.2. Концептуальное моделирование
6.1.2.1. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы. 1. Природа проблемы (проблемной области) 2. Экспертиза и опыт инженеров 3. Требования заказчика к процессу 4. Доступность методов и инструментов 5. Внутрикорпоративные стандарты и регламент 6. Культура разработки
6.1.3. Архитектурное проектирование и распределение требований
6.1.3.1. Архитектурное проектирование перекрывается с программным и системным дизайном (проектированием) и иллюстрирует насколько сложно провести четкую грань между различными аспектами проектирования. Существует ряд стандартов и общепринятых практик, связанных с архитектурным проектированием. Среди них наиболее популярны 1. Стандарт IEEE 1471-2000 “Recommended Practice for Architectural Description of Software Intensive Systems” 2. Модель Захмана – Zachman Framework 3. TOGAF – The Open Group Architecture Framework
7. Анализ качества и оценка дизайна
7.1. Атрибуты качества
7.1.1. Применимые к run-time, то есть ко времени выполнения системы; например, среднее время отклика системы позволяющий оценить качество дизайна с точки зрения производительности;
7.1.2. Ориентированные на design-time, то есть позволяющие оценивать качество получаемого дизайна еще на этапе проектирования или, в общем случае, вплоть до тестирования, включительно;
7.1.3. Атрибуты качества архитектурного дизайна как такового, например, концептуальная целостность дизайна, непротиворечивость, полнота, завершенность;
7.2. Анализ качества и техники оценки
7.2.1. В индустрии распространены многие инструменты, техники и практики, помогающие добиться качественного дизайна: 1. обзор дизайна (software design review); например, неформальный обзор архитектуры членами проектной команды; 2. статический анализ (static analysis); например, трассировка с требованиями; 3. симуляция и прототипирование (simulation and prototyping) – динамические техники проверки дизайна в целом или отдельных его атрибутов качества; например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым;
7.3. Измерения
7.3.1. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера <проекта>, структуры (ее сложности) или качества (например, в контексте требований, предъявляемых к производительности). Чаще всего, все метрики разделяют по двум категориям: 1. функционально ориентированные 2. объектно-ориентированные
8. Атрибуты требований
8.1. Требования должны состоять не только из описания того, что необходимо сделать, но и содержать информацию, необходимую для интерпретации требований и управления ими. Например, с пользовательскими требованиями часто ассоциируют сценарии Use Case (как в текстовом, так и графическом представлении) и, в то же время, функциональные требования часто трансформируются в задачи в терминах проектного управления, с которыми связаны параметры законченности.
9. Требования
9.1. Основы требований
9.1.1. Эта секция включает определение программных требований как таковых и описывает основные типы требований и их отличия: к продукту и процессу, функциональные и нефункциональные требования и т.п.
9.1.1.1. Определение требований
9.1.1.1.1. Условие или возможность, требуемая пользователем для решения задач или достижения целей. Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами. Документальная репрезентация (зафиксированное представление, определение, описание) условий или возможностей, перечисленных в предыдущих пунктах.
9.1.1.2. Требования к продукту и процессу
9.1.1.2.1. Проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться.
9.1.1.3. Функциональные и нефункциональные требования
9.1.1.3.1. Группа функциональных требований
9.1.1.3.2. Группа нефункциональных требований
9.1.1.3.3. Системные требования
9.1.1.4. Независимые свойства
9.1.1.4.1. Эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть соотнесены с отдельнымы ее элементами. Примером может служить требования к «пропускной способности» коллцентра, которая будут зависеть от того, каким образом будут взаимодействовать коммуникационное оборудование, оператор и программное обеспечение в конкретных условиях.
9.1.1.5. Количественные требования
9.1.1.5.1. Требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост пропускной способности” без указания конкретных количественных характеристик является просто некорректно определенным требованием.
9.1.1.6. Системные и программные требования
9.1.1.6.1. Комбинация взаимодействующих элементов для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники, службы и другие поддерживающие элементы; таким образом, подразумевается, что система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности.
9.2. Процесс работы с требованиями
9.2.1. Данная секция вводит процессы, касающиеся вопросов работы с требованиями, и в определенной степени “сшивает” в единое целое оставшиеся пять секций области знаний, посвященной требованиям к программному обеспечению.
9.2.1.1. Модели процессов
9.2.1.1.1. Не является дискретным; это постоянно действующий процесс на всех этапах жизненного цикла программного обеспечения. Процесс работы с требованиями инициируется в начале проекта и продолжается на протяжении всего жизненного цикла, в плоть до завершения проекта.
9.2.1.1.2. Идентифицирует программные требования как элементы конфигурации и контролирует их с использованием тех же практик конфигурационного управления, что и для других активов программных проектов.
9.2.1.1.3. Требует адаптации к проектному и/или организационному контексту, в рамках которого ведется соответствующий программный проект.
9.2.1.2. Участники процессов
9.2.1.2.1. Пользователи (Users): группа, охватывающая тех людей, кто будет непосредственно использовать программное обеспечение; пользователи могут описать задачи, которые они решают (планируют решать) с использованием программной системы, а также ожидания по отношению к атрибутам качества, отображаемые в пользовательских требованиях.
9.2.1.2.2. Заказчики (Customers): те, кто отвечают за заказ программного обеспечения или, в общем случае, являются целевой аудиторией на рынке программного обеспечения (образуют целевой рынок ПО);
9.2.1.2.3. Аналитики (Market analysts): продукты массового рынка программного обеспечения не обладают “заказчиками” в понимании персонификации тех, кто заказывает разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в идентификации потребностей и обращению к тем, кто может играть роль <квалифицированных> “представителей” потребителей;
9.2.1.2.4. Регуляторы (Regulators): многие области применения (“домены”) являются регулируемыми, например, телекоммуникации или банковский сектор. Программное обеспечение для ряда целевых рынков (в первую очередь, корпоративного сектора) требует соответствия руководящим документам и прохождения процедур, определяемых уполномоченными органами.
9.2.1.2.5. Инженеры по программному обеспечению, иженеры-программисты (Software Enginner): лица, обладающие обоснованным интересом к разработке программного обеспечения, например, повторному использованию тех или иных компонент, библиотек, средств и инструментов. Именно инженеры ответственны за техническую оценку путей решения поставленных задач и последующую реализацию требований заказчиков.
9.2.1.3. Управление и поддержка процессов
9.2.1.3.1. Эта тема затрагивает вопросы распределения ресурсов, необходимых для осуществления проектной деятельности. Основная цель данной темы – обеспечение связи между процессами и деятельностью, определенными в 2.1 “модели процесса определения требований” и вопросами использования проектных ресурсов – стоимостью, человеческими ресурсами, инструментами и т.п.
9.2.1.4. Качество и улучшение процессов
9.2.1.4.1. Покрытие процессов работы с требованиями с точки зрения стандартов и моделей улучшения процессов, в целом.
9.2.1.4.2. Измерение и количественная оценка (benchmarking) процессов работы с требованиями.
9.2.1.4.3. Планирование и реализация процесса улучшения, как такового.
9.3. Извлечение требований
9.3.1. Данная секция освещает вопросы сбора требований как с точки зрения организации процесса, так и определения источников, откуда поступают требования. Это первая стадия построения видения автоматизируемой проблемной области. Идентификация заинтересованных лиц, их взаимодействия, выполняемых ими бизнес-процессов – все это является ключевыми вопросами, без четкого и однозначного ответа на которые даже не стоит думать об успешности проекта.
9.3.1.1. Источники требований
9.3.1.1.1. 1. Цели 2. Знания предметной области 3. Заинтересованные лица 4. Операционное окружение 5. Организационная среда
9.3.1.2. Техники сбора требований
9.3.1.2.1. Интервьюрирование – традиционный подход извлечения требований; не стоит забывать, что получение информации от пользователя “не равно” получению требований; информация должна быть проанализирована и трансформирована в требования, таким образом, информация от пользователя является “входом” в процессы сбора требований, а сами требования – “выходом” этих процессов;
9.3.1.2.2. Сценарии – контекст для сбора пользовательских требований, определяющий ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями;
9.3.1.2.3. Прототипы – отличный инструмент для уточнения и/или детализации требований; существуют разные подходы к прототипированию – от “бумажных” моделей до пилотных подсистем, реализуемых как самостоятельные проекты или бета-версии продуктов; часто прототипы постепенно трансформируются в результаты проекта и используются для проверки и утверждения требований;
9.3.1.2.4. “Разъясняющие встречи” – особая форма встреч участников проекта и заинтересованных лиц со стороны заказчика, посвященная обсуждению тех вопросов, ответы на которые не могут быть определены в результате обычных интервью и которые требуют вовлечения большего количества лиц, чем просто пары “пользователь-аналитик”
9.3.1.2.5. Наблюдение (observation) – подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов.
9.4. Спецификация требований
9.4.1. Документ определений системы
9.4.1.1. Описывает системные требования. Содержание документа определяет высокоуровневые требования, часто – стратегические цели, для достижения которых создается программная система. Документ описывает системные требования вместе с необходимой информацией о бизнес-процессах, операционном окружении с точки зрения бизнес-процедур и организационных и других регламентов.
9.4.2. Спецификация системных требований
9.4.2.1. Спецификация системных требований описывает деятельность системных инженеров. Стандарт IEEE 1233 является одним из признанных руководств по разработке системных требований. Системные требования – один из элементов реального связывания различной инженерной деятельности - программной и системной.
9.4.3. Спецификация программных требований
9.4.3.1. Программные требования устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать. Документ может включать процедуры проверки получаемого программного обеспечения на соответствие предъявляемым ему требованиям (вплоть до содержания планов тестирования), характеристики, определяющие качество и методы его оценки, вопросы безопасности и многое другое.
9.5. Проверка требований
9.5.1. Обзор требования
9.5.1.1. Суть его заключается в том, что ряд лиц, вовлеченных в проект (для крупных проектов – специально выделенные специалисты), “вычитывают” требования в поисках необоснованных предположений, описаний требований, допускающих множественные интерпретации, противоречий, несогласованности, недостаточной степени детализации, отклонений от принятых стандартов и т.п.
9.5.2. Прототипирование
9.5.2.1. В общем случае, прототипирование подразумевает проверку инженерной интерпретации программных требований и извлечение новых требований, неопределенных или неясных на ранних итерациях сбора требований.
9.5.2.1.1. Минусы:
9.5.3. Утверждение моделей
9.5.3.1. Уверенность в соответствии модели заданным требованиям может быть закреплена формально со стороны пользователей/заказчика.
9.5.4. Приемочные тесты
9.5.4.1. Если описанное требование не сопровождается процедурами проверки – в большинстве случаев говорят о недостаточной детализации или неполном описании требования и, соответственно, спецификация требований должна быть отправлена на доработку и если необходимо, должны быть предприняты дополнительные усилия, направленные на сбор требований.
9.6. Практические соображения
9.6.1. Итеративная природа процесса работы с требованиями
9.6.1.1. Необходимо концентрироваться только на том, что требует внимания “прямо сейчас”, не закладываясь на предупреждение всех возможных рисков, в том числе связанных с изменениями, включая изменения требований.
9.6.2. Управление изменениями
9.6.2.1. Управление изменениями – одна из ключевых тем управления требованиями. Это не только вопросы контроля версий, но управление всеми активами проекта, включая код, требования, запросы на изменения
9.6.3. Трассировка требований
9.6.3.1. Трассировка требований обеспечивает связь между требованиями и отслеживание источников требований. Трассировка является фундаментальной основой проведения анализа влияния при изменении требований, помогая предсказывать эффект от внесения таких изменений. Трассировка предполагает направленную связь между требованиями, то есть зависимости.
9.6.4. Измеряемые требования
9.6.4.1. Измерение объема функциональности (Functional Size Measurement, FSM) техника такого рода численной оценки, определена на концептуальном уровне в стандарте IEEE 14143.1. Стандарты ISO/IEC и другие источники описывают частные методы FSM
10. Поддержка и эксплуатация
10.1. Основы поддержки и эксплуатации
10.1.1. Определения и терминология
10.1.2. Природа поддержки и эксплуатации
10.1.3. Потребность в поддержке и эксплуатации
10.1.4. Приоритет стоимости поддержки и эксплуатации
10.1.5. Эволюция программного обеспечения
10.1.6. Категории поддержки и эксплуатации
10.2. Ключевые вопросы поддержки и эксплуатации
10.2.1. Технические вопросы
10.2.2. Управленческие вопросы
10.2.3. Измерения в поддержке и эксплуатации
10.2.4. Оценка стоимости поддержки и эксплуатации
10.3. Процесс
10.3.1. Процессы поддержки и эксплуатации
10.3.2. Работы по поддержке и эксплуатации
10.4. Техники
10.4.1. Понимание программных систем
10.4.2. Реинжиниринг
10.4.3. Обратный инжиниринг