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

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

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

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

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

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

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

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

Введение

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

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

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

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

---

Оглавление

Глава 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. Каскадная схема проектирования АИС

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---