Технология программирования 2

Далее рассмотрим инкрементную модель. В основу данного подхода лежат те же этапы разработки. Но вот расположение их и подход к их использованию совсем другой. Кроме этапов в данной модели жизненного цикла еще существуют версии, что позволяет улучшать и улучшать программный продукт со временем, что принципе актуально, учитывая изменения современного мира.
В начале работы над проектом определяются все основные требования к системе, после чего выполняется ее разработка в виде последовательности версий. При этом каждая версия является законченным и работоспособным продуктом. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система.
Данная модель жизненного цикла характерна при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат (информационная система). Разработка версиями ведется в силу разного рода причин:
— отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;
— отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;
— требований поэтапного внедрения и освоения продукта конечными пользователями. Внедрение всей системы сразу может вызвать у ее пользователей неприятие и только «затормозить» процесс перехода на новые технологии. Образно говоря, они могут просто «не переварить большой кусок, поэтому его надо измельчить и давать по частям».
Достоинства и недостатки этой стратегии такие же, как и у классической. Но в отличие от классической стратегии заказчик может раньше увидеть результаты. Уже по результатам разработки и внедрения первой версии он может незначительно изменить требования к разработке, отказаться от нее или предложить разработку более совершенного продукта с заключением нового договора.
Далее рассмотрим спиральную модель. Основу данной модели составляют тоже этапы и версии, но эти версии будут идти одна за одной и формировать вот такую воображаемую спираль. В начале заказчик, по каким-то причинам, не может сформировать требования к программному продукту. Эти требования он выдает по мере понимания предметной области, что приводит к постоянному возвращению к программе и формированию новых версий разработки.
Данная модель жизненного цикла характерна при разработке новаторских (нетиповых) систем. В начале работы над проектом у заказчика и разработчика нет четкого видения итогового продукта (требования не могут быть четко определены) или стопроцентной уверенности в успешной реализации проекта (риски очень велики). В связи с этим принимается решение разработки системы по частям с возможностью изменения требований или отказа от ее дальнейшего развития.
Достоинства модели:
— позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;
— допускает изменение требований при разработке информационной системы, что характерно для большинства разработок, в том числе и типовых;
— обеспечивает большую гибкость в управлении проектом;
— позволяет получить более надежную и устойчивую систему. По мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации;
— позволяет совершенствовать процесс разработки – анализ, проводимый в каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации;
— уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.
Недостатки модели:
— увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;
— затруднены операции временного и ресурсного планирования всего проекта в целом. Для решения этой проблемы необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа выполнена. План составляется на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков.
На основании анализа предметной области, постановки задачи и теории по моделям жизненного цикла, а также учтем простату создаваемого программного продукта, можно сказать, что в нашем случае целесообразно выбрать каскадную модель жизненного цикла системы кассового обслуживания с одним продавцом на примере веломастерской.