Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Vvedenie_v_PI.docx
Скачиваний:
5
Добавлен:
25.04.2019
Размер:
186.11 Кб
Скачать

Введение в пи 4-5 лекция (29.09.11, 6.10.11)

Моделирование системы:

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

Внешний центр управления

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

Функциональные компоненты системы.

Их можно классифицировать по ряду категорий:

  1. Сенсорный компонент. Собирает информацию о системном окружении.

  2. Исполнительный компонент. Производит некоторые действия в окружении систем

  3. Вычислительный компонент. На их ход поступают определенные данные, над которыми они производят определенные вычисления. Затем на выходе получаем новые данные.

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

  5. Координирующие компоненты. Согласуют работу других компонентов.

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

Не сложно отнести системные компоненты к одному из перечисленных типов. Вместе с тем, если в системе используется программное обеспечение, то как правило программные элементы встраиваются в большинство системных компонентов. Кроме того программное обеспечение обычно используется для управления всей системы. Приведенная классификация компонентов помогает при проектировании системы. Большинство систем содержат компоненты всех типов и задача разработчика состоит в точном определении типа компонента. Исходя из спецификации системы. Если несколько компонентов содержат признаки разных типов, это может привести к тому, что на этапе проектирования системы могут возникнуть определенные проблемы.

Процесс создания систем.

1) Этапы процесса создания системы:

2)Определение требований

3) Проектирование системы

4) Разработка подсистем

5) Сборка системы

6) Ввод системы в эксплуатацию

7) Совершенствование системы

8) Вывод системы из эксплуатации

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

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

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

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

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

Этапы создания системы.

1 этап. Определение системных требований. На этом этапе формируется и формализуются требования к системе, рассматриваемой как единое целое. Здесь производятся консультации с заказчиками системы и ее конечными пользователями. Обычно формируются требования трех типов:

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

2) Системные свойства – это интегрированные свойства системы. Они могут включать в себя производительность, безотказность, защищенность и так далее. Эти нефункциональные свойства оказывают большое влияние на все требования, определяемые для подсистем

3) Свойства, которые должны отсутствовать у системы. Порой, гораздо сложнее указать, что система не должна делать, тем то, что она должна выполнять

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

Процесс создания систем. Этапы создания системы: Определение состоит из нескольких этапов. 1. Разработка требований к системе – результатом этого процесса является спецификация системных требований. Этапы разработки требований Анализ осуществимости – на этом этапе решаются такие вопросы как. Отвечает ли система общим и бизнес целям организации заказчика, разработчика.

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

Аттестация требований - должна продемонстрировать что требование действительно определяющее систему которую хочет иметь заказчик. В процессе аттестации выполняются различные типы проверки документации требований. 1 тип проверок – проверка правильности требований. Проверка адекватности, проверка на не противоречивость. Требования не должно быть противоречащих ограниченияй или различных описаний одной и той же системной функции. Проверка на полноту. Проверка на выполняемость 2. Проектирование системы / определение подсистем Определяются подсистемы, которые индивидуально или совместно реализуют системные требования, группа требований обычно проецируется на несколько подсистем поэтому можно объединить несколько требований в одно 3. Распределение требований по подсистемам 4. Специфицирование функциональных характеристик подсистем. – определяются функциональные характеристики каждой подсистемы на этом этапе так же формализуются взаимоотношения между системой. 5. Определение интерфейсов подсистем

Разработка подсистем

На этом этапе реализуются те подсистемы, которые были определены на предыдущем этапе. Тут есть три варианта:

1. Разработка системы с нуля

2. Приобретение на рынке промышленных изделий, готовой подсистемы и её интеграция в создаваемую систему.

3. Приобретается некоторая «заготовка» - платформа, которая затем дорабатывается.

Все подсистемы как правило разрабатываются параллельно, если возникают проблемы прерывающие процесс разработки подсистем может потребоваться модификация всей системы

Сборка системы

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

  1. Метод большого взрыва

  2. Последовательная сборка. Предпочительнее потому что:

  1. Как правило этапы разработки различных подсистем заканчиваются неодновременно

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

Ввод системы в эксплуатацию

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

  1. Окружение в котором инсталлируется система не совпадает с тем для которого она спроектирована. Это общая проблема которая часто возникает при инсталляции ПО,

  2. Вредные пользователи препятствующие внедрению этой системы в своей организации

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

  4. Возможны чисто физические проблемы. Сложность при подготовке системы где она инсталлируется.

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

Совершенствование системы

Совершенствование системы.

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

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

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

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

Вывод системы из эксплуатации. - Извлечение системы из её окружения, после окончания срока службы. Приобретение систем - сложные вычислительные системы, можно купить как единое целое, а можно как некоторые части потом интегрируются, а можно спроектировать систему, и разработать по отдельному заказу с нуля. Для больших систем процесс выбора одного из этих вариантов может растянуться на несколько месяцев, или даже лет. Процесс приобретения системы это определение наиболее эффективного для организации пути её произведения и выбор поставщика системы. Этот процесс полностью подчиняется системотехнике. До его начала (приобретения) необходимо разработать системную спецификацию, и архитектуру системы, что обусловлено следующими причинами:

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

  • Практически всегда легче купить систему чем разработать её. Архитектура системы необходима для того чтобы определить какие её подсистемы можно купить а какие необходимо разрабатывать

Адаптирование требований >выбор системы >формирование заявки на покупку> выбор продавца

Исследование рынка /\ Формирование требований к заказчику> Выбор заказчика>Заключение контракта>Разрешение на выполнение контракта

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

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

Процесс создания программного обеспечения.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]