Использование структурного подхода при проектировании программного продукта

Использование структурного подхода при проектировании программного продукта

Использование офисного пакета Microsoft Project для управления проектами.

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

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

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

Задача имеет длительность, то есть время, необходимое на ее выполнение. Кроме того, задача характеризуется объемом трудозатрат (объемом работ) и затратами (или стоимостью), необходимыми для ее выполнения.

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

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

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

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

План работ лучше всего составлять в представлении Gantt Chart (Диаграмма Ганта).

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

Главная цель отслеживания проекта — вовремя обнаружить отклонения фактических работ от запланированных. Для этого нужно собирать данные о ходе выполнения работ и сравнивать их с базовым планом проекта. Чтобы такое сравнение было возможно, перед началом выполнения работ нужно зафиксировать базовый план, с которым в дальнейшем будут сравниваться его актуальные состояния. Для отслеживания проекта используется представление Tracking Gantt (Диаграмма Ганта с отслеживанием).

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

MS Project содержит ряд автоматизированных средств для оперативного перепланирования, позволяющих быстро перенести невыполненную работу на время после заданной даты (текущей даты или даты отчета). Они запускаются автоматически в момент ввода данных по задачам (при установленных флажках в настройках расчетов, которые переносят невыполненные работы к дате отчета) или вручную в любой момент (с помощью панели инструментов и диалоговых окон обновления задач и проекта). Перепланирование можно также проводить вручную с помощью диаграмм с повременными данными, например Task Usage (Использование задач).

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

Отчет — это формат представления проектных данных, предназначенный для распечатки. В MS Project входит набор предопределенных отчетов, которые можно использовать в готовом виде или настроить. Самый простой статистический отчет, Project Statistics (Статистика проекта), вызывается с помощью кнопки Statistics (Статистика) из диалогового окна сведений о проекте.

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

а) набор необходимых моделей (схем, диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

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

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

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

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

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

Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграмм Насси-Шнейдермана. Для краткости и понятности описания не только разработчику, но и заказчику, чаще всего используют псевдокоды.

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

Средства описания структурных алгоритмов Одним из способов обеспечения высокого уровня технологичности разрабатываемого ПО является структурное программирование. Различают три вида вычислительного процесса, реализуемого программами:

а) линейный (для получения результата необходимо выполнить операции в определенной последовательности);

б) разветвленный (конкретная последовательность операций зависит от значений одной или нескольких переменных);

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

Для реализации этих вычислительных процессов в программах служат соответствующие управляющие операторы. Для изображения схем алгоритмов используется ГОСТ 19.701−90, согласно которому каждой группе действий ставится в соответствие специальный блок. Стандарт предусматривает блоки для обозначения циклов, не запрещает произвольной передачи управления и допускает использование команд условной и безусловной передачи управления при реализации алгоритма.

Для реализации трех основных управляющих конструкций в языках программирования высокого уровня имеются управляющие операторы. К базовым относят:

а) следование — обозначает последовательное выполнение действий;

б) ветвление — выбор одного из двух вариантов действий;

в) цикл-пока — определяет повторение действий, пока не будет нарушено некоторое условие, выполнение которого проверяется в начале цикла.

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

а) выбор — выбор одного варианта из нескольких в зависимости от значения некоторой величины;

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

в) цикл с заданным числом повторений (счетный цикл) — повторение некоторых действий указанное количество раз.

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

Использование блок-схемы для описания алгоритма поиска в массиве А (n) элемента, равного заданному.

Фрагмент блок-схемы алгоритма поиска

В приведенном примере используется структурный вариант алгоритма (цикл-пока). Элементы массива перебираются и поочередно сравниваются с заданным значением Y. В результате выводится соответствующее сообщение.

Представление алгоритма программы в виде схемы с точки зрения структурного программирования имеет два недостатка:

1) предполагает слишком низкий уровень детализации, что часто скрывает суть сложных алгоритмов;

2) позволяет использовать неструктурные способы передачи управления, причем часто на схеме алгоритма они выглядят проще, чем эквивалентные структурные.

Кроме схем, для описания алгоритмов можно использовать псевдокоды, Flow-формы и диаграммы Насси-Шнейдермана, которые базируются на тех же основных структурах, допускают разные уровни детализации и делают невозможным описание неструктурных алгоритмов.

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

Использование псевдокода для описания алгоритма поиска в массиве А (n) элемента, равного заданному (фрагмент).

i:=1

Цикл-пока i n и A (i) Y

i:= i + 1

Все-цикл

Если i n

то Вывести «Элемент найден»

иначе Вывести «Элемент не найден»

Все-если

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

Использование Flow-форм для описания алгоритма поиска в массиве А (n) элемента, равного заданному.

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

Использование диаграмм Насси-Шнейдермана для описания алгоритма поиска в массиве А (n) элемента, равного заданному

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

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

1. ГОСТ 19.701−90. ЕСПД. Схемы алгоритмов и программ. Обозначения условные, графические. — М.: Издательство стандартов, 1990.

2. Либерти Дж. Освой самостоятельно С++ за 21 день. — М.: Издательский дом «Вильямс», 2001.

3. Ашарина И. В. Основы программирования на языках С и С++. — М.: Горячая линия-Телеком, 2002.

4. Крупник А. Б. Самоучитель С++. — СПб.: Питер, 2005.

5. Бентли Дж. Жемчужины программирования. — СПб.: Питер, 2003.

6. Марченко А. Л. С++. Бархатный путь. — М.: Горячая линия-Телеком, 2002.

7. Иванова Г. С. Технология программирования. — М.: Изд-во МГТУ им. Н. Э. Баумана, 2002.

8. Вирт Н. Алгоритмы и структуры данных. — М.: Мир, 1989.

9. Тассел Д. Ван. Стиль, разработка, эффективность, отладка и испытание программ. — М.: Мир, 1985.

10. Соммервиль И. Инженерия программного обеспечения. — М.: Изд-во Вильямс, 2002.

11. Мандел Т. Разработка пользовательского интерфейса. — М.: ДМК Пресс, 2001.

12. Канер С., Фолк Д., Нгуен Е. К. Тестирование программного обеспечения. — Киев: «ДиаСофт», 2000

13. Гримм С.Дж. Как писать руководства для пользователей. — М.: Радио и связь, 1985.

14. Липпман С., Лажойе Ж. Весь С++ от азов до совершенства. — СПб.: Невский диалект. — М.: ДМК Пресс, 2007.