Архивы: по дате | по разделам | по авторам

«ERP» для программистских проектов

Архив
автор : Михаил Кумсков   21.02.2003

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

В практике разработки программного обеспечения нередко бывают такие ситуации, когда разработчики становятся заложниками своего успеха. Вот, к примеру, небольшая группа бодро разработала и сдала проект. Заказчик доволен, счастлив и говорит: давайте развивать систему, вот вам еще договор, набирайте людей. Разработчики расширяют систему, заказчику пока все нравится. В команде проекта занято уже человек 20–30, но работают они по-старому, как будто их 5–10 человек; есть лидеры, которые ведут разработку в целом и держат все в голове. И все было бы хорошо, если б в один прекрасный момент проект не начинает пробуксовывать. Появляются факторы часто незаметные при выполнении небольших проектов.

 

Первый из них — сложность. Подкрадывается она неожиданно. Например, система ни с того ни с сего начинает работать неустойчиво, то есть она вроде работает, но в некоторые моменты вдруг непонятно почему «падает». Попытки исправить ошибки приводят к тому, что возникают новые ошибки в самых неожиданных местах. Это свидетельствует о том, что проект сделан не по правилам, или, можно сказать, сделан вовсе без проекта, поскольку каждый программист как считал нужным написать свой модуль, так и сделал.
Статистика показывает, что в плохо структурированных программах, где архитектуре уделялось мало внимания, после исправлении одной ошибки в 50 процентах случаев появляется новая ошибка. В подобных ситуациях в какой-то момент приходится принимать решение: систему больше не модернизировать, потому что нет ни времени ни сил исправлять целый веер ошибок, возникающий при внесении в нее даже незначительных изменений.
Второй случай проявления фактора сложности: система вроде бы нормально работает, но с какого-то момента начинает сильно отставать в производительности. Например, сделали файл-серверную систему на Access-е. Все замечательно, данные вносятся легко и быстро, все «летает». Но что значит файл-серверная система? При возрастании размеров таблиц, числа одновременно подключенных пользователей резко возрастает трафик, по сети гоняются одни и те же таблицы… Система начинает падать сначала раз в неделю, потом несколько раз в день, что, в конце концов, требует принятия кардинальных решений по пересмотру архитектуры системы.
Другая сторона возможных неудач развивающихся ИТ-проектов заключается в том, что при управлении командами программистов возникают специфические риски, которым, как правило, не учат менеджеров по управлению «обычными» проектами. Хрестоматийный пример — закон Брукса, не вполне очевидный для тех, кто никогда не участвовал в разработке софта: добавление людей в «горящий» ИТ-проект только замедляет его выполнение. Среди классических рисков при управлении разработкой программных проектов: неправильный выбор архитектуры на ранних этапах; постоянное изменение и детализация требований, необходимость управлять всеми видами изменений.
Надо также учитывать и статистику успешности выполнения программных проектов. Так, например, по данным компании Standish Group, в США в 1998 году только 26% проектов были успешными, 46% — завершились с превышением лимита бюджета или времени, а 28% потерпели полный крах и были прекращены (проценты даны в общей стоимости проекта1). Среди факторов неуспеха в порядке убывания приоритета можно привести: отсутствие вовлечения пользователей в проект, нечеткие цели, неполные требования и спецификации, постоянное изменение требований и спецификаций, ошибки планирования.
В результате мы приходим к выводу, что при создании сложного программного обеспечения необходимо четко и грамотно организовать весь процесс разработки или заказа ПО — от написания технического задания до внедрения и дальнейшего развития. Без использования специальных технологий автоматизирующих процесс разработки, мы неизбежно будем наступать на одни и те же «грабли». Вот лишь основные из них:
 1.  разработчики и пользователи разговаривают на «разных языках», что не позволяет точно перевести неформальные требования в формальную спецификацию системы. В результате трудно создать систему, отвечающую требованиям пользователей. Требуются постоянные переделки и доработки;
 2. отсутствие проектных спецификаций («чертежей») на систему приводит к отсутствию структуры и единой концепции системы. Развитие такой системы трудоемко и ведет к дальнейшему росту «хаотичности»;
 3. трудоемкость документирования в ходе разработки выливается либо в неприемлемые сроки создания точной проектной документации, либо в неприемлемое качество документации, что

влечет за собой проблематичность модификации программного обеспечения;
 4. ошибки на этапах анализа и проектирования часто обнаруживаются только в начале внедрения, когда стоимость их исправления становится на порядок выше;
 5.  подсистемы, разрабатываемые разными группами разработчиков, трудно интегрировать из-за отсутствия или недостаточной проработки общей концепции проекта;
 6.  информационные системы не переносятся с одной платформы на другую, имеют сложное взаимодействие с другими системами и являются тяжелыми для развития.
В результате разработка нового или изменение существующего ПО поглощает слишком много ресурсов. Мировой опыт показывает, что для успешного создания такого ПО необходимы современные методологии, опирающиеся на мощные и удобные инструментальные средства. Осуществление подобных проектов в приемлемые сроки с высоким качеством невозможно без применения инженерных методов — CASE-технологий.
Для грамотной постановки процесса разработки необходимо решить в первую очередь следующие задачи:

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

Главная проблема работы с проектом это организация коммуникации как внутри команды разработчиков, так и их коммуникации с внешним миром. Поэтому кроме индивидуальных средств работы с проектом (компиляторы, отладчики…) у программистов должны быть средства, поддерживающие основные процессы при разработке. Сами процессы определены в ГОСТе 12207 «Информационная технология. Процессы Жизненного Цикла Программных Средств»2. А средства включают инструментарий, методологию и нормативную базу.


 

Одной из популярных методологий, в которой инструментально поддерживаются все этапы жизненного цикла разработки ПО, является Rational Unified Process3 (RUP). Она опирается на методы анализа, проектирования и разработки ПО, методы управления проектами, а также поддерживает лучшие принципы разработки — итеративность, управление требованиями, компонентную архитектуру, визуальное моделирование (UML)4, постоянную проверку качества, контроль изменений.
Эта методология обеспечивает прозрачность и управляемость процесса и позволяет создавать ПО в соответствии с требованиями заказчика на момент его сдачи, и в соответствии с возможностями, предоставляемыми инструментальными средствами (Rational Suite5) поддержки разработки.

Agile programming (Семейство гибких подходов)
Одна из основных идей: разработка — это адаптивный процесс, изменяющийся по мере развития проекта, с учетом уже полученного опыта. Точнее назвать это подходом, а не методологией, которой свойственна процедурность. Считается, что изменения подхода — это не отклонения, которые уводят в сторону и которые необходимо пресекать, но путь, ведущий к цели («низкоуровневая» адаптация). Каждая команда создает свой уникальный подход для каждого проекта — «высокоуровневая» адаптация, поскольку и задачи, и качества разработчиков и их опыт уникальны.
На первый план выходит человек, а не процесс, ответственные квалифицированные разработчики, а не «винтики». Общению через документацию противопоставляется живое общение людей.
Примеры гибких подходов:
  •  Семейство Crystal Алистера Кокберна (Alistair Cockburn) — минимизация дисциплины, максимизация простоты, адаптация процесса перед началом каждой итерации.
  •  ASD (адаптивная разработка) Джима Хайсмита (Jim Highsmith) — активно используются идеи теории хаоса. В основе три перекрывающиеся итеративные фазы — Обдумывание, Сотрудничество, Обучение — взамен «классическим» — Планирование, Проектирование, Конструирование.
  •  FDD (Feature Driven Development) Джеффа де Люка (Jeff De Luca) и Питера Коуда (Peter Coad) — упор на короткие итерации. Схема проекта: разработка общей модели, список свойств, планирование работы над свойством, проектирование свойства, конструирование свойства. Последние два пункта — итерации. Разделение труда: владельцы классов и старшие программисты (координаторы, архитекторы проекта).

В 2001 году идеологи гибких подходов написали Манифест и образовали Agile Alliance. В июне этого года планируется конференция Альянса. Ожидается, что плодотворный обмен идеями поспособствует развитию подходов («метауровневая» адаптация).


Ключевое понятие RUP — use-case6 (сценарий использования), это единица организации всей работы в проекте, то есть единица планирования, проектирования работ, отладки и тестирования. Ключевое потому. что если вы формулируете функциональные требования в системе не в виде сценариев использования, то работать на основе RUP в проекте вы не сможете.
При внедрении RUP ее процессы должны быть адаптированы и к особенностям самой организации-разработчика, и к специфике выполняемых ею конкретных проектов. И первое, что нужно любой организации, — это правильная постановка работы с требованиями. С требований нужно начинать постановку методологии потому, что ошибки в них самые распространенные и наиболее дорогостоящие. Далее необходимо ставить управление изменениями, управление проектом. Так мы можем достичь второго уровня СММ (Capability Maturity Model for Software7), показывающего степень зрелости организации, при которой базовые процессы разработки в полной мере планируются и контролируются.
В RUP включена и методика его внедрения: в работу можно включать только те роли, задачи и артефакты методологии, которые необходимы. Также в него можно вставлять собственные процессы. Кроме того, RUP интересен еще и тем, что он, строго говоря, инвариантен к тому, какой инструмент для управления требованиями, для управления конфигурацией, визуального моделирования будет использован. Например, для управления требованиями необязательно использовать Requisite Pro, входящий в Rational Suite. Для бизнес-моделирования вместо Rational Rose можно использовать любое другое UML-средство, для конфигурационного управления вместо ClearCase — достаточно дорогой системы, вполне подойдет MS SourceSafe и т. д.
Постановка методологии в разрабатывающей организации — достаточно дорогой процесс, он может стоить несколько десятков тысяч долларов, из которых инструментальные средства составляют 60–70% суммы, обучение 10–12%, развертывание и настройка — 5–7%, разработка регламентов, технологий — 10–15%. Методологию на основе RUP целесообразно внедрять в компаниях (проектах) со штатом от тридцати человек, а эффект, по большому счету, заметен уже в командах, численностью от десяти человек.
Грамотная постановка методологии сродни настройке ERP-системы, впрочем RUP и Rational Suite это и есть ERP-система в области разработки программного обеспечения со всеми вытекающими отсюда рисками при ее внедрении. Полное внедрение методологии и технологии работ может занимать от года до трех лет8


1www.softwaremag.com/archive/1999dec/Success.html
2 Заказ стандартов по Интернету (см. www.interstandard.gost.ru).
3 www.rational.com/products/rup/index.jsp.
4 www.rational.com/uml/index.jsp.
5 www.rational.com/products/entstudio/index.jsp.
6 www.therationaledge.com/content/dec_00/t_usecase.html.
7 www.sei.cmu.edu/cmm/cmm.html
8 см. электронный журнал по теме — www.therationaledge.com

© ООО "Компьютерра-Онлайн", 1997-2024
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.