Программная инженерия Андрей Дмитриев andrei-dmitriev@yandex.ru ©2009. - презентация

1 Программная инженерия Андрей Дмитриев ©2009

2 Цикл разработки ПО

3 Как мы создаём программы?

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

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

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

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

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

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

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

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

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

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

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

15 «Водопадная» модель (cont.) Проект разделен на несколько последовательно проходящих стадий Акцент на планирование, расписания, контрольные точки, бюджет и реализацию системы в целом Все стадии проекта проходят под жестким контролем и полностью документируются Недостатки: Накопление ошибок на ранних этапах Возрастание риска провала проекта Увеличение стоимости проекта

16 Создание прототипа (prototyping) Не отдельная методология, а полезная практика Разрабатывается небольшой прототип системы, который можно показать заказчику/пользователям Позволяет уменьшить риски упустить что-то важное сделать что-то ненужное Прототипы обычно выкидываются. Но при желании их можно разрабатывать так, чтоб потом превратить в работающую систему

17 Итеративный подход (incremental) Процесс разработки разбивается на сегменты, представляющие собой мини-водопады Другой вариант: планирование и дизайн в начале, далее создание прототипа Акцент на гибкость и возможность в любой момент внести серьезные изменения в систему Выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование Реализация Проверка Оценка

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

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

20 Спиральная модель (Spiral)

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

22 Rapid Application Development (RAD) Акцент на быструю разработку качественного продукта с минимальными затратами. Вовлечение пользователей в процесс. Использование инструментов и технологий: CASE, GUI builders, DBMS, и т.п. Результат итерации – работающий продукт (не прототип на выброс). Во главе – требования бизнеса, а не конкретные технологии.

23 Упражнение – сравнение походов Подход ДостоинстваНедостатки Водопадная модель Создание прототипа Спиральная модель RAD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

40 Оценка качества тестирования Не нашли ни одной ошибки ? Лавина ошибок ?

41 Оценка качества тестирования Не нашли ни одной ошибки Хороший продукт Плохо искали Лавина ошибок Неправильно тестировали Проблема в программистах/архитекторах Формальные метрики Широта покрытия кода Покрытие блоков Покрытие условий Объем кода тестовой базы

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

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

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

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

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

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

48 Q&A

49 Спасибо! Андрей Дмитриев ©2009