Внедрение системы и ее эксплуатация

Внутренние задачи:

Изменение рабочих мест, в соответствии с требованиями новой системы.

Обучение персонала работе с создаваемой системой

Планирование новой организационной структуры, ролей и должностных обязанностей

Подготовка (в экстремальных случаях) к изменениям организационной культуры.

Внешние задачи:

Если создаваемая информационная система подразумевает изменение схем и способов взаимодействия с партнерами по бизнесу (электронный обмен данными, изменение форм документов и т.д.) нельзя забывать о необходимости приложения усилий к подготовке партнеров к работе с элементами ВАШЕЙ информационной системы. Требуются время и средства для того чтобы мотивировать и обеспечить готовность партнеров к взаимодействию.

Задачи переходного периода

Обеспечение миграции от старой системы к новой требует как технических работ (перевод существующих файлов и документов со старых носителей на новые, установка нового оборудования и демонтаж старого и т.д.) так и организационных усилий. Например, для того, чтобы обеспечить непрерывность работ зачастую требуется одновременная эксплуатация в течении какого то времени и старой и новой системы, что фактически удваивает трудозатраты в этот период.

Чем более глобален проект создания новой информационной системы, тем больше круг задач, связанных с ним и тем больше усилий и средств нужно уделять их планированию и реализации для того, чтобы физическая реализация системы смогла начать функционировать в соответствии с заданной эффективностью и сроками.

 

В основе деятельности по созданию и использованию ИС лежит понятие жизненного цикла.

Жизненный цикл – это модель создания и использования ИС, отражающая ее различные состояния, начиная с момента возникновения необходимости в данном комплексе средств и заканчивая моментом его полного выхода из употребления у пользователей.

Опыт создания и использования ИС позволяет условно выделить следующие основные этапы их жизненного цикла:

• анализ – определение того, что должна делать система;

• проектирование – определение того, как система будет делать то, что она должна делать. Проектирование это, прежде всего, спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;

• разработка – создание функциональных компонентов и подсистем по отдельности, соединение подсистем в единое целое;

• тестирование – проверка функционального и параметрического соответствия системы показателям, определенным на этапе анализа ;

• внедрение – установка и ввод системы в действие;

• сопровождение – обеспечение штатного процесса эксплуатации системы на предприятии заказчика.

Этапы разработки, тестирования и внедрения ИС обозначаются единым термином – реализация.

Жизненный цикл образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением дополнительных ограничений и т.п. На каждом этапе жизненного цикла порождается определенный набор технических решений и отражающих их документов, при этом для каждого этапа исходными являются документы и решения, принятые на предыдущем этапе.

 

Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого

подхода обнаруживается ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывается в жесткую схему. В процессе создания ПО возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений.                    

 

Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования ИС, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта.

 

Предложенная методология состоит из семи рассматриваемых этапов, которые, в графическом представлении расположены в виде буквы V в соответствии с уровнями менеджеров, которые должны отвечать за их исполнение:

Инициация проекта

Формулирование стратегического плана развития информационной системы, прерогативой топ-менеджеров. Именно они должны (в виде документов) сформулировать общие бизнес требования к будущей системе. Под создаваемой системой мы можем рассматривать не только вновь создающуюся информационную систему, но и новое состояние модернизируемой в ходе проекта существующей системы. Для успешного осуществления этого этапа, топ-менеджеры должны обеспечить в организации соответствующую среду, отвечающую следующим условиям:

Руководство должно быть уверено в том, что инициируемый проект на самом деле необходим и оно будет уделять его реализации достаточно средств и своего внимания.

Руководители подразделений, также заинтересованы в реализации проекта, их понимание целей и задач проекта совпадает с пониманием топ-менеджеров и обеспечено (в первую очередь организационно) их активное участие на стадиях формирования целей и стратегии.

Все сотрудники организации проинформированы о целях и задачах проекта и их мотивация обеспечит успешное проведение всех, связанных с проектом работ.

В дальнейшем, на стадии внедрения и эксплуатации, именно сравнение этих бизнес-требований с полученными результатами будет являться основой для анализа успеха или неуспеха проекта.

На этом же этапе проводится оценка осуществимости проекта с привлечением различных специалистов (технологов, финансистов, кадровиков и др.) и в случае ее позитивного исхода эти бизнес требования передаются менеджерам подразделений для дальнейшей работы. В случае негативного результата анализа осуществимости, топ-менеджеры должны пересмотреть формулировки бизнес требований с учетом выявленных ограничений или даже пересмотреть стратегический план развития информационных систем организации в целом.

Анализ потребностей

Осуществляется руководителями функциональных подразделений, Имея сформулированные бизнес требования, они, совместно со своими сотрудниками, используя опыт, результаты моделирования организации, модели своих функциональных областей и бизнес-процессов, создают пользовательскую спецификацию создаваемой системы. Пользовательская спецификация описывает:

Какая информация, в каком виде, в какое время и т.д. необходима для эффективного достижения подразделением поставленных бизнес-целей на каждом из рабочих мест.

Как должна быть обработана введенная в систему информация для ее использования на рабочих местах

Какие необходимые исходные данные (что, насколько оперативно, с какой частотой и точностью, и т.д.) должны вводиться в систему.

Пользовательская спецификация будет являться рабочим документом на стадии технического дизайна и, вместе с Планом проверки пригодности созданным на ее основе, инструментом проверки функционирования системы.

В случае выявления невозможности удовлетворения бизнес-требований, по каким либо причинам, осуществляется возврат к стадии инициации проекта для их корректировки.

Технический дизайн

Технический дизайн осуществляется под руководством менеджеров отделов, отвечающих за создание информационных систем (Информационный отдел, исследовательский отдел, На этом этапе создаются:

Системная спецификация (чертежи, схемы, диаграммы, описания технических характеристик и т.д.) системы и ее элементов, которые должны будут обеспечить работу системы в соответствии с пользовательской спецификацией.

Руководства пользователей (инструкции по эксплуатации системы)

План тестирования системы и отдельных ее узлов

Если, по техническим причинам, не удается спроектировать систему, действующую в соответствии с требованиями пользовательской спецификации, осуществляется возврат на этап анализа потребностей для корректировки спецификации.

Создание системы

Собственно создание системы (изготовление компонент, сборка, и т.д.) осуществляется под руководством менеджеров технических служб (производство, информационный отдел, канцелярия и т.д.)

Результатом осуществление этого этапа является система или ее отдельные составляющие, способные выполнять задачи, оговоренные в системной спецификации.

Если их создание оказывается невозможным по техническим причинам, происходит возврат на стадию Технического дизайна.

Техническое тестирование

В ходе технического тестирования, проводимого совместно сотрудниками технических и дизайнерских отделов, проверяется работоспособность системы или ее компонент и их соответствие требованиям пользовательской и технической спецификации в соответствии с Планом тестирования. Если полученный результат неудовлетворителен, то, в соответствии с выявленными причинами, осуществляется возврат, либо на стадию создания системы, либо на стадию технического дизайна.

Функциональное тестирование

Принятые на стадии технического тестирования модули передаются на проверку функционирования пользователями в соответствующие отделы. На этой стадии пользователи, или специальные проверяющие вооруженные Руководствами пользователя, в соответствии с планом тестирования проверяют соответствие элементов системы требованиям пользовательской спецификации. При этом могут использоваться как реальные бизнес-ситуации, так и специально подготовленные задачи. Задачей руководителей подразделений на этом этапе является имитация работы системы в реальных (экстремальных в том числе) условиях для проверки соответствия результатов ее работы сформулированным бизнес-требованиям.

Если проверка показала, что бизнес требования не выполняются, это означает, что неверно были сформулированы пользовательские спецификации (соответствие сформулированым пользовательским спецификациям проверялось на предыдущем этапе) и происходит возврат на стадию Анализа потребностей для внесения изменений в пользовательскую спецификацию.

Создание прототипа.

К созданию прототипа, обычно прибегают в тех случаях, когда невозможно, или сложно получить ясное представление об информационных потребностях будущих пользователей системы. Этот метод подразумевает создание упрощенной модели системы, которая выполняет отдельные функции будущей системы и в процессе опытной эксплуатации уточняются требования к создаваемой системе. Несомненными достоинствами этого подхода являются его пригодность для информационного анализа трудно формализуемых бизнес-процессов. Другим положительным свойством является значительная вовлеченность будущих пользователей в процесс создания системы, которая гарантирует как высокую степень соответствия создаваемой системы реальным нуждам пользователей, так и заинтересованность пользователей в применении результатов проекта, в котором они принимали участие.

Создание прототипа является по сути не самостоятельной методологией, а вариантом, замещающим формальный анализ потребностей в методологии жизненного цикла.

Потенциальные системы

Системы этого класса могут давать наиболее непредсказуемые результаты, как положительные, так и отрицательные. Поэтому, нельзя ограничивать и необходимо поощрять стремления персонала, вовлеченного в работу с ней, к творческим изысканиям и поиску новых путей ее применения с одной стороны. С другой стороны, требуется уделять максимум внимания оценке потенциальных последствий их применения для того, чтобы как можно раньше принять решение о скорейшем развитии или прекращении работ в этом направлении. Как правило, люди, обладающие необходимыми для продуктивной работы с потенциальными системами креативными способностями не являются, в то же время хорошими организаторами и администраторами. Поэтому, команда должна быть составлена как из людей, генерирующих идеи, так и из людей, направляющих эти идеи в русло стратегии организации.

Стратегические системы

Эти системы, в силу своей значимости, должны эксплуатироваться командами, сформированными из людей обладающих способностями к тщательному анализу, планированию и неукоснительному следованию разработанным планам. Но при этом, приоритет должен отдаваться не планам как таковым, а целям, достижению которых они служат. Поэтому, анализ и планирование должны быть неотъемлемыми функциями команды гарантированными соответствующей мотивацией. Только такая команда будет способна гарантированно обеспечить работу системы, обеспечивающую достижение организацией ее стратегических целей.

Ключевые системы

«Контроллер» – наиболее подходящее название для руководителя, отвечающего за работу ключевых систем. Обеспечение качества выполняемых работ и их эффективности должно обеспечиваться, в первую очередь, за счет неукоснительного соблюдения правил работ и следования разработанным процедурам. Основной задачей менеджера на этом участке является достижение стабильности, что не допускает привлечения к руководству людей с задатками предпринимателя.

Вспомогательные системы

При эксплуатации систем этого класса, наиболее оптимальным может считаться «реактивный» подход – ничего не делать до тех пор, пока не возникнет проблема. В данном случае, удовлетворение сиюминутных потребностей клиента (внутреннего или внешнего) более важно, чем прогнозирование и планирование долгосрочных действий. Высшее руководство должно ставить целью управления вспомогательными системами недопущение превращения мелких проблем, возникающих в процессе ее эксплуатации, в серьезные проблемы организации.

 

Процесс создания информационных систем, с точки зрения менеджера должен управляться в рамках существующей (или разработанной в процессе создания информационной системы) организационной структуры соответствующими людьми и в соответствии с политикой, выбор которой, также, может быть осуществлен в зависимости от класса управляемой системы:

Потенциальные системы

Системы этого класса могут давать наиболее непредсказуемые результаты, как положительные, так и отрицательные. Поэтому, нельзя ограничивать и необходимо поощрять стремления персонала, вовлеченного в работу с ней, к творческим изысканиям и поиску новых путей ее применения с одной стороны. С другой стороны, требуется уделять максимум внимания оценке потенциальных последствий их применения для того, чтобы как можно раньше принять решение о скорейшем развитии или прекращении работ в этом направлении. Как правило, люди, обладающие необходимыми для продуктивной работы с потенциальными системами креативными способностями не являются, в то же время хорошими организаторами и администраторами. Поэтому, команда должна быть составлена как из людей, генерирующих идеи, так и из людей, направляющих эти идеи в русло стратегии организации.

Стратегические системы

Эти системы, в силу своей значимости, должны эксплуатироваться командами, сформированными из людей обладающих способностями к тщательному анализу, планированию и неукоснительному следованию разработанным планам. Но при этом, приоритет должен отдаваться не планам как таковым, а целям, достижению которых они служат. Поэтому, анализ и планирование должны быть неотъемлемыми функциями команды гарантированными соответствующей мотивацией. Только такая команда будет способна гарантированно обеспечить работу системы, обеспечивающую достижение организацией ее стратегических целей.

Ключевые системы

«Контроллер» – наиболее подходящее название для руководителя, отвечающего за работу ключевых систем. Обеспечение качества выполняемых работ и их эффективности должно обеспечиваться, в первую очередь, за счет неукоснительного соблюдения правил работ и следования разработанным процедурам. Основной задачей менеджера на этом участке является достижение стабильности, что не допускает привлечения к руководству людей с задатками предпринимателя.

Вспомогательные системы

При эксплуатации систем этого класса, наиболее оптимальным может считаться «реактивный» подход – ничего не делать до тех пор, пока не возникнет проблема. В данном случае, удовлетворение сиюминутных потребностей клиента (внутреннего или внешнего) более важно, чем прогнозирование и планирование долгосрочных действий. Высшее руководство должно ставить целью управления вспомогательными системами недопущение превращения мелких проблем, возникающих в процессе ее эксплуатации, в серьезные проблемы организации.

 

Процесс создания информационных систем, с точки зрения менеджера должен управляться в рамках существующей (или разработанной в процессе создания информационной системы) организационной структуры соответствующими людьми и в соответствии с политикой, выбор которой, также, может быть осуществлен в зависимости от класса управляемой системы:

Потенциальные системы

Системы этого класса могут давать наиболее непредсказуемые результаты, как положительные, так и отрицательные. Поэтому, нельзя ограничивать и необходимо поощрять стремления персонала, вовлеченного в работу с ней, к творческим изысканиям и поиску новых путей ее применения с одной стороны. С другой стороны, требуется уделять максимум внимания оценке потенциальных последствий их применения для того, чтобы как можно раньше принять решение о скорейшем развитии или прекращении работ в этом направлении. Как правило, люди, обладающие необходимыми для продуктивной работы с потенциальными системами креативными способностями не являются, в то же время хорошими организаторами и администраторами. Поэтому, команда должна быть составлена как из людей, генерирующих идеи, так и из людей, направляющих эти идеи в русло стратегии организации.

Стратегические системы

Эти системы, в силу своей значимости, должны эксплуатироваться командами, сформированными из людей обладающих способностями к тщательному анализу, планированию и неукоснительному следованию разработанным планам. Но при этом, приоритет должен отдаваться не планам как таковым, а целям, достижению которых они служат. Поэтому, анализ и планирование должны быть неотъемлемыми функциями команды гарантированными соответствующей мотивацией. Только такая команда будет способна гарантированно обеспечить работу системы, обеспечивающую достижение организацией ее стратегических целей.

Ключевые системы

«Контроллер» – наиболее подходящее название для руководителя, отвечающего за работу ключевых систем. Обеспечение качества выполняемых работ и их эффективности должно обеспечиваться, в первую очередь, за счет неукоснительного соблюдения правил работ и следования разработанным процедурам. Основной задачей менеджера на этом участке является достижение стабильности, что не допускает привлечения к руководству людей с задатками предпринимателя.

Вспомогательные системы

При эксплуатации систем этого класса, наиболее оптимальным может считаться «реактивный» подход – ничего не делать до тех пор, пока не возникнет проблема. В данном случае, удовлетворение сиюминутных потребностей клиента (внутреннего или внешнего) более важно, чем прогнозирование и планирование долгосрочных действий. Высшее руководство должно ставить целью управления вспомогательными системами недопущение превращения мелких проблем, возникающих в процессе ее эксплуатации, в серьезные проблемы организации.

 

Внутренние задачи:

Изменение рабочих мест, в соответствии с требованиями новой системы.

Обучение персонала работе с создаваемой системой

Планирование новой организационной структуры, ролей и должностных обязанностей

Подготовка (в экстремальных случаях) к изменениям организационной культуры.

Внешние задачи:

Если создаваемая информационная система подразумевает изменение схем и способов взаимодействия с партнерами по бизнесу (электронный обмен данными, изменение форм документов и т.д.) нельзя забывать о необходимости приложения усилий к подготовке партнеров к работе с элементами ВАШЕЙ информационной системы. Требуются время и средства для того чтобы мотивировать и обеспечить готовность партнеров к взаимодействию.

Задачи переходного периода

Обеспечение миграции от старой системы к новой требует как технических работ (перевод существующих файлов и документов со старых носителей на новые, установка нового оборудования и демонтаж старого и т.д.) так и организационных усилий. Например, для того, чтобы обеспечить непрерывность работ зачастую требуется одновременная эксплуатация в течении какого то времени и старой и новой системы, что фактически удваивает трудозатраты в этот период.

Чем более глобален проект создания новой информационной системы, тем больше круг задач, связанных с ним и тем больше усилий и средств нужно уделять их планированию и реализации для того, чтобы физическая реализация системы смогла начать функционировать в соответствии с заданной эффективностью и сроками.

 

В основе деятельности по созданию и использованию ИС лежит понятие жизненного цикла.

Жизненный цикл – это модель создания и использования ИС, отражающая ее различные состояния, начиная с момента возникновения необходимости в данном комплексе средств и заканчивая моментом его полного выхода из употребления у пользователей.

Опыт создания и использования ИС позволяет условно выделить следующие основные этапы их жизненного цикла:

• анализ – определение того, что должна делать система;

• проектирование – определение того, как система будет делать то, что она должна делать. Проектирование это, прежде всего, спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;

• разработка – создание функциональных компонентов и подсистем по отдельности, соединение подсистем в единое целое;

• тестирование – проверка функционального и параметрического соответствия системы показателям, определенным на этапе анализа ;

• внедрение – установка и ввод системы в действие;

• сопровождение – обеспечение штатного процесса эксплуатации системы на предприятии заказчика.

Этапы разработки, тестирования и внедрения ИС обозначаются единым термином – реализация.

Жизненный цикл образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением дополнительных ограничений и т.п. На каждом этапе жизненного цикла порождается определенный набор технических решений и отражающих их документов, при этом для каждого этапа исходными являются документы и решения, принятые на предыдущем этапе.

 

Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого

подхода обнаруживается ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывается в жесткую схему. В процессе создания ПО возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений.                    

 

Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования ИС, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта.

 

Предложенная методология состоит из семи рассматриваемых этапов, которые, в графическом представлении расположены в виде буквы V в соответствии с уровнями менеджеров, которые должны отвечать за их исполнение:

Инициация проекта

Формулирование стратегического плана развития информационной системы, прерогативой топ-менеджеров. Именно они должны (в виде документов) сформулировать общие бизнес требования к будущей системе. Под создаваемой системой мы можем рассматривать не только вновь создающуюся информационную систему, но и новое состояние модернизируемой в ходе проекта существующей системы. Для успешного осуществления этого этапа, топ-менеджеры должны обеспечить в организации соответствующую среду, отвечающую следующим условиям:

Руководство должно быть уверено в том, что инициируемый проект на самом деле необходим и оно будет уделять его реализации достаточно средств и своего внимания.

Руководители подразделений, также заинтересованы в реализации проекта, их понимание целей и задач проекта совпадает с пониманием топ-менеджеров и обеспечено (в первую очередь организационно) их активное участие на стадиях формирования целей и стратегии.

Все сотрудники организации проинформированы о целях и задачах проекта и их мотивация обеспечит успешное проведение всех, связанных с проектом работ.

В дальнейшем, на стадии внедрения и эксплуатации, именно сравнение этих бизнес-требований с полученными результатами будет являться основой для анализа успеха или неуспеха проекта.

На этом же этапе проводится оценка осуществимости проекта с привлечением различных специалистов (технологов, финансистов, кадровиков и др.) и в случае ее позитивного исхода эти бизнес требования передаются менеджерам подразделений для дальнейшей работы. В случае негативного результата анализа осуществимости, топ-менеджеры должны пересмотреть формулировки бизнес требований с учетом выявленных ограничений или даже пересмотреть стратегический план развития информационных систем организации в целом.

Анализ потребностей

Осуществляется руководителями функциональных подразделений, Имея сформулированные бизнес требования, они, совместно со своими сотрудниками, используя опыт, результаты моделирования организации, модели своих функциональных областей и бизнес-процессов, создают пользовательскую спецификацию создаваемой системы. Пользовательская спецификация описывает:

Какая информация, в каком виде, в какое время и т.д. необходима для эффективного достижения подразделением поставленных бизнес-целей на каждом из рабочих мест.

Как должна быть обработана введенная в систему информация для ее использования на рабочих местах

Какие необходимые исходные данные (что, насколько оперативно, с какой частотой и точностью, и т.д.) должны вводиться в систему.

Пользовательская спецификация будет являться рабочим документом на стадии технического дизайна и, вместе с Планом проверки пригодности созданным на ее основе, инструментом проверки функционирования системы.

В случае выявления невозможности удовлетворения бизнес-требований, по каким либо причинам, осуществляется возврат к стадии инициации проекта для их корректировки.

Технический дизайн

Технический дизайн осуществляется под руководством менеджеров отделов, отвечающих за создание информационных систем (Информационный отдел, исследовательский отдел, На этом этапе создаются:

Системная спецификация (чертежи, схемы, диаграммы, описания технических характеристик и т.д.) системы и ее элементов, которые должны будут обеспечить работу системы в соответствии с пользовательской спецификацией.

Руководства пользователей (инструкции по эксплуатации системы)

План тестирования системы и отдельных ее узлов

Если, по техническим причинам, не удается спроектировать систему, действующую в соответствии с требованиями пользовательской спецификации, осуществляется возврат на этап анализа потребностей для корректировки спецификации.

Создание системы

Собственно создание системы (изготовление компонент, сборка, и т.д.) осуществляется под руководством менеджеров технических служб (производство, информационный отдел, канцелярия и т.д.)

Результатом осуществление этого этапа является система или ее отдельные составляющие, способные выполнять задачи, оговоренные в системной спецификации.

Если их создание оказывается невозможным по техническим причинам, происходит возврат на стадию Технического дизайна.

Техническое тестирование

В ходе технического тестирования, проводимого совместно сотрудниками технических и дизайнерских отделов, проверяется работоспособность системы или ее компонент и их соответствие требованиям пользовательской и технической спецификации в соответствии с Планом тестирования. Если полученный результат неудовлетворителен, то, в соответствии с выявленными причинами, осуществляется возврат, либо на стадию создания системы, либо на стадию технического дизайна.

Функциональное тестирование

Принятые на стадии технического тестирования модули передаются на проверку функционирования пользователями в соответствующие отделы. На этой стадии пользователи, или специальные проверяющие вооруженные Руководствами пользователя, в соответствии с планом тестирования проверяют соответствие элементов системы требованиям пользовательской спецификации. При этом могут использоваться как реальные бизнес-ситуации, так и специально подготовленные задачи. Задачей руководителей подразделений на этом этапе является имитация работы системы в реальных (экстремальных в том числе) условиях для проверки соответствия результатов ее работы сформулированным бизнес-требованиям.

Если проверка показала, что бизнес требования не выполняются, это означает, что неверно были сформулированы пользовательские спецификации (соответствие сформулированым пользовательским спецификациям проверялось на предыдущем этапе) и происходит возврат на стадию Анализа потребностей для внесения изменений в пользовательскую спецификацию.

Внедрение системы и ее эксплуатация

На этапах внедрения и эксплуатации системы происходит сравнение реально полученных результатов с теми, которые ожидались и были сформулированы в Общих бизнес-требованиях. В случае соответствия результатов требуемым, начинается эксплуатация системы. В противном случае происходит возврат на этап Инициации проекта и возобновляется изучение вопроса о формулировании новых бизнес требований и о начале нового цикла проекта с учетом выявленных ошибок.

Методология жизненного цикла, подразумевающая наличие всех вышеперечисленных этапов, обладает как достоинствами, так и недостатками по сравнению с другими методологиями. Основным достоинством данной методологии является высокая управляемость процесса и высокая вероятность достижения целей. К основным ее недостаткам можно отнести высокую сложность формального анализа бизнес потребностей, особенно для стратегических информационных систем, для которых еще не накоплен опыт их создания и эксплуатации. Другим основным недостатком является дороговизна и большие затраты времени по сравнению с получаемым результатом, особенно, если создаваемая система не предназначена для достижения стратегических целей.

 

Создание прототипа.

К созданию прототипа, обычно прибегают в тех случаях, когда невозможно, или сложно получить ясное представление об информационных потребностях будущих пользователей системы. Этот метод подразумевает создание упрощенной модели системы, которая выполняет отдельные функции будущей системы и в процессе опытной эксплуатации уточняются требования к создаваемой системе. Несомненными достоинствами этого подхода являются его пригодность для информационного анализа трудно формализуемых бизнес-процессов. Другим положительным свойством является значительная вовлеченность будущих пользователей в процесс создания системы, которая гарантирует как высокую степень соответствия создаваемой системы реальным нуждам пользователей, так и заинтересованность пользователей в применении результатов проекта, в котором они принимали участие.

Создание прототипа является по сути не самостоятельной методологией, а вариантом, замещающим формальный анализ потребностей в методологии жизненного цикла.