Как называется процесс создания программ разработки всех типов программного обеспечения

Обновлено: 23.05.2024

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

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

2.Создание программного обеспечения. Разработка, отладка и компоновка ПО согласно спецификации на него.

3.Аттестация программного обеспечения. Созданное ПО должно пройти аттестацию для подтверждения соответствия требованиям заказчика.

4.Совершенствование (модернизация) программного обеспечения.

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

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

Модели процесса создания ПО.

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

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

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

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

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

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

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

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

Подходы к процессу разработки ПО.

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

2.Спиральная модель разработки. В спиральной модели разработки весь процесс создания ПО, от начального эскиза системы до ее конечной реализации, разворачивается по спирали.

ОЦЕНКА И РАЗРЕШЕНИЕ РИСКОВ

РАЗРАБОТКА И ТЕСТИРОВАНИЕ.

Структура затрат на создание ПО.

Сборка и тестирование.

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

Учёт человеческого фактора

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

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

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

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

7. Профессиональные и этические требования к специалистам по программному обеспечению.

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

Компетентность. Специалист не должен скрывать (или ложно представлять) свой уровень компетенции и не должен браться за работу, которая этому уровню не соответствует.

Защита прав интеллектуальной собственности. Специалист не должен нарушать соответствующее законодательство о защите авторских прав при использовании чужой интеллектуальной собственности (патентов и т.п.). Он также должен защищать интеллектуальную собственность работодателя и клиентов.

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

Каскадная модель процесса создания ПО.

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

Эволюционная модель процесса создания ПО.

Эволюционная модель разработки ПО основана на следующей идее:

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

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

Управление рисками. Три типа рисков.

Четыре стадии процесса управления рисками. Планирование рисков. Стратегии управления рисками.

Процесс создания программного обеспечения. Четыре фундаментальных этапа.

2.Создание программного обеспечения. Разработка, отладка и компоновка ПО согласно спецификации на него.

4.Совершенствование (модернизация) программного обеспечения.

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

1.1. Понятие технологии конструирования программного обеспечения

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

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

Ключ к решению этих проблем:

грамотная организация процесса создания ПО;
реализация технологических принципов промышленного конструирования программных средств (ПС).

1.1.2. Методы, средства и процедуры технологии конструирования программного обеспечения

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

Рис. 1. Технология конструирования программного обеспечения (ТКПО)

Различают: методы, средства и процедуры ТКПО.

Методы обеспечивают решение задач:

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

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов с помощью CASE-систем.

CASE–система–Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).

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

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

Таким образом, процесс конструирования ПО состоит из последовательности шагов, использующих:

Такие процессы называют парадигмами или моделями ТКПО.

1.1.3. Типовые приемы конструирования пакетов программ сложной структуры

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

Известны две схемы декомпозиции:

алгоритмическая;
объектно-ориентированная.

Алгоритмическая декомпозиция применяется в обычных ПС. В основе лежит разбиение по действиям (алгоритмам).

Объектно-ориентированная — обеспечивает разбиение по автономным лицам (объектам) реального (или виртуального) мира.

Лица (объекты) содержат в себе описания действий и описания данных.

1.2. Модели разработки ПО

1.2.1. Стратегии конструирования ПО

Однократный проход (водопадная стратегия)
Инкрементная стратегия
Эволюционная стратегия

Однократный проход (водопадная стратегия) — линейная последовательность этапов конструирования;

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

Эволюционная стратегия. Система строится в виде последовательности версий, но:

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

1.2.2. Жизненный цикл программного обеспечения

Рис. 2. Жизненный цикл ПО

Достоинства жизненного цикла (ЖЦ):

дает план и временной график по всем этапам проекта;
упорядочивает ход конструирования.

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

1.2.3. Макетирование

Макетирование (прототипирование) (рис. 3)— это процесс создания модели требуемого программного продукта.

Модель может принимать одну из трех форм:

Рис. 3. Схема макетирования

Основная цель макетирования — снять неопределенности в требованиях заказчика.

обеспечивает определение полных требований к ПО.

заказчик может принять макет за продукт;
разработчик может принять макет за продукт.

1.2.4. Инкрементная модель

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

Рис. 4. Инкрементная модель

Современная реализация инкрементного подхода — экстремальное программирование (ХР) (Кент Бек, 1999). ХР ориентировано на очень малые приращения функциональности.

1.2.5. Быстрая разработка приложений (RAD)

Rapid Application Development (RAD). используется при разработке информационных систем (ИС).

В RAD выделяются следующие этапы (рис. 5):

Рис. 5. Этапы быстрой разработки приложений

Недостатки и ограничения RAD:

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

1.2.6. Спиральная модель

Спиральная модель (рис. 6) основана на свойствах классического жизненного цикла и макетирования, к которым добавляется анализ риска.

Рис. 6. Спиральная модель

Спиральная модель определяет четыре действия:

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

Достоинства спиральной модели:

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

Недостатки спиральной модели:

новизна (отсутствует достаточная статистика эффективности модели);
повышенные требования к заказчику;
трудности контроля и управления временем разработки.

1.2.7. Компонентно-ориентированная модель

Компонентно-ориентированная модель (рис. 7) является развитием спиральной модели (рис. 6).

Рис. 7. Компонентно-ориентированная модель

Достоинства компонентно-ориентированной модели:

уменьшает на 30% время разработки программного продукта;
уменьшает стоимость программной разработки до 70%;
увеличивает в полтора раза производительность разработки.

1.3. Процессы разработки программного обеспечения

Процессы разработки программного обеспечения - строго упорядочивающие тяжеловесные (heavyweight) или прогнозирующие (predictive) процессы. В них прогнозируется весь объем предстоящих работ.

Процессы разработки программного обеспечения - группа новых, адаптивных, облегченных (lightweight) или подвижных (agile) процессов.

1.3.1. Упорядочивающие прогнозирующие процессы

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

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

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

1.3.2. Адаптируемость пакетов программ. Адаптивные процессы

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

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

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

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

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

Адаптивный процесс используют при:

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

1.4. Организация проектирования программного обеспечения

Организация проектирования программного обеспечения определяет сущность процесса разработки от его начала до конца.

1.4.1. Этапы процесса руководства проектом

Рис. 8. Руководство программным проектом

Для проведения успешного проекта нужно оценить:

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

Руководство программным проектом:

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

Перед планированием проекта следует:

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

1.4.2. Планирование проектных задач

При планировании программного проекта необходимо оценить:

людские ресурсы (в человеко-месяцах);
продолжительность (в календарных датах);
стоимость.

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

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

1.4.3. Предварительная оценка программного проекта

Измерения, меры и метрики

Измерения процесса производятся в целях его улучшения. Измерения продукта производятся для повышения его качества.

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

В IEEE Standard Glossary of Software Engineering Terms метрика определена как мера степени обладания свойством, имеющая числовое значение. В программной инженерии понятия мера и метрика рассматривают как синонимы.

Процесс оценки. Анализ риска

Анализируется влияние неопределенности перед созданием программного продукта на проект.

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

В результате принимается решение — выполнять проект или нет.

Трассировка и контроль

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

Веха — временная метка, к которой привязано подведение промежуточных итогов.

В результате повторного планирования могут быть:

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

Планирование проектных задач

Основная задача при планировании — определение структуры распределения работ.

Рис. 9. WBS — Work Breakdown Structure

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

Основной рычаг в планировании — вычисление границ времени выполнения задачи:

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

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

Технические требования

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

Системный анализ

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

Системный дизайн

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

Реализация

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

Тестирование

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

Развертывание

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

Обслуживание

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

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

Этап 1: Спецификация требований

Программа должна удовлетворять следующим требованиям:

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

Этап 2: Системный анализ

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

Для расчёта ежемесячного платежа:

monthlyPayment – ежемесячный платёж,
loanAmount – сумма кредита,
monthlyInterestRate – ежемесячная процентная ставка,
numberOfYears – число лет.

Для расчёта всего платежа:

totalPayment – общий платёж,
monthlyPayment – ежемесячный платёж,
numberOfYears – число лет.

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

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

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

Этап 3: Проектирование системы

Во время проектирования системы вы определяете шаги в программе.

Шаг 1. Попросите пользователя ввести годовую процентную ставку, количество лет и сумму кредита.

(Процентная ставка обычно выражается в процентах от основной суммы в течение одного года. Это называется годовой процентной ставкой.)

Шаг 2. Ввод годовой процентной ставки - это число в процентах, например, 4,5%. Программа должна преобразовать ее в десятичную цифру, разделив ее на 100. Чтобы получить ежемесячную процентную ставку от годовой процентной ставки, разделите ее на 12, так как год составляет 12 месяцев. Таким образом, чтобы получить ежемесячную процентную ставку в десятичном формате, вам необходимо разделить процентную ставку в процентах на 1200. Например, если годовая процентная ставка составляет 4,5%, то ежемесячная процентная ставка составляет 4,5 / 1200 = 0,00375.

Шаг 3. Вычислите ежемесячный платеж, используя предыдущую формулу.

Шаг 4. Вычислите общий платеж, который представляет собой ежемесячный платеж, умноженный на 12 и умноженный на количество лет.

Шаг 5. Выведите ежемесячный платеж и общий платеж.

Этап 4: Реализация

Реализация также известна как кодирование (запись кода). В формуле вы должны вычислить (1 + monthlyInterestRate) numberOfYears * 12 , это можно получить используя Math.pow(1 + monthlyInterestRate, numberOfYears * 12).

Полный код программы:

Строка 10 считывает годовую процентную ставку, которая конвертируется в ежемесячную процентную ставку в строке 13.

Выберите наиболее подходящий тип данных для переменной. Например, numberOfYears лучше всего объявлять как int (строка 18), хотя она может быть объявлен как long, float или double. Обратите внимание, что byte может быть наиболее подходящим для numberOfYears. Однако для простоты примеры на этом сайте будут использовать int для целых чисел и double для значений с плавающей запятой.

Формула для расчета ежемесячного платежа преобразуется в код Java в строках 25-27.

Явное изменение типа данных (кастинг) используется в строках 31 и 33 для получения нового monthlyPayment и totalPayment с двумя цифрами после десятичных точек.

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

Этап 5: Тестирование

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

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