Цикл разработки программного обеспечения

Материал из Seo Wiki - Поисковая Оптимизация и Программирование

Перейти к: навигация, поиск

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

Содержание

Предисловие

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

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

Действия в процессе написания программного обеспечения

Файл:Waterfall model.png
Действия в процессе написания, представленные в модели водопада. Есть и другие модели, по-другому представляющие себе этот процесс.

Анализ требований к продукту

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

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

Анализ области работы часто является первой ступенью лестницы проектирования нового фрагмента программного обеспечения, вне зависимости от того, является ли он добавлением к уже существующему приложению или новым приложением, подсистемой или совершенно новой системой. Принимая, что разработчики (так же как и аналитик) не являются в начале достаточно образованными в области знаний нового программного обеспечения, первая задача — это собственно исследование этой самой области знаний. Чем лучше разработчики знают область, в которой работают, тем меньше потом возникает работы. Также её проводят для того, чтобы позже не появлялось путаницы в терминологии, и пониманием того, что делает эта программа. Если аналитик использует неверную терминологию, то опять же возможны недопонимания, в результате того, что программа будет делать не то, что нужно. Эта работа исключает случаи вроде «Я знаю, что вы верите в то, что поняли, что я говорю, но я не уверен, что вы понимаете, что то, что вы слышали — это не то, что я имею в виду.»

Спецификация

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

Архитектура

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

Проектирование, реализация и тестирование

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

Распространение и поддержка

Распространение начинается после того, как код достаточно оттестирован, и признан готовым к релизу.

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

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

Модели

Водопад

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

  1. Спецификация требований
  2. Проектирование
  3. Кодирование
  4. Интеграция
  5. Тестирование и отладка (валидация и верификация)
  6. Установка
  7. Поддержка

Лёгкая модель разработки

Лёгкая модель разработки создана организациями, занимающимися итерационной разработкой. Для этого используется более лёгкий, централизованный на людях подход, чем использующийся в традиционных подходах. Лёгкие процессы используют обратную связь вместо планирования как главный контролирующий механизм. Обратная связь ведётся посредством регулярных тестов, а также частых релизах разрабатываемого продукта. Интересно, что исследования показывают потенциал для хорошего улучшения производительности относительно стандартного «водопадного метода. К примеру исследование, опубликованное в августе 2006 года, и базированное на опросах более чем 700 компаний, гласит о огромной прибыли при использовании этой модели. [1] Исследование было повторено в августе 2007 года с базой в 1,700 компаний.[2]

Итерационные подходы

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

XP: Экстремальное программирование

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

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

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

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

Другие модели

  • ISO 15504 — один из американских стандартов
  • Six sigma — методология для управления вариативностью процесса, использующая данные и статистический анализ, чтобы измерить и увеличить продуктивность компании.
  • Test Driven Development — разработка через тестирование — техника программирования, при которой модульные тесты для программы или ее фрагмента пишутся до самой программы и, по существу, управляют ее разработкой. Является одной из основных практик экстремального программирования.

Формальные методы

Формальные методы — математические представления проблемы создания программного обеспечения, а также оборудования на уровнях требований, спецификации а также дизайна. Как пример можно привести B-Method, Cети Петри, RAISE . Доступны разные формальные нотации спецификаций, такие как Z notation. Чаще всего для создания и валидации приложений и их дизайна используется теория конечных автоматов.

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

See also

Другие методологии:

Related subjects:

Примечания


Ссылки

<tr><th style="white-space:nowrap;" >Концепции</th> <td style="width:100%;background:#f0f0f0" > Моделирование данныхАрхитектура программного обеспеченияFunctional specificationЯзык моделированияПарадигма программированияПрограммное обеспечениеАрхитектура программного обеспеченияМетодология разработки программного обеспеченияЦикл разработки программного обеспеченияКачество программного обеспеченияОбеспечение качества программного обеспеченияСтруктурный анализ программного обеспечения </span></td></tr><tr><th style="white-space:nowrap;" >Направления</th> <td style="width:100%;" > Гибкая методология разработкиАспектно-ориентированное программированиеОбъектно-ориентированное программированиеПроблемно-ориентированное программированиеОнтологияСервисно-ориентированная архитектураЦикл разработки программного обеспеченияОценка затрат на разработку программного обеспечения</span></td></tr><tr><th style="white-space:nowrap;" >Модели</th> <td style="width:100%;background:#f0f0f0" > Модели разработки: Гибкая методология разработкиCleanroomИтеративная разработкаRUPOpenUPRADScrumMSFСпиральная модельМодель водопадаXPV-Model
Другие модели: CMMCMMIМодель данныхFunction modelIDEFInformation modelMetamodelingObject modelView modelUML </span></td></tr><tr><th style="white-space:nowrap;" >Выдающиеся
деятели</th> <td style="width:100%;" > Kent BeckГради БучФред БруксBarry BoehmУорд КаннингемОле-Йохан ДальTom DeMarcoЭдсгер Вибе ДейкстраДональд КнутМартин ФаулерЧарльз Энтони Ричард ХоарWatts HumphreyMichael A. JacksonIvar JacobsonCraig LarmanJames MartinBertrand MeyerDavid ParnasWinston W. RoyceJames RumbaughНиклаус ВиртЭдвард Йордан</span></td></tr><tr><th style="white-space:nowrap;" >Связанные
статьи</th> <td style="width:100%;background:#f0f0f0" > ИнформатикаКомпьютерная инженерияОрганизационная инженерияИстория разработки ПОКонфигурационное управлениеМенеджментДокументированиеМатематикаУправление проектамиУправление программамиВсеобщее управление качествомЭргономикаСистемотехникаОбратная разработка</span></td></tr></table>cs:Návrh počítačového programuda:Softwareudviklingsprocesde:Vorgehensmodell zur Softwareentwicklungen:Software development processes:Ciclo de desarrollofr:Cycle de développementgl:Ciclo de desenvolvementohe:מתודולוגיית פיתוח תוכנהit:Ciclo di vita del softwareja:ソフトウェア開発工程ko:소프트웨어 개발 프로세스lt:Programų kūrimo gyvavimo ciklo modelisnl:Softwareontwikkelmethodeno:Programvareutviklingsprosesspl:Proces wytwórczy oprogramowaniapt:Processo de desenvolvimento de softwareta:மென்பொருள் பொறியியல் வழிமுறைzh:项目生命周期
Личные инструменты

Served in 0.290 secs.