Ознакомление с основными этапами разработки ПО, методами проектирования ПО и документирования программных продукто презентация

лекции –
ознакомление с основными этапами разработки ПО, методами проектирования ПО и документирования программных продуктов

Содержание:

Введение
Жизненный цикл ПО
2.1 Жизненный цикл программ
2.2 Этапы разработки программ
2.3. Тенденции
Методы проектирования ПО
Документирование

Введение в компьютерные науки. Общий обзор, 6-е издание.: Пер. с англ. – М.: Издательский дом «Вильямс», 2001. – 688с. [стр. 341-377]
Информатика. Базовый курс / Симопович С.В. и др. - СИб.: Издательство "Питер", 1999. - 640с.; ил.
Попов С.И. Аппаратные средства мультимедиа. Видеосистема PC / Под ред. О.В. Колисниченко, И.В. Шиштина - СИб.: БХВ - Петербург; 2000. - 400с; ил.

водопада
Пошаговая модель
Прототип
CASE-технология
Модульность
Шаблон проектирования
Нисходящее проектирование
Восходящее проектирование

и согласуется с современными регламентированными процессами ЖЦ ПО стандарта ISO/IEC 12207. В этом ядре знаний содержится описание 10 областей, каждая из которых представлена согласно принятой всеми участниками создания этого ядра общей схемы описания. Описание каждой области вносит определенный запас знаний, который должен практически использоваться на соответствующих процессах ЖЦ с учетом приведенного стандарта.

описание концептуальных основ программной инженерии. Структурно делится на 10 глав (knowledge areas)
– разработка требований;
– проектирование;
– конструирование;
– тестирования;
– сопровождение.
– управление конфигурацией;
– управление инженерией;
– управление качеством
– процесс инженерии;
– методы и средства инженерии ПО;
– управление качеством.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

типовых схем упорядочивания выполнения работ по проектированию и разработке. Такие схемы получили название жизненного цикла и обобщенны в стандарте ISO / IEC 12207 и основных моделях ЖЦ, применяемых на практике.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

систем ПО:
Распределенная банковская система;
Операционная система;
Компьютерная игра;
Система контроля и безопасности полетов…
Особенности разработки – усилия многих людей на протяжении длительного времени.
Технология разработки ПО включает основные принципы (жизненный цикл ПО, модульность, шаблоны проектирования), а также средства и методы разработки ПО.

Жизненный цикл программ

Тенденции

Подходы к проектированию ПО –
Строго последовательное выполнение всех этапов жизненного цикла ПО (каскадная модель);
Поэтапное создание ПО (пошаговая или инкрементная модель);
Спиральная модель;
Эволюционная модель ЖЦ.

модель, где каждая работа выполняется один раз и в установленном порядке
Однако вспомогательные и организационные процессы (контроль требований, управления качеством и др.), как правило, выполняются вместе с процессами разработки ПО. В данной модели возврат к начальному процессу предполагается после сопровождения и исправления ошибок.
Особенность такой модели заключается в фиксации последовательных процессов разработки программного продукта. В ее основу положена модель фабрики, где продукт проходит стадии от замысла до производства, затем его передают заказчику в виде готового изделия, где замена не предусмотрена, хотя можно представить аналогичное устройство.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

такую жесткую форму и последовательность действий.
- Не учитываются изменяемые потребности пользователей, нестабильные условия внешней среды, влияющие на изменения требований к ПС при й разработки.
- Значительный разрыв между временем внесения ошибки (например, на процессе проектирования) и время ее обнаружения (при сопровождении), что приводит к существенной переработки ПС.
При применении каскадной модели возможны следующие факторы риска:
- Требования к ПС недостаточно четко сформулированы, либо не учитывают перспективы развития ОС, условий и т.п.
- Громоздкая система, не допускающая компонентной декомпозиции, может вызвать проблемы по размещению ее в памяти или на платформах, не предусмотренных в требованиях.
- Внесения быстрых изменений в технологии и в требования может ухудшить процесс разработки отдельных частей системы или системы в целом.
- Ограничения на ресурсы (человеческие, программные, технические и др.). В ходе разработки могут сузить отдельные возможности реализации системы.
- Полученный продукт может оказаться непригодным для применения вследствие непонимания разработчиками требований или функций системы или недостаточно проведенного тестирования.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

и системы реализуются одновременно, благодаря чему нельзя забыть ни одного задания, а это способствует установлению стабильных связей между ними.
- Полностью разработанную систему с документацией на нее легче сопровождать, тестировать, фиксировать ошибки и вносить изменения не хаотично, а целенаправленно, начиная с требований, например, добавлять или заменять некоторые функции и повторять процесс.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

с приростом. Ее суть заключается в разработке продукта итерациями, и каждая итерация заканчивается выпуском трудоспособного версии. В каждой новой версии добавляются некоторые функциональные возможности. Разработка системы начинается с определения набора всех требований к ПС и деления процесса разработки на итерации. Каждая итерация реализуется последовательно с использованием процессов ЖЦ и фиксации рабочей версии системы, системы, которая постепенно приближается к окончательной версии

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

часть требований, в последующую версию (выпуск 2) добавляют дополнительные требования до тех пор, пока не будут окончательно выполнены все требования и решены задачи разработки системы.

Для каждой промежуточной версии на процессах ЖЦ выполняются необходимые процессы, работы и задачи, в частности, анализ требований и создание новой архитектуры, которые могут быть выполнены одновременно.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

- Требования составлены с учетом возможности их изменения при реализации продукта;
- Все возможности системы требуется реализовать сразу;
- Быстрое изменение технологии и требований к системе может привести к нарушению полученной структуры системы;
- Ограничения в ресурсном обеспечении (исполнители, финансы) могут привести к несвоевременному вводу системы в эксплуатацию.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

Желательно реализовать некоторые возможности системы быстро за счет создания промежуточной версии продукта;
- Система декомпозируеться на отдельные составные части, которые можно реализовывать как отдельные самостоятельные промежуточные или готовые продукты;
- Возможное увеличение финансирования на разработку
Исходя из возможности внесения изменений, как в процесс, так и в промежуточный продукт была создана спиральная модель.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

только будет установлено, что созданные артефакты или элементы документации не соответствуют действительному положению разработки.
Данная модель ЖЦ допускает анализ продукта на витке разработки, его проверку, оценку правильности и принятия решения о переходе на следующий виток или возврата на предыдущий виток для доработки на нем промежуточного продукта.
Отличие этой модели от каскадной заключается в возможности многократно возвращаться к процессу формулирования требований и к повторной разработки версии системы с любого процесса модели.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

нескольким причинам. Во-первых, высказывания требований заказчиком носит субъективный характер, требования могут многократно уточняться в течение разработки ПС и даже после завершения и испытания, и иногда может выясниться, что заказчик «хотел совсем другое». Во-вторых, меняются обстоятельства и условия использования системы, поэтому общепризнанным законом программной инженерии является закон эволюции, который сформулируем так: каждая действующая ПС со временем требует внесения изменений или выводится из эксплуатации.
При необходимости внесения изменений в систему на каждом витке с целью получения новой версии обязательно вносятся изменения в заранее зафиксированные требования, после чего возвращаются на предыдущий виток спирали для продолжения реализации новой версии системы с учетом всех изменений.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

конструкций. В отличие от инкрементного модели в эволюционной модели требования устанавливаются частично и уточняются в каждом последующем промежуточном блоке структуры системы.
В литературе она часто называется моделью быстрой разработки приложений RAD (Rapid Application Development).

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

одновременно может привести к громоздкости;
- Ограниченные людские ресурсы заняты разработкой течение длительного времени.
Преимущества применения данной модели ЖЦ такие:
- Быстрая реализация некоторых функциональных возможностей системы и их апробация;
- Использование промежуточного продукта в следующем прототипе;
- Выделение отдельных функциональных частей для реализации их в виде прототипа;
- Возможность увеличения финансирования системы;
- Обратная связь с заказчиком для уточнения функциональных требований;
- Упрощение внесения изменений в связи с заменой отдельных функции.
Модель развивается в направлении добавления нефункциональных требований к системе, связанных с защитой и безопасностью данных, несанкционированным доступом к ним

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

методология
Сложная задача сводится к набору более простых задач, решение которых приведет к выполнению исходной задачи. При этом образуется иерархическая система последовательных уточнений, которая отображается в модульную структуру, совместимую с императивной парадигмой программирования
Восходящая методология
Определяются отдельные задачи внутри системы, затем изучается как решение этих задач. Может использоваться в качестве абстрактных инструментов для решения более общих задач. При этом иерархии нет, а модули могут быть равноправными. При этом сложная система ПО строится из стандартных, свободно продаваемых компонентов.

ПС, начиная с разработки концепции до утилизации системы.
Структурно он состоит из описания многих процессов, взаимосвязей между ними, а также сформулированных действий и задач, выполняемых в этих процессах. Иными словами, стандартный жизненный цикл определяет только схему работ по процессам разработки ПС, а не то, как именно выполнять те или иные процессы

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

Этапы разработки программ

Этапы разработки программ

Анализ определяет требования пользователей, т.е. что должна делать предлагаемая система
Проектирование определяет как программная система будет выполнять требования (задачи) пользователя
Реализация включает написание программы, создание файлов данных и разработку баз данных
Тестирование – это обнаружение в системе ошибок

п Процесс (подпроцесс)
1. Категория «Основные процессы»
1.1 Заказ (договор)
1.1.1 Подготовка заказа, выбор поставщика
1.1.2 Мониторинг деятельности поставщика, прием потребителем
1.2 Поставка (приобретение)
1.3 Разработка
1.3.1 Выявление требований
1.3.2 Анализ требований к системе
1.3.3 Проектирование архитектуры системы
1.3.4 Анализ требований к ПО системы
1.3.5 Проектирование ПО
1.3.6 Конструирование (кодирование) ПО
1.3.7 Интеграция ПО
1.3.8 Тестирование ПО
1.3.9 Системная интеграция
1.3.10 Системное тестирование
1.3.11 Установка ПО
1.4 Эксплуатация
1.4.1 Функциональное использование
1.4.2 Поддержка потребителя
1.5 Сопровождение

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

поддержки»
2.1 Документирование
2.2 Управление конфигурацией
2.3 Обеспечение гарантии качества
2.4 Верификация
2.5 Валидация
2.6 Общий обзор
2.7 Аудит
2.8 Решение проблем
2.9 Обеспечение применимости продукта
2.10 Оценивание продукта

процессы»
3.1 Управление
3.1.1 Управление на уровне организации
3.1.2 Управление проектом
3.1.3 Управление качеством
3.1.4 Управление риском
3.1.5 Организационное обеспечение
3.1.6 Измерение
3.1.7 Управление знаниями
3.2 Совершенствование
3.2.1 Внедрение процессов
3.2.2 Оценивание процессов
3.2.3 Совершенствование процессов

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

использовать все процессы ЖЦ одновременно и не ставит особых требований к формату и содержанию разработанных документов. Поэтому организация-пользователь стандарта при разработке конкретного программного продукта может создать стандарты предприятия, методики и процедуры, детализирующие выбранные для конкретных нужд процессы ЖЦ. Международная организация по стандартизации ISO (International Organization for Standardization) выпускает также пособия и наставления, дополняющие стандарт ISO / IEC 12207.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

данном стандарте делятся на три категории:
- Основные процессы;
- Процессы поддержки;
- Организационные процессы.
Для каждого из процессов определены виды деятельности (действия - activity), задачи, совокупность результатов (выходов) деятельности и решения задач, а также некоторые специфические требования. В стандарте приведен перечень работ для основных, организационных процессов и процессов поддержки, но не способ их выполнения и не форма подачи результатов.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

основным процессам относятся:
- Процесс приобретения, который инициирует ЖЦ ПС и определяет действия организации-покупателя (или заказчика), получающего автоматизированную систему, программный продукт или сервис. Этот процесс включает в себя следующие виды деятельности: инициирование и подготовка запроса, оформление контракта и его актуализация; мониторинг пользователей, прием и завершение.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

который определяет действия по передаче покупателю программного продукта или сервиса и включает в себя следующие виды деятельности: подготовку предложений (ответов на запросы); оформление контракта, планирование, исполнение и контроль продукта, поставляемого; анализ и оценку продукта; поставки и завершение работ по поставке. Процесс поставки начинается тогда, когда установлены договорные отношения между заказчиком и поставщиком. В зависимости от условий договора процесс поставки может включать в себя процесс разработки ПО, процесс эксплуатации и сопровождения для исправления и улучшения ПС.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

который определяет действия предприятия-разработчика программного продукта: анализ требований к системе; проектирование архитектуры системы, детальное проектирование компонентов ВС, кодирования и тестирования ПС, интеграцию системы, квалификационное тестирование, установку ПС и обеспечение приема ПС

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

1.3. Кодирование ПС
1.4. Интеграция
1.5. Тестирование
1.6. Системное тестирование
1.7. Инсталляция
2. Эксплуатация
2.1. Внедрение процесса
2.2. Поддержка потребителя
2.3. Функциональное тестирование
2.4. Использование функций
2.5. Эксплуатация системы
3. Сопровождение
3.1. Внедрение процесса
3.2. Анализ проблем и модификаций
3.3. Анализ сопровождения
3.4. Перемещение
3.5. Удаление

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

ходе ее эксплуатации пользователями (консультирование пользователей, изучение потребностей операторов, удовлетворенности потребителей системой и т.д.). Этот процесс регламентирует задачи и действия по функциональному тестированию, проверке правильности эксплуатации системы, соблюдению инструкций и руководств по ее запуску;
- Процесс сопровождения, который определяет действия организации, выполняющей сопровождение программного продукта (управление модификациями, поддержку текущего состояния и функциональной пригодности, инсталляцию программного продукта на вычислительной системе пользователя и его изъятие при списании). Данный процесс включает в себя задачи и действия по анализу вопросов сопровождения и модификации, разработке планов и реализации модификации системы, анализа результатов сопровождение после изменений системы, миграции ПС в другую среду или ее вывода из эксплуатации.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

договора на разработку ПС, мониторинг деятельности поставщиков ПС и т.п.
Стандарт включает в себя описание вспомогательных процессов, регламентирующих дополнительные действия по проверке продукта, управление проектом и его качеством
К процессам поддержки разработки ПС относятся: документирование, управление версиями, верификация и валидация, просмотры, аудиты, оценивание продукта и др. Процесс управления версиями по содержанию соответствует управлению конфигурацией системы, так же, как и продукты процессов, должны проверяться на правильность реализации целей проекта и соответствие требованиям заказчика. Задача по проверке рекомендуется выполнять специальным контроллерам, которые разбираются в методах и процессах проектирования ПС.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

разработки
1.1. Документирование
1.2. Верификация
1.3. Валидация
1.4. Аудит
1.5. Оценивание продукта
1.6. Решение проблем
2. Организационные процессы разработки ПС
2.1. Процессы управления
2.1.1. Управление на уровне организации
2.1.2. Управление проектом
2.1.3. Управление качеством
2.1.4. Управление риском
2.1.5. Организационное обеспечение
2.1.6. Измерение
2.1.7. Управление знаниями
2.2. Процессы усовершенствования
2.2.1. Внедрение процессов
2.2.2. Оценивание процессов
2.2.3. Улучшение процессов
Эти процессы выполняются специальными службами, осуществляющими планирование работ по проекту, контроль процессов, определение метрик для измерения продуктов, проверку показателей качества, соблюдения стандартных положений и др.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

связь: они взаимодополняют и обогащают друг друга, больше в разработке соответствующих документов участвовали одни и те же высококвалифицированные специалисты в области программирования и информатики. Инженерная дисциплина проектирования ПС использует теоретические, прикладные методы и средства разработки ПС и стандарты (ISO / IEC 12207, ISO / IEC 15404, ISO / IEC 9126 и др.), а также рекомендации и методики управления разработкой, к которым относят методы оценки на процессах ЖЦ, качества ПС, израсходованных ресурсов и стоимости выполненных работ. При этом ядро знаний SWEBOK, а также многочисленные монографии и статьи рекомендуют к применению методы и средства программной инженерии, а стандарт дает указания к построению процессов на стандартизированной инженерной основе.

ХАРЬКОВСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ РАДИОЭЛЕКТРОНИКИ, КАФ. ПОЭВМ,
ТЕЛ. 7021446, E-MAIL: SOFTWARE@KTURE.KHARKOV.UA

помощью какого метода можно определить, сколько ошибок содержится в определенной части ПО?
В чем состоит отличие между требованиями к системе и спецификацией на систему?
Кратко охарактеризуйте каждый из четырех этапов (анализ, проектирование, реализация и тестирование) фазы разработки в жизненном цикле ПО.
Какие существуют формы документации на ПО?
Что важнее, программа или ее документация?