(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Методология структурного анализа и проектирования SADT. Глава 20

Глава 20. Управление проектом

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

20.1. Начало проекта

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

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

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

Верно выбранные основные пункты работы служат базой для правильного подбора коллектива специалистов. Определите число экспертов, авторов, читателей и вспомогательный персонал (библиотекарь, делопроизводители и технические оформители) для получения необходимых результатов. (Представление о необходимом объеме работ дают обзоры проектов в части VI.) Определите также, кто войдет в Комитет технического контроля. Эти лица должны отвечать за разрешение конфликтов,

Рис. 20-1. Типичная структура SADT-проекта

проведение политики проекта, принятие результатов, интерпретацию и реализацию технического задания. Обеспечьте участие в работе Комитета нескольких специалистов с высоким уровнем компетентности, которые смогут отстоять свои решения. В процессе работы над проектом ваша организационная структура будет иметь вид, аналогичный приведенному на рис. 20-1.

20.2. Создание и рецензирование результатов работы

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

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

Размер папки - это один из аспектов проектирования. Не менее важно количество

Рис. 20-2. Уровни консенсуса

папок, рассылаемых в соответствии с конкретным объектом. Мы рекомендуем по каждому рецензируемому объему информации рассылать не одну, а серию папок. Для этого сначала пошлите папку очень опытному эксперту и добейтесь его согласия с вами. Затем отправьте вторую папку с тем же содержанием еще нескольким экспертам и достигните согласия с этой группой. Затем направьте скорректированную папку всей читательской аудитории, чтобы получить общее одобрение вашей работы. Этот процесс достижения возрастающих уровней согласия, начиная от одного человека, затем переходя к небольшой группе лиц и далее - ко всем участникам проекта, типичный путь нашего получения знания в SADT. Он схематически изображен на рис. 20-2, где показаны также уровни достижения согласия. Обычно для достижения согласия со всей читательской аудиторией необходимо несколько папок.

20.3. Создание модели

Создание эффективных SADT-моделей не сводится просто к вычерчиванию правильных диаграмм. Оно требует использования совместной деятельности специалистов для получения утвержденных диаграмм А-0 и АО, назначение авторов для декомпозиции конкретных блоков диаграммы АО, формирования основных задач декомпозиции и кропотливого доведения модели до конца. Мы обычно начинаем работу по моделированию с технического совещания, в котором принимают участие эксперты и разработчики. Совещание длится в течение недели. Руководитель группы управляет этой совместной работой, организуя поток информации от экспертов к авторам и поощряя обмен мнениями между ними. Обсуждение продолжается до тех пор, пока не будут выработаны схемы диаграмм АО и А-0, а также уточнены цель и точка зрения модели (см. уроки в главе 22, где приведено подробное описание такой работы).

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

В ходе совместного творческого процесса каждый автор детализирует свою часть модели, которая рецензируется экспертами и другими авторами. Эта детализация как результат индивидуальной работы требует сбора автором информации (в основном путем чтения документов и опроса экспертов), ограничения каждого декомпозируемого объекта, определения точки зрения декомпозиции, создания диаграммы и ее рецензирования (см. уроки в главах 25 и 26). Для такой работы необходимы внутренняя дисциплинированность и понимание потенциальных проблем. Как и все SADT-авторы, мы выработали за годы работы принципы, позволяющих избежать ловушек. Некоторые наиболее важные из них заключаются в выборе задания для очередного шага, в определении производительности своего труда и отслеживании необходимых ограничений.

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

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

Таблица 20-1. Сроки создания SADT-диаграмм.

Задание
Совершенно заново
Новая версия
Черчение
15-60 минут
10-30 минут
Критика
10-30 минут
10-30 минут
Комментирование
10-40 минут
5-20 минут
Количество диаграмм в день
2-5
5-10

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

Таблица 20-2. Критические размеры SADT-продуктов

Результаты работы
Количество
Папка
Папка
Модель
 
2-6 диаграмм
3-6 циклов рецензирования
10-30 диаграмм

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

20.4. Стратегии дополнения модели

Описание системы в методологии SADT приводит к созданию модели, которая определяет и описывает функции и объекты системы. Но обычно одной модели недостаточно для выработки спецификаций. Модель, как правило, сопровождается дополнениями для того, чтобы разработать полную систему спецификаций. В главе 27 показано, как модель "Питание семьи" может быть дополнена кратким описанием для разработки спецификации, которую легко читать и выполнять. Теперь определим, какие дополнения к модели будут полезны. Стандарты спецификаций в промышленности весьма различны, поэтому их форму мы обсуждать не будем.

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

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

20.5. Резюме

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

Дополнительная литература

Brackett, J.: "Structuring the Analysis and Design Process", GUIDE Productivity Symposium, 1976
Burack, E., and Torda, F.: "The Manager's Guide to Change", Lifetime Learning Publications, 1979.
DeMarco, Т.: "Breaking the Language Barrier", Computerworld, August 1978.
DeMarco, Т.: "Controlling Software Projects, Yourdon Press, New York, 1982.
Parkin, A.: Data Processing Managment, Little, Brown, Boston, 1980.
Ross, D. and Schoman, K.: "Structured Analysis for Requirements Definitions", IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.
Schoman, K.: "SADT and PERT", SofTech Deliverable no. CLIN#0-02AG, November 1977.
Weinberg, G.: "Understanding the Professional Programmer, Little, Brown, Boston, 1982.
Yourdon, E.: "How to Manage Structured Programming", Yourdon Press, New York, 1976.



 Распечатать »
 Правила публикации »
  Написать редактору 
 Рекомендовать » Дата публикации: 23.03.2003 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
NauDoc Enterprise 10 рабочих мест
ABViewer Professional пользовательская
Quest Software. Toad for DBA Suite for Oracle
Oracle Database Personal Edition Named User Plus License
IBM DOMINO ENTERPRISE CLIENT ACCESS LICENSE AUTHORIZED USER LICENSE + SW SUBSCRIPTION & SUPPORT 12 MONTHS
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
CASE-технологии
eManual - электронные книги и техническая документация
Мир OLAP и Business Intelligence: новости, статьи, обзоры
Delphi - проблемы и решения
Каждый день новые драйверы для вашего компьютера!
Компьютерная библиотека: книги, статьи, полезные ссылки
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
 



    
rambler's top100 Rambler's Top100