1 Перечень документов, на основании которых создается система 2 Плановые сроки начала, и окончания работы по созданию системы 2 - shikardos.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
№ урока Тема Вид урока Плановые сроки прохождения Скорректированные... 1 108.35kb.
Перечень торговых объектов, в которых применяются системы внутриведомственного... 1 20.86kb.
Перечень документов, предоставляемых юридическим лицом, зарегистрированным... 1 50.73kb.
Пакет документов необходимо предоставить в течении 7 дней после прохождения... 1 88.05kb.
Рабочая программа по искусству для 9 класса составлена на основании... 1 132.48kb.
Анализ воспитательной работы за 2012-2013 учебный год 1 221.17kb.
Перечень необходимых документов на визу в австрию для граждан РФ 1 48.2kb.
Краткое руководство пользователя арм «Клиент» ас «Клиент-Сбербанк»... 1 197.53kb.
Основные понятия 8 2 документы. Классификация документов 20 3 нормативно-методическое... 13 2031.77kb.
Воспитательная работа в школе (2012-2013 уч год.) 2 320.25kb.
Перечень станций метрополитена, в кассах которых осуществляется приём... 1 148.67kb.
«Динозаврик» 1 30.34kb.
- 4 1234.94kb.
1 Перечень документов, на основании которых создается система 2 Плановые сроки начала - страница №1/1

СОДЕРЖАНИЕ

Оглавление


СОДЕРЖАНИЕ
1

ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ 1

Техническое задание 1

1Общие сведения 1

1.1.Полное наименование системы и ее условное обозначение 1

1.2.Наименование предприятий разработчика и заказчика системы и их реквизиты 1

1.3.Перечень документов, на основании которых создается система 2

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

1.5.Сведения об источниках и порядке финансирования работ 2

1.6.Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы 2

2Назначение и цели создания системы 3

2.1.Назначение системы 3

2.2.Цели создания системы 3

3Характеристика объектов автоматизации 3

4Требования к системе 5

4.1.Требования к системе в целом 5

4.2.Требования к функциям (задачам), выполняемым системой 8

4.3. Требования к видам обеспечения. 14

Требования к информационному обеспечению содержится в техническом задании на «РБЦГИ». 15

Проектирование и реализация БД должны быть выполнены с использованием реляционной модели базы данных. 15

Для управления базой данных должна быть использована FireBird 2.5. 15

Должна быть гарантирована целостность и непротиворечивость данных в режиме обработки и в режиме хранения с использованием механизмов FireBird 2.5. 15

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

Все используемое для подготовки информационного обеспечения стороннее программное обеспечение должно иметь соответствующие условиям эксплуатации лицензии. 15

Требования к информационному обеспечению содержится в техническом задании на «РБЦГИ». 15

1)процессор Intel Pentium 4; 16

2)оперативная память объёмом не менее 1 Гб; 16

3)видеоадаптер типа SVGA, обеспечивающий отображение цветов с глубиной 16 бит в разрешении 1024х768; 16

4)монитор, обеспечивающий отображение цветов с глубиной 16 бит в разрешении 1024х768; 16

5)объем свободного места на жёстком диске не менее 100 Мб; 16

6)101 клавишная или Windows-совместимая клавиатура; 16

7)Windows-совместимая мышь. 16

5.Состав и содержание работ по созданию системы 16

6.Порядок контроля и приемки системы 16

7.Требования к документированию 16

8.Источники разработки 17

Распределение требований и работ по итерациям 18






ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ


БД – база данных

ОАО «ТП НИЦ» - открытое акционерное общество "Тимано-Печорский научно-исследовательский центр"

РБЦГИ - Региональный Банк Цифровой Геологической Информации ТПП

ИС – информационная система

СУБД – система управления базами данных

Техническое задание

  1. Общие сведения

    1. Полное наименование системы и ее условное обозначение


Полное наименование системы:

  1. Информационная подсистема Учета палеонтологических коллекций и палеонтологических исследований в составе ИС РБЦГИ.
    1. Наименование предприятий разработчика и заказчика системы и их реквизиты


Заказчиком данной подсистемы является ОАО «ТП НИЦ».

Адрес заказчика: 169300, РК, г. Ухта, ул. Первомайская, 45.

Разработчиком данной системы является Шатохина Татьяна Николаевна, студентка группы ИСТ-09 УГТУ.

Адрес разработчика: 169347, РК, п. Ярега, ул. Мира, 5.

Система разрабатывается для использования работниками ОАО ТП НИЦ.

    1. Перечень документов, на основании которых создается система


Письмо о создании РБЦГИ, техническое задание РБЦГИ.
    1. Плановые сроки начала, и окончания работы по созданию системы


Плановый срок начала работ по созданию информационной подсистемы Учета палеонтологических коллекций и палеонтологических исследований – 01 ноября 2012 года.

Плановый срок окончания работ по созданию информационной подсистемы Учета палеонтологических коллекций и палеонтологических исследований – 31 мая 2013 года.(см. Приложение 1)


    1. Сведения об источниках и порядке финансирования работ


Финансирование работ не предусмотрено.
    1. Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы


Работы по созданию информационной подсистемы Учета палеонтологических коллекций и палеонтологических исследований сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа.
работы ведутся в соответствии с планом итерации, который представлен в Приложении 1.

Результаты работ по созданию системы и планируемые сроки сдачи представлены в таблице 1:

Таблица 1 – Сроки сдачи результатов работ по созданию системы


Результаты работы

Срок сдачи

Рабочая версия созданного программного продукта

15.05.2013

Руководство пользователя (в соответствии с пунктом 3.4 «Руководство пользователя» РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов»).

20.05.2013

Руководство администратора (в соответствии с ГОСТ 19.503-79 «Руководство системного программиста. Требования к содержанию и оформлению»).

25.05.2013


  1. Назначение и цели создания системы

    1. Назначение системы


Информационная подсистема Учета палеонтологических исследований и палеонтологических коллекций предназначена для переноса данных о результатах палеонтологических исследований из унаследованных источников (бумажных документов и электронных таблиц Excel).
    1. Цели создания системы


Информационная подсистема Учета палеонтологических исследований и палеонтологических коллекций создается с целью:


  • централизации результатов для палеонтологических исследований и палеонтологических коллекций;

  • повышения потребительских качеств данных о результатах палеонтологических исследований;

  • сбора данных о палеонтологических коллекциях и палеонтологических исследований.
  1. Характеристика объектов автоматизации


Объектом автоматизации Информационной подсистемы Учета палеонтологических исследований и палеонтологических коллекций является процесс учета палеонтологических коллекций и исследований.

Палеонтологическая коллекция представляет собой поименованный и связанный стратиграфическим возрастом набор отобранных палеонтологических образцов. Палеонтологический образец – это физический палеонтологический шлиф. Шлиф (Приложение 11 - Рис. 1, Рис. 2) — тонкая пластинка горной породы или минерала, приклеенная на стекло. Стандартный петрографический шлиф имеет толщину 0,03-0,02 мм, приклеен на специальную смолу — канадский бальзам и покрыт сверху тонким стеклом. Размер стандартного шлифа примерно 2х4 см. Шлифы изготавливают в первую очередь для изучения породы на петрографическом микроскопе. Изучение шлифов является основным методом науки петрографии.

Коллекции принимаются как на постоянное, так и на временное хранение. На постоянное хранение принимаются только обработанные коллекции после составления окончательных отчетов по работам геологических партий и экспедиций, тематическим и научно-исследовательским работам, характеризующим данные по геологии и полезным ископаемым района (участка, объекта), а также другие коллекции и отдельные образцы, имеющие научную и музейную ценность. Коллекции принимаются на постоянное хранение только после того, как отчеты оформлены для передачи их в геологические фонды. На временное хранение принимаются коллекции, обработка которых не производилась или коллекции по незаконченным работам. Такие необработанные коллекции хранятся на временных складах. При передаче коллекций на постоянное хранение необходимо их зарегистрировать (получить номер коллекции), сократить, отобрать образцы в научную коллекцию и в обменный фонд, произвести соответствующее оформление (занумеровать образцы, написать к ним этикетки и составить каталоги).

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



а) при сдаче коллекций фотоматериалов и рисунков автор заполняет паспорт (Приложение 2- Форма 1) и составляет каталог (Приложение 3 - Форма 5), где подробно должны быть записаны все сведения о каждом негативе, отпечатке, рисунке и т. д. В каждом каталоге порядковый номер является номером фотообъектива данной коллекции;

б) для коллекции фотоматериалов и рисунков этикетирование не производится—все данные по описанию содержания снимка и указание точного места фотографирования заносятся в каталог под тем номером, под которым занумерован фотоматериал;

в) нумерация коллекций фотоматериалов и рисунков ведется следующим образом: на каждом отпечатке или рисунке (на его обратной стороне) и на каждом негативе или пленке (в левом верхнем углу) ставится номер в виде дроби—в числителе номер фото, рисунка, негатива, в знаменателе — номер коллекции;

г) передаваемые на хранение негативы должны быть уложены в коробки, а отпечатки — в конверты или папки из плотной бумаги.

Регистрация коллекционных материалов производится путем записи этих материалов в соответствующие регистрационные книги, которые являются и инвентарными книгами коллекций данного учреждения.

Перед передачей коллекции на постоянное хранение автору коллекции необходимо заполнить полученный у руководителя музея или у лица, ответственного за учет и хранение коллекций, особый бланк — паспорт на коллекцию, в котором должны быть даны исчерпывающие сведения о коллекции. По этому паспорту сотрудник музея или лицо, ответственное за учет и хранение коллекционных материалов, регистрирует коллекцию и, в зависимости от характера коллекции, заносит все сведения в соответствующую регистрационную книгу. Порядковый номер по регистрационной книге, под которым записана принятая на хранение коллекция, является номером коллекции и ее инвентарным номером. Этот номер сообщается автору коллекции и никаким изменениям не подлежит. Он проставляется на всех относящихся к коллекции документах (этикетках, каталоге, образцах).

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


  1. Требования к системе

    1. Требования к системе в целом


4.1.1 Требования к структуре и функционированию системы

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

Информационная подсистема Учета палеонтологических коллекций и палеонтологических исследований является частью крупной информационной системой «РБЦГИ».

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

Подсистема должна быть выполнена средствами общего ОО-каркаса РБЦГИ.


4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы

ИС Учета палеонтологических исследований и палеонтологических коллекций входит в состав ИС «РБЦГИ» и интегрирована с ней на уровне базы данных.


4.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами

1) Подсистема «Паспорт скважины» предоставляет для информационной

системы данные о скважинах, из которых могли отбираться образцы,

шлифы для составления палеонтологических коллекций.



  1. Справочная подсистема представляет данные о нефтяных регионах, тектонических структурах, площадях, месторождения и т.д.

  2. Подсистема «Стратиграфический справочник» представляет данные о составе стратиграфических изменений для дотирования образцов.

  3. Кадровая подсистема предоставляет данные о сотрудниках, которые являются авторами коллекций.


4.1.1.4 Требования к режимам функционирования системы

Система должна поддерживать следующие режимы функционирования:

- Основной режим, в котором подсистемы ИС Учета палеонтологических исследований и палеонтологических коллекций выполняют все свои основные функции.

- Профилактический режим, в котором одна или все подсистемы ИС Учета палеонтологических исследований и палеонтологических коллекций не выполняют своих функций.

В основном режиме функционирования Система ИС Учета палеонтологических исследований и палеонтологических коллекций должна обеспечивать работу пользователя в режиме работы соответствует режиму основных пользователей – 8 часов в день, 5 дней в неделю (8х5) с понедельника по пятницу.

4.1.2 Требования к численности и квалификации персонала системы

4.1.2.1 Требования к численности персонала

Для эксплуатации ИС Учет палеонтологических исследований и палеонтологических коллекций определены следующие роли:



  1. Пользователи - палеонтолог, литолог;

  2. системный администратор.

Основными обязанностями системного администратора являются: установка, модернизация, настройка и мониторинг работоспособности серверной части ИС.
4.1.2.2 Требования к квалификации персонала

Условия эксплуатации системы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК. Необходима квалификация уровня «Пользователь ПЭВМ». Необходимо обеспечить обучение пользователей по направлениям:



  1. пользователь ПЭВМ. Работа в сети Microsoft Windows, Internet, электронная почта;

Администратор должен обладать навыками установки, настройки и текущего контроля компьютерных систем, знание методологии проектирования ИС, знание интерфейсов интеграции ИС с источниками данных, знание СУБД, владеть языками запросов SQL.

Палеонтолог/литолог должен обладать квалификацией пользователя СМН, и так же обладать квалификацией предметной области.


4.1.2.3 Требуемый режим работы персонала АС

Штатный режим – рабочий день с 815 до 1730.



      1. Требования к надежности

При сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла системы;

При ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС;

При ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.

Функционирование системы должно осуществляться без постоянного сопровождения специалистами по информационно-программному обеспечению при минимальной специальной подготовке пользовательского персонала.




      1. Требования к эргономике и технической эстетике

Пользовательский интерфейс системы должен быть выполнен в соответствии со стилем, принятом в разрабатываемых в системах ТП НИЦ.

Система также должна удовлетворять следующим общим требованиям:



  1. Интерфейс должен наиболее полно раскрывать все функциональные возможности системы.

  2. Информация в названиях должна ясно и недвусмысленно идентифицировать назначение отчета или формы.

  3. Пользовательские инструкции должны быть краткими, а для предоставления дополнительной информации должны быть предусмотрены специализированные справочные экраны.

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

  5. Логически связанные поля в форме должны располагаться вместе, причем последовательность их расположения должна быть логически обоснованной.

  6. Форма должна иметь привлекательный внешний вид и представлять собой гармоничное сочетание полей ввода и отображения информации. При этом на форме не должно быть малой концентрации полей ввода и отображения информации, все поля должны быть распределены на форме равномерно.

  7. Названия полей должны быть знакомы и понятны пользователю.

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

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

  10. Для выполнения определенного действия пользователь должен выполнять минимальное количество манипуляций.

  11. При вводе данных поля обязательные и необязательные для ввода информации должны разделяться при помощи цветового оформления, а также располагаться отдельно на форме.

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


4.1.5 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы содержаться в техническом задании на «РБЦГИ».


4.1.6 Требования к защите информации от несанкционированного доступа

Требования к защите информации от несанкционированного доступа содержаться в техническом задании на «РБЦГИ».


4.1.7 Требования по сохранности информации при авариях

Должна быть обеспечена сохранность информации в следующих аварийных ситуациях:



  • сбой аппаратуры или программного обеспечения сервера СУБД;

  • сбой аппаратуры или программного обеспечения рабочей станции пользователя;

  • сбой или выход из строя коммуникационного оборудования;

  • выход из строя аппаратуры сетевого сервера;

  • аварийное отключение питания сервера или рабочей станции.

Для обеспечения сохранности информации постоянно хранимых объектов разрабатываемой системы необходимо осуществлять резервное копирование данных.

Расчетные функции не должны выполняться при нарушении технологии обработки данных, сбоях оборудования и программного обеспечения, приводящих к искажению БД.

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

Для защиты данных необходимо разработать регламент по резервному копированию данных системы. Ведение резервных копий БД, а также восстановление данных должен осуществлять администратор в соответствии с регламентом, разработанным в организации.


4.1.8 Требования к патентной частоте

Установка клиентской части системы не должна предъявлять дополнительных требований к покупке лицензий на программное обеспечение сторонних производителей.

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

Разработка системы ложна осуществляться с использованием стандартных методологий функционального моделирования: DCD, DFD и информационного моделирования в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные поддержки жизненного цикла продукции. Методология функционального моделирования». Для работы с БД должен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92.


    1. Требования к функциям (задачам), выполняемым системой


      1. Система должна предоставлять возможность учета коллекции.

        1. Система должна предоставлять возможность регистрировать коллекции, поступающие на хранение.

        2. Регистрационные данные включают в себя: № коллекции, тип коллекции (палеонтологическая, петрографическая и т.д.), наименование коллекции, ФИО автора, год сбора, место сбора (пространственная привязка по географическому региону, НГР, НГО, нефтегазоперспективная площадь, структура, месторождение), возраст и содержание коллекции, название работы и количество образцов, работа (отчет), в рамках которой формировалась коллекция.

        3. Источники входных данных является пользователь.

        4. Выходными данными являются: сообщение об успешной регистрации коллекции (либо сообщение о неудаче при регистрации) с указанием ее причины.

        5. Пунктом назначения является пользователь.

        6. Предусловием является аутентифицикация и авторизация пользователя, в систему введены данные о возможных типах коллекций (справочник типов коллекций), о пространственной привязке (справочники литологии, местонахождения, НГР).

        7. Постусловием является зарегистрированная коллекция в БД системы, пользователь может приступать к ее наполнению.

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

        9. Основным успешным сценарием является:

          1. Пользователь выбирает пункт меню «Новая коллекция».

          2. Система предоставляет окно ввода коллекции, в элементы управления которого предварительно загружены данные справочников типов коллекций, типов возможных привязок, сотрудников ТП НИЦ, внешних соисполнителей.

          3. Пользователь указывает номер коллекции.

          4. ТД Номер коллекции может быть числовым или буквенным идентификатором.

          5. Пользователь вводит наименование коллекции.

          6. Пользователь выбирает из выпадающего списка тип коллекции.

          7. Пользователь вводит наименование отчета, в рамках которого формировалась коллекция из списка отчетов*.

          8. По введенной части наименования отчета система производит поиск отчета в БД ИС Документы и материалы, в случае, если отчет найден – система информирует об этом пользователя и производит автозаполнение наименования отчета.

          9. Если отчет был выбран из БД ИС Документы и материалы, то система предлагает пользователю список авторов отчета, для того, чтобы их можно было включить в состав авторов коллекции.

          10. Пользователь указывает авторов отчета, которые также являются авторами коллекции.

          11. В общем случае пользователь указывает авторов коллекции, отмечая их в списке.

          12. БП Авторами коллекции могут быть сотрудники ТП НИЦ (имеется справочник сотрудников, который ведется через кадровую подсистему РБЦГИ) или внешние соисполнители (имеется справочник внешних соисполнителей), который ведется через подсистему «Документы и материалы».

          13. Если отчет был выбран из БД ИС Документы и материалы, то система автоматически заполняет дату сдачи отчета датой, выбранной из ИС Документы и материалы.

          14. Пользователь вводит дату формирования коллекции, дату сдачи отчета.

          15. Пользователь указывает привязочные данные, выбирая из выпадающего списка типов привязок нужную привязку.

          16. Система подгружает справочник, соответствующий выбранному пользователем типу привязки.

          17. Пользователь отмечает те элементы справочника, которые характеризуют привязку вводимой коллекции*.

          18. Новая коллекция сохраняется в системе.




        10. Прототип интерфейса (см. Приложение 4)

      1. Система должна предоставлять возможность учета (регистрации) образцов (палеонтологических шлифов) по скважинам (обнажениям).

4.2.2.1. Система должна предоставлять возможность регистрировать отдельные образцы коллекции.

4.2.2.2. Входными данными являются: номер коллекции, номер образца, выбирается из выпадающего списка скважина, привязочные данные по возрасту, литологии, глубине отбора и прикрепляется фото. Так же каждый образец коллекции и коллекция в целом – находятся по определенному месту хранения. Для коллекции это кабинет/склад, для образца – кабинет/склад-ящик/коробка-полка/стеллаж-полка.

4.2.2.3. Источником входных данных является пользователь.

4.2.2.4. Выходными данными является сообщение об успешном сохранении образца коллекции.

4.2.2.5. Пунктом назначения является пользователь.

4.2.2.6. Предусловием является аутентификация и авторизация пользователя, сохранение в системе данных о коллекциях (справочник коллекций), о глубинной привязке (справочники литологии, стратиграфии).

4.2.2.7. Постусловием является сохранение образца в БД.

4.2.2.8. Основным успешным сценарием является:



1) На главной странице пользователь выбирает пункт «Новый образец».

2) Система предоставляет окно ввода нового образца (см. Приложение 5).

3) Пользователь указывает номер коллекции.

4) ТД Номер коллекции может быть числовым или буквенным идентификатором.

5) Пользователь указывает номер образца.

6) Пользователь выбирает из выпадающего списка номер скважины.

7) Пользователь указывает данные о глубинной привязке (справочники литографии и стратиграфии).

8) Пользователь загружает фото образца.

9) Пользователь указывает место хранения образца.

10) Пользователь указывает номер склада или комнаты, где будет храниться образец.

11) Пользователь указывает стеллаж.

12) Пользователь указывает полку.

13) Пользователь указывает ящик.

14) Образец сохраняется.

15) Система переходит на окно «Регистрация образца».

16) Образец сохраняется в системе.



4.2.2.9. Прототип интерфейса (см. Приложение 6)

      1. Система должна предоставлять возможность учета фотографий образцов.

        1. Каждый пользователь имеет возможность зарегистрировать фотографию образца.

        2. Входными данными являются: порядковый номер фотографии, место заснятия объекта, содержание, наименование партии, год, фотография.

        3. Источниками входных данных является пользователь.

        4. Выходными данными является сообщение об успешном сохранении фотографии.

        5. Пунктом назначения является пользователь.

        6. Предусловием является аутентификация и авторизация пользователя.

        7. Постусловием является сохранение фотографии в БД.

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

        9. Основным успешным сценарием является:

          1. Пользователь вносит порядковый номер фотографии.

          2. Пользователь вписывает место заснятия объекта.

          3. Пользователь описывает содержание рисунка (например, обнажение каменно-угольного возраста).

          4. Пользователь выбирает наименование партии и год работы.

          5. Пользователь загружает фотографию путем нажатия на кнопку «обзор..» и выбора необходимого изображения в папке.

          6. Фотография сохраняется.

          7. Система переходит в окно «Регистрация образца».

          8. Сохранение.

        10. Прототип интерфейса (см. Приложение 7)

      2. Система должна предоставлять возможность учета результатов исследований.

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

        2. Входными данными является иерархический справочник ископаемых остатков.

        3. Источниками входных данных является база данных.

        4. Выходными данными являются данные, заполненные на форме.

        5. Пунктом назначения является база данных системы.

        6. Предусловием является аутентификация в авторизованной системе.

        7. Постусловием являются данные сохраненные в БД.

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

        9. Основной успешный сценарий:

          1. Пользователь выбирает шлиф или набор шлифов для которых будет введен результат исследования (в случае если выбирается набор шлифов – подразумевается, что по этому набору получены одинаковые результаты).

          2. Пользователь выбирает виды ископаемых остатков из соответствующего справочника (пользователь имеет возможность искать по части слова)

          3. Пользователь инициирует сохранение.

          4. Система сохраняет данные о результатах исследований в БД для каждого шлифа из набора шлифов.

        10. Прототип интерфейса (см. Приложение 8).

      3. Система должна предоставлять по запросу пользователя формировать отчет о результатах исследований по выбранным скважинам.

        1. Система должна генерировать отчеты в соответствии с пользовательским фильтром.

        2. Входными данными являются: название коллекции, возраст от и возраст до.

        3. Источники входных данных являются пользователь и система.

        4. Выходными данными является отчет о результатах исследований по выбранным скважинам в Microsoft Exel.

        5. Пунктом назначения является пользователь.

        6. Предусловием является определение пользователем критерия для поиска, внесение все справочников в БД.

        7. Постусловием является вводимый список образцов искомой коллекции.

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

        9. Основным успешным сценарием является:

          1. Пользователь выбирает название коллекции.

          2. Пользователь указывает возраст коллекции от и возраст коллекции до.

        10. Прототип интерфейса (см. Приложение 9)

      4. Система должна предоставлять по запросу пользователя формирование схемы (в масштабе глубин и времен) распространения ископаемых видов.

        1. Пользователь выбирает ископаемые и рисуется график распространения ископаемых видов.

        2. Входными данными являются названия ископаемых.

        3. Источником входных данных является пользователь.

        4. Выходными данными является сформированная схема ископаемых.

        5. Пунктом назначения является пользователь.

        6. Предусловием является аутентификация пользователя в авторизованной системе.

        7. Постусловием является изображенная на форме схема распространения ископаемых видов.

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

        9. Основной успешный сценарий:

          1. Пользователь выбирает ископаемые

          2. Система производит необходимые расчеты.

          3. На форме выводится схема распространения ископаемых видов.

        10. Прототип интерфейса (см. Приложение 10).


    1. Требования к видам обеспечения.


4.3.1 Требования к информационному обеспечению

Требования к информационному обеспечению содержится в техническом задании на «РБЦГИ».

Проектирование и реализация БД должны быть выполнены с использованием реляционной модели базы данных.

Для управления базой данных должна быть использована FireBird 2.5.

Должна быть гарантирована целостность и непротиворечивость данных в режиме обработки и в режиме хранения с использованием механизмов FireBird 2.5.

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

Все используемое для подготовки информационного обеспечения стороннее программное обеспечение должно иметь соответствующие условиям эксплуатации лицензии.

4.3.2 Требования к лингвистическому обеспечению

Требования к информационному обеспечению содержится в техническом задании на «РБЦГИ».

Для реализации используется Delphi, система должна быть реализована средствами OO-каркаса РБЦГИ.

В качестве языка манипулирования данными должен использоваться SQL. Код по манипулированию данными должен оформляться в виде хранимых процедур. Разрешается непосредственное обращение к таблицам БД из приложения с использованием запросов языка SQL.

4.3.3 Требования к программному обеспечению системы

4.3.3.1 Требования к программному обеспечению разработчика


  1. При разработке подсистемы в качестве среды разработки должна использоваться среда Delphi, система должна быть реализована средствами OO-каркаса РБЦГИ.

  2. Для организации хранения, редактирования и ввода/вывода данных БД – FireBird 2.5.

  3. Средствами описания предметной области должны являться диаграммы классов в нотации UML, диаграммы бизнес-процессов, ER-диаграммы.

  4. Поддерживаемые операционные системы: Windows XP и выше.

  5. Необходим установленный Microsoft Office 2007.

  6. Система управления базами данных FireBird 2.5.

  7. Операционная система и вспомогательное системное ПО сервера БД должно обеспечивать бесперебойную работу указанной СУБД и выбирается по усмотрению разработчика.

4.3.4 Требования к техническому обеспечению

Для функционирования данной системы компьютеры пользователя должны быть оснащены следующим техническим обеспечением:



    1. процессор Intel Pentium 4;

    2. оперативная память объёмом не менее 1 Гб;

    3. видеоадаптер типа SVGA, обеспечивающий отображение цветов с глубиной 16 бит в разрешении 1024х768;

    4. монитор, обеспечивающий отображение цветов с глубиной 16 бит в разрешении 1024х768;

    5. объем свободного места на жёстком диске не менее 100 Мб;

    6. 101 клавишная или Windows-совместимая клавиатура;

    7. Windows-совместимая мышь.


  1. Состав и содержание работ по созданию системы


Работы по созданию системы выполняются в три этапа:

  • Проектирование. Разработка эскизного проекта. Разработка технического проекта.

  • Разработка рабочей документации. Адаптация программ.

  • Ввод в действие.

Конкретные сроки выполнения стадий и этапов разработки и создания Системы определяются Планом выполнения работ, являющимся неотъемлемой частью технического задания.
  1. Порядок контроля и приемки системы


Система подвергается испытаниям следующих видов:

1. Предварительные испытания. (15.05.2013)

2. Опытная эксплуатация.

3. Приемочные испытания.

Состав, объем и методы предварительных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Рабочая документация».

Состав, объем и методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым на стадии «Ввод в действие».

Состав, объем и методы приемочных испытаний системы определяются документом «Программа и методика испытаний», разрабатываемым на стадии «Ввод в действие» с учетом результатов проведения предварительных испытаний и опытной эксплуатации.

  1. Требования к документированию


Разработчик должен предоставить следующие документы:

  1. техническое задание;

  2. руководство пользователя;

  3. руководство администратора;

  4. программа и методика предварительных испытаний;

  5. альбом экранных форм;

  6. альбом выходных форм;

  7. описание ПО;

  8. описание БД.
  1. Источники разработки


Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов:

- ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».

- ГОСТ 19.301-79 «Программа и методика испытаний. Требования к содержанию и оформлению».

- Р 50.1.028-2001 «Методология функционального моделирования».

- ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем».

- ГОСТ 34.601-90. «Автоматизированные Системы. Стадии Создания».



Приложение 1
План итераций
Плановый срок окончания работ по созданию информационной подсистемы Учета палеонтологических коллекций и палеонтологических исследований – 31 мая 2013 года.

Функциональное требование

Приоритет

Срок реализации

  1. Система должна предоставлять возможность учета коллекций.

10

4 недели

  1. Система должна предоставлять возможность учета образцов (палеонтологических шлифов) по скважинам (обнажениям) (фото)

10

3 недели

  1. Система должна предоставлять учет фотографий.

30

2 недели

  1. Система должна предоставлять возможность учета результатов исследований.

10

3 недели

  1. Система должна предоставлять по запросу пользователя формировать отчет о результатах исследований по выбранным скважинам.

10

3 неделя

  1. Система должна предоставлять по запросу пользователя формирование схемы (в масштабе глубин и времен) распространения ископаемых видов.

30

2 недели

Распределение требований и работ по итерациям




Итерация

Требования

Работы

Время на ФТ

Время на проект

Артефакты

1

1. Система должна предоставлять возможность учета коллекций.


  1. Проектирование структуры ИС на уровне подсистем

  2. Проектирование БД системы

  3. Реализация ФТ – 1

4 недель

2 недели

Диаграмма компонентов

Диаграмма классов подсистемы сбора данных



Модель БД


2

2.Система должна предоставлять возможность учета образцов (палеонтологических шлифов) по скважинам (обнажениям) (фото)


  1. Реализация ФТ – 2

3недели

1 неделя




3

4.Система должна предоставлять возможность учета результатов исследований.

  1. Реализация ФТ – 4

3 неделя

1 неделя




4

5.Система должна предоставлять по запросу пользователя формировать отчет о результатах исследований по выбранным скважинам.

  1. Реализация ФТ – 5

3 недели

1 неделя

Работающая первичная версия программы.

5

3.Система должна предоставлять учет фотографий.

6.Система должна предоставлять по запросу пользователя формирование схемы (в масштабе глубин и времен) распространения ископаемых видов.

  1. Реализация ФТ – 3,6

5недель

1неделя




Приложение 2

Форма 1 «Паспорт коллекции»



Приложение 3

Форма 5 «Составление каталога»



Приложение 4
Прототип интерфейса «Регистрация коллекции»




Приложение 5

Прототип интерфейса «Главная форма»


Приложение 6

Прототип интерфейса «Регистрация образца коллекции»


Приложение 7

Прототип интерфейса «Загрузка фотографии»


Приложение 8

Прототип интерфейса «Учет результатов исследований»


Приложение 9

Прототип интерфейса «Формирование отчета»


Приложение 10

Прототип интерфейса «Схема»


Приложение 11

Рис. 1

(Шлифы на предметном столике микроскопа)

c:\documents and settings\admin\рабочий стол\gabbro_pmg_ss_2006.jpg
Рис. 2

(Микрофотография шлифа габбро при «скрещенных николях»)

c:\documents and settings\admin\рабочий стол\800px-thin_sections.jpg