Проектирование ис. Пономарева н.П.

1. Понятие ЖЦПО. Процессы ЖЦ. Стандарты, регламентирующие процесс создания АС.

ЖЦПО – период времени от потребности создания ПО до его изъятия.

Основным нормативом регламентирующим состав процессов ЖЦПО является международный стандарт ISO-12207 1995года.

ГОСТ 34 - Стадии создания ПО автоматизированных и информационных систем

ГОСТ 34.601 «информационные технологии. Комплекс стандартов на автоматизированные системы. стадии создания»

ГОСТ 34.602 «информационные технологии. Комплекс стандартно автоматизированных систем. Техническое задание на создание автоматизированной системы»

ГОСТ 34.603 «Виды испытаний автоматизированных систем»

В соответствии с ISO-12207 все процессы разделены на 3 группы:

1. Основные процессы

-Приобретение

-Поставка

-Разработка

-Эксплуатация

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

2. Вспомогательные процессы

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

-Управление конфигурацией

-Обеспечение качества

-Верификация

-Аттестация

-Оценка

-Аудит

-Разрешение проблемы

3. Организационные процессы

-Управление

-Усовершенствование

-Создание инфраструктуры

-Обучение

2. Модели и стадии ЖЦПО.

Под моделью ЖЦПОпонимается структура определяющая последовательность выполнения и взаимосвязи процессов на протяжении жизненного цикла.

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

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

В состав ЖЦПО включают стадии:

1. Формирование требований к ПО

2. Проектирование ПО

3. Реализация

4. Тестирование

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

6. Эксплуатация и сопровождение

7. Снятие с эксплуатации

1. Формирование требований к ПО

   1. Планирование работы. Основные задачи этого этапа:

-Определение цели разработки

-Предварительная экономическая оценка

-Создание плана графика выполнения работы

-Создание и обучение учебной группы

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

3. Построение модели деятельности объекта предусматривает обработку материалов обследования предыдущего этапа и построение 2 видов моделей:

-Модель AS-IS («как есть») которая отражает существующее на данный момент состояние объекта. Позволяет выявить узкие места и сформулировать предложение по улучшению ситуации.

-Модель TO-BE («как будет») которая отражает представление о новых технологиях функционирования объекта.

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

Переход от модели AS-IS к модели TO-BE может быть выполнен 2-мя способами:

1. Совершенствование текущей технологии на основе оценки ее эффективности

2. Радикальное изменение технологии и реинжениринг бизнес-процессов.

Построение модели имеет самостоятельное практическое значение.

2. Стадия проектирования включает следующие этапы:

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

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

Содержание последующих стадий в основном совпадает с соответствующими процессами ЖЦПО.

На каждой стадии могут выполняться несколько процессов определенных стандартом ISO-12207 и наоборот.

Модели ЖЦПО

К настоящему времени наибольшее распространение имеют 2 модели ЖЦПО:

• Каскадная модель

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

Преимущества каскадного подхода:

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

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

Недостатки каскадного подхода:

1. Реальный процесс создания ПО сложно уложить в такую сложную схему.

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

В прямоугольниках 7 стадий ЖЦПО

• Спиральная модель

Как альтернатива каскадному подходу в конце 80-х годов была предложена спиральная модель ЖЦПО. Ее принципиальная особенность – ПО создается не сразу, а по частям с использованием метода прототипирования.

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

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

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

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

определение целей, идентификация и

альтернатив, разрешение рисков, оценка

ограничений альтернатив

начало

планирование следующей

стадии продукт разработка продукта

3. Метод RAD.

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое рас­пространение способ так называемой быстрой разработки приложе­ний, или RAD (Rapid Application Development). Подход RAD предусмат­ривает наличие трех составляющих:

• небольших групп разработчиков (от 3 до 7 человек), выполняю­щих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллек­тива;

• короткого, но тщательно проработанного производственного гра­фика (до 3 месяцев);

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

Жизненный цикл ПО в соответствии с подходом RAD включает четыре стадии:

1) анализ и планирование требований;

2) проектирование;

3) реализация;

4) внедрение.

На стадии анализа и планирования требований пользователи осу­ществляют следующие действия:

• определяют функции, которые должна выполнять система;

• выделяют наиболее приоритетные функции, требующие прора­ботки в первую очередь;

• описывают информационные потребности. Формулирование требований к системе осуществляется в основном силами пользо­вателей под руководством специалистов-разработчиков. Кроме того, на данной стадии решаются следующие задачи: • ограничивается масштаб проекта;

• устанавливаются временные рамки для каждой из последующих стадий;

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

• список расставленных по приоритету функций будущего ПО ЭИС;

• предварительные модели ПО.

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

• более детально рассматриваются процессы системы;

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

• устанавливаются требования разграничения доступа к данным;

• определяется состав необходимой документации.

Результатом данной стадии должны быть:

• общая информационная модель системы;

• функциональные модели системы в целом и подсистем, реализу­емых отдельными командами разработчиков;

• точно определенные интерфейсы между автономно разрабаты­ваемыми подсистемами;

• построенные прототипы экранных форм, отчетов, диалогов.

На стадии реализации выполняется непосредственно сама быст­рая разработка приложения:

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

• пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлет­ворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки.

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

• осуществляется анализ использования данных и определяется не­обходимость их распределения;

• производится физическое проектирование базы данных;

• формулируются требования к аппаратным ресурсам;

• устанавливаются способы увеличения производительности;

• завершается разработка документации проекта. Результатом стадии является готовая система, удовлетворяющая

всем согласованным требованиям.

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

Следует, однако, отметить, что подход RAD, как и любой другой, не может претендовать на универсальность. Он хорош в первую оче­редь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является закон­ченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекомму­никации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, то на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и ско­ростью разработки. Для таких проектов необходимы высокий уро­вень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

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

4. Метод RUP.

Технология RUP (Rational Unified Process) разработана компанией Rational Software. Она ориентирована на использование универсаль­ного языка объектно-ориентированного моделирования UML, явля­ющегося фактическим стандартом в данной области.

На рис. 5.3 показан общий вид процесса RUP в двух изме­рениях:

• горизонтальное измерение представляет время, отражает дина­мические аспекты процессов и оперирует такими понятиями, как циклы, фазы, итерации и контрольные точки;

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

Согласно RUPЖЦПО разбивается на циклы, в каждом из которых создается новое поколение продукта. Цикл разбивается на 4 стадии:

1. Начальная - бизнес-план проекта, устанавливаются границы проекта, выполняется некоторый начальный анализ для оценки размера проекта. Для этого идентифицируются ВСЕ use case и ВСЕ внешние сущности, и описываются важнейшие из них.

Результаты: общее описание системы (основные требования к проекту, его характеристики и ограничения)

-начальная use case до 20%,

-начальный проектный глоссарий,

-бизнес-план,

-план проекта, отражающий стадии и итерации,

-один или несколько прототипов.

2. Уточнение

Результаты: -use-case около 80%,

-перечень дополнительных требований, включая требования нефункционального характера,

-описание базовой архитектуры системы,

-работающий прототип,

-уточненный бизнес-план,

-план разработки всего проекта, отражающий итерации и критерии оценки каждой итерации.

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

3. Конструирование

Построение системы путем серии итераций. В конце каждой выполняется полная итерация. При этом выполняется полный набор тестов.

Результат: продукт, готовый к передаче пользователю.

-ПО, интегрируемое на требуемых платформах,

-руководство пользователя,

-описание текущей реализации.

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

-бета-тестирование, позволяющее убедиться, что система соответствует ожиданиям пользователя,

-конвертирование БД,

-оптимизация производительности,

-обучение пользователей.

Статический аспект.

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

«Исполнитель» определяет поведение и ответственность личности или группы личностей, составляющих проектную команду.

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

«Рабочий процесс» - последовательность действия, приводящую к получению значимого результата.

В рамках RUP 6 процессов основных и 3 процесса поддерживающих.

5. Технологический процесс тестирования.

Цель– оценка качества продукта (не только окончательного, но и архитектуры с ранних этапов вплоть до передачи продукта заказчику).

Процесс включает:

а) проверка взаимодействия компонентов,

б) проверка правильности интеграции компонентов,

в) проверка точности реализации всех требований,

г) выявление дефектов и принятие мер для их устранения.

Характеристики классификации тестов:

1. Тестируемый параметр качества.

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

2. Этап тестирования – момент ЖЦ, в котором выполняется тестирование.

а) блочное (минимальный элемент системы тестируется),

б) интегральное,

в) системное (тестируется завершенное приложение),

г) приемосдаточное.

3. Типы тестов (один тест на один параметр качества).

-аттестационный (сравнивает производительность целевого объекта тестирования и некоторого стандартного объекта, или оценивает производительность согласно некоторой системе мер),

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

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

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

-тестирование целостности,

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

-эксплуатационные испытания (проверяется приемлемость производительности целевого объекта тестирования в различных конфигурациях при постоянных операционных нагрузках),

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

Модель тестирования.

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

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

(средства, поддерживающие автоматизацию тестов и процесс тестирования)

Test Studio – позволяет испытателю создавать сценарий тестирования, имеющий графический интерфейс пользователя.

Инструменты:

-robot – поддерживает выполнение теста,

-logViewer – фиксирует результаты тестирования и представляет отчет для оценки выполнения теста,

-testManager – поддерживает планирование, проектирование и оценку тестов,

-testFactory – тестирование надежности путем автоматического создания и выполнения сценариев тестирования.

Development Studio:

-Rational Purify – инструмент для локализации трудно-обнаруживаемых ошибок,

-Rational Pure Coverage – для определения участков кода, не прошедших тестирование, и выполнения анализа покрытия кода,

-Rational Quantify – для выявления фрагментов кода, ограничивающих производительность.

6. Методологии функционального моделирования.

Методология функционального моделирования. SADT (Structured Analysis and Design Technique)

Методология структурного анализа и проектирования. Она включает в себя: IDEF1.x\Idef0 \idef3 и др.

Методолгия функционального моделирования SADT(IDEF0). Предложена в 1973 Дугласом Россом.

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

Результатом применения метода является функциональная модель состоящая из иерархии диаграмм глассария.

Элементов диаграмной техники два:

1. Блок

2. Дуга

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

Далее контекстную диаграмму необходимо декомпозировать, при этом соблюдаются три правила декомпозиции:

- 3 – 7 , количество блоков на каждом уровне декомпозиции от 3 до 7

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

- Правило балансировки, количество внешних входов на детализирующей диаграмме равно количеству входов на детализируемом блоке.

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

Количество внешних входов на детализируюещй диаграмме, равно количеству внешних входов

Типы связей между функциями:

Случайная связь (связь мала или совсем отсутсвует), Логическая, Временная, Процедурная,

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

Использование трех последних типов связи предпочтительно для построение диаграмм хорошего качества.

Методология потоков данных DFD.

Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе.

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

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

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

Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.

Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, «склад товаров». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.

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

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

процесс имеет два-три входных и выходных потока;

процесс может быть описан в виде преобразования входных данных в выходные;

процесс может быть описан в виде последовательного алгоритма.

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

Миниспецификации обработки — описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификации является полной спецификацией системы.

К преимуществам методики DFD относятся:

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

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

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

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

7. Методология информационного моделирования. (ER)

ERD(entity-relationshipdiagram) – методология информационного моделирования – метод сущность – связь. Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD), нотация которых была впервые введена Питером Ченом в 1976 г.

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

Диаграммы «сущность-связь» включают:

• сущности; • атрибуты; • связи.

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

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

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

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

Разработка ERD включает следующие основные этапы:

• Идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей.

• Идентификация отношений между сущностями и указание типов отношений.

• Разрешение неспецифических отношений (отношений многие-ко-многим).

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

Альтернативный ключ (Alternate Key) - потенциальный ключ, не ставший первичным. На диаграмме альтернативный ключ обозначается AK n . m , где n — порядковый номер ключа, m — порядковый номер атрибута в ключе.

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

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

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

8. Состав процесса разработки ПО (ISO 12207).

Процесс разработки включает следующие действия:

1. Подготовительная работа (выбор модели ЖЦПО соотвествующей масштабу значимости и сложностей процессов составления плана выполнения работ, )

2. Анализ требований к системе (подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности, безопасности, внешним интерфейсам и т.д.)

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

4. Анализ требований ПО (предполагает определения следующих характеристик для каждого компонента ПО:

-Функциональные возможности

-Внешние интерфейсы

-Спецификации надежности и безопасности

-Эргономические требования

-Требования к используемым данным

-Требования к установке и приемке

-Требования к пользовательской документации

-Требования к эксплуатации и сопровождению)

5. Проектирование архитектуры ПО (включает для каждого компонента ПО:

-Трансформация требований к ПО в архитектуру определяющую на высоком уровне структуру ПО и состав его компонентов

-Разработка и документирование интерфейсов ПО и БД

-Разраобтка предварительной версии пользовательской документации

-Разработка и документирование предварительных требований к тестам и плана интеграции ПО)

6. Детальное проектирование ПО (включает:

-Описание компонентов ПО и интерфейсов между ними на более низком уровне достаточным для его последующего кодирования

-Разработка детального проекта БД, доработка пользовательской документации

-Доработка плана тестирования компонентов и плана интеграции ПО)

7. Кодирование и тестирование ПО

8. Интеграция ПО (сборка разработанных компонентов в соответствии с планом интеграции и тестирование агрегированных компонентов)

9. Квалификационное тестирование ПО (проводится разработчиком в присутствии заказчика для демонстрации того, что ПО удовлетворяет спецификациям и готова к эксплуатации)

10. Интеграция системы (сборка всех компонентов, включая ПО и оборудование)

11. Квалификационное тестирование системы

12. Установка ПО (в среде, на оборудовании)

13. Приемка ПО (оценка результатов квалификационного тестирования)