Файл: Управление проектом внедрения специализированного программного обеспечения в Банк.docx

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

• 
  «Разработка требований». Происходит сбор бизнес-требований заказчика, после чего осуществляется их преобразование в функциональные требования к программному продукту;
  
• 
  «Архитектура и дизайн». Определение требований, относящихся к программному обеспечению (базы данных, параметры безопасности, модели данных и интерфейсная схема);
  
• 
  «Разработка». Создание программного продукта, базирующегося на спецификациях, определенных на предыдущих стадиях;
  
• 
  «Тестирование». Проверка отсутствия в программном продукте каких-либо дефектов, а также соответствия функциональности требованиям заказчика
  
• 
  «Внедрение». Инсталляция продукта;
  
• 
  «Поддержка». Проверка корректности в дальнейшей работе программы.
  

(Ledbrook, 2012), (Melonfire, 2006).



Рис. 3 Водопадная модель жизненного цикла IT-проекта

Ключевым моментом водопадной модели является ее последовательный характер, что означает, что каждая фаза не может начаться, если не завершена предыдущая. Данная модель требует четкого планирования в самом начале проекта, и это всегда сопровождается написанием больших технических заданий, а результат работающей программы можно наблюдать только в конце. Управлением IT-проектом в «водопаде» руководит менеджер проекта, который поручает задания разработчикам и устанавливает сроки и бюджет. На протяжении всего жизненного цикла команда проекта отчитывается по проделанной работе только перед менеджером, коммуникации непосредственно с заказчиком отсутствуют. Если определенные в начале проекта требования не меняются, то руководствоваться техническим заданием весьма целесообразно. Проблема заключается в том, что на деле ни один IT-проект нереально спроектировать таким образом, чтобы заранее предугадать все требования пользователей, его функционал и так далее. Помимо всего прочего, если что-то было упущено в работе проекта на его начальных стадиях, исправить это, находясь на завершающих этапах, очень сложно и требует дополнительных затрат.

---

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

1.3.2.3. Итеративная модель жизненного цикла IT-проекта

Итеративная модель жизненного цикла значительно отличается от водопадной. Данный подход подразумевает последовательность циклических итераций, где каждая из них состоит из четырех фаз: сбор требований, планирование, разработка и тестирование (рисунок 4) (Jalote, 2004).



Рис. 4 Фрагмент итерации итеративной модели жизненного цикла IT-проекта

Главной характеристикой итеративной модели является то, что каждая итерация добавляет новый функционал в программный продукт. Для Jalote [32, с. 117] «новая итерация начинается до завершения текущей, тем самым, являясь продолжением актуальной версии программного обеспечения». В этом случае, направление проектной деятельности может быть изменено в начале каждой итерации, что является довольно удобным в случае быстро меняющейся внешней среды. Функциональность всей системы может быть глобально оценена уже в начале проекта (на первых итерациях), а необходимые второстепенные изменения могут быть сделаны в течение следующих итераций. Более того, итерации могут служить средством обратной связи для измерения качества выполнения проекта и продуктивности работы команды участников. Итеративный подход к планированию жизненного цикла предполагает, что различные виды работ над проектом не привязаны к каким-то конкретным стадиям разработки; вместо этого они выполняются по мере необходимости.

1.3.2.4. Спиральная модель жизненного цикла IT-проекта

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

• 
  Цели разрабатываемого в течение данной итерации фрагмента программного обеспечения;
  
• 
  Основные и альтернативы пути к достижению поставленных целей;
  
• 
  Анализ возможных ограничений.
  

---

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

Каждый «виток спирали» представляет собой законченную часть разрабатываемого, продукта, соответственно, с каждым новым «витком» проект достигает более глубокий уровень детализации и конкретизации (рисунок 5):



Рис. 5 Спиральная модель жизненного цикла IT-проекта

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

С развитием теории управления IT-проектами разработчики и их менеджеры поняли, что объединенный вариант итеративной и спиральной моделей жизненного цикла может стать лучшим способом для организации процесса управления IT-проектом. Пошаговая разработка и наличие готовых фрагментов работающего ПО, взятые из итеративной модели, а также главенствующая роль человеческого фактора и анализ возможных рисков, взятые из спиральной модели были объединены в новую методологию, получившую название «гибкой» методологии (agile – англ). Под гибкостью подразумевается следующее:

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

---

(Cobb, 2011).¹

---

1.4. Постановка проблемы

1.4.1 Специфика банковской сферы

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

Идеи об организации автоматизации банковских процессов начали появляться недавно, и это связано с возросшей тенденцией выпускать различные внешние автоматизированные сервисы, предоставляющие определенную информацию о клиентах. Если взять во внимание рынок кредитования, то в качестве примеров таких сервисов можно, безусловно, привести программный комплекс CreditRegistry, выпущенный компанией ЗАО «МТЦ». CreditRegistry автоматизирует бизнес-процессы, связанные со взаимодействием банка с бюро кредитных историй и другими сервисами, помогающими банку организовать свою работу на рынке потребительского кредитования³. Развитие таких сервисов стимулирует банки автоматизировать работу внутри своих департаментов, получая значительную часть данных о клиентах извне.

Банковская сфера является одной из быстро меняющихся и рискованных, что имеет прямое влияние на управление проектами в банках. Достаточно вспомнить кризис 2008 года, после которого множество банковских проектов было попросту заморожено. Банковская сфера также связана с экономической деятельностью государства, соответственно, любые изменения в экономике страны способны изменить актуальность каких-либо данных, использующихся в банках. Таким образом, те IT-проекты, которые предназначаются для автоматизации именно специфических банковских функций, с большей вероятностью будут подвержены изменениям из-за изменений окружающей среды в течение периода их реализации. Банкам также характерны многочисленные конфликты между департаментами, и это зависит от различий в видениях бизнеса. К примеру, рассматриваемый в данной работе проект по внедрению программного обеспечения по принятию решения о выдаче кредита является синтезом идей трех банковских департаментов: рисков, операционного отдела и отдела продаж и маркетинга. Каждый департамент формирует требования, отсортированные по приоритету, руководствуясь собственными мотивами: для отдела продаж главным является повышение количества выданных кредитов (что способствует дальнейшему получению прибыли), для операционного отдела преимуществом является удобность и лаконичность в пользовании программой, риски же стремятся минимизировать вероятность невыплат по кредитам, отбирая, тем самым, только «нерискованных» клиентов.

---