Файл: Технология разработки программного обеспечения.pdf

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

 

 

 
 

21

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

 

Пример.  Поскольку  в  распоряжении  фирмы ABC Services 

нет ни одного программного изделия, которое может выполнять 
функции ASK, должно быть разработано новое изделие. Дейст-
вующих  аналогов  в  готовом  виде  не  существует.  Фирма ABC 
Services  решила  заключить  единственный  договор  с  фирмой 
ABC Computers о создании и сопровождении ASK; это решение 
основывается  на  прошлом  положительном  опыте  заключения 
договоров с фирмой ABC Computers. 

 

2.2.7 Окупаемость капиталовложений 
 
Определяется  прибыль,  которую  даст  создание  изделия,  в 

понятиях, соответствующих целевому назначению организации.

 

Пример.  Фирма ABC Services ожидает,  что  объем  сбыта  в 

финансовой  сфере  увеличится  на 10% в  течение 3-х  месяцев  с 
момента выпуска изделия и достигнет примерно 170% в течение 
первого  года  с  момента  выпуска.  В  результате  ожидаемой 
большой  прибыли  от  такого  увеличения  объема  сбыта  затраты 
на разработку изделия ASK окупятся через 8 месяцев после вы-
пуска,  что  без  новой  версии ASK даст  полную  валовую  при-
быль, в три раза превышающую суммарные затраты на его раз-
работку и сопровождение. 

 
2.3 

Стратегия

 

 
Формулировка  стратегии  предполагает  ответ  на  вопрос 

«что?». Поэтому в данном разделе указывается, что будет пред-
ставлять собой предлагаемое изделие. 

 

2.3.1 Соглашения относительно представления 

материала 

 
Для краткого описания изделия может понадобиться специ-

альная  терминология.  Данный  раздел  предназначен  для  того, 
чтобы представить читателям СТ специальный словарь. И если в 


background image

 

 

 
 

22

пунктах 2.3.1.1 и 2.3.1.2 внешней  спецификации  можно  делать 
дополнения, то в данном разделе СТ ни одна формулировка не 
должна меняться. 

 

2.3.1.1

 

О

БОЗНАЧЕНИЯ

 

Определяются  все  обозначения,  используемые  в  СТ.  На-

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

 

2.3.1.2

 

Т

ЕРМИНОЛОГИЯ

 

Четко  определяется  вся  терминология,  которая  может  ока-

заться специфической для данного изделия.

 

Пример.  Вся  специальная  терминология  определяется  в 

контексте данного документа. 

 

2.3.2 Генерируемое программное обеспечение 
 
Генерируемое  программное  обеспечение
 — это  то,  что  по-

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

 

2.3.3 Системное программное обеспечение 
 
Системное  программное  обеспечение
 — это  все  остальное 

программное обеспечение, включающее операционные системы, 
компиляторы, утилиты, пакеты прикладных программ и др. Это 
программное  обеспечение  относится  к  основному  типу  и  явля-
ется изделием, описываемым в СТ.

 

Разделы 2.3.2 и 2.3.3 строятся  одинаково.  Там,  где  слова 

«программное  обеспечение»  или  «изделие»  появляются  без  оп-
ределений, они относятся как к генерируемому, так и к систем-
ному программному обеспечению. Выражение (ab) означает a 
или  b.  Если  это  выражение  появляется  дважды,  например  (a

1

b

1

)

 (a

2

b

2

), выбирается a

1

 и a

2

 или b

1

 и b

2

.

 


background image

 

 

 
 

23

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

основными, может появиться желание поменять местами разде-
лы 2.3.2 и 2.3.3, а затем опустить раздел 2.3.3 для основного из-
делия. Причина выдвижения здесь генерируемого программного 
обеспечения на первое место состоит в том, что при правильном 
проектировании  сверху  вниз  генерируемое  программное  обес-
печение  является  основной  целью  проектирования  и  должно 
быть  описано  раньше,  чем  его  генератор.  Другими  словами, 
структура генерируемых программ должна определять структу-
ру генератора, а не наоборот. Если изделие является основным, 
под  заголовком «2.3.2. Генерируемое  программное  обеспече-
ние» делается пометка «Не используется» и опускаются пункты 
2.3.2.1—2.3.2.3. 

 

2.3.3.1

 

О

БЩИЕ ХАРАКТЕРИСТИКИ ФУНКЦИЙ

 

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

нальный модуль, чтобы число подразделов было небольшим. Если 
невозможно  адекватно  описать  изделие  без  разбиения  его  на  от-
дельные  функциональные  модули,  следует  дать  схему,  показы-
вающую,  как  связаны  между  собой  функциональные  модули,  и 
присвоить  каждому  модулю  собственное  обозначение.  Затем  для 
каждого  функционального  модуля  отводится  подраздел  раздела 
2.3.(2,3), в заглавии которого используется слово «функция» с по-
следующим именем функционального модуля (рис. 2.1).

 

 

Рис. 2.1 — Структурная схема из соглашения о требованиях

 

для изделия ASK 

 

2.3.3.1

 

ASK

 

2.3.3.2

 

Интерфейс

 

пользователя

 

2.3.3.3

 

Процессор

 

корректировок

 


background image

 

 

 
 

24

Пример.

 

2.3.3.1 Общие характеристики функций ASK.

 

2.3.3.1.1 Внешние ограничения ASK.

 

Отметим,  что  здесь  выполняется  именно  функциональная 

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

 

Разделы 2.3.(2,3).Х организуются по иерархическому прин-

ципу,  чтобы  охватить  как  можно  больше  вопросов  в  первой 
группе подразделов. Это позволяет при отсутствии новой суще-
ственной  информации  просто  ссылаться  на  подразделы  более 
высокого уровня, как это сделано в разделе 2.3.3.2 для системы, 
показанной на рисунке. Здесь и далее X — номер модуля систе-
мы. В рассмотренном примере X = 1 для общих функций ASK, 
X = 2 для интерфейса пользователя и X = 3 для процессора кор-
ректировок.  В  других  проектах  количество  и  состав  модулей 
могут различаться.

 

 
2.3.3.1.1

 

В

НЕШНИЕ ОГРАНИЧЕНИЯ

 

Перечисляются  все  ограничения,  сфера  действия  которых 

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

 

В  разделе 2.3.(2,3).1.1 перечисляются  все  возможные  огра-

ничения,  относящиеся  ко  всем  функциям.  Однако,  если  список 


background image

 

 

 
 

25

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

 

2.3.3.1.1.1

 

Д

ЕЙСТВУЮЩИЕ СТАНДАРТЫ

 

Перечисляются  все  промышленные  стандарты  и  собствен-

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

 

Пример. 2.3.3.1.1.1. Действующие  стандарты:  Стандарт 

ABC на программирование (см. п. 2.4.1 д). 

 

2.3.3.1.1.2

 

О

ГРАНИЧЕНИЯ НА СОВМЕСТИМОСТЬ

 

Всегда  должно  рассматриваться  несколько  аспектов  со-

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

 

 

изделиями-предшественниками,  т.е.  такими,  которые 

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

 

 

изделиями-компаньонами, относящимися к той же груп-

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

 

 

подобными изделиями, т.е. такими, которые выполняют 

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

 

 

конкурирующими изделиями, которые выполняют те же 

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