Анализ факторов, способствующих повышению уровня групповой осознанности сотрудников в проектах по разработке программного обеспечения - Дипломная работа

Данная работа основывается на проблеме слабой изученности факторов, формирующих групповую осознанность в управлении проектом по разработке программного обеспечения. В качестве основной цели исследования можно отметить изучение основных параметров, влияющих на развитие групповой осознанности в проектах по разработке программного обеспечения, в частности, его влияние на непосредственную разработку программного обеспечения, а так же последующая за данным исследованием разработка рекомендаций по повышению эффективности применения концепции групповой осознанности в проектах по разработке программного обеспечения. Полученные данные будут собраны и проанализированы с целью выявления основных факторов, способствующих развитию концепции групповой осознанности в проектах по разработке программного обеспечения. Более развернутое определение информационных технологий являет собой следующее: “Широкий средств и устройств коммуникаций, которые связывают информационные системы и людей, включающую в себя: голосовую почту, электронную почту, голосовые конференции, видеоконференции, интернет, групповые и корпоративные средства связи, а так же факсы, автомобильные телефоны, персональные компьютеры, помощники и так далее”, или “это возможности, предоставленные организациям со стороны информационных систем, электронных вычислительных машин, а так же программного обеспечения, применяемого с целью обмена, хранения, анализа и корректировки информации, баз знаний с целью достижения целей организации”. Модели разработки программного обеспечения представляют собой процессы и методы разработки проекта в зависимости от целей и необходимостей проекта.Проблема недостаточной изученности факторов, формирующих групповую осознанность в управлении проектом по разработке программного обеспечения, к сожалению, не является предметом постоянного исследования, не смотря на экспоненциальное развитие информационных технологий. Постоянный рост и развитие данной отрасли во всех направлениях, и так же постоянное появление разных методологий разработки программного обеспечения говорят о том, что организация, будь она Высоконадежной, или нет, нуждается в структурированном развитии групповой осознанности. Для выполнения данной цели нами были выполнены следующие шаги: Было проведено рассмотрение и анализ моделей разработки программного обеспечения, процесса формирования групповой осознанности в Высоконадежной организации и влияние групповой осознанности на IT-проекты с точки зрения инновационного менеджмента. Была составлена модель эмпирического исследования, которая включала в себя разработку онлайн-анкеты для сотрудников IT-проектов, а так же сбор и анализ данных с целью выявления основных компонентов, влияющих на процесс формирования групповой осознанности в проектах по разработке программного обеспечения. Итак, в виду тех статистических зависимостей, что были выявлены в ходе исследования, можно предложить следующие рекомендации по повышению эффективности применения концепции групповой осознанности в проект по разработке программного обеспечения: С целью повышения эффективности разработки программного обеспечения, необходимо отдавать предпочтение легким методологиям разработки программного обеспечения (Спиральная модель, модель прототипирования, гибкая методология, модель RAD, итерационная модель), в виду того, что только внутри данных моделей есть пространство для внедрения и развития концепции групповой осознанности.

Актуальность темы.

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

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

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

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

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

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

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

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

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

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

Так же, стоит отметить работу Фичмана, который, не смотря на то, что ссылается на работу Свонсона и Рамиллера, но, в свою очередь, настаивает на проведении эмпирических исследований, которые должны способствовать выявлению основных факторов, способствующих развитию данной концепции.

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

В данной исследовательской работе оценка роли групповой осознанности в управлении IT-проектом будет рассмотрена на примере выборки специалистов, собранной с помощью анонимного онлайн-опросника. Деятельность отобранных специалистов активно связана с разработкой программного обеспечения в IT-проектах. Среди них есть: разработчики сайтов, Android-разработчики, разработчики дистанционного банковского обслуживания (далее ДБО), front-end разработчики, и другие.

Размер эмпирической выборки: 88 человек.

Цели и задачи исследования.

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

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

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

Анализ базовых процессов формирования групповой осознанности в организации.

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

Разработать программу исследования.

Сбор тестовых данных сотрудников.

Анализ данных эмпирического исследования.

Определить специфику управления IT-проектом с учетом концепции групповой осознанности.

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

Объект и предмет исследования.

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

Методология исследования.

Исследование будет проводиться в три этапа. В первой части будет проведен анализ уже собранных данных, касающихся тематики влияния групповой осознанности на качество управления IT-проектами. В качестве источников будут использованы такие электронные реферативные базы и источники, как: Web of Science, MIT Sloan Review.

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

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

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

1. Теоретическое исследование проблемы групповой осознанности в управлении проектом по разработке программного обеспечения

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

Согласно определению, информационные технологии - это отрасль, занимающаяся сбором, обработкой и хранением данных, с применением компьютерных ресурсов. Более развернутое определение информационных технологий являет собой следующее: “Широкий средств и устройств коммуникаций, которые связывают информационные системы и людей, включающую в себя: голосовую почту, электронную почту, голосовые конференции, видеоконференции, интернет, групповые и корпоративные средства связи, а так же факсы, автомобильные телефоны, персональные компьютеры, помощники и так далее”, или “ это возможности, предоставленные организациям со стороны информационных систем, электронных вычислительных машин, а так же программного обеспечения, применяемого с целью обмена, хранения, анализа и корректировки информации, баз знаний с целью достижения целей организации”.

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

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

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

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

Основные модели разработки программного обеспечения: 1. Модель водопада.

2. V-модель.

3. Инкрементная модель.

4. RAD модель.

5. Гибкая методология.

6. Итерационная модель.

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

8. Модель прототипирования.

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

Описание основных моделей разработки программного обеспечения: Модель водопада: Данная модель была самой первой структурированной моделью разработки программного обеспечения. Ее еще называют линейно-последовательной моделью, в виду своей простоты использования и применения. В данной модели, каждая фаза должна быть до конца выполнена, и только тогда осуществляется переход к следующей стадии. Данная модель применяется в тех случаях, когда в техническом задании отсутствуют специфические требования к проекту программного обеспечения. В конце каждой фазы выполняется отчет по проделанной работе и структурированные результаты. Это выполняется с целью выявления отклонений по сроку, бюджету, а так же целей проекта, с целью выявления необходимости продолжать или закрывать проект. В данной модели фазы никаким образом не пересекаются.

Основные преимущества данной модели: 1. Крайне простая модель для освоения и применения

2. Легко управляемая в виду своей жесткости - каждая фаза имеет свое место, и должна соблюдаться строгая последовательность.

3. В виду строгой структурированности, одновременно выполняется одна фаза проекта, а потому, фазы не пересекаются никаким образом.

4. Идеально подходит для маленьких проектов, с четкими и ясными требованиями.

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

2. Проект не считается законченным, пока не пройдет через все фазы проекта.

3. Высокие уровни риска и неопределенности.

4. Не подходит для сложных или объектно-ориентированных проектов.

5. Не подходит для проектов с долгим сроком обслуживания или с долгим сроком исполнения.

6. Не подходит для проектов, имеющих высокий риск изменения конечных целей и требования.

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

2. Определение конечного продукта остается стабильным.

3. Технология производства понятна проектной группе.

4. Отсутствуют неоднозначные требования.

5. Открытый доступ для проектной группы ко всем необходимым для выполнения задачи данным.

6. Проект исполняется в малые сроки.

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

V-модель.

Данная модель берет свое название исходя из двух английских слов “Verification” и “Validation”, которые означают “Верификация” и “Валидация” соответственно. Так же, как и в модели водопада, V-образная модель подразумевает только последовательный путь выполнения процессов. По своей сути, данная модель является расширением модели водопада. Помимо движения вниз по линейной модели водопада, в модели V, после стадии реализации происходит подъем вверх, данным образом формируя букву V. Основным отличием между V-моделью и моделью водопада - раннее планирование тестирования в соответствии с V-образной моделью.

К основным преимуществам данной модели относят: 1. Простота использования.

2. Каждая фаза нацелена на определенные практические результаты.

3. Более высокая вероятность успеха относительно модели водопада в виду разработки планов тестирования на ранней стадии проекта.

4. Отлично работает, когда требования ясно сформулированы.

5. Верификация и Валидация продукта происходят на ранних стадиях разработки.

К основным недостаткам данной модели относят: 1. Как и модель водопада, является негибкой моделью разработки.

2. Малая гибкость и настраиваемость в процессе разработки делает проект дорогостоящим.

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

4. Модель не предусматривает плана действий с неучтенными проблемами.

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

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

Инкрементная модель.

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

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

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

2. Техническое задание формируется непосредственно перед планированием разработки.

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

К основным преимуществам данной модели относят: 1. Возможность внесения нововведений и исправления ошибок после каждого цикла

2. Модерация проекта осуществляется на протяжении всего жизненного цикла проекта, посредством выпущенной документациям и обзорам

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

4. Помогает смягчить архитектурные и интеграционные риски заранее.

5. Позволяет формировать пакеты обновлений, которые постепенно становятся более полными и могут запускаться в программе в виде дополнительных релизов.

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

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

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

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

Данная модель разработки программного обеспечения применяется в следующих случаях: 1. Инкрементная модель разработки внедряется только в тех случаях, когда существуют точные технические требования к проекту.

2. Не смотря на то, что основные требования должны оставаться без изменений, некоторые детали могут со временем меняться и расширяться.

3. В случае, когда необходимо в скором времени выпустить продукт на рынок.

4. Когда внедряется новая технология разработки.

5. Необходимо в сжатые сроки достичь высокоприоритетных целей. К примеру, запустить проект раньше конкурентов.

Модель RAD.

Модель RAD, или Rapid Application Development, или Быстрая Разработка Приложений, являет собой разновидность инкрементной модели. В модели RAD компоненты системы разделяются на несколько составляющих и разрабатываются одновременно, таким образом формируя мини проекты. Итоговые разработки упаковываются, распределяются и собираются в рабочий прототип. Эта модель разработки дает возможность заказчику увидеть и опробовать систему, а так же сформировать отзыв и детализировать требования.

Модель имеет следующие фазы: 1. Бизнес моделирование: Информационные потоки распределяются между подразделениями.

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

3. Моделирование процессов: Объекты данных конвертируются в моделирование данных с целью достижения поставленных бизнес-целей. Объекты данных обрабатываются по системе CRUD.

4. Генерирование приложения: Средства автоматической сборки преобразуют мини проекты в одно приложение.

5. Тестирование и запуск: Финальное тестирование всех компонентов системы и ее интерфейса, запуск.

К основным преимуществам RAD модели относят: 1. Оптимизированное время разработки.

2. Позволяет повторно использовать некоторые компоненты.

3. Появляется возможность быстрой первоначальной проверки.

4. Появляется возможность обратной связи с клиентами.

5. Оптимизированная интеграция с самого начала производства.

К основным недостаткам RAD модели относят: 1. Необходимо иметь высокопрофессиональную команду проекта, способную предоставить узкоспециализированных сотрудников для достижения бизнес целей.

2. Данная модель применима лишь к тем проектам, которые можно разделить на модули.

3. Требуются профессиональные дизайнеры и разработчики.

4. Модель является зависимой от навыков моделирования. Неправильно спланированная модель разработки может навредить проекту.

5. Не подходит для малобюджетных проектов, так как стоимость разработки моделей и средств автоматической сборки высока.

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

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

3. Данную модель необходимо выбрать в том случае, когда есть доступ к высокому уровню знаний в бизнесе и при необходимости создать систему за короткий промежуток времени (2-3 месяца).

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

Гибкая методология разработки, как и предыдущая модель, берет свое начало из инкрементной модели. Программное обеспечение разрабатывается в соответствии с инкрементными, ускоренными циклами. В результате разработчик получает маленькие сборки системы, которые накладываются на предыдущую сборку, тем самым повышая функционал. Каждый выпуск проходит тестирование, с целью выявления ошибок и недочетов. Данная методология разработки применяется для разработки стратегически важных приложений. На сегодняшний день, самой популярной моделью Гибкой методологии разработки является Экстремальное Программирование (Extreme Programming, XP).

К основным преимуществам Гибкой методологии относят: 1. Клиент удовлетворен постоянным, актуальным и качественным программным обеспечением.

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

3. Программное обеспечение часто обновляется.

4. Предпочтительной формой общения считается личный разговор, а не корпоративная переписка.

5. Тесное и каждодневное сотрудничество между разработчиками и заказчиком.

6. Постоянное внимание на техническое совершенствование и улучшение дизайна.

7. Постоянная адаптация программного обеспечения в соответствии с обстоятельствами.

8. Даже самые поздние корректировки в техническое задание не наносят существенного ущерба проекту.

К основным недостаткам Гибкой методологии относят: 1. В случае с особо крупными проектами, довольно сложным становится расчет усилий, необходимых для достижения цели вначале разработки программного обеспечения.

2. Отсутствует обязательность фиксирования всех согласованных изменений в дизайне, документации и дизайне проекта.

3. В случае, если клиент не имеет представления, какой конечный результат он ожидает, проект может “сломаться”.

4. Только высококвалифицированные разработчики способны работать внутри данной модели.

Данная модель разработки программного обеспечения применяется в следующих случаях: 1. В случае, когда необходимо внести новые изменения в старый продукт. Возможности, которые открываются внутри Гибкой методологии, позволяют вносить самые разные нововведения с минимальными затратами, и быстро оптимизированы благодаря частому обновлению сборок.

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

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

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

Итеративная (или итерационная) модель.

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

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

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

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

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

4. В данной модели больше времени уделяется непосредственному проектированию продукта, а не документированию.

К основным недостаткам Итеративной модели относят: 1. Каждая стадия итерации является жесткой и не имеет перекрытий.

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

Данная модель разработки программного обеспечения применяется в следующих случаях: 1. Требования к разрабатываемой системе полностью определены и понятны.

2. Когда проект является большим по своим масштабам.

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

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

Спиральная модель очень похожа на инкрементную модель, только с наибольшим вниманием к анализу рисков. Данная модель имеет четыре этапа: 1. Планирование: На данном этапе происходит сбор требований к проекту. Собираются требования типа “BRS” (Business Requirement Specifications) и “SRS” (System Requirement specifications), или Технические и системные требования.

2. Анализ рисков: На данном этапе происходит идентификация рисков и рассмотрение их решений по их минимизации. На данном этапе разрабатывается прототип проекта. Если в последствии разработки выявляются риски, то последующим шагом является разработка мер по их минимизации и немедленное внедрение решения.

3. Разработка: На данном этапе происходит разработка программного обеспечения и его тестирование.

4. Оценка: Данный этап предоставляет клиентам и стейкхолдерам оценить конечный продукт, прежде чем он перейдет к следующей спирали.

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

К основным преимуществам Спиральной модели относят: 1. Высокий уровень анализа рисков.

2. Подходит для стратегически важных проектов.

3. Высокий уровень контроля документации и процессов.

4. Дополнительный функционал может быть добавлен позднее.

5. Программное обеспечение создается на ранней стадии разработки.

К основным недостаткам Спиральной модели относят: 1. Высокий уровень анализа рисков требует привлечения специалистов.

2. Может перерасти в крайне дорогой проект.

3. Успешность проекта зависит от качества анализа рисков.

4. Не эффективен для небольших проектов.

Данная модель разработки программного обеспечения применяется в следующих случаях: 1. Когда важны затраты и учет риска.

2. Для проектов с средними и высокими рисками.

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

4. Заказчик и пользователи не до конца уверены в своих требованиях.

5. Сложные требования к проекту.

6. Разрабатывается новая линейка продуктов.

7. Ожидаются значительные изменения.

Модель прототипирования.

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

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

К основным преимуществам прототипирования относят: 1. Пользователи активно вовлечены в процесс разработки.

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

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

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

5. Недостающий функционал может быть быстро выявлен и внедрен.

6. Сложный и непонятный пользователю функционал так же быстро может быть выявлен и исправлен.

К основным недостаткам прототипирования относят: 1. Может привести к постепенному усложнению проекта и уходу его от базовой концепции.

2. Фактически, модель прототипирования может усложнить систему в разы, отклонив ее от конечной цели.

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

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

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

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

Следовательно, методологии разработки программного обеспечения подразделяются по следующим категориям: Тяжеловесы и Легкие. Методологии-тяжеловесы подходят тем проектам, внутри которых изменения вряд ли произойдут, а уровень программного обеспечения позволяет детально распланировать разработку. Методологии-тяжеловесы легкие для понимания и применения. Они обеспечивают надежную документацию и являются привлекательными для владельцев проекта, поскольку они хорошо структурированы и демонстрируют ощутимые результаты на каждом этапе проекта, а так же создают иллюзию контроля процесса в виду строгой последовательности исполнения. Действуя внутри методологии-тяжеловеса, руководитель проекта может в любой момент провести проверку отчетности и дать оценку выполненной работе. Таким образом, руководитель проекта вовлечен только в стадии планирования, исследования и проверки проекта на предмет соответствия выполненного задания техническим требованиям.

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

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

Подходы к изучению групповой осознанности.

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

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

Процессы, которые можно найти в Высоконадежных организациях, обеспечивают развитие благоприятной организационной структуры, которая, в свою очередь, положительно влияет на взаимодействие адаптивного обучения и продуктивной работы. Обратив внимание на данные процессы, мы должны привести в качестве примера исследования мистера Перроу (1984), сосредоточенные именно на макроуровне высоконадежных организаций. Основным вкладом данного исследования является доказательство того, что посредством изучения и развития когнитивных моделей и процессов управления, организация подтверждает и укрепляет свою надежность, а так же вырабатывает механизм управления, благодаря которому создаются надежные структуры организации.

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

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

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

2. Отказ от упрощений.

3. Чувствительность к о

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Swanson E.B. and N.C. Ramiller (2004), “Innovating mindfully with information technology”, MIS Quarterly, 28, 553-583.

2. Duncan N.B. (1995), “Capturing flexibility of information technology infrastructure: a study of resource characteristics and their measures”, Journal of Management Information Systems, 12, 37-57.

3. Yates J. and J. Van Maanen (2001), “Information Technology and Organizational Transformation: History, Rhetoric, and Practice”, Sage Publications: London.

4. Fichman R.G. (2004), “Going beyond the dominant paradigm for information technology innovation research: emerging concepts and methods”, Journal of the Association of Information Systems, 5, 314-355.

5. Mikko Valorinta. (2009),” Information technology and mindfulness in organizations, Industrial and Corporate Change”, Volume 18, Number 5, pp. 963-997.

6. Dewett T., and Jones G.R. (2001). “The role of information technology in the organization: A review, model, and assessment.” Journal of Management 27, 313-346.

7. Attaran M. (2003). “Information technology and business-process redesign.” Business Process Management Journal 9, 440-458.

8. W.W. Royce, “Managing the development of large software systems: Concepts and techniques”, IEEE WESCON, vol. 26, no. 8, pg. 1-9, 1970.

9. S. Mathur, S. Malik, “Advancements in the V-Model”, International Journal of Computer Applications, vol. 1, no. 12, pg. 29-34, 2010, doi: 10.5120/266-425.

10. K. Beck, “Embracing change with extreme programming”, Computer, vol. 32, no.10, pg. 70- 77, 1999, doi:10.1109/2.796139.

11. C. Larman, V.R. Basili, “Iterative and Incremental Development: A Brief History”, Computer, vol. 36, no. 6, pg. 47-56, 2003, doi:10.1109/MC.2003.1204375.

12. J. Martin, Rapid application development, Publisher: Macmillan Publishing, 1991,pg. 788, ISBN:0-02-376775-8.

13. B.W. Boehm, “A spiral model of software development and enhancement”, Computer, vol. 21, no. 5, pg. 61-72, 1988, doi: 10.1109/2.59.

14. M. Liviu, “Comparative study on software development methodologies”, Database Systems Journal, vol. 5, no. 3/2014, pg. 37-56.

15. D. Riehle, “A comparison of the value systems of Adaptive Software Development and Extreme Programming: How methodologies may learn from each other”, Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering, XP 2000, 21-23 Jun. 2000, Cagliari, Italy, pg. 35-50.

16. J.A. Livermore, “Factors that Impact Implementing an Agile Software Development Methodology”, Proceedings of IEEE SOUTHEASTCON, SECON 2007, 22-25 Mar. 2007, Richmond, USA, Publisher: IEEE, 2007, doi: 10.1109/SECON.2007.342860, pg.82-86.

17. J.E. Cooling, T.S. Hughes, “The emergence of rapid prototyping as a realtime software development tool”, Proceedings of the Second International Conference on Software Engineering for Real Time Systems, 18-20 Sep. 1989, Cirencester, UK, Publisher: IET, 1989, pg. 60-64.

18. Karl E. Weick, Kathleen M. Sutcliffe and David Obstfeld, “Organizing for High Reliability: Processes of Collective Mindfulness”, R.S. Sutton and B.M. Staw (eds), Research in Organizational Behavior, Volume 1 (Stanford: Jai Press, 1999), pp. 81-123.

19. Perrow C. (1984). “Normal accidents: Living with high-risk technologies.”, New York: Basic Books.

Размещено на .ru