 |
Задачи переходного периода
|
|
|
|
Обеспечение миграции от старой системы к новой требует как технических работ (перевод существующих файлов и документов со старых носителей на новые, установка нового оборудования и демонтаж старого и т.д.) так и организационных усилий. Например, для того, чтобы обеспечить непрерывность работ зачастую требуется одновременная эксплуатация в течении какого то времени и старой и новой системы, что фактически удваивает трудозатраты в этот период.
Чем более глобален проект создания новой информационной системы, тем больше круг задач, связанных с ним и тем больше усилий и средств нужно уделять их планированию и реализации для того, чтобы физическая реализация системы смогла начать функционировать в соответствии с заданной эффективностью и сроками.
В основе деятельности по созданию и использованию ИС лежит понятие жизненного цикла.
Жизненный цикл – это модель создания и использования ИС, отражающая ее различные состояния, начиная с момента возникновения необходимости в данном комплексе средств и заканчивая моментом его полного выхода из употребления у пользователей.
Опыт создания и использования ИС позволяет условно выделить следующие основные этапы их жизненного цикла:
• анализ – определение того, что должна делать система;
• проектирование – определение того, как система будет делать то, что она должна делать. Проектирование это, прежде всего, спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;
• разработка – создание функциональных компонентов и подсистем по отдельности, соединение подсистем в единое целое;
• тестирование – проверка функционального и параметрического соответствия системы показателям, определенным на этапе анализа;
|
|
|
• внедрение – установка и ввод системы в действие;
• сопровождение – обеспечение штатного процесса эксплуатации системы на предприятии заказчика.
Этапы разработки, тестирования и внедрения ИС обозначаются единым термином – реализация.
Жизненный цикл образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением дополнительных ограничений и т.п. На каждом этапе жизненного цикла порождается определенный набор технических решений и отражающих их документов, при этом для каждого этапа исходными являются документы и решения, принятые на предыдущем этапе.
Тщательное, детализированное планирование с учетом лучшего опыта, методик и стандартов, позволяет избежать проблем на стадии создания и добиться эффективной эксплуатации создаваемых систем.
Напротив, недостаточное планирование приводит к постоянным корректировкам задания в процессе создания систем, превышению бюджетов и неадекватным, дорогостоящим в эксплуатации результатам.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого
подхода обнаруживается ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывается в жесткую схему. В процессе создания ПО возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. 
|
|
|
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования ИС, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта.
Предложенная методология состоит из семи рассматриваемых этапов, которые, в графическом представлении расположены в виде буквы V в соответствии с уровнями менеджеров, которые должны отвечать за их исполнение:
Инициация проекта
Формулирование стратегического плана развития информационной системы, также как и инициация действий по его реализации является прерогативой топ-менеджеров. Именно они должны (в виде документов) сформулировать общие бизнес требования к будущей системе. Под создаваемой системой мы можем рассматривать не только вновь создающуюся информационную систему, но и новое состояние модернизируемой в ходе проекта существующей системы. Для успешного осуществления этого этапа, топ-менеджеры должны обеспечить в организации соответствующую среду, отвечающую следующим условиям:
Руководство должно быть уверено в том, что инициируемый проект на самом деле необходим и оно будет уделять его реализации достаточно средств и своего внимания.
Руководители подразделений, также заинтересованы в реализации проекта, их понимание целей и задач проекта совпадает с пониманием топ-менеджеров и обеспечено (в первую очередь организационно) их активное участие на стадиях формирования целей и стратегии.
Все сотрудники организации проинформированы о целях и задачах проекта и их мотивация обеспечит успешное проведение всех, связанных с проектом работ.
Сформулированные бизнес требования не должны быть привязаны к какой-либо из технологий. Их основное назначение – обрисовать ЧТО создаваемая информационная система должна обеспечить организации и какие преимущества (в тех же терминах, которые используются в стратегическом плане организации) организация должна получить в результате реализации этого проекта. В дальнейшем, на стадии внедрения и эксплуатации, именно сравнение этих бизнес-требований с полученными результатами будет являться основой для анализа успеха или неуспеха проекта.
|
|
|
На этом же этапе проводится оценка осуществимости проекта с привлечением различных специалистов (технологов, финансистов, кадровиков и др.) и в случае ее позитивного исхода эти бизнес требования передаются менеджерам подразделений для дальнейшей работы. В случае негативного результата анализа осуществимости, топ-менеджеры должны пересмотреть формулировки бизнес требований с учетом выявленных ограничений или даже пересмотреть стратегический план развития информационных систем организации в целом.
Анализ потребностей
Осуществляется руководителями функциональных подразделений, являющихся объектами изменений, связанных с созданием новой информационной системы. Имея сформулированные бизнес требования, они, совместно со своими сотрудниками, используя опыт, результаты моделирования организации, модели своих функциональных областей и бизнес-процессов, создают пользовательскую спецификацию создаваемой системы. Пользовательская спецификация описывает:
Какая информация, в каком виде, в какое время и т.д. необходима для эффективного достижения подразделением поставленных бизнес-целей на каждом из рабочих мест.
Как должна быть обработана введенная в систему информация для ее использования на рабочих местах
Какие необходимые исходные данные (что, насколько оперативно, с какой частотой и точностью, и т.д.) должны вводиться в систему.
Пользовательская спецификация будет являться рабочим документом на стадии технического дизайна и, вместе с Планом проверки пригодности созданным на ее основе, инструментом проверки функционирования системы.
|
|
|
В случае выявления невозможности удовлетворения бизнес-требований, по каким либо причинам, осуществляется возврат к стадии инициации проекта для их корректировки.
На этой стадии руководители подразделений должны учитывать не только моменты связанные с работой новой системы в рамках своего подразделения, но и изменения, которые потребуется внести в работу других подразделений и партнеров по бизнесу.
Технический дизайн
Технический дизайн осуществляется под руководством менеджеров отделов, отвечающих за создание информационных систем (Информационный отдел, исследовательский отдел, отдел организации документооборота и делопроизводства и т.д.)
На основании пользовательской спецификации, с применением методик и средств технического и системного дизайна, на этом этапе создаются:
Системная спецификация (чертежи, схемы, диаграммы, описания технических характеристик и т.д.) системы и ее элементов, которые должны будут обеспечить работу системы в соответствии с пользовательской спецификацией.
Руководства пользователей (инструкции по эксплуатации системы)
План тестирования системы и отдельных ее узлов
Если, по техническим причинам, не удается спроектировать систему, действующую в соответствии с требованиями пользовательской спецификации, осуществляется возврат на этап анализа потребностей для корректировки спецификации.
Создание системы
Собственно создание системы (изготовление компонент, сборка, и т.д.) осуществляется под руководством менеджеров технических служб (производство, информационный отдел, канцелярия и т.д.)
Результатом осуществление этого этапа является система или ее отдельные составляющие, способные выполнять задачи, оговоренные в системной спецификации.
Если их создание оказывается невозможным по техническим причинам, происходит возврат на стадию Технического дизайна.
Техническое тестирование
В ходе технического тестирования, проводимого совместно сотрудниками технических и дизайнерских отделов, проверяется работоспособность системы или ее компонент и их соответствие требованиям пользовательской и технической спецификации в соответствии с Планом тестирования. Если полученный результат неудовлетворителен, то, в соответствии с выявленными причинами, осуществляется возврат, либо на стадию создания системы, либо на стадию технического дизайна.
|
|
|
