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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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