Современные подходы к управлению проектом

Став бригадиром, я упростил этот процесс до мыслимого предела.
Б. Ерофеев. " Москва - Петушки"

Продолжающиеся непрерывные неудачи в крупных программных проектах заставили министерство обороны США сформировать подразделение, которое получило название Сеть менеджеров по разработке программного обеспечения (Software Program Managers Network - SPMN) (http: //www.spmn.com). Для этой организации были сформулированы четыре главных цели ее работы.

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

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

Перечислим основные практики.

• Формальное управление рисками. Рекомендуется постоянно вести и анализировать списки основных важнейших рисков. У сотрудников не должно быть никаких иллюзий о допустимости рисков.
• Согласованность интерфейсов. Интерфейсы - необходимая часть архитектуры. Чем позже будут определены соглашения об интерфейсах, тем больше вероятность того, что систему придется проектировать заново.
• Формальные проверки проекта. Экспертизы, проверки, сквозной контроль - все те действия, которые позволяют устранить ошибки как можно раньше.
• Планирование и управление на основе метрик. В основу планов и оценок должны быть положены числовые оценки - метрики, накопленные в предыдущих проектах.
• Контроль качества на детальном уровне. Промежуточные итоги должны подводиться еженедельно или даже ежедневно.
• Свободный доступ к информации о ходе проекта. Проект будет испытывать большие трудности, если менеджер скрывает от остальной команды информацию о состоянии проекта.
• Отслеживание причин возникновения ошибок для достижения высокого качества. Ошибки должны быть формально отслеживаемы, каждый случай обнаружения и устранения ошибки должен быть обязательно документирован.
• Конфигурационное управление. Использование систем управления исходными кодами, позволяющих отслеживать изменения и дающих возможность вернуться к предыдущим версиям.
• Ответственность и подотчетность руководства перед сотрудниками. Такая мотивация сотрудников может значительно повысить производительность труда программистов.

2.3. Анализ требований и проектирование

2.3.1. Введение в анализ требований и проектирование

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

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

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

Проектирование должно проводиться на двух уровнях:

• Проектирование архитектуры (проектирование системы, проектирование " в большом" ).
• Детальное проектирование (проектирование модулей, проектирование " в малом" ).

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

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

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

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

В основе ведения процессов анализа и проектирования лежат методы, поддерживаемые языками и системами. Методы, объединенные в некоторую совокупность (комбинацию), образуют подходы к анализу и проектированию. Подходы имеют названия, среди которых много именных. Примеры подходов - подход Йордона и ДеМарко (структурная методология) и подход Шлеер и Меллора (объектно-ориентированная методология).

2.3.2. Отступление " о спецификациях"

- Вовочка, ты уже покрасил окна?
-Да, осталось покрасить только рамы!
Анекдот о необходимости точных спецификаций

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

Средства спецификации - любые средства получения или построения таких описаний.

Язык спецификации - рационально оформленный и синтаксически организованный набор таких средств.

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

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

Существует точка зрения об относительности понятия спецификации [Агафонов 1984]. Имея дело с одной и той же задачей, данные люди в данном окружении (включающем их знания, языки и т. п.) будут склонны считать спецификацией одно, а другие люди в другой обстановке - совсем другое. Например " х: = х + i" будет лучшей спецификацией задачи " увеличить х на единицу" для человека, знакомого с оператором присваивания и его обозначением.

Средства спецификации, которые допускают машинную обработку, мы будем классифицировать по уровню формализации и по способу представления [Деметрович, Кнут, Радо 1989].

По уровню формализации выделим три класса.

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

Существует два основных способа представления спецификаций:

• Текстовое представление, которое подходит для словесных и формальных спецификаций.
• Представление с помощью информационных объектов. Как правило, таким способом представляются модельные спецификации.

2.3.3. Отступление " об архитектуре"

Архитектура программного продукта - это его строение как оно видно (или должно быть видно) извне его, т. е. представление программного продукта как системы, состоящей из некоторой совокупности взаимодействующих подсистем [Жоголев 1996]. В качестве таких подсистем обычно выступают отдельные программы.

Следующее определение принадлежит Криспену (http: //www.sei.cmu.edu/architecture/definitions.html): Архитектура состоит из (а) стратегии разделения и (б) стратегии объединения. Стратегия разделения заключается в делении монолитной системы на дискретные, полностью покрывающие ее части (или компоненты). Стратегия объединения заключается в явном определении интерфейсов между этими компонентами.

И, наконец, еще одно определение содержится в работе [Буч, Рамбо, Джекобсон 2000]: Архитектура - это совокупность существенных решений, касающихся:

• организации программной системы;
• выбора структурных элементов, составляющих систему, и их интерфейсов;
• поведения этих элементов, определенного в процессе взаимодействия с другими элементами;
• составления из этих структурных и поведенческих элементов все более и более крупных подсистем;
• архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, .их интерфейсы, кооперации и способ их объединения.

Выделяют следующие классы архитектур программных продуктов [Майерс 1980], такие как:

• цельная (монолитная) программа;
• комплекс автономно выполняемых программ;
• слоистая программная система;
• коллектив параллельно выполняемых программ.

Можно определить четыре структуры, которые в совокупности описывают программную архитектуру [Ахтырченко, Леонтьев 2001].

• Логическая (концептуальная) структура, включающая множество абстракций, необходимых для описания функциональных требований к системе на абстрактном уровне (уровне, не затрагивающем вопросы реализации). Данная структура строится на основе анализа проблемной области.
• Модульная структура, определяющая организацию программного средства как совокупности модулей - программных единиц, с которыми могут быть соотнесены рабочие задания, выполняемые членами проектной команды.
• Процессная структура, описывающая поведение системы во время ее исполнения.
• Физическая структура, определяющая отображение элементов программного средства на аппаратное обеспечение.

Кроме этих четырех часто используются и другие структуры.

• Структура вызовов.
• Структура потоков данных.
• Структура потоков управления.
• Структура использования.
• Структура классов.

Практически все технологические подходы содержат рекомендации по моделированию большинства перечисленных структур.

Мэри Шоу (Mary Shaw) и Дэвид Гарлан (David Garlan) предложили использовать каталог архитектурных стилей [Shaw, Garlan 1996].

• Независимые компоненты:
• взаимодействующие процессы;
• системы с событиями: неявный вызов и явный вызов.
• Поток данных:
• пакетно-последовательный;
• каналы и фильтры.
• Централизованные данные:
• хранилище;
• классная доска.
• Виртуальные машины:
• интерпретатор;
• системы с правилами.
• Вызов с возвратом:
• главная программа и подпрограммы;
• объектно-ориентированный;
• слойный.

Идентификация и документирование таких архитектурных стилей позволяет программистам использовать их в качестве стартовой точки. Хорошие примеры архитектурных паттернов (шаблонов) и каркасов проектирования приведены в книге [Гамма, Хелм, Джонсон, Влиссидес 2001].

2.3.4. Отступление " о классификации всего сущего"

Женщина.
Исихара Икидаэ (XI век). Из цикла " стихотворения из одного слова"

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

Большинство окружающих нас объектов относится к категориям, рассмотренных в книге [Шлеер, Меллор 1993].

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

Образование иерархий широко используется человеком как стратегия организации информации. Иерархия предпочтений, выявленная Килем в Ходе психологических экспериментов с детьми, представлена на рис. 3.3.

Классифицировать можно даже ненаблюдаемые объекты. Их можно разбить на четыре категории, расположенные в порядке убывания научного интереса, который они представляют [Физики 1968].

• Явления, ненаблюдаемые по определению (например, невидимый свет).
• Явления, ненаблюдаемые в принципе (например, абсолютная скорость).
• Явления, ненаблюдаемые в природе (например, потомство от стерильных кроликов).
• Явления, ненаблюдаемые в обществе воспитанных людей (например, ковыряние в носу).

2.3.5. Проектирование архитектуры (проектирование " в большом" )

Верите ли, это бредовое сооружение Ирода, - прокуратор махнул рукою
вдоль колоннады, так что стало ясно, что он говорит о дворце, -
положительно сводит меня с ума. Я не могу ночевать в нем.
Мир не знал более странной архитектуры.
Михаил Булгаков. " Мастер и Маргарита"

Структурная методология

Проектирование архитектуры (проектирование " в большом" ) для структурной методологии включает следующие основные методы:

• метод нисходящего проектирования;
• метод восходящего проектирования;
• метод расширения ядра.

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

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

Метод нисходящего проектирования представляет собой подход функциональной декомпозиции на основе двух стратегий.

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

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

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

⇐ Предыдущая123456Следующая ⇒

Поделиться: