1. Конструирование
1.1. Основы конструирования
1.1.1. Минимизация сложности
1.1.1.1. придание большей значимости читаемости кода, простоте тестирования, приемлемому уровню производительности и удовлетворению заданных критериев
1.1.2. Ожидание изменений
1.1.2.1. большинство программных систем изменяются с течением времени. Ожидание изменений является одной из движущих сил конструирования программного обеспечения.
1.1.3. Конструирование с возможностью проверки
1.1.3.1. предполагает, что построение программных систем должно вестись таким образом, чтобы сама программная система помогала вести поиск причин сбоев, будучи прозрачной для применения различных методов проверки, как на стадии независимого тестирования, так и в процессе операционной деятельности - эксплуатации, когда особенно важна возможность быстрого обнаружения и исправления возникающих ошибок.
1.1.3.1.1. обзор, оценка кода
1.1.3.1.2. модульное тестирование
1.1.3.1.3. структурирование кода совместно с применениям автоматизированных средств тестирования
1.1.3.1.4. ограниченное применение сложных или тяжелых для понимания языковых структур
1.1.4. Стандарты в конструировании
1.1.4.1. Использование внешних стандартов
1.1.4.1.1. Конструирование зависит от внешних стандартов, связанных с языками программирования, используемым инструментальным обеспечением, техническими интерфейсами и взаимным влиянием Конструирования программного обеспечения и других областей знаний программной инженерии
1.1.4.2. Использование внутренних стандартов
1.1.4.2.1. Определенные стандарты, соглашения и процедуры могут быть также созданы внутри организации или даже проектной команды. Эти стандарты поддерживают координацию между определенными видами деятельности, группами операций, минимизируют сложность, могут быть связаны с вопросами ожидания и обработки изменений, рисков и вопросами конструирования для проверки и дальнейшего тестирования.
1.2. Управление конструированием
1.2.1. Модели конструирования
1.2.1.1. определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. В большинстве случаев, модели конструирования определяются используемым стандартом жизненного цикла, применяемыми методологиями и практиками.
1.2.2. Планирование конструирования
1.2.2.1. Планирование конструкторской деятельности определяет порядок, в котором создаются компоненты и другие активы данной области знаний (фазы деятельности), проводятся работы по обеспечению качества получаемого программного обеспечения, распределяются задачи и соответствующие ресурсы, в том числе, определяются назначения/отображения работ конкретным инженерам- программистам, членам проектной группы.
1.2.3. Измерения в конструировании
1.2.3.1. Большая часть результатов, да и самой деятельности по конструированию программного обеспечения, может быть измерена, в том числе - количественно. Это и исходный разработанный код, и модифицированный объем кода, и степень повторного использования, и многие другие характеристики. Эти измерения, или как их еще принято называть – результаты аудита кода и метрики кода, несут большую пользу для оценки рисков и качества, а также, для управления конструированием и программными проектами, в целом.
1.3. Практические соображения
1.3.1. Проектирование в конструировании
1.3.1.1. Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования; другие проекты явно выделяют проектную деятельность в форме фазы дизайна. Вне зависимости от четкости выделения деятельности по проектированию, как таковой, практически всегда на стадии конструирования приходится заниматься и вопросами детального дизайна системы.
1.3.2. Языки конструирования
1.3.2.1. включают все формы коммуникаций, с помощью которых человек может задать решение проблемы, выполняемое на компьютере.
1.3.2.1.1. конфигурационный язык
1.3.2.1.2. инструментальный язык
1.3.2.1.3. язык программирования
1.3.2.2. нотации, используемые при определении языков программирования
1.3.2.2.1. Лингвистические
1.3.2.2.2. Формальные
1.3.2.2.3. Визуальные
1.3.3. Кодирование
1.3.3.1. техники создания легко понимаемого исходного кода на основе использования соглашений об именовании, форматирования и структурирования кода
1.3.3.2. использование классов, перечисляемых типов, переменных, именованных констант и других выразительных сущностей
1.3.3.3. организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и другие структуры)
1.3.3.4. использование структур управления
1.3.3.5. обработка ошибочных условий и исключительных ситуаций
1.3.3.6. предотвращение возможных брешей в безопасности (например, переполнение буфера или выход за пределы индекса в массиве)
1.3.3.7. использование ресурсов на основе применения механизмов исключения и порядка доступа к параллельно используемым ресурсам (например, на основе блокировки данных, использования потоков и их синхронизации и т.п.)
1.3.3.8. документирование кода
1.3.3.9. тонкая “настройка” кода
1.3.3.10. рефакторинг
1.3.4. Тестирование
1.3.4.1. Главная цель тестирования в конструировании уменьшить временной разрыв между моментом проявления ошибок, имеющихся в коде, и моментом их обнаружения.
1.3.4.1.1. модульное тестирование
1.3.4.1.2. интеграционное тестирование
1.3.4.2. IEEE Std 829-1998: “IEEE Standard for Software Test Documentation”
1.3.4.3. IEEE Std 1008-1987: “IEEE Standard for Software Unit Testing”
1.3.5. Повторное использование
1.3.5.1. задачи
1.3.5.1.1. выбор единиц (units), баз данных тестовых процедур, данных <полученных в результате> тестов и самих тестов, подлежащих повторному использованию
1.3.5.1.2. оценка потенциала повторного использования кода и тестов
1.3.5.1.3. отслеживание информации и создание отчетности по повторному использованию в новом коде, тестовых процедурах и данных, полученных в результате тестов.
1.3.6. Качество
1.3.6.1. техники обеспечения качества
1.3.6.1.1. модульное (unit) и интеграционное (integration) тестирование
1.3.6.1.2. разработка с первичностью тестов
1.3.6.1.3. пошаговое кодирование
1.3.6.1.4. использование процедур утверждений
1.3.6.1.5. отладка
1.3.6.1.6. технические обзоры и оценки
1.3.6.1.7. статический анализ
1.3.7. Интеграция
1.3.7.1. планирование последовательности, в которой интегрируются компоненты
1.3.7.2. обеспечение поддержки создания промежуточных версий программного обеспечения
1.3.7.3. задание “глубины” тестирования и других работ по обеспечению качества интегрируемых в дальнейшем компонент
1.3.7.4. определение этапных точек проекта, когда будут тестироваться промежуточные версии конструируемой программной системы.
2. Тестирование
2.1. Основы тестирования
2.1.1. Терминология тестирования
2.1.1.1. Тестирование - процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определённым образом
2.1.1.2. Тестирование – это наблюдение за выполнением программы, запущенной в целях тестирования с заданными параметрами, по заданному сценарию или с другими заданными начальными условиями или целями тестирования. Эффективность теста может быть определена только в контексте заданных условий.
2.1.2. Ключевые вопросы
2.1.2.1. Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования
2.1.2.2. Эффективность тестирования
2.1.2.3. Тестирование для идентификации дефектов
2.1.2.3.1. Данный случай тестирования подразумевает успешность процедуры тестирования, если дефект найден.
2.1.2.4. Теоретические и практические ограничения тестирования
2.1.2.5. Проблема неосуществимых путей
2.1.2.5.1. путь, по которому выполняются потоки работ тестируемой программной системы, не могут быть заданы входными параметрами.
2.1.2.6. Тестируемость
2.1.2.6.1. описывает степень легкости описания критериев покрытия тестами для заданной программной системы.
2.1.2.6.2. определяет возможность вероятность, возможность статистического измерения того, что при тестировании проявится сбой программной системы.
2.1.3. Связь тестирования с другой деятельностью
2.1.3.1. Тестирование программного обеспечения отличается от статических техник управления качеством, проверки корректности, отладки и программирования, но связано со всеми этими работами. Полезно рассматривать тестирование с точки зрения аналитиков и специалистов по сертификации качества.
2.2. Уровни тестирования
2.2.1. Над чем производятся тесты
2.2.1.1. тесты производятся над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий.
2.2.2. Цели тестирования
2.2.2.1. Примочное тестирование
2.2.2.1.1. Проверяет поведение системы на предмет удовлетворения требований заказчика.
2.2.2.2. Установочное тестирование
2.2.2.2.1. данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.
2.2.2.3. Альфа- и бета-тестирование
2.2.2.3.1. Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки.
2.2.2.4. Функциональные тесты/тесты соответствия
2.2.2.4.1. проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.
2.2.2.5. Достижение и оценка надежности
2.2.2.5.1. повышение надежности программных систем.
2.2.2.6. Регрессионное тестирование
2.2.2.6.1. повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходит и после внесения таковых.
2.2.2.7. Тестирование производительности
2.2.2.7.1. Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности.
2.2.2.8. Нагрузочное тестирование
2.2.2.8.1. Необходимо понимать отличия между рассмотренным выше тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы.
2.2.2.9. Сравнительное тестирование
2.2.2.9.1. Единичный набор тестов, позволяющих сравнить две версии системы.
2.2.2.10. Восстановительные тесты
2.2.2.10.1. Проверка возможностей рестарта системы в случае непредусмотренной катастрофы, влияющей на функционирование операционной среды, в которой выполняется система.
2.2.2.11. Конфигурационное тестирование
2.2.2.11.1. В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях.
2.2.2.12. Тестирование удобства и простоты использования
2.2.2.12.1. Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; насколько эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя.
2.2.2.13. Разработка, управляемая тестированием
2.2.2.13.1. стиль организации процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью требований
2.3. Техники тестирования
2.3.1. Техники, базирующиеся на интуиции и опыте
2.3.1.1. Специализированное тестирование
2.3.1.1.1. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий.
2.3.1.2. Исследовательское тестирование
2.3.1.2.1. Одновременное обучение, проектирование теста и его исполнение. Данный вид тестирования заранее не определяется в плане тестирования и такие тесты создаются, выполняются и модифицируются динамически, по мере необходимости
2.3.2. Техники, базирующиеся на спецификации
2.3.2.1. Эквивалентное разделение приложения
2.3.2.1.1. Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик спецификации.
2.3.2.2. Анализ граничных значений
2.3.2.2.1. Тесты строятся с ориентацией на использование тех величин, которые определяют предельные характеристики тестируемой системы. Расширением этой техники являются тесты оценки живучести системы, проводимые с величинами, выходящими за рамки специфицированных пределов значений.
2.3.2.3. Таблицы принятия решений
2.3.2.3.1. Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве “входов”) и действиями (могут рассматриваться как “выходы”). Набор тестов строится последовательным рассмотрением всех возможных кросс-связей в такой таблице.
2.3.2.4. Тесты на основе конечного автомата
2.3.2.4.1. Строятся как комбинация тестов для всех состояний и переходов между состояниями, представленных в соответствующей модели (переходов и состояний приложения).
2.3.2.5. Тестирование на основе формальной спецификации
2.3.2.5.1. Для спецификации, определенных с использованием формального языка, возможно автоматически создавать и тесты для функциональных требований.
2.3.2.6. Случайное тестирование
2.3.2.6.1. В отличие от статистического тестирования, сами тесты генерируются случайным образом по списку заданного набора специфицированных характеристик.
2.3.3. Техники, ориентированные на код
2.3.3.1. Тесты, базирующиеся на блок-схеме
2.3.3.1.1. Набор тестов строится исходя из покрытия всех условий и решений блок-схемы.
2.3.3.2. Тесты на основе потоков данных
2.3.3.2.1. В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть до уничтожения (неопределенности). В реальной практике используются нестрогое тестирование такого вида, ориентированное, например, только на проверку задания начальных значений всех переменных или всех вхождений переменных в код, с точки зрения их использования.
2.3.3.3. Ссылочные модели для тестирования, ориентированного на код
2.3.3.3.1. Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов
2.3.3.4. Тестирование, ориентированное на дефекты
2.3.3.4.1. тесы ориентированные на ошибки, точнее – на специфические категории ошибок.
2.3.3.5. Предположение ошибок
2.3.3.5.1. Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, в результате анализа рисков.
2.3.3.6. Тестирование мутаций
2.3.3.6.1. Мутация – небольшое изменение тестируемой программы, произошедшее за счет частных синтаксических изменений кода (в частности, рефакторинга). Соответствующие тесты запускаются для оригинального и всех “мутировавших” вариантов тестируемой программы.
2.3.4. Техники, базирующиеся на условиях использования
2.3.4.1. Операционный профиль
2.3.4.1.1. Базируется на условиях использования системы. Тестирование для оценки надёжности системы должно проводиться в таком тестовом окружении, которое максимально приближено к реальным условиям работы системы. Результаты таких тестов позволяют оценить поведение системы в реальных условиях.
2.3.4.2. Тестирование, базирующееся на надежности инженерного процесса
2.3.4.2.1. Базируется на условиях разработки системы. Соответствующие тесты проектируются в контексте используемого процесса разработки и методик тестирования.
2.3.5. Техники, базирующиеся на природе приложения
2.3.5.1. Объектно-ориентированное тестирование
2.3.5.2. Компонентно-ориентированное тестирование
2.3.5.3. Web-ориентированное тестирование
2.3.5.4. Тестирование на соответствие протоколам
2.3.5.5. Тестирование систем реального времени
2.3.6. Выбор и комбинация различных техник
2.4. Измерение результатов тестирования
2.4.1. Оценка программ в процессе тестирования
2.4.2. Оценка выполненных тестов
2.5. Процесс тестирования
2.5.1. Практические соображения
2.5.2. Тестовые работы
3. Поддержка и эксплуатация (сопровождение)
3.1. Основы поддержки и эксплуатации
3.1.1. Определения и терминология
3.1.1.1. Сопровождение программного обеспечения определяется стандартом IEEE Standard for Software Maintenance (IEEE 1219) как модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик. стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных процессов жизненного цикла. Международный стандарт ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) определяет сопровождение программного обеспечения в тех же терминах, что и стандарт 12207
3.1.2. Природа сопровождения
3.1.2.1. сопровождение, с точки зрения операций отслеживания и контроля, обладает большим содержанием, чем разработка (в общем понимании). поддерживает функционирование программного продукта на протяжении всего операционного жизненного цикла, то есть периода его эксплуатации. В процессе сопровождения фиксируются и отслеживаются запросы на модификацию
3.1.3. Потребность в сопровождении
3.1.3.1. Сопровождение необходимо для обеспечения того, чтобы программный продукт на протяжении всего периода эксплуатации удовлетворяет требованиям пользователей. Деятельность по сопровождению применима для программного обеспечения, созданного с использованием любой модели жизненного цикла. нужно для устранение сбоев - улучшение дизайна - реализация расширений функциональных возможностей> -создание интерфейсов и тд
3.1.4. Приоритет стоимости сопровождения
3.1.4.1. более 80% усилий по сопровождению связаны не столько устранением сбоев, сколько с другими работами, не связанными с исправлением дефектов
3.1.5. Эволюция ПО
3.1.5.1. В процессе эволюционирования, программная система становится все более сложной до тех пор, пока не предпринимаются специальные усилия (в том числе, в рамках специального проекта по модификации) по уменьшению его сложности.
3.1.6. Категории сопровождения
3.1.6.1. Корректирующее сопровождение (corrective maintenance): “реактивная” модификация программного продукта, выполняемая уже после передачи в эксплуатацию для устранения сбоев; Адаптирующее сопровождение (adaptive maintenance): модификация программного продукта на этапе эксплуатации для обеспечения продолжения его использования с заданной эффективностью (с точки зрения удовлетворения потребностей пользователей) в изменившемся или находящемся в процессе изменения окружении; в первую очередь, подразумевается изменение бизнес-окружения, порождающее новые требования к системе; - Совершенствующее сопровождение (perfective maintenance): модификация программного продукта на этапе эксплуатации для повышения характеристик производительности и удобства сопровождения; - Профилактическое сопровождение (preventive maintenance): модификация программного продукта на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до того, когда они приведут к реальным сбоям.
3.2. Ключевые вопросы поддержки и эксплуатации
3.2.1. Технические вопросы
3.2.1.1. ограниченное понимание
3.2.1.1.1. Ограниченное понимание подразумевает как быстро инженер по сопровождению может понять где необходимо внести исправления или изменения в код системы, которую он не разрабатывал.
3.2.1.2. анализ
3.2.1.2.1. Анализ влияния описывает как проводить (в частности, с точки зрения эффективности затрат) полный анализ возможных последствий и влияний изменений, вносимых в существующую систему.
3.2.1.3. тестирование
3.2.1.3.1. Стоимость повторения полного набора тестов для основных модулей системы может быть существенным как по времени, так и по стоимости.
3.2.1.4. Возможность сопровождения
3.2.1.4.1. Возможность сопровождения или сопровождаемость программной системы определяется, например, глоссарием IEEE (стандарт 610.12-90 Standard Glossary for Software Engineering Terminology, обновление 2002 года) как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований.
3.2.2. Управленческие вопросы
3.2.2.1. Процесс (в общем случае, жизненный цикл, прим. автора) является набором работ (activities), методов, практик и, своего рода, трансформаций, которые используются людьми для разработки и сопровождения программных систем и ассоциированных с ними продуктов
3.2.2.2. Заимствованный термин “аутсоурсинг” уже прижился не только в среде ИТ-менеджеров, он стал частью современного бизнеса и управленческих практик. Суть его заключается в передаче работ, в первую очередь, вспомогательных (непрофильных для организации) “на сторону
3.2.2.3. Организационные цели описывают как продемонстрировать возврат инвестиций от деятельности по сопровождению программного обеспечения
4. Проектирование
4.1. Основы проектирования
4.1.1. Контекст программного дизайна( Общие концепции проектирования)
4.1.1.1. К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения.
4.1.2. Процесс проектирования
4.1.2.1. двух-шаговый процесс: Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент; Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент.
4.1.2.1.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.3.1.5. Разделение интерфейса и реализации
4.1.3.1.6. Достаточность, полнота и простота
4.2. Ключевые вопросы проектирования
4.2.1. Параллелизм в проектировании
4.2.1.1. Охватывает вопросы, подходы и методы организации процессов, задач и потоков для обеспечения эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.
4.2.2. Контроль и обработка событий
4.2.2.1. тема касается и неявных методов обработки событий, часто реализуемых в виде функции обратного вызова (call-back), как одной из фундаментальных концепций обработки событий.
4.2.3. Ошибки, обработка исключений и защищенность от сбоев
4.2.3.1. как предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее функционирование системы
4.2.4. Взаимодействие и представление
4.2.4.1. вопросы представления информации пользователям и взаимодействия пользователей с системой, с точки зрения реакции системы на действия пользователей
4.2.5. Сохраняемость данных
4.2.5.1. суть вопроса – как должны обрабатываться “долгоживущие” данные
4.3. Структура и архитектура ПО
4.3.1. Архитектурные структуры и точки зрения
4.3.1.1. Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы.
4.3.2. Архитектурные стили (макроархитектурные шаблоны)
4.3.2.1. Шаблон проектирования макро-архитектуры - на уровне модулей, "крупноблочного" взгляда. Архитектурный стиль – набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям.
4.3.3. Шаблоны проектирования (микроархитектурные шаблоны)
4.3.3.1. Общее решение общей проблемы в заданном контексте. Задают микро-архитектуру, то есть определяют частные аспекты деталей архитектуры.
4.3.3.1.1. Шаблоны создания
4.3.3.1.2. Структурные шаблоны
4.3.3.1.3. Шаблоны поведения
4.3.4. Семейство программ и фреймворков
4.3.4.1. Один из возможных подходов к повторному использованию архитектурных решений и компонент заключается в формировании линий продуктов на основе общего дизайна.
4.4. Анализ качества и оценка программного дизайна
4.4.1. Атрибуты качества
4.4.1.1. Спектр различных атрибутов, помогающих оценить и добиться качественного дизайна. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна как такового – “тестируемость”, “переносимость”, “модифицируемость”, “производительность”, “безопасность” и т.п.
4.4.2. Анализ качества и техники оценки
4.4.2.1. Инструменты, техники и практики, помогающие добиться качественного дизайна
4.4.2.1.1. Обзор дизайна
4.4.2.1.2. Статический анализ
4.4.2.1.3. Симуляция и прототипирование
4.4.3. Измерения (метрики)
4.4.3.1. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера проекта, структуры (ее сложности) или качества
4.4.3.1.1. Функционально-ориентированные
4.4.3.1.2. Объектно-ориентированные
4.5. Нотации проектирования ПО
4.5.1. Структурные описания (статическое представление)
4.5.1.1. Графические (в основном) нотации, описывающие и представляющие структурные аспекты программного дизайна.
4.5.1.1.1. Языки описания архитектуры
4.5.1.1.2. Диаграммы классов и объектов
4.5.1.1.3. Диаграммы компонентов или компонентные диаграммы
4.5.1.1.4. Карточки функциональной ответственности и связей класса
4.5.1.1.5. Диаграммы развёртывания
4.5.1.1.6. Диаграммы сущность-связь
4.5.1.1.7. Языки описания/определения интерфейса
4.5.1.1.8. Структурные диаграммы Джексона
4.5.1.1.9. Структурные схемы
4.5.2. Поведенческие описания (динамическое представление)
4.5.2.1. Используются для описания динамического поведения программных систем и их компонентов.
4.5.2.1.1. Диаграммы деятельности или операций
4.5.2.1.2. Диаграммы сотрудничества
4.5.2.1.3. Диаграммы потоков данных
4.5.2.1.4. Таблицы и диаграммы принятия решений
4.5.2.1.5. Блок-схемы и структурированные блок-схемы
4.5.2.1.6. Диаграммы последовательности
4.5.2.1.7. Диаграммы перехода и карты состояний
4.5.2.1.8. Формальные языки спецификации
4.5.2.1.9. Псевдокод и программные языки проектирования
4.6. Стратегии и методы проектирования
4.6.1. Общии стратегии
4.6.1.1. “разделяй-и-властвуй” и пошаговое уточнение
4.6.1.1.1. Метод предполагает декомпозицию (разбиение) задачи размера n на частные задачи, решение которых позволяет получить решение общей, исходной задачи.
4.6.1.2. проектирование “сверху-вниз” и “снизу-вверх”
4.6.1.2.1. Восходящее проектирование (снизу-вверх)
4.6.1.2.2. Нисходящее проектирование (сверху-вниз)
4.6.1.3. абстракция данных и сокрытие информации
4.6.1.3.1. Абстракция
4.6.1.3.2. Сокрытие информации
4.6.1.4. итеративный и инкрементальный подход
4.6.1.4.1. итеративный
4.6.1.4.2. инкрементный
4.6.2. Функционально-ориентированный (структурный дизайн)
4.6.2.1. один из классических методов проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций “сверху-вниз”.
4.6.3. Проектирование на основе структур данных
4.6.3.1. фокус сконцентрирован в большей степени на структурах данных, которыми управляет система, чем на функциях системы. Часто вначале описывают структуры данных входов и выходов, а, затем, разрабатывают структуру управления этими данными (или, например, их трансформации).
4.6.4. Компонентное проектирование
4.6.4.1. Данный подход призван решить задачи использования, разработки и интеграции программных компонентов с целью повышения повторного использования активов
4.6.5. Другие методы
5. Требования
5.1. Функциональные и нефункциональные требования
5.1.1. функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий”
5.1.1.1. Функциональные требования - то перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
5.1.1.2. Нефункциональные требования - это чёткие критерии того, как система должна работать, описание характеристик системы и ее окружения, а не поведение системы.
5.2. Основы требований
5.2.1. Определение требований
5.2.1.1. Требования - это свойства, которыми должно обладать разработанное или адаптированное ПО, для того чтобы решать поставленные задачи.
5.2.1.1.1. IEEE Standard Glossary of Software Engineering Terminology (1990) 1. условия или возможности, необходимые пользователю для решения проблем или достижения целей; 2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам; 3. документированное представление условий или возможностей для пунктов 1 и 2
5.2.1.2. Уровни требований
5.2.1.2.1. Бизнес-требования
5.2.1.2.2. Пользовательские требования
5.2.1.2.3. Продуктные требования
5.2.2. Требования к продукту и процессу
5.2.2.1. проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться
5.2.2.1.1. Требования к продукту - описание задачи или проблемы, которую хочет решить заказчик с помощью ПО Требования к процессу -формулирование требований к тому, как Разработчик будет выполнять работы по созданию целевой системы, регламентация
5.2.3. Свойства
5.2.3.1. Свойства требований
5.2.3.1.1. Полнота (нельзя задать уточняющие вопросы) (ни одна из важных для реализации деталей не упущена)
5.2.3.1.2. Ясность (недвусмысленность, определенность, однозначность спецификаций)
5.2.3.1.3. Корректность и согласованность (непротиворечивость)
5.2.3.1.4. Верифицируемость (пригодность к проверке).
5.2.3.1.5. Необходимость и полезность при эксплуатации.
5.2.3.1.6. Осуществимость (выполнимость)
5.2.3.1.7. Трассируемость (возможность отслеживания связи между требованиями)
5.2.3.1.8. Упорядоченность по важности и стабильности
5.2.3.1.9. Наличие количественной метрики
5.2.3.2. Независимые свойства
5.2.3.2.1. Эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть соотнесены с отдельными ее элементами
5.2.4. Количественные требования
5.2.4.1. требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; обязательно должны содержать указания конкретных количественных характеристик
5.2.5. Системные и программные требования
5.2.5.1. требования к системе в целом и программному обеспечению (или программной системе), в частности
5.2.5.1.1. система - “комбинация взаимодействующих элементов созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”;
5.3. Процесс
5.3.1. Модели процессов
5.3.1.1. Модель процесса определения требований - это схема процессов ЖЦ, которые выполняются от начала проекта и до тех пор, пока не будут определены и согласованы требования.
5.3.2. Участники процессов
5.3.2.1. Люди, которые участвуют в процессе работы с требованиями, для которых определяются роли. Заинтересованные лица - некто, имеющий возможность (в том числе, материальную) повлиять на реализацию проекта/продукта.
5.3.2.1.1. Пользователи (Users)
5.3.2.1.2. Заказчики (Customers)
5.3.2.1.3. Аналитики (Market analysts
5.3.2.1.4. Инженеры по программному обеспечению, иженеры-программисты (Software Enginner)
5.3.2.1.5. Регуляторы (Regulators)
5.3.3. Управление и поддержка процессов
5.3.3.1. распределение ресурсов, необходимых для осуществления проектной деятельности
5.3.3.2. обеспечение связи между процессами и деятельностью и вопросами использования проектных ресурсов – стоимостью, человеческими ресурсами, инструментами и т.п.
5.3.4. Качество и улучшение процессов
5.3.4.1. Покрытие процессов работы с требованиями с точки зрения стандартов и моделей улучшения процессов, в целом
5.3.4.2. Измерение и количественная оценка процессов работы с требованиями
5.3.4.3. Планирование и реализация процесса улучшения, как такового
5.4. Извлечение требований
5.4.1. Источники требовний
5.4.1.1. Заказчик
5.4.1.1.1. Его представления и ожидания
5.4.1.2. Администраторы и технический персонал
5.4.1.3. Нормативные документы
5.4.1.3.1. федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
5.4.1.3.2. нормативное обеспечение организации (регламенты, положения, уставы, приказы, должностные инструкции, описания бизнес-процессов)
5.4.1.4. Эксперты в данной предметной области
5.4.1.5. Конкурирующие программные продукты и их документация
5.4.1.6. Маркетинговые исследования/опросы/статистические выборки
5.4.1.7. Отчеты об ошибках, жалобы, запросы на усовершенствование
5.4.1.8. Системы, с которыми необходимо обеспечить интеграцию.
5.4.2. Стратегии выявления требований
5.4.2.1. Интервью
5.4.2.1.1. Проведения переговоров и нахождение компромисса
5.4.2.2. Анкетирование
5.4.2.2.1. письменная форма опроса, осуществляющаяся, как правило, заочно, т.е. без прямого и непосредственного контакта интервьюера с респондентом.
5.4.2.3. Наблюдение
5.4.2.3.1. сбор сведений о параметрах, признаках и объектах в соответствующей предметной области.
5.4.2.4. Самостоятельное описание требований
5.4.2.4.1. По результатам анализа документов и собственных знаний аналитик может составить описание требований и предложить его представителям Заказчика в качестве информации к размышлению, либо - основы для формирования технического задания.
5.4.2.5. Совместные семинары
5.4.2.5.1. совместная работа участников проектной команды
5.4.2.6. Прототипирование
5.4.2.6.1. Программный прототип - "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика.
5.5. Анализ требований
5.5.1. Классификация требований
5.5.1.1. Модель FURPS+
5.5.1.1.1. Функциональность
5.5.1.1.2. Удобство использования
5.5.1.1.3. + ограничения
5.5.2. Концептуальное моделирование
5.5.2.1. Разработка модели проблемы реального мира. Цель – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы.
5.5.2.2. это первоначальный этап разработки проекта
5.5.2.3. реализуется с помощью UML
5.5.2.4. построение ER-диаграмм
5.5.2.4.1. Сущность
5.5.2.4.2. Атрибут
5.5.2.4.3. Связь
5.5.3. Архитектурное проектирование и распределение требований
5.5.3.1. Архитектурное проектирование очень близко к концептуальному моделированию. Непосредственное отображение бизнес-сущностей реального мира на программные компоненты не является обязательным. Во многом поэтому и существует такое разделение между моделированием и проектированием.
5.5.3.1.1. деятельность по моделированию в большей степени касается того, ”что” надо сделать, а архитектура - “как” это будет реализовано.
5.5.3.2. Стандарт IEEE 1471-2000
5.5.3.3. Модель Захмана – Zachman Framework
5.5.3.4. TOGAF – The Open Group Architecture Framework
5.6. Спецификация требований
5.6.1. Документ определения системы (спецификация пользовательских требований), (концепция)
5.6.1.1. Документ описывает системные требования вместе с необходимой информацией о бизнес-процессах, операционном окружении с точки зрения бизнес-процедур и организационных и других регламентов.
5.6.2. Спецификация системных требований
5.6.2.1. Документ описывает программную систему в контексте системной инженерии
5.6.3. Спецификация программных требований
5.6.3.1. Программные требования устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать.
5.6.3.2. Документ может включать процедуры проверки получаемого программного обеспечения на соответствие предъявляемым ему требованиям (вплоть до содержания планов тестирования), характеристики, определяющие качество и методы его оценки, вопросы безопасности и многое другое.
5.7. Утверждение требований
5.7.1. Обзор требований
5.7.1.1. ряд лиц, вовлеченных в проект (для крупных проектов – специально выделенные специалисты), “вычитывают” требования в поисках необоснованных предположений, описаний требований, допускающих множественные интерпретации, противоречий, несогласованности, недостаточной степени детализации, отклонений от принятых стандартов и т.п.
5.7.2. Прототипирование
5.7.2.1. проверка инженерной интерпретации программных требований и извлечение новых требований, неопределенных или неясных на ранних итерациях сбора требований.
5.7.2.1.1. минусы
5.7.3. Утверждение модели
5.7.3.1. обеспечения приемлемого качества продукта, подтвержденная формально со стороны пользователей/заказчика, либо проверена с помощью использования формальных методов, например, статического анализа (поиск связей и путей взаимодействия между описанными объектами и выделение различного рода несоответствий).
5.7.4. Приемочные тесты
5.7.4.1. процесс проверки того, что решение работает для пользователя.
5.8. Практические соображения
5.8.1. Итеративная природа процесса работы с требованиями
5.8.1.1. Требования часто меняются в силу изменений бизнес-контекста для которого создается и в котором эксплуатируется программное обеспечение. Необходимо понимать неизбежность изменений и планировать шаги по уменьшению проблем, связанных с изменениями.
5.8.2. Атрибуты требований
5.8.2.1. дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков.
5.8.3. Управление изменениями
5.8.3.1. все действия, по обеспечению целостности, точности и своевременности обновления соглашения о требованиях в ходе проекта.
5.8.4. Трассировка требований
5.8.4.1. Обеспечивает связь между требованиями и отслеживание источников требований. Трассировка является фундаментальной основой проведения анализа влияния при изменении требований, помогая предсказывать эффект от внесения таких изменений.
5.8.5. Измерение требований
5.8.5.1. нечто, позволяющее определить “объем” требований для заданного (создаваемого) программного продукта. Это число полезно для исследования “масштабов” изменений в требованиях, оценки стоимостных характеристик разработки и поддержки программной системы, опосредовано – оценки продуктивности разработки и эффективности поддержки на этапах реализации требований и внесения изменений и т.п.
5.8.5.1.1. ISO/IEC