Классическое проектирование АИС. Реферат на тему Классическое проектирование аис, каскадная схема проектирования аис, стадии и этапы проектирования аис в соответствии с гост 34. 60190.

• Название: Реферат на тему Классическое проектирование аис, каскадная схема проектирования аис, стадии и этапы проектирования аис в соответствии с гост 34. 60190.
• Анкор: Классическое проектирование АИС
• Дата: 17.04.2023
• Размер: 330.45 Kb.
• Имя файла: Классическое проектирование АИС.docx
• Тип: Реферат; #1067114

Частное профессиональное образовательное учреждение.

Пермского краевого союза потребительских обществ

«Пермский кооперативный техникум»

Реферат на тему

«Классическое проектирование АИС, каскадная схема проектирования АИС, стадии и этапы проектирования АИС в соответствии с ГОСТ 34.601-90. »

Выполнил: студент 3 курса группы ИС30/2020 Мезенцев Илья Николаевич Преподаватель: Самгин Виктор Николаевич

Верещагино, 2022 г.

Введение

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

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

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

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

Оглавление

Глава 1. Классическое проектирование АИС 4

2.1 Отрицательные факторы применения 6

Глава 2. Каскадная схема проектирования АИС 8

Глава 3. Стадии и этапы проектирования АИС в соответствии с ГОСТ 34.601-90 14

Приложения 19

Глава 1. Классическое проектирование АИС

Как классическое рассматривается проектирование ИС для достаточно стабильных условий, что явно или неявно предполагалось в 70-е и в первой половине 80-х годов XX в. Представительность соответствующих технологий, ориентация на наиболее массовую часть И С, наличие не только теоретических оснований, но и промышленных методик и стандартов, использование этих методик в течение десятилетий — именно это позволяет называть описываемые методы классическими. Методы проектирования таких ИС в 80-х годах были хорошо описаны и в зарубежной, и в отечественной литературе разных направлений: методические монографии, стандарты (ГОСТы, ANSI, ISO), учебники.

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

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

• 
  запуск: организация основания для деятельности и запуск работ: приказ и(или) договор о разработке автоматизированной системы, задание на выполнение работ (proposal for the development, agreement, mobilization);
  
• 
  обследование: предпроектное обследование, общий анализ ситуации на предприятии, разработка общего обоснования целесообразности создания ИС (feasibility stady, scope analysis, strategy stady and planning, requirement definition);
  
• 
  концепция, ТЗ: исследования требований предприятия и пользователей, выработка рекомендаций по разработке И С, разработка ТЗ на проектирование ИС в целом и частных ТЗ по подсистемам (strategy planning, analysis, requirement specification, function description);
  
• 
  эскизный проект: разработка архитектуры будущей ИС в рамках эскизного проекта (detailed analysis, high level design);
  
• 
  опытный вариант ИС разработка упрощенного варианта, пилотного проекта будущей ИС (pilot-project, test development);
  
• 
  опытное использование пилот-проекта ИС, разработка исправлений и дополнений к ТЗ (test, corrected requirement specification);
  
• 
  ТП разработка технического проекта ИС (detailed analysis and design, test development);
  
• 
  РП: разработка рабочей документации проекта (development, test, system implementation);
  
• 
  ввод в действие: по-другому — «внедрение» И С (deployment, put into operation).
  

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

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

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

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

2.1 Отрицательные факторы применения

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

Недостаток 1 (опоздание).

Чаще всего в качестве основного недостатка называлось существенное запаздывание с получением результатов, имевшее несколько аспектов:

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

Недостаток 2 (бесполезность).

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

В отечественной практике возник афоризм, описывающий эффект работы типичной АСУ, механически перемалывающей существующий бумажный поток: «Что на входе, то и на выходе». Ниже укажем, что современные аналитики до сих пор указывают на существование этого эффекта.

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

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

Глава 2. Каскадная схема проектирования АИС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На стадии проектирования в соответствии с утвержденными параметрами ТЗ осуществляется техническое и логическое проектирование и разрабатывается технический проект И С:

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

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

• 
  алгоритмизацию функциональных задач ИС;
  
• 
  разработку, отладку и тестирование ПО;
  
• 
  формирование информационных массивов и БД;
  
• 
  -подготовку программно-технической документации — руководств пользователям, системным программистам и администраторам ИС.
  

Стадия внедрения заключается в передаче ИС заказчику:

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

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

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

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

Глава 3. Стадии и этапы проектирования АИС в соответствии с ГОСТ 34.601-90

Формирование требований к АС

1.Обследование объекта и обоснование необходимости создания АС;

2.Формирование требований пользователя к АС;

3.Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания).

Разработка концепции АС

1. 
   Изучение объекта;
   
2. 
   Проведение необходимых научно-исследовательских работ;
   
3. 
   Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя;
   
4. 
   Оформление отчёта о выполненной работе.
   

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

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

Эскизный проект

1. 
   Разработка предварительных проектных решений по системе и её частям;
   
2. 
   Разработка документации на АС и её части.).
   

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

1. 
   Разработка проектных решений по системе и её частям;
   
2. 
   Разработка документации на АС и её части;
   
3. 
   Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (ТЗ) на их разработку;
   
4. 
   Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.).
   

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

1.Разработка рабочей документации на систему и её части;

2.Разработка или адаптация программ.

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

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

Сопровождение АС

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

Содержание работ:

На этапе 1.1. "Обследование объекта и обоснование необходимости создания АС" проводят: сбор данных об объекте автоматизации и осуществляемых видах деятельности; оценку качества функционирования объекта и осуществляемых видах деятельности, выявление проблем, решение которых возможно средствами автоматизации; оценку целесообразности создания АС.

На этапе 1.2. "Формирование требований пользователя к АС" проводят: подготовку исходных данных для формирования требований АС; формулировку и оформление требований пользователя к АС.

На этапе 1.3. "Оформление отчёта о выполненной работе и заявки на разработку АС" проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС.

На этапах 2.1. "Изучение объекта" и 2.2. "Проведение научно-исследовательских работ" разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчёты о НИР.

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

На этапе 2.4. "Оформление отчёта о выполненной работе" подготавливают и оформляют отчет, содержащий описание выполненных работ.

На этапе 3.1. "Разработка и утверждение ТЗ на создание АС" проводят разработку, оформление, согласование и утверждение ТЗ.

На этапе 4.1. "Разработка предварительных проектных решений по системе и её частям" определяются: функции АС; функции подсистем, их цели и эффекты; задачи; концепция инфо базы, её структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры программных средств.

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

На этапах 4.2. и 5.2. "Разработка документации на АС и её части" проводят разработку, оформление, согласование и утверждение документации.

На этапе 5.3. "Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку" проводят: подготовку и оформление документации на поставку изделий для АС; определение технических требований и составление ТЗ на разработку изделий.

На этапе 5.4 "Разработка заданий на проектирование в смежных частях проекта объекта автоматизации" осуществляют разработку и утверждение заданий для проведения строительных, электротехнических и др. работ, связанных с созданием АС.

На этапе 6.1 "Разработка рабочей документации на систему и её части" осуществляют разработку рабочей документации, содержащей все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АС в действие и её эксплуатации.

На этапе 6.2 "Разработка или адаптация программ" проводят разработку программ и программных средств системы, выбор и адаптацию приобретаемых программных средств.

На этапе 7.1 "Подготовка объекта автоматизации к вводу АС в действие" проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие.

На этапе 7.2 "Подготовка персонала" проводят обучение персонала и проверку его способности обеспечить функционирование АС.

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

На этапе 7.4 "Строительно-монтажные работы" проводят: выполнение работ по строительству специализированных помещений для размещения технических средств и персонала АС; сооружение кабельных каналов; выполнение работ по монтажу технических средств и линий связи, их испытание.

На этапе 7.5 "Пусконаладочные работы" проводят: наладку технических и программных средств.

На этапе 7.6 "Проведение предварительных испытаний" осуществляют: испытания АС на работоспособность и соответствие ТЗ; устранение неисправностей и внесение изменений в документацию на АС; оформление акта о приёмке АС в опытную эксплуатацию.

На этапе 7.7 "Проведение опытной эксплуатации" проводят: опытную эксплуатацию АС; анализ результатов эксплуатации; доработку ПО АС; дополнительную наладку технических средств АС; оформление акта о завершении опытной эксплуатации.

На этапе 7.8 "Проведение приёмочных испытаний" проводят: испытания на соответствие ТЗ; анализ результатов испытания АС и устранение недостатков; оформление акта о приёмке АС в постоянную эксплуатацию.

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

На этапе 8.2 "Послегарантийное обслуживание" осуществляют работы по: анализу функционирования системы; выявлению отклонений от проектных значений; установлению причин этих отклонений и их устранение; внесению изменений в документацию на АС.

Приложения

Приложение A

(Символами «+», «н—» и «++» показаны примерные оценки доли наличия каждого компнента на каждой стадии.)

Приложение B