Программная инженерия до коллоквиума (набранные рукописные_ спасибо Дане и Денису) (1133619)

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла

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

Объект изучения – программная система (информационный а не математический объект)

Программная система отличается от программы большим количеством людей:

1)решается группа задач а не конкретная

2)программные системы живут долго и потому есть необходимость ее развития

3)экономические вопросы появляются – ограниченность бюджета и времени.

Способы борьбы со сложностью программирования системы

1)Модульность –

а)разбить задачи на части

б)решение подзадач

в)сборка обратно

г)выделение интерфейса

д)сокрытие внутренней реализации

1

2)абстракции (нужно выделить важное и не важное)

состав важного и неважного может меняться на ходу

3)многократное использование

Пример системаISO/OSI – стек протоколов

1)физический

2)канальный

3)сетевой

4)транспортный

5)прикладной

Чтобы обеспечить модульность и при этом не усложнить всё, разбивать на модули надо с умом и в этих модулях должны быть “интерфейсы” для его пользования.

Интерфейсы – фиксируемы и не могут меняться.

Интерфейсы должны быть:

1)адекватность – т.е. должны содержать все необходимое в зависимости от задачи, решаемой модулем.

2)полны – все необходимые вещи есть в интерфейсе

3)минимальны – нет ничего лишнего

4)простота и понятность

выгода ~ качество

ресурсы время люди деньги

Качество => удобство развития

Любая система должна демонстрировать хоть какую-нибудь функциональность даже при некоректной работе. (например не сотрет БД) 2

Технологический процесские процессы разбаротки ПО

• виды деятельности

• артефакты(документы модели код) СОСТАВЛЯЮЩИЕ ПРОЦЕССОВ

• роли

Пример:

1)пришел заказчик => нужно договориться =>

Заказчик и Руководитель =>роли

“Инициализация проекта” => деятельность

“Концепция” => артефакты

“Оценка проекта” => артефакты

2)”Анализ и фиксация деятельности”

(6) <= “Тех задание” или “Спецификация требований”

заказчик/эксперты / аналитик

(более общее)

3)”Архитектурное проектирование ” => Архитектура <= правила, как компоненты

Структура <=выделяются и взаимодействуют+

архитектор/руководитель проекта +контр набор компонентов.

детальные планы

(для контроля планирования проекта)

4)”Детальное проектирование” =>”Детальный проект”

“Проекторование пользовательсткого интерфейса” =>”Структура UI”

архитектор/разработчики UI

5 )Построение ПО

Документация

6 )Тестирование => “Отчет”

тестировщики

7)”Передача в эксплуатацию”

старший разработчик

анатилик

заказчик

3

Жизненный Цикл ПО

Идея создания Эксплуатация Эксплуатация Отказ от эксплуатации

| | | | | | | | | | |

доработка доработка

2 0-25% всех потраченных ресурсов

Модели жизненного цикла

1)каскадная (водопадная)

когда деятельность идет одна за другой в технологическом процессе на предыд стр

т олько в очень простых проектах

2)итеративная

самая практичная

Инкрементальная – отдельно идет разработка для разных модулей

3

Анализ и оценка решений

)Спиральная

Выработка решений

Реализация

Планировщие

П ример:

RUP – Rational Unified Process

Системы

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

V

Архитектура

Детали дизайна

– модель - Требования

Интерфейс тестирования

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

Тот проверяется

соответствие

4

Стандарты

IEEE 1074 – американский институт электроники и эелктротехники

ISO – International Standartization Organization

12207 -

15288 – процесс разработки программно-аппаратной системы

15504(SPICE) – регулирует оценку процесса разработки

указ виды деятельности

CMM/CMMI – дает +5 уровней зрелости и организации

(чем больше уровней зрелости тем больше состояний в процессе разработки)

1)нет требований

2)повторяемый(управляемый)

(если ведется какая-то оценка ресурсов)

3)определенный

(четко прописан процесс разработки)

4)управляемый (управляемый метриками)

ним. Оценки по затратам ресурсов

ним. Оценки качества

делаются прогнозы основываюсь на

5)совершенствующийся

есть инновации в процессе разработки

Пример: ISO 12207

Процессы:

Управление договорами

Тут все работы по приобрет. использ. сторонных ПО

Процессы обеспечения

Обеспечение возможности работы разных проектов например –

1)управл. инфраструктуры

2)управл. человеч. Ресурсов

3)управл. Качеством – проверка, что есть контроль качества

Проектная деятельность

1)планирование

2)оценка и текущий контроль

3)управление рисками

4)принятие решений

5)управлений конфигурациями

6)измерение затрат

5

Процессы построения ПО

1)анализ требований

2)архитектурное проектирование

3)детальное проектирование

4)построение ПО/реализация

5)интеграция

6)квалификационное тестирование

Поддерживающие

1)управление документами

2)управление конфигурациями

3)обеспечение качества

4)верификация и валидация

есть четкие нет четких

критерии проверки критериев

5)экспертизы и аудиты

6)разрешение проблем

Построение системы

Многократное использование

Как использовать несколько раз докум./модули и прочее

RUP/XP

Rational Unified Process / Extreme programming

Жесткий процесс agile – гибкий процесс разработки

Разработки

Пытается оторвать привязывается к имеющимся людям по максимальному

Разработку от самого использованию их потенциал., но

Продукта, чтобы не было привязки после работы тут остается мало докум.

К программистам

И те и другие нацелены на постоянные изменения, в процессе разработки, и после.

Поэтому есть:

1)итерации

2)использование use case (это для RUP)

6

т.е. все требования должны быть описаны в виде use case

3)архитектура – ее использование для планирования всех действий

4)модели – они описывают все принятые решение, чтобы мог вникнуть посторонний человек

1)начало проекта – нужно определять с бюджета, ресурса, задач, использованных технологий, команды ~10%(трудовые) ~5%(временные)

2)проектирование – выработка архитектуры ~20%(трудовые) ~30%(временные)

3)построение (разработка(разработка кода и тесты)) ( construction)

~65%(трудовые) ~5(50)%(временные)

4)внедрение(передача заказчику – документация/обучение заказчика/…)

~5%(трудовые) ~15%(временные)

4 фазы каждой итерации

итераций может быть много

М одели:

1)варианты использования use case

обычно рисуются овалами, сценарии описывают отдельно роли

(описывают требования к системе в виду сценариев работы)

у основных сценариев могут быть ответвления

2)модель анализа(концептуальная)

набор классов/сущностей – работающие в системе

3)проектирование

1. интерфейсы

2. управляющие ОСНОВНЫЕ КЛАССЫ

3.классы данных

4)реализации

набор компонент, в которых классы уже собраны,

компоненты друг от друга достаточно независимы

описание того, как система расположена на железе –

т.е. это набор узлов(?) и периферических устройств.

5)развертывание

описание того, как система расположена на железе –

т.е. это набор узлов(?) и периферических устройств.

6)тестирование.

1. Состоит из тестовые вариантов – имеют более или менее

абстрактное описание.

Для каждого сценария(каждой альтернативы) строится тестовый вариант

Альтернатива в тестах может быть только, если система недетерминирована.

2. Тестовые процедуры –

Тут все четко определено(не абстрактное описание)

Виды деятельности (в RUP - дисциплины)

1)Бизнес моделирование (моделирование предметной области)

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

7

2)определение требований – описание вариантов использования и их реализация в моделях

анализа

3)анализ и проектирование

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

4)реализация системы – разработка кода

5)тестирование – разработка тестов и тестирование

6)развертка – передача в руки пользователю

Поддерживающее деятельность

7)1)управление конфигурацией

определение разных версий/составляющих модулей

8)2)управление проектом

все административные работы

9)3)управление средой проекта

подготовка рабочего места/средств разработки/…

1

2

3

4

5

6

1

2

3

4

1

2

3

4

Пункты с конца предыдущего листа

XP

В XP есть 4 принципа(они отражают agile методы)

1)люди важнее процессов

(то есть отдается приоритет людям, а не инструментам)

2)система важнее документация

3)сотрудничества важнее контракт

с заказчиком

( то есть привязыватьмя надо к тому, что заказчик хочет, а не то что описано в

тех зад.)

4)изменение важнее планов

Структура итераций

8

Истории использования

Планирование

(фиксирование основного решения и

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

Будьте внимательны на мобильных устройствах, так как там используются упрощённый функционал даже в официальном приложении от Microsoft, поэтому для просмотра скачивайте PDF-версию. А если нужно редактировать файл, то используйте оригинальный файл.

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

Список файлов лекций