Постановка задачи(УСТАНОВЛЕНИЕ и анализ ТРЕБОВАНИЙ) И ПРОЕКТИРОВАНИЕ

ВОЗНИКНОВЕНИЕ И ИССЛЕДОВАНИЕ ИДЕИ(замысла)

Процессы классической технологии программирования

Для каждого из них существует свой ГОСТ(позже)

или еще на более крупные фазы:

1) Фаза разработки

2) Фаза использования(эксплуатации);

3) Фаза сопровождения (продолжающейся разработки)

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

использование

------------------

разработка /

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

\_________________

Программное обеспечение создается, эксплуатируется и развивается во времени.

Разработка включает в себя все работы:

1) по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации,

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

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

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

Трудозатраты при классической разработке ПО, %

Анализ	Проектирование	Кодирование	Тестирование

Напомню:

1. возникновение и исследование идеи(замысла);

2. подготовительный этап

3. анализ требований к информационной системе;

4. проектирование архитектуры системы;

5. анализ требований к программному обеспечению;

6.проектирование архитектуры программного обеспечения;

7.детальное проектирование программного обеспечения;

8.реализация(программирование);

9.тестирование и отладка ПО;

10.интеграция ПО

11. квалификационное тестирование ПО

12.интеграция системы

13.квалификационное тестирование ИС

14.управление и разработка документации;

15.ввод в эксплуатацию (внедрение);

16.приемка ПО (это были процессы разработки - фаза разработки)

17.эксплуатация (фаза использования)

18.сопровождение (фаза сопровождения);

19.завершение эксплуатации.

Основные шаги этапа разработки: возникновение и исследование идеи, (системный анализ), проектирование ПО, программирование, тестирование, отладка и разработка документации.

Рисунок.

Этот технологический процесс имеет следующие действия:

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

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

а) требует автоматизации;

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

в) приводит к ошибкам в программном продукте.

Советы по организации поиска решения задачи:

- следует лучше понять – в чем смысл проблемы;

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

- фиксировать внимание к произвольным мыслям и ощущениям;

- выразить задачу на простом (детском) языке;

- заняться другой задачей;

- ждать, пока решение не придет в голову.

2) детальное исследование идеи, выработка концепции

Идея(концепция) нового ПП подвергается тщательному анализу.

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

Идея может привести либо к развитию уже существующего программного продукта, либо к созданию нового.

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

Действие заканчивается составлением спецификации.

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

Если более кратко, то спецификация - это подробное описание некоторой работы, подлежащей выполнению.

Что же такое реальная задача или предметная область?

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

Каждый фрагмент предметной области характеризуется:

а) множеством объектов и процессов, использующих объекты;

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

От полноты описания задачи в большой степени зависит успех ее решения.

3) экспертиза идеи.

Идея создания нового ПО подвергается тщательной экспертизе специалистами.

а) Проводится СИСТЕМНЫЙ АНАЛИЗ (экономический, технический), учитывающий потенциальный сбыт, издержки производства, уровень и сроки окупаемости, конкуренцию на рынке, требуемые инвестиции, краткосрочную и долгосрочную прибыль, степень риска. В случае если компания считает, что она сможет выгодно продавать свой продукт в существующих условиях, принимается решение о начале разработки.

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

в) для ПП необходимо заранее предусмотреть переход на новые версии и учесть затраты на продолжение разработки. (Пример подсистемы поддержки «Абонент ГРО»).

Итогом первого этапа является принятие решения о начале работы над проектом.

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

6.2. Подготовительный этап - выбор модели жизненного цикла, стандартов, методов и средств разработки, а также составление плана работ.

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

Это два тесно связанных процесса.

В процеесе постановки задачи:

а) четко формулируют назначение и основные требования к ИС и его результатам,

б) выявляются ограничения, существующие для достижения целей ИС и выполнения требований.

Почему требования - это важно?

Причины провалов проектов:

Неполнота требований	13.1%
Недостаточное привлечение пользователей	12.4%
Недостаток ресурсов	10.6%
Нереалистичные ожидания	9.9%
Недостаточная поддержка руководства	9.3%
Изменение требований	8.7%
Неверное планирование	8.1%
Потеря актуальности	7.5%

Факторы успеха проектов:

Вовлечение пользователей	15.9%
Поддержка руководства	13.9%
Четкие и ясные требования	13%
Хорошее планирование	9.6%
Реалистичные ожидания	8.2%
Частые контрольные точки	7.7%
Компетентная команда	7.2%
Актуальныетребования	5.3%

Требования связаны с тестами (V-модель):

V-модель помогает спланировать проект:

Конец формы

Установление требований– процесс ЖЦ программы, во время которого требования заказчика уточняются, формализуются и документируются. Требования к системе это формулировка:

а) сути системного сервиса (функциональные требования) и

б) ограничений.

Формулировка сути сервиса:

1) Определение функции, кототрые должно выполнять разрабатываемое ПО. Характеризует поведение системы по отношению к пользователям. Это определение бизнес - правил, которые должны всегда выполняться, например, «двухнедельная зарплата выплачивается в среду» или «стипендия студентам начисляется до 25 числа месяца» и т.д. Основной решаемый вопрос – «Что должна делать будущая система?»

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

Формулировка ограничений выражает ограничивающие условия:

а)на поведение системы

б)разработку системы.

в) эксплуатацию системы

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

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

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

Формулируется цель решения задачи и подробно описывается ее содержание:

- что дано,

- что необходимо найти, получить;

- как определить решение;

- какие данные должны быть подготовлены и источники их получения.

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

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

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

Известны три способа разработки определения требований к ПС:

· управляемая пользователем разработка,

· контролируемая пользователем разработка,

· независимая от пользователя разработка.

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

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

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

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

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