Управление проектами информатизации

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

5.4.2. Календарный план  как модель жизненного  цикла программного

обеспечения

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

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

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

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

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

Таблица 5.2. 

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

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

     Распределение технических ресурсов и задание  сроков их предоставления – содержание столбца 5. Здесь указывается необходимая для выполнения задания техническая, а в ряде случаев и программная база. Иногда этот раздел дополняется сведениями о лицах, отвечающих за выполнение указываемых требований. Это удобно как для менеджера, так и для ответственных исполнителей: наглядно видны нарушения поставок (несоответствия между плановыми и фактическими сроками). Полезным расширением состава сведений столбца 5 является включение в него информации о зависимости работ внутри проекта, т.е. перечисление заданий (в том числе, ссылки на другие строки данного календарного плана), без выполнения которых осуществимость планируемых работ нарушается. Отслеживание зависимостей работ – это более содержательная задача выполнения проекта по сравнению с тем, что можно получить через только что указанное расширение календарного плана, и ей в дальнейшем будет уделено внимание. Схема календарного плана пытается охватить все аспекты, которые нужно учитывать при выделении работ и отслеживании сроков их выполнения. Однако абсолютной точности здесь добиться не удается. Рассмотренные и другие подобные расширения схемы призваны компенсировать недостающие элементы технологии управления. В частности, они иллюстрируют возможность вынесения на уровень работы с календарным планом элементов сетевого планирования и оперативного использования их в управленческой деятельности. Но предусмотреть расширения схемы так, чтобы полностью удовлетворить все потребности управления в статической картине календарно

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

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

5.4.3. Спиральная модель  ЖЦ

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

     Для преодоления этих недостатков используются инкрементная и эволюционная стратегии разработки ПО.

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

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

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

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

     Модель  расширения охвата прикладной области  совсем не претендует на инструментальность. Поэтому обсуждать эти свойства для данной модели мы не будем.

5.5. Современные средства разработки ПС

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

Средства  управления требованиями

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

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

     Из  наиболее часто применяющихся в  мире средств управления требованиями следует отметить Rational Requisite Pro (IBM, www.ibm.com), Borland CaliberRM (Borland, www.borland.com) и Telelogic DOORS (Telelogic, www.telelogic.com). Эти продукты обладают теми или иными средствами интеграции с другими инструментами поддержки жизненного цикла приложений и позволяют генерировать различные документы, содержащие требования к продукту (например, техническое задание или его аналоги). Отметим, что указанные категории инструментов применяются, как правило, в компаниях-разработчиках или в отделах разработки, хотя иногда заказчикам предоставляется упрощенный интерфейс для доступа к хранилищу требований (например, с помощью Web-интерфейса).

Средства  моделирования бизнес-процессов, приложений и данных

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

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

     К наиболее известным средствам моделирования  и проектирования относятся:

     • AIIFusion Modelling Suite (Computer Associates, www.cai.com), состоящий из нескольких различных инструментов моделирования;

     • Oracle Designer, представляющий собой комплексный инструмент, осуществляющий все перечисленные виды моделирования;

     • Sybase PowerDesigner, представляющий собой инструмент, в состав которого входят средства создания моделей и объектно-ориентированного моделирования;

     • System Architect (Popkm Software), позволяющий осуществлять проектирование данных и структурное моделирование, а также генерировать код клиентских приложений для ряда средств разработки;

     • Visio (Microsoft, www.microsoft.com), представляющий собой универсальное средство моделирования данных и приложений (ориентированное главным образом на СУБД и средства разработки производства самой Microsoft);

     • Rational Rose и Rational XDE Professional (IBM) – популярные средства объектно-ориентированного UML-моделирования приложений, обладающие средствами интеграции как с другими инструментами самой IBM, так и со средствами разработки некоторых других производителей.

     • Together (Borland) – средство UML-моделирования, обладающее на данный момент наиболее совершенными средствами интеграции с различными средствами разработки как компании Borland, так и других производителей (в частности, Microsoft).