1. Трассировка требований
2. Общие концепции проектирования
2.1. Принципы проектирования, являются ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в различных методах и подходах к проектированию программного обеспечения.
2.2. К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения.
3. Основы проектирования
3.1. Контекст программного дизайна
3.1.1. Для понимания роли проектирования программного важно понимать контекст, в котором осуществляется проектирование и используются его результаты.
3.2. Процесс проектирования
3.2.1. Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде.
4. Требования
4.1. Полнота отдельного требования - свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
4.2. Количественная оценка
4.2.1. Продукции, определение численных значений показателей качества продукции.
4.3. Основы требований
4.3.1. Определение требований
4.3.1.1. Требования
4.3.1.2. Уровни
4.3.1.2.1. Бизнес
4.3.1.2.2. Пользовательские
4.3.1.2.3. Функциональные
4.3.2. Требования к продукту или процессу
4.3.2.1. Продукт
4.3.2.1.1. св-ва продукта, который надо получить
4.3.2.2. Процесс
4.3.2.2.1. св-ва с помощью которого разрабатывается продукт
4.3.3. Функциональные и не функциональные
4.3.3.1. Функциональные
4.3.3.1.1. задают "что" система должна делать
4.3.3.2. Не функциональные
4.3.3.2.1. с соблюдением "каких условий"
4.3.3.3. Описывающие, что необходимо реализовать в продукте или системе.
4.3.4. Свойства
4.3.4.1. Полнота
4.3.4.1.1. Полнота системы требований - свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.
4.3.4.2. ясность
4.3.4.2.1. Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
4.3.4.3. Корректность и согласованность
4.3.4.3.1. Требования не должны противоречить, и должны взаимодействовать друг с другом
4.3.4.4. Верифицируемость
4.3.4.4.1. пригодность к проверке
4.3.4.5. Необходимость и полезность при эксплуатации
4.3.4.5.1. Необходимость требований, которые влияют на работоспособность
4.3.4.6. Осуществимость
4.3.4.6.1. Требования на практике определяется разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами
4.3.4.7. Трассируемость
4.3.4.7.1. связь между требований
4.3.4.8. Упорядоченность по важности
4.3.4.8.1. Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика.
4.3.5. Системные и программные требования
4.3.5.1. Системные
4.3.5.1.1. Описание примерных характеристик, которым должен соответствовать компьютер для того, чтобы на нём могло использоваться какое-либо определённое программное обеспечение.
4.3.5.2. Програмнные
4.3.5.2.1. Совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.
4.4. Извлечение требований
4.4.1. Стратегия выявление требований
4.4.1.1. Интервьюирование
4.4.1.1.1. Подготовка
4.4.1.1.2. Проведение интервью
4.4.1.1.3. Завершение
4.4.1.2. Анкетирование
4.4.1.2.1. заполнение анкет, подготовленных заранее
4.4.1.3. Наблюдение
4.4.1.3.1. Активное
4.4.1.3.2. пасивное
4.4.1.4. Самостоятельное описание требований
4.4.1.4.1. Документы - источник информации, они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе.
4.4.1.5. Совместный семинар
4.4.1.5.1. проведение совместного семинара с компанией
4.4.1.6. Прототипирование
4.4.1.6.1. создание прототипа
4.4.2. Источники требований
4.4.2.1. Заказчик
4.4.2.2. Группа работников предприятия
4.4.2.3. Документация
4.4.2.4. Важные работники предприятия
4.4.2.5. Прототип
4.4.3. Программный прототип это зеркало в котором видно отражение того как понял исполнитель требования заказчика
4.5. Процесс работы
4.5.1. Модель процесса определения требований
4.5.1.1. Это схема процессов жц которые выполняются от начала проекта до тех пор пока не будут определены и согласованы требования
4.5.2. Участники процессов
4.5.2.1. Пользователи
4.5.2.1.1. могут описать задачи которые он будет решать
4.5.2.2. Заказчики
4.5.2.2.1. целевой рынок ПО
4.5.2.3. Аналитики
4.5.2.4. Регуляторы
4.5.2.4.1. делают все по закону
4.5.2.5. Инженеры по ПО
4.5.3. Управление и поддержка процессов
4.5.3.1. Распределение ресурсов
4.5.3.2. Инициация и определение содержания
4.5.3.3. Управление в программной инженерии
4.5.4. Качество процессов
4.5.4.1. Покрытие работы с требованиями с точки зрения стандартов и моделей услуг процесса
4.5.4.2. Измерение и количественная оценка
4.5.4.3. Планирование и реализация процесса улучшения
4.6. Анализ требований
4.6.1. Классификация требований
4.6.1.1. Функциональные и не функциональные требования
4.6.1.1.1. Функциональные требования описывают функции, которые должно выполнять разрабатываемое ПО.Нефункциональные требования — требования, определяющие свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.
4.6.1.1.2. Требования к процессу как и на каком ПО разработчик будет выполнять работу. К продукту описывает эксплуатационные свойства программного продукта. Эта требования к производительности системы обьему необходимой памяти надежности переносимости системы на разные платформы и удобство в эксплуатации
4.6.1.2. Требование к процессу или продукту
4.6.2. Концептуальное моделирование
4.6.2.1. Природа проблемы
4.6.2.2. Экспертиза и опыт инженеров
4.6.2.3. Требования заказчика к процессу
4.6.2.4. Доступность методов и инструментов
4.6.2.5. Внутрикорпоративные стандарты и регламент
4.6.2.6. Культура разработки
4.6.3. Сбор требований
4.6.4. Архитектурное проектирование и распределение требований
4.6.4.1. Стандарт ISO12207
4.6.4.2. Модель Захмана
4.6.4.3. TOGAF
4.7. Спецификация требований
4.7.1. Определение системы
4.7.2. Спецификация системных и программных требований
4.7.2.1. Терминологические неопределенности
4.7.2.2. Отсутствие о представления классификации требований
4.7.2.3. Фокусировка на деталях пользовательского интерфейса
4.7.2.4. Излишние акцентирование внимания на деталях реализации
4.7.2.5. Слабая формализация бизнес-процессов
4.8. Проверка требований
4.8.1. Прототипирование
4.8.1.1. Смещение внимания с целевых функций прототипа и как следствие неудовлетворение пользователей
4.8.1.2. Превращение прототипа в реальную систему
4.8.2. Утверждение модели
4.9. Проектирование соображений
4.9.1. Интерактивная природа процесса
4.9.2. Управление изменениями
4.9.3. Атрибуты требований
4.9.3.1. Приемочный тест
4.9.4. Измерение требований
5. Проектирование программного обеспечение
5.1. Ключевые вопросы проектирования
5.1.1. Параллелизм в проектировании
5.1.1.1. Эта тема охватывает вопросы, подходы и методы организации процессов, эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.
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.2.1. может рассматриваться как обобщенный шаблон для проектирования архитектуры ПО, опирающийся на некий набор принципов и обеспечивающий условную базу для определенного семейства систем
5.2.3. Шаблоны проектирования
5.2.3.1. общее решение общей проблемы в заданном контексте”
5.2.4. Свойства программ и фреймворков
5.2.4.1. готовый шаблон и наполняете его своим кодом
5.3. Нотации проектирования ПО
5.3.1. Анализ качества и оценка программного дизайна
5.3.1.1. Атрибуты качества
5.3.1.1.1. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна как такового – “тестируемость”, “переносимость”, “модифицируемость”, “производительность”, “безопасность” и т.п.
5.3.1.2. Анализ качества
5.3.1.3. Измерения
5.3.1.3.1. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера <проекта>, структуры (ее сложности) или качества (например, в контексте требований, предъявляемых к производительности).
5.3.2. Структурные описания
5.3.2.1. Следующие нотации, в основном, являются графическими, описывая и представляя структурные аспекты программного дизайна. Чаще всего они касаются основных компонент и связей между ними
5.3.3. Поведение описания
5.3.3.1. Следующие нотации и языки используются для описания динамического поведения программных систем и их компонентов.
5.4. Стратегии и методы проектирования
5.4.1. Общие стратегии
5.4.1.1. Правила помогающие в проведении работ по проектированию.
5.4.2. Функционально-ориетированный
5.4.2.1. Это один из классических методов проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций “сверху-вниз”.
5.4.3. Проектирование на основе структур данных
5.4.3.1. структура данных, которыми управляет система, чем на функциях системы.
5.4.4. Компонентное проектирование
5.4.4.1. Программные компоненты являются независимыми единицами, которые обладают однозначно-определенными интерфейсами и зависимостями (связями) и могут собираться и развертываться независимо друг от друга.
6. Тестирование
6.1. Основы тестирования
6.1.1. Связь тестирования с другой деятельностью
6.1.2. Терминология тестирования
6.1.2.1. Определение тестирования и связанной терминологии достаточно полно дается в “Глоссарии терминов по программной инженерии” – IEEE Standard 610-90
6.1.3. Ключевые вопросы
6.1.3.1. Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования
6.2. Уровни тестирования
6.2.1. Приемочное тестирование
6.2.1.1. Проверяет поведение системы на предмет удовлетворения требований заказчика.
6.2.2. Модульное тестирование
6.2.2.1. Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы.
6.2.3. Интеграционное тестирование
6.2.3.1. Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.
6.2.4. Системное тестирование
6.2.4.1. Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов.
6.3. Метрики, связанные с тестированием
6.3.1. Плотность дефектов
6.3.2. Плотность дефектов после вставки
6.3.3. Доля отклонения дефектов
6.3.4. Эффективность тестирования
6.3.5. Доля покрытия требований
6.3.6. Плотность покрытия требований
6.3.7. Доля повторно открытых дефектов
6.4. Техники тестирования
6.4.1. Техники базирующиеся на природе приложения
6.4.1.1. В зависимости от технологической или архитектурной природы приложений, могут также применять специфические техники, важные именно для заданного типа приложения.
6.4.2. Тестирование ориентированные на дефекты
6.4.2.1. Как это ни странно звучит на уровне названия таких техник тестирования, они, действительно, ориентированы на ошибки. Точнее – на специфические категории ошибок.
6.4.3. Техники, базирующиеся на интуиции и опыте
6.4.3.1. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий.
6.4.4. Техники, базирующиеся на спецификции
6.4.4.1. Область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик <спецификации>.
6.4.5. Техники, базирующиеся на условиях использования
6.4.5.1. Базируется на условиях использования системы.Тестирование для оценки надёжности системы должно проводиться в таком тестовом окружении, которое максимально приближено к реальным условиям работы системы.
6.4.6. Выбор и комбинации различных техник
6.5. Процесс тестирования
6.5.1. Практические соображения
6.5.2. Тестовые работы
7. Конструирование
7.1. Основы конструирования
7.1.1. Минимизация сложности
7.1.1.1. Основной причиной того, почему люди используют компьютеры в бизнес-целях, являются ограниченные возможности людей в обработке и хранении сложных структур и больших объемов информации, в частности, на протяжении длительного периода времени.
7.1.2. Ожидание изменений
7.1.3. Конструирование с возможностью проверки
7.1.3.1. “Конструирование для проверки” (а именно такой смысл заложен в оригинальное название данной темы) предполагает, что построение программных систем должно помогать вести поиск проблем и сбоев, будучи прозрачной для применения проверки.
7.1.4. Стандарты в конструировании
7.1.4.1. Стандарты, которые напрямую применяются при конструировании, включают себя 4 пункта
7.1.4.1.1. 1. Коммуникационные методы (например, стандарты форматов документов и <оформления> содержания) 2. Языки программирования и соответствующие стили кодирования (например, Java Language Specification, являющийся частью стандартной документации JDK – Java Development Kit и Java Style Guide, предлагающий общий стиль кодирования для языка программирования Java) 3. Платформы (например, стандарты программных интерфейсов для вызовов функций операционной среды, такие как прикладные программные интерфейсы платформы Windows - Win32 API, Application Programming Interface или .NET Framework SDK, Software Development Kit) инструменты (не в терминах сред разработки, но возможных средств конструирования – например, UML как один из стандартов для определения нотаций для диаграмм, представляющих структура кода и его элементов или некоторых аспектов поведения кода)
7.2. Управление конструированием
7.2.1. Изменение в конструировании
7.2.1.1. Модели конструирования определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки.
7.2.2. Планирования конструирования
7.2.2.1. Выбор метода (методологии) конструирования является ключевым аспектом для планирования конструкторской деятельности.
7.3. Практические соображения
7.3.1. Проектирование в конструировании
7.3.1.1. Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования;
7.3.2. Языки конструирования
7.3.3. Кодирование в конструировании
7.3.4. Практика конструирования программного обеспечения показывает активное применение следующих соображений и техник. При конструировании используются две формы тестирования, проводимого инженерами, непосредственно создающими исходный код
7.3.5. Тестирование
7.3.5.1. При конструировании используются две формы тестирования, проводимого инженерами, непосредственно создающими исходный код.
7.3.6. Повторное использование
7.3.6.1. Во введении в стандарт IEEE Std. 1517-99 “IEEE Standard for Information Technology – Software Lifecycle Process – Reuse Processes” даётся следующее понимание повторному использованию в программном обеспечении: “Реализация повторного использования программного обеспечения подразумевает и влечёт за собой нечто большее, чем просто создание и использование библиотек активов.
7.3.7. Качество
7.3.7.1. Существует ряд техник, предназначенных для обеспечения качества кода, выполняемых по мере его конструирования. Основные техники обеспечения качества, используемые в процессе конструирования, включают:
7.3.7.1.1. Модели конструирования
7.3.8. Интеграция
7.3.8.1. Одна из ключевых деятельностей, осуществляемых в процессе конструирования, - интеграция отдельно сконструированных операций классов, компонентов и подсистем . В дополнение к этому, некоторые программные системы нуждаются в специальной интеграции с другим программным и аппаратным обеспечением. к обсуждаемым интеграционным вопросам конструирования относятся:
7.3.8.1.1. планирование последовательности, в которой интегрируются компоненты; обеспечение поддержки создания промежуточных версий программного обеспечения; задание “глубины” тестирования (в частности, на основе критериев “приемлемого” качества) и других работ по обеспечению качества интегрируемых в дальнейшем компонент; наконец, определение этапных точек проекта, когда будут тестироваться промежуточные версии конструируемой программной системы.
8. Ключевые вопросы поддержки и эксплуатации
8.1. Технические вопросы
8.1.1. Ограниченное понимание
8.1.1.1. Ограниченное понимание подразумевает как быстро инженер по сопровождению может понять где необходимо внести исправления или изменения в код системы, которую он не разрабатывал.
8.1.2. Тестирование
8.1.2.1. Стоимость повторения полного набора тестов для основных модулей системы может быть существенным как по времени, так и по стоимости.
8.1.3. Анализ влияния
8.1.3.1. Анализ влияния описывает как проводить (в частности, с точки зрения эффективности затрат) полный анализ возможных последствий и влияний изменений, вносимых в существующую систему.
8.1.4. Возможность сопровождения
8.1.4.1. Возможность сопровождения или сопровождаемость программной системы определяется, например, глоссарием IEEE (стандарт 610.12-90 Standard 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. Заимствованный термин “аутсоурсинг” уже прижился не только в среде ИТ-менеджеров, он стал частью современного бизнеса и управленческих практик. Суть его заключается в передаче работ, в первую очередь, вспомогательных (непрофильных для организации) “на сторону”.