Техническое задание как основа создания ис. Как правильно разработать техническое задание для автоматизированной системы. Требования к аппаратному обеспечению

ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы.Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85)

Дата введения с 01.01.1990г.

Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее - ТЗ на АС).

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

Дополнительно могут быть разработаны ТЗ на части АС:

• на подсистемы АС, комплексы задач АС и т. п. в соответствии с требованиями настоящего стандарта;
• на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП;
• на программные средства в соответствии со стандартами ЕСПД;
• на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

Примечание. В ТЗ на АСУ для группы взаимосвязанных объектов следует включать только общие для группы объектов требования. Специфические требования отдельного объекта управления следует отражать в ТЗ на АСУ этого объекта.

1.3. Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают.

1.4. Включаемые в ТЗ на АС требования должны соответствовать современному уровню развития науки и техники и не уступать аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам. Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений.

1.5. ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС», установленной ГОСТ 24.601.

1.6. В ТЗ на АС включают только те требования, которые дополняют требования к системам данного вида (АСУ, САПР, АСНИ и т. д.), содержащиеся в действующих НТД, и определяются спецификой конкретного объекта, для которого создается система.

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с... ».

2. СОСТАВ И СОДЕРЖАНИЕ

2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

• 1) общие сведения;
• 2) назначение и цели создания (развития) системы;
• 3) характеристика объектов автоматизации;
• 4) требования к системе;
• 5) состав и содержание работ по созданию системы;
• 6) порядок контроля и приемки системы;
• 7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
• 8) требования к документированию;
• 9) источники разработки.

В ТЗ на АС могут включаться приложения.

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

В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом.

2.3. В разделе «Общие сведения» указывают:

• 1) полное наименование системы и ее условное обозначение;
• 2) шифр темы или шифр (номер) договора;
• 3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
• 4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
• 5) плановые сроки начала и окончания работы по созданию системы;
• 6) сведения об источниках и порядке финансирования работ;
• 7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

2.4. Раздел «Назначение и цели создания (развития) системы» состоит из подразделов:

• 1) назначение системы;
• 2) цели создания системы.

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

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

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

2.5. В разделе «Характеристики объекта автоматизации» приводят:

• 1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
• 2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Примечание : Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

2.6. Раздел «Требования к системе» состоит из следующих подразделов:

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

Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида.

2.6.1. В подразделе «Требования к системе в целом» указывают:

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

2.6.1.1. В требованиях к структуре и функционированию системы приводят:

• 1) перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы;
• 2) требования к способам и средствам связи для информационного обмена между компонентами системы;
• 3) требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.);
• 4) требования к режимам функционирования системы;
• 5) требования по диагностированию системы;
• 6) перспективы развития, модернизации системы.

2.6.1.2. В требованиях к численности и квалификации персонала на АС приводят:

• требования к численности персонала (пользователей) АС;
• требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков;
• требуемый режим работы персонала АС.

2.6.1.3. В требованиях к показателям назначения АС приводят значения параметров, характеризующие степень соответствия системы ее назначению.

Для АСУ указывают:

• степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления;
• допустимые пределы модернизации и развития системы;
• вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

2.6.1.4. В требования к надежности включают:

• 1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;
• 2) перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности, и значения соответствующих показателей;
• 3) требования к надежности технических средств и программного обеспечения;
• 4) требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

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

2.6.1.6. В требования по эргономике и технической эстетике включают показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала.

2.6.1.7. Для подвижных АС в требования к транспортабельности включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам.

2.6.1.8. В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают:

• 1) условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания;
• 2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.;
• 3) требования по количеству, квалификации обслуживающего персонала и режимам его работы;
• 4) требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов;
• 5) требования к регламенту обслуживания.

2.6.1.9. В требования к защите информации от несанкционированного доступа включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.

2.6.1.10. В требованиях по сохранности информации приводят перечень событий: аварий, отказов технических средств (в том числе - потеря питания) и т. п., при которых должна быть обеспечена сохранность информации в системе.

2.6.1.11. В требованиях к средствам защиты от внешних воздействий приводят:

• 1) требования к радиоэлектронной защите средств АС;
• 2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

2.6.1.13. В требования к стандартизации и унификации включают: показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1, общесоюзных классификаторов технико-экономической информации и классификаторов других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.

2.6.1.14. В дополнительные требования включают:

• 1) требования к оснащению системы устройствами для обучения персонала (тренажерами, другими устройствами аналогичного назначения) и документацией на них;
• 2) требования к сервисной аппаратуре, стендам для проверки элементов системы;
• 3) требования к системе, связанные с особыми условиями эксплуатации;
• 4) специальные требования по усмотрению разработчика или заказчика системы.

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

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

при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;

2) временной регламент реализации каждой функции, задачи (или комплекса задач);

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

4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.

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

2.6.3.2. Для информационного обеспечения системы приводят требования:

• 1) к составу, структуре и способам организации данных в системе;
• 2) к информационному обмену между компонентами системы;
• 3) к информационной совместимости со смежными системами;
• 4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии;
• 5) по применению систем управления базами данных;
• 6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
• 7) к защите данных от разрушений при авариях и сбоях в электропитании системы;
• 8) к контролю, хранению, обновлению и восстановлению данных;
• 9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

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

2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:

• 1) к независимости программных средств от используемых СВТ и операционной среды;
• 2) к качеству программных средств, а также к способам его обеспечения и контроля;
• 3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

2.6.3.5. Для технического обеспечения системы приводят требования:

• 1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;
• 2) к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы.

2.6.3.6. В требованиях к метрологическому обеспечению приводят:

• 1) предварительный перечень измерительных каналов;
• 2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;
• 3) требования к метрологической совместимости технических средств системы;
• 4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;
• 5) требования к метрологическому обеспечению технических и программных средств, входящих в состав измерительных каналов системы, средств, встроенного контроля, метрологической пригодности измерительных каналов и средств измерений, используемых при наладке и испытаниях системы;
• 6) вид метрологической аттестации (государственная или ведомственная) с указанием порядка ее выполнения и организаций, проводящих аттестацию.

2.6.3.7. Для организационного обеспечения приводят требования:

1) к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию;

2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

3) к защите от ошибочных действий персонала системы.

2.6.3.8. Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т. п.).

2.7. Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.

В данном разделе также приводят:

• 1) перечень документов, по ГОСТ 34.201-89 , предъявляемых по окончании соответствующих стадий и этапов работ;
• 2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);
• 3) программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
• 4) перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).

2.8. В разделе «Порядок контроля и приемки системы» указывают:

• 1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);
• 2) общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
• З) статус приемочной комиссии (государственная, межведомственная, ведомственная).

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

В перечень основных мероприятий включают:

• 1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
• 2) изменения, которые необходимо осуществить в объекте автоматизации;
• 3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
• 4) создание необходимых для функционирования системы подразделений и служб;
• 5) сроки и порядок комплектования штатов и обучения персонала.

Например, для АСУ приводят:

• изменения применяемых методов управления;
• создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

2.10. В разделе «Требования к документированию» приводят:

• 1) согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли заказчика;
  перечень документов, выпускаемых на машинных носителях;
  требования к микрофильмированию документации;
• 2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
• 3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

2.11. В разделе «Источники разработки» должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

2.12. В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

• 1) расчет ожидаемой эффективности системы;
• 2) оценку научно-технического уровня системы.

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.

3. ПРАВИЛА ОФОРМЛЕНИЯ

3.1. Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд. 2 настоящего стандарта.

3.2. ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105.95 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней.

Номера листов (страниц) проставляют, начиная с первого листа, следующего за титульным листом, в верхней части листа (над текстом, посередине) после обозначения кода ТЗ на АС.

3.3. Значения показателей, норм и требований указывают, как правило, с предельными отклонениями или максимальным и минимальным значениями. Если эти показатели, нормы, требования однозначно регламентированы НТД, в ТЗ на АС следует приводить ссылку на эти документы или их разделы, а также дополнительные требования, учитывающие особенности создаваемой системы. Если конкретные значения показателей, норм и требований не могут быть установлены в процессе разработки ТЗ на АС, в нем следует сделать запись о порядке установления и согласования этих показателей, норм и требований:

«Окончательное требование (значение) уточняется в процессе...и согласовывается протоколом с... на стадии...».

При этом в текст ТЗ на АС изменений не вносят.

3.4. На титульном листе помещают подписи заказчика, разработчика и согласующих организаций, которые скрепляют гербовой печатью. При необходимости титульный лист оформляют на нескольких страницах. Подписи разработчиков ТЗ на АС и должностных лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, помещают на последнем листе.

Форма титульного листа ТЗ на АС приведена в приложении 2. Форма последнего листа ТЗ на АС приведена в приложении 3.

3.5. При необходимости на титульном листе ТЗ на АС допускается помещать установленные в отрасли коды, например: гриф секретности, код работы, регистрационный номер ТЗ и др.

3.6. Титульный лист дополнения к ТЗ на АС оформляют аналогично титульному листу технического задания. Вместо наименования «Техническое задание» пишут «Дополнение № ... к ТЗ на AC ... ».

3.7. На последующих листах дополнения к ТЗ на АС помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.

3.8. При изложении текста дополнения к ТЗ следует указывать номера соответствующих пунктов, подпунктов, таблиц основного ТЗ на АС и т. п. и применять слова: «заменить», «дополнить», «исключить», «изложить в новой редакции».

ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

1. Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.).

При конкурсной организации работ варианты проекта ТЗ на АС рассматриваются заказчиком, который - либо выбирает предпочтительный, вариант, либо на основании сопоставительного анализа подготавливает с участием будущего разработчика АС окончательный вариант ТЗ на AC.

2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС,

Работу по согласованию проекта ТЗ на AC осуществляют совместно разработчик ТЗ на АС и заказчик системы, каждый в организациях своего министерства (ведомства).

3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

4. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС.

5. Если при согласовании проекта ТЗ на АС возникли разногласия между разработчиком и заказчиком (или другими заинтересованными организациями), то составляется протокол разногласий (форма произвольная) и конкретное решение принимается в установленном порядке.

6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на этот документ.

7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы.

8. ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой нормоконтроля организации - разработчика ТЗ и, при необходимости, подвергнуто метрологической экспертизе.

9. Копии, утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы.

10. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.

11. Изменения к ТЗ на АС не допускается утверждать после представления системы или ее очереди на приемо-сдаточные испытания.

12. Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии, с требованиями ГОСТ 2.501.

ФОРМА ТИТУЛЬНОГО ЛИСТА ТЗ НА АС

________________________________________________________

наименование организации - разработчика ТЗ на АС УТВЕРЖДАЮ Руководитель (должность, наименование предприятия - заказчика АС) Личная подпись Расшифровка подписи Печать Дата УТВЕРЖДАЮ Руководитель (должность, наименование предприятия - разработчик” АС) Личная подпись Расшифровка подписи Печать Дата ________________________________________________________ наименование вида АС ________________________________________________________ наименование объекта автоматизации ________________________________________________________ сокращенное наименование АС ТЕХНИЧЕСКОЕ ЗАДАНИЕ На ____ листах Действует с СОГЛАСОВАНО Руководитель (должность, наименование согласующей организации) Личная подпись Расшифровка подписи Печать Дата

ФОРМА ПОСЛЕДНЕГО ЛИСТА ТЗ НА АС

(код ТЗ)

СОСТАВИЛИ СОГЛАСОВАНО

ПРИЛОЖЕНИЕ 4
Справочное

ПОЛОЖЕНИЯ ПО СОЗДАНИЮ ЕДИНОГО КОМПЛЕКСА СТАНДАРТОВ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

1. Исходные предпосылки создания комплекса

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

1.2. В период принятия Госстандартом СССР решения о совершенствовании межотраслевых комплексов стандартов действовали следующие комплексы и системы стандартов, устанавливающие требования к различным видам АС:

• 1) единая система стандартов автоматизированных систем управления (24-я система), распространяющаяся на АСУ, АСУП, АСУ ТП и другие организационно-экономические системы;
• 2) комплекс стандартов (система 23501); распространяющихся на системы автоматизированного проектирования;
• 3) четвертая группа 14-й системы стандартов, распространяющаяся на автоматизированные системы технологической подготовки производства.

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

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

1.5. В настоящее время осуществляется переход к созданию сложных АС (за рубежом системы CAD - САМ), включающих в свой состав АСУ технологическими процессами и производствами, САПР - конструктора, САПР - технолога, АСНИ и др. системы. Использование противоречивых правил при создании таких систем приводит к снижению качества, увеличению стоимости работ, затягиванию сроков ввода АС в действие.

1.6. Единый комплекс стандартов и руководящих документов должен распространяться на автоматизированные системы различного назначения: АСНИ, САПР, ОАСУ, АСУП, АСУТП, АСУГПС, АСК, АСТПП, включая их интеграцию.

1.7. При разработке межотраслевых документов следует учитывать следующие особенности АС как объектов стандартизации:

• 1) техническое задание является основным документом, в соответствии с которым проводят создание АС и приемку его заказчиком;
• 2) АС, как правило, создают проектным путем с комплектацией изделиями серийного и единичного производства и проведением строительных, монтажных, наладочных и пусковых работ, необходимых для ввода в действие АС;
• 3) в общем случае АС (подсистема АС) состоит из программно-технических (ПТК), программно-методических комплексов (ПМК) и компонентов технического, программного и информационного обеспечений.
  Компоненты этих видов обеспечения, а также ПМК и ПТК должны изготовляться и поставляется как продукция производственно-технического назначения.
  Компоненты могут входить в АС в качестве самостоятельных частей или могут быть объединены в комплексы;
• 4) создание АС в организациях (предприятиях) требует специальной подготовки пользователей и обслуживающего персонала системы;
• 5) функционирование АС и комплексов обеспечивается совокупностью организационно-методических документов, рассматриваемых в процессе создания как компоненты правового, методического, лингвистического, математического, организационного и др. видов обеспечений. Отдельные решения, получаемые в процессе разработки этих обеспечений, могут реализовываться в виде компонентов технического, программного или информационного обеспечений;
• 6) совместное функционирование и взаимодействие различных систем и комплексов осуществляется на базе локальных сетей ЭВМ.

Спецификации и соглашения, принятые для локальных сетей ЭВМ, обязательны для обеспечения совместимости систем, комплексов и компонентов.

2. Взаимосвязь ЕКС АС с другими системами и комплексами стандартов

2.1. Стандартизация в области АС является составной частью работ по обобщенной проблеме «Информационная технология».

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

2.3. ЕКС АС должен охватывать специфические для автоматизированных систем направления стандартизации и распространять традиционные направления стандартизации на программно-технические, программно-методические комплексы и автоматизированные системы в целом.

2.4. Направления и задачи стандартизации при нормативно-техническом обеспечении процессов создания и функционирования АС группируют следующим образом:

• 1) установление технических требований к продукции;
• 2) регламентация методов испытаний и правил аттестации и сертификации продукции;
• 3) регламентация правил и порядка разработки;
• 4) установление правил документирования;
• 5) обеспечение совместимости;
• 6) регламентация организационно-методических вопросов функционирования систем.

Направления 1-4 являются традиционными при разработке, изготовлении и поставке продукции. Направления 5, 6 являются специфичными и вытекают из особенностей, присущих АС.

2.5. Обеспеченность АС в целом и их составных частей нормативно-технической документацией в рамках принятых направлений и задач стандартизации различна.

Компоненты технического, программного и информационного обеспечений, как продукцию производственно-технического назначения, рассматривают, соответственно, как конструкторские, программные и информационные изделия. На эти изделия распространяются действующие комплексы стандартов ЕСКД, СРПП, ЕСПД, СГИП, УСД, классификаторы и кодификаторы технико-экономической информации, комплексы стандартов вида «ОТТ», «Методы испытаний», «ТУ», а также ОТТ заказчика.

2.5.1. Весь жизненный цикл конструкторских изделий полностью обеспечен нормативно-технической документацией, действующей в машиностроении и приборостроении.

2.5.2. Программные изделия обеспечены НТД, входящей в ЕСПД и ОТТ заказчика. Однако область распространения этих НТД должна быть расширена с целью отражения вопросов, связанных с разработкой, созданием, распространением и эксплуатацией программных изделий.

2.5.3. Информационные изделия в настоящее время не обеспечены НТД, хотя отдельные вопросы проработаны в рамках УСД, классификаторах и кодификаторах технико-экономической информации.

2.6. Программно-технические и программно-методические комплексы рассматриваются как сложные изделия, не имеющие аналогов в машиностроении. Учитывая статус ПТК и ПМК как продукции производственно-технического назначения, правила и порядок их разработки должен быть аналогичен требованиям, установленным стандартами системы разработки и постановки продукции на производство (СРПП).

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

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

Техническое задание - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки ИС. ТЗ на ИС является основным документом, определяющим требования и порядок создания, развития или модернизации ИС, в соответствии с которым проводится её разработка, ввод в действие и приёмка.

Успех в реализации ИС заключается в правильности поставленной задачи заказчиком. Если все необходимые условия для написания хорошего ТЗ выполнены, то тогда результат из ожидаемого превратится в выполнимый.

силами самого заказчика;

силами исполнителя, но в таком случае, в его обязанности войдет проектирование и проведение испытаний;

конкурсными исполнителями, чьи обязанности включают только написание ТЗ;

силами сторонних исполнителей.

Для тех ТЗ, которые пишутся исполнителем, существует ряд нормативной документации:

ГОСТ 21.408-93 «Правила выполнения рабочей документации автоматизации технологических процессов»;

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

ГОСТ 24.703-85 «Типовые проектные решения в АСУ. Основные положения»;

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

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

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

ГОСТ 19.201- 78 Единая система программной документации;

ГОСТ 2.114-95 Единая система конструкторской документации.

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

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

Определенных рекомендаций по тому, что должно содержать ТЗ нет, значит разделы и подразделы должны быть разработаны и размещены в порядке, установленном исполнителем. Существуют лишь общие характеристики разделов и подразделов. Разработчик может самостоятельно изменять, добавлять и редактировать их наименование и количество.

Номера листов (страниц) проставляют, начиная с первого листа, следующего за титульным листом, в верхней части листа (над текстом, посредине) после обозначения кода ТЗ на ИС.

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

Титульный лист дополнения к ТЗ оформляют аналогично титульному листу технического задания. Вместо наименования «Техническое задание» пишут «Дополнение №... к ТЗ на AC... »

На последующих листах дополнения к ТЗ помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.

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

На начальном этапе разработки ТЗ исполнитель создает примерный план содержания.

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

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

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

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

Условия эксплуатации;

Требования к программной документации;

Технико-экономические показатели;

Стадии и этапы разработки;

Порядок контроля и приемки.

Данные разделы могут быть разделены на подразделы. Так же в ТЗ могут включаться приложения, которые описываются по установленным стандартам. Исполнитель может добавлять удалять по необходимости нужные разделы, все эти факторы должны быть оговорены с заказчиком. Придерживаясь установленного плана, исполнитель может разработать ТЗ качественно и в краткие сроки.

При необходимости исполнитель создает список принятых сокращений и глоссарий.

Техническое задание на разработку ИС медицинского учреждения размещено в приложении Б.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

на разработку информационной системы

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

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

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

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

В соответствии с договором № МП23 между "ООО ТехноПлюс " (в дальнейшем Разработчик) и ООО ОптоТорговля (в дальнейшем Заказчик), Разработчик проектирует БД, разрабатывает и вводит в эксплуатацию информационную систему «Учет торговых операций»

Днем начала проектирования БДБ считается день, следующий после под­пи­са­ния данного Технического задания

Если в процессе разработки Заказчик изменяет описанные в данном до­ку­мен­те требования, то они оформляются отдельным документом и влекут за собой из­ме­не­ние или дополнение Договора между Заказчиком и Разработчиком БД в части срока выполнения и оплаты договора

Заказчик оплачивает работы Разработчика БД в соответствии с договором N XXX

2. Назначение и цели создания (развития) системы

ИС «Учет торговых операций» предназначена для хранения, обработки и анализа информации, относящейся к основной деятельности Заказчика.

Целью создания ИС «Учет торговых операций» является:

Хранение информации о совершенных торговых операциях;

Отражение торговых операций в бухгалтерском учете ;

Анализ финансовых результатов торговых операций;

Анализ торговой деятельности в разрезе номенклатура и контрагенты .

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

3.1. Основной деятельностью Заказчика является торговля мебелью и сопутствующими товарами по безналичному расчету .

3.2. Заказчик не является плательщиком НДС

3.3. За день Заказчик совершает не более 100 торговых операций по покупке и продаже товаров.

3.4. Общий объем номенклатуры товаров не превышает 3000 единиц

3.5. Общее количество контрагентов - поставщиков не более 100 единиц.

3.6. Количество контрагентов – покупателей – не ограничено. На момент подписание договора N XXX составляло 300 единиц.

3.7. Списывание товаров со склада Заказчик осуществляет по методу средневзвешенной стоимости.

3.9. В качестве счетов расходов используются только счета класса 9.

3.10. Фінансові результати торгівельної діяльності підприємства (прибутковість чи збитковість операцій) визначаються на основі різниці рахунків 702 та 902.

3.11. Совершение торговых операция регистрируются в первичных документах Приходная накладная, Расходная накладная, Банковская выписка.

Прибуткова накладна (ПН) відображує факт надходження товару на склад підприємства та містить таку інформацію:

– номер;

– дату;

– ім’я контрагента (фірми - постачальника);

– найменування товару;

– кількість;

– ціну одиниці товару;

– суму.

Видаткова накладна (ВН) відображує факт відвантаження товару зі складу підприємства покупцю та містить інформацію, схожу на інформацію в ПН (лише замість фірми-постачальника вказується фірма-покупець).

Рядок банківської виписки підтверджує факт надходження/вибуття коштів із розрахункового рахунку (р/р) підприємства та містить таку інформацію:

– дату;

– ознаку приходу/витрати коштів;

– ім’я контрагента (від кого надійшли / кому перераховано кошти).

3.12. Кожний первичный документ є підставою для здійснення певних проводок, які здійснюють зміни певних бухгалтерських рахунків. Операції торгівельного підприємства викликають такі проводки (табл.3.1)

Таблица 3.1 – Проводки, используемые в бухгалтерском учете на предприятии Заказчика

Операция	Документ	Дебет счета	Кредит счета	Сумма проводки
Оприходование	Приходная накладная			сумма документа
Отгрузка товара	Расходная накладная			сумма документа
				себестоимость отгруженного товара
Поступление денег на расчетный счет	Банковская выписка (приходная)			сумма документа
Перечисление денег с расчетного счета	Банковская выписка (расходная)			сумма документа
Определение финансовых результатов				на сумму закрытия 902 счета
				на сумму закрытия 702 счета

де 281 – товари на складі;

311 – розрахунковий рахунок у вітчизняній валюті;

361 – розрахунки з вітчизняними покупцями;

631 – розрахунки з вітчизняними постачальниками;

702 – доход від реалізації товару;

902 – собівартість реалізованих товарів (витрати).

3.13. У якості бухгалтерської звітності використовується оборотно-сальдова відомість синтетичного обліку вигляду як у таблиці 3.2.

Таблиця 3.2 – Оборотно-сальдова відомість синтетичного обліку

Номер позиції	Сальдо початкове	Обороти	Сальдо кінцеве
Разом

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

ИС «Учет торговых операций» должна отвечать следующим требованиям:

4.1. БД для ИС «Учет торговых операций» должна обеспечивать хранение, отображение и редактирование справочной и оперативной информации.

Справочная информация:

o описание товаров:

Номер номенклатуры (товара);

Название товара;

Описание;

o контрагенты – поставщики;

Номер контрагента;

Имя контрагента;

Адрес контрагента;

Контакты;

o контрагенты – покупатели;

Номер контрагента;

Имя контрагента;

Адрес контрагента;

Контакты;

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

o перечень базовых проводок для отображения торговых операций в бухгалтерском учете, вызванных первичными документами, которые имеют следующий вид, как в таблице3.1;

Оперативная информация:

o Первичные документы: Приходная накладная, Расходная накладная, Банковская выписка (описание документов приведено в 3.11)

o Бухгалтерские проводки, вызванные первичными документами (вид проводок приведен в таблице 3.2)

o Информация о товарах на складе:

Номер товара;

Количество;

Сумма;

Средняя цена.

4.2. ИС «Учет торговых операций» должна позволять автоматизировать следующие действия:

4.2.1 Отражать факты оприходования (получения) и отгрузки товара на складе, а именно, пересчитывать количество товара на складе и его среднюю стоимость.

4.2.2 Формировать по первичным документам бухгалтерские проводки в автоматическом режиме.

4.2.3 Проводить поиск следующей информации:

Первичных документов указанного типа за определенный период;

Проводок для указанного типа документов за определенную дату;

Информации о контрагенте

Информации о товаре

4.2.4 Проводить анализ торговой деятельности за указанный период в следующих разрезах:

Финансовых результатов торговой деятельности;

Результатов расчетов по каждому контрагенту;

Остатков товаров на складе по каждому наименованию;

Стоимости сделок по каждому контрагенту;

Стоимости и количеству продаж по каждому виду товаров

4.2.5 Формировать отчеты за указанный период:

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

В ИС должны быть предусмотрены механизмы резервного копирования, ИС должна быть оснащена соответствующим оборудованием и программным обеспечением:

Количественные значения показателей надежности:

- время автоматического завершения работы должно быть не более 1 минуты;

- время восстановления после сбоя должно быть не более 30 минут;

- показатель отказоустойчивости ИС должен составлять 11/7, т. е. бесперебойной работы ИС 11часов в день 7 дней в неделю.

Обслуживание ИС должно производиться без прерывания ее работы.

4.5 Требования к методам оценки и контроля показателей надежности на стадии опытной эксплуатации

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

Дату возникновения ошибки;

Общую наработку объекта с начала его эксплуатации до момента выявления ошибки;

Внешние признаки и характер появления ошибки;

Вид работы, при которых была обнаружена ошибка.

4.6 Требования к производительности ИС

Система должна поддерживать возможность обрабатывать до 1000 документов в день

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

80% операций должны иметь время отклика (время выполнения операции) менее 1сек.;

15% операций – от 5сек. до 10сек;

5% операций - более 10сек, но не более 30мин.

4.7 Требования к объемам (масштабируемости)

Система должна поддерживать доступ к данным за 10 лет.

Предполагаемый прирост объема БД за один день эксплуатации 20Мб.

4.8 Требования к численности, функциям и квалификации персонала ИС и режиму его работы

Работу с ИС будет осуществлять следующий персонал Заказчика:

Администратор:

Количество: 1;

Квалификация: сетевой администратор, администратор баз данных ;

Функции: управление безопасностью системой, резервное копирование данных в начале каждого рабочего дня, архивирование данных один раз в год;

Режим работы: 1 час в день, 5 дней в неделю

Оператор (пользователь), фиксирующий факт торговой операции и анализирующих результаты торговой деятельности:

Количество: 2;

Квалификация: бухгалтер, пользователь ПК;

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

Режим работы: посменно для обеспечения работы системы 11 час в день 7 дней в неделю;

Доступ к работе: 8-й часовой курс обучения;

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

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

4.10 Требования к программному обеспечению и составу, структуре и способам организации БД ИС

Данные в Системе должны храниться в реляционной СУБД МS SQL Server 2000.

- T-SQL (диалект языка SQL);

С # .

Программное обеспечение состоит из общесистемного программного обеспечения, приобретаемого за счет средств Заказчика (покупных программных средств), и специального программного обеспечения, разрабатываемого в рамках работ по созданию ИС.

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

Операционная система;

Система управления базами данных МS SQL Server 2000;

Программное обеспечение для резервного копирования;

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

Сервер БД, 2 рабочие станции.

Пропускная способность сети - 100Мбит в сек.

4.12 Требования к перспективам развития, модернизации ИС

Должна быть предусмотрена возможность модернизации и развития ИС без привлечения Разработчика силами администратора ИС на уровне:

- добавления, изменения, удаления справочной информации ИС;

- подключения/удаления новых пользователей ИС;

- изменения паролей;

- импорт/экспорт данных из/во внешние источники данных.

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

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

Работы по проектированию ИС «Учет торговых операций» производятся в три этапа.

Первый этап включает в себя:

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

Проектирование БД ИС;

Заполнение разработанной БД тестовым набором данных;

Разработку дизайна интерфейса пользователя;

Разработка низкоуровневой технической спецификации на разработку ИС «Учет торговых операций»

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

Второй этап - разработка тестовой версии ИС «Учет торговых операций». Окончанием данного этапа является ввод тестовой версии в опытную эксплуатацию.

Третий этап - опытная эксплуатация ИС «Учет торговых операций», включающая в себя устранение выявленных ошибок, недоработок и несоответствий с данным Техническим заданием. Окончанием второго этапа является ввод ИС в промышленную эксплуатацию.

Окончание каждого второго и третьего этапа подтверждается Сторонами договора под­пи­са­нием Акта приема-передачи.

Длительность первого этапа составляет 10 дней. Началом первого этапа считается день, следующий за днем подписания Заказчиком и Разработчиком БД данного Технического задания.

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

Длительность третьего этапа составляет 20 дней. Началом третьего этапа считается день, следующий за днем подписания Заказчиком и Разработчиком БД Акта приема-передачи тестовой версии ИС в опытную эксплуатацию.

Набор данных для тестирования ИС пре­до­став­ля­ет Заказчик.

По окончанию второго этапа работ Разработчик БД устанавливает тестовую ИС на тестовый сервер Заказчика и предоставляет Заказчику предварительное руководство пользователя, содержащее описание процедур, необходимых для работы с ИС «Учет торговых операций». Описания предоставляются в электронном виде.

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

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

По окончанию первого этапа подписывается внутренний Акт о выполненной работе и утверждается низкоуровневая техническая спецификация на разработку ИС.

По окончанию второго и третьего этапов проектирования Разработчик устанавливает ИС у Заказчика, демонстрирует работу ИС в соответствии с требованиями, изложенными в данном Техническом задании, и подписывает Акт приема-передачи.

7. Требования к составу и содержанию работ по подготовке объ­ек­та автоматизации к вводу системы в действие

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

Отсутствие сервера для установки БД ИС «Учет торговых операций» не может являться основанием в отказе подписания Акта приема-передачи ИС «Учет торговых операций» в опытную или промышленную эксплуатацию.

В конце второго этапа по разработке ИС «Учет торговых операций» Разработчик проводит 8-часовой курс обучения с персоналом Заказчика по обслуживанию ИС. По окончанию данного курса персонал Заказчика проходит тестирование.

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

По окончанию третьего этапа Разработчик ИС «Учет торговых операций» передает Заказчику сле­дую­щую документацию:

1. Инструкцию программиста.

В Инструкции программиста описываются процедуры, необходимых для работы с ИС «Учет торговых операций». Описание процедур включает в себя:

Название процедуры;

Описание выполняемых процедурой действий;

Описание входных параметров, с указанием типа параметра, формата его записи и значения по умолчанию, если таковое определено для параметра;

Описание выходных параметров и (или) возвращаемых наборов записей с указанием их типов и форматов

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

2. Инструкцию по установке ИС «Учет торговых операций».

3. Инструкция пользователя ИС «Учет торговых операций».

Иная документация Заказчику не предоставляется. Ин­струк­ции пре­до­ставляются как в печатном, так и в электронном виде. Инструкции в печатном виде предоставляется в одном экземпляре.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

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

Размещено на http://www.allbest.ru/

• Введение
• 1. Техническое задание
• 1.1 Общие сведения
• 1.2 Основания для разработки
• 1.3 Назначение и цели создания системы
• 1.4 Требования к системе
• 1.4.1 Требования к системе в целом
• 1.4.2 Требования к функциям (задачам), выполняемым системой
• 1.4.3 Требования к видам обеспечения
• 1.5 Характеристика объектов автоматизации
• 1.6 Требования к документированию
• 1.7 Стадии и этапы разработки
• 1.7.1 Стадии разработки
• 1.7.2 Этапы разработки
• 1.7.3 Содержание работ по этапам
• 1.8 Порядок контроля и приемки системы
• 1.8.1 Виды, состав, объем и методы испытаний системы и ее составных частей
• 1.8.2 Общие требования к приемке работ по стадиям
• 1.8.3 Статус приемочной комиссии (государственная, межведомственная, ведомственная)
• 2. Технический проект
• 2.1 Функциональная структура
• 2.1.1 Описание предметной области
• 2.1.2 Функции и организационная структура
• 2.1.3 Описание потоков данных и бизнес процессов
• 2.2 Системное проектирование ИС
• 2.2.1 Разработка концепции, архитектуры построения и платформы реализации ИС
• 2.2.2 Структура информационной системы, состав функциональных и обеспечивающих подсистем
• 2.2.3 Техническое обеспечение ИС
• 2.3 Информационное обеспечение ИС
• 2.3.1 Описание логической структуры информационной базы
• 2.3.2 Описание физической реализации БД
• Заключение
• Список литературы

Введение

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

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

ТЗ состоит из трех стадий:

1. обоснование необходимости разработки информационной системы - постановка задачи, сбор исходных материалов, выбор и обоснование критериев эффективности и качества разработанной системы, обоснование необходимости проведения НИР;

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

3. разработка и утверждение ТЗ - определение требований к программам, разработка технико-экономического обоснования системы, определение стадий, этапов и сроков разработки системы и документация на нее, выбор языков программирования, определение необходимости проведения НИР на последних стадиях, согласование и утверждение ТЗ.

ТЗ выполняет следующие функции:

Организационная функция - зафиксированное задание для Исполнителя и окончательные требования со стороны Заказчика.

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

Коммуникационная функция - взаимная договоренность о "предмете проекта", исключающая претензий.

Юридическая функция - ТЗ имеет равную юридическую силу с "Договором".

От того полноты и точности составления ТЗ во многом зависит результат разрабатываемого технического проекта.

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

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

Полное наименование системы и ее условное обозначение: "Автоматизированная информационная система агентства по продаже и бронированию авиабилетов". Краткая характеристика области применения

Система предназначена для применения в организации заказчика, в нашем случае - агентство по продаже и бронированию авиабилетов.

Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы: АИС "Билет" поставляется в виде исполняемых модулей по завершению всего объема работ, технические средства приобретаются Заказчиком самостоятельно. Оформление результатов работ по созданию системы производится путем подписания акта о принятии системы Заказчиком при отсутствии претензий к Разработчику. Акт составляется в двух экземплярах. Один экземпляр находится у Заказчика, другой - у Разработчика.

1.2 Основания для разработки

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

Наименование темы разработки - "Разработка информационной системы агентства по продаже и бронированию авиабилетов"

Условное обозначение темы разработки (шифр темы) - "ИС АПБ"

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

Функциональное назначение системы: АИС "Билет" предназначена для автоматизации работы агентства по продаже и бронированию авиабилетов.

Эксплуатационное назначение системы: Система должна эксплуатироваться сотрудниками организации.

Цели создания системы: Система ускоряет процесс заказа авиабилетов, тем самым упрощает работу агентства.

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

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

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

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

АИС "Билет" включает следующие подсистемы:

Принятие заказа;

Оформление билета;

Расчет с заказчиком.

Подсистема "Принятие заказа" предназначена для регистрации заказа авиабилетов.

Подсистема "Расчет с заказчиком" обеспечивает заказчика номером брони, связанным с паспортными данными (оплата по карточке).

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

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

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

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

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

Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков:

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

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

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

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

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

Требования к безопасности

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

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

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

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

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

а) идентификацию и аутентификацию пользователя;

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

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

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

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

Для данной системы должна применяться каскадная модель жизненного цикла ПО.

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

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

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

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

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

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

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

Подсистема принятия заказа,

Подсистема расчета с клиентом.

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

К информационному обеспечению системы

К составу, структуре и способам организации данных в системе

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

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

Данные вводятся в систему вручную, обрабатываются и выдаются пользователю в требуемом виде (электронный, печатный).

К защите данных от разрушений при авариях и сбоях в электропитании системы

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

К контролю, хранению, обновлению и восстановлению данных

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

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

Система должна работать в операционных системах Windows XP/Vista/7/8

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

К видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе.

Рабочие станции;

Источник бесперебойного питания;

Среда передачи данных между рабочими станциями (например, витая пара UTP 5e);

Принтер.

Технические средства приобретаются Заказчиком самостоятельно.

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

Процессор Intel Pentium IV 2 ГГц и выше, оперативная память не менее 2Гб, объем жесткого диска не менее 500 Гбайт.

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

Для организационного обеспечения приводят требования:

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

Функционирование системы обеспечивает инженер-системотехник, в эксплуатации участвуют 4 сотрудника.

К организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации.

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

К защите от ошибочных действий персонала системы.

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

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

Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию

В качестве объекта автоматизации выступает процесс, связанный с заказом авиабилетов.

Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды

Данная система будет установлена в производственных и офисных помещениях.

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

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

Схема организационной структуры;

Схема функциональной структуры;

Перечень входных сигналов и данных;

Перечень выходных сигналов (документов);

Пояснительная записка к техническому проекту;

Описание автоматизируемых функций;

Описание постановки задач (комплекса задач);

Описание организации информационной базы;

Описание массива информации;

Описание программного обеспечения;

Руководство пользователя.

1.7 Стадии и этапы разработки

1.7.1 Стадии разработки

Разработка должна быть проведена в 6 стадий:

1. Разработка технического задания

2. Разработка проектной документации

3.Создание эскизного проекта

4. Рабочее проектирование

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

6. Сопровождение и модернизация

1.7.2 Этапы разработки

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

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

На стадии создания эскизного проекта должен быть выполнен эскизный проект для предварительного предоставления заказчику.

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

1) разработка информационной системы;

2) разработка документации.

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

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

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

1) постановка задачи;

2) определение и уточнение требований к техническим средствам;

3) определение требований к информационной системе;

4) определение стадий, этапов и сроков разработки информационной системы и документации на неё;

5) обоснование и выбор инструментария;

6) согласование и утверждение технического задания.

На этапе разработки проектной документации должны быть выполнены перечисленные ниже работы:

1) определение основных бизнес-процессов (в виде диаграмм IDEF0);

2) определение основных вариантов использования Системы для трех категорий пользователей (Гость, Авторизованный пользователь, Администратор) в виде UML диаграмм вариантов использования;

3) проектирование структуры базы данных в виде (ER диаграммы);

4) проектирование основных компонентов и алгоритмов Системы в виде соответствующих UML диаграмм;

5) проектирование структуры пользовательского интерфейса;

6) согласование и утверждение проектной документации.

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

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

На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию.

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

1. Анализ требований к ИС

2. Согласование требований с заказчиком

3. Выбор и разработка варианта концепции системы

4. Разработка технического задания и проекта

5. Согласование и утверждение технического задания и проекта

6. Составление плана по проведению работ

7. Подготовка аппаратного обеспечения

8. Разработка ПО

9. Проверка на совместимость аппаратного и программного обеспечения

10. Интеграция и тестирование программного и аппаратного обеспечения

11. Внесение изменений

12. Разработка инструкций по эксплуатации ИС

13. Оформление полной документации на ИС

14. Сдача ИС заказчику

Таблица 1 - Исходные данные для расчета

№ работы	Перечень работ	Продолжительность работы, дни
	1.Анализ требований к ИС
	2.Согласование требований с заказчиком
	3.Выбор и разработка варианта концепции системы
	4.Разработка технического задания и проекта
	5.Согласование и утверждение технического задания и проекта
	6.Составление плана по проведению работ
	7.Подготовка аппаратного обеспечения
	8.Разработка ПО
	9.Проверка на совместимость аппаратного и программного обеспечения
	10.Интеграция и тестирование программного и аппаратного обеспечения
	11.Внесение изменений
	12.Разработка инструкций по эксплуатации ИС
	13.Оформление полной документации на ИС
	14.Сдача ИС заказчику

Рисунок 1 - Постановка задач

Рисунок 2 - Диаграмма Ганта

Рисунок 3 - Сетевой график выполнения работ

Критический путь сетевого графика будет следующим: 0 1 2 3 4 5 6891011121314

Таблица 2 - Временные параметры событий

Номер события	Сроки совершения события	Резерв времени

Таблица 3 - Расчет полного и свободного резервов времени

	Продолжительность, дни	Временные параметры работ, дни	Полный резерв	Свободный резерв
		раннее начало	Раннее окончание	Позднее начало	Позднее окончание

1.8 Порядок контроля и приемки системы

1.8.1 Виды, состав, объем и методы испытаний системы и ее составных частей

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

1.8.2 Общие требования к приемке работ по стадиям

Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной комиссии.

Все создаваемые в рамках настоящей работы программные изделия передаются Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (на компакт-диске).

1.8.3 Статус приемочной комиссии (государственная, межведомственная, ведомственная)

Статус приемочной комиссии определяется Заказчиком до проведения испытаний.

2. Технический проект

2.1 Функциональная структура

2.1.1 Описание предметной области

Предметной областью является агентство по продаже и бронированию авиабилетов

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

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

2.1.2 Функции и организационная структура

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

Агенство "Билет" состоит из следующих отделов:

Директор;

Административный отдел;

Отдел эксплуатации рабочих станций;

Отдел операторов.

Организационная структура предприятия отражена на рисунке 4.

Рисунок 4 - Организационная модель

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

Отдел производства осуществляет разработку проекта изделие, его последующее изготовление и сборку.

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

Отдел эксплуатации рабочих станций отвечает за работоспособность системы.

Операторы отвечают за принятие заказа, ввод данных в базу.

2.1.3 Описание потоков данных и бизнес процессов

Моделирование бизнес-процессов

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

Проанализировав деятельность агенства, и проведя пред-проектное исследование, можно выделить три основных бизнес-процесса АИС "Билет":

1. Принятие заказа.

2. Выдача идентификационного номера.

3. Расчет с заказчиком.

Функциональное моделирование бизнес-процессов представлено методологией IDEF0. Она описывает те деловые процессы, которые протекают в объекте автоматизации. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в IDEF0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе. Можно выделить четыре типа диаграмм:

Контекстную диаграмму А-0 (в каждой модели может быть только одна контекстная диаграмма);

Диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А 0, раскрывающая контекстную);

Диаграммы дерева узлов;

Диаграммы только для экспозиции (FEO).

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

Главная бизнес-функция "АИС Билет" - продажа авиабилетов. Входными данными является заказ билетов. Выходными - квитанция. Инструментами выполнения главной бизнес-функции служат сотрудники ОАО "Билет" (бухгалтер, менеджер, IT-техники, операторы).

Диаграмма потоков данных

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

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

В DFD работы (процессы) представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.

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

Потоки работ изображаются стрелками и описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями.

В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое.

2.2 Системное проектирование ИС

техзадание калькуляция трудозатраты бронирование

2.2.1 Разработка концепции, архитектуры построения и платформы реализации ИС

Основными аспектами при выборе архитектуры построения ИС являются быстродействие, надежность, масштабируемость и безопасность.

В настоящее время наиболее распространенными архитектурами являются:

­ файл-сервер;

­ клиент-сервер;

­ многоуровневая архитектура.

Файл-серверная архитектура подразумевает под собой то, что сервер возлагает на себя лишь функцию хранения данных, а обработка производится на клиентских машинах. Это означает, что данные необходимо передавать по сети, что приведет к сильной загрузке сетевого трафика. А это в свою очередь приведет к снижению производительности при увеличении числа пользователей. Также при реализации архитектуры файл-сервер, проблема целостности, согласованности и одновременного доступа к данным решается децентрализовано: данные хранятся на сервере, а обрабатываются на клиенте. Вследствие этого снижается надежность приложения. Еще одним недостатком являются высокие затраты на модернизацию и сопровождение сервисов бизнес - логики на каждой клиентской рабочей станции. Однако данная архитектура обладает и рядом преимуществ, таких как низкая стоимость разработки, высокая скорость разработки и невысокая стоимость обновления и изменения программного обеспечения.

Архитектура клиент-сервер лишена недостатков вышеописанной архитектуры, т.к. сервер баз данных не только обеспечивает доступ к общим данным, но и выполняет их обработку. Клиент посылает на сервер запросы, на языке "понятном" серверу, а он в свою очередь обрабатывает запрос, контролируя при этом целостность и согласованность данных, и возвращает на клиент результат отработанного запроса. В результате нагрузка на сеть снижается: клиенту больше не нужно обрабатывать промежуточные данные. Хранение и обработка производится централизовано, поэтому данная архитектура надежнее архитектуры файл-сервер. К недостаткам клиент-серверной архитектуры относятся, во-первых, достаточная сложность разработки системы из-за необходимости исполнять бизнес-логику и обеспечивать интерфейс с пользователем в одной программе и высокие требования к рабочим станциям по той же причине.

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

­ масштабируемость;

­ конфигурируемость - изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

­ высокая безопасность;

­ высокая надёжность;

­ низкие требования к скорости канала (сети) между терминалами и сервером приложений;

­ низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.

Однако, несмотря на неоспоримые достоинства, данная система не получила распространения, по следующим причинам:

­ сложность разработки систем на основе многоуровневой архитектуры, т.к очень сложно "состыковать" различные модули, особенно если они написаны разными группами. А изменение в одном модуле, как правило, вызывает лавинообразные изменения в остальных, и с этой точки зрения даже простую систему, основанную на многоуровневой архитектуре, будет сложнее выполнить в 2 раза;

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

­ высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений;

­ высокая сложность администрирования.

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

Схема функционирования и построения информационной системы представлена рисунке 5.

Рисунок 5 - Архитектура "клиент-сервер"

2.2.2 Структура информационной системы, состав функциональных и обеспечивающих подсистем

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

Информационная;

Техническая;

Программная;

Математическая;

Лингвистическая.

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

Состав обеспечивающих подсистем не зависит от выбранной предметной области и имеет:

Функциональную структуру;

Информационное обеспечение;

Математическое (алгоритмическое и программное) обеспечение;

Техническое обеспечение;

Организационное обеспечение,

а на стадии разработки ИС дополнительные обеспечения:

Правовое;

Лингвистическое;

Технологическое;

Методологическое;

Интерфейсы с внешними ИС.

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

Математическое обеспечение состоит из алгоритмического и программного.

Организационное обеспечение - это совокупность средств и методов организации производства и управления ими в условиях внедрения ИС.

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

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

2.2.3 Техническое обеспечение ИС

В комплекс технических средств должны входить следующие элементы:

Рабочие станции;

Источники бесперебойного питания;

Средства для построения ЛВС;

Сервер БД;

Принтер.

Требования к серверу:

Память 8 Гб;

Процессор 2.2 ГГц Intel Xeon 5500 минимум;

Скорость диска SATA 8 Гбит/с;

Сетевой адаптер 10 Гбит/с;

Операционная система Windows Server 2008.

Требования к рабочей станции:

Процессор 2 Ггц;

Память 2 Гб;

Жесткий диск не менее 500;

Операционная система Windows 7;

Сетевой адаптер 100 Мбит/с.

Технические средства ИС описаны с учетом требований к функционированию прикладного пpогpаммного комплекса. Технические средства должны обеспечить:

Круглосуточный режим работы комплекса технических средств и оборудования;

Гарантированное выполнение всего комплекса программного обеспечения в случае сбоя или выхода из строя части оборудования;

Защиту данных от несанкционированного доступа;

Сервера и рабочие места должны быть объединены локальной сетью.

На рисунке 2.3 представлена топология локальной вычислительной сети (ЛВС) для ОАО "Билет".

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

Рисунок 6 - Логическая схема сети ОАО "Заказчик"

2.3 Информационное обеспечение ИС

2.3.1 Описание логической структуры информационной базы

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

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

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

Исключение некоторых типов избыточности;

Устранение некоторых аномалий обновления;

Разработка проекта базы данных, который является достаточно "качественным" представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;

Упрощение процедуры применения необходимых ограничений целостности.

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

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

2.3.2 Описание физической реализации БД

Физическое проектирование - создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.

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

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

Заключение

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

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

В соответствии с поставленными задачами технического задания были выполнены следующие этапы создания технического проекта:

- выполнен анализ предметной области;

- разработана функциональная схема АИС "Билет";

- разработана концепция, выбраны архитектура построения и платформа реализации системы;

1. спроектирована концептуальная модель АИС "Билет";

2. спроектирована логическая модель системы АИС "Билет" на основе концептуальной модели;

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

Список литературы

1. ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

2. ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

3. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов

4. В.П. Романов, Н.З. Емельянова, Т.Л. Партыка Проектирование экономических информационных систем. Методологии и современные технологии. - М: Экзамен, 2005.- 256 с.;

5. Маклаков С.В. BPWin и ERWin CASE - средства разработки информационных систем / Маклаков С.В. - М: ДИАЛОГ МИФИ, 2001.-256с.;

6. Бойко В.В. Проектирование баз данных информационных систем / Бойко В.В., Савинков В.М. - 2-е изд. - М.: Финансы и статистика, 1989. - 350 с.

Размещено на Allbest.ru

...

Подобные документы

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

дипломная работа , добавлен 11.07.2015


Нормативно-правовые акты Российской Федерации в области информационной безопасности. Порядок организации работ по защите информации в информационных системах. Общий подход к разработкам технического задания на разработку системы защиты этой сферы.

курсовая работа , добавлен 05.05.2015


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

курсовая работа , добавлен 13.05.2015


Создание информационной системы "Голд", автоматизирующей работу Ювелирной мастерской. Моделирование бизнес-процессов с помощью диаграмм IDEF0 и UML и потоков данных DFD и sicuence. Составление технического проекта и задания на основании ГОСТ 34.602-89.

курсовая работа , добавлен 10.02.2013


Cостав экспертной системы. Требования к комплексу технических средств. Структура и организация технического обеспечения автоматической информационной системы. Техническая документация на разработку программных средств и способы их использования.

реферат , добавлен 09.10.2014


Изучение языков программирования PHP, SQL, C++, HTML. Рассмотрение правил запуска и использования локального сервера Denwer. Составление технического задания по разработке программного продукта. Описание создаваемого мобильного и веб-приложения.

курсовая работа , добавлен 07.04.2015


Разработка автоматизированной информационной системы для учета и контроля выполнения ремонтных работ, и предоставления услуг по разработке программного обеспечения компании "МегионСофтОйл", разработка алгоритмов приложений программной системы и модулей.

дипломная работа , добавлен 29.06.2012


Обоснование необходимости разработки информационной системы. Анализ предметной области. Техническое задание на создание ЭИС. Правовой статус и краткая экономическая характеристика предприятия. Состояние учетно-аналитической работы на предприятии.

реферат , добавлен 09.01.2009


Разработка и внедрение автоматизированной информационной системы (АИС) работы с клиентами туристической фирмы (приема и обработки заявок). Технико-экономическая оценка туристического агентства, алгоритм и схема интерфейса программного обеспечения его АИС.

дипломная работа , добавлен 21.07.2011


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