Операционные системы. Задание. Техническое задание явля ется первым разделом курсовой работы. 1
 Скачать 0.67 Mb.
|
|
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 Рассмотренные альтернативы Кратко описываются альтернативы данной разработки, ко- торые были рассмотрены и отклонены, а также причины откло- нения. Если программы должны быть закуплены, поясняется, почему они не могут быть разработаны собственными силами, и наоборот. Лица, критически анализирующие СТ, могут потребо- вать весомых доказательств необходимости разработки про- 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 Соглашения относительно представления материала Для краткого описания изделия может понадобиться специ- альная терминология. Данный раздел предназначен для того, чтобы представить читателям СТ специальный словарь. И если в 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 строятся одинаково. Там, где слова «программное обеспечение» или «изделие» появляются без оп- ределений, они относятся как к генерируемому, так и к систем- ному программному обеспечению. Выражение (a, b) означает a или b. Если это выражение появляется дважды, например (a 1 , b 1 ) … (a 2 , b 2 ), выбирается a 1 и a 2 или b 1 и b 2 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 Процессор корректировок 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 перечисляются все возможные огра- ничения, относящиеся ко всем функциям. Однако, если список 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 О ГРАНИЧЕНИЯ НА СОВМЕСТИМОСТЬ Всегда должно рассматриваться несколько аспектов со- вместимости: исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов, форматы листингов и форматы языка управления заданиями (управляющие карты, структура команд и т.п.). Специально должна оговариваться совмести- мость со следующими программными изделиями: − изделиями-предшественниками, т.е. такими, которые пользователь может заменить новым изделием; если в новом изделии отсутствует какая-либо возможность, которую имеет предшественник, должны быть приведены обоснования ее исключения; − изделиями-компаньонами, относящимися к той же груп- пе средств, которые являются альтернативами нового изделия; примером может служить программа задания выходного форма- та, которая отличается от другой аналогичной программы толь- ко самим форматом; − подобными изделиями, т.е. такими, которые выполняют похожие функции в других программных изделиях той же се- рии; такими изделиями являются, например, программа сорти- ровки с использованием диска и программа ленточной сорти- ровки; − конкурирующими изделиями, которые выполняют те же функции, но поставляются другими организациями, например 26 Кобол фирмы IBM является конкурентом Кобола фирмы Burroughs. В каждом случае должно указываться, является ли данное изделие расширением или частным случаем другого продукта, и должна даваться соответствующая ссылка в разд. 2.4.1 СТ. Опи- сываются также условия получения данного изделия из других версий или других изделий. Пример. Не существует программных изделий или баз дан- ных, совместимых с системой ASK. Файлы, генерируемые сис- темой ASK, будут VSOS-файлами прямого доступа (см. п. 2.4.1 б) и поэтому могут быть непосредственно использованы други- ми программами. 2.3.3.1.1.3 П РОГРАММНЫЕ ОГРАНИЧЕНИЯ Указывается, если это необходимо, операционная система, с которой должно работать предлагаемое программное изделие, а также другие программные средства, с которыми оно должно стыковаться в процессе работы. Следует убедиться, что указаны все средства, необходимые для загрузки программного изделия либо передачи управления ему или от него. Если имеются программы, которые должны быть исключе- ны из операционной системы, необходимо указать их и объяс- нить, почему они исключаются. Пример. ASK работает с системой VSOS версии 4 (см. п. 2.4.1 б). Любой компонент семейства VSOS может работать одновременно с ASK столько времени, сколько будет доступна конфигурация устройств, описанная в пункте 2.3.3.1.1.4. Про- цессор корректировок может работать параллельно с интерфей- сом пользователя, но интерфейсу пользователя закрыт доступ к файлу, который используется в данное время процессором кор- ректировок. 2.3.3.1.1.4 А ППАРАТНЫЕ ОГРАНИЧЕНИЯ Приводится таблица устройств, используемых при работе программного изделия. Для каждого устройства указывается минимальное, номинальное и максимальное требуемое число. Номинальным является оптимальное число устройств или наи- 27 более вероятное, если оптимум не определен. В случае необхо- димости каких-либо дополнительных устройств они должны быть отмечены отдельно. Пример. Помимо устройств, требуемых системами, указан- ными в пункте 2.4.1 б, для системы ASK потребуются устройст- ва, перечисленные в таблице 2.2. Таблица 2.2 — Необходимые для работы ASK устройства Устройство Минимальное число Номинальное число Максимальное число M103 Блок операций с плавающей точкой 1 1 1 M107 Резервный блок питания 1 1 1 M1100 Модуль памяти 1 2 2 M3100 Дисковый модуль 1 3 8 M210 Пульт 1 1 1 Терминал Telcoscope 43 1 128 256 2.3.3.1.2 В НЕШНИЕ ХАРАКТЕРИСТИКИ Информация данного раздела должна быть расширена (но не изменена) во внешней спецификации, а в СТ должны быть представлены лишь самые основные ее аспекты. Если предла- гаемое изделие является расширением какого-либо существую- щего изделия, описываются главным образом его дополнитель- ные характеристики. Этот раздел должен иметь иерархическую структуру, в которой, прежде всего, должно уделяться внимание наиболее важным для конечного пользователя вопросам. 2.3.3.1.2.1 Р ЕЗУЛЬТАТЫ РАБОТЫ Описываются все выходные данные программного изделия или функционального модуля с точки зрения их содержания и назначения — отчеты, файлы, записи, поля данных, сообщения, таблицы, флажки. Должны быть рассмотрены все возможные носители и средства отображения информации, в том числе про- граммно опрашиваемые индикаторы, каналы прерывания, па- нельные индикаторы и т.п. 28 Пример. Записи в общедоступных и частных файлах, яв- ляющихся VSOS-файлами прямого доступа (см. п. 2.4.1 б). За- писи в DATABASE для ведения системы индексно-последова - тельных файлов (см. п. 2.4.1 б) под управлением VSOS (см. п. 2.4.1 б). Поля и записи данных, передаваемые на терминалы и на пульт. Все результаты должны выдаваться под контролем модуля логического доступа VSOS. 2.3.3.1.2.2 П РОЦЕССЫ ОБРАБОТКИ Описываются операции, выполняемые программным изде- лием, которое при этом рассматривается в целом или по функ- циональным модулям как черный ящик (или совокупность чер- ных ящиков). Как минимум, устанавливается соответствие входной и выходной информации, а если обсуждение идет на уровне модулей или этапов обработки, указываются также мо- дули или этапы, которые требуются для получения определен- ной выходной информации. Определяются все параметры, не- обходимые для генерации и выполнения программ. Пример. Рабочий режим состоит в интерактивном поиске, вычислении, выдаче сообщений и построении диаграмм на за- просы специалистов по финансовому анализу. Режим обслуживания состоит в интерактивном анализе ба- зы данных, ее реорганизации и корректировке, производимых системными аналитиками, прошедшими курс обучения обслу- живанию баз данных. 2.3.3.1.2.3 В ХОДЫ СИСТЕМЫ Описываются входные данные так же, как результаты рабо- ты в пункте 2.3.3.1.2.1. Пример. 1. Блоки записей из DATABASE и файлов корректур DATABASE (а также файлы системы VSOS). 2. Записи из общедоступных и частных файлов системы ASK. 3. Поля данных с клавиатуры терминалов и пультов. 4. Все входные данные контролируются модулями логиче- ского доступа VSOS. 29 2.3.3.1.3 Э РГОНОМИЧЕСКИЕ ХАРАКТЕРИСТИКИ Эргономическими характеристиками изделия являются та- кие свойства, которые обеспечивают надежность, комфорт и продуктивность работы пользователей и операторов. В данном разделе описываются прикладные аспекты эргономики приме- нительно к данному изделию и определяется, насколько разно- образным будет режим его работы. 2.3.3.1.3.1 Б ЕЗОПАСНОСТЬ И СЕКРЕТНОСТЬ СИСТЕМЫ Описываются в общих чертах характеристики изделия, обеспечивающие безопасность и секретность данных и про- грамм. Пример. Никакие общедоступные файлы, в том числе DATABASE, не могут быть записаны с терминала. Все секрет- ные файлы защищены паролем в соответствии с соглашениями VSOS. Все операции записи в общедоступные файлы, включая DATABASE, должны выполняться с пульта. 2.3.3.1.3.2 Н АДЕЖНОСТЬ Под надежностью программных средств понимается спо- собность к восстановлению нормальной работы при ошибках и сбоях в работе оборудования. Первостепенную важность имеет защита данных пользователя. Следует указать, могут ли ошибки в данных быть исправлены оператором, или определить, как должна продолжаться обработка после обнаружения ошибки, а также установить степень потери информации в различных си- туациях, включая сбои в работе оборудования. Затем определяется степень защиты программ от ошибок, возникающих в других частях системы. Если некоторая про- грамма должна работать в мультипрограммном режиме, необхо- димо рассмотреть возможные ошибки в других программах на- ряду с ошибками в работе оборудования. Если мультипро- граммный режим не предусматривается, этот вопрос затрагивать не нужно. В противном случае необходимо рассмотреть защи- щенность от ошибок, которые возникают в программах, нахо- дящихся в памяти одновременно с данной программой. 30 Следует рассмотреть, как могут повлиять на работу предла- гаемых программных средств ошибки в этих сопутствующих программах. При этом учитываются следующие моменты: а) Операции распределения ресурсов, при которых другим программам может выделяться некоторая область памяти на том же самом устройстве или в той же его части, что и для данной программы. Следует указать, как программные средства изоли- руются друг от друга во избежание перекрытия отводимых им областей памяти. Если такая изоляция обеспечивается операци- онной системой или загрузчиком, достаточно сослаться на эти возможности. б) Ошибки выполнения других программ. Здесь также мож- но ограничиться указанием соответствующих возможностей (если таковые имеются) аппаратных средств и операционной системы. Пример. Многие ошибки фиксируются системой ASK, ре- гистрируются в файле ошибок и обрабатываются соответст- вующими средствами восстановления, имеющимися в составе VSOS. ASK не изменяет базы данных DATABASE; для псевдокор - ректировки базы данных используются виртуальные файлы. ASK подчиняется всем ограничениям интерфейса VSOS и поэтому не вызывает сбоя в работе параллельно функциони- рующих программных средств, и наоборот, параллельно рабо- тающие средства, которые также подчиняются соглашениям, не вызовут сбоя в работе ASK. Каждый блок записей в DATABASE содержит контрольную сумму, которая вычисляется и сравнивается системой ASK для проверки целостности данных. Виртуальный телекоммуникационный метод доступа (VTAM) системы VSOS используется на логическом уровне 4, наивысшем уровне восстановления при ошибках (который реги- стрирует все сбои оборудования, допускающие восстановление). 2.3.3.1.3.3 Р ЕСТАРТ Указываются возможности, обеспечивающие сохранение и использование данных при возобновлении работы после ава- 31 рийного прерывания, например при рестарте из контрольной точки. Пример 1. Программы, генерируемые ASK, могут запус- каться с любого этапа обработки данных. Пример 2. Модуль SORT обеспечивает автоматическую или ручную регистрацию параметров и данных, необходимых для рестарта, из последней или любой предыдущей контрольной точки. Вся необходимая для этого информация при выключении электропитания сохраняется, чтобы отказы блока питания не влияли на рестарт. 2.3.3.1.3.4 С ООТВЕТСТВИЕ ТРЕБОВАНИЯМ ЗАКАЗЧИКА Указываются свойства, которые позволяют программному изделию или его выходным данным удовлетворять конкретным требованиям. Перечисляются, если это возможно, модули, кото- рые могут не удовлетворять требованиям заказчика. Указывается также, какие ресурсы машинного времени и памяти резервируют- ся для учета требований заказчика и какие средства предусматри- ваются для обслуживания выходных каналов пользователя. Пример. ASK характеризуется параметрами времени ком- поновки и времени запуска, позволяющими определять требуе- мую конфигурацию вычислительной системы. Параметры ком- поновки определяются для различного числа модулей памяти и дисковых модулей, а также для разного количества и типов кон- троллеров связи. Параметры запуска определяются для различ- ного числа линий и терминалов, а также для различных струк- тур идентификаторов терминалов и паролей. В систему встрое- ны алгоритмы для оптимизации распределения дисковой памяти и для оценки ситуации, в соответствии с которой следует просто подтвердить прием команды вместо немедленного ее выполне- ния. Обеспечиваются служебные программы для корректировки, анализа и реорганизации общедоступных файлов ASK и файлов пользователя. 2.3.3.1.3.5 Р АБОЧИЕ ХАРАКТЕРИСТИКИ Приводится основная переменная или основной принцип, по которому должна измеряться эффективность работы про- 32 граммы; указывается соответствующее значение или диапазон значений для этой переменной. Главным здесь является уста- новление количественной меры. Нельзя, например, писать «ско- рость работы генерируемой программы будет соответствовать быстродействию программы, написанной вручную на ассембле- ре». Такое утверждение нельзя проверить или использовать при принятии решений относительно внутренней структуры про- граммного изделия. Фраза должна быть определенной, напри- мер «производительность будет составлять, как минимум, 21 сообщение в 1 минуту». Характеристики, включенные в данный раздел, должны быть доступны для измерения пользователем. Ими могут быть быстродействие, пропускная способность, ско- рость передачи данных, скорость компиляции, генерации или ас- семблирования, расход машинных ресурсов, время реакции и т.п. Пример 1. Каждое периферийное устройство должно рабо- тать с максимальной производительностью в предположении отсутствия других параллельных операций. Пример 2. Для 16 активных терминалов будет обеспечи- ваться время реакции в пределах 5 секунд и меньше по 90% всех тривиальных операций взаимодействия, где тривиальное взаи- модействие определяется как передача с терминала односим - вольного запроса, поиск на диске односимвольного ответа и прием односимвольного ответа на том же терминале. Время от- вета не будет увеличиваться более чем на 100% (до 10 секунд) при увеличении числа активных терминалов с 16 до 180. Пример 3. Изделие не накладывает никаких ограничений на конфигурацию, помимо ограничений, определяемых оборудова- нием. 2.3.3.1.3.6 У ДОБСТВО ЭКСПЛУАТАЦИИ Описываются свойства, которые делают взаимодействие «человек — машина» удобным для человека. Примерами явля- ются свободный формат входных данных, диалоговый режим, синтаксическая совместимость, возможность ввода сокращен- ных команд и т.д. Если существуют другие программные сред- ства, с которыми предполагаемые пользователи могут быть зна- комы и которые имеют идентичные или похожие операции, 33 операторы, команды, сообщения об ошибках или другие струк- туры, следует указать, что соответствующие структуры предла- гаемого программного изделия будут такими же, когда они оди- наковы, или похожими, когда они сходны. Учитываются также состав специалистов, требуемых для использования тех или иных компонентов программного изделия, и уровень их квали- фикации, например специалисты в области сбыта, системные программисты, операторы. Необходимо стремиться использо- вать простой стандартный способ выделения уровней квалифи- кации, например высокий (семь и более лет работы), средний (от двух до шести лет работы) или низкий (один год и менее). Должно быть показано, как начинается и как заканчивается работа программного изделия. Для таких функций, как сбор, ввод и вывод данных, связь, вычисление, компиляция или генерация, не- обходимо указать соответствующие типы режима работы: − пакетный; − интерактивный; − приоритетный; − фоновый; − режим интерпретации; − диагностический; − непрерывный; − с прерываниями. 2.3.3.1.3.7 М ОБИЛЬНОСТЬ Описываются требования и цели обеспечения переноса про- граммного изделия из одних рабочих условий в другие. Пример. В ASK соблюдаются все условия интерфейса VSOS и используется модуль логического доступа VSOS для всех операций ввода-вывода. Поэтому ASK может работать без модификаций с любой операционной системой, для которой VSOS является подсистемой. 2.3.3.1.4 В НУТРЕННИЕ ХАРАКТЕРИСТИКИ 2.3.3.1.4.1 У ДОБСТВО СОПРОВОЖДЕНИЯ Описываются меры, гарантирующие идентифицируемость модулей, если этот вопрос не решен с помощью стандарта. 34 Пример 1. Каждый исходный и объектный модуль будет снабжаться шифром программного изделия и категорией выпус- ка, а также, если позволяет место, шифром проекта и идентифи- катором изделия. Эта информация должна располагаться таким образом, чтобы каждый модуль можно было идентифицировать на любом диске, ленте или в дампе памяти. Описываются все встроенные средства отладки и компо- новки, включая сопряжения с мониторами; указывается, воз - можно или нет их выборочное отключение. Чтобы можно было позднее оценить удобство сопровождения, следует указать язы- ки, с которыми способно работать данное программное изделие, а также затраты машинных ресурсов на исправление ошибок. Пример 2. В системе ASK используются средства програм- мирования BIL3 (см. п. 2.4.1, е), предусматривающие коэффи- циент резервирования памяти, равный 10%. В соответствии с разделом 2.1.4 пользователям будут передаваться объектные программы. Для коррекции объектных программ используется программа UPDATE (см. п. 2.4.1, ж). Указывается, какие лица, не входящие в группу сопровож- дения, могут вносить изменения. При этом необходимо опреде- лить условия их подготовки и требуемые ресурсы. Пример 3. Инженер, являющийся специалистом по систе- мам и успешно освоивший базовую версию VSOS, сможет за- трачивать на внесение изменений в объектный модуль не более 2 часов своего времени и 0,5 часа машинного времени. Следует убедиться в том, что усилия, затрачиваемые на достижение удобства сопровождения, согласуются со временем жизни изделия, определенным в разделе 2.2.4 СТ. 2.3.3.1.4.2 А ЛГОРИТМЫ Если какие-то используемые алгоритмы или методы играют особую роль в обеспечении успеха или неудачи изделия в смыс- ле его надежности и требуемых характеристик, отмечаются принимаемый риск или ожидаемые преимущества. В противном случае констатируется, что они подлежат описанию во внутрен- ней спецификации. 35 2.3.3.2 И НТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ 2.3.3.2.1 В НЕШНИЕ ОГРАНИЧЕНИЯ 2.3.3.2.1.1 С ТАНДАРТЫ ДЛЯ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ Пример. ANSI ХЗ.28-1971 (см. п. 2.4.1, г). 2.3.3.2.1.3 П РОГРАММНЫЕ ОГРАНИЧЕНИЯ НА ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ Пример. Необходимо наличие модулей VSOS DAM, ILSAM и VTAM (см. п. 2.4.1, б). 2.3.3.2.1.4 А ППАРАТНЫЕ ОГРАНИЧЕНИЯ НА ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ Пример. Помимо устройств, указанных в разделе 2.3.3.1.1.4, интерфейсу пользователя требуются минимальные конфигура- ции, необходимые для VSOS ILSAM, DAM и VTAM (см. п. 2.4.1, б). 2.3.3.2.2 В НЕШНИЕ ХАРАКТЕРИСТИКИ 2.3.3.2.2.1 Р ЕЗУЛЬТАТЫ РАБОТЫ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ Пример. Результаты такие же, как в разделе 2.3.3.1.2.1, ис- ключая записи в DATABASE. 2.3.3.2.2.2 П РОЦЕССЫ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ Пример. Интерфейс пользователя дает возможность: − формировать критерии выбора и (или) зависимости; − создавать файлы фирм или отраслей; − добавлять данные в файлы; − сортировать данные; − выдавать сообщения, строить диаграммы и/или сохра- нять результаты. 2.3.3.2.2.3 В ХОДЫ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ Пример. Такие же, как в разделе 2.3.3.1.2.3, кроме данных из файлов корректировки DATABASE. 2.3.3.2.3 Э РГОНОМИЧЕСКИЕ ХАРАКТЕРИСТИКИ 2.3.3.2.3.3 Р ЕСТАРТ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ Пример. Состояние системы для всех активных пользовате- лей (в том числе отключенных, но еще обслуживаемых) перио- дически запоминается на диске (с интервалом, оговариваемым в рамках определения времени компоновки). Обеспечиваются ав- 36 томатическая и ручная процедуры рестарта на основе использо- вания этих данных. 1. Автоматический рестарт. При использовании вспомога- тельного блока питания M l07 интерфейс пользователя обеспе- чивает автоматическое восстановление питания. Все пользова- тели, активные в момент отключения питания, оповещаются о сбое. Эти активные пользователи опрашиваются и по их жела- нию либо выводятся из работы, либо их обслуживание продол- жается, начиная с последней контрольной точки. Для неактив- ных пользователей восстановление не производится; работа с ними прекращается, за исключением случаев запоминания ре- зультатов выполнения команд, которые были выданы перед от- ключением питания. Такая же процедура выполняется и после любого другого сбоя, если это может быть сделано достаточно надежно. 2. Ручной рестарт. В каждой контрольной точке произво- дится полный дамп памяти интерфейса пользователя. При каж- дом старте интерфейса пользователя оператор опрашивается с целью выяснения, выполнять ли новый старт или осуществлять пуск с контрольной точки. Если выбирается пуск с контрольной точки, интерфейс пользователя загружается из файла контроль- ной точки и вызывается процедура восстановления при сбое пи- тания. Если же возникает сбой, при котором не может быть на- дежно инициирован автоматический рестарт, на пульт посыла- ется диагностическое сообщение и оператору системы VSOS дается возможность предпринять ручной рестарт. 2.3.3.2.3.5 Х АРАКТЕРИСТИКИ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ Пример. При допущении, что на вычислительной машине выполняется только ASK и что параметр восстановления харак- теризуется одной контрольной точкой в 1 минуту, каждая ко- манда должна выполняться или подтверждаться не более чем за 5 секунд с момента ее ввода (при среднем значении 3 секунды). Все команды, подтверждаемые, но не исполняемые при первой реакции, должны выполняться в течение 2 секунд (на каждый элемент данных по одной фирме и за один период). 37 В контексте данного раздела отметка «Выполнено» означа- ет, что начался вывод данных на терминал, но команда при этом может быть отработана не полностью. Весь вывод на терминал должен выполняться со скоростью не менее 2 строк в секунду при проектной скорости 200 визуальных символов в секунду (при надлежащем использовании возможности табулирования). 2.3.3.2.3.6 О БЛАСТЬ ПРИМЕНИМОСТИ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ Пример. В типичном сеансе с ASK пользователь, не имею- щий опыта программирования, подключается к системе с помо- щью терминала и вступает в диалог, в котором он определяет: − интересующие его отрасли промышленности и фирмы; − типы сравнений, которые он хочет выполнить; − критерии, которые он хочет использовать для представ- ления и сортировки данных; − сообщения и диаграммы, которые ему нужны. ASK будет отвечать на каждую команду либо диагностиче- ским сообщением, в котором указываются ошибки и несоответ- ствия в данных, вводимых пользователем, либо ответом на ко- манду, либо подтверждением, что система начинает выполнение команды. Последний случай возникает, когда генерация ответа требует так много времени, что пользователь может предполо- жить какую-либо неисправность, если не получит подтвержде- ния (например, когда вводится команда создания файла). Когда ответ на такую команду готов, ASK посылает его на терминал, если только пользователь не выключился из работы. Если же пользователь уже отключился, ASK сохраняет результат и ин- формирует пользователя о готовности данных при следующем подключении. Доступны два типа информации из файлов: табличный и графический. Когда объем запрошенной информации превыша- ет емкость экрана устройства Telcoscope 43, данные автоматиче- ски разбиваются на страницы. Терминалы оборудованы печа- тающими устройствами, способными печатать страницы по вы- бору. 38 2.3.3.2.4 В НУТРЕННИЕ ХАРАКТЕРИСТИКИ 2.3.3.2.4.2 А ЛГОРИТМ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ Пример. ASK выполняет каждую команду в режиме интер- претации и немедленно; таким образом, накопление команд не разрешается (за исключением команд запоминания, которые бу- дут рассмотрены ниже). В системе используется концепция виртуального файла с сохранением дисковой памяти и присущих ей характеристик извлечения данных. Когда пользователь будет описывать неко- торый файл как более высокий уровень какого-либо сущест- вующего файла (определенного пользователем или системой), никакие существующие данные не будут храниться в этом но- вом файле. Если в конце сеанса работы на терминале пользова- тель захочет сохранить такие созданные во время сеанса файлы, выполнение команды запоминания приведет к копированию и сохранению всех элементов данных. Если непосредственно за этой командой последует команда выхода из сеанса, команда запоминания будет выполняться после выхода, освобождая тем самым пользователя и терминал для другой работы. Программа общего синтаксического анализа просматривает каждую запись, чтобы выполнить ее проверку по диапазону зна- чений, типу и количеству символов и т.п. перед передачей управления процессору команд или любому другому процессо- ру входа. Это дает возможность пользователю сразу корректи- ровать ошибки во вводимой информации. 2.3.3.3 Ф УНКЦИЯ «П РОЦЕССОР КОРРЕКТИРОВОК » Для всех пропущенных подразделов см. соответствующие подразделы раздела 2.3.3.1. 2.3.3.3.1 В НЕШНИЕ ОГРАНИЧЕНИЯ 2.3.3.3.1.3 П РОГРАММНЫЕ ОГРАНИЧЕНИЯ ДЛЯ ПРОЦЕССОРА КОРРЕКТИРОВОК Пример. Требует только VSOS ILSAM. 2.3.3.3.1.4 А ППАРАТНЫЕ ОГРАНИЧЕНИЯ Пример. Помимо устройств, нужных для VSOS ILSAM (см. п. 2.4.1, б и в), процессору корректировок потребуются устрой- ства, перечисленные в таблице 2.3. 39 Таблица 2.3 — Устройства, необходимые процессору корректировок Устройство Минимальное число Номинальное число Максимальное число M103 Блок операций с плавающей точкой 1 M107 Резервный блок питания 1 M1100 Модуль памяти 2 M3100 Дисковый модуль 3 M210 Пульт 1 2.3.3.3.2 В НЕШНИЕ ХАРАКТЕРИСТИКИ 2.3.3.3.2.1 Р ЕЗУЛЬТАТЫ РАБОТЫ ПРОЦЕССОРА КОРРЕКТИРОВОК Такие же, как в разделе 2.3.3.1.2.1, за исключением записей в общедоступные и частные файлы и данных, передаваемых на терминалы. 2.3.3.3.2.2 В ХОДЫ ПРОЦЕССОРА КОРРЕКТИРОВОК Такие же, как в разделе 2.3.3.1.2.3, за исключением обще- доступных и частных файлов и данных, поступающих с терми- налов. 2.3.3.3.3 Э РГОНОМИЧЕСКИЕ ХАРАКТЕРИСТИКИ 2.3.3.3.3.3 Р ЕСТАРТ ПРОЦЕССОРА КОРРЕКТИРОВОК Указываются возможности контроля файлов, предусмот- ренные в программе UPDATE (см. п. 2.4.1, ж) и позволяющие иметь контрольные точки для рестарта. 2.3.3.3.3.5 Х АРАКТЕРИСТИКИ ПРОЦЕССОРА КОРРЕКТИРОВОК Используются концепции программы UPDATE, и заимству- ется оттуда максимально возможное количество программ. Процессор корректировок должен работать с не меньшей скоро- стью, чем программа UPDATE, в случае сравнимых операций. 2.3.3.3.3.6 И СПОЛЬЗОВАНИЕ ПРОЦЕССОРА КОРРЕКТИРОВОК В этой части процессор корректировок также базируется на UPDATE и будет иметь по возможности максимально похожий интерфейс оператора. |