Эволюция программного обеспечения
Эта статья может сбивать с толку или быть непонятной читателям . В частности, введение написано с неясной грамматикой и не дает адекватного обзора темы. ( февраль 2020 г. ) |
Эволюция программного обеспечения — это непрерывная разработка части программного обеспечения после его первоначального выпуска с учетом меняющихся требований заинтересованных сторон и/или рынка. Эволюция программного обеспечения важна, поскольку организации вкладывают в свое программное обеспечение большие суммы денег и полностью зависят от него. Эволюция программного обеспечения помогает программному обеспечению адаптироваться к меняющимся требованиям бизнеса, исправлять дефекты и интегрироваться с другими меняющимися системами в среде программной системы.
Общее введение [ править ]
Фред Брукс в своей ключевой книге «Мифический человеко-месяц » [1] заявляет, что более 90% затрат на типичную систему приходится на этап обслуживания, и что любое успешное программное обеспечение неизбежно будет поддерживаться.
Фактически, Agile-методы основаны на действиях, подобных техническому обслуживанию, в веб-технологиях и вокруг них, где основная часть возможностей исходит из фреймворков и стандартов. [ нужна ссылка ]
Сопровождение программного обеспечения направлено на исправление ошибок и незначительные улучшения, а эволюция программного обеспечения направлена на адаптацию и миграцию .
Программные технологии будут продолжать развиваться. Эти изменения потребуют создания и обоснования новых законов и теорий. Некоторые модели также потребуют дополнительных аспектов при разработке будущих программ. Инновации и улучшения действительно расширяют неожиданные формы разработки программного обеспечения. Проблемы сопровождения также, вероятно, изменятся, чтобы адаптироваться к развитию будущего программного обеспечения. Программные процессы сами по себе развиваются, проходя обучение и усовершенствования, они всегда повышают свою эффективность и результативность. [2]
Основные понятия [ править ]
Необходимость в эволюции программного обеспечения обусловлена тем фактом, что никто не может априори предсказать, как будут развиваться требования пользователей . [3] Другими словами, существующие системы никогда не являются завершенными и продолжают развиваться. [4] По мере развития сложность систем будет расти, если не будет лучшего решения для решения этих проблем. Основными задачами эволюции программного обеспечения являются обеспечение функциональной актуальности, надежности и гибкости системы. Эволюция программного обеспечения может быть полностью ручной (на основе изменений, внесенных разработчиками программного обеспечения), частично автоматизированной (например, с использованием инструментов рефакторинга) или полностью автоматизированной.
На эволюцию программного обеспечения большое влияние оказал Интернет:
- Быстрый рост Всемирной паутины и интернет-ресурсов облегчает пользователям и инженерам поиск соответствующей информации.
- Разработка открытого исходного кода, где каждый мог загрузить исходные коды и, следовательно, изменить их, обеспечила быструю и параллельную эволюцию (через форки).
Виды обслуживания программного обеспечения [ править ]
Э.Б. Суонсон первоначально определил три категории технического обслуживания: корректирующее, адаптивное и совершенное. Затем Лиентц и Свенсон (1980) каталогизировали четыре категории программного обеспечения. [5] С тех пор они были обновлены и нормализованы на международном уровне в стандарте ISO/IEC 14764:2006: [6]
- Корректирующее обслуживание : реактивная модификация программного продукта, выполняемая после поставки для устранения обнаруженных проблем;
- Адаптивное обслуживание : Модификация программного продукта, выполняемая после поставки, чтобы сохранить возможность использования программного продукта в изменившейся или изменяющейся среде;
- Совершенное обслуживание : Модификация программного продукта после поставки для улучшения производительности или удобства сопровождения;
- Профилактическое обслуживание : Модификация программного продукта после поставки для обнаружения и исправления скрытых ошибок в программном продукте до того, как они станут действительными ошибками.
Все вышеперечисленное имеет место, когда существует известная потребность в изменении.
Хотя эти категории были дополнены многими авторами, такими как Warren et al. (1999) [7] и Чапин (2001), [8] международный стандарт ISO/IEC 14764:2006 сохранил четыре основные категории.
Совсем недавно описание сопровождения и развития программного обеспечения было выполнено с использованием онтологий ( Китченхэм и др. (1999), [9] Дериддер (2002), [10] Вискайно (2003), [11] Дни (2003), [12] и Руис (2004) [13] ), которые обогащают описание многих эволюционных действий.
Сценическая модель [ править ]
Текущие тенденции и практики прогнозируются с использованием новой модели эволюции программного обеспечения, называемой поэтапной моделью. [14] Поэтапная модель была введена для замены традиционного анализа, который менее подходит для современной разработки программного обеспечения и быстро меняется из-за трудностей, с которыми трудно внести вклад в эволюцию программного обеспечения. В простой поэтапной модели есть пять различных этапов (начальная разработка, эволюция, обслуживание, поэтапный вывод и закрытие).
- По мнению К. Х. Беннета и В. Т. Райлиха, [14] Ключевой вклад заключается в том, чтобы разделить этап «технического обслуживания» на этап развития, за которым следуют этапы обслуживания и поэтапного вывода из эксплуатации. Первая версия программной системы, в которой отсутствуют некоторые функции, будет разработана на начальной стадии разработки или также известна как альфа-стадия. [14] Однако архитектура, уже созданная на этом этапе, приведет к любым будущим изменениям или поправкам. Большинство ссылок на этом этапе будут основаны на сценариях или тематических исследованиях. Знания определены как еще один важный результат первоначального развития. Такие знания, включая знание предметной области приложения, требований пользователей, бизнес-правил, политик, решений, алгоритмов и т. д. Знания также кажутся важным фактором для последующего этапа эволюции.
- После успешного завершения предыдущего этапа (и он должен быть успешно завершен перед переходом на следующий этап) следующим этапом будет эволюция. Пользователи склонны менять свои требования, а также предпочитают видеть некоторые улучшения или изменения. Из-за этого фактора индустрия программного обеспечения сталкивается с проблемами быстро меняющейся среды. Следовательно, целью эволюции является адаптация приложения к постоянно меняющимся требованиям пользователя и операционной среде. [14] На предыдущем этапе созданная первая версия приложения может содержать множество ошибок, и эти ошибки будут исправлены на этапе развития на основе более конкретных и точных требований в зависимости от тематического исследования или сценариев.
- Программное обеспечение будет постоянно развиваться до тех пор, пока оно не перестанет развиваться, а затем войдет в стадию обслуживания (также известную как зрелость программного обеспечения). На этом этапе будут внесены лишь незначительные изменения.
- На следующем этапе поэтапного прекращения обслуживания этого конкретного программного обеспечения больше не будет. Однако программное обеспечение все еще находится в производстве.
- Наконец, закрытие. Использование программного обеспечения отключено или прекращено. [14] и пользователи направлены на замену. [14]
Лемана эволюции Законы программного обеспечения
Профессор Меир М. Леман , работавший в Имперском колледже Лондона с 1972 по 2002 год, и его коллеги определили набор моделей поведения в эволюции несвободного программного обеспечения. Такое поведение (или наблюдения) известно как законы Лемана. Он называет системы Е-типа системами,написанный для выполнения какой-либо реальной деятельности. Поведение таких систем тесно связано со средой, в которой они работают, и такая система должна адаптироваться к изменяющимся требованиям и обстоятельствам в этой среде. Восемь законов таковы:
- (1974) «Продолжение изменений» - систему электронного типа необходимо постоянно адаптировать, иначе она станет все менее удовлетворительной. [15]
- (1974) «Повышение сложности» - по мере развития системы E-типа ее сложность увеличивается, если не проводится работа по ее поддержанию или уменьшению. [15]
- (1980) «Саморегулирование» - процессы эволюции системы электронного типа саморегулируются с распределением продуктов и показателей процесса, близким к нормальному. [15]
- (1978) «Сохранение организационной стабильности ( инвариантная скорость работы )» - средняя эффективная глобальная скорость активности в развивающейся системе E-типа инвариантна в течение всего срока службы продукта. [15]
- (1978) «Сохранение привычности» — по мере развития системы электронного типа все, кто с ней связан, например, разработчики, торговый персонал и пользователи, должны поддерживать владение ее содержанием и поведением для достижения удовлетворительного развития. Чрезмерный рост умаляет это мастерство. Следовательно, средний прирост остается неизменным по мере развития системы. [15]
- (1991) «Постоянный рост» - функциональное содержание системы электронного типа должно постоянно расширяться, чтобы поддерживать удовлетворенность пользователей на протяжении всего срока ее службы.
- (1996) «Снижение качества» - качество системы E-типа будет снижаться, если ее не будут тщательно поддерживать и адаптировать к изменениям операционной среды.
- (1996) «Система обратной связи» (впервые заявлена в 1974 году, официально оформлена в виде закона в 1996 году) — процессы эволюции электронного типа представляют собой многоуровневые, многоконтурные, многоагентные системы обратной связи и должны рассматриваться как таковые для достижения значительного улучшения по сравнению с любыми разумными системами обратной связи. база [16]
Стоит отметить, что применимость всех этих законов для всех типов программных систем изучалась несколькими исследователями. Например, см. презентацию Нанджангуда К. Нарендры. [17] где он описывает тематическое исследование корпоративного Agile-проекта в свете законов эволюции программного обеспечения Лемана. Некоторые эмпирические наблюдения, полученные в результате изучения разработки программного обеспечения с открытым исходным кодом, по-видимому, бросают вызов некоторым законам. [ нечеткий ] [ нужна ссылка ] .
Законы предсказывают, что необходимость функциональных изменений в программной системе неизбежна, а не является следствием неполного или неправильного анализа требований или плохого программирования. Они заявляют, что существуют пределы того, чего может достичь команда разработчиков программного обеспечения с точки зрения безопасного внедрения изменений и новых функций.
Модели зрелости, специфичные для эволюции программного обеспечения, были разработаны для улучшения процессов и помогают обеспечить постоянное обновление программного обеспечения по мере его итеративной эволюции. [ нужна ссылка ] .
«Глобальный процесс», осуществляемый многими заинтересованными сторонами (например, разработчиками, пользователями, их менеджерами), имеет множество контуров обратной связи. Скорость эволюции является функцией структуры петли обратной связи и других характеристик глобальной системы. Методы моделирования процессов, такие как системная динамика, могут быть полезны для понимания и управления такими глобальными процессами.
Эволюция программного обеспечения вряд ли будет дарвиновской , ламарковской или болдуинской , а является важным явлением сама по себе. Учитывая растущую зависимость от программного обеспечения на всех уровнях общества и экономики, успешная эволюция программного обеспечения становится все более важной. Это важная тема исследований, которой не уделялось особого внимания.
Эволюция программного обеспечения из-за ее быстрого пути по сравнению с другими искусственными объектами рассматривалась Леманом как «дрозофила» в изучении эволюции искусственных систем.
См. также [ править ]
- Энтропия программного обеспечения
- Меир М. Леман
- Дарвиновская эволюция
- Ламаркианская эволюция
- Болдуинская эволюция
- Журнал программного обеспечения: эволюция и процесс
Доступные инструменты [ править ]
- LibVCS4j Библиотека Java, которая позволяет существующим инструментам анализировать эволюцию программных систем, предоставляя общий API для различных систем контроля версий и средств отслеживания проблем.
Ссылки [ править ]
- ^ Фред Брукс , Мифический человеко-месяц . Аддисон-Уэсли , 1975 и 1995. ISBN0-201-00650-2 и ISBN 0-201-83595-9 .
- ^ Эдди; ссылка: Понимание эволюции программного обеспечения с открытым исходным кодом Институт исследований программного обеспечения Уолта Скакки
- ^ Беннетт, К.Х.; Райлих, В.Т.; Мазрул, Р. Мохамад (1995). «Устаревшая система: как добиться успеха». Программное обеспечение IEEE . стр. 19–23.
- ^ Трунг Хунг Во (2007), Обслуживание программного обеспечения
- ^ Лиенц, Б.П. и Суонсон, Э.Б., Управление обслуживанием программного обеспечения, Исследование обслуживания компьютерного прикладного программного обеспечения в 487 организациях по обработке данных . Аддисон-Уэсли, Ридинг, Массачусетс, 1980. ISBN 0-201-04205-3
- ^ ИСО/МЭК 14764:2006, 2006.
- ^ Пол Уоррен; Корнелия Болдырева; Малкольм Манро (1999). «Эволюция веб-сайтов». Материалы Седьмого международного семинара по пониманию программ . IEEE. стр. 178–185.
- ^ Нед Чапин; Джоан Э. Хейл; Халед Мд Хан; Хуан Ф. Рамиль; Уи-Ги Тан (2001). «Типы эволюции программного обеспечения и сопровождения программного обеспечения». Журнал обслуживания и развития программного обеспечения: исследования и практика . 13 (1): 3–30. дои : 10.1002/смр.220 .
- ^ Барбара Китченхем ; Гильерме Травасос; Аннелиза фон Майрхаузер; Фрэнк Ниссинк; Норман Шнайдевинд; Дженис Сингер; Синго Такада; Ристо Вехвилайнен; Хунцзи Ян (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 .
- ^ Дирк Дериддер (2002). «Концептуально-ориентированный подход к поддержке обслуживания и повторного использования программного обеспечения». Материалы 5-й совместной конференции по программной инженерии, основанной на знаниях .
- ^ Аврора Вискайно; Хесус Фавела; Марио Пьяттини (2003). «Мультиагентная система управления знаниями в сопровождении программного обеспечения». Интеллектуальные информационные и инженерные системы, основанные на знаниях . Спрингер. стр. 415–421.
- ^ Марсио Диас; Николя Анкетиль; Катия де Оливейра (2003). «Организация знаний, используемых при сопровождении программного обеспечения». Журнал универсальной информатики . 9 (7): 641–658.
- ^ Франсиско Руис; Аврора Вискайно; Марио Пьяттини; Феликс Гарсиа (2004). «Онтология для управления проектами сопровождения программного обеспечения». Международный журнал программной инженерии и инженерии знаний . 14 (3): 323–349. дои : 10.1142/S0218194004001646 . S2CID 15592498 .
- ^ Jump up to: Перейти обратно: а б с д и ж Беннетт, Кейт; Райлих, Вацлав (1 июля 2000 г.). «Поэтапная модель жизненного цикла программного обеспечения» (PDF) . Компьютер . 33 (7). Компьютерное общество IEEE: 66–71. дои : 10.1109/2.869374 . S2CID 7547412 . Проверено 23 мая 2020 г.
{{cite journal}}
: CS1 maint: дата и год ( ссылка ) - ^ Jump up to: Перейти обратно: а б с д и Леман, ММ (1980). «О понимании законов, эволюции и сохранения в жизненном цикле большой программы». Журнал систем и программного обеспечения . 1 : 213–221. дои : 10.1016/0164-1212(79)90022-0 .
- ^ Законы эволюции программного обеспечения Лемана
- ^ Нарендра, Нанджангуд (29 апреля 2011 г.). «Эволюция программного обеспечения в гибкой разработке» . ИнфоQ . Проверено 19 марта 2016 г.
Дальнейшее чтение [ править ]
- Андреа Капилуппи, Хесус М. Гонсалес Бараона, Исраэль Херраис, Грегорио Роблес, адаптация «поэтапной модели эволюции программного обеспечения» к FLOSS
- Марк К. Полк, История программного обеспечения модели зрелости возможностей