Главная страница
Навигация по странице:

  • 3.2.1.Начальное исследование Начальное исследование

  • 3.2.2. Обследование системы

  • 3.2.3. Техникоэкономическое обоснование

  • 3.2.4. Определение информационных потребностей и требований к системе

  • технология проектирования ИС. Реферат на тему _Технологии проектирования ИС_. Лекция Технологии проектирования ис 1 Основные определения


    Скачать 0.49 Mb.
    НазваниеЛекция Технологии проектирования ис 1 Основные определения
    Анкортехнология проектирования ИС
    Дата17.03.2023
    Размер0.49 Mb.
    Формат файлаdocx
    Имя файлаРеферат на тему _Технологии проектирования ИС_.docx
    ТипЛекция
    #996770
    страница3 из 8
    1   2   3   4   5   6   7   8

    План разработки проекта - основная составляющая планирования ИС. Он содержит анализ затрат и доходов, требования к разработке и применению, включая требования к аппаратному и программному обеспечению, финансированию, кадрам, а также расписание мероприятий, необходимых для разработки. Деятельность по разработке проекта должна быть представлена графиком работ. График выполнения проекта представляет собой сжатое описание основных шагов разработки, определяющих сроки их выполнения и исполнителей. Множество инструментальных средств управления проектом могут применяться для разработки графика и отслеживания отклонений от него. Большинство проектов ИС используют диаграмму Ганта (Gantt chart), изображенный на рис.3.4.



    Рис. 3.4, Представление графика работ диаграммой Ганта

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

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

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

    3.2. Анализ системы

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

    Таблица 3.1,

    Шаги анализа системы



    3.2.1.Начальное исследование

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

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

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

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

    Таблица 3.2,

    Примеры формулировки проблем



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

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

    • архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и ПО;

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

    • требования к программным и информационным компонентам ПО, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонентов ПО, их интерфейсы.

    3.2.2. Обследование системы

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

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

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

    — наладить рабочие взаимоотношения с пользователями ИС;

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

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

    Таблица 3.3

    Достоинства и недостатки методов сбора данных о системе



    Собранная информация должна быть документирована для дальнейшего использования. Эффективный способ документировать систему в процессе анализа. - создать модель системы. Для этой цели используются различные методики: диаграммы потоков данных (DFD - dataflow diagrams) для описания документооборота в компьютерных системах и в организации, блок-схемы процедур, моделирование данных (ERD- entity relation diagrams), прототи-
    пирование и др.

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

    3.2.3. Техникоэкономическое обоснование

    Информация, собранная на этапе обследования системы, используется для проведения более детального технико-экономического обоснования (feasibility study, business case). Это самый трудный этап в создании системы. При работе с масштабными системами для него даже часто создают специальную группу, в которую входят руководители, бухгалтеры, пользователи, специалисты по компьютерам. Поскольку технико-экономическое обоснование выполняется в начале цикла разработки системы, часто исследование не учитывает некоторые
    проблемы или параметры, которые могут значительно изменить ожидаемый масштаб системы. Естественно, что обоснование требует времени и средств и для очевидных проектов не выполняется. Стоимость работ по технико-экономическому обоснованию должна составлять не более 5-10% от стоимости разработки системы.

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

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

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

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

    Временные возможности. Может ли ИС быть создана в отведенное время?

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

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

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

    Титульная страница – наименование проекта, заголовок проекта, автор(ы), дата.

    Оглавление – список глав с номерами страниц.

    Определение проблемы – ясное, сжатое сжатое до одной страницы определение проблемы.

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

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

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

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

    Рекомендации – устанавливается рекомендованное направление разработки проекта. Представляется материал для поддержки и обоснования рекомендаций. В особенности представляется анализ стоимость/эффективность.

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

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

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

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

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

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



    Как предлагают пользователи и менеджеры

    Как преподносится высшему руководству

    Как планируется группой разработчиков

    Как утверждается руководящим комитетом



    Как разработана главным аналитиком

    Как написана программистами

    Как установлена для использования

    Что на самом деле нужно пользователям

    Рис. 3.5 Коммуникационные проблемы анализа системы.

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

    Для определения требований к системе используются различные методики: опрос пользователей об их потребностях, анализ существующих систем, исследование их применения, использование прототипа новой системы (табл.3.4.).

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

    Таблица 3.4.

    Возможное содержание требований к системе

    Процессы

    Описание всех процессов в новой системе, включая распределение обязанностей исполнителей

    Элементы данных

    Описание элементов данных, включая имена, форматы, источники и предназначение

    Структуры данных

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

    Выходы

    Образцы выходных документов с объяснением их назначения, частоты использования, предназначения

    Входы

    Образцы первичных документов и объяснение их содержания, источников и ответственных за них лиц

    Документация

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

    Ограничения

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

    Контроль

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

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

    Требуемые реорганизационные меры - увеличение или сокращение штатов, добавление новых функций, создание подразделений
    1   2   3   4   5   6   7   8


    написать администратору сайта