Операционные системы. Задание. Техническое задание явля ется первым разделом курсовой работы. 1
 Скачать 0.67 Mb.
|
|
7 1 ТЕХНИЧЕСКОЕ ЗАДАНИЕ Составление технического задания — цель первой части первой лабораторной работы. Также техническое задание явля- ется первым разделом курсовой работы. 1.1 Содержание Техническое задание оформляют в соответствии с ГОСТ 19.106-78. Для внесения изменений или дополнений в техниче- ское задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Со- гласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для техниче- ского задания. Техническое задание должно содержать следующие разделы: − введение; − основания для разработки; − назначение разработки; − требования к программе или программному изделию; − требования к программной документации; − технико-экономические показатели; − стадии и этапы разработки. В зависимости от особенностей программы или программ- ного изделия допускается уточнять содержание разделов, вво- дить новые разделы или объединять отдельные из них. 1.2 Введение В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программ- ного изделия и объекта, в котором используют программу или программное изделие. Пример. Получение заготовок во многих отраслях, таких как судостроение, авиастроение, легкая промышленность, авто- мобилестроение и др., основано на вырезке необходимых кон- туров из листового материала с помощью термических уст- 8 ройств. Минимизация пути режущего инструмента обеспечива- ет существенную экономию энергии и трудозатрат. Наименование — система минимизации пути режущего ин- струмента при раскрое листовых материалов (далее просто минимизатор). Краткая характеристика — двумерный минимизатор с ло- кальной базой сформированных маршрутов резки. 1.3 Основание для разработки В разделе «Основания для разработки» должны быть указаны: − документ (документы), на основании которого ведется разработка; − организация, утвердившая этот документ, и дата его ут- верждения; − наименование и (или) условное обозначение темы разра- ботки. Пример. Задание для проведения лабораторных занятий и выполнения курсовой работы, выдано кафедрой АСУ ТУСУРа 01.09.2007. Наименование темы разработки — «Минимизатор». 1.4 Назначение разработки В разделе «Назначение разработки» должно быть указано функциональное (чем является программное изделие) и экс- плуатационное (область применения) назначение программы или программного изделия. Пример. Минимизатор предназначен для формирования минимального пути вырезки многоугольных контуров, разме- щенных в прямоугольной области, а также для хранения полу- ченных маршрутов в базе данных. 1.5 Требования к программе или программному изделию Раздел «Требования к программе или программному изде- лию» должен содержать следующие подразделы: − требования к функциональным характеристикам; 9 − требования к надежности; − условия эксплуатации; − требования к составу и параметрам технических средств; − требования к информационной и программной совмес- тимости. 1.5.1 Требования к функциональным характеристикам В подразделе «Требования к функциональным характери- стикам» должны быть указаны требования к составу выполняе- мых функций, организации входных и выходных данных, вре- менным характеристикам и т.п. Пример. 1. Редактор должен работать в многооконном графическом режиме и поддерживать работу как клавиатуры, так и манипу- лятора типа «мышь». 2. Пользователь, по своему желанию, должен иметь воз- можность установки масштабного поля для каждого окна. 3. Минимизатор должен обеспечивать нахождение мини- мального пути с проходом только один раз через каждое ребро каждого многоугольного контура детали в области размещения. 4. Найденный путь должен демонстрироваться на экране в различных режимах. 5. Информация о размещении контуров и сформированном маршруте может быть сохранена в локальной базе данных минимизатора. 6. Должен быть обеспечен графический просмотр базы дан- ных с возможностью удаления из нее или копирования в актив- ное окно указанного размещения с имеющимся маршрутом. 7. Информация о размещении и сформированном маршруте может быть выведена в форме файла геометрической информа- ции следующей структуры: … 8. Перечисление вершин контуров деталей в соответствую- щем дескрипторе выходного файла должно соответствовать сформированному маршруту резки. 9. Программа должна использовать в качестве входной ин- формации файл геометрической информации, первой деталью которого будет прямоугольник области размещения. 10 10. Программа должна обеспечивать просмотр выходного файла. 1.5.2 Требования к надежности В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирова- ния (устойчивое функционирование, контроль входной и вы- ходной информации, время восстановления после отказа и т.п.). Пример. Программа должна обрабатывать ошибочные дей- ствия пользователя и сообщать ему об этом. Программа должна обеспечивать контроль входной и выходной информации в форме файлов геометрической информации. 1.5.3 Условия эксплуатации В подразделе «Условия эксплуатации» должны быть указа- ны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых обеспечиваются заданные характеристи- ки, а также вид обслуживания, необходимое количество и ква- лификация персонала. 1.5.4 Требования к составу и параметрам технических средств В подразделе «Требования к составу и параметрам техниче- ских средств» указывают необходимый состав технических средств и их основные технические характеристики. Пример. Программное обеспечение разрабатывается для персональной ЭВМ (IBM PC-совместимой) со следующими ха- рактеристиками: − процессор с частотой не ниже 1 ГГц; − объем ОЗУ не менее 128 Мб; − графический адаптер SVGA; − манипулятор типа «мышь». 11 1.5.5 Требования к информационной и программной совместимости В подразделе «Требования к информационной и программ- ной совместимости» должны быть указаны требования к ин- формационным структурам на входе и выходе и методам реше- ния, исходным кодам, языкам программирования и программ- ным средствам, используемым программой. При необходимости должна обеспечиваться защита информации и программ. Пример. ЭВМ должна работать под управлением операци- онной системы не ниже, чем Windows 98/NT 4.0. Требование информационной совместимости должно быть обеспечено рабо- той с файлами геометрической информации определенной структуры в качестве входной и выходной информации. 1.6 Требования к программной документации В разделе «Требования к программной документации» дол- жен быть указан предварительный состав программной докумен- тации и, при необходимости, специальные требования к ней. 1.7 Технико - экономические показатели В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преиму- щества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами. 1.8 Стадии и этапы разработки В разделе «Стадии и этапы разработки» устанавливают не- обходимые стадии разработки, этапы и содержание работ (пере- чень программных документов, которые должны быть разрабо- таны, согласованы и утверждены), а также, как правило, уста- навливают сроки разработки и определяют исполнителей. 12 2 СОГЛАШЕНИЕ О ТРЕБОВАНИЯХ Составление соглашения о требованиях — цель второй час- ти первой лабораторной работы. Также соглашение о требова- ниях является вторым разделом курсовой работы. Ниже дается описание разделов, которые должны присутст- вовать в любом соглашении о требованиях (СТ) согласно ГОСТу. Все последующие упоминания о соглашении о требованиях имеют в виду соглашение о требованиях, разработанное в соот- ветствии с данным разделом. Описываемый подход предполага- ет также декомпозицию проекта и дальнейшую детализацию, отражаемую во внешней спецификации изделия. Предполагается, что все утверждения, включенные в со- глашение о требованиях, являются требованиями, если они не определены как цели. Различие состоит в том, что требование должно быть обязательно выполнено, а цель допускает ее дос- тижение с некоторым приближением. Описание информации, содержащейся в СТ, дается ниже очень подробно, и, возможно, после чтения первых абзацев поя- вится желание ограничиться беглым просмотром. Однако если вам когда-нибудь придется разрабатывать свой собственный стандарт СТ, вы, вероятно, оцените предлагаемый здесь со все- ми подробностями пример и используете его как образец. С уче- том того, что сжатость заголовков разделов и большой объем их описаний скрывают порядок и простоту, лежащие в основе ре- зультирующего документа, в конце каждого пункта приводится пример оформления на конкретное изделие. Вероятно, вам опять не захочется читать все приложение целиком, поэтому рекомендуется для начала бегло просмотреть его, чтобы полу- чить представление, как выглядит типичное СТ в целом. Затем можно будет обращаться к отдельным его разделам, чтобы иметь дополнительные примеры, иллюстрирующие приводимый материал. 13 2.1 Описание программного изделия 2.1.1 Наименование и шифры изделия 2.1.1.1 П ОЛНОЕ НАИМЕНОВАНИЕ ИЗДЕЛИЯ Указывается предлагаемое полное наименование изделия. После утверждения СТ не должны использоваться никакие дру- гие наименования для данного изделия, кроме сокращенных на- именований, которые приводятся ниже. Пример. ASK (произносится «аск»). 2.1.1.2 С ОКРАЩЕННЫЕ НАИМЕНОВАНИЯ Указываются все предлагаемые сокращения, которыми раз- решается заменять наименование, приведенное в пункте 2.1.1.1. После утверждения СТ не рекомендуется использовать никакие другие сокращения. В противном случае делается пометка «От- сутствуют». 2.1.1.3 Ш ИФРЫ ИЗДЕЛИЯ Указываются шифр или шифры изделия, присвоенные в со- ответствии с требованиями удобства управления его конфигу- рацией. Если предполагается выпуск печатных изданий и разра- ботка планов поддержки, порядок присвоения шифров конеч- ным результатам работы группы выпуска документации и груп- пы поддержки может быть иным. Пример. L301A. 2.1.1.4 Ш ИФРЫ ПРОЕКТА Приводятся все шифры проекта, используемые в процессе разработки изделия. Пример. C013. 2.1.2 Краткое описание изделия Описываются кратко и в общих понятиях основные функ- циональные свойства изделия. Если программное изделие явля- ется расширением уже существующего, характеризуются только его новые свойства. 14 Пример. ASK позволяет специалисту по финансовому ана- лизу или другому лицу с аналогичными аналитическими зада- чами в интерактивном режиме и на расстоянии запрашивать ЭВМ серии Stella 100 выполнить поиск и обработку финансовой информации из DATABASE, которая содержит фундаменталь- ные сведения и зависимости по данным за 20 лет для большого числа корпораций и отраслей. ASK может также формировать дополнительные общедоступные или частные сведения, файлы корпораций и отраслей, выражения и элементы и использовать их вместе с информацией из DATABASE. Программное изделие ASK в совокупности с DATABASE образует сервисную систему ASK DATABASE; все три системы являются собственностью фирмы ABC Services. 2.1.3 Сведения об авторском праве Если предполагается заявить об установленной законом за- щите авторских прав на данное изделие, это должно реализо- ваться уже в CТ. В противном случае делается пометка «Не тре- буется». Пример. Copyright © 1977 by ABC Computers Company. 2.1.4 Результирующие компоненты изделия В данном разделе приводится таблица, подобная или экви- валентная таблице 2.1. В данном случае использована заранее подготовленная печатная форма, что уменьшает время подго- товки информации и обеспечивает ее согласованность. В указанной таблице в строке «Тип изделия» ставится метка X против соответствующей характеристики «Основное» или «Вспомогательное». Если изделие не используется для создания других изделий, оно отмечается как основное. В противном слу- чае (например, ассемблер, компилятор или генератор) оно отме- чается как вспомогательное. В графе «Уровень поддержки» выбирается метка 1, 2 или 3 в соответствии с пояснениями в бланке. 15 Каждый элемент изделия отмечается меткой X в графе «Формируется целиком», если он будет создаваться заново, или в графе «Модифицируется», если будут вноситься только до- полнения или изменения. Метка X ставится в графе «Распро- страняется» (за пределы группы разработки) или «Не распро- страняется» (за пределы группы разработки) в зависимости от того, что является правильным. В графе «Ответственная группа» пишется Р, И, П или C — по ключу на бланке. Если предполага- ется выпуск нестандартных изделий, этот факт отмечается в графе «Другие спецификации» и описание соответствующих документов дается сразу после таблицы. Таблица 2.1 — Результирующие компоненты изделия Ф орм ируе тс я целико м М одиф ицир уе тс я Р аспр ос тр аня ет ся Не ра сп рос тра няе тс я О тв етс тв ен на я гр уппа Спецификации Внешняя специ- фикация X X Р Внутренняя спе- цификация X X Р Спецификация испытаний (не надо) Спецификация сопровождения (не надо) Другие специфи- кации Документация Техническое опи- сание системы Обозначения: Основное изделие — не исполь- зуется для создания других из- делий Вспомогательное изделие — используется для создания дру- гих изделий Уровень поддержки 1: удовле- творяются заявки на исправле- ние дефектов; возможно сооб- щение об изменениях; прини- маются заявки на расширение функциональных возможностей изделия Уровень поддержки 2: удовле- творяются заявки на исправле- ние дефектов; возможно сооб- щение об изменениях; заявки на расширение не принимаются Уровень поддержки 3: удовле- творяются заявки на исправле- ние дефектов Р — группа разработки Справочное руко- водство X X Б 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 П РИНЯТЫЕ ЗАЯВКИ Перечисляются все предложения на расширение, которые были одобрены и будут реализованы в изделии. Если таких предложений нет, делается пометка «Отсутствуют». |