Методология доработки информационной системы

При планировании процесса доработки ИС важно не только оценить длительность работы, но и представлять себе соотноше ние длительности различных стадий процесса. Так, например, по данным компании Rational Software, распределение времени и объема работ по стадиям представлено в таблице.

Такое распределение справедливо для проекта, имеющего следующие характеристики:

• — средний размер проекта и средний объем работ;
• — незначительное число рисков и нововведений;
• — нахождение в начальном цикле разработки;
• — отсутствие предопределенной архитектуры.

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

• 1) Если отсутствует архитектура, предусматривается примене ние новых (или незнакомых) технологий и (или) имеются жесткие ограничения производительности, значительное число технических рисков, а персонал большей частью сос тоит из новичков, — увеличивается стадия разработки отдельных элементов.
• 2) Если проект представляет собой модернизацию существующей системы и в архитектуру не вносятся значительные изменения — уменьшаются стадии разработ ки и внедрения кода в систему.
• 3) Если нужно быстро предоставить готовую систему заказчику и спланировать постепенное заверше ние доработки — уменьшается стадия внедрения кода и увеличивается стадия аналитических проверок.
• 4) Если затруднено внедрение, например, при замещении од ной системы другой без прерывания эксплуатации или при необходимости сертификации (в таких областях, как меди цинское оборудование, ядерная промышленность или авиа ционная электроника), — увеличивается стадия внедрения и изменения и разработка отдельных элементов.

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

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

• 1) Группа из пяти человек может выполнить некоторое плани рование в понедельник утром, наблюдать за ходом проекта и перераспределять задания во время ежедневных совместных обедов, начать конструирование во вторник, а завершить итерацию в пятницу вечером.
• 2) Если попытаться применить этот сценарий для группы из 20 человек, то это окажется затруднительным. Распределение работы, синхронизация подгрупп и интеграция будут зани мать больше времени. В этом случае итерация может занять три-четыре недели.
• 3) Если же группа будет состоять из 40 человек, то только неде ля уйдет на прохождение указаний от руководства к исполни телям. Нужны промежуточные уровни управления; кроме то го, достижение общего понимания целей потребует большей формальности и документирования. В этом случае разумной продолжительностью итерации будет уже три месяца.

Именно поэтому компания ООО «Руфокс» выделила на данный проект три человека, а четвертый сотрудник — студент данной выпускной квалификационной работы.

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

После того как определена приемлемая длительность итера ции, следует определить число итераций на каждой стадии.

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

На стадии разработки нужна, как минимум, одна итерация. Если отсутствует начальная архитектура и нужно адаптироваться к новым инструментальным средствам, технологиям, платформе или языку программирования, то следует планировать две—три итерации. В данной ИС используется три итерации, так как внедряется новый идейных механизм, новые услуги и средства Adobe Flash.

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

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

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

Таким образом, можно принять в качестве эмпирического правила, что средний итерационный проект включает 6 + 3 ите рации.

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

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

Большинство моделей для определения трудоемкости доработки веб-системы могут быть сведены к функции пяти основных параметров: размера конечного результата, особенностей процесса, возможностей персонала, среды и требуемого ка чества продукта. [8].

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

Технология проектирования определяется как совокупность трех составляющих:

• — пошаговой процедуры, определяющей последовательность технологических операций проектирования.
• — критериев и правил, используемых для оценки результатов выполнения технологических операций;
• — нотаций (графических и текстовых средств), используемых для описания проектируемой системы.

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

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

• 1. Технология должна поддерживать полный жизненный цикл программного обеспечения (ЖЦ ПО).
• 2. Технология должна обеспечивать гарантированное достижение целей разработки информационной системы с заданным качеством и в установленное время.
• 3. Технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (то есть возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных информационных систем показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций.
• 4. Технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (от трех до семи человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей.
• 5. Технология должна обеспечивать минимальное время получения работоспособной информационной системы. Речь идет не о сроках готовности всей информационной системы, а о сроках реализации отдельных подсистем. Реализация информационной системы в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам.
• 6. Технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта.