SW 유지보수
- SW에 대해 추가/수정 개발이 이루어지게 되는데 그 과정에서 해당 SW는 어떤 일정한 패턴을 보이며 변화하고 진화하다는 논리가 바로 'Lehman의 SW 변화 원리'
리먼의 SW 변화법칙
- 사용자 요구에 따른 SW의 계속적인 변경 시, SW 변화 관리 및 유지 관리를 위하여 활용하는 소프트웨어 변화의 법칙
- 중요성
소프트웨어 변화의 특성을 제대로 이해하고, 유지보수, 변경관리, 형상관리, 품질통제의 중요
모델로 반영할 수 있으므로 효과적인 유지보수 및 변화관리가 가능하다.
소프트웨어 변화의 특성을 반영하여 SW 조직(People), 프로세스(Process), 기술(Technology)에 반영하여
Baseline유지, CCB구성, 인력고도화, 버전관리 등을 설계하는 중요 원리로 사용할 수 있다.
변화 법칙
- Continuing Change (계속적 변경)
소프트웨어는 지속적으로 변경의 요청을 받는다. 이때 새로 개발하는 것보다는 수정하는 것이 경제적이라고 판단되는 동안은 변경을 가한다. - Increasing Complexity (복잡성 증가)
소프트웨어는 변경이 가해질 수록 그 구조는 복잡해진다. - Program Evolution(프로그램 진화)
프로그램 별 변경되는 고유 패턴/추세 가 있다. - Organizational Stability (조직적 안정)
개발 생산성이 변화에 민감하지 않고 안정적임. 즉 작업량에 큰 변화가 없음 - Conservation of Familiarity (친근성 유지)
소프트웨어 각 버전의 변화는 일정하다. 소프트웨어는 규칙적인 수행 결과와 추이 보여주기 때문에 예측 가능 - Continuing Growth(지속적 성장)
SW 생애주기동안, 사용자 만족 유지 위해 기능의 지속적 성장 - Declining Quality (품질 감소)
변화 지속 기능 증가, 품질 저하 -> 레거시
엄격하게 관리/운영되지 않거나, 환경 변화에 미적응 시, 품질 감소 - Feedback System (피드백 시스템)
진화 프로세스는 다중레벨, 다중루프, Multi-Agent 피드백 시스템 수용, 중요 개선 달성 위해 피드백 필수
결론
- 한정적인 리소스 내에서 SW 개발/수정 요청을 어떻게 하면 효율적으로 운영/처리할지에 대한 것으로 지금까지 나왔던 기술부채, 레거시의 연장선
하자보증
- 소프트웨어(SW)산업진흥법에 명시된 내용으로 소프트웨어사업자는 국가기관등과 소프트웨어사업 계약을 체결한 경우 사업을 종료한 날부터 1년 이내의 범위에서 발생한 하자에 대해 담보책임이 있다.
유지보수 4가지 유형
수정 유지보수(corrective maintenance) : 잘못된 것을 수정하는 유지보수
적응 유지보수(adaptive maintenance) : 시스템을 새로운 환경에 적응시키는 유지보수
완전 유지보수(perfective maintenance) : 새로운 기능을 추가하거나 개선하는 유지보수
예방 유지보수(preventive maintenance) : 미래의 시스템 관리를 하는 유지보수
유지보수가 왜 중요할까?
소프트웨어도 유지보수가 필요하다. 특히 소프트웨어는 하드웨어라는 자원 위에서 동작되기 때문에 자원 상태도 매순간 체크가 되어야 한다. 유지보수를 한다는 것이 단순히 하자를 수정하는 것도 있겠지만, 이런식으로 운영 관점에서 영속성을 계속되게 하기 위한 노력인 측면이 있다. 그리고 유지보수에는 프로세스가 필요하다. 왜냐면 유지보수라는 것은 기본적으로 동작되고 있는 것이 더 나아지거나 개선되거나 고쳐지게 하는 것이다. 개발때에는 다시 개발을 할 수 있는 여지가 있다. 개발 후에 테스트 기간도 별도로 있고, 수정할 수 있는 시간도 가진다. 유지보수 시는 운영 시점이다. 유지보수 후에 바로 다시 정상 동작이 되어야 한다.
- 우리 관점에서는 결제 시스템은 지속적으로 가맹점/원천사의 요청사항이 인입되기에 이를 히스토리를 통해 관리해야하고 이런 개발 요청사항에 대해 빠르게 적용하고 정상 동작할 수 있도록 해야되기 때문
ATM