Определение и анализ требований.

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

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

Анализ требований включает три типа деятельности:

I. Сбор требований – общение с клиентами и пользователями, чтобы определить, каковы их требования; анализ предметной области.

II. Анализ требований – определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; решение этих проблем; выявление взаимосвязи требований.

III. Документирование требований – требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.[20]

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

Анализ требований включает в себя следующие фазы:

1. Разработки требований

2. Выявление

3. Анализ

4. Спецификация

5. Проверка

6. Управления требованиями. [21]

Результатом проведенного анализа становится формирование основного регламента, на который будет опираться исполнитель в своей работе - технического задания на разработку программного обеспечения. Техническое задание должно полностью описывать поставленные перед разработчиком задачи и охарактеризовать конечную цель проекта в понимании заказчика. [22]

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

Проектирование – процесс создания проекта программного обеспечения; моделирование теоретической основы будущего продукта. На данной стадии постановка задачи должна быть превращена в алгоритм. Поэтому алгоритмист должен обладать достаточным опытом программирования и подходить к каждой новой задаче, опираясь на твердо установленную методику проектирования.[23] Самые современные средства программирования позволяют частично объединить этапы проектирования и конструирования, то есть технической реализации проекта, будучи основанными на объектно-ориентированном подходе, но полноценное планирование требует более тщательного и скрупулезного моделирования. Качественный анализ перспектив и возможностей создаваемого продукта станет основой для его полноценного функционирования и выполнения всего комплекса возлагаемых на ПО задач. Одной из составных частей этапа проектирования, к примеру, является выбор инструментальных средств и операционной системы, которых сегодня на рынке присутствует очень большое количество.

В рамках данного этапа стороны должны осуществить:

1) оценку результатов проведенного первоначально анализа и выявленных ограничений;

2) поиск критических участков проекта;

3) формирование окончательной архитектуры создаваемой системы;

4) анализ необходимости использования программных модулей или готовых решений сторонних разработчиков;

5) проектирование основных элементов продукта — модели базы данных, процессов и кода;

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

7) определение основных требований к безопасности разрабатываемого ПО.[24]

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

Существуют две основные модели вывода:

I. Дедуктивный вывод.

II. Индуктивный вывод.

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

Если при этом он использует метод проектирования «сверху вниз», то единственная задача проектирования может быть разбита на две меньшие подзадачи: (1) проектирование холодильного агрегата и (2) проектирование морозильника.

Однако можно воспользоваться методом проектирования «снизу вверх» и начать с проектирования холодильного компрессора, а затем охлаждающих труб, агрегата или холодильной камеры. В таком случае этот выбор будет налагать определенные ограничения на весь проект.[25]