 |
Порядок контроля и приемки системы
|
|
|
|
При проведении испытаний выявляются ошибки, ИС проверяется на соответствие функциональным и эксплуатационным требованиям, требованиям нормативных документов и ТЗ, проверяется надежность системы. При необходимости система дорабатывается и готовится к следующему этапу испытаний.
Информационная система проходит обычно три этапа испытаний:
- предварительные испытания: по усмотрению разработчика создается программа и методика автономных или комплексных испытаний (ГОСТ 34.603-92, РД 50-34.689-90, ЕСПД). Работы проводятся разработчиком и заказчиком на протяжении 2 дней;
- опытная эксплуатация: разработчик – создает программу и методики испытаний (ГОСТ 34.603-92, РД 50-34.689-90, ЕСПД). В соответствии с этой программой проводят опытную эксплуатацию. Работы проводятся разработчиком и заказчиком на протяжении 2 дней.
- приемочные испытания: разработчик - создает программу и методики испытаний (в соответствии со стандартом ГОСТ 34.603-92, РД 50-34.689-90, ЕСПД). В соответствии с этой программой проводят приемочные испытания. Работы проводятся разработчиком и заказчиком на протяжении 3 дней.
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие
7.1. Преобразование входной информации виду, пригодному для обработки с помощью ПК.
Все виды документации, используемые внутри общежития и за его пределами приводятся к единой стандартной форме.
7.2. Изменения, которые необходимо осуществить в объекте автоматизации
Проведение подобных работ оговаривается отдельно.
7.3. Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ
|
|
|
Заказчик обязуется к моменту запуска ИС подготовить необходимые помещения для серверной, оплатить разработку проекта локальной сети и ее реализацию.
7.4. Сроки и порядок комплектования штатов и обучения персонала
Перед началом работы с ИС заведующей общежития должна пройти начальный курс работы с ПК и курс обучения работы с данной ИС.
Требования к документированию
Перечень подлежащих разработке документов:
- технический проект;
- руководство пользователя;
- пояснительная записка;
- приложение.
Приложение 4
Шаблон спецификации требований к ПО
- Введение
- Введение представляет собой обзор, помогающий читателям разобраться в структуре и принципе использования спецификации требований к ПО.
Назначение
Определите продукт или приложение, требования для которого указаны в этом документе, в том числе редакцию или номер выпуска. Если эта спецификация требований к ПО относится только к части системы, идентифицируйте эту часть или подсистему. Опишите типы читателей, которым адресован этот документ, например разработчикам, менеджерам проектов, маркетологам, пользователям, тестировщикам или составителям документации.
Соглашения, принятые в документах
Опишите все стандарты или типографические соглашения, включая значение стилей текста, особенности выделения или нотацию. Если вы нумеруете требования вручную, можно определить принятый формат на случай, если кому-нибудь позже понадобиться добавить требование.
Границы проекта
Кратко опишите ПО и его назначение. Покажите, как связан продукт с пользователями или корпоративными целями, а также с бизнес-целями и стратегиями. Если имеется отдельный документ о концепции и границах проекта, не повторяйте его содержимое, а просто сошлитесь на него. Если спецификацию требований к ПО предполагается разрабатывать постепенно, она должна содержать собственное положение о концепции и границах продукта в качестве подраздела долгосрочной стратегической концепции. Можно предоставить высокоуровневую сводку главной функциональности выпуска или функций, которые он должен выполнять.
|
|
|
Ссылки
Перечислите все документы или другие ресурсы, на которые вы ссылаетесь в этой спецификации, в том числе гиперссылки на них, если их местоположение меняться не будет. Это могут быть руководства по стилям пользовательского интерфейса, контракты, стандарты, спецификации к системным требованиям, спецификации интерфейса и спецификации требований к ПО связанных продуктов. Объем информации должен быть достаточным для того, чтобы пользователь сумел при необходимости получить доступ к каждому указанному материалу, а именно: название, имя автора, номер версии, дата, источник, место хранения или URL-адрес.
Общее описание
В этом разделе представлен общий обзор продукта и среды, в которой он будет применяться, предполагаемая пользовательская аудитория, а также известные ограничения, предположения и зависимости.
Общий взгляд на продукт
Опишите контекст и происхождение продукта. Поясните, является он новым членом растущего семейства продуктов, новой версией существующей системы, заменой существующего приложения или совершенно новым продуктом. Если спецификация требований определяет компонент более крупной системы, укажите, как это ПО соотносится со всей системой и определите основные интерфейсы между ними. Неплохо также включить визуальные модели, такие как контекстную диаграмму или карту экосистемы, чтобы показать взаимосвязь продукта с другими системами.
Классы и характеристики пользователей
Определите различные классы пользователей, которые, как предполагается, будут работать с вашим продуктом, и опишите их соответствующие характеристики. Некоторые требования могут относиться только к определенным классам пользователей. Определите привилегированные классы пользователей. Классы пользователей представляют подмножество заинтересованных в проекте лиц, их описание приводится в документе концепции и границ проекта. Описания классов пользователей являются повторно используемым ресурсом. Если есть главный каталог классов пользователей, можно включить описания классов пользователей, просто указав их в каталоге, не дублируя информацию.
|
|
|
Операционная среда
Опишите рабочую среду, в которой будет работать ПО, включая аппаратную платформу, операционные системы и их версии, а также географическое местоположение пользователей, серверов и баз данных вместе с организациями, в которых располагаются соответствующие базы данных, серверы и веб-сайты. Перечислите все остальные компоненты ПО или приложения, с которыми система должна быть совместима. Если в связи с разработкой новой системы нужно произвести значительную работу с технической инфраструктурой, стоит подумать о создании отдельных требований к инфраструктуре, в которой детально изложить подробности этой работы.
|
|
|
