Файл: 1 в реальных условиях проектирование это поиск способа, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных ограничений. Системный подход.docx

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

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

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

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

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

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

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

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

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

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

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

3) 1. Метод "снизу-вверх" - не создание тиражируемых продуктов, а обслуживание сотрудников конкретного учреждения. Успешно автоматизируются отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривается недостаточно хорошо, особенно в перспективе. («Лоскутная автоматизация»)

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

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

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

Жизненный цикл ИС- ряд событий, происходящих с системой в процессе ее создания и использования.

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

5) стадии ЖЦ – отражают состояния ИС и их изменения;

этапы ЖЦ – входят в состав стадий; предполагают выполнение определенного объема работ в течение ограниченного времени;

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

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

Разработка требований->Проектирование->Реализация->Тестирование->Вход в действие

Достоинства каскадной модели

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

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

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

7) Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки. Разработка требований-проектирование-Реализация-Тестирование-Вход в действие



8) Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы.

Цель проекта – достижение бизнес-целей заказчика

Технология

Исполнитель проекта – смешанная команда с распределением ролевых задач (напр., ролевые кластеры MSF: Управление продуктом Управление программой Разработка Тестирование Удовлетворение потребителя Управление выпуском)

Специализированные средства проектирования – CASE- средства (IDEFDesigner, ERwin\BPwin, OraclDesigner, BPMWorkbench, Aris, RationalRose …)

9) ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

ISO/IEC 12207:1995 Information technology - Software life cycle processes (Информационные технологии. Процессы жизненного цикла программного обеспечения) (ISO - International Organization of Standardization - Международнаяорганизацияпостандартизации, IEC - International Electrotechnical Commission - Международнаякомиссияпоэлектротехнике)

ISO/IEC 15288 Systems engineering. System life cycle processes (Системотехника. Процессы жизненного цикла системы)

10) 1. ФТ - Формирование требований к АС.- 1.1. Обследование объекта и обоснование необходимости
создания АС; 1.2. Формирование требований пользователя к АС; 1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания);

2. РК - Разработка концепции АС. - 2.1. Изучение объекта; 2.2. Проведение необходимых научно-исследовательских работ; 2.3. Разработка вариантов концепции АС, удовлетворяющей требованиям пользователя 2.4. Оформление отчета о выполненной работе;

3. ТЗ - Техническое задание на АС. - 3.1. Разработка и утверждение технического задания на создание.

4. ЭП - Эскизный проект. - 4.1. Разработка предварительных проектных решений по системе и ее частям; 4.2. Разработка документации на АС и ее части.

5. ТП - Технический проект. - 5.1. Разработка проектных решений по системе и ее частям; 5.2. Разработка документации на АС и ее части; 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку; 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

6. РД - Рабочая документация - 6.1. Разработка рабочей документации на систему и ее части; 6.2. Разработка или адаптация программ.

7. ВД - Ввод в действие. - 7.1. Подготовка объекта автоматизации к вводу АС в действие; 7.2. Подготовка персонала; 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями); 7.4. Строительно-монтажные работы; 7.5. Пуско-наладочные работы; 7.6. Проведение предварительных испытаний;7.7. Проведение опытной эксплуатации; 7.8. Проведение приемочных испытаний.

8. Сп - Сопровождение АС. - 8.1. Выполнение работ в соответствии с гарантийными обязательствами; 8.2. Послегарантийное обслуживание.

11) ISO/IEC 12207 - 1)Формирование требований к ПО 2)Проектирование 3)Реализация 4)Тестирование 5)Ввод в действие 6)Эксплуатация и сопровождение 7)Снятие с эксплуатации

12) ISO/IEC 15288 – 1)Формирование концепции 2)Разработка 3)Реализация 4)Эксплуатация 5)Поддержка 6)Снятие с эксплуатации

13) Методика Oracle CDM – 1)Определение требований 2)Анализ 3)Проектирование 4)Реализация 5)Внедрение 6)Эксплуатация

16) RD - Определение производственных требований,

ES - Исследование существующих систем,

TA - Определение технической архитектуры,

DB - Проектирование и построение БД,

MD - Проектирование и реализация модулей,

CV - Конвертирование данных,

DO - Документирование,

TE - Тестирование,

TR - Обучение,

TS - Переход к новой системе,

PS - Поддержка и сопровождение.

Последовательности задач

RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 – MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где

RD.020   – изучение существующих бизнес-процессов

RD.030   – моделирование будущих бизнес-процессов

RD.070   – выявление детальных требований к будущим бизнес-процессам

BR.020   – отображение бизнес-процессов в функциональность приложения

BR.080   – тестирование принятых решений

RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 – MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где MD.020 – оценка решений по доработке функциональности приложения

MD.060 – дизайн расширений функциональности приложения

DO.070 – разработка инструкций пользователя

TE.110    – тестирование приложения

PM.050 – установка приложения на систему периода эксплуатации

CV.140   – ввод начальных данных

PM.080  – запуск новой системы

17) Стандарт, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах ИС с реализацией на инструментальных средствах Oracle.

Ориентирован на поддержку деятельности разработчика.

18)определяется возможностями:

опускать стадию эскизного проектирования и объединять стадии "Технический проект" и "Рабочая документация";

опускать этапы, объединять и опускать большинство документов и их разделов;

вводить дополнительные документы, разделы документов и работы;

гибко формировать ЖЦ динамически создавая т. н. ЧТЗ; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

19) Прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС.

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

Объектами стандартизации являются автоматизированные системы различных (любых!) видов и все виды их компонентов (а не только ПО и БД):

"организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях" (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга;

20) ISO/IEC 12207:2008 Systems and software engineering — Software life cycle processes — стандарт ISO, описывающий процессы жизненного цикла программного обеспечения.

Стандарт разработан подкомитетом ПК 7 «Системная и программная инженерия» (англ. SC 7 SystemandSoftwareEngineering) Совместного технического комитета №1 ИСО/МЭК «Информационные технологии» (англ. ISO/IECJTC 1 InformationTechnology).

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

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

22) -ограничивается тремя разновидностями каскадной модели ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track) (еще более сильно ориентированная на использование инструментов моделирования и программирования Oracle), "облегченный подход" (рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения).

Методика не предусматривает:

включене дополнительной задачи, которой нет в CDM, и ее привязку к остальным;

удаление задачи (и порождаемых ею документов);

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

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

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

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

24) Обобщенная модель бизнес-процесса отображается на уровне информационных процессов с помощью нескольких видов моделей: ER-диграмм («сущность-связь») для баз данных; функциональных иерархий, диаграмм потоков данных и диаграмм потоков событий для процедур. Так, определения классов рабочих объектов, ресурсов, организационных единиц составляют основу ЕR-диаграмм. Иерархии функций бизнес-процесса определяет иерархию программных процедур. Диаграммы потоков данных устанавливают интерфейсы программных процедур с базами данных, входными и выходными формами информации, а диаграммы потоков событий определяют управление переходами между процедурами.

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

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

Технология Aris – управляемые событиями модели

Программные средства: IDEF Designer, ERwin\BPwin, Oracl Designer, BPM Workbench, Aris, Rational Rose

26) IDEF0 - методология функционального моделирования. Система отображается в виде набора взаимосвязанных функциональных блоков.

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

IDEF1X (IDEF1 еХtended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и используется для моделирования реляционных баз данных в системе;

IDEF3 – методология документирования процессов. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса.

IDEF4 – методология построения объектно-ориентированных систем.

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

Критерии разбиения системы на «черные ящики»:

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

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

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

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

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

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

Для моделирования бизнес-функции обычно достаточно 2-3 уровней детализации.

Общее число уровней в модели обычно не превышает 6-7.

29) Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания». Всего предусматривается 8 стадий:

Формирование требований к ИС

Разработка концепции

Техническое задание

Эскизный проект

Технический проект

Рабочая документация

Ввод в действие

Сопровождение

30) Силами заказчика – 1)Документальная инвентаризация 2)Самофотография рабочего дня 3)Ведение индивидуальных тетрадей-дневников

Силами разработчика – 1)Наблюдение 2)Интервью 3)Метод аналогий 4)Фотография рабочего дня

31) Визуальное моделирование – это способ восприятия проблем с помощью зримых абстракций, воспроизводящих понятия и объекты реального мира

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

32) *каждый “черный ящик” должен реализовывать единственную функцию системы.

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

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

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

33) В структурном анализе и проектировании используются различные модели, описывающие:

*функциональную структуру системы

*последовательность выполняемых действий

*передачу информации между функциональными процессами

*отношения между данными

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

Цель– продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами

35) Цель - обеспечении разработчика ИС концептуальной схемой БД в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных

С её помощью определяются важные для предметной области объекты, их свойства и отношения друг с другом

36) Унифицированный язык моделирования (UML – Unified Modeling Language) стал промышленным стандартом для разработки и проектирования программного обеспечения

UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределённых Web-приложений и встроенных систем реального времени

37)Отдельные языки объектно-ориентированного моделирования начали появляться в середине 1970-х годов

*В период между 1989-1994 годах общее число наиболее известных языков моделирования возросло с 10 до более чем 50

*К середине 1990-х некоторые методы были существенно улучшены и приобрели самостоятельное значение при решении различных задач объектно-ориентированного анализа и проектирования

38) октябрь 1994 г. – Гради Буч и Джеймс Румбах начали работу по унификации методов Буча и OMT

*октябрь 1995 г. – подготовлен и опубликован проект унифицированного метода (Unified Method) версии 0.8

*осенью 1995 г. – к проекту присоединился А. Джекобсон с целью интеграции своего метода OOSE с двумя предыдущими

*январе 1997 г. – опубликован документ с описанием языка UML 1.0

*2003 г. – вышел проект языка UML 2.0

39) UML включает набор графических элементов и правила для объединения этих элементов

*Диаграммы используются для отображения различных представлений системы

*Модель UML описывает, что должна делать система, но ничего не сообщает о том, как она будет реализована