github twitter email rss
Программная инженерия
0001 Jun 1
9 minutes read

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

Литература source

Общая

  • Гецци К., Джазаейри М., Мандриоли Д. Основы инженерии программного обеспечения. 2-е изд.: Пер. с англ. – СПб.: БХВ-Петербург, 2005. – 832 с.: ил. (Толстая хорошая, большинство, многое не правильно)
  • Орлов С. Технологии разработки программного обеспечения. Разработка сложных программных систем. Учебное пособие. СПб: Питер, 2003. 480 с, ил. (Лучший учебник на русском языке)
  • Благодатских В.А. Стандартизация разработки программных средств: учеб. пособие /В.А. Благодатских, В.А. Волнин, К.Ф. Поскакалов; под ред. О.С. Разумова. - М. : Финансы и статистика, 2006. - 288 с : ил. (Больше как справочник)
  • Брукс Ф. Мифический человеко-месяц или как создаются программные системы. СПб: Символ-Плюс, 2006. – 304 с., ил. (Must read)
  • Д. Кознов. Введение в программную инженерию: Учебный курс. М.: Интуит, 2008.

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

  • Бек К. Экстремальное программирование. – СПб.: Питер, 2002. – 224 с., ил.
  • Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.: Питер, 2002. – 496 с.: ил.

Управление требованиями

  • Вигерс К. Разработка требований к программному обеспечению / Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.
  • Коберн А. Современные методы описания функциональных требований к системам. М: Издательство «Лори», 2002. 263 с.: ил.

Качество ПО

  • Фаулер М. Рефакторинг. Улучшение существующего кода. – Пер. с англ. – СПб: Символ-Плюс, 2003. – 432 с., ил.
  • Глухих М.И., Ицыксон В.М. Программная инженерия. Обеспечение качества программных средств методами статического анализа. Учебное пособие. СПб: Изд-во Политехн. ун-та. 2011, 150 с.
  • Б.В. Черников. Управление качеством программного обеспечения. М:ИД «ФОРУМ», 2012. – 240 с.: ил.

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

  • Бейзер. Б. Тестирование черного ящика. Технологии функционального тестирования ПО и систем. СПб: Питер, 2004. – 318 с, ил.
  • Калбертсон Р, Браун К., Кобб Г. Быстрое тестирование: Пер. с англ.. – М.: Издательский дом «Вильямс», 2002.– 384 с.: ил.


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

Outline

Жизненный цикл
    Фазы жизенного цикла ПО
    Стратегии конструирования ПО
        Однократные стратегии
            Классическая каскадная модель
        Инкрементные стратегии
            Инкрементная модель
            RAD
        Эволюционные стратегии
            Прототипирование
            Спиральная модель
            Экстремальное программирование
            Модель SCRUM
        Смешанные подходы
            Ratinal Unified Process (RUP)        
Управление требованиями
    Сбор требований
    Анализ требований
    Документрование требований
    Изменение требований
    Планирование и управление требованиями
Управление программными проектами
    Управление ресурсами
    Управление проектами
    Управление версиями
    Непрерывная интеграция
    Сборка и выпуск
    Управление рисками
Обеспечение качества программного обеспечения
    Оценка качества программного обоспечения 
    Методы обеспечения качества программного обеспечения
Документирование программного обеспечения
Качество процесса разработки

Основные фазы жизненного цикла ПО

  • Анализ и планирование
  • Разработка
  • Документирование
  • Проектирование
  • Тестирование
  • Эксплуатация / Сопровождение

Критерии успешности проекта

  • Качество Реализованы все возможности и с надлежащим качеством
  • Время Проект и этапы проекта реализованы вовремя
  • Бюджет

Программная индустрия существенно отличается от других областей производства:

  • Очень высокая сложность системы
  • Менее предсказуем результат
  • Хуже поддается планированию
  • До сих пор в большей степени творчество, чем ремесло

Что влияет по успешность программного проекта ?

  • Решаемая задача
  • Заказчик
  • Со стороны разработчика
    – Команда разработки
    – Инфраструктура
    – Выбранная методология проектирования ПО

Различия методологий проектирования ПО

  • Состав и последовательность работ
    • список этапов
    • последовательность этапов
    • связи этапов
    • состав этапов
    • длительность этапов
  • Требования
    • Формулировка требований
    • Корректировка требований
  • Команда
    • Размер
    • Роли
    • Способы взаимодействия
  • Артефакты
    • Состав и содержание
    • Время получения
  • Заказчик
    • Квалификация
    • Степень участия
  • Порядком контроля и проверки качества


Характеристики методологий проектирования

  • Стратегия конструирования
  • Адаптивность процесса
  • Этапы и связи между ними
  • Формулировка требований

Стратегии конструирования

  • Однкоратные
    • Определены все требования, не меняются
    • один цикл конструирования
    • промежуточных версий нет
  • Инкрементные
    • определены все требованиями
    • множество циклов конструирования
    • промежуточные версии могут распостраняться
  • Эволюционные
    • определены не все требования
    • множество циклов конструирования
    • промежуточные версии могут распостраняться

Адаптивность процесса к окружению

  • Тяжеловесные (прогнозирующие)
    • фиксированные требования
    • большая команда
    • разная квалификация разработчиков
  • Адаптивные (облегченные)
    • постоянное меняющиеся требования
    • маленькая комманда
    • высококвалифицированные разработчики


Как выбрать методологию проектирования ?

  • Решаемая задача
  • Срок реализации
  • Размер команды
  • Опыт команды
  • Сработанность команды
  • Местонахождение команды
  • Требования заказчика
  • Механизмы взаимодействия с заказчиком


Методологии

                    Стратегия       Адаптивность    Полнота
-----------------------------------------------------------
Классическая        Однокр.         Прогн.          +
Прототипирование    Эвол.           Прогн.          -
Спиральная          Эвол.           Прогн.          +
Инкрементная        Инкр.           Прогн.          +
RAD                 Инкр.           Прогн.          +
RUP                 Инкр./Эвол.     Прогн.          +
MSF                 Однокр./Эвол.   Прогн./Адапт.   +
XP                  Эвол.           Адапт.          +
SCRUM               Эвол.           Адапт.          +

% использования методологий

Классическая модель проектирования ПО

Этапы

Анализ и планирование
    --> Проектирование
        --> Кодирование
            --> Тестирование
                --> Эксплуатация, сопровождение
  • Анализ и планирование
    • Сбор требований
    • Анализ требований
    • Планирование проекта
  • Проектирование
    • Разработка архитектуры
    • Разработка моделей данных
    • Разработка алгоритмов
  • Кодирование
  • Тестирование / верификация
  • Сопровождение
    • Внедрение
    • Эксплуатация
    • Внесение изменений

Достоинства

  • Имеется план по всем этапам

Недостатки

  • Отсутствует гибкость
  • Часто всех требований на начальном этапе нет
  • Результат доступен толко в конце

Модификации классической модели

  • Общепринятая линейная модель Этапы идут строго по очереди
  • Классическая итерационная Обратная связь после каждого этапа, можно вернуться на любой предыдущий этап
  • Каскадная модель Завершение каждого этапа проверкой
  • Строгая каскадная модель Минимизация возвратов к пройденным этапам, возврат только на 1 шаг назад


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

Когда не имеются все требования

Этапы

  • Сбор и уточнение требований
  • Быстрое проектирование
  • Построение макета
  • Получение фидбека. Заказчик удовлетворен ?
    • нет –> уточнение требований
    • да –> Конструирование

Достоинства

  • Способствует определению полных требований

Недостатки

  • Можно принять макет за продукт


Инкрементная модель

Объединяет классический подход и прототипирование
Весь проект делится на инкременты - версии продукта с определенной функциональностью
Для каждого инкремента выполняется:

  • Анализ
  • Проектирование
  • Разработка
  • Тестирование
    Результат каждого инкремента - работающий продукт

Достоинства

  • Имеется план по всем этапам
  • Доступны промежуточные версии

Недостатки

  • Отсутствует гибкость
  • Усложенное проектирование
  • Часто всех требований на начальном этапе нет


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

Классическая модель + Прототипирование + Анализ рисков

  • Планирование
  • Анализ
  • Проектирование
  • Разработка
  • Оценивание

Детализированная спиральная модель

Достоинства

  • Адекватно отражает эволюционный характер проектирования
  • Позволяет явно учитывать риски на каждом витке эволюции
  • Использует моделирование

Недостатки

  • Высокие требования к заказчику
  • Трудность контроля времени разработки и управления им


Rapid Application Development (RAD)

Инкрементная стратегия конструирования
Конструирование с использованием компонентов
Ориентирована на разработку ИС

Этапы

  • Бизнес моделирование Моделируется информационный поток между безнес-функциями
    • Какая информация создается
    • кто ее создает
    • кто ее обрабатывает
    • где информация применяется
  • Моделирование данных По информационному потоку формируется набор объектов данных
    • свойства объектов
    • отношения между объектами
  • Моделирование обработки Определение преобразований объектов данных
    • описание добавления объектов данных
    • модификации объектов данных
    • удаление объектов данных
    • поиск объектов данных
  • Генерация приложения
    • Использование готовых компонентов
    • Создание повторно используемых компонентов
  • Тестирование и интеграция


Rational Unified Process (RUP)

Инкрементная и эволюционная итеративная методология
Базируется на широком использовании UML
Используются программные метрики
Требует высокой квалификации участников
Для больших и очень больших проектов
Наиболее продуманная методология???

Процесс делится на этапы
Этап состоит из итераций
Итерация - законченный цикл разаботки, вырабатывающий промежуточный продукт.

Rational Unified Process RAP

Рабочиие потоки процесса

  • Бизнес-моделирование
  • Управление требованиями
  • Анализ и проектирование Создание статическиого и динамичесиого представления системы.
  • Конструирование
  • Тестирование

Артефакты

Этапы

Начальная стадия (Inception)

  • Назначение Запуск проекта
  • Цели
    • Определение области применения
    • Определение элементов Use Case критических для системы
    • Определение обещих черт архитектуры
    • Определение обшей стоимости и плана проекта
    • Идентификация основных элементов риска
  • Действия
    • Формулировка области применения проекта
      • Выявление требований и ограничений
    • Планирование
      • Подготовка основного плана развития и альтернатив развития для управления риском
      • Оределение персонала
      • Определение проектного плана
      • Определение зависимостей между стоимостью планированием и полезностью
    • Синтез предварительной архитектуры
      • Развитие решений проектирования
      • Определение используемых компоненов(разаботка, покупка, повторное использование)
  • Артефакты
    • Спецификация основых проектных требований
    • Начальная модель Use Case
    • Начальный словарь проекта
    • Начальный план развития
    • Начальная оценка риска
    • Проектный план с этапами и итерациями

Уточнение (Elaboration)

  • Назначение Создать архитектурный базис
  • Цели
    • Определение оставшихся требований
      • Функциональные требования выразить с помощью Use Case
    • Определение архитектурной платформы системы
    • Отслеживание рисков, утранение наибольших рисков
    • Разработка плана итераций этапа «Конструирование»
  • Действия
    • Развитие спецификации
    • Формирование критических элементов Use Case, задающих дальнейшие решения
    • Развитие архитектуры, выделение ее компонентов
  • Артефакты
    • Модель Use Case
    • Дополнительные требования, функциональные и нефункциональные
    • Описание программной архитектуры
    • Действующий архитектурный макет
    • Переработанный список элементов рисков
    • Основаной план развития
    • План разработки всего проекта
      • Все итерации и критерии развития для каждой итерации

Конструирование (Construction)

  • Назначение
    • Создание программного продукта с начальной функциональностю
  • Цели
    • Минимизация стоимости разработки
    • Быстрое получение требуемого качества
    • Быстрое получение версии
  • Действия
    • Управление ресурсами
    • Контроль ресурсов
    • Оптимизация процессов
    • Полная разработка компонентов и их тестирование
    • Оценивание реализаций продукта
  • Артефакты
    • Программный продукт пригодный для тестирования
    • Описание текущей реализации
    • Руководство пользователя

Внедрение (Transition)

  • Назначение
    • Отдать программыной продукт пользователя
    • Завершить выпуск продукта
  • Действия в каждой итерации
    • Выпуск бета-верий или релизов
    • Исправление найденных в процессе бета тестирования ошибок
  • Результат
    • Законченный продукт



Гибкие методологии (Agile)

  • Отказ от классических неповоротливых подходов
  • Проекты с постоянно меняющимися требованиями
  • Небольшые команды
  • Высокая значимость не только технических составляющих процесса, но и социальных, организационных..

Экстремальное программирование (XP)

@TODO

- До 10 человек
- Группа в одном помещении
- 
- Итеративный

Scrum
Lean
AUP
FDD

Управление программными проектами

Ресурсы в программных проектах

Подлежат управлению и планированию

  • Сотрудники (Роли)
  • Рабочее время
  • Обрудование
  • Машинное время
  • ПО

Роли (сотрудники)

  • Заказчик (customer)
  • Планировщик ресурсов (planner)
  • Менеджер проекта (project manager)
  • Архитектор (architect)
  • Руководитель команды (team leader)
  • Разработчик (developer)
  • Тестер (tester, Quality Assurance, QA)
  • Разработчик документации (technical writer)
  • Пользователь (user)
  • Инженер группы поддержки (support engineer)
  • Эксперт предметной области
  • Специалист по пользовательскому интерфейсу и эргономике
  • Ответственный за выпуск релизов

Заказчик

  • участие в сборе требований
  • участие в разработке спецификации требований
  • принимает результаты разработки

Планировщик ресурсов

Менеджер проекта

  • Внешние функции
    • Взаимодействие с заказчиком
    • Взаимодействие с планировщиком ресурсов
  • Внутренние функции
    • Распределение задач
    • Организация выполнения проекта

Архитектор

  • Разрабатывает архитектуру, основные проектные решения
  • Общий план развития системы
  • Формирует инфраструктуру разработки

Руководитель команды

  • Главный разработчик
  • Техническое руководство
  • Решение технических вопросов

Разработчик

  • Реализация компонентов
  • Модульные тесты

Тестер

  • Проверяет качество (функциональность, надежность, эффективность)
  • Тесты
  • Функциональное тестирование
  • Интеграционное, системное тестирование

Разработчик документации

  • Разработка документации
    • Программная
    • Эксплуатационная документация
  • Информационная поддержка процесса разработки

Пользователь

  • не заказчик
  • потребитель проекта

Эксперт предметной области

  • Информационная поддержка предметной области
    • Словарь, терминология

Специалист UI UX Эргономика

  • Проектирование пользовательсий интерфейс
  • Анализ и оценка характеристик интерфейса (Эргономичность, локализуемость..)

Совмещение ролей

Рабочее время

Оборудование, ПО

Для разработки, тестирования

Методика управлением рисками

@todo

Стандарты управления рисками

  • ГОСТ Р 51901
  • ISO 12207
  • ISO 15504
  • NIST 800-30


Дефекты

  • Явное нарушение спецификации
  • Неявное нарушение






















#############################################################################
Трёхуровневая_архитектура

Артефакты - это объекты которые создаются в процессе проектирования: файлы, модели, документы, шаблоны, документация, файлы документации, файлы конфигурации, исходные коды, объектные модули, исполнимые модули..
функциональные требования - задача которую система решает
нефункциональные требования - надежность, производительность, совместимость, ограничения
Ахитектурный макет - каркас который функцию не выполняет но основные взаимодействия между компонентами выполняет
UML
CPP copy paste programming, код копируется и подгоняется
Clone похожие участки кода появившиеся методом CPP

#############################################################################

## Анализ и планирование
- Управление требованиями 
- Планирование

## Проектирование ПО
- Проектирование ПО 
- Объектно-ориентированныи анализ и проектирование, визуальное моделирование
- Алгоритмизация

## Разработка ПО
- Кодирование
- Отладка

## Процесс разработки ПО
- Управление проектами 
- Версионирование 
- Управление изменениями и дефектами 
- Непрерывная интеграция 
- Сборка и выпуск 
- Управление рисками

## Качество ПО
- Стандарты качества 
- Оценка качества
- Обеспечение качества

## Сопровождение
- Выпуск продукта 
- Лицензирование

## Документирование
- Стандарты 
- Технологии документирования



критический путь
риски
бюджетирование
планирование работ


При создании ПО всего лишь около 15% усилий затрачивается собственно на программирование.

Для успешного осуществления проекта приходится помимо кодирования выполнять много других задач. Управление требованиями, проектирование, тестирование, планирование, контроль за ходом проекта, управление изменениями — одинаково важные задачи, на которые тратится приблизительно 85% ресурсов.

 анализ потребностей пользователей и идентификация функций, реализующих эти потребности

 Что должна делать будущая система?». Для ответа на этот вопрос, во-первых, необходимо понять, какие именно потребности пользователей призвана обеспечить будущая система, а во-вторых, задокументировать это понимание, т.к. если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют.

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


Архитектурный или высокоуровневый дизайн (software architectural design, top-level design) – описание высокоуровневой структуры и организации компонентов системы;
•   
Детализированная архитектура (software detailed design) – описывающая каждый компонент в том объеме, который необходим для конструирования.

Back to posts


comments powered by Disqus