Методическая разработка «Процесс создания программ»

Методическая разработка

«Процесс создания программ»

по МДК.03.01. Технология разработки

программного обеспечения

г. Нижний Новгород

2021 год

Аннотация

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

.

СОДЕРЖАНИЕ

Перечень условных обозначений 4

ВВЕДЕНИЕ 5

Методика создания программ 6

ЗАКЛЮЧЕНИЕ 9

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

Перечень условных обозначений

В методической разработке используются следующие сокращения:

• ПО – программное обеспечение;

• ПС – программные средства.

ВВЕДЕНИЕ

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

Методика создания программ

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

Текст программы для решения большой проблемы занимает много больше места, чем одна страница.

Создание таких программ путем написания на С# программы «с листа» практически невозможно.

Как правило, эта разработка предполагает систематический подход:

• описание проблемы;

• разработка алгоритма;

• написание программы.

Созданное программное средство (ПС, программа) должно быть читабельным, эффективным и корректным.

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

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

Ясность означает, что любой, кто знаком с языком С# и прикладной областью, поймет алгоритм, читая текст программы, комментарии и спецификацию проблемы.

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

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

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

Такой алгоритм можно разбить на следующие этапы:

1. Формирование и осознание проблемы. Назовём этот этап постановкой задачи.

2. Спецификация программы.

3. Разбиение проблемы на подпроблемы, до тех пор пока не подберём существующий алгоритм, либо не сможем «сходу» выписать свой.

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

5. Запись на языке C# программы со спецификациями промежуточных состояний.

6. Проверка правильности.

7. Оформление программы.

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

ЗАКЛЮЧЕНИЕ

Несмотря на появление новых тенденций, основные этапы разработки ПО остались неизменными:

1. Определение процесса разработки ПО.

2. Управление проектом разработки.

3. Описание целевого программного продукта.

4. Проектирование продукта.

5. Разработка продукта.

6. Тестирование частей.

7. Интеграция частей и тестирование продукта в целом.

8. Сопровождение продукта.

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

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

1. IEEE Std. 1320.1–1998. Стандарт IEEE по языку функционального мо-делирования – Синтаксис и семантика IDEF0. – Введ. 1998-09-25. –

2. IEEE Std. 1320.2–1998. Стандарт IEEE по синтаксису и семантике языка концептуального моделирования IDEFIX97 (IDEF Object). – Введ. 1998-06-25. – Нью-Йорк : IEEE, 1998.

3. ISO/IEC 12207:1995. Информационная технология – Процессы жизненного цикла программных средств. – Введ. 1995-08-01. – Женева : ISO/IEC, 1995.

4. ISO/IEC 12207:2008. Системная и программная инженерия – Процессы жизненного цикла программных средств. – Введ. 2008-02-01. – Нью-Йорк : ISO/IEC-IEEE, 2008.

5. ISO/IEC14598–1:1999. Информационная технология – Оценка про-граммного продукта – Ч. 1 : Общий обзор.

6. ГОСТ Р ИСО/МЭК ТО 12182 – 2002. Информационная технология. Классификация программных средств. – Введ. 2002 – 06 – 11. – М. : Изд-во стандартов, 2002.

7. ГОСТ Р ИСО/МЭК ТО 15271 – 2002. Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цик-ла программных средств). – Введ. 2002 – 06 – 05. – М. : Изд-во стандартов, 2002.

8. Trpo_lections[https://portal.tpu.ru/SHARED/i/IGSAVENKO/academic/]