Слайд 2
Литература (продолжение)
6. Р. Фатрелл, Д. Шафер, Л.
Шафер
Управление программными проектами.
Вильямс, 2006 год.
7. Э. Эванс
Предметно-ориентированное проектирование.
Вильямс, 2011 год.
8. Г. Буч и др.
Объектно-ориентированный анализ и проектирование с примерами приложений
Третье издание, Вильямс, 2008 год.
9. С. Макконнелл
Совершенный код, Русская редакция, 2007 год.
10. Cайт университета информационных технологий.
www.intuit.ru
11. Бабич А.В. Введение в UML
www.intuit.ru, 2008
Слайд 3
Расходование средств на ИТ
Программное обеспечение (ПО)
Системное
Средства
разработки
Прикладное
Аппаратные средства (АП)
Компьютеры
Мониторы
Периферийное оборудование
Услуги (У)
Консалтинг
Системная интеграция
Установка и сопровождение
Обучение
Разработка
заказного ПО
Слайд 4
Изменение относительной стоимости ПО и У
Слайд 5
Российские производители ПО
Типы программных продуктов (распространение):
Software
коммерческое
Shareware условно-бесплатное
Freeware бесплатное, свободное
Open source с открытым кодом
Производители:
ABBYY – распознавание текстов, словари
Лаборатория
Касперского – антивирусные программы
1С – автоматизация работы предприятий, бухгалтерия, игры
Spirit – микропрограммное ПО
Parallels – виртуализация ПО
Слайд 6
Модели оценки качества ПО
Обобщенные критерии качества
Элементарные критерии качества
Каждый
элементарный критерий может влиять
на несколько обобщенных
Показатели качества или
метрики
Каждая метрика влияет только на один элементарный критерий
Слайд 7
Обобщенные критерии качества
Функциональность Functionality
Мобильность Mobility
Надежность Reliability
Эффективность Performance
Модифицируемость Serviceability
Практичность
(понятность и
простота использования ) Usability
Слайд 8
Элементарные критерии качества
Точность
Согласованность
Структурированность
Отсутствие избыточности
Универсальность
Защищенность
…
Слайд 9
Метрики
Число строк кода – Lines Of Code (LOC)
Число
обнаруженных ошибок за месяц работы ПО
Число строк документации
Число различных
операндов
Наличие средств проверки входных данных
Число внешних вводов
Число внешних выводов
Число классов
Глубина иерархии классов
Степень взаимосвязанности классов
Число переопределяемых методов
Время разработки в человеко-месяцах (характеризует процесс разработки)
Стоимость разработки (характеризует процесс разработки)
Относительные характеристики: KLOC, число ошибок / KLOC, стоимость / LOC, число строк документации / KLOC
.......
Слайд 10
Для чего нужны критерии?
Анализ – оценка уже разработанного
ПО с точки зрения значений критериев качества
Синтез – разработка
ПО, имеющего определенные значения критериев качества
Прогноз – предсказание значений критериев качества до начала разработки ПО
Слайд 11
Критерии выбора языка программирования
Соответствие языка характеру решаемой задачи
Надежность
Возможности
управления аппаратными средствами
Быстрота трансляции
Эффективность объектного кода
Сервисные возможности (средства отладки,
работа с файлами, встроенная помощь, навигация)
Интеграция со средствами организации коллективной работы
Поддержка языка CASE-средствами, в частности, возможность автоматической генерации кода на данном языке
Соответствие языка характеру решаемой задачи
Надежность
Возможности управления аппаратными средствами
Быстрота трансляции
Эффективность объектного кода
Сервисные возможности (средства отладки, работа с файлами, встроенная помощь, навигация)
Интеграция со средствами организации коллективной работы
Поддержка языка CASE-средствами, в частности, возможность автоматической генерации кода на данном языке
Слайд 12
Жизненный цикл ПО
Технико-экономическое обоснование разработки
Анализ требований (анализ предметной
области)
Проектирование
Программирование
Тестирование и отладка
Эксплуатация и сопровождение
Слайд 13
Технико-экономическое обоснование разработки
постановка задачи (определение основных
функций системы);
определение экономических возможностей заказчика;
определение технической базы;
определение сроков разработки;
определение требований к безопасности.
В результате должно быть сформировано обобщенное техническое задание (ТЗ) на разработку системы. Разработка ТЗ осуществляется заказчиком.
ТЗ может быть скорректировано заказчиком после консультаций с исполнителем.
Слайд 14
Техническое задание
1. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
2.
ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
3. ТРЕБОВАНИЯ К СИСТЕМЕ
3.1 Требования
к системе в целом
3.2 Требования к функциям
3.3 Требования к интерфейсу
3.4 Требования к данным
3.5 Требования к техническим средствам
3.6 Требования к безопасности
4. КАЛЕНДАРНЫЙ ПЛАН РАБОТ
5. ПОРЯДОК КОНТРОЛЯ И ПРИЁМКИ СИСТЕМЫ
6. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ
Слайд 15
Стратегии разработки ПО
Функционально-ориентированная стратегия технологии:
Нисходящая (водопадная)
Расширения ядра
Объектно-ориентированная стратегия
технологии:
Спиральная
Эволюционная или инкрементная
Гибкая (agile software development)
Слайд 16
Риски при разработке ПО
1. Дефицит необходимых специалистов.
2. Нереалистичные сроки
3. Недостаточный бюджет.
4. Реализация несоответствующей
требованиям функциональности.
5. Разработка неудачного пользовательского интерфейса.
6. “Золотая сервировка”, то есть ненужная оптимизация и оттачивание деталей проекта.
7. Непрекращающийся поток изменения требований со стороны заказчика.
Недостаточная производительность разрабатываемой системы.
9. Несоблюдение требований безопасности.
Слайд 17
Для чего нужны технологии?
Повысить качество ПО.
Снизить сроки разработки.
Уменьшить
стоимость.
Обеспечить контроль над ходом разработки.
Слайд 18
Нисходящая технология
Основная цель этапа проектирования – построение схемы
иерархии.
Схема иерархии – функциональная схема, представляющая собой ориентированный граф.
Вершины – функции (подпрограммы), ребра – отношения функция-подфункция.
В процессе построения схемы иерархии каждая новая функция рассматривается как черный ящик. В схеме иерархии не отражены потоки данных и логика работы программной системы.
Слайд 20
Функционально-ориентированные технологии: этапы разработки
Технико-
экономическое
обоснование
Анализ
требований
Функциональное
проектирование
Программирование
Тестирование
и Отладка
Возвраты на предыдущие
этапы нежелательны
Слайд 21
Достоинства ФОС разработки
Возможность планирования всего процесса разработки, поскольку
требования к ПС должны быть четко определены
с самого начала
Богатый опыт использования ФОС
Адекватность примерно 20% предметных областей
Слайд 22
Недостатки ФОС разработки
Неадекватность по отношению к большинству предметных
областей
Требования к ПС должны быть четко определены с самого
начала и не должны изменяться
Последовательное выполнение всех этапов разработки
Невозможность в большинстве случаев создания прототипа системы
Невозможность выбора альтернатив
Сложность внесения изменений в готовую систему
Повышение трудоемкости к концу разработки
Недостаточное внимание уделяется данным
Желательно наличие у разработчиков опыта работы над аналогичными проектами
Слайд 23
Анализ требований
Диаграммы прецедентов
Словарь терминов
Исполнитель – внешняя
по отношению к системе сущность, обладающая поведением.
Прецедент –
действие которое система может выполнять.
Диаграмма прецедентов – схема, на которой отображаются отношения между исполнителями и прецедентами, с одной стороны, и между прецедентами, с другой.
Слайд 24
Типы отношений
Исполнитель и прецедент связывает отношение ассоциации, если,
либо исполнитель инициирует выполнение прецедента, либо исполнитель анализирует и
использует результаты работы прецедента.
Два прецедента могут связывать отношения обобщения и зависимости.
Обобщение – это отношение наследования. Зависимость определяет условные и безусловные отношения между прецедентами.
Слайд 25
Диаграммы прецедентов
Ввод запроса
Анализ запроса
Поиск
Выдача результата
Пользователь
Слайд 26
Диаграммы прецедентов
Проверка
полномочий
Ввод запроса
Анализ запроса
Добавление
записи
Администратор
Слайд 27
Отношения между прецедентами
предоставление
льгот
предоставление
кредита
предоставление
кредита
проверка
платежеспособности
оформление
кредита
физическим лицом
оформление
кредита
>
>
Зависимость
Обобщение
Слайд 28
Диаграммы прецедентов
Выдача наличных денег
Проверка
PIN-кода
Сообщение о
неверном
PIN-коде
Выдача
справки
о состоянии счета
Клиент
Банк
<>
<>
<>
Банкомат
Слайд 29
Описание сценария
Исполнители Банкомат
1. Клиент
помещает карту в банкомат 2. Проверяет карту
Исключение1. Карта недействительна
4. Клиент
вводит PIN-код 3. Просит ввести PIN-код
5. Проверяет PIN-код
Исключение 2. PIN-код неверен
7. Клиент выбирает снятие денег 6. Отображает на экране меню
8. Делает запрос в банк и выясняет состояние счета
Исключение 3. Счет пуст
10. Клиент вводит сумму 9. Предлагает клиенту ввести сумму
11. Банк проверяет сумму
Исключение 4. Сумма больше допустимой
12. Банк изменяет состояние счета 13. Возвращает кредитную карту,
выдает деньги и чек
14. Клиент получает деньги, чек и
кредитную карту
Слайд 30
Классы, объекты и методы
Классы нужны для описания нового
типа, содержащего поля и методы
Объекты – это экземпляры классов
Методы
реализуют функционал класса
<имя объекта>.<имя метода>(<аргументы>)
Работа объектно-ориентированной программы может быть представлена как последователь-ность действий, состоящая из вызовов методами друг друга.
Слайд 31
Шаблоны классов
Имя класса
*
-
+
…
#
-
#
…
+
область
атрибутов
область
сигнатуры
кратность
видимость
Слайд 32
Отношения между классами
Обобщение
простое
множественное
Ассоциация
простая
агрегирование
композитное агрегирование
классы-ассоциации
Зависимость
Слайд 33
Отношение обобщения
Человек
Студент
Млекопитающее
Кит
Рыба
Слайд 34
Отношение ассоциации
Компания
Сотрудник
Человек
родственник
работает
работник
работодатель
Человек
предок
потомок
Прямое родство
Слайд 35
Навигация
Навигация определяет возможность перехода от объектов одного класса
к объектам другого класса, участвующим в ассоциации. Навигация изображается
стрелкой. В данном случае навигация позволяет перейти от конкретного объекта Компания ко всем объектам Сотрудник, которые в этой компании работают. Обратный переход от Сотрудника к Компании, в которой этот сотрудник работает, невозможен.
Компания
Сотрудник
работает
работник
работодатель
Слайд 36
Кратность ассоциаций
A
A
B
B
B
A
B
1
1..*
0..1
*
n..m
A
A
B
Слайд 37
Кратность ассоциаций
Человек
родитель
ребенок
родитель-ребенок
*
2
родственник
1..*
1..*
Слайд 38
Классы-ассоциации
Компания
Сотрудник
Работа
*
1..*
Должность
Зарплата
Дата начала работы
Слайд 39
Ассоциация “один-ко-многим”
Компания
Сотрудник
Работа
*
1..*
Должность
Зарплата
Дата начала работы
1
1
Слайд 40
Агрегирование
Факультет
Кафедра
входит в состав
1
Окно
Кнопка
1
*
2..*
Слайд 41
Диаграмма классов
Студент
Факультет
Предмет
обучается на
посещает
имеет в программе обучения
*
1
1..*
10..*
5..*
50..*
Кафедра
входит
читает
7..*
1..*
1
1..*
Слайд 42
Представление объектов
[Имя объекта]: Имя класса
=значение-1
=значение-2
…
=значение-n
область
атрибутов
Слайд 43
Диаграмма объектов
:Сотрудник
Петров
Сидоров
Вед. инженер
20000
Аспирант
7000
Газпром
МИФИ
Росатом
Роснефть
:Работа
Инженер
15000
Юрина
:Сотрудник
Иванов
:Сотрудник
Юрина
:Компания
Газпром
Газпром
:Компания
МИФИ
:Компания
Роснефть
Газпром
:Компания
Росатом
:Работа
Вед.инженер
20000
:Работа
Аспирант
7000
:Работа
Инженер
12000
:Работа
Инженер
15000
:Работа
Программист
25000
Слайд 44
Объектно-ориентированное проектирование
1. Идентификация классов определенного уровня абстракции, соответствующего
данной итерации.
2. Определение атрибутов и сигнатуры классов (шаблоны классов).
3.
Определение отношений между классами (диаграммы классов).
4. Определение областей видимости элементов классов (шаблоны классов).
5. Планирование реализации базовых методов (диаграммы последовательностей).
Уровень абстракции – совокупность знаний о предметной области, используемых на данной стадии разработки, т.е. на данной итерации
Слайд 45
CASE-средства
CASE (Computer Aided Software Engineering)-средства ориентированы на постоянное
использование компьютера в процессе разработки ПО.
В большинстве CASE-средств применяются
UML-диаграммы.
Наиболее известные CASE-средства – Rational Software Architect (IBM), Together (Borland), AllFusion (Computer Associates), TAU (Telelogic)
Поддержка UML-диаграмм встроена во многие системы программирования: Visual Studio, Eclipse, Delphi.
http://www.objectsbydesign.com/tools/umltools_byCompany.html
Цели использования CASE-средств:
построение UML-диаграмм;
генерация кода по UML-диаграммам;
генерация UML-диаграмм на основе кода.
Слайд 46
ОО-технологии: этапы разработки
Технико-
экономическое
обоснование
Анализ
требований
ОО
Проектирование
ОО
Программирование
Тестирование
и
Отладка
Эволюция объединяет четыре этапа
…
Эволюция начинается со второй итерации
Слайд 48
Спиральная модель Боэма
Анализ требований
Анализ рисков
Проектирование
Программирование, тестирование и
отладка
Готовый
прототип
Стоимость
Слайд 49
Достоинства ОО-технологий разработки ПО
1. Тесная связь с
заказчиком в процессе разработки.
2. Возможность изменения требований к
ПО.
3. Получение работающих версий до завершения разработки.
4. Повышенное внимание к объектам и структурам данных.
5. Возможность принятия альтернативных решений.
6. Детальная отработка элементов интерфейса.
7. Равномерное распределение разных видов работ в процессе создания программной системы.
Слайд 50
Выявление классов
Формулирование предназначения класса в программной системе.
2.
Класс – шаблон описания множества однотипных объектов. Классы, предусматривающие
существование одного объекта, встречаются редко. Это, как правило, управляющие вспомогательные классы.
3. Класс должен содержать набор атрибутов.
Часто существуют один или несколько атрибутов, идентифицирующих объекты класса.
4. Класс должен отличаться от атрибута.
5. Класс должен содержать набор операций.
Слайд 51
Спецификация обобщения
Отношение обобщения соединяет базовый класс с более
специализированными классами. У специализированного класса – класса-потомка – имеются
по отношению к базовому классу дополнительные атрибуты и/или операции.
Обобщение делает возможным повторное использование элементов базового класса.
Наличие абстрактных классов предопределяет использование отношения обобщения. Обычно абстрактные классы в качестве базовых специфицируются в процессе разработки позднее их потомков.
При поиске отношений обобщения ключевой вопрос формулируется так:
является один класс разновидностью второго или нет?
Слайд 52
Спецификация ассоциаций
Ассоциация существует, когда объекты одного класса устойчиво
связаны с объектами другого или других классов.
Спецификация ассоциаций включает:
задание
имени ассоциации
задание имен ролей ассоциации
установление кратности ассоциации.
Кратности ассоциаций могут уточняться на начальных итерациях разработки.
Отметим, что CASE-средства часто автоматически генерируют имена ролей ассоциаций. Имена ролей бывают важны для ассоциаций, связывающих объекты одного класса.
Важно уметь выявлять избыточные ассоциации. Для этого надо анализировать циклы ассоциаций и отбрасывать лишние ассоциации.
Слайд 53
Избыточные ассоциации
Покупатель
Платеж
*
1
Заказ
1
*
Заказ-товара
Осуществление-платежа
Слайд 54
Спецификация агрегирования
Агрегирование – это отношение «часть - целое».
Агрегирование – это особый случай ассоциации, обладающий дополнительной семантикой.
Так агрегирование обладает свойствами транзитивности и асимметричности.
Транзитивность: если объект класса А является частью объекта класса В, а объект класса В - частью объекта класса С, то объект класса А является частью объекта класса С.
Асимметричность: если объект класса А является частью объекта класса В, то объект класса В не является частью объекта класса А.
Композитное агрегирование обладает дополнительным свойством – зависимостью по существованию.
Агрегирование степени выше 2 бессмысленно.
Слайд 55
Эволюция системы
добавление новых классов
введение абстрактных классов
разделение одного класса
на ряд других
изменение интерфейсов классов
корректировка отношений между классами
введение новых
отношений между классами
изменение логики работы базовых методов классов
Слайд 56
Диаграммы взаимодействий
Диаграммы последовательностей
Диаграммы кооперации
Служат для описания динамики работы
программной системы с точки зрения взаимодействия объектов в процессе
работы системы.
Слайд 57
Диаграммы последовательностей
A:Class1
:Class2
I – момент времени
k –
момент времени
j – момент времени
Слайд 58
Условные обозначения
Синхронная передача управления
Возврат управления
Асинхронная передача управления
Имя:Класс
Фокус управления
Объект
Линия
жизни
Слайд 59
Диаграммы последовательностей
:Register
:Sale
MakePayment
:Payment
Create
Identify
A1
Слайд 60
Диаграммы последовательностей (рефлексивный вызов)
:Person
Travel
Do
a1:Person
Travel
Do
d2:Person
Слайд 61
Фреймы
Фреймы используются для:
Реализации вложенных диаграмм
Представления ветвлений и условий
Реализации
циклов
Фреймы изображаются в виде прямоугольников с ярлычками (метками) в
левом верхнем углу
Слайд 62
Диаграммы последовательностей (фреймы – связывание)
Слайд 63
Диаграммы последовательностей (фреймы – связывание)
:B
Слайд 64
Диаграммы последовательностей (ветвление)
О1:Object1
О3:Object2
Modify
:Object3
Create
alt
Init (X)
[x
Слайд 65
Диаграммы последовательностей (условие)
:Object1
:Object2
[x
Слайд 66
Диаграммы последовательностей (циклы)
: А
: В
[для всех z
Begin (Z)
Слайд 67
Диаграмма последовательностей с исполнителем
:User
:A
M1
:B
M2
Слайд 68
Диаграмма последовательностей “зачисление студента на курсы”
:ControlForm
:Student
Init
:Course
Available
:Offering
Do(St,C)
Add
Place
Слайд 69
Диаграмма последовательностей “оплата услуги кредитной картой”
:Control
:CreditCard
Available
:Account
Payment
Modify
Slip
Слайд 70
Прокат велосипедов
Оплата времени проката кредитной картой в паркомате.
Получение
кода.
Ввод кода на клавиатуре стоянки велосипеда.
Получение велосипеда.
Катание.
Сдача велосипеда на
стоянку.
Слайд 71
Диаграмма последовательностей “прокат велосипедов”
:Controller
:Agender
Create
:Bicycle
Input Code
:Parking
Fixed1
Fixed2
Return
Code
Query
Slip
:User
TimeIn
TimeFin
Return
Слайд 72
Виды интерфейса
1. Командная строка (DOS, UNIX).
2. Текстовый интерфейс
(оболочки для DOS, например, Norton Commander).
3. Графический интерфейс (Mac
OS, Windows).
a. Оконный интерфейс.
b. Трехмерный интерфейс.
4. Альтернативные виды интерфейса (голосовой, жесты).
Слайд 73
Проектирование графического интерфейса
Основные принципы разработки
Управление со стороны
пользователя
Следование стандартам
Возможность настройки
Толерантность
Обратная связь
Удобство
и эстетичность
Простота
Слайд 74
Удобство и эстетичность
Факторы:
Цветовая гамма
Симметрия
Выравнивание
Расстояния между элементами
Пропорциональность
Группирование связанных элементов
Порядок
расположения
Слайд 75
Проектирование графического интерфейса
Элементы интерфейса
Главное окно и вторичные окна.
Главное окно обычно содержит дочерние окна. Дочерние окна размещаются
внутри главного и уничтожаются вместе с ним.
Вторичных окон может быть много. Вторичные окна не зависят от главного. Вторичные окна обычно являются модальными; они расширяют функциональность главного окна.
Содержимое главного окна как правило организовано в виде панелей. В панелях размещаются дочерние окна. Часто дочерние окна располагают своими собственными элементами управления.
Слайд 76
Вид главного окна (Delphi)
заголовок
главное меню
инструментальная линейка
панель
полоса прокрутки
Слайд 78
Вторичные окна
Диалоговое окно
Требует ввода информации пользователем, обычно
содержит строки или окна редактирования
Папка с вкладками
Объединяет сразу
несколько окон, инициируемых с помощью ярлыков
Окно сообщений
Обычно требует только подтверждения или подтверждения/отказа. Всегда модально
Слайд 79
Организация интерфейса в Eclipse
Рабочее пространство workspace
Рабочая среда workbench
Перспектива perspective
Modeling, RAS, Java …
Представление view
Project Explorer, Palette, Outline …
Редактор
editor
Разные редакторы для разных перспектив
Слайд 80
Список вопросов
Тенденции развития ИТ. Понятие программного обеспечения.
Рынок
ПО в России и в мире. Защита авторских прав
разработчиков.
Обобщенные критерии качества ПО.
Элементарные критерии качества и метрики ПО.
Жизненный цикл ПО.
Технико-экономическое обоснование разработки и техническое задание.
Функционально-ориентированная стратегия разработки ПО.
Схема иерархии
Характеристики модулей
Объектно-ориентированная стратегия разработки ПО.
Риски при разработке ПО.
Диаграммы прецедентов.
Сценарии.
![Представление объектов [Имя объекта]: Имя класса=значение-1=значение-2…=значение-nобластьатрибутов](/img/tmb/15/1433718/4e0ba56546913aad3d7fa71636b689f0-720x.jpg "Лекции по управлению ИТ проектами")
