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

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПО Цель лекции – ознакомление с основными этапами разработки ПО, методами проектирования ПО и документирования программных продуктов Содержание: Введение Жизненный цикл ПО 2.1 Жизненный цикл программ 2.2 Этапы разработки программ 2.3. Тенденции Методы проектирования ПО Документирование

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

СЛОВАРЬ ТЕРМИНОВ Жизненный цикл Модель водопада Пошаговая модель Прототип CASE-технология Модульность Шаблон проектирования Нисходящее проектирование Восходящее проектирование

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

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

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

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

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

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

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

Каскадная модель ЖЦ программных систем

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

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

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

Инкрементный модель ЖЦ

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

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

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

Спиральная модель ЖЦ

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

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

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

Эволюционной модель

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

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

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

Жизненный цикл ПО. Этапы разработки программ

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

Процессы жизненного цикла в стандарте ISO / IEC 12207 № п / п Процесс (подпроцесс) 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 Сопровождение

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

Процессы жизненного цикла в стандарте ISO / IEC 12207 3. Категория «Организационные процессы» 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 Совершенствование процессов

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

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

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

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

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

Основные процессы ЖЦ ПС 1. Разработка 1.1. Разработка требований 1.2. Проектирование ПС 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. Удаление

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

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

Схема вспомогательных процессов ЖЦ ПС Вспомогательные процессы ЖЦ ПС: 1. Процессы поддержки разработки 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. Улучшение процессов Эти процессы выполняются специальными службами, осуществляющими планирование работ по проекту, контроль процессов, определение метрик для измерения продуктов, проверку показателей качества, соблюдения стандартных положений и др.

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

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