Модели создания программного обеспечения

Этап 3: создание дизайна

Не все разработанные приложения проходят через этот этап, особенно, если они являются “тестовыми продуктами” для проверки ниши. При разработке нативных приложений на базе iOS и Android очень часто довольствуются прототипами и стандартными компонентами операционной системы. Но, если идее важна какая-то графическая изюминка, дизайнерская уникальность, то за дело берется дизайнер, который вдыхает краски в экраны, рисует иконки, подбирает шрифты и.т.п. Проще говоря, дизайнер собирает UI-kit.

UI-kit – это набор всех элементов из которых строится дизайн (в нашем случае мобильного приложения). Обычно, это огромный документ созданный дизайнером в Figma, Adobe XD или Photoshop для программиста.

Этапы и результаты проектирования

Проектирование состоит из следующих этапов:

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

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

1. Что делать (содержит описание продукта, функциональных возможностей, категорию пользователей)?
2. Как делать (содержит описание архитектуры)?
3. Как проверить, достигнута ли цель (варианты тестирований, критерии оценки)?

Замечание 1

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

Agile – это…

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

В Agile process включают:

• экстремальное программирование;
• Scrum;
• бережливую разработку;
• создание «через тестирование»;
• функционально управляемый подход;
• методологии «чистой комнаты»;
• итеративно-инкрементальный подход;
• MSF;
• написание динамических систем.

А еще здесь встречается метод управления Kanban. Ниже – таблица, которая поможет отличить Agile от «классических» приемов написания программного продукта.

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

Этапы STLC-цикла и критерии их начала и завершения (входа и выхода)

Этап	Критерии входа	Действия	Критерии выхода	Результаты
Анализ требований	— Есть документ о требованиях (как функциональных, так и нефункциональных).— Описаны критерии приемлемости.— Есть документ, описывающий архитектуру приложения.	— Анализ планируемой функциональности приложения.— Определение ролей пользователей.— Сбор требований о пользовательских интерфейсах, аутентификации, локализации и других особенностях.— Определение типов тестирования, которые будут проводиться.— Сбор информации о приоритетах тестирования.— Создание RTM-матрицы (матрицы отслеживания требований).— Определение тестового окружения, в котором будет проводиться тестирование.— Анализ возможности автоматизации (если нужно).	— Заполнена RTM-матрица.— Подготовлен и согласован отчет о возможности автоматизации.	— RTM-матрица.— Отчет о возможности автоматизации (если нужно).
Планирование	— Есть документы с требованиями.— Есть RTM-матрица.— Есть документ о возможности автоматизации тестирования.	— Анализ возможности различных методов тестирования.— Финализация наиболее подходящего метода тестирования.— Подготовка документа со стратегией/планом тестирования— Подбор инструментов тестирования.— Оценка трудозатрат.— Планирование ресурсов и определение ролей и ответственности.	— Готов и согласован документа со стратегией тестирования.— Одобрен документ по оценке трудозатрат.	— Документ со стратегией тестирования.— Документ с оценкой трудозатрат.
Создание тест-кейсов	— Есть документы с требованиями.— Есть RTM-матрица и план тестирования.— Есть отчет о возможности автоматизации.	— Создание тест-кейсов, автоматизированных тестов (если нужно).— Обновление тест-кейсов и автоматизированных тестов.— Создание тестовых данных.	— Готовы тест-кейсы и скрипты.— Готовы тестовые данные.	— Тест-кейсы и скрипты.— Тестовые данные.
Настройка тестового окружения	— Готовы документы по дизайну системы и ее архитектуре.— Есть план по настройке окружения.	— Оценка архитектуры.— Настройка окружения.— Создание списка требований к аппаратной и программной части окружения.— Финализация требований к качеству.— Подготовка задач по настройке окружения.— Настройка тестового окружения.— Подготовка и проведение smoke-тестов билда приложения.	— Окружение работает согласно списка требований.— Завершена подготовка тестовых данных.	— Готовое окружение.
Выполнение тестирования	— Есть базовая RTM-матрица, план тестирования, тест-кейсы и/или автоматизированные скрипты.— Готово тестовое окружение.— Завершена настройка тестовых данных.	— Выполнение тестов.— Документирование результатов тестирования.— Создание баг-репортов.— Обновление тест-плана и тест-кейсов (если нужно).— Обновление RTM-матрицы.— Повторное тестирование проблемных мест.— Регрессионное тестирование приложения.— Отслеживание проблемных мест, до закрытия тестирования.	— Все запланированные тесты проведены.— Созданы баг-репорты.	— Полностью заполненная RTM-матрица.— Обновленные по результатам тестирования тест-кейсы.— Баг-репорты.
Завершение тестирования	— Тестирование завершено.— Есть результаты тестирования.— Есть баг-репорты.	— Оценка цикла на основе времени, покрытии тестами, трудозатрат.— Подготовка метрик тестов.— Подготовка документа с итогами проекта.— Подготовка отчета о завершении тестирования.— Подготовка отчета о качестве продукта.— Анализ результатов тестирования.	— Отчет о завершении тестирования утвержден клиентом.	— Отчет о завершении тестирования.— Метрики тестов.

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

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

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

Формулировка задачи
– это само её объявление, её постановка.

Но просто формулировка ничем не поможет программистам.
Для этого и существует второй подэтап – это анализ задачи.

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

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

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

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

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

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

«Математическая
модель — это математическое представление реальности» — это определение
созданное математиками.

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

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

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

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

У алгоритма есть 2
обязательных условия:

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

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

Так же у алгоритмов
есть свойства:

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

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

3. Конечность,
т. е. каждое действие и алгоритм в целом должны иметь возможность завершения.

4. Массовость,
т. е. один и тот же алгоритм можно использовать с разными исходными данными.

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

В мире существует
несколько видов алгоритмов:

·
Линейный
алгоритм (описание действий, которые выполняются однократно в заданном
порядке);

·
Циклический
алгоритм (описание действий, которые должны повторятся указанное число раз или
пока не выполнено условие);

Этапы разработки мобильных приложений

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

1. Идея.

2. Разработка прототипа.

3. Разработка (написание кода).

4. Тест и отладка.

5. Релиз.

Теперь немного поговорим о каждом из них по очереди.

Идея

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

В этой статье мы вместе попробуем создать приложение-раскраску. Его идея — помочь отвлечься и занять человека чем-то интересным в свободное время. Это значит, что оно подойдет всем: и взрослым, и детям.

Разработка прототипа

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

Зачастую прототип разрабатывает UX/UI-дизайнер. Такой специалист может заранее представить, как будет выглядеть макет приложения, где будут располагаться кнопки и виджеты, а также какие функции они будут выполнять. Дизайнер создает главный экран программы и остальные страницы. При этом он указывает логическую связь и переходы между ними. Обычно это происходит с помощью специальных сервисов для создания прототипов, таких как: Marvel, InVision, Proto.io, Pixate, Framer и других.

Написание кода

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

Тест и отладка

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

Релиз

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

• Google Play;

• App Store;

• Appland;

• Samsung Apps;

• Huawei App Store.

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

Лучшие методологии разработки программного обеспечения

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

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

Гибкая методология разработки

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

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

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

Методология развертывания DevOps

DevOps — это составной термин, включающий Dev — разработку программного обеспечения и Ops — ИТ-операции. Основная идея метода заключается в том, чтобы объединить две стороны создания приложения — разработку программного обеспечения и совершенствование процессов разработки в одну.

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

Метод Waterfall Development

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

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

Быстрая разработка приложений

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

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

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

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

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

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

2. Анализ задачи и моделирование — определяются исходные данные и результат, выявляются ограничения на их значения, выполняется формализованное описание задачи и построение (выбор) математической модели, пригодной для решения на компьютере.

3. Разработка или выбор алгоритма решения задачи — выполняется на осно­ве ее математического описания. Многие задачи можно решить различными способами. Программист должен выбрать оптимальное решение. Неточности в постановке, анализе задачи или разработке алгоритма могут привести к скрытой ошибке — программист получит неверный результат, считая его правильным.

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

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

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

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

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

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

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

&nbspпредыдущая &nbsp &nbsp &nbsp &nbsp &nbspменю &nbsp &nbsp &nbsp &nbsp вверх &nbsp &nbsp &nbsp &nbsp &nbspследующая

Этапы разработки

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

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

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

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

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

   • • Кодирование – основной этап создания. Задуманный алгоритм программы нужно записать на языке программирования. Отнестись к этому процессу нужно со всей серьёзностью, ведь код должен работать правильно.

     

     

     

     

     

     

     

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

4. Внедрение и поддержка.

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

Кроме того, программа для ЭВМ – это объект авторского права. Она охраняется законодательство Российской Федерации. Регистрация программ для ЭВМ – это необязательная процедура. Однако будет надёжной защитой от недобросовестных конкурентов, которые могут воспользоваться результатами разработки.

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

Первоначальный дизайн

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

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

В рамках создания исходного дизайна выполняются следующие действия: 

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

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

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

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

История

Фреймворк методологии разработки программного обеспечения (также известный как SDM) появился только в 1960-х годах. Согласно Эллиотту (2004), жизненный цикл разработки систем (SDLC) можно считать старейшей формализованной методологической структурой для построения информационные системы. Основная идея SDLC заключалась в том, чтобы «продолжать разработку информационных систем очень продуманным, структурированным и методичным образом, требуя, чтобы каждый этап жизненного цикла — от зарождения идеи до доставки окончательной системы — был выполняется жестко и последовательно » в контексте применяемой структуры. Основная цель этой методологической основы в 1960-х годах заключалась в том, чтобы «разработать крупномасштабную функциональную бизнес-системы в эпоху крупных бизнес-конгломератов. Деятельность информационных систем вращалась вокруг тяжелых обработка данных и числовой хруст рутины «.

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

1970-е годы

• Структурированное программирование с 1969 г.
• Кепка Gemini SDM, первоначально от PANDATA, первый английский перевод был опубликован в 1974 году. SDM означает методологию разработки системы.

1980-е

• Метод анализа и проектирования структурных систем (SSADM) с 1980 г.
• Анализ требований к информации / Методология мягких систем

1990-е

• Объектно-ориентированного программирования (ООП) был разработан в начале 1960-х и стал доминирующим подходом к программированию в середине 1990-х.
• Быстрая разработка приложений (RAD), с 1991 г.
• Метод разработки динамических систем (DSDM), с 1994 г.
• Scrum, с 1995 г.
• Программный процесс команды, с 1998 г.
• рациональный унифицированный процесс (RUP), поддерживается IBM с 1998 г.
• Экстремальное программирование, с 1999 г.

2000-е

• Гибкий унифицированный процесс (AUP) поддерживается с 2005 г. Скотт Эмблер
• Дисциплинированная гибкая доставка (DAD) Заменяет AUP

2010-е

• Масштабируемая гибкая структура (Безопасный)
• Крупномасштабная шкала (Меньше)
• DevOps

Примечательно, что с момента DSDM в 1994 году все методологии из приведенного выше списка, за исключением RUP, были гибкими методологиями, однако многие организации, особенно правительства, по-прежнему используют процессы pre-agile (часто каскадные или аналогичные). Программный процесс и качество программного обеспечения тесно взаимосвязаны; на практике наблюдались некоторые неожиданные грани и эффекты

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