Файл: Основы проектирования программ. Этапы создания программного обеспечения (Анализ требований).pdf

Разработка программного обеспечения (далее - ПО) – это колоссальная работа, требующая тщательной проработки. Проектирование ПО, как и любых других сложных систем, выполняется поэтапно. Для создания ПО необходимо иметь представление о основных этапах и элементах разработки:

Анализ требований;
Специфицирование ПО;
Программирование;
Тестирование и отладка;
Документирование;
Внедрение и сопровождение.

На каждом этапе разработки выполняются определенные проектные операции, которые соответствующим образом документируются.

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

В данной курсовой работе, мы познакомимся с основными этапами для создании ПО.

Анализ требований

1.1. Процесс определения требований

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

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

Управляемые пользователем;
Утверждаемые пользователем;
Независимые от пользователя.

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

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

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

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

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

В процессе разработки требований необходимо решить следующие задачи.

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

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

1. Разработка целей создания программного обеспечения

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

В процессе описания целей возможно возникновение следующих ошибок:

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

В общем случае цели разработки ПО могут быть сгруппированы в 10 достаточно самостоятельных категорий:

универсальность;
человеческие факторы;
адаптируемость;
сопровождаемость;
безопасность;
документация;
стоимость;
календарный план;
производительность;
надежность.

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

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

Краткое описание - в нем кратко определяется общее назначение разрабатываемого ПО и его функций.
Определение пользователя - описывается круг возможных пользователей, характеризуются специфические особенности отдельных групп пользователей.
Подробное описание функциональных задач - характеризует однозначное восприятие задач пользователем и разработчиком.
Документация - определяются типы документации и предполагаемый круг читателей для каждого типа.
Эффективность - описываются все цели, касающиеся производительности: временные характеристики, использование ресурсов и т.д.
Совместимость - указываются стандарты, которым необходимо следовать в процессе разработки, а также другие программные продукты, с которыми разрабатываемое ПО должно быть совместимо.
Конфигурация - определяются различные конфигурации технических и программных средств, в среде которых может работать проектируемое ПО.
Безопасность - формируются цели в отношении сохранения работоспособности ПО при возникновении сбоев.
Обслуживание - обеспечиваются цели по затратам и времени исправления ошибок, а также функции для достижения этих целей.
Установка-описываются методы и средства настройки ПО на конкретные условия эксплуатации.
Надежность - цели по достижении надежности, из которых указываются:

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

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

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

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

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

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

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

1. Документирование требований. Техническое задание

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

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

Специфицирование программного обеспечения

Спецификации и их роль в разработке программ

Грубо говоря, спецификация программы – это описание задачи, которую решает программа. Слово "спецификация" буквально означает "описание" или "получение описания", а "специфицировать" значит "описывать". Заметим, что и сама программа тоже является некоторым описанием задачи. Так зачем же нужна спецификация? Чем она отличается от программы?

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

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

Таким образом, спецификация занимает промежуточное положение между требованиями к программе и самой программой.

К основным свойствам спецификации можно отнести следующее.

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