Методология разработки программного обеспечения: понятие, принципы, методы и этапы развития
Опубликованно 18.08.2018 13:15
Как создается программное обеспечение? Что в своей работе руководствуются специалисты? В этой важной области методологии разработки программного обеспечения. Некоторые из них мы рассмотрим в этой статье, подробно останавливаясь на цели, этапы, основные принципы и различия этих методов. Что?
Начнем с статья определения. Методология разработки программного обеспечения-это принципы, система идей, понятий, методов, технологий и инструментов, которые в конечном счете будут определять стиль развития. Другими словами, методология-это здесь конкретной реализации стандарта.
Важно отметить, что стандарты здесь советуют, и не предписывают, как он должен быть. Таким образом, перед создателем сохраняет свободу выбора, адаптации теория.
Конкретные продукты производятся с помощью методологии разработки программного обеспечения. Она позволит определить, как специалист будет выполнять свою работу. Сегодня, эти методы в множество, мы рассмотрим в течение области. Что же влияет на выбор-только один? Отличается от численности группы, сложности и специфики проекта, зрелости и стабильности бизнес-процессов компании-работодателя, личных предпочтений создателя.
Таким образом, методология-это ядро теории управления разработкой программного обеспечения. Ранее в их отношении была применена классификация, разделение методологии на два типа: последовательного и wordpad (в зависимости от применения модели жизненного цикла). Сегодня используется современное зачете, разделяющаяся также на две группы: прогнозируемые и адаптивные. Познакомимся с ними подробнее.
Прогнозируемые методологии
Что относится к данным методологии разработки программного обеспечения? Это варианты, которые фокусируются на детальном планировании будущего. Задач и ресурсов, известный на протяжении срока действия проекта. Там, работа в команде будет трудно реагировать на неожиданные изменения.
Этот план составляется на состав необходимых работ, требования к ним. Где изменения требований непосредственно приводит к изменению общего плана, дизайна проекта. Предсказуемо методологии типично создание специального комитета, диспетчер изменения для проекта учитывает только основные потребности. Адаптация методики
В чем особенность данных методологий разработки программного обеспечения? Они уже направлены на преодоление ожидаемых несовершенства, неполноты требований на постоянное изменение последних. В результате изменения спроса будет заменена и развития команды проекта.
Точный план по адаптации методологии разработки только в ближайшее время. Планов, связанных с наиболее удаленной от реальности событий, существует в форме заявления о цели работы, ее результаты и затраты.
Гибкие методологии
Гибкие методологии разработки программного обеспечения англ. Agile software development. Отсюда и второе название: agile-методов.
Гибкие методологии разработки программного обеспечения-это набор подходов к разработке, которая ориентирована на использование итеративного развития, динамическое формирование требований к проекту, обеспечение реализации в счет взаимодействий внутри работников самоорганизующихся групп, состоящих из специалистов различного профиля.
В первую очередь, это хорошие практики профессиональной деятельности небольших коллективов, занимающихся однотипной творчески. В сочетании с комбинированным (демократический и либеральный) метод управления.
Гибкие методологии разработки программного обеспечения ит, предназначены для минимизации рисков совместного проекта на все циклы (так называемые итерациям) и максимальной продолжительностью от 2 до 3 недель.
Итерации здесь миниатюрный программный проект, который включает в себя все задачи по обеспечению функциональной мини-роста. Как: планирование, анализ требований, проектирование, программирование, тестирование, разработка, документация. Конечно, итерации не является достаточным для производства конечного продукта. Здесь относится к другому. В конце каждой итерации готова гибкий продукт. Также в конце периода команды обязательно выполняет переоценку приоритетов разработки.
В ходе каждой итерации (этапа разработки программного обеспечения) делает акцент на прямое общение профессионалов "лицом к лицу". Большинство команд расположены в одном офисе. Обязательно наличие "клиента" - полномочный представитель, представляет проектные требования. С этой ролью управляет менеджер проекта, клиент, клиента, бизнес-аналитик. В офисе также могут быть тестеры, технические писатели, дизайнеры интерфейса и так далее.
Основной мерой здесь является конечный продукт. Более прямое общение специалистов, что является относительно небольшой объем сопутствующей письменной документации.
Agile Manifesto
Разберем основные стандарты разработки программного обеспечения. Первым выделяется сложный процесс развития под названием Agile. Он определяется Agile Manifesto. Важно сказать, что Agile не включает в себя некоторые практические советы, и содержит принципы и ценности, которыми должны руководствоваться в своей деятельности команды разработчиков.
Agile Manifesto разработана и принята 1-13 февраля 2001 года, в комплекс горнолыжного курорта в горах штата Юта. Содержит 4 основные идеи и 12 принципов командной работы, без единого совета.
Представьте основные идеи этой современной методологии разработки программного обеспечения: Взаимодействие и люди более важны, чем процессы и инструменты. Работающий продукт выше, является исчерпывающим документации. Сотрудничество с заказчиком важнее согласования отдельных условий договоров. Готовность команды к важным изменениям журнала первоначальные планы.
Также в рамках Agile Manifesto были определены следующие принципы деятельности разработчики: Удовлетворение запросов клиента за счет преемственности ранней поставки, стоимость. Приветствие изменений требований даже в конце проекта. По сути, это то, что может улучшить свою конкурентоспособность. Частые поставки работы каждую неделю до месяца. В проекте заняты мотивированные личности, обеспеченные комфортные условия работы, доверия и поддержки. Ежедневное тесное взаимодействие между клиентом и командой разработчиков. Лучший счетчик ход работы программного обеспечения. Пользователи, спонсоры, и разработчики решили сохранить темпы неопределенный срок. Постоянное внимание улучшению дизайна продукта, технические требования. Простота-это искусство не делать лишней работы. Постоянная адаптация команды к изменяющимся условиям деятельности. Разработчики должны постоянно находить пути повышения эффективности их работы, следовать в будущем. Waterfall Model
Манифест гибкой методологии разработки программного обеспечения, переходим на новый тип. Waterfall Model - "водопад" или каскадная модель. Одним из наиболее старых методов. Включает в себя последовательное прохождение этапов разработки программного обеспечения, каждый из которых должен завершиться до начала следующей.
Благодаря такой жесткости эта методика является довольно легко управлять проектом. Стоимость и сроки разработки определены заранее, и почему работы проходят быстро. Но важно помнить и о таких аспектах: каскадная, модель дает отличный результат в проекты заранее четко определенные требования для их осуществления. Здесь специалисты не имеет никаких шансов "откат", по сути, тест начинается только после окончания этапа.
Если выбор такой модели не достаточно оправдано для продукта, выход может быть замечен значительный дефицит. Действительно, эти последние узнают после окончания работ, в связи с порядок действий. Исправление ошибок уходит здесь достаточно дорого. Для начала исправления должны ждать конца развития.
Эксперты советуют использовать методику "каскад" в следующих случаях: Требований проекта известны, в том числе и стационарные. Каких-либо противоречий между ними. Не проблема, чтобы привлечь программистов необходимой квалификации. Проект является относительно небольшой.
V-Model
Стадии разработки программного обеспечения, а также последовательными. Эта особенность V-Model "в наследство" от "каскад". Особенно хорошо для систем, где требуется правильного функционирования. Хороший пример: создание приложения для клиник, используется для непрерывного мониторинга пациентов. Или программное обеспечение для управления механизмами, подушками безопасности в транспортных средствах. Или приложение мобильного оператора, разработан, чтобы сэкономить расходы пользователя на роуминг за рубежом.
Проект выполняется по четким пунктам творческой задачи. Тем не менее, значительная роль уделяется и в сроки тестирования: функциональное, интеграция, поплаваем, простота интерфейса.
Когда вы должны использовать эту методику для развития: В случаях, когда необходимо проводить испытания продукции. Для малых и средних проектов четко определены требования. В кругах, где инженеры, тестеры конкретной квалификации. Incremental Model
В этой технологии, разработка программного обеспечения комплекса требований системы состоит в сборке. Другими словами, это описание поэтапной сборки. Несколько циклов развития проекта образуют комплекс с именем "multi-каскад".
Цикл, в свою очередь, разделяется на отдельные легко порожденных модулей. Каждый из них проходит через этапы определения требований, проектирования, внедрения, тестирования, кодирования.
Особенностью здесь является то, что первый большой шаг-это продукт, модель развития. Затем добавляем шагом, новые функции. Этот процесс длится, пока не создает, не полностью. Инкрементные модели хороши там, где запросы на изменение являются легкими, могут просто быть формализованы и реализованы.
Опишем случаи, когда использование Incremental Model будет оправдано: Четко определены и поняты требования конечного продукта. Допускается доработать некоторые детали с течением времени. Есть несколько рисков, целей. Нужно на ранней стадии, вывод на рынок.
RAD Model
Просто обратите внимание, что RAD Model является одной из разновидностей дополнительных модели. Компоненты или функции программы здесь параллельную разработку нескольких профессиональных команд. В результате, получается несколько мини-проектов. Время на создание каждого из них строго ограничено. Все модули складываются в целом рабочий прототип. Система хороша тем, что позволяет представить клиенту для обзор работы продукта, которые затем можно провести ряд изменений.
Процесс разработки программного обеспечения состоит из нескольких этапов: Бизнес-моделирования. Это определение информационных потоков между спектром деления. Информационного моделирования. Данные, собранные на первом этапе, чтобы определить объекты, необходимые для потоков информации. Процесс моделирования. На этом этапе информационные потоки связывают определенные объекты для достижения целей проектирования. Сборки приложения. Есть способы еще для трансформации модели конструкции в коде. Тесты. Проверка новых компонентов и интерфейсов.
Использование метода разработки программного обеспечения только в том случае, когда команда высококвалифицированных и "узкие" специалисты. Бюджет проекта, безусловно, является большой: нужно оплатить работу профессионалов, стоимость кредита средства автоматизированной сборки.
Модель для определенного знания цели предприятия в случаях, когда нужно представить готовый продукт в короткие сроки - за 2-3 месяца. Iterative Model
Следующий пример организации разработки программного обеспечения является итеративной (или итеративной модели). Особенностью проекта является то, что для начала ее осуществления не нужны все спецификации требований. Создание начинается с проектирования базы данных, которая должна служить основой для определения новых условий.
Версии в этом случае может быть и не является несовершенной. Главное требование-чтобы она работала. Разработчик понимает и видит конечную цель работы. Он должен убедиться в том, что каждый шаг его деятельности был продуктивным, и каждая созданная версия работоспособна.
Что-то создание здесь напоминает создание картины: сначала сделал эскиз, а затем он наполнен цветами, добавляются детали, насыщенность, переходов, оттенков, отделки и процесс будет завершен.
Выглядит как инкрементная модель? Давайте посмотрим на разницу. В смене методологии изделие состоит из деталей, функциональный и складывается, что называется, постепенно. Но каждая часть-это уже целостный элемент. И "куски" в итеративной модели не имеют самостоятельности.
Еще один хороший пример разработки программного обеспечения методологии: инструмент, которые создают голос. Все началось с подготовки научной базы. Затем собрал необходимую документацию. С каждой новой разработкой качество инструмента повысилась. Но идеальный уровень, она не достигла до сих пор. Таким образом, проект еще не завершен.
Применение итеративной модели оправдано в следующих случаях: Требования к конечной версии развития ясны и четко определены. Проект очень амбициозный. Основная задача заранее определена. Но его детали приемлемым улучшить, изменить рабочий процесс.
Spiral Model
Спиральная модель очень похожа на предыдущую. Однако, в центре внимания по-прежнему задача разработки программного обеспечения - оценка рисков. Больше эта методология применима для решения критически важных работ, когда не было проекта может нанести серьезный ущерб деятельности компании.
Спираль модель широко используется при выпуске новых линеек программного обеспечения, при необходимости, научно-исследовательских проекта, практические тесты. Каждого "витка спирали проходит в четыре этапа: Планирования. Анализ рисков. Строительство. Оценка результатов. Если он положительный, то разработчик переходит к новой "революции" проекта.
Спиральная модель не стоит использовать для небольших бюджетов проектов. С другой стороны, он больше подходит для больших и дорогостоящих. Отличный пример применения методологии для разработки банковской системы workflow. Здесь много внимания уделяется не столько самой программирования, сколько анализ каждого продукта "революции". LD
Так называемые седан разработки. Является одной из ветвей гибкой методологии, что мы видели выше. Главное достоинство LD: сохранение целостности и функционального состояния профессионалов. В частности, это: Продвижение каждого из сотрудников, особенно успешной деятельности. Задачи проекта изменяются только в случае необходимости или по запросу клиента. Строгое выполнение плана. Увидят здесь, считаются признаком потери времени и ресурсов. Реализация в работе целостного видения деятельности: "Широко мыслить, быстро ошибаться, мало работать, тренироваться". XP
Очень любопытный пример методологии так называемого экстремального программирования. Что он скрывает? Это поведение развития в условиях изменения требований к продукту. Направление методологии имеет следующие характеристики: "Игра в планирование". В начале работы представлен лишь примерный план. Каждый этап в развитии его ясность увеличивается. Высокая частота пресс-релизы. Это означает, что новая версия будет иметь лишь небольшие отличия от предыдущего, но на его шоу посвящено минимум времени. Контакт с клиентом. Для следующих настоящей методики, важно быстро реагировать на все требования заказчика, оперативно реагировать на все его комментарии. Рефакторинг. Качество кода улучшается, без уменьшения его функциональности. Стандартное выполнение кода. На лице, или следовать правило, или отсутствие различий в процессе развития. Коллективная ответственность. Да, каждый член команды занят в одной области работ. Но общий результат, ответственность уже вся команда.
FDD
И последнее методологии в нашей статье. Она обеспечивает масштабируемость и воспроизводимость. Но поощряет творчество, применение в работе инноваций. Основные принципы методики следующие: Развития каждый большой проект-это система мероприятий. Все процессы должны быть простыми и хорошо понеси меня. Последовательность и значение каждого процесса должна быть ясной и понятной для любого члена команды. Желательно - короткий цикл разработки. Это позволяет уменьшить количество ошибок, однако, за счет увеличения функциональности.
Значение методологии и что она регулирует продолжительность процесса. На организационные вопросы, в каждом цикле не должен галстук более 25 % времени. Остальные 75% - особо на проектирование, монтаж, тестирование функциональности.
На этом закончим познакомиться с разработками программного обеспечения. Как вы можете видеть, особенности каждой из них позволяют выбрать методику, для успешной реализации нескольких проектов. Автор: Юлия Альба 6 Августа 2018 года
Категория: Hi-Tech
