необходимость документировать каждое действие разработчиков;
множество рабочих продуктов (в первую очередь документов), создаваемых в бюрократической атмосфере;
отсутствие гибкости;
детерминированность (долгосрочное детальное планирование и предсказуемость всех видов деятельности, а также распределение человеческих ресурсов на длительный срок, охватывающий большую часть проекта.
Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах «быстрой разработки ПО.
Современные тенденции в программной инженерии
Современные тенденции в программной инженерии
В начале 2001 года века ряд ведущих специалистов в области программной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайсмит, Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки ПО» (Agile Alliances Manifesto) и заключающихся в следующем:
индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;
работающее ПО ценится выше всеобъемлющей документации;
сотрудничество с заказчиками ценится выше формальных договоров;
реагирование на изменения ценится выше строгого следования плану.
При таком подходе технология занимает в процессе создания ПО вполне определенное место и повышает эффективность деятельности разработчиков при наличии следующих условий:
технология позволяет людям легче выразить свои мысли;
технология выполняет задачи, невыполнимые вручную;
технология автоматизирует утомительные и подверженные ошибкам действия;
технология облегчает общение между людьми.
Технология не должна действовать против характера культурных ценностей и познавательной способности человека.
Однако при всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов Алистер Коберн ввел два параметра критичность и масштаб. Критичность определяется последствиями, вызываемыми дефектами в ПО. Ее уровень может иметь одно из четырех значений:
C дефекты вызывают потерю удобства;
D дефекты вызывают потерю возместимых средств (материальных или финансовых);
E дефекты вызывают потерю невозместимых средств;
L дефекты создают угрозу человеческой жизни.
Масштаб определяется количеством разработчиков, участвующих в проекте:
от 1 до 6 человек малый масштаб;
от 6 до 20 человек средний масштаб;
свыше 20 человек большой масштаб.
По оценке Коберна, быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критичностью (C или D). Общие принципы оценки технологий в таких проектах заключаются в следующем:
интерактивное общение лицом к лицу это самый дешевый и быстрый способ обмена информацией;
избыточная «тяжесть» технологии стоит дорого;
более многочисленные команды требуют более «тяжелых» и формальных технологий;
большая формальность подходит для проектов с большей критичностью;
возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах;
дисциплина, умение и понимание противостоят процессу, формальности и документированию;
потеря эффективности в некритических видах деятельности вполне допустима.
Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является «Экстремальное программирование» (Extreme Programming XP). Этот метод предназначен для небольших компактных команд, нацеленных на получение как можно более высокого качества и продуктивности, что достигается посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению, навыкам, дисциплине, пониманию.
Однако задача поиска повторяемого, предсказуемого процесса или методологии, которые бы улучшили продуктивность, качество и надёжность разработки до сих пор не решена. Одни подходы делают акцент на систематизации и формализации процессов. Другие ставят во главу угла методы управления проектами и методы программной инженерии. Третьи исходят из необходимости постоянного контроля со стороны заказчика.
При выборе методологии разработки программного обеспечения следует руководствоваться тем, что сложность методологии сравнима со сложностью структуры программного продукта, и неоправданная для продукта данной сложности сложность методологии только неоправданно увеличит стоимость разработки.
Инструментальные средства бизнес-моделирования
Моделирование бизнес-процессов является важной составной частью проектов по созданию крупномасштабных систем ПО организационно-экономических систем. Отсутствие таких моделей является одной из главных причин неудач многих проектов.
Моделирование бизнес-процессов является важной составной частью проектов по созданию крупномасштабных систем ПО организационно-экономических систем. Отсутствие таких моделей является одной из главных причин неудач многих проектов.
Назначением будущего ПО организационно-экономических систем является, в первую очередь, решение проблем бизнеса. Требования к ПО формируются на основе бизнес-модели, а критерии проектирования систем прежде всего основываются на наиболее полном их удовлетворении.
Модели бизнес-процессов являются не просто промежуточным результатом, используемым консультантом для выработки каких-либо рекомендаций и заключений. Они представляют собой самостоятельный результат, имеющий большое практическое значение.
Бизнес-моделирование (деловое моделирование) деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) и указание связей между ними. Требования к формируемым моделям и их соответствующее содержание определяются целями моделирования.
Бизнес-моделированием также называют дисциплину и отдельный подпроцесс в процессе разработки программного обеспечения, в котором описывается деятельность компании и определяются требования к системе. То есть те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой информационной системе.
Нередко бизнес-моделирование сочетается с управленческим консалтингом, призванным выработать рекомендации по совершенствованию системы управления. В этом случае производится:
анализ опыта других организаций (близких по профилю, отрасли, рынку, методам ведения бизнеса и т.д.), связанного с внедрением информационных технологий;
определение целей проекта в контексте повышения эффективности решения существующих управленческих задач и возможности внедрения принципиально новых управленческих технологий;
определение укрупненных показателей эффективности бизнес-процессов, подлежащих автоматизации (целевых бизнес-процессов), и формирование первоначальных критериев успешности проекта реорганизации управления на основе внедрения новых программных средств;
определение приемлемого объема финансирования проекта.
При проведении управленческого консалтинга, направленного на выработку рекомендаций по совершенствованию системы управления предприятием проводятся следующие работы.
Диагностика текущего состояния и тенденций развития предприятия.
Выявление ключевых внутренних и внешних проблем.
Анализ баланса сил, интересов и целей, распределения полномочий и ответственности среди участников (учредителей) и руководства предприятия и разработка рекомендаций по их корректировке.
Подготовка рекомендаций по целевому планированию.
Разработка предложений по корректировке стратегии развития организации.
Анализ функционирования основных подсистем управления организацией и подготовка предложений по их совершенствованию.
Анализ соответствия организационно-функциональной структуры организации стратегии ее развития и подготовка рекомендаций по совершенствованию оргструктуры.
Выявление проблем информационного обеспечения системы управления организацией и оценка затрат на их решение.
На сегодняшний день в моделировании бизнес-процессов преобладает процессный подход. Его основной принцип заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. При этом, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.
Наиболее популярными специализированными инструментами описания бизнес-процессов являются:
Business studio (см. Приложение 1);
ARIS (см. Приложение 2);
Casewise Corporate Modeler Suite (см. Приложение 3);
AllFusion Process Modeler (см. Приложение 4);
PayDox (см. Приложение 5).
Наряду с ними применяются инструменты для описания, имитации и анимации бизнес-процессов:
AnyLogic (см. Приложение 6);
GPSS;
IBM WebSphere Business Modeler.
Жизненный цикл программной системы
Жизненный цикл программного обеспечения (ПО) это период времени с момента принятия решения о необходимости создания программной системы до момента ее полного изъятия из эксплуатации.
Основным международным стандартом определения жизненного цикла ПО является ISO/IEC 12207:2008 «System and software engineering Software life cycle processes» (российский аналог ГОСТ Р ИСО/МЭК 122072010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств). Наряду с ним в России применяется ГОСТ 34.60190.
ГОСТ 34.60190
Стандарт ГОСТ 34.60190 был создан еще в СССР и предусматривает следующие стадии и этапы создания автоматизированной системы (АС).
1. Формирование требований.
Обследование объекта и обоснование необходимости создания АС.
Формирование требований пользователя к АС.
Оформление отчета о выполнении работ и заявки на разработку АС.
Разработка концепции АС.
Изучение объекта.
Проведение необходимых научно-исследовательских работ.
Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей.
Оформление отчета о проделанной работе.
2. Техническое задание разработка и утверждение технического задания на создание АС.