1. Стратегии и методы проектирования
1.1. Общие стратегии
1.1.1. Существуют различные общие стратегии, помогающие в проведении работ по проектированию.
1.2. Функционально - ориентированный
1.2.1. Это один из классических методов проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций"сверху - вниз".
1.3. Проектирование на основании структур данных
1.3.1. В данном подходе фокус сконцентрирован в большей степени на структурах данных, которыми управляет система, чем на функциях системы.
1.4. Компонентное проектирование
1.4.1. Программные компоненты являются независимыми единицами, которые обладают однозначно - определенными интерфейсами и зависимостями и могут собираться и развертываться независимо друг от друга.
1.5. Другие методы
2. как предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее функционирование системы.
3. Ключевые вопросы проектирования
3.1. Параллелизм в проектировании
3.1.1. Эта тема охватывает вопросы, подходы и методы организации процессов, эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.
3.2. Контроль и обработка событий
3.2.1. В самом названии данной темы заложен комплекс обсуждаемых вопросов. Данная тема касается и неявных методов обработки событий, часто реализуемых в виде функций обратного вызова,как одной из фундаментальных концепций обработки событий.
3.3. Ошибки обработка исключений и защищенность от сбоев
3.4. Взаимодействие и представление
3.4.1. Тема касается вопросов представления информации пользователям и взаимодействие пользователей с системой, с точки зрения реакции системы на действия пользователей.
3.5. Сохраняемость данных
3.5.1. Именно сохраняемость, а не сохранность, так как тема касается не доступа к базам данных, как такового, а также на гарантий сохранности информации. Суть вопроса - как должны обрабатываться "долгоживущие" данные.
4. Основной причиной того, почему люди используют компьютеры в бизнес - целях, являются ограниченные возможности людей в обработке и хранении сложных структур и больших объемов информации, в частности, на протяжении длительного периода времени.
5. Проектирование программного обеспечения
5.1. Основы проектирования
5.1.1. Общие концепции проектирования
5.1.1.1. Принципы проектирования, являются ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в различных методах и подходах к проектированию программного обеспечения.
5.1.1.2. К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения.
5.1.2. Контекст программного дизайна
5.1.2.1. Для понимания роли проектирования ПО важно понимать контекст, в котором осуществляется проектирование и используются его результаты.
5.1.3. Процесс проектирования
5.1.3.1. Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде.
5.1.4. Техники применения
5.2. Анализ качества и оценка программного дизайна
5.2.1. Атрибуты качества
5.2.1.1. Существует целый спектр различных атрибутов, помогающих оценить и добиться качественного дизайна. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна как такого.
5.2.2. Анализ качества
5.2.3. Изменения
5.2.3.1. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, "размера"
5.3. Нотации проектирования ПО
5.3.1. Структурные описания
5.3.1.1. Следующие нотации, в основном, являются графическими, описывая и представляя структурные аспекты программного дизайна. Чаще всего они касаются основных компонентов и связей между ними.
5.3.2. Поведение описания
5.3.2.1. Следующие нотации и языки используются для описания динамического поведения программных систем и их компонентов. Многие из этих нотаций успешно используются для проектирования деталей дизайна, но не только для этого.
6. Конструирование
6.1. Практические соображения
6.1.1. Интеграция
6.1.1.1. Одна из ключевых деятельностей. Некоторые программные системы нуждаются в специальной интеграции с другим программным и аппаратным обеспечением.
6.1.2. Модели конструирования
6.1.2.1. планирование последовательностей в которой интегрируются компоненты; обеспечение поддержки создания промежуточных версий программного обеспечения; задание "глубины"тестирования (в частности, на основе критериев "приемлемого"качества) и других работ по обеспечению качества интегрируемых в дальнейшем компонент; наконец, определение этапных точек проекта, когда будут тестироваться промежуточные версии конструируемой программной системы.
6.1.3. Качество
6.1.3.1. Существует ряд техник, предназначенных для обеспечения качества кода, выполняемых по мере его конструирования. Основные техники обеспечения качества, используемые в процессе, конструирования включают:
6.1.4. Тестирование
6.1.4.1. При конструировании используются две формы тестирования, проводимого инженерами, непосредственно создающими исходный код.
6.1.5. Повторное использование
6.1.5.1. Во введении в стандарт IEEE Std.1517-99 "IEEE Standart for Information Technology-Software Lifecycle Process - Reuse Processes"дается следующее понимание повторному использованию в программном обеспечении:"Реализация повторного использования программного обеспечения подразумевает и влечет за собой нечто больше, чем просто создание и использование библиотек и активов".
6.1.6. Кодирование в конструировании
6.1.6.1. Практика конструирования программного обеспечения показывает активное применение
6.1.7. Языки конструирования
6.1.8. Проектирование в конструировании
6.1.8.1. Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования;
6.2. Управление конструированием
6.2.1. Планирование конструирования
6.2.1.1. Выбор метода (методологии) конструирования является ключевым аспектом для планирования конструкторской деятельности.
6.2.2. Изменение в конструировании
6.2.2.1. Модели конструирования определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit- тесты) и другие аспекты, связанные с общим жизненным циклом разработки.
6.3. Основы конструирования
6.3.1. Минимизация сложности
6.3.2. Ожидание изменений
6.3.3. Конструирование с возможностью проверки
6.3.3.1. "Конструирование для проверки"
7. Тестирование
7.1. Основы тестрования
7.1.1. Связь тестирования с другой деятельностью
7.1.2. Терминология тестирования
7.1.2.1. Определение тестирования и связанной полной терминологии достаточно полно дается в "Глоссарии терминов по программной инженерии"- IEEE Standart 610-90
7.1.3. Ключевые вопросы
7.1.3.1. Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования
7.2. Уровни тестирования
7.2.1. Приемочное тестирование
7.2.1.1. Проверяет поведение системы на предмет удовлетворения требований заказчика.
7.2.2. Модульное тестирование
7.2.2.1. Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы.
7.2.3. Интеграционное тестирование
7.2.3.1. Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.
7.2.4. Системное тестирование
7.2.4.1. Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов.
7.3. Метрики, связанные с тестированием
7.3.1. Плотность дефектов
7.3.2. Плотность дефектов после вставки
7.3.3. Доля отклонения дефектов
7.3.4. Эффективность тестирования
7.3.5. Доля покрытия требований
7.3.6. Плотность покрытия требований
7.3.7. Доля повторно открытых дефектов
7.4. Техники тестирования
7.4.1. Техники базирующиеся на природе приложения
7.4.1.1. В зависимости от технологической или архитектурной природы приложений, могут также применять специфические техники, важные именно для заданного типа приложения.
7.4.2. Тестирования ориентированные на дефекты
7.4.2.1. Как это ни странно звучит на уровне названия таких техник тестирования, они, действительно, ориентированы на ошибки. Точнее - на специфические категории ошибок.
7.4.3. Техники, базирующиеся на интуиции и опыте
7.4.3.1. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий.
7.4.4. Техники, базирующиеся на спецификации
7.4.4.1. Область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик "спецификации".
7.4.5. Техники, базирующиеся на условиях использования
7.4.5.1. Базируются на условиях использования системы. Тестирование для оценки надежности системы должно проводиться в таком тестовом окружении, которое максимально приближено к реальным условиям работы системы.
7.4.6. Выбор и комбинации различных техник
7.4.7. Практические соображения
7.5. Процесс тестирования
7.5.1. Тестовые работы
8. Ключевые вопросы поддержки и эксплуатации
8.1. Технические вопросы
8.1.1. Ограниченное понимание
8.1.2. Тестирование
8.1.2.1. Стоимость повторения полного набора тестов для основных модулей системы может быть существенным как по времени, так и по стоимости.
8.1.2.2. Анализ влияния
8.1.2.2.1. Анализ влияния описывает как проводить (в частности, с точки эффективности затрат) полный анализ возможных последствий и влияний изменений, вносимых в существующую систему.
8.1.3. Возможность сопровождения
8.1.3.1. Возможность сопровождения или сопровождаемость программной системы определяется, например глоссарием IEEE (стандарт 610.12-90 Standart Glossary for Software Engineering Terminology, обновление 2002 года) как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований.
8.2. Управленческие вопросы
8.2.1. Согласование с организационными целями
8.2.1.1. Организационные цели описывают как продемонстрировать возврат инвестиций от деятельности по сопровождению программного обеспечения.
8.2.2. Проблемы кадрового обеспечения
8.2.2.1. Данная тема касается вопросов привлечения и удержание квалифицированного персонала по сопровождению.
8.2.3. Процесс
8.2.3.1. Процесс (в общем случае, жизненный цикл прим. автора) является набором работ (activities), методов, практик и, своего рода, трансформаций, которые используются людьми для разработки и сопровождения программных систем и ассоциированных с ними продуктов.
8.2.4. Организационные аспекты сопровождения
8.2.4.1. В первую очередь,организационные вопросы подразумевают какая организация будет отвечать и/или какие функции необходимо выполнять для обеспечения деятельности по сопровождению.
8.2.5. Аутсоурсинг
8.2.5.1. Заимствованный термин"аутсоурсинг"уже прижился не только в среде ИТ-менеджеров, он стал частью современного бизнеса и управленческих практик. Суть его заключается в передаче работ, в первую очередь, вспомогательных (непрофильных для организации) "на сторону".
9. Поддержка при эксплуатации
9.1. Основы поддержки эксплуатации
9.1.1. Результат усилий по разработке программного обеспечения состоит в передачи в эксплуатацию программного продукта, удовлетворяющего требованиям пользователей. Соответственно, в процессе эксплуатации продукт будет изменяться или эволюционировать. Связано это с обнаружением при реальном использовании скрытых дефектов, изменениями в операционном окружении, необходимостью покрытия новых требований и т.п.
9.2. Процесс
9.2.1. Процессы сопровождения
9.2.1.1. Эта секция включает концепции и терминологию, формирующие основы понимания роли и содержания работ по сопровождению программных систем.
9.2.2. Уникальные работы
9.2.2.1. Анализ влияния
9.2.2.2. Передача
9.2.3. Работы по сопровождению
9.2.3.1. Качество программного обеспечения
9.2.3.2. Конфигурация управления
9.2.4. Работы по планированию по сопровождению
9.2.4.1. Достижение соглашения с пользователем
9.2.4.2. Оценка рисков
9.2.4.3. Идентификация постоянных конфликтов
9.3. Техники
9.3.1. Понимание программных систем
9.3.2. Реинжиниринг
9.3.2.1. Реинжиниринг определяет как детальная оценка ( examination) и перестройка программного обеспечения для формирования понимания.
9.3.3. Обратный инжиниринг
9.3.3.1. "Обратный"инжиниринг (часто путаемый с реинжинирингом, в том числе, в понимании SWEBOK) или это процесс анализа программного обеспечения с целью идентификации программных компонентов и связей между ними, а также формирования представления о программном обеспечении, с дальнейшей перестройкой в новой форме (уже, в процессе реинжиниринга)
9.3.4. Получение и сбор информации
10. Большинство программных систем изменяются с течением времени. Причин этому - множество. Ожидание изменений является одной из движущих сил конструирования программного обеспечения. Изменения это часть программной среды.
11. Требования
11.1. Извлечение требований
11.1.1. Стратегия выявления требований
11.1.1.1. Интервьюирование
11.1.1.1.1. Подготовка
11.1.1.1.2. Проведение интервью
11.1.1.1.3. Завершение
11.1.1.2. Анкетирование
11.1.1.3. Наблюдение
11.1.1.3.1. Через наблюдение , а, возможно и участие аналитики получают информацию за день операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик только читал или разговаривал с экспертами
11.1.1.4. Самостоятельное описание требований
11.1.1.4.1. Документы - источник информации. Они чаще всего доступны и их можно "опрашивать"в любом для себя темпе. Чтение документов - способ получить представление о системе и сформулировать вопросы к экспертам
11.1.1.5. Совместный семинар
11.1.1.5.1. Первое правило мозгового штурма "запрет на любую критику". Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет полноценным образом подключить творческую фантазию
11.1.1.5.2. разработка + проведение переговоров нахождение компромисса
11.1.1.6. Прототипирование
11.1.1.6.1. Прототипирование - ключевая стратегия выявления требований в большинстве современных методологий. Программный прототип "зеркало" отражение того, как понял Исполнитель требования Заказчика
11.1.2. Источники требований
11.1.2.1. Заказчик
11.1.2.2. Группа работников предприятия
11.1.2.3. Документация
11.1.2.4. Важные работники предприятия
11.1.2.5. Прототип
11.1.2.5.1. Программный прототип это отражение того, как понял Исполнитель требования Заказчика
11.2. Процесс работы
11.2.1. Модель процесса определения требований
11.2.1.1. Это схема процессов жц , которые выполняются до тех пор, пока не будут определены и согласованы требования
11.2.2. Участники процессов
11.2.2.1. Пользователи
11.2.2.1.1. Могут описать задачи, которые он будет решать
11.2.2.2. Заказчики
11.2.2.2.1. Целевой рынок ПО
11.2.2.3. Аналитики
11.2.2.4. Регуляторы
11.2.2.4.1. Делают все по закону
11.2.2.5. Инженеры по ПО
11.2.3. Управление и поддержка процессов
11.2.3.1. Распределение ресурсов
11.2.3.2. Инициация и определение содержания
11.2.3.3. Управление в программной инжинериии
11.2.4. Качество процессов
11.2.4.1. Покрытие работы с требованиями с точки зрения стандартов и моделей услуг процесса
11.2.4.2. Измерения и количественная оценка
11.2.4.3. Планирование и реализация процесса улучшения
11.3. Анализ требований
11.3.1. Классификация требований
11.3.1.1. Функциональные и нефункциональные требования
11.3.1.1.1. Функциональные требования описывают функции, которое должно выполнять разрабатываемое ПО. Нефункциональные требования - требования ,определяющие свойства, которые она должна соблюдать не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации
11.3.1.1.2. Требования к процессу как и на каком ПО разработчик будет выполнять работу . К продукту описывают эксплуатационные свойства программного продукта. Эти требования к производительности системы объему необходимой памяти надежности переносимости системы на разные платформы и удобство в эксплуатации
11.3.1.2. Требование к процессу или продукту
11.3.2. Концептуальное моделирование
11.3.2.1. Природа проблемы
11.3.2.2. Экспертиза и опыт инженеров
11.3.2.3. Требования заказчика к процессу
11.3.2.4. Доступность методов и инструментов
11.3.2.5. Внутрикорпоративные стандарты и регламент
11.3.2.6. Культура разработки
11.3.3. Сбор требований
11.3.4. Архитектурное проектирование и распределение требований
11.3.4.1. Стандарт ISO 12207
11.3.4.2. Модель Захмана
11.3.4.3. TOGAF
11.4. Спецификация требований
11.4.1. Определение системы
11.4.2. Спецификация системных и программных требований
11.4.2.1. Терминологические неопределенности
11.4.2.2. Отсутствие о представлении классификации требований
11.4.2.3. Фокусировка на деталях пользовательского интерфейса
11.4.2.4. Излишние акцентирование внимания на деталях реализации
11.4.2.5. Слабая формализация бизнес - процессов
11.5. Проверка требований
11.5.1. Прототипирование
11.5.1.1. Превращение прототипа в реальную систему
11.5.2. Утверждение модели
11.5.2.1. Утверждение или аттестация модели связана с вопросами обеспечения приемлемого качества продукта.
11.6. Проектирование соображений
11.6.1. Интерактивная природа процесса
11.6.1.1. Понимание требований со временем изменяется в процессе разработки и проектирования ПО
11.6.2. Управление изменениями
11.6.2.1. Необходимость определения процедур для обработки информации
11.6.3. Атрибуты требований
11.6.3.1. Приемочный тест
11.6.4. Трассировка требований
11.6.4.1. Обеспечивается связь между требованиями, также отслеживаются источники этих требований
11.6.5. Измерение требований
11.7. Основы требований
11.7.1. Свойства
11.7.1.1. Полнота
11.7.1.1.1. Описывает всё, что необходимо, от разрабатываемой системы
11.7.1.2. Ясность
11.7.1.2.1. Требование, которое определенно однозначно и понятно
11.7.1.3. Корректность и согласованность
11.7.1.3.1. Требование от которого зависит точность и при этом оно не противоречит другим требованиям
11.7.1.4. Верифицируемость
11.7.1.4.1. Процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа
11.7.1.5. Необходимость и полезность при эксплуатации
11.7.1.5.1. Требование от которого зависит корректная работа системы
11.7.1.6. Осуществимость
11.7.1.6.1. Требования на практике определяются разумным балансом между ценностью (степенью необходимости полезности) и потребными ресурсами
11.7.1.7. Трассируемость
11.7.1.7.1. Трассируемость - это возможность соотнести элемент проекта с другими элементами, особенно связанными с требованиями.
11.7.1.8. Упорядоченность по важности
11.7.1.8.1. Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требования обычно назначает представитель Заказчика
11.7.2. Количественная оценка
11.7.2.1. Процесс оценивания, определения количественных или качественных параметров
11.7.3. Системные и программные требования
11.7.3.1. Системные
11.7.3.1.1. Описание примерных характеристик, которым должен соответствовать ПК, чтобы на нем могло использоваться какое - либо программное обеспечение
11.7.3.2. Программные
11.7.3.2.1. Совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации
11.7.4. Основные мероприятия по контролю и снижению риска - регламентация процесса создания ПО и его аудит. Заказчик регламентирует требования к проекту в зависимости от ценности конечного продукта для Заказчика, степени доверия заказчика к разработчику, суммы подписанного контракта, увязки срока сдачи продукта в эксплуатацию с бизнес - рисками Заказчика и т.д.
11.7.5. Полнота отдельного требования - свойство, означающее, что текст требования не требует дополнительной детализации, в нем уже предусмотрены все необходимые нюансы и детали данного требования
11.7.6. Определение требований
11.7.6.1. Требования
11.7.6.1.1. Какое - то условие либо свойства, которым должна соответствовать система
11.7.6.2. Уровни
11.7.6.2.1. Бизнес
11.7.6.2.2. Пользовательские
11.7.6.2.3. Функциональные
11.7.7. Требования к продукту или процессу
11.7.7.1. Продукт
11.7.7.2. Процесс
11.7.8. Функциональные и не функциональные
11.7.8.1. Функциональные
11.7.8.1.1. Поведение системы в определенных ситуациях, ее реакция на те или иные входные данные или действия, которые система позволит выполнять пользователю
11.7.8.2. Нефункциональные
11.7.8.2.1. Описывающие, как должна работать система или программный продукт и какими свойствами или характеристиками должна обладать
11.7.8.3. Описывающая, что необходимо реализовать в продукте или системе какие действия должны выполнять пользователи при взаимодействии с ними