- •Двусторонние шпоры по файзу
- •Печатай прямо этот файл
- •1. Общая характеристика процесса проектирования асоиу. Цели и этапы разработки консалтинговых проектов
- •2. Разработка системного проекта на основе стандарта iso 12207. Основные процессы жизненного цикла программного обеспечения асоиу.
- •3. Модели жизненного цикла программного обеспечения асоиу. Подход rad.
- •3. Методология rad
- •Основные принципы методологии rad
- •4. Структурный подход к проектированию информационной системы. Функциональная модель асоиу. Количественный анализ диаграмм idef0 и dfd.
- •5. Объектно-ориентированный подход к анализу и проектированию информационной системы. Унифицированный язык моделирования uml.
- •6. Моделирование бизнес-процессов спецификация требований на основе структурного подхода.
- •7. Моделирование бизнес-процессов спецификация требований на основе объектно-ориентированного подхода. Методика rup.
- •8. Разработка модели защиты данных в асоиу
- •9. Управление проектом асоиу
- •10. Проектная документация асоиу. Требования госТов к документации, содержание документации.
- •11. Инструментальные средства проектирования асоиу.
- •12. Типизация проектных решений асоиу. Использование коробочных продуктов и адаптируемых интегрированных систем.
- •Самостоятельная разработка
- •Заказные системы
- •Тиражируемые (коробочные) продукты
- •Адаптируемые интегрированные системы
- •Адаптируемые интегрированные системы как платформа современных комплексных систем автоматизации
- •13. Графические средства представления проектных решений асоиу (idef, dfd, uml, erd и т.Д.)
- •14. Классификация ис
- •15. Рынок ис
- •16. Методы проектирования ис
- •17. Каноническое проектирование
- •18. Типовое проектирование
- •19. Предпроектное обследование предприятий
- •1. Анкетирование
- •2. Сбор документов
- •3. Интервьюирование
- •20. Этапы проектирования ис с применением uml
- •21. Модель процессов msf (тут же про опыт ibm)
- •22. Сертификация и оценка процессов создания по. Модель зрелости cmm.
- •23. Сертификация и оценка процессов создания по. Методика spmn.
- •9 Лучших навыков, рекомендованных spmn.
- •5. Качество продукта должно контролироваться на детальном уровне.
- •8. Конфигурационное управление.
- •24. Парадигма Бейзили
- •25. Проектирование бд
- •26. Распределенная обработка данных
- •27. Системное проектирование программных систем на основе стандартизации
- •28. 34 Компетенции для Управления Проектом
Адаптируемые интегрированные системы как платформа современных комплексных систем автоматизации
Разработка АСОИУ на базе адаптируемых интегрированных систем ведется, как правило, на основе соответствующего договора между заказчиком и исполнителем. Процесс создания АСОИУ на базе адаптируемых интегрированных систем в общем случае включает в себя несколько этапов: заключение договора, обследование предприятия, проектирование модели бизнеса, консультации (консультации могут осуществляться на протяжении всего проекта, параллельно с другими работами), настройка автоматизированной системы на модель бизнеса (происходит адаптация интегрированной системы исходя из построенной модели бизнеса), технологическое внедрение (проводится установка у заказчика необходимого оборудования и соответствующих программ), сопровождение и развитие (необходимые консультации, поставка обновленных версий программных модулей, разработка при необходимости, новых функциональных модулей и т. д.).
13. Графические средства представления проектных решений асоиу (idef, dfd, uml, erd и т.Д.)
Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую АСОИУ, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
CASE-средства обладают следующими основными особенностями :
-
имеют мощные граф/ср-ва для описания и документирования АСОИУ;
-
осуществляют интеграцию отдельных компонент CASE-средств;
-
используют организованное хранилище проектных метаданных (репозитория).
Интегрированное CASE-средство должно содержать следующие компоненты:
-
репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
-
графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели АСОИУ;
-
средства разработки приложений, включая языки 4GL и генераторы кодов;
-
средства конфигурационного управления;
-
средства документирования;
-
средства тестирования;
-
средства управления проектом;
-
средства реинжиниринга.
Все современные CASE-средства классифицируются по типам (отражает функциональную их ориентацию на те или иные процессы ЖЦ (в основном совпадает с компонентным составом CASE-средств)). Класс-ция по категориям определяет степень интегрированности по выполняемым функциям и включает следующее :
-
отдельные локальные средства, решающие небольшие автономные задачи (tools);
-
набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла систем (toolkit);
-
полностью интегрированные средства, поддерживающие весь ЖЦ систем и связанные общим репозиторием.
CASE-средства можно классифицировать по другим признакам:
-
применяемым методологиям и моделям систем и БД;
-
степени интегрированности с СУБД;
-
доступным платформам.
На сегодня российский рынок ПО располагает следующими CASE-средствами: Vantage Team Builder, Designer/2000, Silverrun, Erwin+Bpwin, S-Designor, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE; VIS; RATIONAL ROSE.
DFD- диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью требования представляются в виде иерархии процессов, связанных потоками данных. Главная цель– показать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии определяют основные процессы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня.
Основные компоненты: внешние сущности, системы и подсистемы, процессы, накопители данных, потоки данных.
Внешняя сущность – материальный объект или физ/лицо, представляющее собой источник или приемник инф-ии.
Процесс преобразования входных потоков данных в выходные. Номер процесса служит для его идентификации. В поле имени вводится наименование процесса. Инф-ия в поле физической реализации показывает, какое подразделение организации, программа, аппаратное устройство выполняет данный процесс.
Накопитель данных – абстрактное устройство для хранения информации, которую можно извлечь.
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику.
ERD – данная нотация используется в CASE средстве Oracle Designer.
Первый шаг моделирования – извлечение информации из интервью и выделение сущностей.
Второй шаг моделирования – идентификация связей. Связь- это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным количеством экземпляров, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности родителя. Имя связи между двумя сущностями должно быть уникальным. Имена связи модели не должны быть уникальны. Имя связи формируется с точки зрения родителя. Степень и обязательность связи можно показать графически.
Третий шаг – идентификация атрибута. Атрибут может быть либо обязательным, либо не обязательным. Каждый атрибут идентифицируется уникальным номером и изображается в виде списка имен внутри блока ассоциированной сущности. Каждая сущность обладает хотя бы одним возможным ключом.
Возможный ключ – один или несколько атрибутов, чьи значенья однозначно определяют каждый экземпляр сущности.
Супертипы и подтипы: одна сущность является обобщающим понятием для группы подобных сущностей.
Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи из группы взаимно исключающих связей.
Рекурсивная связь – сущность может быть связана сама с собой.
Неперемещаемые связи – экземпляр сущность не может быть перенесен из одного экземпляра связи в другой.
UML - является прямым объединением и унификацией методов Буча, Рамбо, Якобсона. Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических и других. UML содержит стандартный набор диаграмм и нотаций: диаграммы вариантов использования (для моделирования бизнес-процессов организации), классов (для моделирования статической структуры классов системы и связи между ними), поведения системы, взаимодействия (для моделирования процесса обмена сообщениями между объектами), состояния (для моделирования поведения объектов системы при переходе из одного состояния в другое), деятельности (для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельности ).
IDEF0 – диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм, который осуществляет операцию, представляется дугой, входящей в блок снизу.