Введение в программную инженерию для студентов первого курса

Введение в программную инженерию для студентов первого курса специальности «Инженерия программного обеспечения» 1/31/2018 Разработал: ассистент каф. ПМИ Бондаренко Иван Юрьевич 1

Контактная информация Бондаренко Иван Юрьевич Email: bond 005@yandex. ru Skype: i_yu_bondarenko 1/31/2018 2

Определение Программная инженерия – это: – – установление и использование обоснованных инженерных принципов (методов) для экономного получения ПО, которое надежно и работает на реальных машинах. [Bauer 1972]. дисциплина, целью которой является создание качественного ПО, которое завершается вовремя, не превышает выделенных бюджетных средств и удовлетворяет выдвигаемым требованиям [Schach, 99] 1/31/2018 3

Полезные ссылки 1. Форум «Исходники. ру» - http: //forum. sources. ru/ 2. Библиотека MSDN (Microsoft Developer Network) - http: //msdn. microsoft. com/ruru/library 3. Сайт RSDN (Russian Software Developer Network) - http: //rsdn. ru/ 1/31/2018 4

Полезные ссылки 1. Форум SQL. ru - http: //www. sql. ru/ 2. Сайт «Королевство Delphi» - http: //delphikingdom. ru/ 3. «Программирование для прагматиков» (блог Алёны Сагалаевой, посвящённый программированию на C++ и не только) - http: //alenacpp. blogspot. com/ 1/31/2018 5

Становление программной инженерии. Предпосылки В конце 60 -х – начале 70 -х годов произошел кризис программирования - стоимость программного обеспечения стала приближаться к стоимости аппаратуры ( «железа» ). Тогда и заговорили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ. С тех пор становление программной инженерии прошло ряд этапов, каждый этап связан с появлением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы. 1/31/2018 6

Этапы становления программной инженерии 1. Повторное использование кода (модульное • • программирование) Проблема: высокая стоимость программ связана с разработкой одинаковых (или похожих) фрагментов кода в различных программах. Модульное программирование. Главный принцип модульного программирования состоял в выделении таких фрагментов и оформлении их в виде модулей. Каждый модуль снабжался описанием, в котором устанавливались правила его использования – интерфейс модуля. 1/31/2018 7

Этапы становления программной инженерии 1/31/2018 2. Рост сложности программ (структурное программирование) 8

Этапы становления программной инженерии 2. Рост сложности программ (структурное программирование) Структурное программирование. Этап сопровождения программного комплекса включал действия по исправлению ошибок в работе программы и внесению изменений в соответствии с изменившимися требованиями пользователей. Основная причина высокой стоимости (а порой и невозможности выполнения) этапа сопровождения состояла в том, что программы были плохо спроектированы – документация была не понятна и не соответствовала программному коду, а сам программный код был очень сложен и запутан. Нужна технология, которая обеспечит «правильное» проектирование и кодирование. 1/31/2018 9

Этапы становления программной инженерии 3. Модификация программ (объектноориентированное программирование) Проблема. Следующая проблема роста стоимости программ была вызвана тем, что изменение требований к программе стали возникать не только на стадии сопровождения, но и на стадии проектирования – проблема заказчика, который не знает, что он хочет. Возник вопрос как проектировать и писать программы, чтобы обеспечить возможность внесений изменений в программу, не меняя ранее написанного кода. 1/31/2018 10

Этапы становления программной инженерии 3. Модификация программ Объектно-ориентированное программирование. Суть подхода состоит в том, что вводится понятие класса как развитие понятия модуля с определенными свойствами и поведением, характеризующими обязанностями класса. Каждый класс может порождать объекты – экземпляры данного класса. При этом работают основные принципы: - Инкапсуляция – объединение в классе данных (свойств) и методов (процедур обработки). - Наследование – возможность вывода нового класса из старого с частичным изменением свойств и методов - Полиморфизм – определение свойств и методов объекта по контексту 1/31/2018 11

Определения • • • Жизненный цикл – непрерывный процесс, начинающийся с момента принятия решения о создании ПО и заканчивающийся снятием его с эксплуатации. Жизненный цикл разбивается на отдельные процессы. Процесс – совокупность действий и задач, имеющих целью достижение значимого результата. Основными процессами (иногда называют этапами или фазами) жизненного цикла являются: 1/31/2018 12

Определения • • • Разработка спецификации требований (результат – описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать) Разработка проекта программы (результат – описание того, как программа будет работать) Кодирование (результат – исходный код и файлы конфигурации) Тестирование программы (результат - контроль соответствия программы требованиям) Документирование (результат – документация к программе) 1/31/2018 13

Модели жизненного цикла программы Водопадная (каскадная) модель – процесс разбивается на последовательное выполнение стадий; каждая стадия начинается после полного завершения предыдущей, продукт создается завершением последней стадии и должен полностью соответствовать изначально установленным требованиям. Спиральная (циклическая) модель – процесс также разбивается на стадии, но стадии выполняются циклическим повторением. На первом цикле создается прототип продукта, выполняющий часть требований. Дальнейшие циклы связаны с наращиванием прототипа до полного удовлетворения требований. 1/31/2018 14

Модели жизненного цикла программы Компонентная модель предполагает сборку продукта из заранее написанных частей – компонент. Основной упор делается на интеграцию и совместное тестирование компонент. Формальная модель основана на формальном описании требований с последующим преобразованием (трансляцией) требований в исходный код. Применение формальной модели гарантирует соответствие кода описанным требованиям. Задача программного инженера – подобрать правильную комбинацию моделей, ориентируясь только на конечный результат. 1/31/2018 15

Некоторые итоги Главная цель программной инженерии - сокращение стоимости и сроков разработки программ. Основной принцип программной инженерии состоит в том, что программы создаются в результате выполнения нескольких взаимосвязанных этапов (анализ требований, проектирование, разработка, внедрение, сопровождение), составляющих жизненный цикл программного продукта. Фундаментальными методами проектирования и разработки являются модульное, структурное и объектно-ориентированное проектирование и программирование. 1/31/2018 16

Продолжение кризиса программного обеспечения По информации агентства Standish Group Деловой мир США ежегодно тратит $250 млрд. на разработку программного обеспечения. Стоимость среднего проекта колеблется от $430 000 до $2 300 000 – в зависимости от размера компании. 1/31/2018 17

Продолжение кризиса программного обеспечения По информации агентства Standish Group 1/31/2018 18

Примеры неудачных проектов Высокотехнологической жемчужиной нового международного аэропорта в Денвере, открывшегося 11 лет назад, должна была стать автоматизированная багажная линия. Предполагалось, что почти 42 км конвейеров будут быстро и без задержек доставлять чемоданы и дорожные сумки к багажным отсекам самолетов в залы прилета. 1/31/2018 19

Примеры неудачных проектов Проблемы с программным обеспечением задержали открытие аэропорта на 16 месяцев и повлекли за собой дополнительные расходы в сотни миллионов долларов. Настройка автоматизированной линии длилась еще несколько лет, но требуемого уровня надежности так и не удалось достичь. 1/31/2018 20

Примеры неудачных проектов Летом 2003 года проблема была, наконец, решена: теперь багаж доставляют вручную на обычных грузовых тележках. Фирма BAE Automated Systems, разрабатывавшая багажный конвейер, была ликвидирована, а компания United Airlines, ее главный заказчик, оказалась на грани банкротства. 1/31/2018 21

Примеры неудачных проектов • В 1997 году Налоговое управление США без толку потратило $4 млрд. на новый компьютерный проект, а потом еще $8 млрд. на его модернизацию. • В 2005 году неудачу потерпело ФБР, потерявшее $170 млн. на разработке виртуальной системы управления делами, которая оказалась неработоспособной. • Несмотря на огромные затраты, Федеральное управление гражданской авиации США до сих пор не может справиться с обновлением морально устаревшей системы управления воздушным движением. 1/31/2018 22

Тяжеловесные и облегченные процессы Традиционно для упорядочения и ускорения программных разработок предлагались строго упорядочивающие тяжеловесные процессы. В этих процессах прогнозируется весь объем предстоящих работ, поэтому они называются прогнозирующими процессами. Порядок, который должен выполнять при этом, чрезвычайно строг — «шаг вправо, шаг влево — виртуальный расстрел!» . 1/31/2018 23

Тяжеловесные и облегченные процессы В последние годы появилась группа новых, облегченных процессов. Теперь их называют подвижными процессами. Они привлекательны отсутствием бюрократизма, характерного для тяжеловесных (прогнозирующих) процессов. Новые процессы должны воплотить в жизнь разумный компромисс между слишком строгой дисциплиной и полным ее отсутствием. 1/31/2018 24

Тяжеловесные и облегченные процессы У каждого семейства есть свои достоинства, недостатки и область применения: • адаптивный процесс используют при частых изменениях требований, малочисленной группе высококвалифицированных разработчиков и грамотном заказчике, который согласен участвовать в разработке; • прогнозирующий процесс применяют при фиксированных требованиях и многочисленной группе разработчиков разной квалификации. 1/31/2018 25

Экстремальное программирование (ХРпроцесс) • Экстремальное программирование (ХР)– вид облегченного (подвижного) процесса (1999 г. ) • ХР-процесс должен быть высокодинамичным процессом. ХР-группа имеет дело с изменениями требований на всем протяжении итерационного цикла разработки, причем цикл состоит из очень коротких итераций. Четырьмя базовыми действиями в ХР-цикле являются: кодирование, тестирование, выслушивание заказчика и проектирование. 1/31/2018 26

Экстремальное программирование (ХРпроцесс) • Динамизм обеспечивается с помощью четырех характеристик: непрерывной связи с заказчиком (и в пределах группы), простоты (всегда выбирается минимальное решение), быстрой обратной связи (с помощью модульного и функционального тестирования), смелости в проведении профилактики возможных проблем. • Большинство принципов, поддерживаемых в ХР, продиктованы здравым смыслом и применяются в любом упорядоченном процессе. Просто в ХР эти принципы достигают «экстремальных значений» . 1/31/2018 27

Экстремальное программирование (ХРпроцесс), примеры экстремальных значений • Принцип постоянной проверки кода реализуется с помощью парного программирования - весь код пишется двумя программистами, работающими на одном компьютере. • Частая смена версий — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле. • Коллективное владение кодом — любой разработчик может улучшать любой код системы в любое время. 1/31/2018 28

Требования к «хорошим» программам «Хорошая программа» должна делать то, что ожидает от нее заказчик – т. е. удовлетворять требованиям заказчика. Такие требования называют функциональными. Но кроме функциональных требований, существует еще ряд общих характеристик, которым в той или иной степени должна обладать каждая программа. 1/31/2018 29

Требования к «хорошим» программам 1) Сопровождаемость означает, что программа должна быть написана с расчетом на дальнейшее развитие. Это критическое свойство системы, т. к. изменения ПО неизбежны вследствие изменения бизнеса. Сопровождение программы выполняют, как правило, не те люди, которые ее разрабатывали. Сопровождаемость включает такие элементы как наличие и понятность проектной документации, соответствие проектной документации исходному коду, понятность исходного кода, простота изменений исходного кода, простота добавления новых функций. 1/31/2018 30

Требования к «хорошим» программам • 2) Надежность ПО включает такие элементы как: – Отказоустойчивость – возможность восстановления программы и данных в случае сбоев в работе. – Безопасность – сбои в работе программы не должны приводить к опасным последствиям (авариям). – Защищенность от случайных или преднамеренных внешних воздействий (защита от дурака, вирусов, спама). 1/31/2018 31

Требования к «хорошим» программам • 3) Эффективность. ПО не должно впустую тратить системные ресурсы, такие как память, процессорное время, каналы связи. Поэтому эффективность ПО оценивается следующими показателями: время выполнения кода, загруженность процессора, объем требуемой памяти, время отклика и т. п. • 4) Удобство использования. ПО должно быть легким в использовании, причем именно тем типом пользователей, на которых рассчитано приложение. Это включает в себя интерфейс пользователя и адекватную документацию. 1/31/2018 32

Профессиональные обязательства программистов • Конфиденциальность – программные специалисты должны уважать конфиденциальность в отношении своих работодателей или заказчиков независимо от того, подписывалось ли ими соответствующее соглашение. • Компетентность – программный специалист не должен завышать свой истинный уровень компетентности и не должен сознательно браться за работу, которая этому уровню не соответствует. 1/31/2018 33

Профессиональные обязательства программистов • Защита интеллектуальной собственности – специалист должен соблюдать законодательство и принципы защиты интеллектуальной собственности при использовании чужой интеллектуальной собственности. Кроме того, он должен защищать интеллектуальную собственность работодателя и клиента. Внимание: создаваемая им интеллектуальная собственность является собственностью работодателя или клиента. • Злоупотребление компьютером – программный специалист не должны злоупотреблять компьютерными ресурсами работодателя или заказчика; под злоупотреблениями мы здесь понимаем широкий спектр — от игр в компьютерные игрушки на рабочем месте до распространения вирусов. 1/31/2018 34

Стандартизация и стандарты По происхождению программные продукты бывают двух типов: заказные (под заказ конкретного потребителя) и коробочные (для массовой продажи на рынке). Для заключения контракта заказчик должен быть уверен, что разработчик справится и не завалит проект. Вопрос: как его в этом убедить? В мировой практике промышленного производства ответы на эти вопросы дают стандарты на производство продуктов и услуг и сертификация производителей на соответствие этим стандартам. 1/31/2018 35

Профессиональный стандарт • SWEBOK (Стандарт ISO/IEC TR 19759 IEEE, 15. 09. 2005) – дает представление о знаниях программного инженера, имеющего степень бакалавра и четырехлетний опыт работы 1/31/2018 36

SWEBOK (Soft. Ware Engineering Body Of Knowledge) • • • Содержит описания состава знаний по следующим 10 разделам (областям знаний) программной инженерии: Software Requirements – требования к ПО Software Design – проектирование ПО Software Construction – конструирование ПО Software Testing – тестирование ПО Software Maintenance – сопровождение ПО 1/31/2018 37

SWEBOK (Soft. Ware 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/ 1/31/2018 38

Определение требований к программной системе Существуют функциональные и нефункциональные требования. Функциональные требования регламентируют функционирование или поведение системы, они должны отвечать на вопрос: «что должна делать система» , абстрагируясь от вопроса «как она 1/31/2018 39

Общая модель формирования и анализа требований 1/31/2018 40

UML (Unified Modeling Language) UML (унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. 1/31/2018 41

Описание требований к программной системе – диаграмма вариантов использования Варианты использования – это методика формирования требований, основанная на сценариях. Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. В самой простой форме в вариантах использования определены действующие лица – актеры и возможные взаимодействия – прецеденты. 1/31/2018 42

Диаграмма вариантов использования • Диаграммы вариантов использования описывают взаимоотношения и зависимости между группами вариантов использования (прецедентами) и действующих лиц (актерами), участвующими в процессе. 1/31/2018 43

Диаграмма вариантов использования. Условные обозначения 1/31/2018 44

Диаграмма вариантов использования. Пример 1/31/2018 45

Правила построения диаграммы При работе с вариантами использования важно помнить несколько простых правил: • каждый вариант использования относится как минимум к одному действующему лицу; • каждый вариант использования имеет инициатора; • каждый вариант использования приводит к соответствующему результату. 1/31/2018 46

Связи между прецедентами в диаграмме вариантов использования Варианты использования также могут взаимодействовать с другими вариантами использования. Три наиболее часто встречающихся типа взаимодействия между вариантами использования приведены ниже: <<включение>> указывает, что вариант использования встраивается в другой вариант использования; 1/31/2018 47

Связи между прецедентами в диаграмме вариантов использования - <<добавление>> (<<расширение>>) указывает, что в определённых ситуациях или в некоторой точке (называемой точкой расширения) вариант использования будет расширен другим; - <<обобщение>> (<<наследование>>) указывает, что вариант использования наследует характеристики «родительского» варианта использования и может переопределить некоторые из них или добавить новые, подобно наследованию в классах. 1/31/2018 48

Связи между прецедентами в диаграмме вариантов использования 1/31/2018 49

Связи между прецедентами в диаграмме вариантов использования Следует подчеркнуть, что потомок наследует все свойства поведения своего родителя, а также может обладать дополнительными особенностями поведения. 1/31/2018 50

Связи между актером и прецедентом Отношение <<ассоциации>> – одно из фундаментальных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм. Применительно к диаграммам вариантов использования <<ассоциация>> служит для обозначения специфической роли актера при его взаимодействии с отдельным вариантом использования. Другими словами, <<ассоциация>> специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы. Других связей между актером и прецедентом быть не может! 1/31/2018 51

Связи между актером и прецедентом 1/31/2018 52

Связи между актерами – расширение или наследование 1/31/2018 53

Описание требований к системе дистанционного обучения • Актеры: студент, преподаватель, администратор системы, база данных • Прецеденты: – студент: аутентификация, просмотр лекций, выполнение заданий, тестирование; – преподаватель: аутентификация, внесение новой информации, составление тестов, просмотр результатов тестирования студентов; 1/31/2018 54

Описание требований к системе дистанционного обучения – администратор: поддержка системы. 1/31/2018 55

Диаграмма вариантов использования обучающей системы 1/31/2018 56

Microsoft Visio Пакет Microsoft Visio предназначен для визуального общения с помощью чертежей и диаграмм. Программа Visio дает возможность быстро и эффективно создавать при помощи встроенных шаблонов, трафаретов и стандартных модулей как простейшие слайды и схемы, так и очень сложные чертежи и диаграммы. 1/31/2018 57

Для создания диаграммы необходимо выбрать шаблон. Основные типы шаблонов: - бизнес; блок-схемы; карты и планы этажей; общие; программное обеспечение и базы данных; расписание; сеть; техника. 1/31/2018 58

Microsoft Visio. Основные понятия Связанные друг с другом фигуры включены в трафареты. Например, если создать «Простую блок-схему» из шаблона «Блок-схема» , то можно увидеть, что стандартно в таком документе будет четыре трафарета: стрелки, фоновые рисунки, фигуры простой блок-схемы, рамки и заголовки. 1/31/2018 59

Microsoft Visio. Пример 1/31/2018 60

Работа с фигурами Для добавления фигуры в документ, её надо «перетащить» из раздела трафарета в рабочую область документа. Для изменения размеров, положения фигуры на рабочей области предназначены маркеры-манипуляторы, которые появляются в случае активации фигуры. Для добавления к фигуре текста достаточно её выделить и вводить текст. 1/31/2018 61

Соединения фигур Для соединения нескольких фигур используют соединительные линии, которые при перемещаются вместе с фигурами, к которым они привязаны. 1/31/2018 62

Создание UML-диаграммы Для создания UML диаграммы выбирают шаблон «Программное обеспечение и базы данных» - «Схемы модели UML» . Данный шаблон содержит трафареты для создания множества UML диаграмм: сценарии выполнения (диаграмма вариантов использования), деятельности, классов, компонентов, состояний. 1/31/2018 63

Создание собственных фигур для диаграмм и схем Microsoft Visio С помощью панели инструментов Рисование (Drawing) можно создавать собственные фигуры С помощью пункта меню Фигура можно производить различные операции над нарисованными фигурами (объединение, пересечение и др. ) 1/31/2018 64

Сохранение созданной фигуры в трафарете Для сохранения созданной фигуры достаточно «перетащить» её с рабочей области на трафарет. Однако, стандартные трафареты Visio открыты только для чтения, добавлять фигуры можно в новый трафарет ([Файл]-> [Фигуры]-> [Создать новый набор]). 1/31/2018 65

Управление программным проектом Управление - изменение состояния объекта, системы или процесса, ведущее к достижению поставленной цели. Слово «проект» имеет достаточно много значений. Происходит от латинского projectus, что означает «брошенный вперед» . Проект – это произвольный ряд действий или задач, имеющий определенную цель, которая будет достигнута в рамках выполнения некоторых заданий, характеризующихся определенными датами начала и окончания, пределами финансирования и ресурсами 1/31/2018 66

Характеристики проекта Цель проекта. Наличие четко выраженного конечного результата, выхода, продукции, определяемых в терминах затрат, качества и времени реализации. • Уникальность. Проект - это разовое начинание, которое не будет повторяться. Даже “повторяющиеся” проекты, например, по строительству еще одного предприятия по той же проектной документации, значительно отличаются друг от друга использующимися ресурсами и средой реализации. • 1/31/2018 67

Характеристики проекта • Ограниченность во времени. Проект имеет начало и конец. Для его реализация необходима временная концентрация ресурсов. По минованию надобности, ресурсы используются на другие цели. • Ограниченность ресурсов, выделяемых на выполнение проекта (финансовых, людских, материальных). • Сложность. Для достижения целей проекта необходимо решить множество задач. Отношения между задачами могут быть довольно сложными, особенно, если в проекте много задач. 1/31/2018 68

Характеристики проекта • Неопределенность. Возможность достижения цели в указанные сроки с выделенными ресурсами заранее не гарантирована. • Предсказуемость. По мере реализации проекта, изменяется потребность в тех или иных ресурсах. Это изменение идет в определенной предсказуемой последовательности, определяемой жизненным циклом проекта. 1/31/2018 69

Управление проектами - набор проверенных принципов, методов и методик, применяемых для эффективного планирования, составления графика, управления и отслеживания результатов работы. 1/31/2018 70

Основные принципы • Основные принципы: – Умение – знание принципов и методов управления проектом (планирования, организация, составление графиков, контроль, управление и отслеживание). – Навыки – опыт в области управления – применение умения для достижения целей в конкретных условиях. 1/31/2018 71

Категории управления проектами • Выделяют следующие группы категорий – Цели, определяемые ожидаемыми результатами проекта. – Критерии успеха и ограничения: стоимость, сроки, качество. – Основные рычаги управления: ресурсы (являющиеся также ограничением) и технологии. 1/31/2018 72

Категории управления проектами (продолжение) – Вспомогательные рычаги управления: контракты, организация, взаимодействие, персонал. – Неопределенность, связанная с рисками выполнения проекта. 1/31/2018 73

ги Вр нь 1/31/2018 Де • Закон Лермана: "Любую техническую проблему можно преодолеть, имея достаточно времени и денег» • Следствие Лермана: «Вам никогда не будет хватать либо времени, либо денег» ем я Треугольник ограничений проекта Качество 74

Непроект - это • Программа – широкомасштабное усилие, направленное на достижение некоторой комплексной цели – цель конкретна, сроки и ресурсы не определены • Выполнение установившегося процесса – деятельность, которая выполняется многократно и постоянно – имеет конкретную цель, выделенные ресурсы – не является уникальной, сложной и не связана с конкретными сроками • Решение творческой задачи – есть цель, уникальность и сложность – нет ограничений по времени и ресурсам – слишком велика степень неопределенности 1/31/2018 75

SQI: 34 компетенции IT менеджера • Главное действующее лицо проекта – менеджер. • Институтом качества ПО (SQI - Software Quality Institute) разработан руководящей документ (Body of Knowledge) для сертификации менеджеров программных проектов (SWPM – Soft. Ware Project Management). В этом документе содержится список 34 компетенций, которыми должен обладать менеджер программного проекта. 1/31/2018 76

Компетенции IT менеджера • Три основные категории: – Методика разработки продукта – Навыки управления проектами – Навыки управления персоналом 1/31/2018 77

Методика разработки продукта • • • Процессы оценивания - определение критериев для отбора Знание стандартов процесса Определение продукта - идентификация клиентской среды и требований, выдвигаемых к продукту Оценка альтернативных процессов Управление требованиями- мониторинг изменения требований 1/31/2018 78

Методика разработки продукта • • Управление субподрядчиками - планирование, управление и осуществление контроля Выполнение начальной оценки - оценка степени трудности, рисков, затрат и создание графиков Отбор методов и инструментов - определение процессов отбора Подгонка процессов - модификация стандартных процессов с целью удовлетворения требований проектов 1/31/2018 79

Методика разработки продукта • Отслеживание качества продукта - контроль качества в процессе разработки продукта • Понимание действий по разработке продукта - изучение цикла разработки ПО 1/31/2018 80

Навыки управления проектами • • • Создание структуры пооперационного перечня работ Документирование планов - идентификация ключевых компонент Оценка стоимости - стоимости завершения проекта Оценка трудозатрат - необходимых для завершения проекта Менеджмент рисков - идентификация, определение воздействия, обработка рисков 1/31/2018 81

Навыки управления проектами • • Отслеживание процесса разработки - контроль процесса разработки Составление графика - разработка графика и ключевых стадий проекта Выбор метрических показателей Отбор инструментов менеджмента проекта - выбор методик и инструментов 1/31/2018 82

Навыки управления проектами • • Отслеживание процессов - мониторинг совместимости членов команды Отслеживание хода разработки продукта - мониторинг хода разработки по выбранным метрическим показателям 1/31/2018 83

Навыки управления персоналом • • Оценка производительности - оценка действий команды, направленных на повышение ее производительности Вопросы интеллектуальной собственности - понимание степени влияния критических проблем Организация эффективных встреч - планирование и проведение Взаимодействие и общение - с разработчиками, руководством и другими командами 1/31/2018 84

Навыки управления персоналом • • Лидерство - обучение проектных команд для получения оптимальных результатов Управление изменениями - обеспечение эффективного управления изменениями Успешное ведение переговоров - разрешение конфликтов и ведение переговоров Планирование карьерного роста - структурирование и управление ходом реализации карьеры 1/31/2018 85

Навыки управления персоналом • • Эффективное представление - использование письменных и устных навыков Набор персонала - вербовка и собеседование с членами команды Отбор команды - выбор высококомпетентных специалистов Создание команды - формирование, руководство и поддержка эффективной команды 1/31/2018 86

Управление командой проекта Управление программным проектом включает решение трех основных задач. • Подбор и управление командой • Выбор процесса • Выбор инструментальных средств Эффективное решение первой из задач предопределяет успех всего проекта. 1/31/2018 87

Основные вопросы при управлении командой • Ролевая модель команды • Модели организации команд • Общение в команде 1/31/2018 88

Ролевая модель команды • Состав команды определяется опытом и уровнем коллектива, особенностями проекта, применяемыми технологиями и уровнем этих технологий. Один из вариантов состава команды приведен на следующем слайде. 1/31/2018 89

Ролевая модель команды • • Менеджер проекта Проектировщик Разработчик Тестировщик Инженер по качеству Технический писатель Технолог разработки ПО 1/31/2018 90

Менеджер проекта • Менеджер проекта - главное действующее лицо, обладающее знаниями и навыками, необходимыми для успешного управления проектом. Его основные функции: • Подбор и управление кадрами • Подготовка и исполнение плана проекта • Руководство командой • Обеспечение связи между подразделениями • Обеспечение готовности продукта 1/31/2018 91

Проектировщик • Проектировщик - это функция проектирования архитектуры высокого уровня и контроля ее выполнения. В небольших командах функция распределяется между менеджером и разработчиками. В больших проектах это может быть целый отдел. 1/31/2018 92

Проектировщик. Основные функции • Анализ требований • Разработка архитектуры и основных интерфейсов • Участие в планировании проекта • Контроль выполнения проекта • Участие в подборе кадров 1/31/2018 93

Разработчик • Разработчик – роль, ответственная за непосредственное создание конечного продукта. Помимо собственно программирования (кодирования) в его функции входит: • Контроль архитектурных и технических спецификаций продукта • Подбор технологических инструментов и стандартов 1/31/2018 94

Разработчик • Диагностика и разрешение всех технических проблем • Контроль за работой разработчиков документации, тестирования, технологов • Мониторинг состояния продукта (ведение списка обнаруженных ошибок) • Подбор инструментов разработки, метрик и стандартов. Контроль их использования. 1/31/2018 95

Тестировщик • Тестировщик – роль, ответственная за удовлетворение требований к продукту (функциональных и нефункциональных). В функции тестировщика входит: • Составление плана тестирования. План тестирования составляет один из элементов проекта и составляется до начала реализации (разработки) проекта. Время, отводимое в плане на тестирование может быть сопоставимо с временем разработки. 1/31/2018 96

Тестировщик • Контроль выполнения плана. Важнейшая функция контроля – поддержка целостности базы данных зарегистрированных ошибок. В этой базе регистрируется: – кто, когда и где обнаружил, описание ошибки, описание состояния среды; – статус ошибки: приоритет, кто разрешает – состояние ошибки: висит, в разработке, разрешена, проблемы Эта база должна быть доступна всем, т. к. в тестировании принимают участие все члены команды. 1/31/2018 97

Тестировщик • Разработка тестов. Самая трудоемкая часть в работе тестировщика. Тестирование должно обеспечить полную проверку функциональности при всех режимах работы продукта. • Автоматизация тестирования включает автоматизацию составления тестов, автоматизацию пропуска тестов и автоматизацию обработки результатов тестирования. В виду важности автоматизации тестирования, иногда вводят нового участника – инженера по автоматизации. 1/31/2018 98

Тестировщик • Выбор инструментов, метрик, стандартов для организации процесса тестирования. • Организация Бета тестирования - тестирования почти готового продукта внешними тестерами (пользователями). Эту важную процедуру надо продумать и организовать в случае разработки коробочного продукта. 1/31/2018 99

Инженер по качеству Функции, отличные от функций тестировщика: • Составление плана качества. План качества включает все мероприятия по повышению качества (на всех уровнях). Имеет долговременный характер. План тестирования – его оперативная составляющая. • Описание процессов является их формализацией. При описании вводятся метрики процесса, влияющие на качество продукта. 1/31/2018 100

Инженер по качеству • Оценка процессов включает регистрацию хода выполнения процессов и оценку значений установленных метрик процессов. Выявление «слабых» мест и выработка рекомендаций по улучшению процессов. 1/31/2018 101

Технический писатель • Технический писатель - разработчик пользовательской (и иной) документации как части программного продукта. Функциями технического писателя являются: • Разработка плана документирования, который включает состав, сроки подготовки и порядок тестирования документов. • Выбор и разработка стандартов и шаблонов подготовки документов. 1/31/2018 102

Технический писатель • Выбор средств автоматизации документирования • Разработка документации • Организация тестирования документации • Участие в тестировании продукта. Технический писатель все время работает с продуктом (его готовыми версиями) и выступая от имени пользователя видит все недочеты и несоответствия. 1/31/2018 103