ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 5838
Скачиваний: 6
16
Справочный бук-
лет
X
X
Б
Руководство опе-
ратора
X
X
Б
Основ-
ное
X
Указатель сис-
темных сообще-
ний
X
X
Б
Тип
изде
-
лия
Вспо-
мога-
тельное
Началь-
ный уро-
вень
под-
держки
Информацион-
ный листок вы-
пуска
1
X
Другие печатные
издания
2
Рекламные мате-
риалы
3
Программное
обеспечение
Листинги
X
X
Р
Исходные модули
X
X
Р
Объектные модули
X
Р
Контрольные
примеры
X
X
Р
И
Средства разра-
ботки
X
Прочие средства
Листинги представляют собой комплект распечаток, полу-
ченных при компоновке и трансляции программного изделия.
Исходные модули содержат совокупность операторов, ко-
торые должны быть ассемблированы или откомпилированы для
получения готовой программы.
Объектные модули представляют собой редактируемые или
загружаемые программы на машинном языке, получаемые в ре-
зультате ассемблирования или компиляции исходных модулей,
или программу, которая порождается некоторым генератором
(если она пригодна для непосредственного выполнения или ин-
терпретации).
Окончание табл. 2.1
17
Отладочный материал используется для доказательства то-
го, что программное изделие может быть правильно ассембли-
ровано, откомпилировано, отредактировано, загружено и вы-
полнено. Отладочный материал может включать листинги, ис-
ходные модули, объектные модули и процедуры.
Средства разработки включают ассемблеры, компиляторы,
загрузчики, процедуры получения дампов и тому подобные
средства, разработанные в рамках данного проекта с целью по-
лучения программного изделия.
2.2
Цели
Формулировка цели создания программного изделия отве-
чает на вопрос «зачем?». Поэтому в данном разделе указывают-
ся все причины выпуска изделия. Часто такой причиной может
быть выполнение плана или договора либо устранение недос-
татков предшествующего изделия.
Пример. Коммерческим планом финансовых служб преду-
сматриваются создание в фирме ABC Services и поставка на ры-
нок интерактивной системы финансового анализа с дистанцион-
ным доступом, предназначенной для финансовых кругов. Сис-
тема ASK призвана удовлетворить требования к программному
обеспечению, изложенные в коммерческом плане.
2.2.1 Согласование заявок на проверку
Заявки на проверку представляют собой предписанные из-
менения изделия, которые являются результатом событий, на-
ходящихся вне сферы контроля разработчиков изделия. Если
заявки на проверку отсутствуют, этот факт отмечается и пункты
2.2.1.1 и 2.2.1.2 опускаются.
2.2.1.1
О
ТКЛОНЕННЫЕ ЗАЯВКИ
Обычно такие заявки отсутствуют, поскольку внесение из-
менений является обязательным. Однако учет какого-либо кон-
кретного изменения все же может оказаться нецелесообразным,
18
в этом случае отказ должен быть тщательно обоснован и доку-
ментирован, начиная с данного раздела СТ.
2.2.1.2
П
РИНЯТЫЕ ЗАЯВКИ
Здесь перечисляются все предлагаемые в заявках измене-
ния, которые были одобрены и будут включены в изделие. Если
таких заявок нет, следует дать пометку «Отсутствуют».
2.2.2 Согласование заявок на расширение
Если заявок на расширение нет, этот факт отмечается и
пункты 2.2.2.1 и 2.2.2.2 опускаются.
2.2.2.1
О
ТКЛОНЕННЫЕ ЗАЯВКИ
Перечисляются все предложения, касающиеся расширения
изделия, которые были специально рассмотрены с точки зрения
их реализации, но не могли быть приняты, указываются причи-
ны их отклонения. Если таких предложений нет, делается по-
метка «Отсутствуют».
2.2.2.2
П
РИНЯТЫЕ ЗАЯВКИ
Перечисляются все предложения на расширение, которые
были одобрены и будут реализованы в изделии. Если таких
предложений нет, делается пометка «Отсутствуют».
2.2.3 Согласование заявок на внесение исправлений
Если предметом рассмотрения СТ является новое изделие,
которое не предназначается для замены другого изделия, внеш-
них запросов на внесение исправлений быть не может. В этом
случае делается пометка «Не требуется» и опускается пункт
2.2.3.1.
2.2.3.1
О
ТКЛОНЕННЫЕ ЗАЯВКИ
Если целью является переработка или расширение изделия
либо замена изделия с известными ошибками, следует планиро-
вать исправление ошибок, обнаруженных на данный момент
19
времени. Поэтому в этом пункте пишется примерно следующее:
«Все существенные ошибки, зарегистрированные до последнего
срока подачи заявок на внесение исправлений (этап СТ), будут
исправлены. Заявки, полученные в период между СТ и датой
готовности продукта, будут удовлетворены по возможности».
Здесь же отмечаются все существенные ошибки, зарегистриро-
ванные до появления СТ, которые не будут исправлены (как
правило, в связи с технической сложностью), а также причины
такого решения. По мере продвижения работы над проектом
неудовлетворенные заявки на внесение исправлений могут на-
капливаться и фиксироваться. Если такие заявки накопятся,
данный раздел СТ должен быть изменен.
2.2.4 Согласование планов
2.2.4.1
И
СКЛЮЧЕННЫЕ ПУНКТЫ ПЛАНА
Если имеются какие-либо плановые указания, требующие
особых свойств и возможностей программных средств, которые
не могут быть обеспечены, если изделие разрабатывается в со-
ответствии с другими требованиями, описанными в СТ, каждое
такое указание необходимо рассмотреть отдельно и пояснить,
почему оно будет исключено. Если таких указаний нет, делается
пометка «Отсутствуют». Отмечаются также и все другие свой-
ства (не фигурирующие в заявках на расширение), которые бы-
ли детально рассмотрены и исключены.
Пример. Широкий набор терминальных устройств, требуе-
мый в коммерческом плане финансовых служб, не будет обес-
печен. С системой ASK будет эффективно работать только уст-
ройство Telcoscope 43 или электрически и функционально экви-
валентные терминалы. Рассмотрение команд графического вы-
вода (вместо выдачи таблиц) и сортировки файлов откладывает-
ся до следующей версии.
2.2.4.2
В
КЛЮЧЕННЫЕ ПУНКТЫ ПЛАНА
Если необходимость создания изделия обоснована таким
документом, как план выпуска изделия, план выпуска серии или
описание задачи, то цитируется либо определенное место из ка-
20
ждого документа, либо приводится краткое содержание соот-
ветствующих разделов. Плановые указания устанавливают (в
самых общих чертах), что должно делаться и почему. Эти ука-
зания отличаются от технических обоснований, определяющих
в конкретных понятиях технические предпосылки осуществле-
ния того, что должно делаться. Для каждой цитаты делается от-
сылка к соответствующей записи в разделе 2.4.1 СТ.
Пример. Коммерческий план финансовых служб, раздел 5
(см. п. 2.4.1 а).
2.2.5 Перечень требований пользователя
Указываются заказчики изделия и поясняется, почему оно им
необходимо. В этом разделе указывается также предполагаемый
срок использования изделия. Обычно это будет срок службы обо-
рудования или время до выпуска изделия-преемника. Если дан-
ное изделие должно быть заменено, указывается наименование
изделия-преемника. Цель этого раздела — дать некоторое пред-
ставление о степени сложности условий работы программ.
Пример. Система ASK предназначается для специалистов
по финансовому анализу или других лиц с аналогичными анали-
тическими задачами, как, например, управляющий по контролю
и регулированию портфеля заказов. Ожидается, что пользовате-
ли не знакомы с программированием и не имеют подготовлен-
ных операторов терминалов.
В соответствии с документом, указанным в пункте 2.4.1 a,
первая версия ASK должна быть готова для продажи через 6—12
месяцев, а вторая версия — не позже, чем через 18 месяцев.
2.2.6 Рассмотренные альтернативы
Кратко описываются альтернативы данной разработки, ко-
торые были рассмотрены и отклонены, а также причины откло-
нения. Если программы должны быть закуплены, поясняется,
почему они не могут быть разработаны собственными силами, и
наоборот. Лица, критически анализирующие СТ, могут потребо-
вать весомых доказательств необходимости разработки про-