Каноническое проектирование ис кратко

Обновлено: 05.07.2024

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

Процесс каскадного проектирования в соответствии с ГОСТ 34601-90 "Автоматизированные системы стадий создания" делится на семь стадий:
В целях изучения взаимосвязанных приемов и методов канонического проектирования, перечисленные 7 стадий можно сгруппировать в часто используемые на практике четыре стадии процесса разработки АИС
- П1 - предпроектная стадия;
- П2 - стадия техно-рабочего проектирования;
- П3 - стадия внедрения;
- П4 - стадия эксплуатации и сопровождения проекта.
Рисунок 1 ТСП стадий и этапов канонического проектирования АИС:
Д 1.1. - Предметная область
Д 1.2. - Материалы обследования
Д 1.3. - ТЭО, ТЗ на проектирование
Д 1.4. - Эскизный проект
Д 2.1. - Техно-рабочий проект (ТРП)
Д 3.1. - Исправленный ТРП, переданный в эксплуатацию
Д 3.2. - Акт о приемке проекта в промышленную эксплуатацию
Д 4.1. - Модернизированный ТРП

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

Каноническое проектирование ИС характеризуется следующими особенностями:
1. Отражает особенности ручной технологии проектирование;
2. Предполагает выполнение индивидуального (оригинального) проектирования;
3. Не предполагает использования средств интеграции;
4. Соответствует каскадной модели ЖЦ ИС.

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

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

Стадия 1. Формирование требований к ИС.
На начальной стадии проектирования выделяют следующие этапы работ:
· обследование объекта и обоснование необходимости создания ИС;
· формирование требований пользователей к ИС;
· оформление отчета о выполненной работе и технического задания на разработку.

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

Стадия 3. Техническое задание.
· разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.
· разработка предварительных проектных решений по системе и ее частям;
· разработка эскизной документации на ИС и ее части.

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

Стадия 6. Рабочая документация.
· разработка рабочей документации на ИС и ее части;
· разработка и адаптация программ.

Стадия 7. Ввод в действие.
· подготовка объекта автоматизации;
· подготовка персонала;
· комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами);
· проведение опытной эксплуатации;
· проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.
· выполнение работ в соответствии с гарантийными обязательствами;
· послегарантийное обслуживание.

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

Каноническое проектирование ИС. Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

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

1. Формирование требований к ИС. Этапы работ: обследование объекта и обоснование необходимости создания ИС; формирование требований пользователей к ИС; оформление отчета о выполненной работе и тактико-технического задания на разработку.

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

3. Техническое задание: разработка и утверждение технического задания на создание ИС.

4. Эскизный проект: разработка предварительных проектных решений по системе и ее частям; разработка эскизной документации на ИС и ее части (архитектура проекта: структура входных и выходных данных, предварительная схема БД, общая архитектура ИС (структура, информ.потоки, модель управления ИС))

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

6. Рабочая документация: разработка рабочей документации на ИС и ее части; разработка и адаптация программ.

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

8. Сопровождение АС: выполнение работ в соответствии с гарантийными обязательствами, послегарантийное обслуживание.

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

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

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

Состав и содержание работ на стадиях:

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

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

Стадия 4. Ее цель – разработка предварительных решений. В экономических ИС применяется редко.

Стадия 5. Это основная стадия. Здесь уточняется состав и количество технических средств системы к узлам обработки данных. В части орг-го обеспечения предлагаются изменения в орг-ой структуре управления (пример: сливаются подразделения). В части инф-го обеспечения выбирается система классификации и кодирования, разрабатывается классификатор технико-экономической инф-ции; проектируется БД. Главное – алгоритмизация функциональных задач (не программирование). Разрабатываются формы документов, составляется план мероприятий по подготовке объекта к внедрению системы, проводится уточненный расчет ожидаемой экономической эффективности.

Стадия 6. Главное назначение – программирование или адаптация готовых программных средств. Здесь составляются технические инструкции, которые соответствуют должностным инструкциям, уточненным на стадии технического проектирования. При наличии проекта с-мы стадия техн-го проектирования. При наличии протатипа с-мы стадия технического проекта и рабочие документации объединяются в одну стадию – техно-рабочий проект.

Стадия 7. Проводится опытная эксплуатация и сдача системы комиссии в постоянную эксплуатацию в соответствии с требованиями технологического задания.

Стадия 8. Цель сопровождения системы – поддержание эксплуатационных характеристик на проектом уровне. Сопровождение осуществляется исполнителем. Формы сопровождения: консультационная помощь, устранение недостатков, предложения по развитию ИС.

В состав проектной документации по созданию ИС входят следующие основные док-ты:

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

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

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

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

- сбор материалов обследования;

- анализ материалов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ).

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

- техническое проектирование и

- подготовка объекта к внедрению проекта; опытное внедрение проекта и

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

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

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

Каноническое проектирование ИС

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

Стадии и этапы создания ИС , выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ :

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ :

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

Стадия 2. Разработка концепции ИС.

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

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

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

Стадия 4. Эскизный проект.

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

Стадия 5. Технический проект.

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

Стадия 6. Рабочая документация.

разработка рабочей документации на ИС и ее части;
разработка и адаптация программ.

Стадия 7. Ввод в действие.

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

Стадия 8. Сопровождение ИС.

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

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

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

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

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

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

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

Ориентировочное содержание этого документа:

ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы;
сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;
описание выполняемых системой функций;
возможности развития системы;
информационные объекты системы;
интерфейсы и распределение функций между человеком и системой;
требования к программным и информационным компонентам ПО, требования к СУБД;
что не будет реализовано в рамках проекта.

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

Модели деятельно сти организаци и ("как ес ть" и "как д олжно быть").

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

Типовое проектирова ние ИС. Понятие ти пового проекта, пред посылки типизац ии.

Объекты типизации. Методы типового проектирован ия. Оценка эффективн ости

Типовое проектное решение (ТПР) . Классы и структура ТПР. Состав и содер жание

Функциональные пакеты прикладных программ (ППП) как основа Т ПР. Адаптац и я

типовой ИС. Методы и средства про тотипного про ектирования ИС.

Организация кано нического про ектирования ИС ориентирова на на использовани е

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

В зависимости от сложности объ екта автоматиз ации и набора зад ач, требующи х

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

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

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

Стадии и этапы с оздания ИС, выполня емые ор ганизациями - участ никами,

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

На начальной стади и проектир ования выделяю т следующие этапы р абот:

обследование о бъекта и обо снование необх одимости создания ИС;

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

проведение необходим ых научно - исследоват ельских работ;

разработка вариан тов концепции ИС, удовлетворяющ их требования м

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

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

разработка эскизн ой докум ентации на ИС и ее части.

разработка про ектных решений по системе и ее частям;

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

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

комплектация ИС п оставляемым и изделиям и (программными и техническ ими

средствами, программн о - техни ческими компл ексами, инф ормационн ыми

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

Oбследование - это изучение и диагностич еский анализ организационн ой структуры

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

Материалы, получ енные в результате обсл едования , и спользуются для:

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

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

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

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

стратегии внедр ения ИС и детальн ый анализ деятельности ор ганизации.

Основная задача п ервого этапа обследовани я - оценка р еального объема про екта, его

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

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

заказчиком ИС са мостоятельн о, или с привле чением консалт инговых организац ий. Этап

предполагает т есное взаимодействи е с основными п отенциальными пользователями

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

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

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

По завершении этой стадии о бследования появляется возможность опред елить

вероятные техни ческие подходы к созданию системы и оц енить затраты на ее

реализацию (затраты на аппаратн ое обеспечение, закупаемое прогр аммное

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

Результатом этапа определения страт егии явл яется документ ( т ехнико - эконом ическое

обоснование про екта ), где четк о сформулировано , что получит зака зчик, если

согласится финанс ировать проект, ко гда он получ ит готовый проду кт (график

выполнения рабо т) и сколько эт о будет стоить (дл я крупных пр оектов должен быть

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

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

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

ограничения, ри ски, критич еские факторы, которые могут повлиять на

совокупность усл овий, при которых предполагается эксплуатироват ь будущую

систему: архит ектура системы, аппаратн ые и программ ные ресурсы , условия

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

сроки завершения отдельных этап ов, форма пр иемки/сдачи раб от,

интерфейсы и ра спределение ф ункций между человеком и сис темой;

требования к про граммным и информационны м компонентам ПО, требования к

На этапе детальн ого анализа деят ельности организ ации изучают ся задачи,

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

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

вышестоящим органа м управлен ия. На этом э тапе должны быт ь выявлены:

инструктивно - методические и д ирективны е материалы , на основани и которых

возможности пр именения новых методов реш ения задач.

Аналитики собира ют и фиксируют информаци ю в двух взаим освязанных ф ормах:

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

сущности - информ ация о вещах, имеющих значен ие для орган изации и о

При изучении ка ждой функцио нальной задач и управления опр еделяются:

наименование задачи; сроки и периоди чность ее реш ения;

источники инф ормации, необход имые для ре шения задачи;

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

действующие ср едства сбора, пе редачи и обработки информа ции;

действующие форм ы представлен ия исходны х данных и результа тов их

Одной из наибол ее трудоемких, х отя и хорошо формал изуемых зада ч этого этапа

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

документообор ота составляется сх ема маршрута дв ижения докумен тов, которая должна

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

По результатам обследования устанавли вается перечень задач управления, р ешение

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

На этапе об следования следу ет классифиц ировать планиру емые функц ии системы по

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

Эта аббревиатура ра сшифровыва ется так: Mu st have - необходимы е функции; Sh ould

have - желательн ые функции; C ould have - возможные функции; W on't have -

Функции первой кат егории обеспе чивают крити чные для успешн ой работы систем ы

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

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

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

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

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

Модели деятельно сти организации создаются в дв ух видах:

модель "как ес ть" ("as- is")- отражает существующи е в организации бизн ес -

модель "как должно быть" ( "to-be") - отражает н еобходимые изм енения

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

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

аппаратных платформ , операц ионных сист ем, СУБД, иног о окружен ия;

разработки плана раб от по обе спечению над ежности информац ионной си стемы и

Привлечение тест ировщиков на ранних этапа х разработки я вляется целесообраз ным

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

сл ишком п оздно (на этапе разр аботки или, ч то еще хуже, на этапе внедрения в

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

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

стоимость сопровожд ения с истемы. Вр емя на тестировани е системы и на исправление

обнаруженных ошиб ок следует преду сматривать не тол ько на этапе разработки, но и на

Для автоматизаци и тестирования след ует использо вать системы отс леживания ошибо к

(bug trackin g). Это позволяет и меть единое хр анилище ошибок, отслеживать их

повторное появлен ие, контролиро вать скорость и э ффективность ис правления ошибо к,

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

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

e- mail и т.п.). Чем б ольше про ект, тем сильн ее потребност ь в bug tracking.

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

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

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

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

установить общую ц ель создания ИС, опреде лить состав подс истем и

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

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

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

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

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

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

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

уровень экономич еской эффекти вности ее внедрения .

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

Читайте также: