Проектирование информационной системы «Ювелирная мастерская»

Министерство транспорта РФ Федеральное агентство морского и речного транспорта ФБОУ ВПО «Новосибирская государственная академия водного транспорта»

Электромеханический факультет Кафедра «Информационных систем»

Пояснительная записка к курсовому проекту По дисциплине «Проектирование информационных систем»

Тема: Проектирование информационной системы «Ювелирная мастерская»

Выполнил студент группы ИС-6:

Попов Р.В.

Проверил:

Ботвинков А.В.

Новосибирск, 2012

Содержание Задание Исходные данные Введение

1. Проведение обследования

1.1 Предварительная информация об организации

1.2 Описание границ проекта

1.3 Отчет об исследовании

1.4 Общие требования к информационной системе

2. Моделирование предметной области

2.1 Построение диаграмма бизнес-процессов

2.1.1 Построение диаграмма бизнес-процессов на основе IDEF0

2.1.2 Построение диаграмма бизнес-процессов на основе use-case диаграммы UML

3. Построение диаграмма потоков данных на основе диаграммы DFD

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

5. Технический проект Заключение Список используемой литературы

Задание

1. Произвести сравнение двух подходов моделирования предметной области.

2. Написать техническое задание в соответствии с ГОСТ 34.602−89

3. Написать технический проект в соответствии с данными, предоставленными преподавателем

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

Классы объектов Изделия (Название, Тип, Материал, Вес, Цена).

Материалы (Название, Цена за грамм).

Продажи (Изделие, Дата продажи, Фамилия покупателя, Имя покупателя, Отчество покупателя).

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

Введение

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

В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:

· неадекватная спецификация требований;

· неспособность обнаруживать ошибки в проектных решениях;

· низкое качество документации, снижающее эксплуатационные качества;

· затяжной цикл и неудовлетворительные результаты тестирования.

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

Перечисленные факторы способствовали появлению программно-технологических средств специального класса — CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

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

· подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

· широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

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

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся «полочным» ПО (shelfware). В связи с этим необходимо отметить следующее:

· CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

· реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

· широкое разнообразие качества и возможностей CASE-средств;

· относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

· широкое разнообразие в практике внедрения различных организаций;

· отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

· широкий диапазон предметных областей проектов;

· различная степень интеграции CASE-средств в различных проектах.

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

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

· Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

· Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;

· Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

Для того, чтобы принять взвешенное решение относительно инвестиций в CASE-технологию, пользователи вынуждены производить оценку отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных «подводных камней» использования CASE-средств. Среди наиболее важных проблем выделяются следующие:

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

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

· отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;

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

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

· негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

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

· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

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

· приемлемый уровень отдачи от инвестиций в CASE-средства.

В соответствии с ГОСТ 34.602−89:

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

1) общие сведения;

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

3) характеристика объектов автоматизации;

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

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

6) порядок контроля и приемки системы;

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

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

9) источники разработки.

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

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

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

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

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5) плановые сроки начала, и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

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

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

1) назначение системы;

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

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

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

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

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

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

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

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

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

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

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

3) требования к видам обеспечения.

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

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

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

показатели назначения;

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

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

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

требования к транспортабельности для подвижных АС;

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

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

требования по сохранности информации при авариях требования к защите от влияния внешних воздействии;

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

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

дополнительные требования.

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

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

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

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

4) требования к режимам функционирования системы;

5) требования по диагностированию системы;

6) перспективы развития, модернизации системы.

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

требования к численности персонала (пользователей) АС;

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

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

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

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

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

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

вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

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

1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;

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

3) требования к надежности технических средств и программного обеспечения;

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

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

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

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

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

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

2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.;

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

4) требования к составу размещению и условиям хранения комплекта запасных изделий и приборов;

5) требования к регламенту обслуживания.

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

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

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

1) требования к радиоэлектронной защите средств АС;

2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

1.6.1.13. В требования к стандартизации и унификации включают:

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

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

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

2) требования к сервисной аппаратуре, стендам для проверки элементов системы;

3) требования к системе, связанные с особыми условиями эксплуатации;

4) специальные требования по усмотрению разработчика или заказчика системы.

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

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

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

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

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

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

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

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

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

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

2) к информационному обмену между компонентами системы;

3) к информационной совместимости со смежными системами;

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

5) по применению систем управления базами данных;

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

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

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

9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

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

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

1) к независимости программных средств от используемых СВТ и операционной среды;

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

3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

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

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

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

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

1) предварительный перечень измерительных каналов;

2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;

3) требования к метрологической совместимости технических средств системы;

4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;

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

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

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

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

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

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

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

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

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

1) перечень документов, по ГОСТ 34.201, предъявляемых по окончании соответствующих стадий и этапов работ;

2) вид и порядок проведения экспертизы технической документации, (стадия, этап, объем проверяемой документации, организация-эксперт);

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

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

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

1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

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

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

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

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

1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

2) изменения, которые необходимо осуществить в объекте автоматизации;

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

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

5) сроки и порядок комплектования штатов и обучения персонала.

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

изменения применяемых методов управления;

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

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

1) согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;

2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

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

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

1) расчет ожидаемой эффективности системы;

2) оценку научно-технического уровня системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— обоснования разработки и поэтапного внедрения систем;

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

— разработки технического и рабочего проектов систем.

На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.

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

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

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

1.1 Предварительная информация об организации Полное фирменное наименование предприятия: ОАО ЗФ ГМК НН «Роскошь» .

Адрес: 647 000, Островского, 12 Тел./Факс: (39 191)58569

Предприятие осуществляет следующие основные виды деятельности:

· Оказание услуг по изготовлению Ювелирных изделий ;

· Помощь клиентам в выборе материала и эскиза изделия;

· Продажа готового продукта.

1.2 Описание границ проекта В рамках проекта развертывание новой системы предполагается осуществить только в следующих подразделениях организации:

· Регистратура;

· Склад

1.3 Отчет об исследовании Список программного обеспечения, используемого предприятием на момент обследования

— Excel для учета клиентов и продукции Существующий уровень автоматизации:

— Количество рабочих станций, всего: 1

— Сотрудники отдела IT — отсутствуют.

— Количество ПК, одновременно работающих в сети — 0

— Наличие и форма связи с удаленными объектами — выделенная линия подключения к интернету — отсутствует

— Характеристики компьютеров — Intel Pentium II (300Mhz)

— Операционная система — Windows 98

1.4 Общие требования к информационной системе Одно из основных требований организации ОАО ЗФ ГМК НН «Роскошь» к будущему решению состоит в том, чтобы оно было построено на фундаменте единой интегрированной системы, а работа всех сотрудников велась в одном информационном пространстве.

Ключевые функциональные требования к информационной системе:

— Мощные средства защиты данных от несанкционированного доступа. Разграничения доступа к данным в соответствии с должностными обязанностями.

— Возможность удаленного доступа.

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

— несколько БД, имеющие возможность легкого переноса и стабильной совместной работы.

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

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

2.1 Построение диаграммы бизнес-процессов

2.1.1 Построение диаграммы бизнес-процессов на основе IDEFO

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

Нотация IDEF0 необходима для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем. Исходными строительными блоками любой модели IDEFO процесса являются деятельность (sicuence) и стрелки (arrows).

Модель типа «TO-BE» .

Словарь данных для диаграммы IDEF0

2.1.2 Построение диаграммы бизнес-процессов на основе use-case диаграммы UML

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

Диаграмма USE CASE

Диаграмма последовательности

3. Построение диаграммы потоков данных на основе диаграммы DFD

Диаграммы потоков данных (Data Flow Diagram) используются для документирования механизмов передачи и обработки информации в моделируемой системе. Диаграммы DFD обычно строятся для наглядного отображения текущей работы системы документооборота организации. Чаще всего диаграммы DFD применяют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

Словарь данных для диаграммы DFD0

информационный автоматизирующий моделирование диаграмма

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

При разработке технического задания необходимо решить следующие задачи:

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

· разработать и обосновать требования, предъявляемые к подсистемам;

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

· установить общие требования к проектируемой системе;

· определить перечень задач создания системы и исполнителей;

· определить этапы создания системы и сроки их выполнения;

Состав и содержание ТЗ:

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

1.1. полное наименование системы «Голд», ее условное обозначение «Голд»

1.2. номер договора — Договор ЗТФ № 204 565 от 26.10.2012

1.3. наименование предприятия заказчика — ОАО ЗФ ГМК НН «Роскошь» .

наименование предприятия разработчика — ОАО ЗФ НН-ИНФОКОМ

1.4. перечень документов, на основании которых создается ИС:

— ГОСТ 34.602−89

— задание к курсовому проекту

— договор ЗТФ № 204 565 от 26.10.2012 на создание ИС комплекса

1.5. плановые сроки начала и окончания работ:

— дата начала работ 27.10.2012

— дата окончания работ 31.12.2013

1.6. сведения об источниках и порядке финансирования приведены в договоре ЗТФ № 204 565 от 26.10.2012

1.7. Работы по созданию системы «Голд» сдаются ОАО ЗФ НН-ИНФОКОМ, далее именуемым «Разработчиком», поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает ОАО ЗФ ГМК НН «Роскошь», далее именуемый «Заказчик», соответствующие отчетные документы этапа, состав которых определены Договором.

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

2.1. вид автоматизируемой деятельности — автоматизация работы ювелирной мастерской с клиентами

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

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

2.3.1. технические — в данной работе не присутствуют

2.3.2. технологические — автоматизация сбора данных о клиентах

2.3.3. производственно-экономические — повышение эффективности качества обслуживания и увеличения прибыли

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

3.1. краткие сведения об объекте автоматизации — регистратура выполняет такие функции как ведение документации по клиентам, и их информирование. База склад — хранит сведения о материалах и ценах.

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

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

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

4.1.1. требования к структуре

4.1.1.1. перечень подсистем

4.1.1.1.1. подсистема регистратуры

4.1.1.1.2. подсистема склада

4.1.1.1.3. подсистема защиты от несанкционированного доступа

4.1.1.2. централизация — полностью централизована

4.1.1.3. информационный обмен основан на базе сервера баз данных

4.1.1.4. режимы функционирования — система может работать одним блоком, а также каждая подсистема может функционировать по отдельности

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

4.1.1.6. перспективы развития системы — в дальнейшем есть возможность по увеличению степени автоматизации и ее оптимизации

4.1.2. требования к персоналу

4.1.2.1. численность пользователей данной системой — 3 человек

· Руководитель Ювелирной мастерской -1человек

· Администратор подсистемы сбора, обработки и загрузки данных, хранения данных, формирования и визуализации отчетности-1 человек

· Оператор системы — 1 человек Данные лица должны выполнять следующие функциональные обязанности.

— Руководитель эксплуатирующего подразделения — на всем протяжении функционирования ИС «Голд» обеспечивает общее руководство группой сопровождения.

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

4.1.2.2. квалификация — базовые знания ПК и специфики ПО

4.1.2.3. режим работы — согласно графику работы

4.1.2.4. подготовка — тренинговые курсы при внедрении системы и курсы по повышению квалификации

4.1.3. показатели назначения — гибкая система к изменениям процессов управления и значения параметров

4.1.4. требования:

4.1.4.1. к надежности — стабильность работы в соответствии с: СНиП 3.05.06−85, ГОСТ Р21.11.01−2009, РД 78.36.002−999, ГОСТ 25 953–90 ГУВО МВД России.

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

4.1.4.3. к эргономике — должна быть удобная в эксплуатации, соответствовать общепринятым требованиям к ПО данной направленности.

В части внешнего оформления:

— интерфейсы подсистем должен быть типизированы;

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

— должен использоваться шрифт: Times New Roman

— размер шрифта должен быть: 12

— цветовая палитра должна быть: 65 535цветов

— в шапке отчетов должен использоваться логотип Заказчика.

В части диалога с пользователем:

— для наиболее частых операций должны быть предусмотрены «горячие» клавиши;

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

В части процедур ввода-вывода данных:

— должна быть возможность многомерного анализа данных в табличном и графическом видах.

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

4.1.4.4. к эксплуатации — не допускать к системе некомпетентных пользователей

4.1.4.5. к защите и сохранности информации — информация должна быть защищена специальными механизмами

— Защита Системы должна обеспечиваться комплексом программно-технических средств и поддерживающих их мер.

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

— Программно-технические средства защиты не должны существенно ухудшать основные функциональные характеристики Системы (надежность, быстродействие, возможность изменения конфигурации).

— Разграничение прав доступа пользователей и администраторов Системы должно строиться по принципу «что не разрешено, то запрещено» .

4.1.4.6. к патентной чистоте — все элементы, входящие в состав продукта, взятые со стороны, имеют соответствующее разрешение к использованию

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