- •Основы построение аис Содержание
- •1. Понятие автоматизированной информационной системы
- •2. Структура автоматизированной информационной системы
- •3. Основные понятия системного анализа
- •4. Порядок системного анализа
- •5. Принципы системного анализа
- •6. Понятие жизненного цикла аис и его модели
- •7. Процессы жизненного цикла аис: основные, вспомогательные, организационные.
- •8. Этапы (стадии) жизненного цикла аис
- •9. Описание предметной области аис моделью «Как есть»
- •10. Информационное обеспечение аис и информационные модели «Как должно быть»
- •11. Управление требованиями на стадиях детального проектирования, разработки, внедрения и сопровождения ис
- •12. Анализ предметной области аис
- •13. Выбор проектных решений аис и его обоснование
- •14. Проектирование системной архитектуры и анализ требований к по
- •15. Проектирование программной архитектуры и техническое проектирование программных средств
- •16. Кодирование
- •17. Тестирование
- •18. Установка и сопровождение
- •19. Каскадная модель жизненного цикла аис
- •4.Тестирование
- •20. Спиральная модель жизненного цикла аис
- •21. Понятие и виды моделей информационной системы
- •22. Методы проектирования аис
- •23. Графическая нотация и метод проектирования idef0
- •24. Графическая нотация и метод проектирования idef3
- •23. Методика построения dfd-диаграмм
- •24. Графическая нотация epc
- •25. Нотация aris Organizational Chart
- •26. Нотация aris Information Flow
- •27. Сравнительный анализ aris idef0 и idef3
- •28. Метод проектирования 1с:Профкейс
- •29. Понятие технологии проектирования
- •30. Технология проектирования информационного обеспечения аис
- •31. Технологии проектирования программного обеспечения аис (структурный и объектно-ориентированный подходы).
- •32. Саsе-средства, их функциональные возможности и характеристика
- •33. Оценка и управление качеством аис
- •34. Организация труда при разработке аис
- •35. Оценка необходимых ресурсов для реализации проекта
- •36. Технология групповой разработки аис
- •37. Автоматизация управления групповой разработкой проектов аис на примере 1с:Предприятия
- •38. Классификация аис по признаку структурированности задач
- •39. Классификация аис по виду деятельности
- •40. Классификация информационных систем по уровням управления
14. Проектирование системной архитектуры и анализ требований к по
Проектирование - определение того, как система будет делать то, что она должна делать, спецификация подсистем технического, информационного, программного обеспечения функциональных компонентов, способов и средств их реализации и взаимодействия в единой системе. Проектная часть является решением проблематики, изложенной при анализе предметной области, на языке информационных технологий. Поэтому недопустимо, если при проектировании используется информация об объекте управления, не описанная в процессе анализа.
Проектирование системной архитектуры состоит из следующих задач, которые разработчик должен выполнить или обеспечить их выполнение.
Общая характеристика системной архитектуры проектируемого программного средства (архитектуры верхнего уровня) – это описание объектов технических и программных средств и ручных операций.
Должно быть обеспечено распределение всех требований к системе между объектами архитектуры. Затем должны быть определены объекты конфигурации технических и программных средств и ручных операций на основе объектов архитектуры.
Должна быть документально оформлена привязка системной архитектуры и требований к системе относительно установленных объектов. В этой документации приводятся конкретные сценарии действий пользователей, диаграммы размещения технических (компьютерных и сетевых) и программных средств, выделяются подсистемы и объекты приложения.
Системная архитектура и требования к объектам архитектуры должны быть оценены с учетом следующих критериев (при этом результаты оценок должны быть документально оформлены):
a) учет требований к системе;
b) соответствие требованиям к системе;
c) соответствие используемых стандартов и методов проектирования;
d) возможность программных объектов архитектуры выполнять установленные для них требования;
e) возможности эксплуатации и сопровождения.
Анализ требований к программным средствам заключается в построении дерева функций - иерархии функций управления и обработки данных, которые призван автоматизировать разрабатываемый программный продукт. При этом можно выделить и детализировать два подмножества функций: реализующих служебные функции (например, проверки пароля, ведения календаря, архивации баз данных и др.) и реализующих основные функции управления и обработки данных: ввода первичной информации, обработки, ведения справочников, ответов на запросы и др.
Выявление состава функций, их иерархии и выбор языка общения (например, языка типа «меню») позволяет разработать структуру сценария диалога, дающего возможность определить состав кадров диалога, содержание каждого кадра и их соподчиненность.
Разработчик должен установить и документально оформить следующие требования к программным средствам, включая технические требования к характеристикам качества (рекомендации по определению характеристик качества приведены в ГОСТ Р ИСО/МЭК 9126):
a) функциональные и технические требования, включая производительность, физические характеристики и окружающие условия, под которые должен быть создан программный объект архитектуры (далее - программный объект);
b) требования к внешним интерфейсам программного объекта архитектуры;
c) квалификационные требования;
d) требования безопасности, включая требования, относящиеся к методам эксплуатации и сопровождения, воздействию окружающей среды и травмобезопасности персонала;
e) требования защиты, включая требования, относящиеся к допустимой точности информации;
f) эргономические требования, включая требования, относящиеся к ручным операциям, взаимодействию "человек-машина", персоналу и областям, требующим концентрации внимания человека, связанным с чувствительностью объекта к ошибкам человека и обученности персонала;
g) требования к определению данных и базе данных;
h) требования по вводу в действие и приемке поставляемого программного продукта на объекте(ах) эксплуатации и сопровождения;
i) требования к документации пользователя;
j) требования к эксплуатации объекта пользователем;
k) требования к обслуживанию пользователя.
Разработчик должен оценить требования к программным средствам по следующим критериям (при этом результаты оценок должны быть документально оформлены):
a) учет требований к системе и проекту системы;
b) внешняя согласованность с требованиями к системе;
c) внутренняя согласованность требований к объектам между собой;
d) тестируемость требований;
е) выполнимость программного проекта;
f) возможность эксплуатации и сопровождения.