Программное обеспечение
<<  Программная инженерия Программная инженерия  >>
Программная инженерия
Программная инженерия
Часть 1. Цикл разработки ПО
Часть 1. Цикл разработки ПО
План
План
Определения
Определения
Разработка ПО
Разработка ПО
Процесс разработки ПО
Процесс разработки ПО
Одна компонента успешного проекта
Одна компонента успешного проекта
Составные процесса разработки ПО
Составные процесса разработки ПО
Шаги процесса разработки ПО
Шаги процесса разработки ПО
Жизненный цикл разработки
Жизненный цикл разработки
Модели процессов разработки ПО
Модели процессов разработки ПО
Модель Института Управления Проектами
Модель Института Управления Проектами
«Водопадная» схема
«Водопадная» схема
«Водопадная» схема (cont
«Водопадная» схема (cont
Гибкая методология
Гибкая методология
Итеративный подход
Итеративный подход
Преимущества итеративного подхода
Преимущества итеративного подхода
Другие модели проектирования
Другие модели проектирования
Требования
Требования
Общие требования
Общие требования
Значение требований к ПО
Значение требований к ПО
Виды требований к ПО
Виды требований к ПО
Техническое задание
Техническое задание
Значение ТЗ
Значение ТЗ
Значение ТЗ (cont
Значение ТЗ (cont
Значение ТЗ (cont
Значение ТЗ (cont
Требования и техническое задание
Требования и техническое задание
Спецификация
Спецификация
Проектирование
Проектирование
Направление проектирования
Направление проектирования
Направление проектирования(cont
Направление проектирования(cont
Реализация
Реализация
Тестирование
Тестирование
Виды тестирования
Виды тестирования
Оценка качества тестирования
Оценка качества тестирования
Поддержка
Поддержка
Типы поддержки
Типы поддержки
Сообщение об ошибке
Сообщение об ошибке
Запрос пользователя
Запрос пользователя
Выводы
Выводы
Ссылки
Ссылки
Q&A
Q&A
Спасибо
Спасибо

Презентация на тему: «Программная инженерия». Автор: home. Файл: «Программная инженерия.ppt». Размер zip-архива: 97 КБ.

Программная инженерия

содержание презентации «Программная инженерия.ppt»
СлайдТекст
1 Программная инженерия

Программная инженерия

Дмитриев Андрей Владиславович andrei-dmitriev@yandex.ru 2008

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

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

3 План

План

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

4 Определения

Определения

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

5 Разработка ПО

Разработка ПО

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

6 Процесс разработки ПО

Процесс разработки ПО

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

7 Одна компонента успешного проекта

Одна компонента успешного проекта

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

8 Составные процесса разработки ПО

Составные процесса разработки ПО

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

9 Шаги процесса разработки ПО

Шаги процесса разработки ПО

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

10 Жизненный цикл разработки

Жизненный цикл разработки

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

11 Модели процессов разработки ПО

Модели процессов разработки ПО

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

12 Модель Института Управления Проектами

Модель Института Управления Проектами

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

13 «Водопадная» схема

«Водопадная» схема

Работа над проектом движется линейно через фазы:

Определение требований/исследование среды. Проектирование. Реализация/кодирование. Интеграция. Тестирование и отладка. Инсталляция/развертывание. Поддержка.

14 «Водопадная» схема (cont

«Водопадная» схема (cont

Недостатки: накопление ошибок на ранних этапах. возрастание риска провала проекта. увеличение стоимости проекта.

15 Гибкая методология

Гибкая методология

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

16 Итеративный подход

Итеративный подход

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

17 Преимущества итеративного подхода

Преимущества итеративного подхода

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

18 Другие модели проектирования

Другие модели проектирования

Быстрая разработка (Rapid Application Development, RAD). ПО с открытым исходным кодом (OpenSource).

19 Требования

Требования

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

20 Общие требования

Общие требования

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

21 Значение требований к ПО

Значение требований к ПО

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

22 Виды требований к ПО

Виды требований к ПО

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

23 Техническое задание

Техническое задание

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

24 Значение ТЗ

Значение ТЗ

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

25 Значение ТЗ (cont

Значение ТЗ (cont

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

26 Значение ТЗ (cont

Значение ТЗ (cont

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

27 Требования и техническое задание

Требования и техническое задание

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

28 Спецификация

Спецификация

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

29 Проектирование

Проектирование

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

30 Направление проектирования

Направление проектирования

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

31 Направление проектирования(cont

Направление проектирования(cont

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

32 Реализация

Реализация

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

33 Тестирование

Тестирование

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

34 Виды тестирования

Виды тестирования

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

35 Оценка качества тестирования

Оценка качества тестирования

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

36 Поддержка

Поддержка

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

37 Типы поддержки

Типы поддержки

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

38 Сообщение об ошибке

Сообщение об ошибке

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

39 Запрос пользователя

Запрос пользователя

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

40 Выводы

Выводы

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

41 Ссылки

Ссылки

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

42 Q&A

Q&A

43 Спасибо

Спасибо

Дмитриев Андрей Владиславович andrei-dmitriev@yandex.ru

«Программная инженерия»
http://900igr.net/prezentacija/informatika/programmnaja-inzhenerija-253155.html
cсылка на страницу
Урок

Информатика

130 тем
Слайды