Итерационная_модель_Петров.md 10 KB
Итерационная модель имплементации информационных систем
Попытаемся устранить недостаток однопроходной модели. Для этого каждый из этапов схемы дополним контуром обратной связи, тем самым добавив возможность возврата на предыдущие стадии. Если внимательно проанализировать полученный результат, окажется, что каждый из этапов может выполняться несколько раз. Именно поэтому полученную модель (рис. 4) называют итерационной. Впервые применённая в США ещё в 1957 году, многопроходная итерационная модель основана на концепции IID (Iterative and Incremental Development), включающей принципы итеративности (уточнение и детализация разрабатываемого программного обеспечения шаг за шагом), инкрементальности (увеличение функциональности ПО для каждой итерации) и эволюционности (максимальное использование наработок предыдущих итераций для последующих).
Рис.4. Переход от каскадной и итерационной модели внедрения КИС
Разработка ПО согласно концепции IDD сводится к разбиению этапа реализации на серию быстрых, лёгких и адаптивных итераций, оперативно приносящих результаты. Каждая итерация основана на PDCA-цикле Деминга (Plan-Do-Check-Act) и завершается демонстрацией потребителю полученного промежуточного продукта с целью скорейшего выявления потенциальных ошибок. Более того, в ходе выполнения итераций представление о конечном продукте изменяется, поэтому добавляются новые функциональные возможности. Продолжительность каждой итерации варьируется в пределах 1-6 недель, а начальный список требований к ПО вообще может отсутствовать.
Отметим плюсы итерационной модели:
1)оперативная разработка и демонстрация ПО для устранения ошибок;
2)допускается отсутствие требований к ПО,
А также минусы:
1)отсутствие понимания объёма работ для завершения проекта;
2)ориентированность на разработку, но не кастомизацию ПО.
Рассмотрим проект имплементации КИС согласно предлагаемой модели:
1)идентификация и анализ требований, предъявляемых к КИС, а также приоритезация найденных требований (опционально);
2)определение числа и продолжительности итераций разработки КИС, в случае наличия приоритезированных требований их распределение по итерациям разработки;
3)доработка и кастомизация КИС, функциональное и интеграционное тестирование с последующей демонстрацией полученного продукта заказчику для уточнения требований (для всех итераций);
4)проведение приёмочного тестирования;
5)документирование реализованного программного решения;
6)переход к продуктивной эксплуатации и поддержка.
Выполнение итераций подразумевает демонстрацию продукта заказчику, в результате чего выявляются дефекты и идентифицируются новые требования к ПО. Первый минус многопроходной модели формулируется достаточно просто: вновь появляющиеся требования и пожелания клиента могут выйти за временные рамки изначально обсуждённых итераций. Таким образом, необходимо некое мерило требований для отсекания маловажных, что в принципе противоречит самой концепции IID.
Второй минус выглядит куда более серьёзно: раньше речь шла исключительно о доработке КИС, теперь же непонятно, как быть с кастомизацией и интеграцией. Сначала разберёмся с кастомизацией. Настройке в КИС подлежат уровни данных и бизнес-процессов: организационная структура, процессы, основные и переменные данные. Невозможно выполнить настройку, например, бизнес-процесса в КИС, следуя принципу итеративности. Разумнее всего применить инкрементальный подход: разбить процесс на части и настроить одну часть бизнес-процесса в заданной итерации, а остальные – в следующих. Данный подход применим также к оргструктуре и данным. В итоге получается некий аналог требований: процессы, организационная структура и данные должны быть декомпозированы на объекты и распределены по итерациям. Дальше необходимо понять, полученные объекты включать в начальные или завершающие итерации? Ответ связан с вопросом интеграции.
Интеграцию КИС можно разделить на внутреннюю и внешнюю. Под внутренней интеграцией подразумевается взаимодействие объектов и модулей КИС между собой, например, приход товара на склад должен порождать бухгалтерские проводки. В данном примере присутствуют две сущности различных модулей: приход и проводка, относящиеся к функциональности логистики закупки и финансам соответственно. Второй вид интеграции подразумевает взаимодействие КИС с внешними подсистемами, например, SRM, CRM, WMS и др. Если внутреннюю интеграцию в большей степени можно отнести к кастомизации КИС, то внешнюю – к настройке и доработке. Никакая доработка КИС не может вестись без наличия базовых компонентов системы, которые преимущественно заводятся путём настройки. Тем самым логично в начальные итерации включить кастомизацию КИС и интеграцию, и лишь затем доработку. Поэтому каждая итерация должна включать как функционально-модульное, так и интеграционное тестирование. Суммируя, видится следующая картина реализации итераций:
1)начальные итерации должны включать настройку системы и внутреннюю интеграцию по инкрементальному принципу с целью подготовки основополагающего ядра КИС;
2)последующие итерации содержат доработки КИС, использующие ранее подготовленные функции КИС путём кастомизации.
Резюмируя вышесказанное, применение итерационной модели вполне логично для доработки КИС, настройка же потребует дополнительных манипуляций. Не смотря на статистику, гласящую, что порядка 70% функционала иностранных КИС требуют доработки, пока многопроходная модель применяется в России достаточно редко. Возможно, причина кроется в том, что предпочтение отдаётся максимальному использованию стандартного функционала КИС, то есть кастомизации, против его доработки.