Если 10 лет назад полный жизненный цикл продукта в среднем 8-12 лет, то в наше время -
Если 10 лет назад полный жизненный цикл продукта в среднем 8-12 лет, то в наше время - лишь 2-4 года. В связи с этим информационная структура должна прогнозировать конкурентоспособность и задавать ее показатели в момент проектирования информационного продукта с большим запасом, тогда как разработка продукта с высокой конкурентоспособностью требует длительного срока и больших затрат. Следовательно, при проектировании нового продукта информационная структура должна обеспечить оптимальное сочетание преимуществ быстрого выхода на рынок с низкими темпами морального стариння.Жизненный цикл любого информационного продукта должен быть привязан к конкретному рынку или даже отдельного сегмента, поскольку спрос на один и тот же продукт на разных рынках будет различным из-за неравномерности развития потребностей, требований, традиций, быта и т.д.. Информационная структура должна быть заинтересована в продлении жизненного цикла продукта в сфере потребления для укрепления у потребителя положительного представления о производителе, его имидж и престиж. Кроме того, на протяжении жизненного цикла продукта производитель может осуществлять сервисное обслуживание, операции по совершенствованию его и прочее, что позволит получать дополнительные доходи.
Система послепродажного обслуживания и сопровождения ИПП приобретает решающее значение в конкурентной борьбе однотипных продуктов. Потребителей интересуют не только набор определенного типа услуг, но и их объем и качество. Сервисное обслуживание должно предусматривать:
надежность поставок, технические инструкции;
ремонт оборудования, корректировка программ и актуализацию БД;
предоставление скидок;
простоту вступления в контакт.
Сервисное обслуживание стало закономерным, осознанным предпринимателями, этапом ЖЦ продукта, поскольку продлевает його.
Как известно, главная цель программной инженерии - достижение высокой экономической эффективности. Для этого необходимо глубокое понимание всех процессов, связанных с каждой фазой жизненного цикла продукта. Построение его модели - шаг к познанию этих закономерностей. В самом общем виде модель ЖЦ продукта может быть описана тремя последовательными фазами.
Первая фаза - разработка стратегии автоматизации, выполняемая заказчиком совместно с ее будущими пользователями и консультантами, может быть довольно длительной. Зависимости от квалификации заказчика и сложности системы эта стратегия может быть зафиксирована в документах более или менее детально. Если заказчик - государственная организация, то при разработке стратегии необходимо определить цели автоматизации, пользователей, ожидаемые преимущества и ресурсы, необходимые для создания информационной системы, источники и факторы риска, предполагаемого разработчика и порядок взаимодействия с ним, организацию проекта и распределение ответственности за его реализацию. По достаточно крупных проектов может быть объявлено о тендере для розробникив.
Вторая фаза - собственно создание ИС и внедрение ее - может быть построена по-разному в зависимости от принятой модели жизненного цикла. Главную роль в течение этой фазы играет организация-розробник.
Третья фаза - переход системы после внедрения в полное распоряжение заказчика или организации-пользователя, интересы которой он представляет; разработчик осуществляет сопровождение системы. В процессе сопровождения разработчик устраняет все ошибки, обнаруженные после внедрения, осуществляет адаптацию ИС с учетом условий эксплуатации, изменившихся по требованию заказчика дорабатывает ее с целью повышения качества функционирования. Правильно организованный сопровождение значительной мере замедляет моральное старение программного обеспечения ИС, срок службы которого может в два-три раза превышать срок морального старения ЕОМ.
Существующие модели жизненного цикла различаются по структуре и конкретным содержанием фаз создания и внедрения автоматизированной системы (АС) или отдельных ее составляющих. Распространенными моделями ЖЦП являются:
каскадная модель;
спиральная модель;
метод быстрого прототипа;
метод последовательного наращивания функций;
модель, основанная на повторном использовании компонентов;
модель, основанная на автоматизированном синтезе програм.
Каскадная модель характеризуется четкой упорядоченностью таких стадий создания и внедрения АС:
определение требований;
разработка технического задания;
планирование разработки;
проектирование;
реализация;
сборки системы;
сопровождение;
уточнения вимог.
Такая упорядоченность требует, чтобы работы, предусмотренные на каждой стадии, выполнялись без необходимости их пересмотра, т.е. без возвращения к предыдущей стадии. Модель содержит только внешний цикл, включающий стадию сопровождения, поскольку на этой стадии могут уточняться и изменяться требования заказчика и происходит возврат к стадии разработки технического задания с последующим повторением всех других стадий.
Преимущество каскадной модели - в ее детерминированности и четкой регламентированности. Это важно при разработке сложных проектов, в которых необходима согласованная участие нескольких организаций, представляющих заказчика, разработчиков и пользователей. Ее слабой стороной является то, что от утверждения технического задания до внедрения готового продукта проходит очень много времени. Существует риск, что за это время реальные потребности пользователя могут измениться и поэтому не будут полностью удовлетворены. Кроме того, возможны ситуации, когда реальные потребности, которые остаются неизменными, но были неправильно или недостаточно полно осознанные пользователями при разработке технического задания, их истинное понимание наступает лишь после ввода системы в эксплуатацию, когда уже поздно вносить серьезные змини.
Спиральная модель жизненного цикла предполагает многократное прохождение одних и тех же стадий разработки, пока созданный продукт не будет удовлетворять заказчика. Эта модель итерационный характер, присущий процессу создания таких сложных искусственных объектов, которыми являются программные средства. На каждой итерации создают действующий прототип, который подвергают критическому оцениванию. На заключительной итерации прототип принимают за окончательный вариант системи.
Спиральная модель свободна от недостатков каскадной модели, поскольку на каждом витке спирали есть возможность убедиться в том, что требования, которые изменились, учтены при разработке очередного прототипа. К недостаткам спиральной модели следует отнести сложность планирования и организации работ, а также значительные затраты ресурсов при разработке крупных проектов. Поэтому его используют в тех случаях, когда система небольшая, но существует некоторая неопределенность относительно требований пользователей. Если проект достаточно большой, то обычно в нем удается выделить ограниченную по объему подсистему, которую действительно целесообразно разрабатывать, используя спиральную модель. Через трудности планирования работ эта модель чаще применяется тогда, когда заказчик, разработчик и пользователь - одна и та же организация или когда продукт разрабатывается для массового споживача.
Метод быстрого прототипа предусматривает разработку в сжатые сроки действующего макета части автоматизированной системы, наиболее критичной к изменениям требований пользователей, а также проведение тестовой эксплуатации макета к разработке полномасштабного образца. Конечно прежде прототипирования подлежит интерфейс с будущей системой. Это позволяет привлечь конечных пользователей к активному сотрудничеству на ранней стадии разработки АС и таким образом избежать доработок законченной системы (стоят дорого), как это часто случается при использовании каскадной модели. Основное назначение прототипирования - облегчить выявление всех требований пользователей. Поэтому, как правило, прототип после разработки технического задания больше не используют и далее модель жизненного цикла совпадает с каскадной. Такой подход, в частности, реализовано в британской технологии SSADM. Предусмотрена британским стандартом разработка действующего прототипа еще больше смягчает недостатки каскадной модели.
Метод последовательного наращивания функций состоит в проектировании и реализации АС поэтапно. На каждом этапе пользователи получают вариант системы со все большим функциональным наполнением. Это позволяет резко сократить время, необходимое для ввода в действие первой очереди АС и начала эксплуатации ее. В результате организация-пользователь довольно скоро начинает испытывать реальный эффект от автоматизации. Поэтому к сильной стороны такого подхода по сравнению с каскадной моделью можно отнести сокращение срока окупаемости. Слабыми сторонами являются трудности планирования управления проектом в сочетании с необходимостью соблюдать открытой архитектуры, часто сильно усложняет задачу разработчика. Метод последовательного наращивания функций достаточно успешно может быть применен при создании АС организационного управления. При этом в первую очередь может быть разработана часть АС, реализующей сравнительно простые информационные задачи, внедрение которых может дать сразу заметный эффект. В состав следующих очередей могут быть включены другие информационные задачи и лишь затем - задачи, требующие выполнения достаточно сложных розрахункив.
Эволюционная модель предусматривает доработку полномасштабного образца автоматизированной системы до уровня качества, удовлетворяющей конечных пользователей, непосредственно в процессе эксплуатации ее. При этом реализацию АС начинают из функций, о которых разработчики имеют достаточно четкое представление. Знания относительно других функций системы уточняют уже после ее частичной сдачи в эксплуатацию. В этом рассматриваемый подход противоположен методу быстрого прототипа, согласно которому разработку начинают по реализации функций, относительно которых у разработчиков есть наибольшие сомнения. При создании сложных АС эволюционный подход позволяет изначально сосредоточиться на достижении высоких эксплуатационных характеристик, таких как надежность, мобильность, модификованисть т.д., почему иногда препятствует разработка быстрых прототипов. Эволюционный подход может быть особенно полезным при разработке систем, в которых работы по созданию программного обеспечения не лежащих на критическом пути общего графика робит.
Повторное использование компонентов является основой так называемого сборочного программирования, что позволяет существенно сократить стоимость и длительность разработки АС, а также повысить его надежность при одновременном сокращении затрат на сопровождение. Наибольший эффект получается тогда, когда значительную часть задач удается сформулировать в терминах относительно небольшого числа подзадач, которым ставится в соответствие стандартные подпрограммы. Тогда разработки очередной задачи сводится к написанию сравнительно несложной программы, что вызывает эти подпрограммы в нужной последовательности и организует между ними обмен данными. Однако уникальные алгоритмы обработки информации или субъективные знания эвристики, которыми пользуются эксперты при решении сложных задач, с помощью стандартных программ описать невозможно. Поэтому модель, основанная на повторном использовании компонентов, является идеализацией и в чистом виде не используется. Время в связи с распространением объектно-ориентированного подхода к разработке АС она приобретает все большее значення.
Автоматизированный синтез программ основан на трансформации спецификаций, составленных на языке высокого уровня, в машинные программы. Согласно развития таких языков менялось и значение, которое вкладывается в понятие «синтез программ». Наиболее высокий уровень присущ так называемым языкам четвертого поколения. Тогда очевидно, что языки «высокого» уровня - это существующие языки представления знаний систем искусственного интеллекта, которые относят к пятому поколению. Таким образом, концепция автоматизированного синтеза программ в ее современном понимании основана на представлении знаний как о предметной области, так и о процессе создания программных средств. В отличие от подходов, рассмотренных выше, реализация этого подхода требует достаточно высоких первоначальных затрат на построение моделей знаний и особенно на создание инструментальных средств для поддержания их, что связано с риском значительного подорожания разработки. Автоматизированный синтез программ по их спецификациями позволяет резко сократить все виды расходов и реализовать высокое качество программного продукта. Поэтому существуют условия, при которых рассматриваемый подход может оказаться экономически весьма эффективным, и задача программной инженерии состоит в том, чтобы найти эти умови.
Рассмотренные выше подходы к разработке АС порождают различные структуры жизненного цикла систем. Так, при последовательном наращивании функций и при эволюционном подходе те или иные части проекта в любой момент времени могут находиться на разных стадиях разработки. В модели, основанной исключительно на повторном использовании компонентов, в структуре жизненного цикла отсутствует стадия реализации, а при автоматизированном синтезе программ выпадают даже две стадии - проектирование и реализация. На самом же состав стадий жизненного цикла останется неизменным, хотя их удельный вес может существенно зминитися.
Если фирма работает на неопределенный круг пользователей, то есть на рынок в целом, или заказчик - негосударственная организация, то выбор модели диктуется только здравым смыслом и желанием заказчика. Последний вряд ли навязывать разработчику свою волю в тех вопросах, где он некомпетентен. Если фирма работает на государственный заказ, то должна будет соблюдать требования госстандарта, т.е. выбрать каскадную модель жизненного цикла, хотя она предполагает жесткую схему, главное преимущество которой - простота контроля за исполнением, достигается иногда за счет снижения качества и эффективности. Из этого следует необходимость совершенствования отечественных стандартов.
Маркетинговые мероприятия на всех этапах разработки информационного продукта и, в частности, на этапе продвижения на рынок, будут зависеть от того, какая модель ЖЦ продукта используется разработчиком. Так, для каскадной модели в рекламе будущего товара можно указывать его конкретные возможности, которые будут в него заложены по требованию заказчика. При использовании модели метода быстрого прототипа можно рекламировать преимущества товара на этапе его потребления, его интерфейса с пользователем. Для модели метода последовательного наращивания функций возможна продажа любого промежуточного варианта (версии) АС с определенным набором функций, которые могут удовлетворить определенного пользователя. То же можно сказать о эволюционную модель, тем более, что дальнейшее развитие АС у каждого пользователя может идти своим путем расширения возможностей.
Поскольку жизненный цикл продукта, разрабатываемого фирмой, тесно связан с жизненным циклом товара, которым станет этот продукт на рынке, то и в дальнейшем, рассматривая рыночные проблемы информационной отрасли, мы будем опираться на приведенные модели жизненного цикла информационных продуктов.
| Классификация информационных продуктов и услуг имеет динамический характер. Ранее | Основной задачей информационных структур является создание и вывод на рынок новых |