Эволюция программного обеспечения

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

Общее введение

Фред Брукс в своей ключевой книге «Мифический человеко-месяц » ^[1] утверждает, что более 90% затрат на типичную систему возникают на этапе обслуживания, и что любая успешная часть программного обеспечения неизбежно будет поддерживаться.

Фактически, методы Agile берут начало в деятельности, связанной с обслуживанием веб-технологий, где основная часть возможностей исходит от фреймворков и стандартов. ^{[ необходима цитата ]}

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

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

Основные понятия

Необходимость в эволюции программного обеспечения проистекает из того факта, что никто не может предсказать, как будут развиваться требования пользователей априори . ^[3] Другими словами, существующие системы никогда не бывают полными и продолжают развиваться. ^[4] По мере развития сложность систем будет расти, если только не будет лучшего решения для решения этих проблем. Главными целями эволюции программного обеспечения являются обеспечение функциональной релевантности, надежности и гибкости системы. Эволюция программного обеспечения может быть полностью ручной (на основе изменений, вносимых инженерами-программистами), частично автоматизированной (например, с использованием инструментов рефакторинга) или полностью автоматизированной.

Интернет оказал огромное влияние на эволюцию программного обеспечения:

• Быстрый рост Всемирной паутины и интернет-ресурсов облегчает пользователям и инженерам поиск соответствующей информации.

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

Типы обслуживания программного обеспечения

EB Swanson изначально выделил три категории обслуживания: корректирующее, адаптивное и перфектное. Затем Lientz и Swanson (1980) каталогизировали четыре категории программного обеспечения. ^[5] С тех пор они были обновлены и нормализованы на международном уровне в ISO/IEC 14764:2006: ^[6]

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

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

Хотя эти категории были дополнены многими авторами, такими как Уоррен и др. (1999) ^[7] и Чапин (2001), ^[8] международный стандарт ISO/IEC 14764:2006 сохранил четыре основные категории.

Совсем недавно описание поддержки и развития программного обеспечения выполнялось с использованием онтологий ( Китченхэм и др. (1999), ^[9] Дериддер (2002), ^[10] Вискайно (2003), ^[11] Диас (2003), ^[12] и Руис (2004) ^[13] ), которые обогащают описание многих видов деятельности по развитию.

Модель сцены

Текущие тенденции и практики проецируются вперед с использованием новой модели эволюции программного обеспечения, называемой поэтапной моделью. ^[14] Поэтапная модель была введена для замены традиционного анализа, который менее подходит для современной разработки программного обеспечения, которая быстро меняется из-за ее трудностей внесения вклада в эволюцию программного обеспечения. В простой поэтапной модели есть пять отдельных этапов (начальная разработка, эволюция, обслуживание, поэтапный отказ и закрытие).

• По мнению KHBennett и VT Rajlich ^[14] , ключевым вкладом является разделение фазы «обслуживания» на стадию развития, за которой следуют стадии обслуживания и поэтапного отказа. Первая версия программной системы, в которой отсутствуют некоторые функции, будет разработана на этапе начальной разработки или также известна как альфа-стадия. ^[14] Однако архитектура, уже созданная на этом этапе, принесет любые будущие изменения или поправки. Большинство ссылок на этом этапе будут основаны на сценариях или тематических исследованиях. Знания определяются как еще один важный результат начальной разработки. Такие знания включают знание области применения, требований пользователя, бизнес-правил, политик, решений, алгоритмов и т. д. Знания также кажутся важным фактором для последующей фазы эволюции.
• После успешного завершения предыдущего этапа (и его необходимо успешно завершить перед переходом на следующий этап) следующим этапом будет эволюция. Пользователи склонны менять свои требования, а также предпочитают видеть некоторые улучшения или изменения. Из-за этого фактора индустрия программного обеспечения сталкивается с проблемами быстро меняющейся среды. Следовательно, цель эволюции — адаптировать приложение к постоянно меняющимся требованиям пользователей и операционной среде. ^[14] На предыдущем этапе первая версия приложения, созданная, может содержать много ошибок, и эти ошибки будут исправлены на этапе эволюции на основе более определенных и точных требований из-за тематического исследования или сценариев.
• Программное обеспечение будет непрерывно развиваться до тех пор, пока оно не перестанет поддаваться развитию, а затем перейдет в стадию обслуживания (также известную как зрелость программного обеспечения). На этой стадии будут вноситься только незначительные изменения.
• Следующий этап, который является поэтапным прекращением, больше не будет доступно обслуживание для этого конкретного программного обеспечения. Тем не менее, программное обеспечение все еще находится в производстве.
• Наконец, закрытие. Использование программного обеспечения отключается или прекращается ^[14] , и пользователи направляются к замене. ^[14]

Законы Лемана об эволюции программного обеспечения

Профессор Меир М. Леман , работавший в Имперском колледже Лондона с 1972 по 2002 год, и его коллеги определили набор поведений в эволюции фирменного программного обеспечения. Эти поведения (или наблюдения) известны как законы Лемана. Он называет системы типа E теми, которые написаны для выполнения некоторой реальной деятельности. Поведение таких систем тесно связано со средой, в которой они работают, и такая система должна адаптироваться к изменяющимся требованиям и обстоятельствам в этой среде. Восемь законов таковы:

1. (1974) «Продолжающиеся изменения» — система типа E должна постоянно адаптироваться, иначе она станет все менее удовлетворительной ^[15]
2. (1974) «Увеличение сложности» — по мере развития системы типа E ее сложность увеличивается, если не предпринимать никаких действий по ее поддержанию или снижению ^[15]
3. (1980) «Саморегуляция» — процессы эволюции систем типа Е являются саморегулирующимися с распределением показателей продукта и процесса, близким к нормальному ^[15]
4. (1978) «Сохранение организационной стабильности (инвариантная скорость работы)» — средняя эффективная глобальная скорость активности в развивающейся системе типа E остается неизменной в течение всего срока службы продукта ^[15]
5. (1978) «Сохранение узнаваемости» — по мере развития системы типа E все, кто с ней связан, например, разработчики, торговый персонал и пользователи, должны поддерживать мастерство ее содержания и поведения, чтобы достичь удовлетворительной эволюции. Чрезмерный рост снижает это мастерство. Следовательно, средний прирост остается неизменным по мере развития системы. ^[15]
6. (1991) «Постоянный рост» — функциональное наполнение системы E-type должно постоянно увеличиваться для поддержания удовлетворенности пользователей на протяжении всего срока ее службы.
7. (1996) «Снижение качества» — качество системы типа E будет снижаться, если ее не поддерживать в надлежащем состоянии и не адаптировать к изменениям в условиях эксплуатации.
8. (1996) «Система обратной связи» (впервые заявлена ​​в 1974 году, формализована в виде закона в 1996 году) — процессы эволюции типа E представляют собой многоуровневые, многоконтурные, многоагентные системы обратной связи и должны рассматриваться как таковые для достижения значительного улучшения по сравнению с любой разумной базой ^[16]

Стоит отметить, что применимость всех этих законов для всех типов программных систем изучалась несколькими исследователями. Например, см. презентацию Нанджангуда С. Нарендры ^[17] , где он описывает пример корпоративного Agile-проекта в свете законов Лемана об эволюции программного обеспечения. Некоторые эмпирические наблюдения, полученные в ходе изучения разработки программного обеспечения с открытым исходным кодом, по- видимому, ставят под сомнение некоторые из законов ^{[ неопределенно ] [ необходима цитата ]} .

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

Модели зрелости, характерные для эволюции программного обеспечения, были разработаны для улучшения процессов и обеспечения постоянного обновления программного обеспечения по мере его итеративного развития ^{[ необходима ссылка ]} .

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

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

Эволюция программного обеспечения, ввиду ее быстрого развития по сравнению с другими созданными человеком сущностями, рассматривалась Леманом как «дрозофила» в изучении эволюции искусственных систем.

Смотрите также

• Энтропия программного обеспечения
• Меир М. Леман
• дарвиновская эволюция
• Ламарковская эволюция
• Эволюция Болдуина
• Журнал программного обеспечения: эволюция и процесс

Доступные инструменты

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

Ссылки

1. Фред Брукс , Мифический человеко-месяц . Addison-Wesley , 1975 и 1995. ISBN 0-201-00650-2 и ISBN  0-201-83595-9 .
2. aeddy; ссылка: Понимание эволюции программного обеспечения с открытым исходным кодом Институт исследований программного обеспечения Уолта Скакки
3. Беннетт, КХ; Райлих, ВТ; Мазрул, Р. Мохамад (1995). «Устаревшая система: как совладать с успехом». IEEE Software . С. 19–23.
4. Trung Hung Vo (2007), Техническое обслуживание программного обеспечения
5. Lientz, BP и Swanson, EB, Управление обслуживанием программного обеспечения, исследование обслуживания программного обеспечения компьютерных приложений в 487 организациях обработки данных . Addison-Wesley, Reading MA, 1980. ISBN 0-201-04205-3 
6. ИСО/МЭК 14764:2006, 2006.
7. Пол Уоррен; Корнелия Болдырефф; Малкольм Манро (1999). «Эволюция веб-сайтов». Труды Седьмого международного семинара по пониманию программ . IEEE. С. 178–185.
8. Нед Чапин; Джоан Э. Хейл; Халед Мд Хан; Хуан Ф. Рамил; Вуй-Джи Тан (2001). «Типы эволюции программного обеспечения и обслуживания программного обеспечения». Журнал обслуживания и эволюции программного обеспечения: исследования и практика . 13 (1): 3–30. doi :10.1002/smr.220.
9. Барбара Китченхэм ; Гильерме Травассос; Аннелиза фон Майрхаузер; Фрэнк Ниссинк; Норман Шнайдевинд; Дженис Сингер; Синго Такада; Ристо Вехвилайнен; Хунцзи Ян (1999). «К онтологии обслуживания программного обеспечения». Журнал обслуживания программного обеспечения: исследования и практика . 11 (6): 365–389. doi : 10.1002/(SICI)1096-908X(199911/12)11:6<365::AID-SMR200>3.0.CO;2-W . hdl : 10945/55140 .
10. Дирк Дериддер (2002). «Концептуально-ориентированный подход к поддержке обслуживания и повторного использования программного обеспечения». Труды 5-й Объединенной конференции по программной инженерии на основе знаний .
11. Аврора Вискайно; Хесус Фавела; Марио Пьяттини (2003). «Многоагентная система для управления знаниями в обслуживании программного обеспечения». Интеллектуальные информационные и инженерные системы на основе знаний . Springer. С. 415–421.
12. Марсио Диас; Николя Анкетиль; Катия де Оливейра (2003). «Организация знаний, используемых при сопровождении программного обеспечения». Журнал универсальной информатики . 9 (7): 641–658.
13. Франциско Руис; Аврора Вискайно; Марио Пьяттини; Феликс Гарсия (2004). «Онтология для управления проектами по обслуживанию программного обеспечения». Международный журнал по программной инженерии и инженерии знаний . 14 (3): 323–349. doi :10.1142/S0218194004001646. S2CID  15592498.
14. Беннетт, Кит; Райлих, Вацлав (2000-07-01). "Поэтапная модель жизненного цикла программного обеспечения" (PDF) . Компьютер . 33 (7). IEEE Computer Society: 66–71. doi :10.1109/2.869374. S2CID  7547412 . Получено 2020-05-23 .{{cite journal}}: CS1 maint: дата и год ( ссылка )
15. Lehman, MM (1980). «О понимании законов, эволюции и сохранения в жизненном цикле больших программ». Журнал систем и программного обеспечения . 1 : 213–221. doi :10.1016/0164-1212(79)90022-0.
16. Законы Лемана об эволюции программного обеспечения
17. Нарендра, Нанджангуд (29 апреля 2011 г.). «Эволюция программного обеспечения в гибкой разработке». InfoQ . Получено 19 марта 2016 г. .

Дальнейшее чтение

• Андреа Капилуппи, Хесус М. Гонсалес Бараона, Исраэль Херраис, Грегорио Роблес, адаптация «поэтапной модели эволюции программного обеспечения» к FLOSS
• Марк С. Полк, История модели зрелости возможностей программного обеспечения