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

2. Техническое задание на создание информационной системы

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

Автоматизированная информационная система «Строительное предприятие»

2.2 Цели создания информационной системы

Для решения задач контроля и учета проектирования и изготовления, и продаж в данном предприятии создается автоматизированная информационная система, которая проектируется в среде СУБД ACCESS.

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

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

Основные функции, которые решает ИС:

· Контроль работы предприятия;

· Учет продаж предприятия;

· Учет результатов (доходов и расходов предприятия).

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

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

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

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

2.4.1 Требования к входной, нормативно-справочной и выходной информации

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

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

· Данные, поступающие из отдела маркетинга, которые содержат заявки на поставку товаров и выполнение других работ, сведения об установленных ценах;

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

Эти данные представлены в виде таблицы БД, в виде запроса, а также в виде отчета на экране и на бумаге.

Выходные результаты решения задачи по учету результатов деятельности предприятия выводятся:

· На принтер и на жесткий диск в отделе проектирования и изготовления, и отделе продаж;

· Передаются по каналу связи в бухгалтерию и в планово-экономический отдел.

Выдача выходных данных осуществляется каждый квартал.

2.4.2 Предложения по кодированию и классификации информации

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

· Сокращение временных и других затрат на решение задач в системе управления;

· Обеспечение высокого качества информации.

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

Эти данные кодируются с использованием порядкового метода. Его достоинством является простота использования, недостатком - переполнение кодов.

Классификация информации.

Существует 2 метода классификации:

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

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

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

Ш Кумулятивность - полнота информации;

Ш Достоверность - отсутствие скрытых ошибок;

Ш Защищенность - невозможность несанкционированного доступа;

Ш Оперативность - своевременность;

Ш Гомоморфность - данные должны быть представлены в одном виде;

Ш Идентичность - соответствие объектов на данный момент;

Ш Конфиденциальность - секретность.

Основным программным методом контроля качества информации, используемой в системе управления, является:

· Логический - смысловая проверка, т. е контроль по отклонениям, по заданной последовательности записей

· Программный.

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

2.4.4 Предлагаемые меры по защите информации от несанкционированного доступа

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

Его виды:

1. Косвенный - подслушивающие устройства, дистанционные фотографии, радиоперехват и др.

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

Защита наиболее уязвимой части информации производится следующими методами:

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

· Программные - защита БД и прикладных программ от копирования, антивирусные программы, шифрование, резервирование информации

В информационной системе применяется программный метод защиты (проверка на вирусы).

База данных создавалась в системе СУБД ACCESS т.к она больше ориентирована на обычного пользователя, по сравнению, например, с СУБД FOXPRO, которая ориентирована на прикладного программиста. Выбор СУБД определяется уровнем сложности решаемых в составе АИС задач управления. Поэтому для данной курсовой работы оптимальна СУБД ACCESS.

2.4.5 Требования к базе данных (БД) и системе управления БД

Система управления БД, которая будет использоваться в автоматизированной системе - СУБД ACCES, так как она больше ориентирована на обычного пользователя, а СУБД FOXPRO - на прикладного программиста.

2.4.6 Требования к техническим средствам

Рекомендуется использовать ПК с процессором Pentium -IV, с оперативной памятью объемом не менее 256 МБт, с дисковой памятью объемом не менее 200 ГБт. Это обеспечит высокопроизводительную работу ЛВС при использовании любой топологии и операционной системы.

Требования к вспомогательным устройствам. Для работы в сети устанавливаются 32 - разрядные сетевые адаптеры EtherNet с протоколом ISA или адаптеры TokenRing с протоколом MicroChannel, или сетевые адаптеры ArcNet с протоколом ISA.

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

· Иметь высокую производительность;

· Иметь достаточную буферную память;

· Иметь высокую надежность работы;

· Обеспечивать высокое качество печати;

· Желательно иметь возможность копирования документов.

Исходя из этого, применяется лазерный принтер - HP LaserJet 1100.

Для повышения надежности работы сети необходима установка устройств бесперебойного питания UPS, особенно для файл - сервера.

3. Технорабочий проект (Проектное решение)

Автоматизация процесса поиска плагиата

Автоматизация работы техподдержки пользователей

В соответствии с ГОСТ 34.601-90, настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях...

Автоматизация расчетов по оплате труда на примере ОАО "Нечкинское" Сарапульского района Удмуртской Республики с использованием программы 1С:Предприятие 8.0

Автоматизированная информационная система учета расхода воды

Общие сведения Полное наименование системы и ее условное обозначение Информационная системы учета расхода воды на примере общества с ограниченной ответственностью "Водоснабжение" (АИС УРВ "Водоснабжение")...

Автоматизированная информационная система учета хранения и обслуживания контрольно-измерительных приборов

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

Виртуальный деканат

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

Информационная система "Клинника"

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

Информационное обеспечение АТП

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

Проектирование информационной сети

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

Разработка web-сайта организации (на материалах ООО "Автомир", г. Гомель)

Рассмотрим уровень технического обеспечения в ООО «Автомир». В организации все рабочие места автоматизированы. На рабочих местах установлены персональные компьютеры...

Разработка и проектирование информационной системы для салона мобильной связи при помощи Microsoft Access на языке программирования Visual Basic

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

Разработка информационной системы администратора сети организации ООО "WestCall"

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

1 Общие сведения. 1.1 Полное наименование системы и ее условное обозначение "Bentec IT & Soft invent" 2. Назначение и цели создания системы. 2.1 Назначение системы...

Разработка технического задания для автоматизации магазина "Буква"

Общие сведения Наименование системы автоматизированная система учета деятельности магазина "Буква-Серов". Предприятие заказчик - ООО "Эталон"...

Создание сайта группы

1) Тип изделия: Динамический web-сайт группы; 2) Цель: Создание сайта группы для удобства информирования студентов группы в неучебное и учебное время; 3) Целевая аудитория: Студенты группы и преподаватели ВУЗа; 4) Требования к сайту: 1)Удобный...

Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?». Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему.

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

Для начала надо разобраться, какой в действительности вопрос интересует тех, кто спрашивает «Как разработать техническое задание?» Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания. О каких вариантах я говорю:

• Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
• Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
• Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.

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

  • Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
  • Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
  • Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
  • Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
  • Возможны и другие, реже встречающиеся варианты;

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

• А почему нельзя разрабатывать Техническое задание всегда одинаково?;
• Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
• Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
• Как понять, хорошо составлено Техническое задание или нет?
• За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли. Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

Что такое техническое задание?

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

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по середине. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

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

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
• ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

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

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:

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

Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома. Красота!). Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания .

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

1. Требование должно быть понятным ;
2. Требование должно быть конкретным ;
3. Требование должно быть тестируемым ;

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

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

• на каком языке (в смысле сложности понимания) должно быть написано техническое задание?
• Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
• А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?

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

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

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

Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.

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

Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.

А нужно ли вообще техническое задание? А Технический проект?

Не перегрелся ли я? Разве такое возможно, вообще без Технического задания ? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого» . Золотые ведь слова, ко всему подходят. Так что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.

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

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

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

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

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

Несмотря на то, что формулировка требований является основной частью Технического задания , а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично! Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю? Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.

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

Итого, 9 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.

Раздел 1. общие сведения.

Рекомендации по ГОСТ
полное наименование системы и ее условное обозначение;	Тут все понятно: пишем, как будет называться система, ее краткое наименование
шифр темы или шифр (номер) договора;	Это не актуально, но можно и указать, если требуется
наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;	указывают, кто (какие организации) будут работать над проектом. Можно указать и их роли.Можно вообще удалить этот раздел (достаточно формальный).
перечень документов, на основании которых создается система, кем и когда утверждены эти документы;	Полезная информация. Тут стоит указать ту нормативно-справочную документацию, которую Вам предоставили для ознакомления с определенной частью требований
плановые сроки начала и окончания работы по созданию системы;	Пожелания по срокам. Иногда в ТЗ об этом пишут, но чаще такие вещи описываются в договорах на работы
сведения об источниках и порядке финансирования работ;	Аналогично, как и в предыдущем пункте про сроки. Более актуально для государственных заказов (для бюджетников)
порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.	Не вижу необходимости в этом пункте, т.к. требования к документированию вынесены отдельно, а кроме этого есть целый отдельный раздел «Порядок контроля и приемки» системы.

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

Рекомендации по ГОСТ	Что с этим делать на практике
Назначение системы	С одной стороны с назначением все просто. Но желательно формулировать конкретно. Если написать что-то вроде «качественно автоматизировать складской учет в компании Х», то потом можно долго обсуждать результат при его завершении, даже независимо от хорошей формулировки требований. Т.к. Заказчик всегда может говорить, что под качеством он имел ввиду нечто иное. В общем, нервов можно попортить друг другу много, а зачем? Лучше сразу написать примерно так: «Система предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном Техническом задании».
Цели создания системы	Цели – это безусловно важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у Вас трудности с формулировкой целей, то лучше вообще исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое оформление документов менеджером». Что такое быстрое? Это можно потом доказывать бесконечно. Если это важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строк за 10 минут». Подобная цель может появиться, если, например, в настоящее время менеджер тратит на это около часа, что слишком много для этой компании и для них это важно. В такой формулировке цель уже пересекается с требованиями, что вполне естественно, т.к. при разворачивании дерева целей (т.е. дробя их на более мелкие связанные цели), мы и так будем приближаться к требованиям. Поэтому, увлекаться не стоит.

Вообще, умение выделять цели, формулировать их, строить дерево целей это тема совершенно отдельная. Запомните главное: умеете – пишите, не уверены – вообще не пишите. А что будет, если не сформулировать цели? Будете работать по требованиям, такое часто практикуется.

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

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

ГОСТ расшифровывает перечень таких требований:

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

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

• Требования к квалификации . Возможно, разрабатываемая система потребует переподготовки специалистов. Это могут быть как пользователи будущей системы, так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное внимание к данному вопросу нередко перерастает в проблемы. Если квалификация имеющегося персонала явно недостаточна, лучше прописать требования к организации обучения, программе обучения, срокам и т.п.
• Требования к защите информации от несанкционированного доступа. Тут комментарии излишни. Это как раз и есть требования к разграничению доступа к данным. Если такие требования планируются, то их нужно расписать отдельно, как можно более детально по тем же правилам, что и функциональные требования (понятность, конкретность, тестируемость). Поэтому, можно эти требования включить и в раздел с функциональными требованиями
• Требования к стандартизации. Если существуют какие-либо стандарты разработки, которые применимы к проекту, они могут быть включены в требования. Как правила, такие требования инициирует IT-служба Заказчика. Например, у компании 1С есть требования к оформлению программного кода, проектированию интерфейса и пр.;
• Требования к структуре и функционированию системы. Тут могут быть описаны требования к интеграции систем между собой, представлено описание общей архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел или даже отдельное Техническое задание, т.к. эти требования могут оказаться достаточно сложными.

Все остальные требования менее важны и можно их не описывать. На мой взгляд, они только утяжеляют документацию, и практической пользы несут немного. А Требования к эргономике описывать в виде общих требований очень сложно, лучше их перенести к функциональным. Например, может быть сформулировано требование «Получить информацию о цене товара нажав только одну кнопку». На мой взгляд, это все-таки ближе к конкретным функциональным требованиям, хоть и относится к эргономике.Требования к функциям (задачам), выполняемым системойВот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье, которая войдет в 5-й выпуск рассылки. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил.Требования к видам обеспечения

ГОСТ выделяет такие виды:

• Математическое
• Информационное
• Лингвистическое
• Программное
• Техническое
• Метрологическое
• Организационное
• Методическое
• и другие…

На первый взгляд может показаться, что эти требования не важны. В большинстве проектов это действительно так. Но не всегда. Когда стоит описывать данные требования:

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможно, у Заказчика есть принятые корпоративные стандарты, значит надо к ним обращаться.

Игнорирование требований к документации очень часто приводит к самым неожиданным последствиям на проектах. Например, все сделано и все работает. Пользователи тоже умеют работать. Про документацию вообще не договаривались и не разговаривали. И вдруг при сдаче работ кто-то из топ-менеджеров Заказчика, который даже не участвовал в проекте, но участвует в приемке работ, Вас спрашивает: «А где руководства пользователя?» И начинает Вас убеждать, что о наличии руководств пользователя договариваться было и не нужно, это «само собой» якобы подразумевается. И все, не хочет принимать у Вас работу. За чей счет будете разрабатывать руководства? На этот крючок попадали уже многие команды.

Раздел 9. Источники разработки

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

И так, мы рассмотрели все разделы, которые могут быть включены в Техническое задание. «Могут», а не «Обязаны» именно потому, что любой документ должен разрабатываться для достижения результата. Поэтому, если для Вас очевидно, что какой-то отдельный раздел к результату не приблизит, значит он Вам не нужен и не надо тратить на него время.

Но вот без главного: функциональных требований ни одно грамотно Техническое задание не обходится. Хочу заметить, что в практике такие Технические задания встречаются, и еще как! Есть деятели, которые сумеют развести воды по всем разделам, опишут общие требования общими словами, и документ получается весьма увесистый, и слов в нем умных много, и даже Заказчику может понравится (т.е. он его утвердит). Но вот работать по нему может не получиться, т.е. практической пользы от него мало. В большинстве случаев такие документы рождаются, когда надо получить много денег именно под Техническое задание, а сделать его надо быстро и не погружаясь в детали. А особенно, если известно, что дальше дело не пойдет, или его будут делать совсем другие люди. В общем, просто для освоения бюджета, особенно государственного.

Во второй статье будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.

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

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

Тестируемое ли это требование? Вроде бы простая вещь, но как ее проверять, если нет конкретики?

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

ЭргономичностьПрограмма должна иметь удобный интерфейсПризнаться, под данной формулировкой пришлось однажды подписаться самому – проблем потом было не сосчитать. Конечно же, подобных формулировок быть не должно. Тут нет не конкретики, ни возможность проверить это требование. Хотя, безусловно, понятное (субъективно). Тут переформулировать никак нельзя, надо подробно расписывать каждый элемент «удобности», раз Заказчик на этом настаивает. Например:

• Строки в документ должны добавляться как по нажатию на кнопку «Добавить», так и при нажатии на клавиши «insert», а также вводе пользователем части наименования;
• При просмотре списка товаров должна быть возможность поиска по наименованию, штрихкоду и артикулу;
• И пр.

Разграничение прав доступаДоступ к данным по прибыли должен быть доступен только финансовому директоруПонятно? Почти. Правда, прибыль бывает разная, надо уточнить.Конкретно? Конечно нет. Как это видится в реализации? Если речь идет о валовой прибыли, то значит необходимо ограничивать доступ к данным о стоимости закупки, т.к. в противном случае валовую прибыль вычислить не составит труда, поскольку данные о стоимости реализации известны широкому кругу лиц. К тому, что относится к правам доступа, надо относиться очень аккуратно. А если у менеджеров по продажам мотивация построена на валовой прибыли, так эти требования еще и противоречат друг другу, т.к. менеджеры никогда не смогут это проверить. Если уж включать такое требование, то нужно указывать конкретные отчеты и объекты системы, в которых указывать, какая часть данных должны быть доступна отдельным категориям лиц. И рассматривать каждый такой случай индивидуально.ПроизводительностьОтчет по продажам должен формироваться за 1 минуту.Да, понятно. И даже есть конкретное ограничение по времени: 1 минута. Но не известно, какая детализация при этом предполагается: по каждому товару, группам товаров, клиентам или как-то еще?Можно сформулировать примерно так: «Отчет по продажам в разрезе клиентов с детализацией до каждой товарной позиции (см. образец) должен выводится не более, чем за 1 минуту при условии, что количество товаров в выборке не превышает 5000 строк».

Надеюсь, идея понятна. Если будут конкретные вопросы, пишите, попробую помочь.

Чтобы в Техническом задании было больше конкретики, существует немало рекомендаций. Даже есть перечень слов, которые употреблять в Техническом задании не рекомендуется. Интересно об этом пишет К.Вигерс, в своей книге «Разработка требований к программному обеспечению». Приведу самые интересные и простые, на мой взгляд, рекомендации:

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

Все, что написано выше, это информация важная, но не самая. Как Вы помните, в начале статьи я это назвал термином «камуфляж», т.к. самое главное, что составит как минимум 90% времени и сложности работы над документом – это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. Одно из таких ключевых отличий – это наличия этапа построения прототипа будущей системы, или как его еще называют «модели информационной системы».

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

Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов. Часть 2

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

Как обычно происходит в жизни:

Как это происходит в большинстве проектов
	Как это происходит
	Понятное дело, что есть повод для радости, особенно, если проект большой, ничего плохого в этом нет! Главное, не радоваться слишком долго, оттягивая начало фактических работ, с этой минуты время будет идти по-другому.
	Обычно этот процесс ограничивается несколькими встречами с руководством, затем с руководителями подразделений. Зафиксировав некие «позывы» со стороны Заказчика, они фиксируются в виде общих формулировок. Иногда к этому добавляют имеющуюся документацию (кто-то когда-то пытался уже поводить обследование, документы по существующим регламентам, формы используемых отчетов) Как ни удивительно, но после этого большинство внедренцев систем автоматизации радостно восклицает: «да в нашей системе все это есть! Ну немного поднастроить и все будет работать». На вопрос, надо ли обсуждать, как все должно работать (или как выполняется конкретный процесс) с конечными пользователями, ответ обычно отрицательный. Высказывается мнение, что руководитель все знает за своих подчиненных. А зря… За этим скрывается множество ловушек и препятствий, и сдача работ может превратиться в марафон по полосе с препятствиями. Как известно, марафон принято бегать по ровной дороге, а бег с препятствиями возможен только на коротких дистанциях (можно и не добежать).
Документирование результатов работы	После этого начинается документирование результатов в зависимости от целей работ: Если требуется разработать Техническое задание, консультант начинает рассовывать полученную информацию по заготовленному шаблону документа, чтобы и выглядело красиво, и основные требования были зафиксированы (те, что озвучены от руководства, а то ведь могут не утвердить). Понимая, что на практике такое Техническое задание особо не используется и приходится все выяснять «по ходу дела», главной целью Технического задания он ставит минимальное время согласования и утверждения. И, если получится, информация для примерной оценки стоимости будущих работ (кстати, тоже немаловажно). Если требуется описать бизнес-процессы. Как ни странно, но часто все предшествующие действия выглядят аналогично, как и в случае с разработкой Технического задания. Разница лишь в оформлении документации. Тут возможны варианты: консультанты описывают процесс произвольными словами или используют какие-либо правила описания бизнес-процессов (нотации). В первом случае такой документ получается удивительным образом похож на Техническое задание. Бывает даже такое, что если заменить титульный лист, никакой разницы не увидишь.В последнем случае часто делают акцент не на соответствии действительности, а на «правильности описания», т.е. формальное следование правилам описания.К сожалению, оба варианта являются не самой лучшей практикой, т.к. являются скорее формальностью, а пользы приносят не много.

Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования. Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».

Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?

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

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

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

Как это может происходить при более грамотной организации работ
	Как это происходит
Решение принято, проекту быть!	Тут ничего не меняется относительно первого варианта, эмоции никто не отменял
Провели совещание с руководителями, собрали некоторую информацию об их видении результата.	Этот шаг тоже остается, и он имеет большое значение. Но основное назначение первой встречи (или нескольких встреч) с руководителями и собственниками это знакомство. Знакомство в первую очередь с людьми и компанией. Сформулированные цели и пожелания на таких общих встречах могут быть самими различными, в том числе фантастическими. Все они будут, конечно же, выслушаны, но не факт, что будут реализованы. При более глубоком погружении в бизнес компании будут как появляться другие цели, так и отвергаться предыдущие. Я это к тому, что из предварительных встреч нельзя сформулировать четкие цели, все это потребует тщательной проработки.На таких встречах необходимо конспектировать все посылы от собственников и первых лиц, чтобы потом можно было к ним вернуться и обсудить, когда будет собрано достаточное количество информации. Даже простое на первый взгляд требование может оказаться нереализуемым либо очень трудоемким.
Формирование рабочей группы от Заказчика и Исполнителя, распределение ролей	Необходимо определиться, кто будет работать над проектом как со стороны Заказчика, так и со стороны Исполнителя. Несмотря на кажущуюся простоту данного этапа, он имеет очень большую роль. Если не зафиксировать четко, кто за что отвечает, в ходе реализации работ Вы рискуете столкнуться с неразберихой. Если со своей стороны Вы можете всегда конкретизировать роли в своей команде, то у Заказчика с этим могут возникнуть проблемы. На что следует обратить внимание: в состав рабочей группы Заказчика обязательно должны войти те люди, которые будут в дальнейшем хоть как-то влиять на принятие результата. Если допустить ситуацию, что при сдаче работ подключатся сотрудники Заказчика, которые не принимали участие в работах по формированию целей и выявлению требований, то проблемы гарантированы. Возможна даже такая абсурдная ситуация, что все, оказывается, сделано не так, как требовалось.В моей практике я сталкивался с такой ситуацией не раз.Поэтому, Вы себя можете обезопасить, если оговорите и зафиксируете документально, что никто, кроме рабочей группы Заказчика не может принимать участие в приемке-сдаче работ. А лучше всего, прописать такое в договорных условиях (В договоре или Уставе проекта). Помню, был такой случай: в одном крупном проекте учредитель решил подключиться к процессу (уж не знаю почему, скучно видать стало) и посетил одну из рабочих встреч, где обсуждался вопрос формирования счетов клиентам. Он с удивлением для себя узнал, что счет клиенту выставляет менеджер по продажам. В его представлении счет должен выставлять бухгалтер, и никак иначе. Но на самом деле бухгалтер вообще не представлял, о чем идет речь, а менеджер не мог себе представить, как так работать, если за каждым счетом бегать к бухгалтеру. В результате потеряли кучу времени, но ничего не поменялось, счет по-прежнему выставлял менеджер. А учредитель остался при своем мнении, но больше в процесс не вмешивался. На этом же этапе целесообразно разработать Устав проекта, в котором зафиксировать роли участников, порядок коммуникаций, регламент и состав отчетности, а также все остальное, что следует прописать в Уставе. Разработка Устава проекта это тема опять же отдельная.
Обучение проектной команды методикам и инструментам работы, согласование правил работы, видов и состава документации	Во-первых, необходимо разъяснить проектной команде все, что прописано в Уставе, как это будет применяться на практике. Во-вторых, проектную команду Заказчика необходимо обучить тем методам работы, которые Вы собираетесь использовать на всех последующих этапах. Имеет смысл обсудить форматы документов, которые будут использоваться, рассмотреть образцы. Если будут применяться какие-либо правила описания моделей или бизнес-процессов, то надо обсудить и эти правила, чтобы они были понятны.
Анкетирование	Этап анкетирования позволяет сравнительно быстрым способом получить достаточно достоверный срез информации о компании. Качество такой информации будет определяться тремя факторами: В первую очередь тем, как Вы обучили проектную группу Заказчика. Они должны четко понимать, как происходит процесс анкетирования и уметь донести информацию до всех участников Сама форма анкет. Анкеты должны быть понятными. Желательно, чтобы была инструкция по заполнению анкет. Еще лучше, если будет пример заполнения. Состав участников. Необходимо правильно выбрать состав участников. Если ограничиться только руководителями, собрать достоверную информацию не получится. Я рекомендую включать в состав анкетирования всех, кто будет в будущем являться пользователем конечных результатов. Например, если речь идет о внедрении автоматизированной системы, то стоит включить всех, кто будет являться пользователем. Бывают случаи, когда из 10 сотрудников одной должности найдется один, который выполняет какую-нибудь особенную функцию, о которой никто из оставшихся 9-ти больше не знает (например, готовит особый отчет для руководства). Если речь идет о дальнейшем перераспределении обязанностей или разработке должностных инструкций, следует поступить аналогично. Обращаю внимание, что методика анкетирования для последующей внедрения автоматизированной системы или описания бизнес-процессов в правильном случае различается. Конечно, структура анкет может быть и одинаковая, но это не самый лучший вариант. Когда мы описываем бизнес-процессы, то анкеты обычно носят более общий характер, т.к. неизвестно точно, с чем придется столкнуться. Если же речь идет о внедрении конкретной автоматизированной системы, то лучше иметь анкеты, учитывающие особенности этой системы. При таком подходе можно сразу выявить все узкие места системы, которые не подходят для данного предприятия. Как правило, методики внедрения готовых систем предусматривают наличие таких анкет. Такие анкеты могут разрабатываться либо по отдельным областям учета (например, учет заказов, продажи, ценообразование), либо для конкретных должностей (финансового директора, например). Состав вопросов примерно одинаковый.
Опросы	Опросом называется проведение устного собеседование со специалистами с целью выяснить особенности отдельных процессов. Необходимо организовать опрос так, чтобы он не выглядел как просто «встретились-поговорили», а более организовано. Для этого необходимо подготовить так называемый план опроса. В него можно включить те части анкеты, которые у Вас вызывают вопросы, противоречат сведениям других анкет или информация представлена поверхностно. Целесообразно добавить вопросы и просто из личного опыта.Ответы надо конспектировать в обязательном порядке. Идеально, если Вы договоритесь о ведении аудиозаписи. На этом же этапе следует проследить за полнотой предоставленной информации о документообороте (как форм первичных документов, так и различных отчетов)
Выделение ключевых бизнес- процессов или областей автоматизации	После анкетирования и опроса можно обосновано считать, что информации достаточно, чтобы делать выводы о выделении ключевых бизнес-процессов. На самом деле, уже можно выделить не только ключевые бизнес-процессы, но и практически все (если состав участников был выбран правильно). Вопрос выделения бизнес-процессов это тема совсем отдельная и не простая. Научиться тут сложно и вырабатывается в основном опытом. Из выделенных бизнес-процессов следует составить перечень (классификатор). Затем можно будет принимать решения, какие из них следует исследовать более глубоко, какие нет, а также выделять приоритеты.
Формулирование ключевых требований к системе, целей, критериев успешности проекта, процессов для детального изучения	К этому этапу должна быть собрана вся первичная информация о деятельности компании, составлен перечень бизнес-процессов. Теперь в самое время вернуться к целям, конкретизировать их, при необходимости обсудить с первыми лицами компании. При формулировке целей следует учесть конкретные показатели, при достижении которых будем считать проект успешным. Если речь идет о внедрении автоматизированной системы, то отдельным перечнем можно выделить требования к системе от ключевых пользователей. Я это делаю в виде отдельной таблицы, где все требования сгруппированы по подсистемам, для каждого требования указывается автор требования, формулировка и приоритет. Данную информацию можно будет использовать для составления плана развертывания системы (последовательности внедрения отдельных подсистем), а также для предложений по дальнейшему развитию системы (если отдельные подсистемы в текущем проекте внедрять не планируется). Если необходимо описать бизнес-процессы, принимаются решения о тех процессах, которые необходимо исследовать более детально.

Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.

	Что и как делать
Выделяем бизнес-процесс	Из общего перечня бизнес-процессов, полученного на предыдущих этапах, выделяем один (по приоритету) для детальной проработки. С остальными затем поступаем аналогично.
Детальное изучение бизнес- процесса	Выделенный бизнес-процесс подвергаем детальному изучению: анализируем полученные первичные документы, отчеты и их структуру, используемые в процессе программы, различные файлы (например, Excel), разговариваем с конечными исполнителями. Собираем различные идеи о том, как можно улучшить процесс. Очень полезно, если удастся понаблюдать за процессом именно в тех условиях, в которых он выполняется (не многие любят, когда за ними наблюдают, но что делать)
Графическое и/или текстовое описание бизнес-процесса (первичное)	Полученную подробную информацию начинаем описывать.Прежде чем описывать процесс, надо определиться, потребует ли он графического описания. Если процесс простой и понятный, функций в нем мало, и, графическое представление не улучшит его понимание или восприятие, то не надо тратить на это время. В этом случае достаточно описать его в текстовом виде в табличной форме. Если же процесс сложный, с различными логическими условиями, то лучше привести его графическую схему. Диаграммы всегда воспринимаются легче. Если Вы решили описать процесс в графическом виде, это вовсе не означает, что не надо приводить его текстовое описание. Т.е. текстовое описание процесса должно быть в любом случае, причем выполненное по одинаковой схеме. Удобно это делать в виде таблицы, в которой указать: исполнителей каждого шага, какую информацию они получают на входе, описание каждого шага, какую информацию формируют на выходе. Ниже мы посмотрим на примере, как это может выглядеть.
Согласование с исполнителями и владельцем бизнес-процесса	Лучший способ понять, насколько удачно вы выбрали стиль изложения информации, это показать результат пользователям (исполнителям) процесса.На самое главное в такой демонстрации это понимание того, насколько правильно Вы поняли, как процесс выполняется.Если обучение проектной команды прошло успешно, то можно ожидать от исполнителей вполне адекватной обратной связи. А если им станет интересно, то продвигаться все начнет гораздо быстрее.Выявленные уточнения и несоответствия необходимо отразить в описании (актуализировать), при необходимости операцию повторить.
Выделение показателей бизнес-процесса	После того, как выработано правильное понимание, как выполняется бизнес-процесс, надо подумать над показателями, которыми можно измерить качество или скорость выполнения процесса. Это не просто, но необходимо. Показатель должен быть измеряемым, т.е. выражен в числовом выражении и должен существовать простой способ эту величину получить. Если измеряемый показатель выделить невозможно, есть риск того, что бизнес-процесс выделен неудачно. Кроме того, не будет возможности понять (измерить ведь нельзя), приведут ли изменения процесса к его улучшению или нет.
Окончательное документирование бизнес-процесса	После того, как мы убедились в правильном понимании, как процесс выполняется (или должен выполняться), можно включать его в документацию.
	Дальше возможны варианты: рассматриваемые процессы будут анализироваться и оптимизироваться, разрабатываться должностные инструкции, приниматься решения о необходимости автоматизации отдельных процессов и т.д.Это может быть и отдельный проект: описание бизнес-процессов.

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

	Что и как делать
Выделяем бизнес-требование/область автоматизации	Выделение в качестве требований целой области автоматизации (например, «Складские запасы») на практике используется, однако, это не самый эффективный способ детализации требований. Область автоматизации представляет собой группу требований, и рассматривать их лучше каждое в отдельности. Например, «Учет поступления материала на склад»
Детальное изучение бизнес-требования	Под детальным изучением бизнес-требования понимается то, как это хочет видеть и будет использовать конечный пользователь (разумеется, в соответствии с целями проекта). В технологиях разработки программного обеспечения это часто называют «вариант использования». Таким образом, детальное изучение бизнес-требования сводится к проработке вариантов использования. Пример такого варианта приведен в приложении 2 к статье. В простейших случаях варианты использования вовсе не обязательно рисовать в виде графических схем, можно ограничиться и текстовой формулировкой. Например, требование «При вводе номенклатуры цена должна рассчитаться как цена закупки +20%» рисовать не имеет смысла. В виде диаграммы имеет смысл представлять требования, объединенные до области автоматизации, как показано в примере в приложении 2.
Моделирование требований в информационной системе	Вот оно! Как Вы наверное помните, я уже обращал внимание на этот важнейший элемент в методике разработки Технических заданий. «Построй модель – получишь результат!» А что надо моделировать? Моделировать надо варианты использования, полученные на предыдущем этапе. Что должно быть на выходе моделирования? Должна получиться демонстрационная программа, в которую внесены пользовательские данные, причем желательно привычные его (пользователя) слуху, с учетом отраслевой специфики, актуальных проблем. И не просто так внесены, а должно быть понятно, откуда эти данные взялись, как рассчитались. В этом месте у читателя должны возникнуть вопросы: А что, если планируется разработка новой системы и моделировать попросту не в чем? Что, если для демонстрации не хватает функциональности, и систему надо дорабатывать? Конечно, Вы должны столкнуться с такой ситуацией, и это нормально. Что делать? Если система совсем новая (как говорится «с нуля»), то моделировать придется по большей части на бумаге, тут Вам диаграммы вариантов использования очень помогут. Частично имеет смысл набросать некоторые экранные формы, которые предполагается разработать (прямо в той среде, в которой будет вестись разработка), т.к. рисовать их в каком–нибудь редакторе будет дольше и эта работа скучная. Если внедряется готовая система, и в ней не хватает функциональности, то ничего страшного нет, данные вносятся руками, а пользователю так и рассказывается, что после необходимых доработок должно рассчитаться так-то и так (и он это видит). Целесообразно сопроводить такую модель текстовым описанием, пусть даже кратким, чтобы пользователь мог самостоятельно попробовать поработать с моделью в свободное время. В этом же описании можно формулировать требования к доработкам.
Демонстрация информационной модели рабочей группе	Полученную модель показываем Заказчику и рассказываем, как все должно работать.Демонстрацию модели лучше проводить по подсистемам, т.е. по группам требований. В случае, если выяснится, что у клиента предлагаемая схема работать не будет, надо подумать о других вариантах использования, внести изменения в модель и показать еще раз. Только если есть уверенность, что планируемая модель у данного клиента «будет жить», можно считать модель удачной.
Разработка тестов	Зачем нужны тесты? То, как мы смогли реализовать требования, нужно будет проверять. Соответственно, на все ключевые участки, сложные алгоритмы и пр. тесты желательно сделать. В том числе эти тесты могут быть использованы при сдаче работ. Вовсе необязательно делать тесты на каждую функцию системы, везде должен быть здравый смысл. Если речь идет о готовой системе, то делать тест на «ввод нового элемента в справочник клиентов» будет выглядеть глупо и бесполезной тратой сил и времени. А вот если это совсем новая система, такое вполне возможно. Зачем делать тесты, если еще нет системы?Во-первых, разработчику будет понятнее, чего от него хотят добиться. Во-вторых, мы облегчаем жизнь тестировщику (кто-то ведь будет тестировать результат разработки). Вообще, тестирование это отдельная дисциплина, весьма не простая с множеством методик. На практике, как правило, все равно используются самые простые методы тестирования.
Документирование требований в виде Технического задания	Собранная информация на предыдущих этапах будет являться как раз тем, что и должно войти в основу документа «Техническое задание» в раздел с требованиями.Так что остается все это грамотно оформить.
Дальнейшие действия (или их отсутствие), в зависимости от целей проекта	Дольше может начаться процесс разработки, поиск партнеров для проекта, тендер и т.д., все зависит от ситуации.

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

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

Областное коммунальное высшее учебное заведение

Институт предпринимательства «Стратегия»

Кафедра Экономической кибернетики

Курсовая работа

Тема:

«Проектирование и разработка информационной системы на примере магазина «Computer Master»»

Желтые воды 2010

Введение

Данная курсовая работа рассматривает пример создания информационной системы на базе частного предприятия «Computer Master ». Целью написания данной курсовой работы является изучение методов и способов разработки информационных систем.

Для данной экономической ситуации в стране не взирая на экономический кризис, повсеместно проходит процесс компьютеризации, данная курсовая работа является важной. Все чаще требуются работы по внедрению информационных систем для различных предприятий Украины, а значит растет спрос на квалифицированных специалистов в области создания и внедрения информационных систем. При этом, ИС требуются не только для крупных промышленных предприятий, а и для мелких частных предприятий, на которых так же могут существовать проблемы с управлением и работой предприятия вообще в условиях компьютеризации регионов Украины. Это и показывает данная курсовая работа, которая показывает необходимость внедрения информационной системы для небольшого частного предприятия «Computer Master », и возможный вариант данного внедрения.

1. Предпроектная стадия

1.1 Диалог с заказчиком

Диалог с заказчиком происходит в кабинете его предприятия «Computer Master ». Время встречи 7 ноября, пятница, 11:00.

Разработчик (Р): Здравствуйте! мне бы увидится с вашим начальником!

Секретарша (С): Здравствуйте! Вам, назначена встреча!?

Р: Да, мы созванивались насчет встречи!

С: Подождите немного, я уведомлю, что вы пришли! Проходите, он вас ждет!

Заказчик (З) : доброе утро, меня зовут Виктор Иванович. Пожалуйста, проходите, садитесь.

Р: Здравствуйте меня зовут Иощенко Иван.

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

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

З: Замечательно. Что вам для этого потребуется?

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

З: Это приемлемо. Думаю, мы сможем решить этот вопрос. Что вас еще интересует?

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

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

Р: По вашему мнению, на сколько эффективна работа вашего магазина?

З: Я считаю, мы на сегодняшний день работаем достаточно эффективно. Но как каждый руководитель я желаю повышения эффективности работы управляемого мной объекта.

Р: Каким образом обслуживаются клиенты в вашем магазине?

З: Клиенты обращаются к продавцу-консультанту, спрашивают у него необходимую информацию относительно того или иного товара, а тот в свою очередь старается представить ее и выдать желаемый товар. Затем происходит оплата за товар, если это товар который не требует установки или комплектации и имеется в наличии. Если же его нет, товар заказывается у поставщиков и предоставляется клиентам через определённое время. При покупке ПК, продавец-консультант составляет конфигурацию, которая удовлетворяет желанию клиента, и если комплектующие есть в магазине, компьютер собирается в течение 1–3 часов, если же нет то они заказываются у поставщиков, затем ПК комплектуются. Клиент расплачивается после получения товара.

Р: Ясно. Сколько человек и техники работает в вашем магазине?

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

Р: Каким образом ваши продавцы-консультанты получают информацию о наличии товара на складе, его характеристики?

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

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

З: Да, это так.

Р: Каким образом у вас осуществляется подбор ассортимента?

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

Р: Пару слов о поставщиках?

З: У нас не так уж много поставщиков, их можно разделить на несколько групп:

Мелкие и крупные,

Постоянные и периодические.

Всего обычно не более 5–6.

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

З: Обычно мы закупаем новый товар 1 раз в 2 недели. Перед этим связываемся с поставщиком, заказываем у него определённое количество товара. Учет поставок веду я сам на своем компьютере при помощи Exsel, но меня не устраивает ограниченность его функций для данной деятельности. Мне необходим четко сформированная и надежная система, обеспечивающая быстрый доступ к нужной мне информации, удобные средства для создания отчетов и т.д. Вы понимаете, что я имею ввиду?!

Р: Да, конечно. Это все, что меня интересовало. Я еще более подробно ознакомлюсь с копиями документов, которые Вы мне предоставили, и мы с вами приступим к работе.

З: Хорошо.

Р: Спасибо, Я позвоню вам через 2 дня, мы встретимся и уже детально рассмотрим проект нашей системы.

З: Договорились. До свидания.

Р: До встречи.

В результате встречи можно сделать такие выводы:

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

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

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

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

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

1.2 Описание объекта

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

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

1.3 Документооборот на предприятии

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

1. приходные накладные

2. расходные накладные

3. налоговая накладная

4. договор

5. всевозможные отчетности

6. гарантийные талоны и др.

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

Были выдвинуты следующие основные требования:

1. система проста в обращении

2. Эффективность ИС

3. система разрешит следующие основные проблемы:

· учет материальных запасов;

· учет денежных средств, полученных от реализации товаров;

· сокращение времени формирования отчетов;

· упорядоченность документооборота;

· экономия времени на обслуживание клиентов.

2. Концепция информационной системы

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

2.1 Описание выполненных работ

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

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

Бухгалтер ведёт учет на предприятии, и составляют финансовые отчетности.

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

В обязанности кладовщика входит контроль за наличием и состоянием товара на складе.

Таким образом, можно привести схему системы по автоматизации учета товаров и денежных потоков в магазине «Computer Master ».

2.2 Обоснование предложенного варианта концепции ИС

В связи с результатами изучения объекта автоматизации, разработчиком предлагается внедрить на предприятии систему 1С.

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

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

1. система легка в использовании

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

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

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

5. не трудно найти квалифицированного специалиста, работающего с системой 1С: Предприятие.

2.3 Предварительный состав, сроки выполнения и стоимость работ по внедрению ИС

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

Наименование работ	Сроки выполнения работ	Приблизительная стоимость работ. грн.
Монтаж компьютерной сети
Покупка программного обеспечения «1С»
Найм специалиста по внедрению и конфигурированию системы
Настройка конфигурации создание информационной базы (производит специалист)
Обучение персонала (выполняет специалист с учебного центра)
Найм специалиста для сопровождения и обслуживания системы
Подготовка к введению системы в експлуатацию

Если, подсчитать, то период от начала работ до внедрения системы составляет 3,5-4 месяца. Приблизительная стоимость создания и внедрения ИС по автоматизации учета товаров и денежных потоков от 7480 до 10200 грн. Что есть приемлемой сумой с учетом тех денежных средств которыми располагает заказчик.

3. Техническое задание на создание ИС

Техническое задание составляется в соответствии с ГОСТ 34.602–89 «техническое задание на автоматизирование системы управления».

Автоматизирование системы. Стадии создания. Ответственность за разработку ТЗ несет основной разработчик.

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

Полное наименование АИС: Информационная система по автоматизации учёта товаров и денежных потоков на предприятии «Computer Master».

Условное обозначение: АИС – «Computer Master».

Разработка ведется на основании договора №1 от 09.11.09 между заказчиком (Виктором Ивановичем директор «Computer Master») и разработчиком (Иощенко И.Г.)

Полное наименование предприятие ЧП «Computer Master».

Адрес: Кировоградская обл., г. Александрия, проспект Ленина 45.

Расчетный счет: №53425

Разработчик: Иощенко И.Г.

Адрес: Кировоградская обл., г. Александрия, ул. Садовая 16.

Создание информационной системы ведется на основании договора №1 от 10.01.10 между разработчиком и заказчиком.

Плановые сроки начала работ 9.11.09, окончания работ – 10.03.10.

Финансирование работ по созданию АИС будет осуществляться заказчиком.

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

3.2 Назначение и цели создания АИС

АСУ предназначена для автоматизации управления деятельностью фирмы, а именно:

Учет материальных запасов

Учет основных средств и нематериальных активов

Формирование отчетов

Учет движения товаров на складе

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

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

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

Магазин – пункт розничной торговли, что занимает отдельное помещение имеет торговый зал для покупателей. Склад используется как промежуточное звено в цепочке производитель-покупатель. Чем меньше запасов тем меньше время их хранения и ниже стоимость складских расходов.

Основная деятельность магазина ведется в нормальных условиях труда.

3.4 Требования к ИС

Требования:

Система должна быть простой и понятной пользователю.

Внедрение ИС должно привести к положительному экономическому эффекту.

Ведение учета товаров в магазине

Планирование затрат, связанных с приобретением и хранением товаров

Планирование доходов, связанных с реализацией товаров

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

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

Программное обеспечение должно включать:

1. 1С «Предприятие» и компоненты для работы ИС

2. Антивирусные программы

3. Офисные программы (MS Office или Open Office)

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

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

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

Даная информационная система будет внедрена в течении 3,5–4 месяцев.

Для работы с ИС необходимо обучить персонал.

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

Предпроектная стадия включает в себя:

Определение требований заказчика;

Разработка проекта АИС в соответствии с требованиями заказчика;

Разработка технического задания в соответствии с ГОСТ 34.602–89.27.01.08–21.02.08;

Проектная стадия:

Внедрение ИС;

Сопровождение системы.

Исполнителями работ являются:

Разработчик ИС;

Специалист по созданию ЛВС;

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

Ответственный за выполнение всех работ по всем этапам является разработчик ИС.

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

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

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

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

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

Протокол и журнал испытательной эксплуатации

Штатное расписание подразделений заказчика, которые обслуживают систему.

Акты передачи всех частей информационной системы заказчику

Проект программы и методики испытаний

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

3.7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в эксплуатацию

Для подготовки объекта ко вводу в эксплуатацию следует выполнить:

Подготовка объекта к переходу на работу в новой ИС

Опробование всех материалов технического и рабочего проектов и внесение изменений по результатам

Для внедрения ИС в эксплуатацию необходимо:

Оформить акты о выполнении плана мероприятий по подготовке объекта к внедрению.

Наличие документации по внедрению ИС.

Наличие персонала, что обеспечивает подготовку внедрения и эксплуатацию.

Наличие принятых в эксплуатацию технических средств ИС.

3.8 Требования к документации

Документация оформляется согласно стандартам ЕСКД, ЕСПД и ГОСТ.

В процессе разработки ИС могут бить использованы:

ГОСТ 19.001. – 77. ЕСПД. «Общие положения»;

ГОСТ 19.006. – 82. ЕСПД. «общие требования к программным документам, выполненным печатным способом»;

ГОСТ 19.201. – 82. ЕСПД. «техническое задание на разработку программы».

Кроме того, оформляются и согласовываются разработчиком и заказчиком, различного рода договора на проведение работ, акты о выполнении этапов создания ИС, графики выполнения работ по этапам и документы, составленные после выполнения каждого этапа.

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

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

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

4. Технорабочий проект

4.1 Общая системная документация

4.1.1 Пояснительная записка

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

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

Общее описание ИС «Computer Master »

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

Система отвечает основным целям её создания, а именно:

1. Обеспечение достоверности учетных данных о товарах на складе и о денежных потоках.

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

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

4. Формирование эффективной информационно – аналитической поддержки механизмов по оптимизации учета товаров и денежных потоков.

5. Снижение затрат на хранение товаров.

4.1.2 План мероприятий по подготовке объекта ко вводу ИС в эксплуатацию

Для ввода ИС в эксплуатацию необходимо:

1. Подготовка объекта автоматизации ко внедрению.

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

3. Комплектация ИС поставленными изделиями.

4. Переоборудование помещений и расположение рабочих станций в соответствии со стандартами и нормами.

5. Наем специалиста для обслуживания и сопровождения ИС (проводится заказчиком по рекомендациям разработчика).

4.1.3 Расчет экономической эффективности

Экономическая эффективность внедряемой АИС может быть оценена посредством вычисляемых эффектов. К ним можно отнести:

· Усиление контроля выполнения работ.

· Возможность протоколирования выполняемых операций.

· Увеличение степени надежности информации.

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

· Получение более развернутой информации, автоматизации её сбора.

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

Благодаря автоматизации объекта можно сократить численность продавцов до двух. Тогда зарплата двух продавцов составит 2∙12∙800=19200 грн. в год. Но затраты на содержание специалиста по обслуживанию системы обойдутся в 1∙12∙1000=12000 грн. в год.

Таким образом, годовой экономический эффект от внедрения ИС будет равен: 19200 – 12000 = 7200 грн. в год.

4.2 Документация функциональной части

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

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

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

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

· Формирование эффективной информационно-аналитической поддержки механизмов по оптимизации учета ТМЦ и денежных потоков, минимизации затрат на хранение ТМЦ.

4.2.2 Описание постановки задачи

Основойпостроения АИС «Computer Master » является внедрение системы «1С: Предприятие 7.7» с помощью которой и осуществляется решение проблемы автоматизации учета товаров и денежных потоков в магазине и на складе. Построенная база ИС отвечает целям, которые описании в п2 технического задания на систему, и соответствовать требованиям заказчика.

4.3 Документация организационного обеспечения ИС

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

Описание организационной структуры ИС

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

4.4 Документация информационного обеспечения

Информационное обеспечение (ИО) АИС состоит из нормативно – справочной информации, представленной в виде констант в системе «1С: Предприятие» и которые может изменять специалист по сопровождению АИС. Информационное обеспечение также включает также базы данных формата DBF (структура некоторых из них представлена в приложении 4), которые ранее не применялись на предприятии для учета товаров и были составлены в процессе внесения начальной информации.

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

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

4.5 Документация технического обеспечения

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

В состав технического обеспечения ИС входят: два компьютера одинаковой конфигурации, которые были в наличии. Компьютеры соединяются в локальную сеть с помощью кабеля типа «витая пара» и топологии «логическая кольцевая сеть» что позволяет передавать информацию, со скоростью 10–100 Мбит/сек.

Техническое обеспечение также включает печатающее устройство – принтер.

4.6 Документация математического обеспечения

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

4.7 Документация программного обеспечения

Программное обеспечение АИС «Computer Master » включает:

– операционную систему MS Windows, установленную непосредственно на рабочие станции,

– программу 1С: Предприятие 7.7, включая все её компоненты для непосредственной работы ИС,

– антивирусное программное обеспечение,

– архиватор

– Файловый менеджер

– другое программное обеспечение Microsoft Office 2003.

Основным программным обеспечением для работы АИС «Computer Master » является программа 1С: Предприятие 7.7 которая проинсталлирована на всех ПК, входящих в состав технического обеспечения ИС. Документация на эту программу принята в состав документации на ИС в целом.

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

Система имеет компонентную структуру. Всего три основных компоненты: «Бухгалтерский учет», «Оперативный учет», «Расчет». Каждая компонента расширяет возможности системы своим механизмом обработки информации.

Заключение

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

Список использованной литературы

1. Информационные системы и технологии в экономике За. Ред. В.С. Пономаренка, Киев, «Академия», 2002.

2. Филимоненко Н.И. конспект лекций по курсу «модели и методы управления проектами».

3. Автоматизированные информационные технологии в экономике. Под. Ред. Г.А. Титаренко, Москва, «Компьютер», 1998.

4. Единая система программной документации. Госкомитет СССР по стандартам, М., 1982.

5. Р. Фатрепп, Д. Шафер, Л. Шафер Управление программными проектами. Достижение. Достижение оптимального качества при минимуме затрат, «Вильямс», Москва – Санкт-Петербург – Киев, 2003.

6. Проектирование информационных систем. За. Ред. В.С. Пономаренко, Киев, «Академия», 2002.

Главная > Техническое задание

МИНИСТЕРСТВО КУЛЬТУРЫ РФ

Санкт-Петербургский государственный университет культуры и искусств

Кафедра информатики и информационных технологий

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

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

на разработку

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

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

на 4 листах

выдано __.__.200_

Санкт-Петербург

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

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

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

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

Назначение и цели создания учебной информационной системы

Назначение

Учебная информационная система предназначается:

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

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

Учебная информационная система создается для:

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

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

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

Состав отчетных материалов. Отчетные материалы должны состоять из двух основных частей: проектной документации и макета информационной системы (заполненной базы данных вместе с запросами, формами, отчетами, страницами доступа), реализованного средствами СУБД ACCESS (или другой системы). Макет должен быть реализован в соответствии с проектом. В проектных материалах должен быть описан макет и его возможности.

Содержание проектной документации

Проектная документация должна содержать следующие части.

Титульный лист с названием проектируемой ИС, указанием разработчика и заказчика. Раздел «Технико-экономическое обоснование», содержащий краткую характеристику предметной области:

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

Краткое Техническое задание. В ТЗ должны быть отражены:

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

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

Раздел «Технический проект», содержащий следующие подразделы:

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

Перечень использованных источников (литература). Раздел «Рабочий проект», содержащий следующие подразделы:

концептуальная схема ПО и физическая схема базы данных системы (разработанные средствами системы Power Designer); описание конкретной разработки по реализации проекта ИС:
описание схемы БД на ACCESS (или в другой СУБД), описание задач, реализующих функции, сформулированные в Техническом проекте (с приведением запросов, форм, отчетов, страниц доступа, используемых в этих задачах). Необходимо наличие диалоговых форм и инструкций по пользованию ими. Если в проекте отсутствуют сложные формы, отчеты, оценка снижается на 1 балл.

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

Макет информационной системы

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

Требования по оформлению документации

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

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

Перечень этапов работ и сроки их выполнения

Работы выполняются в соответствии с планом-графиком, приведенным на следующей странице (таблица 4.1).

Порядок контроля и приемки отчетных материалов

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

В осеннем семестре сдается отчет, соответствующий первым пяти пунктам плана-графика. В весеннем семестре сдаются окончательные результаты работы: отчет, (включающий и переработанные результаты предыдущего семестра), а также БД – макет разработанной ИС.

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

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

План-график работ по разработке отчетных материалов

Таблица 4.1.

	Наименование этапа	Срок выполнения	Предъявляемые материалы
	РАБОТЫ ОСЕННЕГО СЕМЕСТРА
1	Выбор предметной области и организации, для которой должна быть спроектирована информационная система	Через неделю после первой лекции	Название ИС
2	«Обследование» предметной области (по литературе и в результате общения с экспертами)	Неделя после третьей лекции
3	Разработка функциональной модели	Неделя после четвертой лекции	Функциональные схемы в рукописном виде
4	Разработка модели потоков данных	Неделя после пятой лекции	Схемы потоков данных в рукописном виде
5	Разработка описаний входных и выходных документов	Конец 25 ноября	Реквизитная структура документа, функциональные зависимости реквизитов
6	Разработка проектной документации в соответствии с пунктами 3.2.1 – 3.2.5	В процессе. практич. занятий.
7	Сдача проектной документации	20 декабря	Документация, оформленная в виде отчета
	РАБОТЫ ВЕСЕННЕГО СЕМЕСТРА
8	Разработка контекстной схемы предметной области	Неделя после второй лекции	Контекстная схема ПО в рукописном виде
9	Разработка схемы БД на языке выбранной СУБД	К концу второго практич. занятия
10	Реализация системы (заполнение таблиц БД, разработка запросов, форм, отчетов, страниц доступа)	К концу пятого практического занятия	Заполненная БД с запросами, формами и т.д.; предъявляется преподавателю
11	Оформление результатов (проект и БД)	Через неделю после п. 9	Курсовая работа: документация, оформленная в виде отчета и в файле; база данных
12	Защита курсовой работы	Не раньше, чем через неделю после предыдущего срока