Ответы_к_госам_final

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии

сэтим выделяют три следующие модели ЖЦ:

1.Каскадная модель (1970–1980 гг.) – предполагает переход на

следующий этап после полного окончания работ по предыдущему этапу.

2. Поэтапная модель с промежуточным контролем (1980–1985

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

3. Спиральная модель (1986–1990 гг.) – делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

каскадная модель, иногда также называемая моделью «водопад»

(waterfall);

спиральная модель.

Роль анализа в жизненном цикле программы

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

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

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

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

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

Цели анализа в моделировании

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

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

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

 Модель анализа структурирует требования так, что это облегчает их понимание, подготовку, внесение изменений и вообще работу с ними.

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

 Выполняя анализ отдельной фазой, вместо того чтобы выполнить его в ходе моделирования и реализации, можно недорого

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

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

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

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

Структурный подход к моделированию АИС

Идеи, лежащие в основе структурных методов

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

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

Конструирование системы черных ящиков существенно упрощается.

Облегчается тестирование таких систем.

Имеется возможность простого реконфигурирования системы черных ящиков

Облегчается доступность для понимания и освоения.

Увеличивается удобство при модификации.

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

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

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

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

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

ними.

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

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

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

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

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

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

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

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

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

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

 Принцип концептуальной общности – заключается в следовании единой философии на всех этапах ЖЦ (структурный анализ – структурное проектирование – структурное программирование – структурное тестирование).

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

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

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

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

Методология предпроектного обследования системы управления

Методика предпроектного обследования

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

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

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

решаемые задачи и выполняемые функции – на основе технологии анкетирования;

информационные потоки и связи, как внутренние, так и

внешние – с помощью реестров.

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

предприятие (директор);

службы и отделы (начальники отделов и служб);

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

отдельные рабочие места.

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

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

наблюдения;

опроса исполнителей (метод интервью);

анализа материалов (анкетирования);

личного участия.

Методы обследования управленческих процедур

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

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

организационная структура управления

цели, функции и задачи управления.

Взависимости от вида экономического объекта оцениваются технико-

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

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

Обследованию подвергается существующая система управления:

состав, периодичность и условия выполнения каждой управленческой функции или задачи;

число исполнителей функции управления, трудоемкость и

сложность работы управленческого персонала;

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

должностные инструкции, штатное расписание и организационная

структура управления – состав подразделений, сфера их деятельности, взаимосвязи по выполняемым функциям управления;

 состояние информационного обеспечения управления и нормативно-справочного хозяйства.

В результате обследования управленческих процедур: устанавливаются цели деятельности (обеспечение стабильного

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

п.) и критерии оценки их достижения; определяются функциональные подсистемы системы управления и

состав их задач.

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

Исследование потоков и структуры информации

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

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

состав и структура сообщений, правила их построения на внемашинном и внутримашинном уровнях (синтаксический уровень);

полезность сообщений для целей системы управления, выполнения

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

Обследование документов и документооборота системы управления

Итак, документ – это совокупность трех составляющих:

физическая регистрация информации;

форма представления информации;

активизация определенной деятельности.

Именно некоторая деятельность и превращает информацию в документ.

Документ – слабоструктурированная совокупность блоков или объектов информации. В общем случае обойтись без документов пока нельзя.

Документооборот может быть двух типов:

 универсальный – автоматизирующий существующие информационные потоки слабоструктурированной информации. Справедливо было бы его называть аморфным или беспорядочным документооборотом;

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

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

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

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

Методика сбора документации предпроектного обследования производится в 2 этапа: сбор материалов и передача материалов аналитикам.

Модели информационного пространства предприятия

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

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

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

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

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

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

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

Точка в пространстве (F, D, R) определяет состояние системы документооборота и имеет координаты (f,d,r), где f,d и r принадлежат множествам F,D и R соответственно. Положение этой точки зависит от уровня развития и стадии внедрения системы документооборота на предприятии, а также от его специфики и самих масштабов производства.

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

Эволюция модели

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

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

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

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

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

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

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

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