Перечень вопросов к зачету


Классическое проектирование информационных систем



страница17/43
Дата09.05.2018
Размер3.55 Mb.
1   ...   13   14   15   16   17   18   19   20   ...   43

Классическое проектирование информационных систем


Как классическое рассматривается проектирование ИС для достаточно стабильных условий, что явно или неявно предполагалось в 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). Схема обязана была включать итерационные процедуры уточнения требований к системе и рассмотрения вариантов проектных решений. Все же эти процедуры и целые этапы работ носили в основном последовательный характер, а, кроме того, предметом была проектируемая ИС целиком, в целостном ее представлении.

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

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

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

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



Стадии


проекта

Виды обеспечения информационной системы

организационное

методическое

информационное

программное

аппаратное

Запуск

+-













Обследование

+-

+-

+-







Концепция ТЗ

+-

+-

+-







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

+-

+-

+-

+-




ТП

+-

+ +

+

+-

+-

РП

+ +

+ +

+ +

+ +

+

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

+ +

+ +

+ +

+ +

+ +

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

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

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

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

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

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

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



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

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

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

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



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

1. Схема непрерывной разработки. Примером может служить подход, который руководители больших проектов IBM в 70-х — 80-х годах прошлого столетия называли «Продолжающейся разработкой». Характеризующей особенностью такого подхода стал непрерывный процесс разработки и развития большой ИС с планируемыми точками передачи в эксплуатацию новых версий и новых функциональных блоков (подсистем, задач) и встроенными в процесс постоянно осуществляемыми процедурами экспертизы качества, работоспособности и др.

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

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



Рис. 5.1. Схема непрерывной разработки

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

2. Схема циклической разработки. В 80-х годах использование принципа продолженной разработки для ускоренного поочередного внедрения отдельных программных комплексов — прикладных или общесистемных — стало развиваться в разных направлениях и получило несколько ходовых жаргонных названий, например «быстрое прототипирование» (rapid prototyping approach или fast-track). В проектный цикл для этого дополнительно включались такие стадии:

• разработка макета-прототипа фрагмента будущей ИС (rapid prototyping) совместно с будущим пользователем;

• опробование макета-прототипа фрагмента будущей ИС, доработка прототипа до работающего фрагмента ИС (feedback, improved prototype design and development).

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

Недостаток 3 и 4 (жесткость и закрытость). Рассмотренные усовершенствованные схемы проектирования претендовали и сейчас часто претендуют на получение и ввод в действие компонентов формально целостной в традиционном смысле ИС и последующей их стыковки в такую ИС.

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

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

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

Одно из популярных в то время представлений архитектуры такой закрытой ИС показано на рис. 5.2, где:

1) компьютер конкретного типа (конкретной фирмы-производителя);

2) конкретная операционная система для данного типа компьютера;

3) СУБД для 1 и 2;

4) прикладные программы для 2 и 3: пакетные (диалоговые) для фиксированных функций или языки нерегламентированных запросов;

5) пользователь-оператор, обученный именно для 2, 3 и 4;

6) конечный пользователь: обучен и снабжен инструкциями для работы именно с 4 и 5.



Рис. 5.2. Модель-луковица закрытой ИС


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

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

Классические методы проектирования. Конец 70-х — начало 80-х годов — это время становления технологии интегрированных баз данных как одной из головных технологий в проектировании ИС. Был разработан и вошел в практику большой набор теоретически обоснованных методов: проектирование концептуальных и логических схем БД, организация физической среды хранения данных, планирование путей доступа к данным и др. Развивались методы проектирования функций: от методов формальной спецификации функций до структурного программирования и первых непроцедурных языков программирования четвертого поколения (4GL). Анализ функций (задач) предприятия также служил основой и в проектировании БД. Появились CASE-системы, ориентированные на формализацию информационных и функциональных требований к ИС и предназначенные для формального описания и бригадной разработки больших программных комплексов.

В конце 70-х — середине 80-х годов XX в. и в нашей стране большое количество разработчиков успешно применяли методы разработки ИС и БД не только на интуитивно-ремесленном уровне, но и как элементы сложившейся дисциплины. Укажем на наиболее популярные из них, применявшиеся на первых стадиях проектирования.

Обследование, общий анализ ситуации на предприятии и разработка общего обоснования целесообразности создания ИС (feasibility stady, scope analysis, strategy stady and planning):

общий системный и ситуационный анализ текущего состояния и целей предприятия, его масштабов, возможности, стоимости и способов разработки ИС, решающей задачи, способствующие достижению целей предприятия; использование методов, структурного анализа, ГОСТов на разработку АСУ и САПР.

«Концепция, ТЗ»: исследования требований предприятия и пользователей, выработка вариантов и рекомендаций по разработке ИС, разработка ТЗ на проектирование ИС в целом и ЧТЗ по подсистемам (strategy stady, analysis, requirement specification):

1) анализ критических факторов успеха и риска с использованием системного и ситуационного анализа;

2) обследование предприятия методами анализа документов, интервью, прямых наблюдений, хронометража и др. (большое количество методик: от SADT Д. Росса до ГОСТа по предпроектным исследованиям при разработке САПР);

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

4) проектирование более целесообразных и учитывающих создаваемую ИС оргструктуры, набора и иерархии функций («задач»), видов документов и правил документооборота, вычленение предметных БД, определение взаимосвязей между ними;

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

6) построение недетализированных моделей БД и функций ИС (с использованием диаграмм данных Ч. Бахмана, модификаций ER-модели П. Чена, функциональных моделей по стандартам IDEFO, по методике HIPO или др.);

7) сбор и описание детальных требований к составу данных и алгоритмам реализации функций (см., например, популярную [16], а также [58], [61] и требования серий ГОСТ24 и ГОСТ36).

«Эскизный проект»: разработка архитектуры будущей ИС в рамках эскизного проекта (detailed analysis, high level design):

1) построение нормализованной реляционной или сетевой модели БД (методы получения нормальных форм Бойса — Кодда, четвертых и пятых нормальных форм, использование предложений комитета CODASYL);

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

3) определение модульной иерархии (верхние уровни) программного обеспечения ИС (модульное программирование, метод HIPO);

4) определение принципов организации аппаратного компьютерного комплекса, на базе которого должна функционировать ИС (расчеты физических параметров ИС: объемов БД, временных характеристик отдельных операций доступа к данным, целых функций и режимов в целом, организации компьютерных сетей, см. также [58]);

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

6) определение совокупности требований к приемке будущей ИС;

7) определение сроков, состава работ и их стоимости для последующих работ по ИС.

Существовал набор методов, применявшихся и на других этапах.

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

Некоторые из усовершенствований в компьютерной поддержке проектирования ИС начиная со второй половины 80-х годов:

1) широкое применение графических диалоговых интерфейсов (диаграммы структур данных, иерархий функций, потоков данных и др.);

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

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

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

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





Поделитесь с Вашими друзьями:
1   ...   13   14   15   16   17   18   19   20   ...   43


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница