СиППО (1-4, 8, 10) (Ответы на все вопросы)

1.     Подходы к разработке программных средств. Их краткая характеристика.

2.     Жизненный цикл программного обеспечения. Основные понятия.

3.     Модели жизненных циклов программного обеспечения, их характеристики и области применения.

4.     Особенности модели жизненного цикла «спираль»

8.     СОСОМО модель. Важнейшие количественные характеристики процесса разработки программного обеспечения.

10. Краткая характеристика объектно-ориентированного подхода к разработке программного обеспечения. Понятия «Класс» и «объект».

1.     Подходы к разработке программных средств. Их краткая характеристика.

Классические подходы:

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

Иерархическая диаграмма (HIPO - Hierarchical Input Process Output):

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

 - счастливый случай (на каком-то этапе выделена задача, которая уже решена, т.е., например, классическая задача);

 - когда подзадача самого нижнего уровня соответствует программно разумным размерам (ПРР).

ПРР означает, что программист может держать в голове хотя бы структуру задачи (по размеру обычно не более 3 экранов).

Диаграммы IPO являются основными в технологии. В диаграммах выделены 3 колонки. В левой записывается входная информация (та, что подается на вход алгоритма), в средней описан процесс (алгоритм), в правой - выходная информация. 

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

2) Метод анализа потоков данных (для автоматизации офисной деятельности).

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

3) Проектирование программ на основе абстрактных структур и типов данных.

4) Объектно-ориентированных подход.

Объект - это реально существующий предмет со всеми его индивидуальным особенностями.

Класс - множество объектов с одинаковыми свойствами и одинаковым поведением.

Если данным присвоить значение, то класс превращается в объект.

Основные свойства класса:

 - инкапсуляция - объединение в структуре данных, классе, данных и методов обработки этих данных.

Классы B И C являются частным случаем класса А. Все, что мы утверждали для класса А, должно остаться в силе безо всяких ограничений для классов В и С. Если класс имеет одного предка, то говорим о единственном наследовании, если более, то о множественном наследовании. Множественное наследование в программе нежелательно.

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

2.     Жизненный цикл программного обеспечения. Основные понятия.

Основные процессы жизненного цикла:

1.     заказ,

2.     поставка,

3.     разработка,

4.     эксплуатация,

5.     сопровождение.

Вспомогательные процессы жизненного цикла:

1.     документирование,

2.     управление конфигурацией,

3.     обеспечение качества,

4.     верификация,

5.     аттестация,

6.     совместный анализ,

7.     аудит, решение проблем.

Организационные процессы жизненного цикла:

1.     управление,

2.     создание инфраструктуры,

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

4.     обучение.

Процесс разработки состоит из следующих работ:

1.     подготовка процесса,

2.     анализ требований к системе,

3.     проектирование системной архитектуры,

4.     анализ требований к программным средствам,

5.     проектирование программной архитектуры,

6.     техническое проектирование программных средств,

7.     программирование и тестирование программных средств,

8.     сборка программных средств,

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

10.   сборка системы,

11.   квалификационные испытания системы,

12.   ввод в действие программных средств,

13.   обеспечение приемки программных средств.

Процесс эксплуатации состоит из следующих работ:

1.     подготовка процесса,

2.     эксплуатационные испытания,

3.     эксплуатация системы,

4.     поддержка пользователя.

Процесс сопровождения состоит из следующих работ:

1.     подготовка процесса,

2.     анализ проблем и изменений,

3.     внесение изменений,

4.     проверка и приемка при внесении изменений,

5.     перенос, снятие с эксплуатации.

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

1.     подготовка процесса,

2.     анализ требований к системе,

3.     проектирование системной архитектуры,

4.     анализ требований к программным средствам,

5.     проектирование программной архитектуры,

6.     техническое проектирование программных средств,

7.     программирование и тестирование программных средств,

8.     сборка программных средств,

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

10.   сборка системы,

11.   квалификационные испытания системы,

12.   ввод в действие программных средств,

13.   обеспечение приемки программных средств.

Подготовка процесса разработки включает:

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

∙        выбор  и адаптацию стандартов, методов и инструментарий разработки,

∙        разработку плана выполнения работы.

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

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

Требования к системе должны быть оценены с учетом следующих критериев:

∙        учет потребностей заказчика,

∙        соответствие потребностям заказчика.

∙        тестируемость,

∙        выполнимость проектирования системной архитектуры,

∙        возможность эксплуатации и сопровождения.

Проектирование системной архитектуры состоит из следующих основных задач.

Определение общей архитектуры системы (архитектуры высшего уровня). Должно быть определено распределение всех требований к системе между объектами архитектуры; определены объекты конфигурации технических и программных средств. Системная  архитектура должны быть оценена по следующим критериям:

∙        учет требований к системе,

∙        соответствие требований к системе,

∙        соответствие используемых стандартов и методов проектирования,

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

∙        возможность эксплуатации и сопровождения.

Анализ требований к программным средствам включает следующие задачи.

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

∙        Требования к внешним интерфейсам.

∙        Квалификационные требования.

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

∙        Эргономические требования, включая требования, относящиеся к ручным операциям, взаимодействию «человек – машина», персоналу и областям, требующим концентрации внимания человека, связанным с чувствительностью объекта к ошибкам человека и обученности персонала.

∙        Требования к определению данных в базе данных.

∙        Требования по вводу в действие и приемке поставляемого программного продукта.

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

∙        Требования к эксплуатации объекта пользователем.

∙        Требования к обслуживанию пользователя.

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

∙        Учет требований к системе и проекту системы.

∙        Внешняя согласованность с требованиями к системе.

∙        Внутренняя согласованность требований к объектам между собой.

∙        Тестируемость требований.

∙        Выполнимость программного проекта.

∙        Возможность эксплуатации и сопровождения.

Проектирование программной архитектуры.

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

Разработанную архитектуру следует оценить по следующим критериям:

∙        Учет требований к программному объекту.

∙        Внешняя согласованность с требованиями к программному объекту.