Технология разработки программ

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

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

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

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

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

Вспомогательные процессы

Процесс документирования. В процессе разработки и далее исполнитель пишет документацию и руководства пользователя к разрабатываемому программному продукту. Данные документы помогут разработчикам [вспомнить/разобраться] структуру и код ПО (ибо со временем всё забывается, особенно в больших проектах), а пользователям освоить работу с программой.
Процесс управления конфигурацией. Данный процесс включается в себя работы по управлению наборами разрабатываемых компонентов ПО и по управлению версиями ПП.

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

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

 Организационные процессы жизненного цикла программного продукта

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

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

Этапы создания ПП.

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

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

Модели жизненного цикла

Модель кодирования и устранения ошибок(Code and Fix)
Каскадная модель
V- образная модель
Инкрементная модель
Итерационная модель
Модель прототипирования
RAD-модель
Гибкие методологии

Модель кодирования и устранения ошибок(Code and Fix)

Готовый продукт

Заказчик счастлив?

да нет

Исправляем ошибки

Пишем код

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

Преимущества
Простота
Скорость
Недостатки
Код не соответствует требованиям
Затраты на исправления и переделки высоки
Исправление 1 ошибки приводит к появлению многих

Каскадная модель (waterfall model)

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

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

Недостатки модели:
Запаздывания с получением результатов
Высокая цена ошибки

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

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

Область применения
Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
Для малых и средних проектов, где требования четко определены и фиксированы.
В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
Недостатки
Не предназначена для управления динамическими событиями

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

Инкрементная модель — это метод, в котором проект проектируется, реализуется и тестируется инкрементно (то есть каждый раз с небольшими добавлениями) до самого окончания разработки. Это включает в себя как разработку, так и дальнейшую поддержку продукта. Он считается законченным в то время, когда удовлетворяет всем требованиям. Модель объединяет элементы каскадной модели с прототипированием.

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

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

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

Прототипированная модель

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

Преимущества:
1)         Взаимодействие заказчика с разрабатываемой системой начинается на раннем этапе;
2)         Благодаря реакции заказчика на прототип сводится к минимуму число неточностей в требованиях;
3)         Снижается вероятность возникновения путаницы, искажения информации или недоразумений при определении требований к программному прдукту, что приводит к созданию более качественного программного продукта;
4)         В процессе разработки всегда можно учесть новые, даже неожиданные требования заказчика;
5)         Прототип представляет собой формальную спецификацию, воплощенную в программный продукт;

6)         Прототип позволяет очень гибко выполнять проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла разработки;
7)         Заказчик всегда видит прогресс в процессе разработки программного продукта;
8)         Возможность возникновения противоречий между разработчиками и заказчиками сведена к минимуму;
9)         Уменьшается число доработок, что снижает стоимость разработки: возникающие проблемы решаются на ранних стадиях, что резко сокращает расходы на их устранение; заказчики принимают участие в процессе разработки на протяжении всего жизненного цикла и в конечном итоге в большей степени довольны результатом работы

Недостатки:
1)         Решение сложных задач может отодвигаться на будущее;
2)         Заказчик может предпочесть получить прототип, а не законченную полную версию программного продукта;
3)         Прототипирование может неоправданно затянуться;
4)         Перед началом работы неизвестно, сколько итераций придется выполнить.

Область применения
1)         Требования к программному продукту заранее неизвестны;
2)         Требования не постоянны или неудачно сформулированы;
3)         Требования необходимо уточнить;
4)         Нужна проверка концепции;
5)         Существует потребность в пользовательском интерфейсе;
6)         Выполняется новая, не имеющая аналогов разработка;
7)         Разработчики не уверены в том, какое решение следует выбрать.

RAD-модель

Достоинства:
1)         Использование современных инструментальных средств позволяет сократить время цикла разработки;
2)         Привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым программным продуктом;
3)         Повторно используются компоненты уже существующих программ.

Недостатки:
1)         Если заказчики не могут постоянно участвовать в процессе разработки, то это может негативно сказаться на программном продукте;
2)         Для работы нужны высококвалифицированные кадры, умеющие пользоваться современными инструментальными средствами;
3)         Существует риск, что работа над программным продуктом никогда не будет завершена, так как может быть зациклена, поэтому всегда надо вовремя остановиться.

Гибкие методологии

Scrum
Extreme Programming
Канбан

Scrum — это фреймворк гибкой разработки ПО, который считается методологией «по умолчанию». Для многих является синонимом Agile.

Преимущества :
Возможность быстрого запуска проекта с наиболее приоритетными функциями и минимально возможным бюджетом;
Ежедневный контроль над ходом работ, и более гибкий контроль над бюджетом проекта;
Частые демонстрации проекта. Применение данной методологии предполагает регулярную демонстрацию разработок заказчику (заказать эффективный сайт можно, скажем, тут, - https://2atom.ru/ , - заодно сможете подсчитать стоимость в калькуляторе), что позволяет в будущем избежать полного провала работы команды и разочарований клиента;
Возможность вносить коррективы в техническое задание по ходу реализации проекта, что является несомненным преимуществом для заказчика.

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

Концепция строится на основании двенадцати приёмов:
Разработка через тестирование (Test-driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Onsite customer)
Парное программирование (Pair programming)
Непрерывная интеграция (Continuous integration)
Рефакторинг (Design improvement)
Частые небольшие релизы (Small releases)
Простота проектирования (Simple design)
Метафора системы
Коллективное владение кодом (Collective code ownership)
Стандарт оформления кода (Coding standard)
40-часовая рабочая неделя (Sustainable pace)


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

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

Канбан

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

Программно-аппаратный комплекс — это набор технических и программных средств, работающих совместно для выполнения одной или нескольких сходных задач.
Аппаратно-программный комплекс — техническое решение концепции алгоритма работы сложной системы, управление которой осуществляется, как правило, исполнением кода из определённого базового набора команд (системы команд), описанных в документации.
Состоит, соответственно, из двух основных частей:
Аппаратная часть (Hardware) — устройство сбора и/или обработки информации например компьютер, плата видеозахвата, биометрический детектор, калибратор и т. д.
Программная часть (Software) — специализированное ПО (как правило, написано компанией — производителем аппаратной части), обрабатывающее и интерпретирующее данные, собранные аппаратной частью