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