Тема 2.1 

4.2. Определение требований к программному средству.

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

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

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

Известны три способа определения требований к ПС [4.2]:

• управляемый пользователем,
• контролируемый пользователем,
• независимый от пользователя.

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

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

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

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

 

Разработка начинается с выработки требований к ПИ. На эту фазу приходится, как правило, 50% стоимости и 32% трудозатрат.

Фаза использования начинается с того момента, как изделие передается пользователю.

На этой фазе обычно выполняется обучение персонала, внедрение и настройка.

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

Процесс сопровождения продолжается параллельно эксплуатации ПИ.  На расширение функциональных возможностей ПИ – 78% времени, на выявление ошибок – 17%. Обучение расширенным возможностям – 5%.

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

Особенности эти проявляются на этапах создания и эксплуатации.

Приведем это в форме таблицы.

Наименование этапов	Содержание работы
	Производственно-техническое назначение	ПИ
1. Разработка	Определение требований пользователя. Определение конструктивных элементов. Проектирование элементов. Изготовление опытного образца и его испытания. Создание технологии массового производства.	-----//-----   -----//-----   -----//----- реализация и тестирование __________
2. Ввод в эксплуатацию	Массовое производство	копирование
3. Эксплуатация и обслуживание	Постановка пользователю.
	Техническое обслуживание (ремонт). Возвращение изделия на доработку. Расширение функциональных возможностей.	___________ сопровождение сопровождение
4. Снятие с эксплуатации	Физический износ Моральный износ	__________ -----//-----

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

                Начальный этап проектирования ПИ состоит из следующих процессов:

1. Анализ и разработка требований к ПИ.

2. Определение целей создания ПИ.

3. Разработка внешних спецификаций проекта.

I процесс.

В процессе разработки требований необходимо решить следующие задачи:

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

б) определить трудоемкость и стоимость предстоящей работы;

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

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

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

                Можно установить две фазы в выработке требований.

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

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

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

                Требования являются определенными в том объеме, в котором они фиксируются в документации.

                За полноту и точность сформулированных требований к ПИ отвечает пользователь. Проектировщик отвечает за качество описания требований и их реализуемость.

II процесс. Разработка и описание целей (т.е. процесс разработки в проектировании).

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

При описании целей возможно возникновение следующих ошибок:

1. Противоречивость в описании сформулированных целей;

2. Наличие поверхностно выявленных целей, не отражающих специфических особенностей разрабатываемого ПИ (например, зарплата);

3. Цели создания ПИ с точки зрения пользователя (цели продукта) и цели проекта (с точки зрения проектировщика) противоречивы (т.е. несогласованность разработки и пользователя).

                Цели ПИ, рассматриваемые с точки зрения пользователей, обычно включают следующую информацию.

                1. Краткое описание. В нем кратко определяется общее назначение разрабатываемого ПИ и его функций.

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

                3. Подробное описание функциональных задач. Оно характеризует однозначное восприятие требований пользователей – разработчиков.

                4. Документация – определяются состав документов, выдаваемый каждому пользователю.

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

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

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

                8. Безопасность. Формируются цели в отношении обеспечения безопасности ПИ (сохранение информации, пароль, гриф секретно).

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

                10. Установка. Описываются методы и средства настройки ПИ на конкретные условия эксплуатации (требования на ограничения по настройке, разделение на 5 человек).

                11. Надежность. Цели по достижению надежности в значительной мере зависят от конкретного типа разрабатываемого ПИ. Но можно определить некоторые общие вопросы, которые должны быть рассмотрены:

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

б) среднее время восстановления ПИ после сбоя;

в) цели по числу ошибок ПИ по категориям сложности и время обнаружения;

г) последствия сбоев системы и наиболее важных функций;

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

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

ж) возможности обнаружения ошибок пользователя и аппаратуры, а также восстановления работоспособности.

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

                Цели проекта должны быть ясными, обоснованными и измеримыми, а также известными как пользователям, так и разработчикам.

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

III процесс.  Разработка внешних спецификаций проекта. Упрощенно – это разработка инструкций пользователю.

При их написании разработчик должен решить три проблемы:

1.     Доведение до минимума ошибок пользователя;

2.     Обнаружение ошибок пользователя в случае их возникновения;

3.     Доведение до минимума сложности разрабатываемого программного изделия.

Разработка внешних спецификаций разбивается на 2 части:

1. Предварительный внешний проект.

2. Детальный внешний проект.

Предварительный внешний проект содержит описание функций по составляющим компонентам ПИ (Решить какие функции необходимо описать в инструкции).

Детальный внешний проект каждой функции пользователя должен содержать следующую информацию:

1. Описание входных данных;

2. Описание выходных данных;

3. Преобразование системы (например, обновление массива начисления и удержания по заработной плате после расчета за месяц, при перерасчете. Оно должно быть написано с точки зрения пользователя);

4. Характеристика надежности. Описывается влияние всех возможных отказов функции на систему.

5. Эффективность. Описываются все ограничения (память, время и т.д.).

 

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

 

Лекция №4.

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

                Чтобы изменения в проекте не приводили к дополнительным ошибкам, следует соблюдать следующие правила:

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

2. Фиксировать результаты каждого этапа процесса проектирования. Требования и цели фиксируются после утверждения, внешние спецификации – после успешного завершения проверки их правильности. Изменения должны также проходить формальную процедуру утверждения.

3. Проверять каждое внесенное изменение до такой степени, до которой проверялось исходное решение.

4. Контролировать, чтобы нужные изменения были сделаны на всех уровнях разработки ПИ.

 

Внутреннее проектирование программного изделия.

                Внутреннее проектирование ПИ начинается с изучения внешних требований, разработанных на предыдущем этапе.

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

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

                ПИ создается на основе модульно-иерархической структуры, состоящей из отдельных модулей.

                К преимуществам ПИ с использованием модулей можно отнести следующее:

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

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

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

4.     Упрощается оценка текущего состояния работ.

 

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

1 путь независимости

Модуль обладает 3 основными признаками:

А) Реализует одну или несколько функций;

Б) Имеет определенную логическую структуру;

В) Используется в одном или нескольких контекстах.

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

Логика модуля определяет его внутренний алгоритм, т.е. то, как модуль выполняет функцию.

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

Существует много способов проектирования, при применении которых программа разбивается на множество модулей. В результате использования этих методов достигается минимальная сложность структуры ПИ.

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

Связанность (связность) модуля определяется как мера независимости его частей. Чем выше связность модуля, тем лучше результат проектирования. Для обозначения связности используется такое понятие как  «сила связности модуля».

Вид связности	Сила связности
По совпадению Логическая Временная Процедурная Коммуникативная Последовательная Функциональная	0  (слабая связность) 1 3 5 7 9 10  (сильная связность)

 

Модель с видом связности «по совпадению» - это модуль, между элементами которого нет осмысленных связей. Такой модуль не выполняет никаких разумных функций. Единственный способ описания подобного модуля – описание его логики.

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

Модуль этого типа тесно связан с вызывающим его модулем.

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

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

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

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

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

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

Модуль с функциональной связностью обладает высшей степенью внутренней связностью.

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

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

2 путь независимости модулей состоит в минимизации связей между ними.

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

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

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

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

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

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

 

Вид сцепления	Степень сцепления
По кодам По внешним ссылкам По управлению По общей области По образцу По данным Независимая	9  (сильное сцепление) 7 5 4 3 1 0   (слабое сцепление)

 

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

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

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

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

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

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

                Модули сцеплены по образцу, если параметры содержат структуры данных.

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

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

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

                Степень сцепления и силу связности модулей можно использовать для оценки существующего проекта и как руководящий принцип при проектировании ПИ.

 

Содержание