3.3.2. Создание системы с помощью прототипа.

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

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

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

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

На шаге 2 используют специализированное программное обеспечение, он быстро создает рабочую модель.

На 3 шаге польз-ль оценивает работу с-мы и дает рекомендации по её улучшению.

4 шаг. Исправление и совершенствование прототипа.

После этого процесс возвращается к 3-му шагу. И последние 2 шага повторяются до тех пор, пока пользователь не будет полностью удовлетворён.

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

«+» и “-“:

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

3.3.3. Разработка с помощью пакетов прикладных программ (ппп)

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

Основу ППП составляет библиотека программ.

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

ППП готовы к работе, их можно приобрести или взять в аренду. Если пакет отвечает большей части потребностей, то создавать собственные программы не требуется. Это может сэкономить время и фин-е ср-ва. Можно использовать построенные и протестированные программы пакета.

При выборе ППП след-т учитывать след-е критерии:

1) функциональность пакета

2) гибкость

3) дружественность интерфейса

4)потребляемые ресурсы

5) требования к БД

7) полнота документации

8) репутация производителя

9) цене.

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

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

«-« подхода:

- Если предполагаются слишком серьезные изменения. То доп-е работы по перепрограммированию и настройка ППП могут обойтись очень дорого и отнять много времени.

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

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

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