другие сайты академии айти
Электронное обучение Ресурсы для обучения в любой точке мира, в удобное время
ООО «Электронные образовательные ресурсы». ГК АйТи Услуги для корпоративных заказчиков по разработке электронного образовательного контента и организации обучения
Интернет-магазин Здесь можно купить наши спецпредложения
С компьютером на «ты»! Бесплатное открытое онлайн обучение для всех
Свободное программное обеспечение в школах Информационно-образовательный портал
Электронные образовательные ресурсы для учителей Информационно-образовательный портал
Энергосбережение и энергоэффективность Информационно-образовательный портал
Мероприятия
Персональные данные: что год грядущий нам готовит
Бесплатный вебинар в записи. Смотрите в любое время.
Роль дополнительного профессионального образования в импортозамещении – 2017
Круглый стол для Российской Ассоциации Бизнес образования

ERP для программистов


3 Февраля 2003 года

ERP для программистов

Михаил Кумсков - Компьютерра

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

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

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

Второй случай проявления фактора сложности: система вроде бы нормально работает, но с какого-то момента начинает сильно отставать в производительности. Например, сделали файл-серверную систему на Access-е. Все замечательно, данные вносятся легко и быстро, все “летает”. Но что значит файл-серверная система? При возрастании размеров таблиц, числа одновременно подключенных пользователей резко возрастает сетевой трафик, гоняются все время одни и те же таблицы… Система начинает падать сначала раз в неделю, потом несколько раз в день, что, в конце концов, требует принятия кардинальных решений.

Другая сторона возможных неудач развивающихся ИТ-проектов заключается в том, что при управлении командами программистов возникают специфические риски, которым, как правило, не учат менеджеров по управлению “обычными” проектами. Хрестоматийный пример – закон Брукса, не вполне очевидный для тех, кто никогда не участвовал в разработке софта: добавление людей в “горящий” ИТ-проект только замедляет его выполнение. Среди классических рисков при управлении разработкой программных проектов: неправильный выбор архитектуры на ранних этапах; постоянное изменение и детализация требований, необходимость управлять всеми видами изменений.

Надо также учитывать и статистику успешности выполнения программных проектов. Так, например, по данным компании Standish Group в США в 1998 году только 26% проектов были успешными, 46% - завершились с превышением лимита бюджета или времени, а 28% потерпели полный крах и были прекращены. Среди факторов провала: отсутствие вовлечения пользователей в проект, нечеткие цели, неполные требования и спецификации, постоянное изменение требований и спецификаций, ошибки планирования.

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

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

· отсутствие проектных спецификаций (“чертежей”) на систему приводит к отсутствию структуры и единой концепции системы. Развитие такой системы трудоемко и ведет к дальнейшему росту “хаотичности”;

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

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

· подсистемы, разрабатываемые разными группами разработчиков, трудно интегрировать из-за отсутствия или недостаточной проработки общей концепции проекта;

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

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

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

- Как преодолеть разрыв между постановкой и реализацией задачи;

- Как обеспечить прозрачность проекта и его хода для заказчика и подрядчиков;

- Как автоматизировать достоверный учет и отчетность о ходе работ;

- Как сформировать и оценивать метрики проекта для постепенного роста качества планирования и точности оценки проектов;

- Как оценить качество результата.

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

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

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

Ключевое понятие RUP – use-case (сценарий использования), это единица организации всей работы в проекте, то есть единица планирования, проектирования работ, отладки и тестирования.

При внедрении RUP ее процессы должны быть адаптированы и к особенностям самой организации-разработчика, и к специфике выполняемых ею конкретных проектов. И первое что нужно любой организации – это правильная постановка работы с требованиями, которые нужны руководителю, чтобы планировать проект, проектировщикам, чтобы проектировать, тестировщикам, чтобы проверять их выполнение. С требований нужно начинать постановку методологии потому, что ошибки в них самые распространенныеинаиболее дорогостоящие. Далее необходимо ставить управление изменениями, управление проектом. Так мы достигаем второго уровня СММ (Capability Maturity Model), показывающего степень зрелости организации, при которой базовые процессы разработки в полной мере планируются и контролируются.

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

Кроме того, RUP интересен еще и тем, что все указания на использование инструментария от самой компании Rational собраны в одном месте, то есть RUP, строго говоря, инвариантен к тому, какой инструмент для управления требованиями, для управления конфигурацией, визуального моделирования будет использован. Например, для управления требованиями необязательно использовать Requisite Pro, входящий в Rational Suite. Для бизнес-моделирования вместо Rational Rose можно использовать любое другое UML-средство, вместо ClearCase (достаточно дорогой системы) вполне подойдет MS SourceSafe и т.д.

Постановка методологии — это достаточно дорогой процесс, десятки тысяч долларов, из которых инструментальные средства занимают 60-70% суммы, обучение 10-15%, развертывание и настройка – 5-10%, разработка регламентов, технологий – 10-15%. Методологию RUP целесообразно внедрять в компаниях от 30 человек, а, по большому счету, эффект заметен уже в командах от 10 человек.

Грамотная постановка методологии сродни настройке ERP-системы, впрочем, RUP и Rational Suite это и есть ERP-система в области разработки программного обеспечения со всеми вытекающими отсюда рисками. И ее полное внедрение занимает приблизительно 2-3 года.