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

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

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

ПО обеспечивает решение следующих задач:

• планирование и оценка проекта

• анализ системных и программных требований

• проектирование алгоритмов и структур данных

• методы кодирования

• методы тестирования

• методы сопровождения

Пример.

Методы анализа, методы структурного проектирования, методы ОО-проектирования.

Утилиты могут объединяться в системы автоматизированного проектирования (САПВ, или Computer Aided Software Engineering, CASE).

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

Жизненный цикл по.

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

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

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

Основные модели жизненного цикла ПО:

Классическая модель (модель водопада) - 70-е – середина 80-х годов. Наибольшее применение в структурном проектировании. Часто называют каскадной моделью. Разбиение на этапы, причем переход на следующий возможен только после того, как полностью завершена работа на предыдущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Как правило, у разработчиков ПО имеются свои роли.

Спиральная модель – середина 80-х – 90-е годы. Применяется в ООП.

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

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

Кодирование

Проектирование

Анализ

К лассическая модель

Характеристика этапов:

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

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

Кодирование – перевод результатов проектирования в код.

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

1) Требования

Уточненная схема для этапов анализа и проектирования каскадной м одели

9) Проектирование логики модуля

8) Внешнее проектирование модулей

6) Структура продукта

7) Проектирование бд

5) Архитектура системы

3) Предварительное внешнее проектирование

4) Детальное внешнее проектирование

2) Цели

1, 2) определение требований системы

2) какие цели ставятся перед системой, достижение функциональности, уровни надежности и т. д.

3, 4) фактически создание макета на бумаге. Это не руководство пользователя, это подробное описание того, как должна функционировать система

5) идет проектирование на уровне подсистем, больших блоков. Может отсутствовать в не слишком больших проектах

6) каждая подсистема рассматривается отдельно на уровне групп модулей, которые эту подсистему составляют. Дерево вызовов модулей в структурном проектировании или диаграмма классов в ООП.

8, 9) проектирование собственно модулей, именно алгоритмы внутри функций, т. е. их содержимое.

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

Определение требований к системе

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

Имеются 3 класса:

1. Управляемая пользователем – требования к системе непосредственно разрабатываются организацией пользователя.

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

3. Не зависящая от пользователя – вся ответственность ложится на разработчика. Разрабатывается небольшой группой: представитель заказчика который может принимать решения (обычно он не является пользователем системы), человек, который будет пользователем системы и обладает достаточным опытом в своей области. От организации разработчика: специалисты, которые отвечают за внешнее и внутренне проектирование. Хотя бы один человек, который обладает опытом взаимодействия с заказчиками.

Цели.

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

Цели продукта:

1. Резюме: назначение разрабатываемого продукта

2. Определение пользователя

3. Публикация – необходимо разработать документацию для определенных групп пользователей

4. Эффективность системы – пропускная способность, временные характеристики, использование ресурсов

5. Совместимость с другими продуктами

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

7. Безопасность

8. Обслуживание – намечается стоимость и время исправления ошибок

9. Установка – описываются методы и средства настройки системы на конкретные условия эксплуатации

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

Внешнее проектирование – процесс описания поведения системы с точки зрения внешнего по отношению к этой системе наблюдателя. Т. е. внимания внутренней архитектуре, данным, алгоритмам не уделяется, интересует внешний вид программы и ее реакции.

Цель этого процесса – конструирование внешнего взаимодействия будущего продукта без конкретизации внутреннего устройства. Результат – внешние спецификации.

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

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

Как правило, ответственность за внешнее проектирование несут 1-2 человека: системный аналитик и специалист по интерфейсам.

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

Как правило, делается:

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

2. Детальное внешнее проектирование более подробно определяют и описывают:

а) описание входных выходных данных

б) преобразование системы

в) характеристики надежности

г) эффективность

д) замечания по программированию

Многие функции могут не только порождать какие-то конкретные данные, но и изменять состояние системы. Такие преобразования должны быть описаны с точки зрения пользователя. Это могут быть логи или что-то другое.

Надежность – описание возможных воздействий отказов системы на саму систему и файл.