Последовательность этапов написания программы

1. Составление технического задания на программирование

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

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

2. Технический проект

На данном этапе выполняется комплекс наиболее важных работ, а именно:

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

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

Проектирование / Разработка программы. Этапы создания программы. Блок-схема и псевдокод.

3. Рабочая документация (рабочий проект)

На данном этапе осуществляется адаптация базовых средств программного обеспечения (операционной системы, СУБД, инструментальных сред конечного пользователя — текстовых редакторов, электронных таблиц и т.п.). Выполняется разработка программных модулей или методов обработки объектов – собственно программирование или создание программного кода. Проводятся автономная и комплексная отладка программного продукта, испытание работоспособности программных модулей и базовых программных средств. Для комплексной отладки готовится контрольный пример, который позволяет проверить соответствие возможностей программного продукта заданным спецификациям.

Основной результат работ этого этапа – создание эксплуатационной документации на программный продукт, включающей:

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

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

С чего начать разработку проекта? — Вопросы и Ответы #10

4. Ввод в действие

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

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

Жизненный цикл программных продуктов (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

Комментариев к записи: 2

Блог программиста

Откуда вы взяли всю эту информацию? — спрашиваю, т.к. выглядит очень сомнительно: Мне кажется, что 1. первые 2 пункта из «Составление технического задания на программирование» противоречат друг другу; 2. на втором этапе (технический проект) первым пунктом сразу составляется детальный алгоритм? — так бывает? 3. почему сначала разрабатывается детальный алгоритм, а потом уже (третьим пунктом) — структура ПО?

4. почему структура ПО разрабатывается до выбора инструментов? — инструменты очень часто сильно влияют на структуру. Простой пример — пишем сервер, инструменты — Java, Cи или Erlang. Какой смысл прорабатывать детальный алгоритм и структуру ПО для Java, если ПОТОМ мы решим использовать Erlang?

5. вы пишите что результатом этапа составления «рабочей документации» является собственно документация. Дак почему на этом этапе «Выполняется разработка программных модулей или методов обработки объектов – собственно программирование или создание программного кода»? По теме статьи есть шикарная книжка Фатрелла, кстати. Есть и ГОСТы еще, но я их не читал (наверняка там описана лишь водопадная модель как у вас, но наверняка там этап написания кода отделен от составления документации и тестирование тоже стопудово есть. )

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

Например, если нужна кроссплатформенность, то на ассемблере составлять ПО затруднительно. 2. Имеется в виду детальный алгоритм ОБРАБОТКИ ДАННЫХ, уточняется, какие данные предстоит обрабатывать. 3. После того, как определились с данными, разрабатывается структура ПО. 4. Возможно, отчасти с Вами соглашусь. К сожалению, я с Erlang не знакома.

5. Разработка программных модулей относится к составлению рабочего проекта, который находится в одном этапе с рабочей документацией. На этом же этапе производится и отладка. Начсет книги, я так понимаю, имеется в виду Роберт Т. Фатрелл, Дональд Ф. Шафер, Линда И. Шафер Управление программными проектами. Достижение оптимального качества при минимуме затрат?

Источник: prog-cpp.ru

Последовательность этапов написания программы

Внимание Скидка 50% на курсы! Спешите подать
заявку

Профессиональной переподготовки 30 курсов от 6900 руб.

Курсы для всех от 3000 руб. от 1500 руб.

Повышение квалификации 36 курсов от 1500 руб.

Лицензия №037267 от 17.03.2016 г.
выдана департаментом образования г. Москвы

Этапы разработки программ. Тестирование и отладка. Документирование программ

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Институт математики и компьютерных наук

Кафедра математики и информатики

По дисциплине: «Основы программирования»

Этапы разработки программ. Тестирование и отладка. Документирование программ

Глава 1. Этапы разработки программ

1.1 Постановка задачи

1.1.1 Формулировка и анализ физической задачи

1.1.2. Составление математической модели

1.1.3 Составление алгоритма задачи

1.2 Создание программы

1.2.1 Составление текста программы

1.2.2 Синтаксическая отладка программы

1.2.3 Тестирование и семантическая отладка

1.3 Документирование программы

1.3.1 Пользовательская документация программы

1.3.2 Документация по сопровождению программы

1.4 Запуск готовой программы и анализ полученных результатов

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

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

Целью данной курсовой работы является рассмотрение не маловажной, для начинающих программистов, темы — «Этапы создания программы». Практическое применение теоретических навыков было опробовано в процессе написания программного приложения — игра «Виселица». Что также стало целью данной курсовой.

Глава 1. Этапы разработки программ

Разработка программы – это не только написание программы. Написание программы является одним из этапов. Для начала перечислим все этапы разработки программ, а затем подробно расскажем о них.

Этапы разработки программ:

1. Постановка задачи

1. Формулировка и анализ физической задачи
2. Составление математической модели
3. Составление алгоритма задачи

1. Составление текста программы
2. Ввод текста программы в компьютер
3. Синтаксическая отладка программы
4. Тестирование и семантическая отладка
5. Документирование программы

1.1 Постановка задачи

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

1.1.1Формулировка и анализ физической задачи

Формулировка задачи – это само её объявление, её постановка. Но просто формулировка ничем не поможет программистам. Для этого и существует второй подэтап – это анализ задачи. Анализ задачи – это подробный просмотр задачи с определением и выявлением входной и выходной информации. ( Входная информация по задаче — это данные, поступающие на вход задачи и используемые для её решения. Выходная информация – это результат.) После проведения анализа поставленной задачи программисту более или менее понятно, с какими проблемами ему придется столкнуться.

1.1.2 Составление математической модели

Начнем опять же с определения. Для более четкого понимания рассмотрим определения математической модели, объявленные в разных (математических, физических, экономических и т.д.) источниках и попробуем создать собственное определение, подходящее для программирования. « Математическая модель — система уравнений и концепций, используемых для описания и прогнозирования данного феномена или поведения объекта.

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

Существует два основных класса задач, связанных с математическими моделями: прямые и обратные. В первом случае все параметры модели считаются известными, и нам остается только исследовать её поведение.

А во втором какие-то параметры модели неизвестны, и требуется их найти, сопоставляя поведение реальной системы с её моделью.» — данное определение используется в основном в экономике. « Математическая модель — это математическое представление реальности» — это определение созданное математиками. Делаем выводы: математическая модель в программировании – это система математических соотношений, приближенно отражающий сформулированную задачу. И она позволяет осуществить предварительный выбор оптимальных вариантов решений по определенным критериям. Создание математической модели не займет у нас много времени, т.к. мы должны были подробно разобрать задачу по предыдущему пункту.

1.1.3 Составление алгоритма задачи

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

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

• Линейный алгоритм (описание действий, которые выполняются однократно в заданном порядке);
• Циклический алгоритм (описание действий, которые должны повторятся указанное число раз или пока не выполнено условие);
• Разветвляющий алгоритм (алгоритм, в котором в зависимости от условия выполняется либо одна, либо другая последовательность действий);

1.2 Создание программы

Процесс создание программы, а точнее разработка программного обеспечения – это второй этап создания программы.

1.2.1 Составление текста программы

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

1.2.2 Синтаксическая отладка программы

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

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

1.2.3 Тестирование и семантическая отладка

1. необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы, чтобы можно было быстро выяснить наличие или отсутствие ошибки в ней;
2. следует по возможности избегать тестирования программы ее автором, т.к. кроме уже указанной объективной сложности тестирования для программистов здесь присутствует и тот фактор, что обнаружение недостатков в своей деятельности противоречит человеческой психологии (однако отладка программы эффективнее всего выполняется именно автором программы);
3. по тем же соображениям организация — разработчик программного обеспечения не должна “единолично ” его тестировать (должны существовать организации, специализирующиеся на тестировании программных средств);
4. должны являться правилом доскональное изучение результатов каждого теста, чтобы не пропустить малозаметную на поверхностный взгляд ошибку в программе;
5. необходимо тщательно подбирать тест не только для правильных (предусмотренных ) входных данных, но и для неправильных (непредусмотренных);
6. при анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать;
7. следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика);
8. тестирования не должно планироваться исходя из предположения, что в программе не будут обнаружены ошибки (в частности, следует выделять для тестирования достаточные временные и материальные ресурсы);
9. следует учитывать так называемый “принцип скопления ошибок” : вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части;
10. следует всегда помнить, что тестирование — творческий процесс, а не относиться к нему как к рутинному занятию.

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

1.2.3.1 Структурное тестирование

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

1.2.3.2 Совместимое тестирование модулей

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

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

1.2.3.3 Семантическая отладка

1. Пошаговая отладка программ с заходом в подпрограммы;
2. Пошаговая отладка программ с выполнением подпрограммы как одного оператора;
3. Выполнение программы до точки остановки.

1.3 Документирование программы

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

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

1.3.1 Пользовательская документация программы

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

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

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

1.3.2 Документация по сопровождению программы

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

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

1.4 Запуск готовой программы и анализ полученных результатов

После полученного нами файла с *. exe (обычно) разрешением мы можем запустить его и ещё раз проверить (проанализировать) верно, ли работает программа. На этом этапы создания программы закончены. 4

Источник: doc4web.ru

ОСНОВНЫЕ ЭТАПЫ РАЗРАБОТКИ ПРОГРАММНОГО ПРОДУКТА

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

При создании ПП можно выделить следующие основные этапы:

1) системный анализ (определение требований и анализ);

6) эксплуатация и сопровождение;

Характеристика основных этапов

Этап системного анализа

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

1) анализ выдвинутых требований и определение реальной возможности их выполнить;

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

3) формализация требований заказчика;

4) оценка сложности задачи;

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

6) разработка целей проекта, которые касаются только самого процесса разработки.

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

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

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

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

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

Этап проектирования

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

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

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

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

2) все связи между подсистемами должны быть явно описаны.

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

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

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

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

Источник: megaobuchalka.ru