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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К преимуществам разработки ПО с использованием модулей можно отнести следующее.

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

Модуль обладает тремя основными признаками: реализует одну или несколько функций, имеет определенную логическую структуру и используется в одном или нескольких контекстах. Функция представляет собой внешнее описание действий, выполняемых модулем, без указания того, как эти действия производятся. Логика модуля определяет его внутренний алгоритм, т.е. то, как модуль выполняет функцию. Функцию модуля можно рассматривать как совокупность логики модуля и функций всех подчиненных (вызываемых им) модулей. Контекст описывает конкретное использование модуля. Результатом проектирования модульной структуры является определение состава программных модулей и установление связей между ними по управлению и по данным.

1. Программирование.

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

Процесс программирования состоит из следующих шагов.

1. Выбор языка программирования. Этот выбор часто бывает предопределен имеющимися у заказчика вычислительными ресурсами, принятыми организационными стандартами и подготовкой программистов. Существенное влияние на выбор языка оказывает его возможности обеспечивать надежный процесс получения программ, наличие и специфические особенности компилятора и т.д.
2. Выбор алгоритма и структуры данных. Этот шаг обусловлен тем, что к настоящему времени разработано значительное количество алгоритмов и соответствующих структур данных, которые позволяют удовлетворить многие потребности разработчиков ПО. Поэтому следует использовать опыт предыдущих разработок и выбрать из имеющихся эквивалентных алгоритмов и структур данных необходимые. Если же выбор не приводит к желаемому результату, то алгоритм и структуры данных необходимо разработать.
3. Оформление начала и конца будущего модуля. На данном шаге осуществляется оформление модулей в соответствии с требованиями принятого языка программирования.
4. Объявление всех данных, используемых в качестве параметров. На этом шаге записываются операторы объявления данных, соответствующие входным и выходным параметрам каждого модуля.
5. Объявление оставшихся данных. Данный шаг предусматривает запись операторов объявления всех оставшихся данных, которые должны быть использованы в модуле. Поскольку трудно предсказать все переменные, которые понадобятся, этот шаг часто перекрывается следующим.
6. Детализация текста модуля. На этом шаге в результате нескольких итераций осуществляется последовательная детализация логики модуля, начиная с достаточно высокого уровня абстракции и заканчивая готовым текстом программы.
7. Окончательное оформление текста программы. На этом шаге текст модуль проверяется еще раз, и при этом вставляются дополнительные комментарии, поясняющие текст программы.
8. Проверка правильности программы. На этом шаге в ручную проверятся правильность модуля. Для этого применяют методы статического тестирования (см. следующий раздел).
9. Компиляция модуля. Этот шаг отмечает переход от этапа программирования к тестированию модуля, так как работа над созданием модуля завершена. Компилятор, строя машинную программу, проводит контроль синтаксиса и частично семантики исходного текста программы.

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

1. Стремитесь к простой, а не сложной программе.
2. Четко и ясно выражайте свои мысли.
3. Возлагайте рутинную работу на ЭВМ.
4. Сначала записывайте программу на легко воспринимаемом языке, а затем переводите ее на требуемый язык программирования.
5. Не останавливайтесь на первом варианте программы.
6. Выбирайте такой способ представления данных, который упрощает программу.
7. Не исправляйте неудачный участок программы - перепишите его заново.
8. Убедитесь, что входные данные соответствуют принятым ограничениям.
9. Обеспечьте распознавание неверно заданных входных данных и, если это возможно, их исправление.
10. Обеспечьте возможность нормального завершения программы в случае неверного задания исходных данных.
11. Стремитесь к тому, чтобы инициализация переменных проводилась прежде, чем они будут использованы.
12. Стремитесь в первую очередь к получению правильной программы и только потом к сокращению времени ее выполнения.
13. Отдавайте предпочтение ясности программы, а не скорости ее выполнения.
14. Не оптимизируйте без необходимости. Программы следует писать просто и ясно. Для оптимизации используйте оптимизирующий компилятор.
15. Не тратьте зря времени на изменение текста программы для сокращения времени ее работы - ищите лучший алгоритм.
16. Помните, что в сложных системах простые последовательные алгоритмы часто работают быстрее, чем более изощренные и сложные.
17. Используйте комментарии, поясняющие текст программы.
18. Обеспечьте соответствие комментариев тексту программы.
19. Комментарий должен не повторять текст программы, а пояснять смысл выполняемых действий.
20. Не пытайтесь с помощью комментариев сделать понятной плохую программу - перепишите ее заново.
21. Идентификаторы переменных и метки в программе должны нести смысловую нагрузку.
22. Избегайте сходных по написанию идентификаторов.
23. Не пользуйтесь в качестве идентификаторов ключевыми словами языка программирования.
24. Избегайте использования промежуточных переменных там, где без них можно обойтись.
25. Во избежание неоднозначности в выражениях употребляйте скобки.
26. Записывайте только один оператор в строке.
27. Используйте сдвиги по строке в соответствии с уровнем вложенности операторов.
28. Избегайте меток операторов, если в этом нет необходимости.
29. Используйте строки пробелов для улучшения внешнего вида программы.
30. Тестирование и отладка программ

Общая схема отладки

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

1. действия, направленные на выявление ошибок (тестирование);
2. диагностику и локализацию ошибок (определение характера и местонахождения ошибок);
3. внесение исправлений в программу с целью устранения ошибок.

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

Если вспомнить распределение временных затрат по этапам разработки на фазе разработки ПО, то общее время проведения отладки, включая как автономную, так и комплексную составляет 45% затрат. По некоторым оценкам, чисто на тестирование уходит до 40% временных затрат фазы разработки. Следовательно, на тестирование в общем процессе отладки выделяется 87.5%. Остальные 12.5% времени разделяется между процессами локализации и устранения ошибок. В среднем из этих двух аспектов, диагностика и локализация ошибок занимает 95%.

Методы диагностики и локализации ошибок

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

Наибольшую популярность в программистской среде получили методы "грубой силы". Это вызвано тем, что они не требуют значительного внимания и больших умственных затрат. Методы "грубой силы" можно разделить на 3 категории:

1. диагностика и локализация ошибок с использованием дампа памяти;
2. метод отладочной печати;
3. диагностика и локализация ошибок с использованием программ – отладчиков.

Наименее эффективен из них анализ дампа памяти. С ним связаны следующие проблемы:

1. Довольно сложно установить соответствия между ячейками памяти и переменными в исходной программе.
2. Обычно анализируется значительный объем данных, многие из которых не используются.
3. Дамп является отображением программы в статике, в то время как для успешного обнаружения ошибки прежде всего важна динамика выполнения программы.
4. Дамп может не отражать состояния программы в точке, содержащей ошибку, а действия, осуществляемые в промежутка между моментом возникновения ошибки и моментом получения дампа, могут помешать локализовать ошибку.

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

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

В-четвертых, метод отладочной печати не применим для отладки некоторых типов ПО, например, операционных систем, программ управления процессами и т.п.

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

Общей проблемой методов "грубой силы" является то, что они игнорируют процесс обдумывания условий и причин появления ошибок.

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

Диагностика и локализация ошибок с обдумыванием результатов исполнения программы объединяет следующие группы методов: индукции; дедукции; прослеживания логики в обратном порядке.

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

Диагностика и локализация ошибок методом индукции разбивается на следующие шаги.

1. Определение данных, имеющих отношение к ошибке, которое заключается в перечислении всех результатов действий, свидетельствующих о правильном выполнении программы и всех ее неправильных действий (т.е. симптомов, которые приводят к выводу о наличии ошибки).
2. Организация данных. Индукция подразумевает анализ от частного к общему, поэтому следующий шаг заключается в структурировании данных, имеющих отношение к ошибке, с целью выявления закономерностей.
3. Изучение взаимосвязи между признаками ошибки и выдвижения гипотезы (одной или нескольких) о причине ошибки. Выдвижение гипотезы осуществляется с учетом закономерностей, выявленных в структуре симптомов ошибки. Если нельзя выдвинуть гипотезы, то необходимы дополнительные данные, которые, возможно, будут получены путем построения и выполнения дополнительных тестов. В том случае, когда возможно несколько гипотез, первой выбирается наиболее вероятная.
4. Доказательство гипотезы. Пропуск этого шага и переход непосредственно к заключениям и попыткам найти ошибку является серьезным просчетом, сильно влияющим на результативность отладки. Необходимо доказать приемлемость гипотезы, прежде чем взять ее за основу. Гипотеза доказывается путем сравнения ее с первоначальными симптомами ошибки или данными. Она должна полностью объяснить существование этих симптомов. Если такое объяснение получить не удается, то, значит, гипотеза либо не обоснована, либо неполна и требуется выдвижение другой гипотезы или уточнения существующей.

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

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

Принципы тестирования

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

Из правильного определения тестирования и его цели вытекает ряд принципов:

1. Процесс тестирования более эффективен, если проводится не автором программы. Так как тестирование, процесс деструктивный (разрушительный) и разработчику трудно на него переключиться после конструктивного процесса проектирования и написания программы. Это не означает, что программист не может тестировать свою программу, речь идет о повышении эффективности тестирования
2. Описание предполагаемых значений результатов тестовых прогонов должно быть необходимой частью тестового набора данных. Что бы определить правильность полученных в результате очередного тестового прогона данных, необходимо знать ожидаемый результат, иначе правдоподобные результаты тестового прогона могут быть признаны правильными.
3. Необходимо досконально изучать результаты применения каждого теста. Из практики видно, что значительная часть всех обнаруженных в конечном итоге ошибок могла быть выявлена в результате самых первых тестовых прогонов, но они бывают пропущены вследствие недостаточно тщательного анализа результатов первых тестовых прогонов.
4. Тесты для неправильных и непредусмотренных входных данных должны разрабатываться также тщательно, как и для правильных, предусмотренных. Согласно этому принципу при обработке данных, выходящих за область допустимых значений, в программе должна быть предусмотрена диагностика в виде сообщений. Если что отсутствует, и программа завершается аварийно или ведет себя непредсказуемо, то такая программа не может считаться работоспособной и требует существенной доработки. Тестовые наборы данных из области недопустимых входных значений обладают большей обнаруживающей способностью, чем тесты, соответствующие корректным входным данным.
5. Необходимо проверить не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать.

То есть любую программу необходимо проверять на нежелательные побочные эффекты.

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

Классификация методов тестирования

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

Все существующие методы тестирования можно разделить на два основных класса – статическое и динамическое тестирование.

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

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

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

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

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

Из всех рассмотренных методов тестирования наиболее формализованными являются статические и динамические детерминированные методы.

Организация процесса тестирования

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

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

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

Под испытанием программ понимают процесс установления соответствия программы ЭВМ заданным требованиям и программным документам. Испытание ПО является завершающим этапом его разработки.

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

1. Документирование программного обеспечения

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

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

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

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

1. Внедрение и сопровождение

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

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

Задачами сопровождения ПО являются:

1. Включение новых функций;
2. Модификация существующих функций;
3. Внесение изменений, связанных с модификацией оборудования;
4. Исправление ошибок (которые остались в программном продукте).

Сопровождение включает следующие виды:

• корректирующее сопровождение (исправление существующих в ПО ошибок без изменения проектных спецификаций);

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

• адаптивное сопровождение (адаптация продукта в связи с модификацией оборудования).

Эти работы занимают до 67% временных затрат в жизненном цикле ПО.

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Липаев В.В. Проектирование программных средств: Учебное пособие для ВУЗов. - М.: Высшая школа, 1990. - 303 с.

2. Экономика, разработка и использование программного обеспечения ЭВМ: Учебник / В.А. Благодатских, М.А. Енгибарян, Е.В. Ковалевская и др. - М.: Финансы и статистика, 1995. - 288 с.

3. Фокс Дж. Программное обеспечение и его разработка. - М.: Мир, 1985. - 368 с.

4. Агафонов В.Н. Спецификация программ: понятийные средства и их организация. - Новосибирск: Наука, 1987. - 240 с.

5. Арефьева Н.А., Пушкина И.П., Родионов С.Т. HIPO-технология - метод разработки и сквозного документирования программ по принципу “сверху вниз” // Управляющие системы и машины. - 1978. - С.35-39.

6. Калянов Г.Н. CASE структурный системный анализ: Автоматизация и применение. - М.: Лори, 1996. - 242 с.

7. Вельбицкий И.В. Технология программирования. - К.: Техника, 1984. - 279 с.

8. Липаев В.В. Тестирование программ. - М.: Финансы и статистика, 1986. - 296 с.

9. Майерс Г. Искусство тестирования программ. - М.: Финансы и статистика, 1982. - 176 с.

10. Котляров В.П., Пинаев Д.В. Методы и средства автоматизации тестирования программного проекта: Учебное пособие. - СПБ: Нестор, 1998. - 90 с.

11. Единая система программной документации. - М.: Издательство стандартов, 1998. - 164 с.

12. Брябрин В.М. Программное обеспечение персональных ЭВМ. Изд. 2-е, стер. - М.: Наука, 1989. – 271 с.