[БЕЗ_ЗВУКА] Какие выводы мы можем сделать по итогам рассмотрения оптимизации моделей жизненного цикла в условиях кризиса для производства корпоративных систем? Ну прежде всего, не существует «серебряной пули», то есть не существует универсальной модели, которая удовлетворяет всем требованиям любого заказчика при производстве любого программного продукта корпоративного типа. Надо отметить, что некоторые модели можно упрощать, некоторые модели можно комбинировать, в том числе с прототипированием, которое дает достаточно быстрый и легкий способ выявления дефектов и устранения дефектов, а также выбора того направления, по которому мы будем совершенствовать программный продукт при его разработке, расширении или развитии. Можно выделить определенное количество признаков, которые являются ключами к успеху разработки программного продукта. Основные из них перечислены на слайде: это прежде всего грамотная постановка задачи, заказчик и разработчик должны прийти к общему пониманию того, что именно будет реализовано и какие именно бизнес-задачи будут реализованы, какие именно проектные ограничения существуют с точки зрения бизнес-возможностей и с точки зрения технологий, то есть задача должна быть грамотно сформулирована и грамотно поставлена, для этого в том числе используются и прототипы. Важной особенностью является насколько возможно более раннее выявление и устранение ошибок, поскольку стоимость их устранения экспоненциально возрастает в ходе жизненного цикла. На это направлены такие подходы и модели, как, скажем, синхронизация и стабилизация с частым и ранним тестированием, как спиральная модель с постоянной оценкой рисков и ряд других моделей. Определяющее значение имеет выбор модели, то есть последовательности и порядка смены фаз жизненного цикла, а также выбор архитектуры программного обеспечения, то есть той самой суперпозиции модуля и путей взаимодействия интерфейсов между ними, которое и определит грамотное поведение программного продукта с точки зрения тех самых атрибутов качества, которые были заявлены и с точки зрения тех проектных рамок, которые были согласованы с заказчиком. Применение правильных моделей, методов и инструментальных средств разработки. Мы упоминали неоднократно о том, что средства разработки и средства поддержки проектирования и тестирования широко используются в таких моделях как, скажем, синхронизация и стабилизация, но на самом деле для производства корпоративных систем вообще работать, так сказать, руками (исключительно руками, без применения высокоуровневых и высокоточных средств разработки) является во многом потерей производительности, потерей времени и потерей ресурсов. Естественно, для CASE средств, для владения этими инструментальными средствами необходимы затраты на обучение персонала, сертификацию персонала, рабочее знание этих продуктов, чтобы, скажем, определенные комбинации горячих клавиш уже могли вводиться разработчиками без чтения соответствующей документации, практически вслепую, и на этом экономить существенные ресурсы. В любом случае, средства инструментального проектирования и поддержки разработки помогают разработчикам вести продуктивный диалог как друг с другом, так и с заказчиком в терминах существующих стандартов. И следование этим стандартам обеспечивает должный уровень качества, в том числе и корпоративных программных продуктов, а также стыковку с теми продуктами, которые уже у заказчика существуют, а также являются в определенной мере ключом к успеху. Грамотная ревизия проекта на ранних стадиях и, вообще говоря, на всех стадиях, то есть оценка того, что разработанные нами программные модули или документации являются полными, не противоречивыми, описывают ровно ту функциональность, которую заказчик требует, и не включают ничего лишнего, никаких дополнительных иллюзий или идей от разработчика, и приведут в итоге к той последовательности действий, которая даст нам полномасштабный программный продукт должного качества, которого от нас и ожидает заказчик. Естественно, определенные знания и определенная зрелость с точки зрения дисциплины, с точки зрения исследований стандартов и с точки знаний CASE средств являются ключами к успеху. Если эта зрелость не проявлена, целый ряд моделей — в том числе объектно-ориентированная модель, в том числе модель синхронизации и стабилизации, в том числе спиральная модель — могут выродиться в подход проб и ошибок, что неприемлемо по эксплуатационным характеристикам зачастую, и конечно же неприемлемо экономически. Нужно кроме того учитывать человеческий фактор, который, как мы помним, с точки зрения корпоративных систем является определяющим и является достаточно важным вкладом в их сложность. Технологическая составляющая сложность у корпоративных систем достаточно высока, но не является определяющей в том смысле, что управленческая сложность зачастую доминирует. Именно поэтому следование стандартам и продуктивное взаимодействие в рамках команды разработчиков и взаимодействий с заказчиком является очень важной составляющей успеха проекта в кризис. Ну и нужно помнить о том, что критериями соответствия продукта тем требованиям, которые предъявляет заказчик в том числе и в кризис, являются атрибуты качества. То есть такие атрибуты как сопровождаемость, процент повторного использования, эргономика, переносимость и так далее являются весьма важными. Нужно отметить, что наш вклад, в том числе и в кризис, в разработку тех продуктов, которые мы используем у одного заказчика, может быть применен и для переработки, повторной разработки с несущественными коррективами, со значительными с экономической точки зрения коррективами, которые могут быть повторно использованы для других заказчиков либо как коробочный продукт. И это является достаточно важным вкладом в антикризисное управление разработкой жизненного цикла. На этом мы заканчиваем наш курс, благодарю за внимание.
