Эволюция программного обеспечения: программное обеспечение модифицируется для адаптации к меняющимся требованиям клиентов и рынка. Эволюция программного обеспечения важна, потому что организация инвестировала большие суммы денег в свое программное обеспечение и полностью зависит от этого программного обеспечения, причем эволюция программного обеспечения запускается изменением требований бизнеса путем сообщения о дефектах программного обеспечения или изменениями в другой системе в программной системной среде (Обновлено 5 января 2020 г.)
Общее введение
Фред Брукс в своей ключевой книге Мифический человеко-месяц , [1] утверждает , что более 90% расходов типичной системы возникают в фазе технического обслуживания, и что любая успешная часть программного обеспечения неизбежно будет поддерживаться.
Фактически, Agile-методы проистекают из действий, аналогичных обслуживанию, в веб-технологиях и вокруг них, где большая часть возможностей исходит из фреймворков и стандартов. [ необходима цитата ]
Сопровождение программного обеспечения направлено на исправление ошибок и незначительные улучшения, а эволюция программного обеспечения сосредоточена на адаптации и миграции .
Программные технологии будут развиваться и дальше. Эти изменения потребуют создания и обоснования новых законов и теорий. Некоторые модели также потребуют дополнительных аспектов при разработке будущих программ. Нововведения и улучшения действительно увеличивают неожиданные формы разработки программного обеспечения. Вопросы обслуживания также, вероятно, изменились бы, чтобы адаптироваться к эволюции будущего программного обеспечения. Программные процессы сами по себе развиваются, пройдя обучение и усовершенствования, они всегда улучшают их эффективность и результативность. [2]
Основные понятия
Потребность в эволюции программного обеспечения исходит из того , что никто не в состоянии предсказать , как потребности пользователей будут развиваться априори . [3] Другими словами, существующие системы никогда не завершаются и продолжают развиваться. [4] По мере развития сложность систем будет расти, если не будет лучшего решения для решения этих проблем. Основные цели эволюции программного обеспечения - обеспечение функциональной актуальности, надежности и гибкости системы. Эволюция программного обеспечения может быть полностью ручной (на основе изменений, вносимых разработчиками программного обеспечения), частично автоматизированной (например, с использованием инструментов рефакторинга) или полностью автоматизированной (с автономной конфигурацией или эволюцией [5] ).
Интернет сильно повлиял на эволюцию программного обеспечения:
- Быстрый рост всемирной паутины и Интернет-ресурсов облегчает пользователям и инженерам поиск соответствующей информации.
- Разработка с открытым исходным кодом, когда любой может загрузить исходный код и, следовательно, изменить его, обеспечила быструю и параллельную эволюцию (через форки).
Виды сопровождения программного обеспечения
EB Swanson первоначально выделил три категории обслуживания: корректирующее, адаптивное и совершенное. Затем Линц и Свансон (1980) каталогизировали четыре категории программного обеспечения. [6] С тех пор они были обновлены и нормализованы на международном уровне в ISO / IEC 14764: 2006: [7]
- Корректирующее обслуживание : реактивная модификация программного продукта, выполняемая после доставки для исправления обнаруженных проблем;
- Адаптивное сопровождение : модификация программного продукта, выполняемая после поставки, чтобы программный продукт оставался пригодным для использования в изменившейся или меняющейся среде;
- Безупречное сопровождение : модификация программного продукта после доставки для повышения производительности или ремонтопригодности;
- Профилактическое обслуживание : модификация программного продукта после доставки для обнаружения и исправления скрытых ошибок в программном продукте до того, как они станут действующими ошибками.
Все предыдущее происходит, когда есть известная потребность в изменении.
Хотя эти категории были дополнены многими авторами, такими как Warren et al. (1999) [8] и Chapin (2001), [9] международный стандарт ISO / IEC 14764: 2006 сохранил четыре основные категории.
Совсем недавно описание сопровождения и развития программного обеспечения было выполнено с использованием онтологий (Kitchenham et al. (1999), [10] Deridder (2002), [11] Vizcaíno (2003), [12] Dias (2003), [13]) и Руис (2004) [14] ), которые обогащают описание многих видов эволюционной деятельности.
Сценическая модель
Текущие тенденции и практики прогнозируются с использованием новой модели эволюции программного обеспечения, называемой поэтапной моделью. [15] Поэтапная модель была введена для замены традиционного анализа, который менее подходит для современной разработки программного обеспечения, быстро меняется из-за трудностей, которые трудно внести в эволюцию программного обеспечения. Простая поэтапная модель включает пять различных этапов (начальная разработка, развитие, обслуживание, поэтапный отказ и закрытие).
- Согласно KHBennett и VT Rajlich, [15] ключевой вклад состоит в разделении фазы «обслуживания» на стадию развития, за которой следуют стадии обслуживания и поэтапного отказа. Первая версия программного обеспечения, в которой отсутствуют некоторые функции, будет разработана на начальном этапе разработки или также известна как альфа-этап. [15] Тем не менее, архитектура уже была создана на этом этапе, и в будущем будут внесены какие-либо изменения или дополнения. Большинство ссылок на этом этапе основано на сценариях или тематическом исследовании. Знания определили как еще один важный результат начального развития. Такие знания, включая знание предметной области, требований пользователей, бизнес-правил, политик, решений, алгоритмов и т. Д. Знания также кажутся важным фактором для последующей фазы эволюции.
- Как только предыдущий этап завершился успешно (и должен быть успешно завершен перед переходом на следующий этап), следующим этапом будет эволюция. Пользователи, как правило, изменяют свои требования, а также предпочитают видеть некоторые улучшения или изменения. Из-за этого фактора индустрия программного обеспечения сталкивается с проблемами быстрых изменений среды. Следовательно, цель эволюции - адаптировать приложение к постоянно меняющимся требованиям пользователей и операционной среде. [15] На предыдущем этапе созданная первая версия приложения может содержать множество ошибок, и эти ошибки будут исправлены на этапе эволюции на основе более конкретных и точных требований из-за тематического исследования или сценариев.
- Программное обеспечение будет непрерывно развиваться до тех пор, пока оно не перестанет развиваться, а затем перейдет на стадию обслуживания (также известную как зрелость программного обеспечения). На этом этапе будут внесены только незначительные изменения.
- Следующим этапом является поэтапный отказ от обслуживания данного программного обеспечения. Однако программное обеспечение все еще находится в разработке.
- Наконец, закрытие. Использование программного обеспечения отключается или прекращается [15], и пользователям рекомендуется заменить его. [15]
Законы Лемана эволюции программного обеспечения
Профессор Меир М. Леман , работавший в Имперском колледже Лондона с 1972 по 2002 год, и его коллеги определили набор моделей поведения в эволюции проприетарного программного обеспечения. Такое поведение (или наблюдения) известно как законы Лемана, и их восемь:
- (1974) «Постоянные изменения» - система E-типа должна постоянно адаптироваться, иначе она становится все менее удовлетворительной [16]
- (1974) «Возрастающая сложность» - по мере развития системы E-типа ее сложность увеличивается, если не выполняется работа по ее поддержанию или уменьшению [16]
- (1980) «Саморегулирование» - процессы эволюции систем Е-типа саморегулируются с распределением продукта и показателей процесса, близкими к нормальным [16]
- (1978) «Сохранение организационной стабильности ( неизменный темп работы )» - средний эффективный глобальный уровень активности в развивающейся системе E-типа неизменен в течение всего срока службы продукта [16]
- (1978) «Сохранение привычки» - по мере развития системы электронного типа все связанные с ней разработчики, торговый персонал и пользователи, например, должны сохранять мастерство в ее содержании и поведении для достижения удовлетворительной эволюции. Чрезмерный рост снижает это мастерство. Следовательно, средний прирост остается неизменным по мере развития системы. [16]
- (1991) «Постоянный рост» - функциональное содержание системы электронного типа должно постоянно увеличиваться, чтобы поддерживать удовлетворенность пользователей на протяжении всего срока ее службы.
- (1996) «Снижение качества» - качество системы электронного типа будет снижаться, если ее не поддерживать и не адаптировать к изменениям операционной среды.
- (1996) «Система обратной связи» (впервые заявлено в 1974 г., оформлено как закон 1996 г.) - процессы эволюции Е-типа представляют собой многоуровневые, многопетлевые, многоагентные системы обратной связи и должны рассматриваться как таковые для достижения значительного улучшения по сравнению с любым разумным база [17]
Стоит отметить, что применимость всех этих законов для всех типов программных систем изучалась несколькими исследователями. Например, см. Презентацию Nanjangud C Narendra [18], в которой он описывает тематическое исследование корпоративного Agile-проекта в свете законов эволюции программного обеспечения Lehman. Некоторые эмпирические наблюдения, полученные при изучении разработки программного обеспечения с открытым исходным кодом, по- видимому, бросают вызов некоторым законам [ расплывчатые ] [ необходима цитата ] .
Законы предсказывают, что необходимость функциональных изменений в программной системе неизбежна, а не является следствием неполного или неправильного анализа требований или плохого программирования. Они заявляют, что существуют пределы того, что команда разработчиков программного обеспечения может достичь с точки зрения безопасного внедрения изменений и новых функций.
Модели зрелости, характерные для эволюции программного обеспечения, были разработаны для улучшения процессов и помогают обеспечить постоянное обновление программного обеспечения по мере его итеративного развития [ необходима цитата ] .
«Глобальный процесс», осуществляемый многими заинтересованными сторонами (например, разработчиками, пользователями, их менеджерами), имеет множество циклов обратной связи. Скорость эволюции зависит от структуры контура обратной связи и других характеристик глобальной системы. Методы моделирования процессов, такие как системная динамика, могут быть полезны для понимания и управления такими глобальными процессами.
Эволюция программного обеспечения вряд ли будет дарвиновской , ламаркистской или балдвиновской , но сама по себе это важное явление. Учитывая растущую зависимость от программного обеспечения на всех уровнях общества и экономики, успешная эволюция программного обеспечения становится все более важной. Это важная тема исследования, которой не уделялось особого внимания.
Эволюция программного обеспечения из-за его быстрого пути по сравнению с другими созданными руками человека объектами была замечена Lehman как «плодовая муха» исследования эволюции искусственных систем.
Смотрите также
- Программная энтропия
- Меир М. Леман
- Дарвиновская эволюция
- Ламарковская эволюция
- Балдвинская эволюция
- Журнал программного обеспечения: эволюция и процесс
Доступные инструменты
Рекомендации
- ^ Фред Брукс , Мифический человеко-месяц . Аддисон-Уэсли , 1975 и 1995. ISBN 0-201-00650-2 и ISBN 0-201-83595-9 .
- ^ эдди; ref: Общие сведения об эволюции программного обеспечения с открытым исходным кодом Институт исследований программного обеспечения им. Уолта Скакки
- ^ Bennett, KH; Rajlich, VT; Мазрул, Р. Мохамад (1995). «Устаревшая система: как справиться с успехом». Программное обеспечение IEEE . С. 19–23.
- ^ Trung Hung Vo (2007), Сопровождение программного обеспечения
- ^ Бодри, Бенуа; Монперрус, Мартин; Мони, Сендрин; Шовель, Франк; Флери, Франк; Кларк, Шивон (2014). «РАЗНООБРАЗИТЬ: Эволюция программного обеспечения, вдохновленная экологией, для появления разнообразия». Неделя развития программного обеспечения 2014 г. - Конференция IEEE по сопровождению, реинжинирингу и обратному проектированию программного обеспечения (CSMR-WCRE) . С. 395–398. CiteSeerX 10.1.1.646.2786 . DOI : 10,1109 / csmr-wcre.2014.6747203 . ISBN 9781479937523. S2CID 2284072 .
- ^ Линц, Б.П. и Суонсон, Э.Б., Управление обслуживанием программного обеспечения, Исследование обслуживания программного обеспечения компьютерных приложений в 487 организациях, занимающихся обработкой данных . Аддисон-Уэсли, Рединг, Массачусетс, 1980. ISBN 0-201-04205-3
- ^ ISO / IEC 14764: 2006, 2006.
- ^ Пол Уоррен; Корнелия Болдырева; Малькольм Манро (1999). «Эволюция веб-сайтов». Материалы седьмого международного семинара по пониманию программ . IEEE. С. 178–185.
- ^ Нед Чапин; Джоан Э. Хейл; Халед Мад Хан; Хуан Ф. Рамиль; Уи-Ги Тан (2001). «Типы развития программного обеспечения и сопровождение программного обеспечения». Журнал сопровождения и развития программного обеспечения: исследования и практика . 13 (1): 3–30. DOI : 10.1002 / smr.220 .
- ^ Барбара Китченхэм; Гильерме Травассос; Аннелиз фон Майрхаузер; Фрэнк Ниссинк; Норман Шнайдвинд; Дженис Сингер; Синго Такада; Ристо Вехвилайнен; Хунцзи Ян (1999). «К онтологии сопровождения программного обеспечения». Журнал обслуживания программного обеспечения . 11 (6): 365–389. DOI : 10.1002 / (SICI) 1096-908X (199911/12) 11: 6 <365 :: AID-SMR200> 3.0.CO; 2-W . ЛВП : 10945/55140 .
- ^ Дирк Дериддер (2002). «Концептуально-ориентированный подход к поддержке деятельности по обслуживанию и повторному использованию программного обеспечения». Труды 5-й совместной конференции по разработке программного обеспечения, основанного на знаниях .
- ^ Аврора Вискайно; Хесус Фавела; Марио Пиаттини (2003). «Многоагентная система управления знаниями при сопровождении программного обеспечения». Интеллектуальные информационные и инженерные системы, основанные на знаниях . Springer. С. 415–421.
- ^ Марсио Диас; Николя Анкетиль; Катия де Оливейра (2003). «Организация знаний, используемых при обслуживании программного обеспечения». Журнал универсальных компьютерных наук . 9 (7): 641–658.
- ^ Франсиско Руис; Аврора Вискайно; Марио Пиаттини; Феликс Гарсия (2004). «Онтология для управления проектами сопровождения программного обеспечения» . Международный журнал программной инженерии и инженерии знаний . 14 (3): 323–349. DOI : 10.1142 / S0218194004001646 . S2CID 15592498 .
- ^ а б в г д е Беннетт, Кейт; Райлих, Вацлав (01.07.2000). «Поэтапная модель жизненного цикла программного обеспечения» (PDF) . Компьютер . Компьютерное общество IEEE. 33 (7): 66–71. DOI : 10.1109 / 2.869374 . S2CID 7547412 . Проверено 23 мая 2020 .CS1 maint: дата и год ( ссылка )
- ^ а б в г д Леман, ММ (1980). «О понимании законов, эволюции и сохранения в жизненном цикле больших программ». Журнал систем и программного обеспечения . 1 : 213–221. DOI : 10.1016 / 0164-1212 (79) 90022-0 .
- ^ Законы Лемана эволюции программного обеспечения
- ^ Нарендра, Нанджангуд (29 апреля 2011 г.). «Эволюция программного обеспечения в гибкой разработке» . InfoQ . Проверено 19 марта +2016 .
дальнейшее чтение
- Андреа Капилуппи, Хесус М. Гонсалес Бараона, Исраэль Херрайс, Грегорио Роблес, Адаптация «Поэтапной модели эволюции программного обеспечения» к FLOSS
- Марк К. Полк, История программного обеспечения модели зрелости возможностей