Реферат Вдипломной работе 88 листов, 13 рисунков, 10 таблиц, 38

Реферат

В дипломной работе 88 листов, 13 рисунков, 10 таблиц, 38 источников, 2 приложения.

УПРАВЛЕНИЕ ПРОЕКТАМИ, МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТОМ, SAAS, PMBOK, КАСКАДНАЯ МОДЕЛЬ, ИТЕРАТИВНАЯ МОДЕЛЬ, SCRUM, WIKI, IT-ПРОЕКТЫ, REDMINE, WIKI, ОЦЕНКИ, ФОКУС-ФАКТОР, ПЛАНИРОВАНИЕ, РИСК-МЕНЕДЖМЕНТ, ОБУЧЕНИЕ, РУКОВОДИТЕЛЬ ПРОЕКТА.

Работа посвящена описанию разработке SaaS-системы для успешного выполнения проектов и обучения руководителей проектов. Даны ключевые понятия проектного управления, рассмотрены основные проблемы возникающие при выполнении проектов. Основное внимание в работе уделяется выполнению IT-проектов.

В результате работы была разработана система позволяющая решить основные проблемы, возникающие в следствие плохого проектного управления.

Содержание

TOC \o «1-4» \h \z \u HYPERLINK \l «_Toc346015928» Введение PAGEREF _Toc346015928 \h 6

HYPERLINK \l «_Toc346015929» 1Основная часть PAGEREF _Toc346015929 \h 7

HYPERLINK \l «_Toc346015930» 1.1Теоретическая часть PAGEREF _Toc346015930 \h 7

HYPERLINK \l «_Toc346015931» 1.1.1Управление проектами PAGEREF _Toc346015931 \h 7

HYPERLINK \l «_Toc346015932» 1.1.2Стандарты проектного управления PAGEREF _Toc346015932 \h 9

HYPERLINK \l «_Toc346015933» 1.1.2.1PMBoK PAGEREF _Toc346015933 \h 9

HYPERLINK \l «_Toc346015934» 1.1.2.2P2M PAGEREF _Toc346015934 \h 10

HYPERLINK \l «_Toc346015935» 1.1.2.3ISO 21500 PAGEREF _Toc346015935 \h 11

HYPERLINK \l «_Toc346015936» 1.1.3Специфика IT-проектов PAGEREF _Toc346015936 \h 12

HYPERLINK \l «_Toc346015937» 1.1.3.1Методологии управления IT-проектами PAGEREF _Toc346015937 \h 12

HYPERLINK \l «_Toc346015938» 1.1.3.2Каскадная модель (Waterfall) PAGEREF _Toc346015938 \h 12

HYPERLINK \l «_Toc346015939» 1.1.3.3Спиральная модель PAGEREF _Toc346015939 \h 14

HYPERLINK \l «_Toc346015940» 1.1.3.4Итеративная разработка PAGEREF _Toc346015940 \h 17

HYPERLINK \l «_Toc346015941» 1.1.3.5Гибкая методология разработки PAGEREF _Toc346015941 \h 18

HYPERLINK \l «_Toc346015942» 1.1.4SaaS-приложения PAGEREF _Toc346015942 \h 23

HYPERLINK \l «_Toc346015943» 1.1.4.1Основные понятия электронно-вычислительных сетей PAGEREF _Toc346015943 \h 23

HYPERLINK \l «_Toc346015944» 1.1.4.2Топология локальных сетей PAGEREF _Toc346015944 \h 25

HYPERLINK \l «_Toc346015945» 1.1.4.3Типы локальных сетей PAGEREF _Toc346015945 \h 30

HYPERLINK \l «_Toc346015946» 1.1.4.4Компьютерная сеть Интернет PAGEREF _Toc346015946 \h 31

HYPERLINK \l «_Toc346015947» 1.1.4.5Основные системы и понятия сети Интернет PAGEREF _Toc346015947 \h 33

HYPERLINK \l «_Toc346015948» 1.1.4.6Уровни сетевой модели OSI PAGEREF _Toc346015948 \h 36

HYPERLINK \l «_Toc346015949» 1.1.4.7SaaS — Software as a service PAGEREF _Toc346015949 \h 40

HYPERLINK \l «_Toc346015950» 1.1.5SaaS-приложения для управления проектами PAGEREF _Toc346015950 \h 41

HYPERLINK \l «_Toc346015951» 1.1.5.1Мегаплан PAGEREF _Toc346015951 \h 41

HYPERLINK \l «_Toc346015952» 1.1.5.2Битрикс24 PAGEREF _Toc346015952 \h 42

HYPERLINK \l «_Toc346015953» 1.1.5.3Basecamp PAGEREF _Toc346015953 \h 43

HYPERLINK \l «_Toc346015954» 1.2Вычислительная часть PAGEREF _Toc346015954 \h 43

HYPERLINK \l «_Toc346015955» 1.2.1Постановка проблемы PAGEREF _Toc346015955 \h 43

HYPERLINK \l «_Toc346015956» 1.2.2Способ решения PAGEREF _Toc346015956 \h 44

HYPERLINK \l «_Toc346015957» 1.2.3Электронный проектный офис как система поддержки принятия решений PAGEREF _Toc346015957 \h 46

HYPERLINK \l «_Toc346015958» 1.2.4Применимость и целевая аудитория PAGEREF _Toc346015958 \h 46

HYPERLINK \l «_Toc346015959» 1.2.4.1Учебные проекты PAGEREF _Toc346015959 \h 46

HYPERLINK \l «_Toc346015960» 1.2.4.2Ориентация на распределенные команды PAGEREF _Toc346015960 \h 47

HYPERLINK \l «_Toc346015961» 1.2.4.3Ориентация на малый бизнес и небольшие команды PAGEREF _Toc346015961 \h 47

HYPERLINK \l «_Toc346015962» 1.2.5Основные функции сервиса PAGEREF _Toc346015962 \h 47

HYPERLINK \l «_Toc346015963» 1.2.6Методология PAGEREF _Toc346015963 \h 49

HYPERLINK \l «_Toc346015964» 1.2.7UseCases PAGEREF _Toc346015964 \h 51

HYPERLINK \l «_Toc346015965» 1.2.7.1Построение Burndown диаграммы PAGEREF _Toc346015965 \h 51

HYPERLINK \l «_Toc346015966» 1.2.7.2Советы и упражнения PAGEREF _Toc346015966 \h 52

HYPERLINK \l «_Toc346015967» 1.2.7.3Массовое добавление задач PAGEREF _Toc346015967 \h 52

HYPERLINK \l «_Toc346015968» 1.2.7.4Ежедневный сбор статистики от участников PAGEREF _Toc346015968 \h 53

HYPERLINK \l «_Toc346015969» 1.2.8Диаграмма базы данных PAGEREF _Toc346015969 \h 54

HYPERLINK \l «_Toc346015970» 1.2.9Макеты пользовательских интерфейсов PAGEREF _Toc346015970 \h 56

HYPERLINK \l «_Toc346015971» 1.2.10Математическая модель PAGEREF _Toc346015971 \h 56

HYPERLINK \l «_Toc346015972» 2Экономическая часть PAGEREF _Toc346015972 \h 59

HYPERLINK \l «_Toc346015973» 2.1Общие положения PAGEREF _Toc346015973 \h 59

HYPERLINK \l «_Toc346015974» 2.2Определение затрат на создание продукта PAGEREF _Toc346015974 \h 59

HYPERLINK \l «_Toc346015975» 2.2.1Материальные затраты PAGEREF _Toc346015975 \h 59

HYPERLINK \l «_Toc346015976» 2.2.2Расходы на оплату труда PAGEREF _Toc346015976 \h 61

HYPERLINK \l «_Toc346015977» 2.2.3Отчисления на социальные нужды PAGEREF _Toc346015977 \h 63

HYPERLINK \l «_Toc346015978» 2.2.4Амортизационные отчисления. PAGEREF _Toc346015978 \h 64

HYPERLINK \l «_Toc346015979» 2.2.5Прочие расходы PAGEREF _Toc346015979 \h 65

HYPERLINK \l «_Toc346015980» 2.3Затраты на создание продукта. PAGEREF _Toc346015980 \h 67

HYPERLINK \l «_Toc346015981» 2.3.1Цена разработанного продукта. PAGEREF _Toc346015981 \h 67

HYPERLINK \l «_Toc346015982» 2.3.2Оценка экономической эффективности использования продукта. PAGEREF _Toc346015982 \h 68

HYPERLINK \l «_Toc346015983» 3Охрана труда и окружающей среды PAGEREF _Toc346015983 \h 71

HYPERLINK \l «_Toc346015984» 3.1Введение PAGEREF _Toc346015984 \h 71

HYPERLINK \l «_Toc346015985» 3.2Факторы, воздействующие на оператора ПК PAGEREF _Toc346015985 \h 72

HYPERLINK \l «_Toc346015986» 3.3Освещение PAGEREF _Toc346015986 \h 72

HYPERLINK \l «_Toc346015987» 3.4Требование к монитору PAGEREF _Toc346015987 \h 74

HYPERLINK \l «_Toc346015988» 3.4.1Визуальная эргономика PAGEREF _Toc346015988 \h 74

HYPERLINK \l «_Toc346015989» 3.4.2Геометрические характеристики изображения PAGEREF _Toc346015989 \h 75

HYPERLINK \l «_Toc346015990» 3.4.3Яркость изображения PAGEREF _Toc346015990 \h 76

HYPERLINK \l «_Toc346015991» 3.4.4Контрастность изображения PAGEREF _Toc346015991 \h 77

HYPERLINK \l «_Toc346015992» 3.4.5Цветопередача PAGEREF _Toc346015992 \h 78

HYPERLINK \l «_Toc346015993» 3.5Эргономика рабочего места PAGEREF _Toc346015993 \h 79

HYPERLINK \l «_Toc346015994» 3.6Заключение PAGEREF _Toc346015994 \h 81

HYPERLINK \l «_Toc346015995» 4Заключение и выводы PAGEREF _Toc346015995 \h 82

HYPERLINK \l «_Toc346015996» 5Список литературы PAGEREF _Toc346015996 \h 83

HYPERLINK \l «_Toc346015997» 6Приложения PAGEREF _Toc346015997 \h 86

HYPERLINK \l «_Toc346015998» 6.1Приложение А PAGEREF _Toc346015998 \h 87

HYPERLINK \l «_Toc346015999» 6.2Приложение Б PAGEREF _Toc346015999 \h 88

Введение

Управление проектами — одна из самых ответственных областей человеческих знаний. Без нее немыслимо представить ни одного маломальского дело. Запуск человека в космос, создание новой модели самолета или разработка новой операционной системы — это все примеры масштабных проектов. Выпускники вузов редко сталкиваются с такими проектами в начале своего трудового пути. Специалисты чаще работают с мелкими и средними проектами, чем с крупными. Таких проектов гораздо больше чем крупных. К сожалению, часто проектами управляют недостаточно квалифицированные менеджеры, а иногда и специалисты, из-за недостатка проектного опыта и внимания к проекту, часто могут возникать различные проблемы.

В данной работе будет рассмотрены теоретические основы проектного менеджмента, основные проблемы, возникающие в процессе работы над проектами. Будет предложена программное обеспечение, позволяющую если не решить, то как минимум снизить негативное влияние основных проблем проектного управления. Так же будут предложены методология управления проектами, схема базы данных, макеты интерфейса программного обеспечения, реализующую данную методологию.

Основная часть

Теоретическая часть

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

Существует несколько толкований термина «Управление проектами».

Управление проектами (англ. project management) — в соответствии с определением международного стандарта ISO 21500, принятого правительствами США, странами Евросоюза и правительством России в сентябре 2012 года — применение методов, инструментов, техник и компетенцией к проекту. Само понятие «проект» в ISO 21500 определяется как уникальный набор процессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для достижения цели. Достижение цели проекта требует получения результатов, соответствующих определенным заранее требованиям, в том числе ограничения на получения результатов, таких как время, деньги и ресурсы.

Управление проектами — в соответствии с определением национальным стандартом ANSI PMBoK — область деятельности, в ходе которой определяются и достигаются четкие цели проекта при балансировании между объемом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками. Ключевым фактором успеха проектного управления является наличие четкого заранее определенного плана, минимизации рисков и отклонений от плана, эффективного управления изменениями (в отличие от процессного, функционального управления, управления уровнем услуг).

Управление проектами — в соответствии с P2М — сочетание науки и искусства, которые используются в профессиональных сферах проекта, чтобы создать продукт проекта, который бы удовлетворил миссию проекта, путем организации надежной команды проекта, эффективно сочетающей технические и управленческие методы, создает наибольшую ценность и демонстрирует эффективные результаты работы.[1]

Продуктами проекта могут быть продукция предприятия (результаты научных и маркетинговых исследований, проектно-конструкторская и технологическая документация на новое изделие, разработанные для заказчика) и решение разных внутренних производственных задач (повышение качества продукции и эффективности организации труда, оптимизация финансовых потоков и т. д.).

Управление проектами является частью системы менеджмента предприятия.

Краеугольным камнем проектного управления является цикл Деминга-Шухарда, приведенный на рисунке ниже. Цикл Деминга-Шухарда представляет собой циклически повторяющийся процесс принятия решений, используемый в управлении качеством. Цикл начинается с планирования:

Методология PDCA представляет собой простейший алгоритм действий руководителя по управлению процессом и достижению его целей. Цикл управления начинается с планирования:

Планирование — установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворения потребителя, планирование выделения и распределения необходимых ресурсов.

Выполнение — выполнение запланированных работ.

Проверка — сбор информации и контроль результата на основе ключевых показателей эффективности (KPI), получившегося в ходе выполнения процесса, выявление и анализ отклонений, установление причин отклонений.

Воздействие (управление, корректировка) — принятие мер по устранению причин отклонений от запланированного результата, изменения в планировании и распределении ресурсов.

Рисунок SEQ Рисунок \* ARABIC 1. Цикл Деминга-Шухарта

Стандарты проектного управления

PMBoK

Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge) представляет собой сумму профессиональных знаний по управлению проектами. Руководство PMBOK фиксирует части Свода знаний по управлению проектами, которая обычно считается хорошей практикой. PMI использует этот документ в качестве основного справочного материала для своих программ по профессиональному развитию. Является Американским национальным стандартом.

В настоящем стандарте описываются суть процессов управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат. Эти процессы разделены на пять групп, называемых «группы процессов управления проектом».

PMBOK 4й редакции стал революционным изменением методик PMI. Впервые была раскрыта методика ведения аналитических работ, прототипирование, итеративность и даже применение систем искусственного интеллекта для прогноза завершения проекта по срокам и бюджету.

P2M

P2M — «A Guidebook of Project and Program Management for Enterprise Innovation» — стандарт по управлению проектами, базирующийся на опыте Японии с 1999 года, который позволил визуализировать проекты с большей добавленной стоимостью и инновационные программы.

P2M — это система знаний, представленная в форме «Руководства по управлению инновационными проектами и программами предприятий».

Первая редакция P2M была опубликована в ноябре 2001 года Японской ассоциацией развития инжиниринга (ENAA), сейчас P2M поддерживается Ассоциацией проектных менеджеров Японии (PMAJ).

P2M сконцентрировал уроки японских компаний с 1980 года, сформировав методологию управления ценностью и выздоровления компаний за последнее десятилетие с 1990 года, как новое направление развития.

Главное преимущество Р2М по отношению к другим школам по управлению проектами состоит в том, что в Р2М существует акцент на выработку инновации как подхода к управлению программами и управление ожиданиями заинтересованных лиц. В то же время проект в Р2М — в первую очередь обязательство менеджера проекта создать ценность как продукт в соответствии с миссией программы и организации в целом.

ISO 21500

ISO 21500 — стандарт по управлению проектами на базе модели PMBOK.

В сентябре 2012 года Россия, США и страны Евросоюза на государственном уровне через International Standard Organization ISO ввели в действие стандарт ISO 21500, который был построен на базе модели PMBOK. Стандарт был принят согласно Уставу ISO Комитетом TC 236 — Проектный менеджмент, единогласным голосованием 37 стран, при отсутствии замечаний от 12 стран-наблюдателей. Управление комитетом, группой разработки и само голосование проводилось Секретариатом комитета, роль которого выполняли официальные представители ANSI.

Текст конечной и официальной редакции стандарта ISO 21500 доступен на сайте ISO.org за 100 долларов, драфт-версии стандарта до утверждения находятся в свободном доступе на сайтах участников его разработки, имеется перевод стандарта на русский язык, c комментариями отечественных экспертов. Драфт-версия стандарта ISO 21500 отличается от релиза тем, что в релизе стандарта было снято ограничение на использование ISO 21500 в качестве национальных стандартов и для проведения сертификаций организаций и персонала. Это условие существенно с точки зрения Устава ISO как аналога Устава ООН, но не для вопросов международной безопасности, а для вопросов международной стандартизации (см. юридические комментарии ниже).

По заключению профессора Станислава Гашика, соавтора 4й редакции PMBOK, стандарт ISO имеет 31 из 39 процессов управления проектами имеют прямой аналог в PMBOK, но авторам ISO 21500 их удалось изложить существенно более компактно.

Об принятии стандарта ISO 21500 был выпущен специальный пресс-релиз PMI с признанием нового основного стандарта. Билл Дункан, автор модели PMBOK, считает, что новый стандарт «достаточно полноценен»[1], что бы заменить текущий стандарт PMBOK, который является национальным стандартом США в управлении проектами (утвержден ANSI).

ISO 21500 вводит определение понятия «проект» также как в других стандартах ISO, которое отличается от PMBOK кардинально, а именно:

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

Специфика IT-проектов

Главной спецификой IT-проектов является то, что чаще всего результат проекта не имеет физического воплощения. Брукс в своей книге «Мифический человеко-месяц» утверждает, что программисты имеют дело с чистой мыслью, которой могут как угодно манипулировать. В такой среде очень сложно достигать нужного результата

Методологии управления IT-проектами

Методология разработки программного обеспечения — структура, согласно которой строится разработка программного обеспечения (ПО).

Существует несколько моделей такого процесса, каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса.

Ниже описаны основные методологии, их плюсы и минусы.

Каскадная модель (Waterfall)

Каскадная модель (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; забавно, что сам Ройс использовал итеративную модель разработки.

В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.

Рисунок SEQ Рисунок \* ARABIC 2. Каскадная модель Ройса.

В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:

Определение требований

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

Конструирование (также «реализация» либо «кодирование»)

Воплощение

Тестирование и отладка (также «верификация»)

Инсталляция

Поддержка

Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей

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

Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.

Каскадная модель позволяет добиваться успехов в случае отточенных навыков работы руководителя, команды, четкости требований и адекватности заказчика. Такое редко встречается в реальном мире, но некоторым крупным компаниям удается работать по водопадной модели.

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

Спиральная модель, предложенная Барри Боэмом в 1988 году, стала существенным прорывом в понимании природы разработки ПО. Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:

Дефицит специалистов.

Нереалистичные сроки и бюджет.

Реализация несоответствующей функциональности.

Разработка неправильного пользовательского интерфейса.

«Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.

Непрекращающийся поток изменений.

Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.

Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

Недостаточная производительность получаемой системы.

«Разрыв» в квалификации специалистов разных областей знаний.

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

Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:

оценка и разрешение рисков,

определение целей,

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

планирование.

На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

небольшую команду программистов (от 2 до 10 человек);

короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);

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

Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз:

фаза определения требований и анализа;

фаза проектирования;

фаза реализации;

фаза внедрения.

Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В условиях, когда бизнес цели таких проектов могут измениться, но требуется разработка стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости, имеет смысл применение Spiral Architecture Driven Development. Данная методология, включающая в себя лучшие идеи спиральной модели и некоторых других, позволяет существенно снизить архитектурные риски, что является немаловажным фактором успеха при разработке крупных систем.

Итеративная разработка

Итеративный подход (англ. iteration, «повторение») в разработке программного обеспечения — это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл Деминга-Шухарта.

Преимущества итеративного подхода:

снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

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

акцент усилий на наиболее важные и критичные направления проекта;

непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

более равномерная загрузка участников проекта;

эффективное использование накопленного опыта;

реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.

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

Рисунок SEQ Рисунок \* ARABIC 3. Итеративная модель разработки ПО.

Пример реализации итеративного подхода — Rational Unified Process.

Гибкая методология разработки

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки и динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности, известны как гибкие методики экстремальное программирование, DSDM, Scrum.

Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.

Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как минимум, она включает и «заказчиков» (англ. product owner — заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных.

Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto[1]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды.

Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Манифест подписали представители следующих методологий Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature-driven development, Pragmatic Programming. Agile Manifesto содержит 4 основные идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит практических советов.

Основные идеи:

Личности и их взаимодействия важнее, чем процессы и инструменты;

Работающее программное обеспечение важнее, чем полная документация;

Сотрудничество с заказчиком важнее, чем контрактные обязательства;

Реакция на изменения важнее, чем следование плану.

Принципы, которые разъясняет Agile Manifesto[2]:

удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

работающее программное обеспечение — лучший измеритель прогресса;



Страницы: Первая | 1 | 2 | 3 | ... | Вперед → | Последняя | Весь текст