Lehman 소프트웨어 변화

I. 변화 관리와 유지보수 핵심, Lehman 소프트웨어 변화

가. Lehman 소프트웨어 변화 원리

• 소프트웨어는 요구에 의해 계속적으로 변경되며, 변경에 따른 복잡성, 프로그램의 고유한 변경 추세, SW조직 생산성의 일관성, 소프트웨어 각 버전의 변화에 대한 일관성을 제시한 SW 변화의 원리

나. Lehman 소프트웨어 변화 원리 특징

• 소프트웨어 변화의 특성을 이해하고 유지보수, 변경관리, 형상관리, 품질통제의 중요 모델로 반영
• 소프트웨어 변화의 특성을 반영하여 SW 조직(People), 프로세스(Process), 기술(Technology)에 반영 하여 Baseline 유지, CCB구성, 인력고도화, 버전관리 등을 설계하는 중요 원리로 사용

다. SW 변화(진화) 프로세스

• 내,외부 변화를 인식하고 파급력(Risk)를 분석하여 요구사항 반영 과정

II. Lehman 소프트웨어 변화 원리의 주요 내용 및 적용 방안

가. Lehman 소프트웨어 변화 원리 주요내용

구분	세부내용
계속적 변경 Continuing change	– 소프트웨어는 계속 진화하며 요구사항에 의해 계속 변경 – 변화는 지속되기 때문에 S/E적 관리가 필요함 – 소프트웨어는 자체적 갱신 불가하며 인간 의지 개입 필요 – 다시 만드는 것보다 경제적이라고 판단되는 한 계속 변화 – 아키텍처의 무결성이 훼손되거나 서비스 패치에 대한 비용이 많이 발생할때 마이그레이션이나 리엔지니어링을 고려
복잡도증가 Increasing complexity	– 변경이 가해질수록 구조는 복잡해짐 – 시스템의 복잡도는 이를 그대로 유지하거나 줄이고자 하는 특별한 작업을 하지 않는 한 계속 증가된다.
대규모 프로그램 진화 Program evolution	– 프로그램 별로 변경되는 사항은 고유한 패턴/추세가 있음 – 변화Size, Release, Interval, Error 건수 – 복잡성을 단순화 시키려는 인간 의지의 개입
Organizational Stability	– 조직의 생산성이 조직 변화에 민감하지 않음 – 개인의 생산성을 최적화 하는 것이 팀의 생산성을 최적화 하는데 필수적이지 않음
Conservation of Familiarity	– 소프트웨어의 각 버전의 변화는 일정함 – 소프트웨어는 규칙적인 수행결과와 추이를 보여주기 때문에 계측 가능
Continuing Growth	– 소프트웨어의 Lifetime 내내, 기능 내용은 사용자 만족도를 유지하기 위해 증가가 계속됨(1991년 내용추가)
Declining Quality	– 변화가 지속되면서 기능은 증가하지만 품질은 저하됨 – 소프트웨어는 엄격하게 관리 및 운영되지 않거나, 환경 변화에 적응 하지 않는다면 품질은 감소함(1996년 추가)
Feedback System	– 피드백 형식으로 변화가 지속됨 – 진화 프로세스는 다중레벨, 다중루프, Multi-Agent 피드백 시스템을 수용하고 중요한 제품개선을 달성하기 위해 소프트웨어를 피드백으로 구성되어야 함(1996년 추가)

나. Lehman 소프트웨어 변화 원리와 SW Lifecycle 연장을 위한 유지보수 분류

다. Lehman 소프트웨어 변화 원리에 대한 적용방안

• Baseline을 기반으로 안정성 추구, 성능개선 등을 통해 사용자 만족도 향상
   

III. Lehman 소프트웨어 변화 원리 적용 고려사항

• 유지보수는 Baseline(기준선)을 기반으로 안정성을 추구하나 성능개선, 예방유지보수, 리팩토링(Refactoring) 활동을 수행하여 안정성과 더불어 효과성, 사용자 만족성을 높이는 활동을 병행해야 함
• Increasing Complexity의 원리에 따라 변경을 수행 후 회귀테스트(Regression Test)를 수행하여 Unit, Input Partition, Path, Data flow에 대한 검증을 통하여 복잡성 증가에 대한 품질 보증 활동 수행이 요구됨