0:06
После обсуждения основных этапов жизненного цикла
рассмотрим коротко, подводя итоги, каким образом эти
этапы находят себя в различных моделях жизненного цикла,
какие преимущества и недостатки в этих моделях можно выделить.
Мы осудили несколько видов моделей жизненного цикла.
Они все в данном случае сведены в таблицу. Мы говорили
о моделях неполного жизненного цикла, об итеративных или
циклических моделях и так сказать о специализированных
моделях или достаточно сложных моделях.
Первая категория моделей: это модель проб и ошибок —
модель Build-and-Fix, — модель водопадная, которая дает
нам один проход разработки и изготовление готового
продукта сразу после этого прохода, и модель быстрого
прототипирования, которая позволяет нам эффективно
оценивать риски и определять пути разработки в соответствии
с возможными направлениями движения, возможными вариантами
развития программного продукта.
Что касается этих трех моделей? Первая модель
заключается в упрощенном жизненном цикле, которых
не содержит фактически первичного проектирования
и высокоуровневого концептуального анализа требований.
Т. е. на самом деле это модель применима для относительно
небольших программных продуктов. Мы ее рассматриваем
в курсе в связи с тем, что в случае корпоративных
систем отдельные модели могут просто вырождаться
в такого рода модели, а также в связи с тем, что
для кризисных условий мы можем в некотором роде
ускорить или упростить жизненный цикл, отдельные
фрагменты этого жизненного цикла сократив. Но нужно
достаточно хорошо думать на чем можно сэкономить
в кризис, а на чем нет. Естественно, без существенного концептуального
проектирования все-таки корпоративные системы
по большому счету строить невозможно. Поэтому для
тривиальных, для небольших продуктов порядка 1000 строк
эта модель применима, для крупномасштабных эта модель
не приемлема. Что касается модели водопадной?
Эта модель хороша тем, что за счет строгой документации
мы в ряде случаев, особенно при технически грамотном
заказчике, который может грамотно ставить задачу
и контролировать ее выполнение на основе анализа проектной
документации, выполненной в соответствии со стандартами,
т. е. различными диаграммами и другими нотациями, которые
формально описывают то, каким образом будет выглядеть
и функционировать будущий программный продукт, позволяет
строить разработку в один проход, позволяет получать
продукт за достаточно быстрый цикл разработки. Но риск
заключается в том, что тот программный продукт, который
мы получим в итоге, может существенно отличаться
от того, что требует заказчик, если наблюдаются существенные
отклонения в ходе выполнения этого жизненного цикла.
На каждом этапе таком, как скажем анализ или проектирование,
или реализация, мы можем производить верификацию
и корректировать документы. Но как только один из этих
этапов завершен, каждый из этих этапов завершен,
подписывается документ о том, что архитектурное
проектирование выполнено, собственно подписывается
архитектурный проект, подписывается техническое задание или
какой-то другой документ, который собственно закрывает
нам работу на этой стадии и приводит нас к последующей
стадии. При этом если проектирование ведется анархичным, и заказчик
не вполне технически грамотен, мы можем получить не совсем
тот программный продукт, который отвечает ожиданиям
заказчика. Также если продукт инновационный или существенно
меняются ключевые эксплуатационные характеристики или ключевые
функциональные требования, естественно, в ходе разработки,
естественно, мы придем в результате разработки
к другому программному продукту. И тогда эта модель
на самом деле не приемлема. И что касается прототипа.
Надо помнить о том, что прототип — это очень хорошее
средство в кризис для моделирования тех последствий, которые
может повлечь движение по той или иной альтернативе
разработки программного продукта. Но прототип — это
совершенно не приемлемая форма программного продукта.
Он недостаточно хорошо задокументирован, он недостаточно
надежен, недостаточно безопасен, недостаточно протестирован,
поэтому сдавать его или пытаться использовать
какую-то его часть как фрагмент будущего программного
продукта не целесообразно, имеет смысл переразработать
заново всю функциональность, которая реализована в прототипе.
Прототип — это хорошее и быстрое средство для
экономичного поиска приемлемого решения.
Далее мы рассмотрели несколько моделей, собственно две
модели циклических или итеративных, которые позволяют
нам разрабатывать программный продукт в несколько стадий.
При этом как инкрементальная модель, так и модель синхронизации
и стабилизации, вернее объектно-ориентированная
модель, которая была рассмотрена, дают нам возможность, вообще
говоря, производить несколько итераций, производить
несколько циклов. Что касается инкрементальной
модели? Эта модель способствует быстрой отдаче инвестиций
за счет того, что мы вводим программный продукт у заказчика
поэтапно. Т. е. изначально только базовая функциональность
реализуется у заказчика, но это полномасштабный
программный продукт с точки зрения эксплуатационных
характеристик. Мы можем передать его, и заказчик
может его эксплуатировать. И в этом достаточно простом
продукте, с точки зрения сравнения с полнофункциональном,
разобраться и его эксплуатировать. Он уже не вызывает каких-то
бурных реакций отторжения, каких-то опасений из-за
его высокой сложности, и поэтому заказчик может
достаточно быстро и легко к нему адаптироваться и
вернуть те инвестиции, которые были им понесены
на первичном этапе разработки. В этом смысле для антикризисной
разработки такого рода подход вполне приемлем,
и для тех продуктов, которые развиваются эволюционно,
поступательно, он вполне применим. Но если мы говорим
о тех продуктах, которые достаточно быстро выходят
за рамки первичной концепции, об инновационных продуктах
или о продуктах с быстроменяющимися ключевыми требованиями,
здесь, конечно, применение этого подхода — инкрементальной
модели — не вполне оправдано. Что касается объектно-ориентированной
модели, ее ключевая особенность — это параллелизм и перекрытие
определенных фаз, таких как скажем анализ требований
и проектирование, при этом необходимо обеспечить
высокую дисциплину, организованность и следование стандартам
внутри коллектива разработки. Если этого не происходит,
мы можем получить вырождение в Build-and-Fix, что достаточно
опасно с точки зрения как эксплуатационных характеристик,
так и, конечно же, затрат ресурсов. Т. е. в кризис
не приемлемо. И, наконец, еще две модели,
которые представляют собой, так сказать, более сложные
жизненные циклы. Они включают в себя анализ рисков, который
сам по себе является достаточно затратным и дорогостоящим
мероприятием. Это модели синхронизации и стабилизации
и спиральная модель. Спиральная модель за счет
того, что на каждом этапе спирали у нас происходит
анализ и оценка рисков, является, во-первых, дорогостоящей
и, во-вторых, рекомендуется ее использовать внутри
корпорации. Т. е. разработчик и заказчик должны находиться
предпочтительно в составе одной и той же корпорации,
для того чтобы конфиденциальные или критичные данные не
утекали наружу. Вот в таких рамках, при таких условиях,
значит, эта модель является достаточно хорошей для
производства больших и сложных корпоративных
систем в кризисных условиях, поскольку она дает возможность
быстро отсечь те альтернативы, которые оказываются неприемлемыми.
Что касается подхода синхронизации и стабилизации, эти процессы
и синхронизация, и стабилизация, т. е. выявление и построение
наиболее стабильного релиза, релиза, который ведет себя
наиболее устойчиво, дают нам возможность опять-таки
быстро отсекать те альтернативы, которые не ведут к хорошему
продукту, и стабилизировать те альтернативы, которые,
наилучшую по сути дела альтернативу, которая ведет
к продукту с лучшими характеристиками. Это опять-таки средство
экономии в кризис, быстрого возврата инвестиций за
счет частого и раннего тестирования. Но здесь
проблема в том, что и синхронизация, и стабилизация с точки
зрения разработки это, вообще говоря, паразитные
процессы. Они, конечно, ведут к улучшению качества,
но не ведут к появлению новых функций в продукте.
И в этой связи, если мы слишком много как разработчики
тратим сил на эти процессы, в итоге это может привести
к тому, что продукт будет разработан с опозданием,
и на самом деле заказчик может в срок его не получить.
Поэтому поскольку требуется применение специальных
инструментальных средств тестирования, эта методика,
скажем, вне Microsoft, который тесно связан с этим подходом,
не получила широкого распространения, но в целом отдельные ее
элементы возможно использовать в кризис для получения
более быстрой отдачи инвестиций. Вот таким образом можно
подвести итоги рассмотрения наших моделей жизненного
цикла в кризисных условиях корпоративных систем.
Зыков Сергей ВикторовичДоцент
