- •Учебное пособие по теоретической подготовке «Технологии разработки программного обеспечения»
- •Оглавление
- •Введение
- •Введение в технологии разработки программного обеспечения
- •Основные этапы развития технологии разработки
- •Первый этап – «стихийное» программирование.
- •Второй этап – структурный подход к программированию (60-70-е годыXXв)
- •Третий этап – объектный подход к программированию (с середины 80-х годов до нашего времени)
- •Четвертый этап – компонентный подход иCase-технологии (с середины 90-х годов до нашего времени)
- •Пятый этап – разработка, ориентированная на архитектуру иCase-технологии (с началаXxIв. До нашего времени)
- •Эволюция моделей жизненного цикла программного обеспечения
- •Каскадная модель
- •Спиральная модель
- •Макетирование
- •Быстрая разработка приложений
- •Компонентно-ориентированная модель
- •Xp-процесс
- •Стандарты, регламентирующие процесс разработки программного обеспечения
- •Гост р исо 9000-2001. Системы менеджмента качества. Основные положения и словарь
- •Предисловие
- •Введение
- •Принципы менеджмента качества
- •Область применения
- •Основные положения систем менеджмента качества Обоснование необходимости систем менеджмента качества
- •Требования к системам менеджмента качества и требования к продукции
- •Подход к системам менеджмента качества
- •Процессный подход
- •Политика и цели в области качества
- •Роль высшего руководства в системе менеджмента качества
- •Документация
- •Оценивание систем менеджмента качества
- •Постоянное улучшение
- •Роль статистических методов
- •Направленность систем менеджмента качества и других систем менеджмента
- •Взаимосвязь между системами менеджмента качества и моделями совершенства
- •Гост р исо/мэк то 15504
- •Область применения
- •Состав исо/мэк то 15504
- •Принцип 1 – Ориентация организации на потребителя (Customer-FocusedOrganization)
- •Принцип 2 – Лидерство (Leadership)
- •Принцип 3 – Вовлечение персонала (Involvement of People)
- •Принцип 4 – Процессный подход (Process Approach)
- •Принцип 5 – Системный подход к административному управлению (System Approach to Management)
- •Принцип 6 – Непрерывное усовершенствование (Continual Improvement)
- •Принцип 7 – Основанный на фактах подход к принятию решений (FactualApproachtoDecisionMaking)
- •Принцип 8 – Взаимовыгодные отношения с поставщиками (Mutually beneficial supplier relationship)
- •Гост р исо/мэк 12207-99. Информационная технология. Процессы жизненного цикла программных средств
- •Введение
- •Область применения Назначение
- •Область распространения
- •Адаптация настоящего стандарта
- •Соответствие
- •Ограничения
- •Прикладное применение настоящего стандарта
- •Построение стандарта
- •Анализ проблемы и постановка задачи
- •Введение в системный анализ
- •Системные ресурсы
- •Анализ проблемы и моделирование предметной области с использованием системного подхода
- •Основные положения
- •Этап 1. Достижение соглашения об определении проблемы
- •Этап 2. Выделение основных причин – проблем, стоящих за проблемой
- •Устранение корневых причин
- •Этап 3. Выявление заинтересованных лиц и пользователей
- •Этап 4. Определение границ системы-решения
- •Этап 5. Выявление ограничений, налагаемых на решение
- •МетодологияAris
- •Организационная модель
- •Диаграмма цепочки добавленного качества
- •МоделиeEpc
- •Стандарты idef0 - idef3
- •Методология описания бизнес процессовIdef3
- •Синтаксис и семантика моделей idef3 Модели idef3
- •Диаграммы
- •Единица работы. Действие
- •Соединения
- •Декомпозиция действий
- •Требования idef3 к описанию бизнес-процессов
- •Определение сценария, границ моделирования, точки зрения
- •Определение действий и объектов
- •Последовательность и параллельность
- •Методология функционального моделированияIdef0
- •Синтаксис и семантика моделейIdef0 Модели idef0
- •Действия
- •Границы и связи
- •Туннели
- •Построение моделей idef0
- •Диаграммы
- •Цикл "эксперт-аналитик"
- •Построение моделей
- •Точка зрения
- •Границы моделирования
- •Выбор наименования контекстного блока
- •Определение стрелок на контекстной диаграмме
- •Нумерация блоков и диаграмм
- •Связь между диаграммой и ее родительским функциональным блоком
- •Два подхода к началу моделирования ("в ширину" и "в глубину")
- •Анализ требований и их формализация
- •Методы определения требований
- •Интервьюирование
- •Этапы проведения интервью
- •Мозговой штурм и отбор идей
- •Генерация идей
- •Отбор идей
- •Совместная разработка приложений (jad –Jointapplication design)
- •Роли в сеансах jad
- •Недостатки метода jad
- •Раскадровка
- •Типы раскадровок
- •Обыгрывание ролей
- •Суть метода обыгрывания ролей
- •Сценарный просмотр
- •Crc-карточки (Class-Responsibility-Collaboration, класс-обязанность-взаимодействие)
- •Быстрое прототипирование
- •Формализация требований
- •Метод вариантов использования и его применение
- •Построение модели вариантов использования
- •Спецификация вариантов использования Определение потока событий
- •Альтернативный поток событий.
- •Выявление пред- и постусловий
- •Преимущества
- •Псевдокод
- •Конечные автоматы
- •Графические деревья решений
- •Диаграммы деятельности
- •Техническое задание (гост 34.602-89)
- •Общие сведения
- •Назначение и цели создания (развития) системы
- •Требования к численности и квалификации персонала на ас
- •Требования к защите информации от несанкционированного доступа
- •Дополнительные требования
- •Требования к функциям (задачам)
- •Требования к видам обеспечения
- •Требования к математическому обеспечению системы
- •Требования к информационному обеспечению
- •Требования к лингвистическому обеспечению
- •Требования к программному обеспечению
- •Требования к техническому обеспечению
- •Требования к метрологическому обеспечению
- •Требования к организационному обеспечению
- •Требования к методическому обеспечению сапр
- •Состав и содержание работ по созданию системы
- •Порядок контроля и приемки системы
- •Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
- •Требования к документированию
- •Источники разработки
- •Архитектуры программных систем
- •Планирование архитектуры
- •Архитектурно-экономический цикл
- •Программный процесс и архитектурно-экономический цикл
- •Этапы разработки архитектуры
- •Создание экономической модели системы
- •Выявление требований
- •Создание или выбор архитектуры
- •Распространение сведений об архитектуре
- •Анализ или оценка архитектуры
- •Суть программной архитектуры
- •Архитектурные образцы, эталонные модели и эталонные варианты архитектуры
- •Архитектурные структуры и представления
- •Программные структуры
- •Компонент и соединитель
- •Распределение
- •Проектирование архитектуры
- •Атрибутный метод проектирования
- •Этапы add
- •Создание макета системы
- •Документирование программной архитектуры
- •Варианты применения архитектурной документации
- •Представления
- •Выбор значимых представлений
- •Документирование представления
- •Документирование поведения
- •Документирование интерфейсов
- •Шаблон для документирования интерфейсов
- •Методы анализа архитектуры
- •Метод анализа компромиссных архитектурных решений – комплексный подход к оценке архитектуры
- •Этапы атам
- •Метод анализа стоимости и эффективности — количественный подход к принятию архитектурно-проектных решений
- •Контекст принятия решений
- •Реализация свам
- •Технология mda.
- •Использование архитектуры, управляемой моделью
- •Концепция архитектуры, управляемой моделью
- •Модельные точки зрения и моделиMda
- •Язык объектных ограниченийOcl
- •Типы данных и операцииOcl
- •Инфиксная форма записи выраженийOcl
- •Последовательности доступа к объектам в языкеOcl
- •Операции над коллекциями
- •Стандартные операции
- •Операция select
- •Операция reject
- •Выделение элементов коллекции
- •Упорядочение набора
- •Логические итераторы
- •Операции для работы со строками
- •Работа с датами
- •Возможности технологииEco
- •Введение в технологию есо
- •Модель есо
- •Пространство имен есо
- •Разработка приложений на основеEco
- •Этапы создания приложения по технологииEco
- •Создание простого mda-приложения
- •Создание модели uml
- •Создание интерфейса
- •Связывание интерфейса с моделью
- •Создание логики на ocl
- •Документирование программных систем в соответствии с гост
- •Управление документированием программного обеспечения
- •Предисловие
- •Область применения
- •Роль руководителей
- •Функции программной документации
- •Информация для управления
- •Связь между задачами
- •Обеспечение качества
- •Определение стандартов и руководств по документированию
- •Выбор модели жизненного цикла программного обеспечения
- •Определение типов и содержания документов
- •Документация разработки
- •Документация продукции
- •Документация управления проектом
- •Определение качества документов
- •Определение форматов документов
- •Определение системы обозначения документов
- •Установление процедуры документирования
- •Распределение ресурсов для документирования
- •Персонал
- •Средства
- •Финансирование
- •Планирование документирования
- •Требования к содержанию документов на автоматизированные системы
- •Общие положения
- •Требования к содержанию документов по общесистемным решениям
- •Ведомость эскизного (технического) проекта
- •Пояснительные записки к эскизному, техническому проектам
- •Описание автоматизируемых функций
- •Описание постановки задачи (комплекса задач)
- •Локальная смета и локальный сметный расчет
- •Паспорт
- •Формуляр
- •Проектная оценка надежности системы
- •Общее описание системы
- •Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)
- •Требования к содержанию документов с решениями по организационному обеспечению
- •Описание организационной структуры
- •Методика (технология) автоматизированного проектирования
- •Технологическая инструкция
- •Руководство пользователя
- •Описание технологического процесса обработки данных
- •Требования к содержанию документов с решениями по программному обеспечению
- •Описание программного обеспечения
- •Другие разделы
- •Принципы разработки руководства программиста
- •Общие положения
- •Содержание разделов
- •Разработка руководства пользователя
- •Общие замечания
- •Содержание разделов руководства
- •Общие сведения
- •Описание применения
- •Требования к процедурам функционирования системы
- •Заключение
- •Библиографический список
Документирование представления
Стандартного шаблона документирования представлений не существует. Поэтому ниже речь пойдет о методике, доказавшей свою жизнеспособность в практической деятельности — стандартной семичастной структуре (seven-part standard organization). Во-первых, вне зависимости от того, каким разделам вы отдадите предпочтение, ввести стандартную структуру совершенно необходимо. Распределение информации по отдельным разделам помогает составителю документации уверенно приступить к решению задачи и установить момент ее выполнения; что же касается читателя, то ему становится проще быстро отыскать интересующую информацию и пропустить все ненужное.
1. Первичное отображение (primarypresentation) содержит перечень элементов представления и установленные между ними отношения. В первичном представлении должна содержаться (в форме словаря) та информация о системе, которую необходимо донести до читателя в первую очередь. Это, без сомнения, основные элементы и отношения представления, хотя в некоторых случаях они могут быть отражены не полностью. К примеру, в первичном отображении можно показать элементы и отношения, характерные для нормального режима работы, а сведения об обработке ошибок или исключений представить во вспомогательной документации.
Как правило, первичное отображение составляется в графической форме. Дело в том, что большинство графических нотаций годятся только для первичного отображения — для всех остальных элементов документации они не приспособлены. Неизменным спутником графического представления должен быть перечень условных обозначений, содержащий объяснение использованной нотации и символики или хотя бы указывающий на источники получения этих объяснений.
Иногда первичное отображение составляется в виде таблицы, которая по своему характеру прекрасно подходит для компактного представления больших объемов информации. Требование о кратком выражении наиболее значимых сведений о представлении распространяется и на текст.
2. Каталог элементов (element catalog) предназначен для более детального описания элементов и отношений — как участвующих, так и не участвующих в первичном отображении. Архитекторы часто совершают одну и ту же ошибку — уделяя излишне серьезное внимание составлению первично го отображения, они забывают, что без дополнительной информации в нем мало толку. К примеру, если на диаграмме показаны элементы А, В и С, необходимо составить относительно детальное описание сущности этих элементов, их назначения и ролей, причем разместить эту информацию лучше всего в словаре представления. Скажем, для представления деком позиции на модули характерно наличие элементов-модулей, различных вариантов отношения «является частью», а также свойств, определяющих обязанности каждого модуля. В представлении процессов содержатся элементы-процессы, отношения, определяющие синхронизацию и другие механизмы межпроцессного взаимодействия, а также свойства с временными параметрами.
Кроме того, в каталоге обязательно должны разъясняться все элементы и отношения, значимые для данного представления, но по каким-то причинам не показанные в первичном отображении.
3. На контекстной диаграмме (context diagram) должно быть показано отношение изображенной в представлении системы к своему окружению из словаря представления. К примеру, представление «компонент и соединитель» подразумевает демонстрацию взаимодействия отдельных компонентов и соединителей с внешними компонентами и соединителями через по средство интерфейсов и протоколов.
4. Руководство по изменчивости (variability guide) демонстрирует способы применения изменяемых параметров, входящих в состав показанной в дан ном представлении архитектуры. В некоторых архитектурах принятие решений откладывается до более поздних стадий процесса разработки, что не отменяет необходимость в составлении документации. Примеры изменчивости обнаруживаются во всех линейках программных продуктов, архитектура которых предусматривает возможность создания множества конкретных систем. В руководстве по изменчивости следует документировать все изменяемые параметры архитектуры, включая:
альтернативы, рассматриваемые при принятии того или иного решения. В модульном представлении такими альтернативами являются различные варианты параметризации модулей. В представлении «компонент и соединитель» могут быть отражены ограничения по дублированию, планированию или выбору протоколов. В представлении распределения это условия назначения конкретного программного элемента тому или иному процессору;
время связывания альтернатив. Одни решения принимаются в период проектирования, другие — в период производства, третьи — в период исполнения.
5. Предпосылки архитектурного решения (architecture background) — это раздел, в котором содержится обоснование отраженного в данном представлении проектного решения. Цель его — объяснить читателю, почему проект выглядит так, как он выглядит, и представить убедительные аргументы его превосходства. В состав этого раздела входят следующие элементы:
логическое обоснование, демонстрирующее предпосылки принятия проектных решений, отраженных в данном представлении, и причины отказа от альтернатив;
результаты анализа, оправдывающие проектное решение и объясняющие последствия модификаций;
отраженные в проектном решении допущения.
6. Глоссарий терминов (glossaryof terms), применяемых в представлениях, и краткое описание каждого из них.
7. Другая информация. Содержание этого раздела зависит от методов работы конкретной организации. В частности, здесь можно разместить административные сведения: авторство, данные управления конфигурациями и история изменений. Кроме того, архитектор волен разместить здесь систем ссылок на отдельные разделы сводки требований. Таким образом, речь идет об информации, которая, строго говоря, не имеет прямого отношения к архитектуре, но которую удобнее всего привести вместе с архитектурным: сведениями.