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

– отсутствие гибкости;

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

Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах «быстрой разработки ПО.

Современные тенденции в программной инженерии

В начале 2001 года века ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки ПО» (Agile Alliance’s Manifesto) и заключающихся в следующем:

– индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;

– работающее ПО ценится выше всеобъемлющей документации;

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

– реагирование на изменения ценится выше строгого следования плану.

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

– технология позволяет людям легче выразить свои мысли;

– технология выполняет задачи, невыполнимые вручную;

– технология автоматизирует утомительные и подверженные ошибкам действия;

– технология облегчает общение между людьми.

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

Однако при всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра – критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами в ПО. Ее уровень может иметь одно из четырех значений:

– C – дефекты вызывают потерю удобства;

– D – дефекты вызывают потерю возместимых средств (материальных или финансовых);

– E – дефекты вызывают потерю невозместимых средств;

– L – дефекты создают угрозу человеческой жизни.

Масштаб определяется количеством разработчиков, участвующих в проекте:

– от 1 до 6 человек – малый масштаб;

– от 6 до 20 человек – средний масштаб;

– свыше 20 человек – большой масштаб.

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

– интерактивное общение лицом к лицу – это самый дешевый и быстрый способ обмена информацией;

– избыточная «тяжесть» технологии стоит дорого;

– более многочисленные команды требуют более «тяжелых» и формальных технологий;

– большая формальность подходит для проектов с большей критичностью;

– возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;

– дисциплина, умение и понимание противостоят процессу, формальности и документированию;

– потеря эффективности в некритических видах деятельности вполне допустима.

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

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

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

Инструментальные средства бизнес-моделирования

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

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

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

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

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

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

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

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

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

– определение приемлемого объема финансирования проекта.

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

– Диагностика текущего состояния и тенденций развития предприятия.

– Выявление ключевых внутренних и внешних проблем.

– Анализ баланса сил, интересов и целей, распределения полномочий и ответственности среди участников (учредителей) и руководства предприятия и разработка рекомендаций по их корректировке.