Программная инженерия Дмитриев Андрей Владиславович 2008

Часть 1. Цикл разработки ПО

План Номенклатура. Стратегии разработки ПО. Фазы проекта. Требования к ПО. Техническое задание. Выводы. Q&A.

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

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

Процесс разработки ПО (software development process) - структура, согласно которой построена разработка ПО.

Одна компонента успешного проекта "Умение - это правильное выполнение работы. Эффективность - это выполнение правильной работы". Питер Друкер.

Составные процесса разработки ПО Процесс состоит из отдельных шагов. Последовательность шагов может варьироваться. Шаги могут повторяться.

Шаги процесса разработки ПО Бизнес-моделирование. Анализ требований. Разработка архитектуры. Кодирование. Тестирование. Документирование. Сопровождение. Завершение проекта.

Жизненный цикл разработки Project Life Cycle – последовательность фаз проекта, задаваемых исходя из целей проекта.

Модели процессов разработки ПО Модель Института Управления Проектами. «Водопадная» схема. Итеративный процесс. Экстремальное программирование (Extreme Programming). Гибкая методология (Agile software development). Спиральная модель.

Модель Института Управления Проектами В рамках этой методологии жизненный цикл проекта имеет фазы: Инициация. Планирование. Выполнение. Контроль и мониторинг. Завершение.

«Водопадная» схема 1. Определение требований/исследование среды. 2. Проектирование. 3. Реализация/кодирование. 4. Интеграция. 5. Тестирование и отладка. 6. Инсталляция/развертывание. 7. Поддержка. Работа над проектом движется линейно через фазы:

«Водопадная» схема (cont.) Недостатки: накопление ошибок на ранних этапах. возрастание риска провала проекта. увеличение стоимости проекта.

Гибкая методология Разбиение на небольшие законченные этапы - итерации. Итерация представляет собой небольшой проект с соответствующей последовательностью шагов. Завершение итерации означает возобновление обсуждения основного проекта. Ориентирование на минимизацию рисков. Может применяться при полной или частичной переделке проекта. См. презентацию Agile.

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

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

Другие модели проектирования Быстрая разработка (Rapid Application Development, RAD). ПО с открытым исходным кодом (OpenSource).

Требования Анализ требований это процесс, включающий в себя: сбор требований к системе систематизацию документирование анализ выявление противоречий выявление неполноты разрешения конфликтов

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

Значение требований к ПО Полнота и качество анализа требований играют ключевую роль в успехе всего проекта. В англоязычной среде также говорят о дисциплине «Инженерия требований» (Requirements Engineering).

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

Техническое задание Это исходный документ для проектирования и разработки информационных систем либо проведения научно-исследовательских работ. В точной формулировке заинтересованы две стороны: Разработчик Заказчик

Значение ТЗ ТЗ обеим сторонам позволяет: представить готовый продукт. выполнить попунктную проверку готового продукта (приёмочное тестирование проведение испытаний). уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).

Значение ТЗ (cont.) Заказчику позволяет: осознать, что именно ему нужно требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ

Значение ТЗ (cont.) Исполнителю позволяет: Понять суть задачи, показать заказчику «технический облик» будущего продукта Спланировать выполнение проекта и работать по намеченному плану Отказаться от выполнения работ, не указанных в ТЗ

Требования и техническое задание Требования – формализованные пожелания относительно будущего проекта Техническое задание – руководство к началу исполнения проекта

Спецификация Должна содержать описание будущей программы в формате «что», а не «как». Спецификация должна быть: Точной; Полной; Ясной; Недвусмысленной. На практике чаще используется словесная спецификация.

Проектирование На данном этапе закладывается архитектура будущей программы: Парадигма; Модули, их связь и иерархия; Алгоритмы реализации; Структуры данных.

Направление проектирования Иерархию будущих объектов можно представить как дерево подчиненных сущностей. Вверху находятся более сложные, а внизу – более простые (базовые) объекты. Выделяют два направления: Проектирование снизу вверх; Проектирование сверху вниз.

Направление проектирования(cont.) Сверху вниз: легче применять при моделировании структур данных и объектов. Снизу вверх: Легче применять при организации стека программ; Каждый новый уровень разрабатывается на основе предыдущего.

Реализация Метод реализации зависит от метода проектирования. Рекомендуется придерживаться установленных стандартов оформления программного кода. Снабжение кода комментариями улучшает его удобочитаемость.

Тестирование Software quality engineering и Software quality assurance. Тестирование можно выполнять в течение всего цикла разработки.

Виды тестирования Модульное. Регрессивное. Нагрузочное. На совместимость. Черного/белого ящика. И др.

Оценка качества тестирования Широта покрытия кода. Покрытие блоков. Покрытие условий.

Поддержка Длительность этапа сопровождения прямо пропорциональна живучести продукта. Срок поддержки может быть частью контракта. Прибыль может быть получена при сопровождении проекта.

Типы поддержки Исправление ошибок. Реализация запросов. Тестирование. Установка/поставка обновлений. Обучение пользователей. Консультирование. Техническая поддержка.

Сообщение об ошибке Каждая жалоба пользователя должна быть обработана: Принята на рассмотрение. Принята к исполнению. Отложена. Оценена. Исправлена. Доставлена пользователю. Закрыта.

Запрос пользователя Может иметь формальные части: Номер. Категория. Краткое описание. Приоритет и серьезность. Ответственный инженер. Заключение. Предлагаемое решение. Дата поставки решения. Способы обойти ошибку.

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

Ссылки С. Макконнелл «Совершенный код» Фредерик Брукс «Мифический человеко- месяц» Эдвард Йордон «Путь камикадзе» Jolyon Hallows Information Systems Project Management Dr. Winston W. Rovce «MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS»

Q&A

Дмитриев Андрей Владиславович Спасибо!