Классификация пакетов программ. Требования к пакетам программ. Типы вариантов разработки. Каскадная модель разработки пакетов программ. Структура и состав команды программистов

1.  Классификация пакетов программ (6 типов)

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

Классификация:

1. Независимая программа – автоматизирует 1 или несколько задач

-  Язык низкого уровня;

-  Вмешательство в тексты при модификации

-  Жёсткая структура

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

-  Жёсткая специализация;

-  В структуру вмешиваться нельзя;

-  Отсутствие ввода/вывода

3. Языковый процессоры – проблема формируется на некотором искусственном языке, который переводится на язык программирования, затем компилируется в исполняемый файл и получается результат
4. Многофункциональные программы

-  Интерфейс пользователя

-  Жёсткая структура

-  Нет необходимости модифицировать текст

5. Пакеты прикладных программ – электронный таблицы, СУБД, редакторы, компиляторы

-  Управляющая программа в наличии

-  Средства взаимодействия с пользователем

-  Модули самоконтроля

6.  Интегрированные пакеты – автоматизируют некоторую область MS Office.

2.  Требования к пакетам программ. Типы вариантов разработки.

Требования к ППП:

1. Удобство пользователя (интерфейс, система справок, диагностика, подсказки, проверка корректности действий)
2. Автоматизация вычислительного процесса. Пользователь должен знать, что делает пакет, а не как он это делает
3. Накопление и представление информации об ошибках
4. Гибкость пакета
5. Эффективность. Использование эффективных отказоустойчивых алгоритмов, оптимизированных по занимаемой памяти и быстродействию
6. Надежность – предоставление достоверной информации о результатах в нормальном времени

Пакет программ разрабатывается при следующих ситуациях:

1.  Классическая схема. Пакет создается заново:

1.1.  по заказу – заказчик участвует в постановке задач и принимает работу;

1.2.  инициативная разработка;

2.  Сопряжение существующих программ:

2.1.  есть исходный код;

2.2.  нет текстов программ;

3.  Использование языка пакета программ.

3.  Каскадная модель разработки пакетов программ. Цель создания пакета, анализ ситуации, выработка требований и проектирование.

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

Проектирование каждого разбитого модуля:

1. Разбиение на модули (каждый выполняет 1 функцию)
2. Интерфейс между модулями, функциями. Должны быть оговорены все типы данных, передаваемые из одного модуля в другой (например, с помощью HIPO – диаграммы)

Выбирается язык, пишутся и тестируются все модули.

Сбор всей системы. Тест всего пакета.

Оформление документации.

Ответственность на разработчике. Все исправления бесплатны. Пакет в реальных условиях.

Если замечания существенны, возвращаемся к анализу.

Остаются алгоритмы

1)  Анализ ситуации. Выработка требований к пакетам

При анализе проблем необходимо сформировать профессиональную команду аналитиков. Возможны 2 ситуации:

-  Новая система. Только проблемная область.

-  Есть прототип (дополняем, модернизируем существующие системы)

  I.  Чтобы проблемная область стала понятна необходимо обследование объекта:

1)  Цель создания систем программ

2)  Обследование с точки зрения описания объекта автоматизации

- 

_ К (критерии)

Функциональное описание. Дает представление о том, какие функции выполняет сам объект автоматизации, его связь с внешним миром, критерии оценки его функционирования

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

-  Информационное описание. Дает представление обо всех информационных потоках, которые используются при управлении объектом. Информационные потоки отражают материальные потоки.

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

  II.  Анализ существующих систем

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

Недостатки разработки:

-  Стоимость разработки всегда выше типовой системы

-  Сроки внедрения больше

-  Человеческие ресурсы после разработки необходимо или задействовать далее или сокращать

Достоинства существующей системы:

-  Мгновенное внедрение

-  Дешевле

Недостатки существующей системы:

-  Затраты на доработку

2)  Проектирование программ

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

1.  Нисходящее проектирование. Заканчивается, когда утверждена структура ПП, т.е. в дальнейшем её желательно не менять. Гарантируется правильная реализация.

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

3.  Экстремальное программирование XP (eXtreme Programming). Применяется, когда до конца не ясна проблема. Задача уточняется в ходе реализации. При этом происходит постоянное взаимодействие заказчика и программиста. Одно из условий такого варианта – выдвижение жестких условий к тестированию. Иногда тестирующая программа пишется до реализации  программы.

4.  Адаптивное программирование. Постановка задачи не выполнена до конца. В процессе разработки происходит взаимодействие заказчика и программиста.

5.  Исследовательское программирование. Научная программа. Требования к результату заранее не могут быть сформулированы. Можно только сформулировать направление в создании программы. Сроки, объемы не оговариваются.

(Ответ по рисунку)

4.  Каскадная модель разработки пакетов программ. Детальное проектирование.

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

Выбор языка программирования зависит от уровня задачи.

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

(Ответ по рисунку)

5.  Каскадная модель разработки пакетов программ. Кодирование, комплексная отладка и внедрение.

Кодирование. Написание кодов программ, процедур, функций, зависит от выбранного языка (языков) программирования. Платформа, поддерживающая несколько языков – Microsoft Studio.NET

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