Реферат Курсовая Конспект
Минимальный набор лекций по АИС Введение и история - раздел История, Минимальный Набор Лекций По Аис ...
|
Минимальный набор лекций по АИС
Введение и история
Блочные методы проектирование
Жизненный цикл
Основные стадии проектирование АИС
Способы построение АИС
Методика выбора АИС
Методология и технология проектирования АИС
Модели как есть и как будет
Жизненный цикл автоматизированных информационных систем (ЖЦ АИС)
Характеристики классов технологий проектирования
Класс технологии проектирования | Степень автоматизации | Степень типизации | лапти |
Каноническое проектирование | Ручное проектирования | Оригинальное проектирование | Реконструкции |
Индустриальное автоматизированное проектирование | Компьютерное проектирование | То же | Реструктуризация модели |
Индустриальное типовое проектирование | То же | Типовое сборочное проектирование | Параметризация и реструктуризация модели |
^ Каноническое проектированиеАПС ориентировано на использование главным образом каскадной модели жизненного цикла АИС.Стадии и этапы работы такого проектирования описаны
в ГОСТ 34.601 —90.
В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной АИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей.
Стадии и этапы создания АИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ.
Сопровождение АИС:
Рассмотрим специфику составляющих некоторых стадий подробнее.
Обследование— это изучение и анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации [20].
Материалы, полученные в результате обследования, используются для:
На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ^ АИС и детальныйанализ деятельности организации.
Основная задача первого этапа обследования оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком АИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес - экспертами. Основная задача взаимодействия получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.
По завершении стадии обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (на аппаратное обеспечение, на закупаемое программное обеспечение и на разработку нового программного обеспечения).
Результатом этапа определения стратегии является документ (технико-экономическое обоснование - ТЭО — проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов — это график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).
Примерное содержание ТЭО:
На этапе детального анализа деятельности организации изучаются деятельность, 0еспечивающая реализацию функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчиненности вышестоящим органам управления. Здесь следует наметить инструктивно методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач, а также возможности применения новых методов решения задач.
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
При изучении каждой функциональной задачи управления
определяются:
потребители результатной информации по задаче.
Одной из наиболее трудоемких, хотя и хорошо формализуемых, задач этого этапа является описание документооборота организации. При обследовании документооборота составляется схема маршрута движения документов, которая должна отразить:
По результатам обследования устанавливают перечень задач управления, подлежащих автоматизации, и очередность их разработки.
На этапе обследования следует классифицировать планируемые функции системы по степени важности.
Один из возможных форматов представления такой классификации — MuSCoW [22].
Эта аббревиатура расшифровывается так:
Функции первой категории обеспечивают критичньте для успешной работы системы возможности. Реализация функций второй м третьей категорий ограничивается временными и финансовыми рамками: разрабатывается необходимое, а также максимально возможное в порядке приоритета число функций второй и третьей категорий. Последняя категория функций особенно важна, поскольку нужно четко представлять границы проекта и набор функций, которые будут отсутствовать в системе.
Модели деятельности организации создаются в двух видах:
Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Чем позже обнаружены ошибки в проектных решениях, тем дороже обходится их исправление; Худший вариант — их обнаружение на этапе внедрения. Таким образом, чем раньше группы тестирования начнут выявлять ошибки в АИС, тем ниже стоимость работы над системой. Время на тестирование системы и на исправление обнаруженных ошибок должно быть предусмотре1о не только на этапе разработки, но и на этапе проектирования.
Облегчить и увеличить эффективность тестирования признаны специальные системы отслеживания ошибок. Их использование позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования.
Результаты обследования представляют объективную основу для формирования технического задания на АИС [16— 181.
^ Техническое задание— это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
При разработке технического задания (ТЗ) необходимо решить следующие задачи:
Типовые требования к составу и содержанию технического задания приведены в таблице ниже:
^ ТаблицаСостав и содержание технического задания
(ГОСТ 34.602 – 89)
Раздел | Содержание |
Общие сведения | Полное наименование системы и ее условное обозначение. Шифр темы или шифр (номер) договора. Наименование предприятий разработчика и заказчика системы, их реквизиты. Перечень документов, на основании которых создается ИС. Плановые сроки начала и окончания работ. Сведения об источниках и порядке финансирования работ. Порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств |
Назначение и цели создания (развития) системы | Вид автоматизируемой деятельности. Перечень объектов, на которых предполагается использование системы. Наименования и требуемые значения технических, технологических, производственно – экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС |
Характеристика объектов автоматизации | Краткие сведения об объекте автоматизации. Сведения об условиях эксплуатации и характеристиках окружающей среды |
Требования к системе | Требования к системе в целом:
|
Классификация CASE средств
Классификация CASE-средств
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;
репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
средства разработки приложений, включая языки 4GL и генераторы кодов;
средства конфигурационного управления;
средства документирования;
средства тестирования;
средства управления проектом;
средства реинжиниринга.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования ииспользующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE).Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).
Вспомогательные типы включают:
средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
средства конфигурационного управления (PVCS (Intersolv));
средства тестирования (Quality Works (Segue Software));
средства документирования (SoDA (Rational Software)).
На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
Vantage Team Builder (Westmount I-CASE);
Designer/2000;
Silverrun;
ERwin+BPwin;
S-Designor;
CASE.Аналитик.
– Конец работы –
Используемые теги: минимальный, набор, лекций, аис, Введение, История0.086
Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Минимальный набор лекций по АИС Введение и история
Если этот материал оказался полезным для Вас, Вы можете сохранить его на свою страничку в социальных сетях:
Твитнуть |
Новости и инфо для студентов