Разделы презентаций
- Разное
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Введение в программную инженерию
Содержание
- 1. Введение в программную инженерию
- 2. Контактная информацияБондаренко Иван ЮрьевичEmail: bond005@yandex.ruSkype: i_yu_bondarenko
- 3. Определение Программная инженерия – это:установление и
- 4. Полезные ссылкиФорум «Исходники.ру» - http://forum.sources.ru/Библиотека MSDN (Microsoft
- 5. Полезные ссылкиФорум SQL.ru - http://www.sql.ru/Сайт «Королевство Delphi»
- 6. Становление программной инженерии. Предпосылки В
- 7. Этапы становления программной инженерии1. Повторное использование кода
- 8. Этапы становления программной инженерии 2. Рост сложности
- 9. Этапы становления программной инженерии 2. Рост сложности программ
- 10. Этапы становления программной инженерии 3. Модификация программ (объектно-ориентированное
- 11. Этапы становления программной инженерии 3. Модификация программ Объектно-ориентированное программирование.
- 12. ОпределенияЖизненный цикл – непрерывный процесс, начинающийся с
- 13. ОпределенияРазработка спецификации требований (результат – описания требований
- 14. Модели жизненного цикла программы Водопадная (каскадная) модель –
- 15. Модели жизненного цикла программы Компонентная модель предполагает сборку
- 16. Некоторые итоги Главная цель программной инженерии - сокращение
- 17. Продолжение кризиса программного обеспеченияПо информации агентства Standish
- 18. Продолжение кризиса программного обеспеченияПо информации агентства Standish Group
- 19. Примеры неудачных проектов Высокотехнологической жемчужиной нового международного аэропорта
- 20. Примеры неудачных проектовПроблемы с программным обеспечением задержали
- 21. Примеры неудачных проектовЛетом 2003 года проблема была,
- 22. Примеры неудачных проектов В 1997 году Налоговое
- 23. Тяжеловесные и облегченные процессы Традиционно для упорядочения и
- 24. Тяжеловесные и облегченные процессы В последние годы появилась
- 25. Тяжеловесные и облегченные процессы У каждого семейства есть
- 26. Экстремальное программирование (ХР-процесс)Экстремальное программирование (ХР)– вид облегченного
- 27. Экстремальное программирование (ХР-процесс)Динамизм обеспечивается с помощью четырех
- 28. Экстремальное программирование (ХР-процесс), примеры экстремальных значенийПринцип постоянной
- 29. Требования к «хорошим» программам «Хорошая программа» должна делать
- 30. Требования к «хорошим» программам 1) Сопровождаемость. Сопровождаемость означает,
- 31. Требования к «хорошим» программам 2) Надежность. Надежность ПО
- 32. Требования к «хорошим» программам3) Эффективность. ПО не
- 33. Профессиональные обязательства программистовКонфиденциальность – программные специалисты должны
- 34. Профессиональные обязательства программистовЗащита интеллектуальной собственности – специалист
- 35. Стандартизация и стандартыПо происхождению программные продукты бывают
- 36. Профессиональный стандартSWEBOK (Стандарт ISO/IEC TR 19759 IEEE,
- 37. SWEBOK (SoftWare Engineering Body Of Knowledge) Содержит описания
- 38. SWEBOK (SoftWare Engineering Body Of Knowledge)Software Configuration
- 39. Определение требований к программной системе Существуют функциональные и
- 40. Общая модель формирования и анализа требований
- 41. UML (Unified Modeling Language) UML (унифицированный язык моделирования) —
- 42. Описание требований к программной системе – диаграмма
- 43. Диаграмма вариантов использованияДиаграммы вариантов использования описывают взаимоотношения
- 44. Диаграмма вариантов использования. Условные обозначения
- 45. Диаграмма вариантов использования. Пример
- 46. Правила построения диаграммы При работе с вариантами использования
- 47. Связи между прецедентами в диаграмме вариантов использованияВарианты
- 48. Связи между прецедентами в диаграмме вариантов использования-
- 49. Связи между прецедентами в диаграмме вариантов использования
- 50. Связи между прецедентами в диаграмме вариантов использованияСледует
- 51. Связи между актером и прецедентомОтношение – одно
- 52. Связи между актером и прецедентом
- 53. Связи между актерами – расширение или наследование
- 54. Описание требований к системе дистанционного обученияАктеры: студент,
- 55. Описание требований к системе дистанционного обученияадминистратор: поддержка системы.
- 56. Диаграмма вариантов использования обучающей системы
- 57. Microsoft Visio Пакет Microsoft Visio предназначен для визуального
- 58. Для создания диаграммы необходимо выбрать шаблон. Основные типы шаблонов:бизнес;блок-схемы;карты и планы этажей;общие;программное обеспечение и базы данных;расписание;сеть;техника.
- 59. Microsoft Visio. Основные понятия Связанные друг с другом
- 60. Microsoft Visio. Пример
- 61. Работа с фигурами Для добавления фигуры в документ,
- 62. Соединения фигур Для соединения нескольких фигур используют соединительные
- 63. Создание UML-диаграммы Для создания UML диаграммы выбирают шаблон
- 64. Создание собственных фигур для диаграмм и схем
- 65. Сохранение созданной фигуры в трафарете Для сохранения созданной
- 66. Управление программным проектом Управление - изменение состояния объекта,
- 67. Характеристики проекта Цель проекта. Наличие четко выраженного конечного
- 68. Характеристики проекта Ограниченность во времени. Проект имеет начало
- 69. Характеристики проекта Неопределенность. Возможность достижения цели в указанные
- 70. Управление проектами Управление проектами - набор проверенных принципов,
- 71. Основные принципыОсновные принципы:Умение – знание принципов и
- 72. Категории управления проектамиВыделяют следующие группы категорийЦели, определяемые
- 73. Категории управления проектами (продолжение)Вспомогательные рычаги управления: контракты, организация, взаимодействие, персонал.Неопределенность, связанная с рисками выполнения проекта.
- 74. Треугольник ограничений проекта Закон Лермана: "Любую техническую проблему
- 75. Непроект - этоПрограммаширокомасштабное усилие, направленное на достижение
- 76. SQI: 34 компетенции IT менеджера Главное действующее
- 77. Компетенции IT менеджераТри основные категории: Методика разработки продуктаНавыки управления проектамиНавыки управления персоналом
- 78. Методика разработки продуктаПроцессы оценивания - определение критериев
- 79. Методика разработки продуктаУправление субподрядчиками - планирование, управление
- 80. Методика разработки продуктаОтслеживание качества продукта - контроль
- 81. Навыки управления проектамиСоздание структуры пооперационного перечня работДокументирование
- 82. Навыки управления проектамиОтслеживание процесса разработки - контроль
- 83. Навыки управления проектамиОтслеживание процессов - мониторинг совместимости
- 84. Навыки управления персоналомОценка производительности - оценка действий
- 85. Навыки управления персоналомЛидерство - обучение проектных команд
- 86. Навыки управления персоналомЭффективное представление - использование письменных
- 87. Управление командой проекта Управление программным проектом включает решение
- 88. Основные вопросы при управлении командойРолевая модель командыМодели организации командОбщение в команде
- 89. Ролевая модель командыСостав команды определяется опытом и
- 90. Ролевая модель командыМенеджер проектаПроектировщикРазработчикТестировщикИнженер по качествуТехнический писательТехнолог разработки ПО
- 91. Менеджер проектаМенеджер проекта - главное действующее лицо,
- 92. ПроектировщикПроектировщик - это функция проектирования архитектуры высокого
- 93. Проектировщик. Основные функцииАнализ требованийРазработка архитектуры и основных интерфейсовУчастие в планировании проектаКонтроль выполнения проектаУчастие в подборе кадров
- 94. РазработчикРазработчик – роль, ответственная за непосредственное создание
- 95. РазработчикДиагностика и разрешение всех технических проблемКонтроль за
- 96. Тестировщик Тестировщик – роль, ответственная за удовлетворение
- 97. ТестировщикКонтроль выполнения плана. Важнейшая функция контроля –
- 98. ТестировщикРазработка тестов. Самая трудоемкая часть в работе
- 99. ТестировщикВыбор инструментов, метрик, стандартов для организации процесса
- 100. Инженер по качеству Функции, отличные от функций
- 101. Инженер по качествуОценка процессов включает регистрацию хода
- 102. Технический писательТехнический писатель - разработчик пользовательской (и
- 103. Технический писательВыбор средств автоматизации документированияРазработка документацииОрганизация тестирования
- 104. Скачать презентанцию
Контактная информацияБондаренко Иван ЮрьевичEmail: bond005@yandex.ruSkype: i_yu_bondarenko
- ВКонтакте
- РћРТвЂВВВВВВВВнокласснРСвЂВВВВВВВВРєРСвЂВВВВВВВВ
- РњРѕР№ Р В Р’В Р РЋРЎв„ўР В Р’В Р РЋРІР‚ВВВВВВВВРЎР‚
Слайды и текст этой презентации
Слайд 1Введение в программную инженерию
для студентов первого курса специальности «Инженерия программного
обеспечения»
Слайд 3Определение
Программная инженерия – это:
установление и использование обоснованных инженерных
принципов (методов) для экономного получения ПО, которое надежно и работает
на реальных машинах. [Bauer 1972].дисциплина, целью которой является создание качественного ПО, которое завершается вовремя, не превышает выделенных бюджетных средств и удовлетворяет выдвигаемым требованиям [Schach, 99]
Слайд 4Полезные ссылки
Форум «Исходники.ру» - http://forum.sources.ru/
Библиотека MSDN (Microsoft Developer Network) -
http://msdn.microsoft.com/ru-ru/library
Сайт RSDN (Russian Software Developer Network) - http://rsdn.ru/
Слайд 5Полезные ссылки
Форум SQL.ru - http://www.sql.ru/
Сайт «Королевство Delphi» - http://delphikingdom.ru/
«Программирование для
прагматиков» (блог Алёны Сагалаевой, посвящённый программированию на C++ и не
только) - http://alenacpp.blogspot.com/
Слайд 6
Становление программной инженерии. Предпосылки
В конце 60-х – начале 70-х
годов произошел кризис программирования - стоимость программного обеспечения стала приближаться
к стоимости аппаратуры («железа»).Тогда и заговорили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ.
С тех пор становление программной инженерии прошло ряд этапов, каждый этап связан с появлением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы.
Слайд 7Этапы становления программной инженерии
1. Повторное использование кода (модульное программирование)
Проблема: высокая
стоимость программ связана с разработкой одинаковых (или похожих) фрагментов кода
в различных программах.Модульное программирование. Главный принцип модульного программирования состоял в выделении таких фрагментов и оформлении их в виде модулей. Каждый модуль снабжался описанием, в котором устанавливались правила его использования – интерфейс модуля.
Слайд 8Этапы становления программной инженерии
2. Рост сложности программ (структурное программирование)
Проблема: Следующий этап возрастания стоимости ПО был связан с
переходом от разработки относительно простых программ к разработке сложных программных комплексов. К числу таких сложных программ относятся: системы управления космическими объектами, автоматизации крупного финансового учреждения и т.д. Сложность таких комплексов оценивалась следующими показателями: большой объем кода (миллионы строк); большое количество связей между элементами кода; большое количество разработчиков (сотни человек); большое количество пользователей (сотни и тысячи).
Слайд 9Этапы становления программной инженерии
2. Рост сложности программ (структурное программирование)
Структурное программирование.
Этап сопровождения программного комплекса включал действия по исправлению ошибок в
работе программы и внесению изменений в соответствии с изменившимися требованиями пользователей. Основная причина высокой стоимости (а порой и невозможности выполнения) этапа сопровождения состояла в том, что программы были плохо спроектированы – документация была не понятна и не соответствовала программному коду, а сам программный код был очень сложен и запутан. Нужна технология, которая обеспечит «правильное» проектирование и кодирование.
Слайд 10Этапы становления программной инженерии
3. Модификация программ (объектно-ориентированное программирование)
Проблема. Следующая проблема
роста стоимости программ была вызвана тем, что изменение требований к
программе стали возникать не только на стадии сопровождения, но и на стадии проектирования – проблема заказчика, который не знает, что он хочет. Возник вопрос как проектировать и писать программы, чтобы обеспечить возможность внесений изменений в программу, не меняя ранее написанного кода.
Слайд 11Этапы становления программной инженерии
3. Модификация программ
Объектно-ориентированное программирование. Суть подхода состоит
в том, что вводится понятие класса как развитие понятия модуля
с определенными свойствами и поведением, характеризующими обязанностями класса. Каждый класс может порождать объекты – экземпляры данного класса. При этом работают основные принципы:- Инкапсуляция – объединение в классе данных (свойств) и методов (процедур обработки).
- Наследование – возможность вывода нового класса из старого с частичным изменением свойств и методов
- Полиморфизм – определение свойств и методов объекта по контексту
Слайд 12Определения
Жизненный цикл – непрерывный процесс, начинающийся с момента принятия решения
о создании ПО и заканчивающийся снятием его с эксплуатации. Жизненный
цикл разбивается на отдельные процессы.Процесс – совокупность действий и задач, имеющих целью достижение значимого результата.
Основными процессами (иногда называют этапами или фазами) жизненного цикла являются:
Слайд 13Определения
Разработка спецификации требований (результат – описания требований к программе, которые
обязательны для выполнения – описание того, что программа должна делать)
Разработка
проекта программы (результат – описание того, как программа будет работать)Кодирование (результат – исходный код и файлы конфигурации)
Тестирование программы (результат - контроль соответствия программы требованиям)
Документирование (результат – документация к программе)
Слайд 14Модели жизненного цикла программы
Водопадная (каскадная) модель – процесс разбивается на
последовательное выполнение стадий; каждая стадия начинается после полного завершения предыдущей,
продукт создается завершением последней стадии и должен полностью соответствовать изначально установленным требованиям.Спиральная (циклическая) модель – процесс также разбивается на стадии, но стадии выполняются циклическим повторением. На первом цикле создается прототип продукта, выполняющий часть требований. Дальнейшие циклы связаны с наращиванием прототипа до полного удовлетворения требований.
Слайд 15Модели жизненного цикла программы
Компонентная модель предполагает сборку продукта из заранее
написанных частей – компонент. Основной упор делается на интеграцию и
совместное тестирование компонент.Формальная модель основана на формальном описании требований с последующим преобразованием (трансляцией) требований в исходный код. Применение формальной модели гарантирует соответствие кода описанным требованиям.
Задача программного инженера – подобрать правильную комбинацию моделей, ориентируясь только на конечный результат.
Слайд 16Некоторые итоги
Главная цель программной инженерии - сокращение стоимости и сроков
разработки программ.
Основной принцип программной инженерии состоит в том, что
программы создаются в результате выполнения нескольких взаимосвязанных этапов (анализ требований, проектирование, разработка, внедрение, сопровождение), составляющих жизненный цикл программного продукта. Фундаментальными методами проектирования и разработки являются модульное, структурное и объектно-ориентированное проектирование и программирование.
Слайд 17Продолжение кризиса программного обеспечения
По информации агентства
Standish Group
Деловой мир США ежегодно
тратит $250 млрд. на разработку программного обеспечения.
Стоимость среднего проекта колеблется
от $430 000 до $2 300 000 – в зависимости от размера компании.
Слайд 19Примеры неудачных проектов
Высокотехнологической жемчужиной нового международного аэропорта в Денвере, открывшегося
11 лет назад, должна была стать автоматизированная багажная линия. Предполагалось,
что почти 42 км конвейеров будут быстро и без задержек доставлять чемоданы и дорожные сумки к багажным отсекам самолетов в залы прилета.
Слайд 20Примеры неудачных проектов
Проблемы с программным обеспечением задержали открытие аэропорта на
16 месяцев и повлекли за собой дополнительные расходы в сотни
миллионов долларов. Настройка автоматизированной линии длилась еще несколько лет, но требуемого уровня надежности так и не удалось достичь.
Слайд 21Примеры неудачных проектов
Летом 2003 года проблема была, наконец, решена: теперь
багаж доставляют вручную на обычных грузовых тележках. Фирма BAE Automated
Systems, разрабатывавшая багажный конвейер, была ликвидирована, а компания United Airlines, ее главный заказчик, оказалась на грани банкротства.
Слайд 22Примеры неудачных проектов
В 1997 году Налоговое управление США без
толку потратило $4 млрд. на новый компьютерный проект, а потом
еще $8 млрд. на его модернизацию.В 2005 году неудачу потерпело ФБР, потерявшее $170 млн. на разработке виртуальной системы управления делами, которая оказалась неработоспособной.
Несмотря на огромные затраты, Федеральное управление гражданской авиации США до сих пор не может справиться с обновлением морально устаревшей системы управления воздушным движением.
Слайд 23Тяжеловесные и облегченные процессы
Традиционно для упорядочения и ускорения программных разработок
предлагались строго упорядочивающие тяжеловесные процессы. В этих процессах прогнозируется весь
объем предстоящих работ, поэтому они называются прогнозирующими процессами. Порядок, который должен выполнять при этом, чрезвычайно строг — «шаг вправо, шаг влево — виртуальный расстрел!».
Слайд 24Тяжеловесные и облегченные процессы
В последние годы появилась группа новых, облегченных
процессов. Теперь их называют подвижными процессами. Они привлекательны отсутствием бюрократизма,
характерного для тяжеловесных (прогнозирующих) процессов. Новые процессы должны воплотить в жизнь разумный компромисс между слишком строгой дисциплиной и полным ее отсутствием.
Слайд 25Тяжеловесные и облегченные процессы
У каждого семейства есть свои достоинства, недостатки
и область применения:
адаптивный процесс используют при частых изменениях требований, малочисленной
группе высококвалифицированных разработчиков и грамотном заказчике, который согласен участвовать в разработке;прогнозирующий процесс применяют при фиксированных требованиях и многочисленной группе разработчиков разной квалификации.
Слайд 26Экстремальное программирование (ХР-процесс)
Экстремальное программирование (ХР)– вид облегченного (подвижного) процесса (1999
г.)
ХР-процесс должен быть высокодинамичным процессом. ХР-группа имеет дело с изменениями
требований на всем протяжении итерационного цикла разработки, причем цикл состоит из очень коротких итераций. Четырьмя базовыми действиями в ХР-цикле являются: кодирование, тестирование, выслушивание заказчика и проектирование. 
Слайд 27Экстремальное программирование (ХР-процесс)
Динамизм обеспечивается с помощью четырех характеристик: непрерывной связи
с заказчиком (и в пределах группы), простоты (всегда выбирается минимальное
решение), быстрой обратной связи (с помощью модульного и функционального тестирования), смелости в проведении профилактики возможных проблем.Большинство принципов, поддерживаемых в ХР, продиктованы здравым смыслом и применяются в любом упорядоченном процессе. Просто в ХР эти принципы достигают «экстремальных значений».
Слайд 28Экстремальное программирование (ХР-процесс), примеры экстремальных значений
Принцип постоянной проверки кода реализуется
с помощью парного программирования - весь код пишется двумя программистами,
работающими на одном компьютере.Частая смена версий — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.
Коллективное владение кодом — любой разработчик может улучшать любой код системы в любое время.
Слайд 29Требования к «хорошим» программам
«Хорошая программа» должна делать то, что ожидает
от нее заказчик – т.е. удовлетворять требованиям заказчика. Такие требования
называют функциональными. Но кроме функциональных требований, существует еще ряд общих характеристик, которым в той или иной степени должна обладать каждая программа.
Слайд 30Требования к «хорошим» программам
1) Сопровождаемость. Сопровождаемость означает, что программа должна
быть написана с расчетом на дальнейшее развитие. Это критическое свойство
системы, т.к. изменения ПО неизбежны вследствие изменения бизнеса. Сопровождение программы выполняют, как правило, не те люди, которые ее разрабатывали. Сопровождаемость включает такие элементы как наличие и понятность проектной документации, соответствие проектной документации исходному коду, понятность исходного кода, простота изменений исходного кода, простота добавления новых функций.
Слайд 31Требования к «хорошим» программам
2) Надежность. Надежность ПО включает такие элементы
как:
Отказоустойчивость – возможность восстановления программы и данных в случае сбоев
в работе.Безопасность – сбои в работе программы не должны приводить к опасным последствиям (авариям).
Защищенность от случайных или преднамеренных внешних воздействий (защита от дурака, вирусов, спама).
Слайд 32Требования к «хорошим» программам
3) Эффективность. ПО не должно впустую тратить
системные ресурсы, такие как память, процессорное время, каналы связи. Поэтому
эффективность ПО оценивается следующими показателями: время выполнения кода, загруженность процессора, объем требуемой памяти, время отклика и т.п.4) Удобство использования. ПО должно быть легким в использовании, причем именно тем типом пользователей, на которых рассчитано приложение. Это включает в себя интерфейс пользователя и адекватную документацию.
Слайд 33Профессиональные обязательства программистов
Конфиденциальность – программные специалисты должны уважать конфиденциальность в
отношении своих работодателей или заказчиков независимо от того, подписывалось ли
ими соответствующее соглашение.Компетентность – программный специалист не должен завышать свой истинный уровень компетентности и не должен сознательно браться за работу, которая этому уровню не соответствует.
Слайд 34Профессиональные обязательства программистов
Защита интеллектуальной собственности – специалист должен соблюдать законодательство
и принципы защиты интеллектуальной собственности при использовании чужой интеллектуальной собственности.
Кроме того, он должен защищать интеллектуальную собственность работодателя и клиента. Внимание: создаваемая им интеллектуальная собственность является собственностью работодателя или клиента.Злоупотребление компьютером – программный специалист не должны злоупотреблять компьютерными ресурсами работодателя или заказчика; под злоупотреблениями мы здесь понимаем широкий спектр — от игр в компьютерные игрушки на рабочем месте до распространения вирусов.
Слайд 35Стандартизация и стандарты
По происхождению программные продукты бывают двух типов: заказные
(под заказ конкретного потребителя) и коробочные (для массовой продажи на
рынке). Для заключения контракта заказчик должен быть уверен, что разработчик справится и не завалит проект. Вопрос: как его в этом убедить?В мировой практике промышленного производства ответы на эти вопросы дают стандарты на производство продуктов и услуг и сертификация производителей на соответствие этим стандартам.
Слайд 36Профессиональный стандарт
SWEBOK (Стандарт ISO/IEC TR 19759 IEEE, 15.09.2005) – дает
представление о знаниях программного инженера, имеющего степень бакалавра и четырехлетний
опыт работы
Слайд 37SWEBOK (SoftWare Engineering Body Of Knowledge)
Содержит описания состава знаний по
следующим 10 разделам (областям знаний) программной инженерии:
Software Requirements – требования
к ПОSoftware Design – проектирование ПО
Software Construction – конструирование ПО
Software Testing – тестирование ПО
Software Maintenance – сопровождение ПО
Слайд 38SWEBOK (SoftWare Engineering Body Of Knowledge)
Software Configuration Management – управление
конфигурациями
Software Engineering Management – управление IT проектом
Software Engineering Process
– процесс программной инженерииSoftware Engineerting Tools and Methods – методы и инструменты
Software Quality – качество ПО
Подробнее: Guide to the Software Engineering Body of Knowledge - http://www.swebok.org/
Слайд 39Определение требований к программной системе
Существуют функциональные и нефункциональные требования. Функциональные
требования регламентируют функционирование или поведение системы, они должны отвечать на
вопрос: «что должна делать система», абстрагируясь от вопроса «как она это должна делать». Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы (примеры: ограничения, атрибуты качества, внешние интерфейсы).
Слайд 41UML (Unified Modeling Language)
UML (унифицированный язык
моделирования) —
язык графического описания
для объектного моделирования в области разработки программного обеспечения. UML является
языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью.
Слайд 42Описание требований к программной системе – диаграмма вариантов использования
Варианты использования
– это методика формирования требований, основанная на сценариях. Этот вид
диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.В самой простой форме в вариантах использования определены действующие лица – актеры и возможные взаимодействия – прецеденты.
Слайд 43Диаграмма вариантов использования
Диаграммы вариантов использования описывают взаимоотношения и зависимости между
группами вариантов использования (прецедентами) и действующих лиц (актерами), участвующими в
процессе.
Слайд 46Правила построения диаграммы
При работе с вариантами использования важно помнить несколько
простых правил:
каждый вариант использования относится как минимум к одному
действующему лицу;каждый вариант использования имеет инициатора;
каждый вариант использования приводит к соответствующему результату.
Слайд 47Связи между прецедентами в диаграмме вариантов использования
Варианты использования также могут
взаимодействовать с другими вариантами использования. Три наиболее часто встречающихся типа
взаимодействия между вариантами использования приведены ниже:- <<включение>> указывает, что вариант использования встраивается в другой вариант использования;
Слайд 48Связи между прецедентами в диаграмме вариантов использования
- () указывает,
что в определённых ситуациях или в некоторой точке (называемой точкой
расширения) вариант использования будет расширен другим;- <<обобщение>> (<<наследование>>) указывает, что вариант использования наследует характеристики «родительского» варианта использования и может переопределить некоторые из них или добавить новые, подобно наследованию в классах.
Слайд 50Связи между прецедентами в диаграмме вариантов использования
Следует подчеркнуть, что потомок
наследует все свойства поведения своего родителя, а также может обладать
дополнительными особенностями поведения.
Слайд 51Связи между актером и прецедентом
Отношение – одно из фундаментальных
понятий в языке UML и в той или иной степени
используется при построении всех графических моделей систем в форме канонических диаграмм.Применительно к диаграммам вариантов использования <<ассоциация>> служит для обозначения специфической роли актера при его взаимодействии с отдельным вариантом использования. Другими словами, <<ассоциация>> специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы. Других связей между актером и прецедентом быть не может!
Слайд 54Описание требований к системе дистанционного обучения
Актеры: студент, преподаватель, администратор системы,
база данных
Прецеденты:
студент: аутентификация, просмотр лекций, выполнение заданий, тестирование;
преподаватель:
аутентификация, внесение новой информации, составление тестов, просмотр результатов тестирования студентов;
Слайд 57Microsoft Visio
Пакет Microsoft Visio предназначен для визуального общения с помощью
чертежей и диаграмм.
Программа Visio дает возможность быстро и эффективно
создавать при помощи встроенных шаблонов, трафаретов и стандартных модулей как простейшие слайды и схемы, так и очень сложные чертежи и диаграммы. 
Слайд 58Для создания диаграммы необходимо выбрать шаблон. Основные типы шаблонов:
бизнес;
блок-схемы;
карты и
планы этажей;
общие;
программное обеспечение и базы данных;
расписание;
сеть;
техника.
Слайд 59Microsoft Visio. Основные понятия
Связанные друг с другом фигуры включены в
трафареты.
Например, если создать «Простую блок-схему» из шаблона «Блок-схема», то можно
увидеть, что стандартно в таком документе будет четыре трафарета: стрелки, фоновые рисунки, фигуры простой блок-схемы, рамки и заголовки. 
Слайд 61Работа с фигурами
Для добавления фигуры в документ, её надо «перетащить»
из раздела трафарета в рабочую область документа.
Для изменения размеров, положения
фигуры на рабочей области предназначены маркеры-манипуляторы, которые появляются в случае активации фигуры.Для добавления к фигуре текста достаточно её выделить и вводить текст.
Слайд 62Соединения фигур
Для соединения нескольких фигур используют соединительные линии, которые при
перемещаются вместе с фигурами, к которым они привязаны.
Слайд 63Создание UML-диаграммы
Для создания UML диаграммы выбирают шаблон «Программное обеспечение и
базы данных» - «Схемы модели UML».
Данный шаблон содержит
трафареты для создания множества UML диаграмм: сценарии выполнения (диаграмма вариантов использования), деятельности, классов, компонентов, состояний.
Слайд 64Создание собственных фигур для диаграмм и схем Microsoft Visio
С помощью
панели инструментов Рисование (Drawing) можно создавать собственные фигуры
С помощью пункта
меню Фигура можно производить различные операции над нарисованными фигурами (объединение, пересечение и др.)
Слайд 65Сохранение созданной фигуры в трафарете
Для сохранения созданной фигуры достаточно «перетащить»
её с рабочей области на трафарет. Однако, стандартные трафареты Visio
открыты только для чтения, добавлять фигуры можно в новый трафарет ([Файл]-> [Фигуры]-> [Создать новый набор]).
Слайд 66Управление программным проектом
Управление - изменение состояния объекта, системы или процесса,
ведущее к достижению поставленной цели.
Слово «проект» имеет достаточно
много значений. Происходит от латинского projectus, что означает «брошенный вперед».Проект – это произвольный ряд действий или задач, имеющий определенную цель, которая будет достигнута в рамках выполнения некоторых заданий, характеризующихся определенными датами начала и окончания, пределами финансирования и ресурсами
Слайд 67Характеристики проекта
Цель проекта. Наличие четко выраженного конечного результата, выхода, продукции,
определяемых в терминах затрат, качества и времени реализации.
Уникальность. Проект
- это разовое начинание, которое не будет повторяться. Даже “повторяющиеся” проекты, например, по строительству еще одного предприятия по той же проектной документации, значительно отличаются друг от друга использующимися ресурсами и средой реализации. 
Слайд 68Характеристики проекта
Ограниченность во времени. Проект имеет начало и конец. Для
его реализация необходима временная концентрация ресурсов. По минованию надобности, ресурсы
используются на другие цели.Ограниченность ресурсов, выделяемых на выполнение проекта (финансовых, людских, материальных).
Сложность. Для достижения целей проекта необходимо решить множество задач. Отношения между задачами могут быть довольно сложными, особенно, если в проекте много задач.
Слайд 69Характеристики проекта
Неопределенность. Возможность достижения цели в указанные сроки с выделенными
ресурсами заранее не гарантирована.
Предсказуемость. По мере реализации проекта, изменяется потребность
в тех или иных ресурсах. Это изменение идет в определенной предсказуемой последовательности, определяемой жизненным циклом проекта. 
Слайд 70Управление проектами
Управление проектами - набор проверенных принципов, методов и методик,
применяемых для эффективного планирования, составления графика, управления и отслеживания результатов
работы.
Слайд 71Основные принципы
Основные принципы:
Умение – знание принципов и методов управления проектом
(планирования, организация, составление графиков, контроль, управление и отслеживание).
Навыки – опыт
в области управления – применение умения для достижения целей в конкретных условиях.
Слайд 72Категории управления проектами
Выделяют следующие группы категорий
Цели, определяемые ожидаемыми результатами проекта.
Критерии
успеха и ограничения: стоимость, сроки, качество.
Основные рычаги управления: ресурсы (являющиеся
также ограничением) и технологии. 
Слайд 73Категории управления проектами (продолжение)
Вспомогательные рычаги управления: контракты, организация, взаимодействие, персонал.
Неопределенность,
связанная с рисками выполнения проекта.
Слайд 74Треугольник ограничений проекта
Закон Лермана: "Любую техническую проблему можно преодолеть, имея
достаточно времени и денег»
Следствие Лермана: «Вам никогда не будет хватать
либо времени, либо денег»
Слайд 75Непроект - это
Программа
широкомасштабное усилие, направленное на достижение некоторой комплексной цели
цель
конкретна, сроки и ресурсы не определены
Выполнение установившегося процесса
деятельность, которая
выполняется многократно и постоянноимеет конкретную цель, выделенные ресурсы
не является уникальной, сложной и не связана с конкретными сроками
Решение творческой задачи
есть цель, уникальность и сложность
нет ограничений по времени и ресурсам
слишком велика степень неопределенности
Слайд 76SQI: 34 компетенции IT менеджера
Главное действующее лицо проекта –
менеджер.
Институтом качества ПО (SQI - Software Quality Institute) разработан
руководящей документ (Body of Knowledge) для сертификации менеджеров программных проектов (SWPM – SoftWare Project Management). В этом документе содержится список 34 компетенций, которыми должен обладать менеджер программного проекта. 
Слайд 77Компетенции IT менеджера
Три основные категории:
Методика разработки продукта
Навыки управления проектами
Навыки
управления персоналом
Слайд 78Методика разработки продукта
Процессы оценивания - определение критериев для отбора
Знание стандартов
процесса
Определение продукта - идентификация клиентской среды и требований, выдвигаемых к
продуктуОценка альтернативных процессов
Управление требованиями- мониторинг изменения требований
Слайд 79Методика разработки продукта
Управление субподрядчиками - планирование, управление и осуществление контроля
Выполнение
начальной оценки - оценка степени трудности, рисков, затрат и создание
графиковОтбор методов и инструментов - определение процессов отбора
Подгонка процессов - модификация стандартных процессов с целью удовлетворения требований проектов
Слайд 80Методика разработки продукта
Отслеживание качества продукта - контроль качества в процессе
разработки продукта
Понимание действий по разработке продукта - изучение цикла разработки
ПО
Слайд 81Навыки управления проектами
Создание структуры пооперационного перечня работ
Документирование планов - идентификация
ключевых компонент
Оценка стоимости - стоимости завершения проекта
Оценка трудозатрат - необходимых
для завершения проектаМенеджмент рисков - идентификация, определение воздействия, обработка рисков
Слайд 82Навыки управления проектами
Отслеживание процесса разработки - контроль процесса разработки
Составление графика
- разработка графика и ключевых стадий проекта
Выбор метрических показателей
Отбор инструментов
менеджмента проекта - выбор методик и инструментов
Слайд 83Навыки управления проектами
Отслеживание процессов - мониторинг совместимости членов команды
Отслеживание хода
разработки продукта - мониторинг хода разработки по выбранным метрическим показателям
Слайд 84Навыки управления персоналом
Оценка производительности - оценка действий команды, направленных на
повышение ее производительности
Вопросы интеллектуальной собственности - понимание степени влияния критических
проблемОрганизация эффективных встреч - планирование и проведение
Взаимодействие и общение - с разработчиками, руководством и другими командами
Слайд 85Навыки управления персоналом
Лидерство - обучение проектных команд для получения оптимальных
результатов
Управление изменениями - обеспечение эффективного управления изменениями
Успешное ведение переговоров -
разрешение конфликтов и ведение переговоровПланирование карьерного роста - структурирование и управление ходом реализации карьеры
Слайд 86Навыки управления персоналом
Эффективное представление - использование письменных и устных навыков
Набор
персонала - вербовка и собеседование с членами команды
Отбор команды -
выбор высококомпетентных специалистовСоздание команды - формирование, руководство и поддержка эффективной команды
Слайд 87Управление командой проекта
Управление программным проектом включает решение трех основных задач.
Подбор
и управление командой
Выбор процесса
Выбор инструментальных средств
Эффективное решение первой из задач
предопределяет успех всего проекта.
Слайд 88Основные вопросы при управлении командой
Ролевая модель команды
Модели организации команд
Общение в
команде
Слайд 89Ролевая модель команды
Состав команды определяется опытом и уровнем коллектива, особенностями
проекта, применяемыми технологиями и уровнем этих технологий.
Один из вариантов
состава команды приведен на следующем слайде.
Слайд 90Ролевая модель команды
Менеджер проекта
Проектировщик
Разработчик
Тестировщик
Инженер по качеству
Технический писатель
Технолог разработки ПО
Слайд 91Менеджер проекта
Менеджер проекта - главное действующее лицо, обладающее знаниями и
навыками, необходимыми для успешного управления проектом. Его основные функции:
Подбор и
управление кадрамиПодготовка и исполнение плана проекта
Руководство командой
Обеспечение связи между подразделениями
Обеспечение готовности продукта
Слайд 92Проектировщик
Проектировщик - это функция проектирования архитектуры высокого уровня и контроля
ее выполнения. В небольших командах функция распределяется между менеджером и
разработчиками. В больших проектах это может быть целый отдел.
Слайд 93Проектировщик. Основные функции
Анализ требований
Разработка архитектуры и основных интерфейсов
Участие в планировании
проекта
Контроль выполнения проекта
Участие в подборе кадров
Слайд 94Разработчик
Разработчик – роль, ответственная за непосредственное создание конечного продукта. Помимо
собственно программирования (кодирования) в его функции входит:
Контроль архитектурных
и технических спецификаций продуктаПодбор технологических инструментов и стандартов
Слайд 95Разработчик
Диагностика и разрешение всех технических проблем
Контроль за работой разработчиков документации,
тестирования, технологов
Мониторинг состояния продукта (ведение списка обнаруженных ошибок)
Подбор инструментов разработки,
метрик и стандартов. Контроль их использования. 
Слайд 96Тестировщик
Тестировщик – роль, ответственная за удовлетворение требований к продукту
(функциональных и нефункциональных). В функции тестировщика входит:
Составление плана тестирования. План
тестирования составляет один из элементов проекта и составляется до начала реализации (разработки) проекта. Время, отводимое в плане на тестирование может быть сопоставимо с временем разработки.
Слайд 97Тестировщик
Контроль выполнения плана. Важнейшая функция контроля – поддержка целостности базы
данных зарегистрированных ошибок. В этой базе регистрируется:
кто, когда и
где обнаружил, описание ошибки, описание состояния среды;статус ошибки: приоритет, кто разрешает
состояние ошибки: висит, в разработке, разрешена, проблемы
Эта база должна быть доступна всем, т.к. в тестировании принимают участие все члены команды.
Слайд 98Тестировщик
Разработка тестов. Самая трудоемкая часть в работе тестировщика. Тестирование должно
обеспечить полную проверку функциональности при всех режимах работы продукта.
Автоматизация
тестирования включает автоматизацию составления тестов, автоматизацию пропуска тестов и автоматизацию обработки результатов тестирования. В виду важности автоматизации тестирования, иногда вводят нового участника – инженера по автоматизации.
Слайд 99Тестировщик
Выбор инструментов, метрик, стандартов для организации процесса тестирования.
Организация Бета тестирования
- тестирования почти готового продукта внешними тестерами (пользователями). Эту важную
процедуру надо продумать и организовать в случае разработки коробочного продукта.
Слайд 100Инженер по качеству
Функции, отличные от функций тестировщика:
Составление плана
качества. План качества включает все мероприятия по повышению качества (на
всех уровнях). Имеет долговременный характер. План тестирования – его оперативная составляющая.Описание процессов. Описание процессов является их формализацией. При описании вводятся метрики процесса, влияющие на качество продукта.
Слайд 101Инженер по качеству
Оценка процессов включает регистрацию хода выполнения процессов и
оценку значений установленных метрик процессов. Выявление «слабых» мест и выработка
рекомендаций по улучшению процессов.
Слайд 102Технический писатель
Технический писатель - разработчик пользовательской (и иной) документации как
части программного продукта. Функциями технического писателя являются:
Разработка плана документирования,
который включает состав, сроки подготовки и порядок тестирования документов.Выбор и разработка стандартов и шаблонов подготовки документов.
Слайд 103Технический писатель
Выбор средств автоматизации документирования
Разработка документации
Организация тестирования документации
Участие в тестировании
продукта. Технический писатель все время работает с продуктом (его готовыми
версиями) и выступая от имени пользователя видит все недочеты и несоответствия.
