소프트웨어 진화

Software evolution

소프트웨어 진화는 변화하는 이해관계자 및/또는 시장 요구사항을 해결하기 위해 초기 출시 후 소프트웨어가 지속적으로 개발되는 것이다.조직은 소프트웨어에 많은 돈을 투자하고 이 소프트웨어에 전적으로 의존하기 때문에 소프트웨어 진화가 중요하다.소프트웨어 진화는 소프트웨어가 변화하는 비즈니스 요구사항에 적응하고, 결함을 수정하며, 소프트웨어 시스템 환경의 다른 변화하는 시스템과 통합할 수 있도록 돕는다.

일반소개

Fred Brooks는 그의 주요 저서 The Mythonic Man-Month에서 전형적인 시스템 비용의 90% 이상이 유지 보수 단계에서 발생하며, 어떤 성공적인 소프트웨어라도 불가피하게 유지될 것이라고 말한다.[1]

사실, 신속한 변화를 위한 방법은 웹 기반 기술 내부와 주변에서 유지 보수와 같은 활동에서 비롯되며, 대부분의 기능은 프레임워크와 표준에서 비롯된다.[citation needed]

소프트웨어 유지보수는 버그 수정과 사소한 개선사항을 다루는 반면 소프트웨어 진화는 적응과 마이그레이션에 초점을 맞춘다.

소프트웨어 기술은 계속 발전할 것이다.이러한 변화들은 새로운 법과 이론을 만들고 정당화하도록 요구할 것이다.일부 모델도 미래 프로그램을 개발할 때 추가 측면이 필요할 수 있다.혁신과 개선은 예상치 못한 형태의 소프트웨어 개발을 증가시킨다.유지보수 문제 또한 미래 소프트웨어의 진화에 적응하기 위해 변경될 것이다.소프트웨어 프로세스는 그 자체로 진화하고 있으며, 학습과 정비를 거친 후에는 항상 효율성과 효율성을 향상시킨다.[2]

기본개념

소프트웨어 진화의 필요성은 사용자 요건이 어떻게 선험적으로 진화할 것인지 아무도 예측할 수 없다는 사실에서 비롯된다.[3]즉, 기존의 시스템은 결코 완전하지 않고 계속 진화하고 있는 것이다.[4]그들이 진화함에 따라, 이러한 문제들을 해결하기 위해 이용할 수 있는 더 나은 해결책이 없는 한 시스템의 복잡성은 커질 것이다.소프트웨어 진화의 주요 목표는 시스템의 기능적 관련성, 신뢰성 및 유연성을 보장하는 것이다.소프트웨어 진화는 완전 수동(소프트웨어 엔지니어에 의한 변경에 근거), 부분적으로 자동화(예: 리팩터링 도구 사용) 또는 완전 자동화(자율적인 구성이나 진화에[5] 의한)될 수 있다.

소프트웨어 진화는 인터넷의 영향을 크게 받았다.

  • 월드 와이드 웹과 인터넷 자원의 급속한 성장으로 사용자와 엔지니어가 관련 정보를 쉽게 찾을 수 있게 되었다.
  • 누구나 소스 코드를 다운로드하여 수정할 수 있는 오픈 소스 개발로 빠르고 병렬적인 진화가 가능해졌다.

소프트웨어 유지관리 유형

E.B. Swanson은 처음에 세 가지 유지보수 범주의 수정, 적응성, 완벽성을 확인했다.그 후 리엔츠와 스완슨(1980년)이 4가지 범주의 소프트웨어를 분류했다.[6]이러한 사항은 이후 ISO/IEC 14764:2006에서 국제적으로 업데이트되고 표준화되었다.[7]

  • 고장 수리:발견된 문제를 해결하기 위해 전달 후 수행된 소프트웨어 제품의 사후 대응적 수정
  • 적응형 유지 관리:소프트웨어 제품을 변경 또는 변경 환경에서 사용할 수 있도록 하기 위해 납품 후 수행되는 소프트웨어 제품의 수정
  • 완벽한 유지 관리:성능 또는 유지보수성 향상을 위한 소프트웨어 제품 제공 후 수정
  • 예방 유지 관리:소프트웨어 제품이 유효 결함이 되기 전에 소프트웨어 제품의 잠재적 결함을 감지하고 수정하기 위해 납품 후 소프트웨어 제품 수정.

앞의 모든 것은 알려진 변경 요건이 있을 때 일어난다.

이러한 범주는 워렌 외 연구진(1999),[8] 채핀(2001)과 같은 많은 저자에 의해 보완되었지만 ISO/IEC 14764:2006 국제 표준은 기본 4개 범주를 유지했다.[9]

보다 최근에는 소프트웨어 유지 및 진화에 대한 설명이 온톨로지(Kitchenham et al., (1999),[10] 데리더(2002),[11] 비즈카이노(2003),[12] 디아스(2003),[13] 루이즈(2004)를 사용하여 수행되어 많은 진화 활동에 대한 설명을 풍부하게 하고 있다.[14]

스테이지 모델

현재 추세와 관행은 단계적 모델이라 불리는 소프트웨어 진화의 새로운 모델을 사용하여 앞으로 예측된다.[15]스테이지 모델은 소프트웨어 진화에 기여하기 어려워 현대 소프트웨어 개발에 적합하지 않은 기존 분석을 대체하기 위해 도입됐다.간단한 단계별 모델(초기 개발, 진화, 서비스, 단계적 아웃, 클로즈다운)에는 5개의 뚜렷한 단계가 있다.

  • K.H.에 의하면.베넷과 브이T Rajlich,[15] 핵심 기여는 '유지보수' 단계를 진화 단계로 구분한 후 서비스 및 단계적 퇴치 단계를 수행하는 것이다.일부 기능이 부족한 소프트웨어 시스템의 첫 번째 버전은 초기 개발 중에 개발되거나 알파 단계로 알려져 있을 것이다.[15]그러나 이 단계에서 이미 보유된 아키텍처는 향후 어떤 변경이나 개정을 가져올 것이다.이 단계에서 대부분의 참조는 시나리오 또는 사례 연구를 기반으로 한다.지식은 초기 발전의 또 다른 중요한 결과로 정의되어 왔다.애플리케이션 도메인, 사용자 요구 사항, 비즈니스 규칙, 정책, 솔루션, 알고리즘 등의 지식을 포함하는 지식지식은 또한 진화의 후속 단계에 중요한 요소로 보인다.
  • 이전 단계가 성공적으로 완료되면(그리고 다음 단계로 진입하기 전에 성공적으로 완료되어야 함), 다음 단계는 진화일 것이다.사용자들은 일부 개선이나 변경을 보는 것을 선호할 뿐만 아니라 요구 사항도 변경하는 경향이 있다.이 때문에 소프트웨어 산업은 급변하는 환경의 도전에 직면해 있다.따라서 진화의 목표는 끊임없이 변화하는 사용자 요구 사항과 운영 환경에 애플리케이션을 적응시키는 것이다.[15]이전 단계에서 생성된 첫 번째 버전 애플리케이션은 많은 결함을 포함할 수 있으며, 그러한 결함은 사례 연구 또는 시나리오로 인해 보다 구체적이고 정확한 요건에 기초하여 진화 단계 중에 수정될 것이다.
  • 소프트웨어는 더 이상 진화가 가능하지 않을 때까지 지속적으로 진화한 후 서비스 단계(소프트웨어 성숙도라고도 한다)에 들어간다.이 단계에서는 사소한 변경만 할 것이다.
  • 단계적으로 폐지되는 다음 단계에서는 해당 특정 소프트웨어에 대해 더 이상 서비스를 이용할 수 없다.그러나 이 소프트웨어는 아직 생산 중이다.
  • 마지막으로 클로즈다운.소프트웨어 사용이 분리되거나 중단되고[15] 사용자는 교체 대상으로 향한다.[15]

리먼의 소프트웨어 진화 법칙

주요 기사:리먼의 소프트웨어 진화 법칙

메이르 M 교수 1972년부터 2002년까지 임페리얼 칼리지 런던에서 일했던 리먼과 그의 동료들은 독점 소프트웨어의 진화에서 일련의 행동을 확인했다.이러한 행동(또는 관찰)은 리먼의 법칙으로 알려져 있다.그는 E-type 시스템을 어떤 실제 활동을 수행하기 위해 쓰여진 시스템이라고 언급한다.그러한 시스템의 동작은 그것이 실행되는 환경과 강하게 연결되어 있으며, 그러한 시스템은 그 환경의 다양한 요건과 상황에 적응할 필요가 있다.8개 법률은 다음과 같다.

  1. (1974) "계속 변화" — E형 시스템을 지속적으로 개조하거나 점차적으로 만족도가[16] 떨어지도록 해야 한다.
  2. (1974) "복잡성 증가" — E형 시스템이 진화함에 따라, 이를[16] 유지하거나 감소시키기 위한 작업이 수행되지 않는 한 복잡성은 증가한다.
  3. (1980) "자체 규제" — E형 시스템 진화 프로세스가 제품 및 공정 조치의 분포와 함께 정상과[16] 가까운 수준으로 자체 규제됨
  4. (1978) "조직적 안정성의 보존(불변속 작업률)" - 진화하는 E-type 시스템의 평균 유효 전역 활동률은 제품 수명[16] 동안 변하지 않는다.
  5. (1978) "친숙함의 보존" — E형 시스템이 진화함에 따라, 그것과 관련된 모든 것, 예를 들어 개발자, 판매 직원 및 사용자는 만족스러운 진화를 달성하기 위해 내용과 행동에 대한 숙달성을 유지해야 한다.과도한 성장은 그 숙달성을 감소시킨다.따라서 시스템이 진화함에 따라 평균 증분 성장은 변하지 않는다.[16]
  6. (1991) "계속 성장" — E-type 시스템의 기능 콘텐츠를 지속적으로 증가시켜 수명 동안 사용자 만족도를 유지해야 한다.
  7. (1996) "품질 저하" — E형 시스템의 품질은 엄격하게 유지되고 운영 환경 변화에 적응하지 않는 한 저하되는 것으로 보일 것이다.
  8. (1996) "피드백 시스템(Feedback System)" (1974년 처음 명시, 1996년 법률로 공식화됨) — E형 진화 프로세스는 다단계, 다중 루프, 다중 에이전트 피드백 시스템을 구성하며, 합리적인 기반에[17] 걸쳐 상당한 개선을 달성할 수 있도록 취급되어야 한다.

모든 종류의 소프트웨어 시스템에 대한 이 모든 법률의 적용가능성은 여러 연구자들에 의해 연구되었다는 것을 언급할 필요가 있다.예를 들어, 그가 리먼의 소프트웨어 진화 법칙에 비추어 엔터프라이즈 애자일 프로젝트의 사례 연구를 설명하는 난장구드 C 나렌드라의[18] 프레젠테이션을 참조하십시오.오픈 소스 소프트웨어 개발 연구에서 나온 일부 경험적 관찰은 일부 법률에[vague][citation needed] 도전하는 것처럼 보인다.

이 법은 소프트웨어 시스템의 기능적 변화의 필요성이 불가피하며, 요건의 불완전하거나 부정확한 분석이나 불량 프로그래밍의 결과가 아니라고 예측한다.그들은 소프트웨어 개발팀이 안전하게 변경과 새로운 기능을 구현한다는 측면에서 달성할 수 있는 것에는 한계가 있다고 말한다.

소프트웨어 진화에 특화된 성숙도 모델은 프로세스를 개선하고 반복적으로[citation needed] 진화하면서 소프트웨어의 지속적인 회생을 보장하도록 개발되었다.

많은 이해관계자(예: 개발자, 사용자, 관리자)가 만드는 "글로벌 프로세스"는 많은 피드백 루프를 가지고 있다.진화 속도는 피드백 루프 구조와 글로벌 시스템의 다른 특징들의 기능이다.시스템 역학과 같은 프로세스 시뮬레이션 기법은 그러한 글로벌 프로세스를 이해하고 관리하는 데 유용할 수 있다.

소프트웨어 진화는 다윈, 라마르크, 볼드위니안이 아니라 그 자체로 중요한 현상일 가능성이 높다.사회와 경제의 모든 수준에서 소프트웨어에 대한 의존도가 증가하고 있다는 점을 감안할 때, 소프트웨어의 성공적인 진화는 점점 더 중요해지고 있다.이것은 별로 주목받지 못한 중요한 연구 주제다.

소프트웨어의 진화는, 다른 인공적인 실체들에 비해 그것의 빠른 경로 때문에, 리먼에 의해 인공 시스템의 진화에 관한 연구의 "과일파리"로 여겨졌다.

참고 항목

사용 가능한 도구

  • LibVCS4j 다른 버전 제어 시스템에 공통 API를 제공하고 추적기를 발행하여 기존 툴이 소프트웨어 시스템의 진화를 분석할 수 있도록 하는 자바 라이브러리.

참조

  1. ^ '신화의 달' 프레드 브룩스야애디슨 웨슬리, 1975년 1995년ISBN 0-201-00650-2 & ISBN0-201-83595-9.
  2. ^ Aeddy; ref: 오픈 소스 소프트웨어 에볼루션의 이해 Walt Scacchi Institute for Software Research
  3. ^ Bennett, K. H.; Rajlich, V. T.; Mazrul, R. Mohamad (1995). "Legacy System: Coping with success". IEEE Software. pp. 19–23.
  4. ^ Trung Hung Vo (2007), Software Maintenance
  5. ^ Baudry, Benoit; Monperrus, Martin; Mony, Cendrine; Chauvel, Franck; Fleurey, Franck; Clarke, Siobhan (2014). "DIVERSIFY: Ecology-inspired software evolution for diversity emergence". 2014 Software Evolution Week - IEEE Conference on Software Maintenance, Reengineering, and Reverse Engineering (CSMR-WCRE). pp. 395–398. CiteSeerX 10.1.1.646.2786. doi:10.1109/csmr-wcre.2014.6747203. ISBN 9781479937523. S2CID 2284072.
  6. ^ Lientz, B.P. 및 Swanson, E.B., 소프트웨어 유지관리, 487 데이터 처리 조직의 컴퓨터 응용 소프트웨어 유지관리에 관한 연구1980년 레딩 MA 애디슨 웨슬리ISBN 0-201-04205-3
  7. ^ ISO/IEC 14764:2006, 2006.
  8. ^ Paul Warren; Cornelia Boldyreff; Malcolm Munro (1999). "The evolution of websites". Proceedings of the Seventh International Workshop on Program Comprehension. IEEE. pp. 178–185.
  9. ^ Ned Chapin; Joanne E Hale; Khaled Md Khan; Juan F Ramil; Wui-Gee Tan (2001). "Types of software evolution and software maintenance". Journal of Software Maintenance and Evolution: Research and Practice. 13 (1): 3–30. doi:10.1002/smr.220.
  10. ^ Barbara Kitchenham; Guilherme Travassos; Anneliese von Mayrhauser; Frank Niessink; Norman Schneidewind; Janice Singer; Shingo Takada; Risto Vehvilainen; Hongji Yang (1999). "Towards an ontology of software maintenance". Journal of Software Maintenance: Research and Practice. 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.
  11. ^ Dirk Deridder (2002). "A concept-oriented approach to support software maintenance and reuse activities". Proceedings of the 5th Joint Conference on Knowledge Based Software Engineering.
  12. ^ Aurora Vizcaíno; Jesús Favela; Mario Piattini (2003). "A multi-agent system for knowledge management in software maintenance". Knowledge-Based Intelligent Information and Engineering Systems. Springer. pp. 415–421.
  13. ^ Márcio Dias; Nicolas Anquetil; Káthia de Oliveira (2003). "Organizing the knowledge used in software maintenance". Journal of Universal Computer Science. 9 (7): 641–658.
  14. ^ Francisco Ruiz; Aurora Vizcaíno; Mario Piattini; Félix García (2004). "An ontology for the management of software maintenance projects". International Journal of Software Engineering and Knowledge Engineering. 14 (3): 323–349. doi:10.1142/S0218194004001646. S2CID 15592498.
  15. ^ a b c d e f Bennett, Keith; Rajlich, Václav (2000-07-01). "A Staged Model for the Software Life Cycle" (PDF). Computer. IEEE Computer Society. 33 (7): 66–71. doi:10.1109/2.869374. S2CID 7547412. Retrieved 2020-05-23.{{cite journal}}: CS1 maint: 날짜 및 연도(링크)
  16. ^ a b c d e Lehman, M. M. (1980). "On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle". Journal of Systems and Software. 1: 213–221. doi:10.1016/0164-1212(79)90022-0.
  17. ^ 리먼의 소프트웨어 진화 법칙
  18. ^ Narendra, Nanjangud (29 April 2011). "Software Evolution in Agile Development". InfoQ. Retrieved 19 March 2016.

추가 읽기

  • 안드레아 카필루피, 예수 M.곤잘레스 바라호나, 이스라엘 헤라이즈, 그레고리오 로블레스, "소프트웨어 진화를 위한 스테이징 모델"을 FLOS에 적용
  • Mark C. Paulk, Capability Model Software의 역사