Учебное пособие 1438

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

В итоге можно перечислить основные принципы методологии RAD:

разработка приложений итерациями;

необязательность полного завершения работ на каждом из этапов жизненного цикла;

обязательное вовлечение пользователей в процесс разработки ИС;

необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

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

23

использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;

тестирование и развитие проекта, осуществляемые одновременно с разработкой;

ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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

Контрольные вопросы

1.Что понимают под программной системой?

2.Как классифицируются ПС?

3.Что такое жизненный цикл ПС?

4.Какие классические этапы ЖЦ существуют?

5.Для чего выделено несколько типов моделей ЖЦ ПС?

6.Что понимается под инкрементной стратегией разработки ПС?

7.В чем преимущества и недостатки ХР-разработки?

8.Каковы особенности RAD-разработок?

9.Как реализуется компонентная разработка приложений?

3. ЭТАП АНАЛИЗА ТРЕБОВАНИЙ

Этап анализа требований является одним из наиболее важных в жизненном цикле программного обеспечения [6, 11]. Сформулированные требования к программной системе далее реализуются в проекте программного обеспечения. Внесение

24

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

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

Результатом этапа анализа требований должны быть четко сформулированные и зафиксированные в техническом задании, согласованном, если это возможно, с заказчиком, требования к программному обеспечению, включающие в себя перечень решаемых задач, требования к этим задачам, организационные требования, по HARD SOFT и т.д. Требования оформляются в техническое задание на разработку программной системы. Содержание этапа сводится к формированию требований с использованием системного анализа [1, 6] задачи, которую должна решать программная система:

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

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

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

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

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

25

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

системный структурный анализ (SADT) [6]; объектно-ориентированный анализ [9, 10]; мозговая атака и другие методы поиска идей [1, 15].

3.1. Особенности этапа анализа требований

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

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

2.Часто заказчик и разработчик общаются «на разных языках». Возникает проблема недопонимания, связанная с тем, что заказчик и разработчик видят программное средство с разных сторон. Заказчик - с точки зрения его функциональной архитектуры, задач, которые нужно переложить на программы. Разработчик - с точки зрения системной архитектуры, про-

26

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

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

3.2. Методы анализа контекста

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

Росса [6, 11, 15]:

рациональный выбор языка общения заказчика, разработчика;

использование цикла «читатель-автор» для сближения точек зрения заказчика и разработчика;

использование стратегии «почему-что-как» на всех этапах анализа и формулирования требований.

Рациональный выбор языка общения заказчика и разработчика заключается в выборе средств описания задачи, понятных и заказчику и разработчику, Это позволяет получать,

27

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

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

Стратегия «почему-что-как» является методом нисходящего системного анализа и проектирования в приложении к задачам анализа контекста и нечеткое формулированным задачам. Нисходящий подход является естественным ходом человеческого мышления, который без затруднений усваивается разработчиком в ходе проектирования технических и программных систем. При переходе к нечетким задачам анализа

28

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

Фаза «почему» соответствует изучению внешнего описания исследуемого объекта как единого целого и сводится к ответу на вопрос «почему должен быть этот объект» (внешние границы системы).

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

Фаза «как» соответствует составлению внешних описаний составных частей объекта исследования и сводится к ответу на вопрос «как должны быть постpоены составные части» (внешние границы элементов системы).

В результате одного цикла «почему-что-как» получается один уровень декомпозиции исследуемой задачи на подзадачи. Эти подзадачи, в свою очередь, детализируются следующим циклом «почему-что-как», и т.д. до построения полного решения задачи.

3.3. Технология анализа и формирования требований

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

1. Формулирование целей.

1.1. Необходимо получить от заказчика постановку задачи в виде контекстного описания задачи.

29

1.2.Следует проанализировать контекст и определить цели, которые преследует решение задачи. Как правило, таких целей несколько, в зависимости от аспектов рассмотрения задачи Основными аспектами являются:

• функциональный (функции, для которых строится за-

дача);

• операционный (операции, необходимые для выполнения функций задачи);

• эксплуатационный (особенности эксплуатации);

• стоимостный (стоимость разработки и эксплуатации);

• надежность;

• эффективность.

Каждая цель (аспект) порождает свою модель (описание) задачи.

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

1.4.Необходимо согласовать цели с заказчиком, используя, например, цикл «читатель-автор» и при необходимости возвратиться к п. 1.1. - 1.3.

2. Этап анализа задачи.

2.1.Выделить подзадачи (подсистемы) с учетом поставленных целей.

2.2.Выделить взаимные связи подзадач.

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

2.4.Согласовать функциональные спецификации с заказчиком в цикле «читатель-автор».

3. Этап формирования требований.

3.1.Сформировать ограничения (требования) на подзадачи и связи между подзадачами.

3.2.Документировать требования к задаче в виде документа технического задания.

30

3.3. Согласовать техническое задание с заказчиком, используя цикл «читатель-автор».

Контрольные вопросы

1.Каковы трудности этапа анализа требований?

2.Какова стратегия взаимодействия разработчика и заказчика?

3.Каковы методы анализа контекста?

4.Какие можно формализовать этап анализа требований?

4. ЭТАП ПРОЕКТИРОВАНИЯ

4.1. Содержание этапа проектирования

На данном этапе решается вопрос «Каким образом система будет удовлетворять требованиям?» [6]. Исследуются:

структура системы;

взаимосвязи ее элементов (без привязки к конкретной платформе).

Создается логическая модель системы, проектируется ее физическая модель. В конце строится логическая модель системы со строго сформулированными целями, пишутся спецификации физической системы. Этот процесс обычно бывает итерационным.

Можно выделить 2 этапа в проектировании:

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

31

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

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

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

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

32