[소프트웨어분석및설계🛠️] 12장 시스템 구현 및 운영
출처 : 강의 교안, 시스템분석설계 with 애자일 (생능출판사, 최은만)
1. 구현 및 운영 개요
1.1 시스템 구현 및 운영
1) 목적
- 최종 물리적 시스템 내역 ➡️ 작동되고 신뢰할만한 소프트웨어로 변환
- 수행된 작업의 문서화
- 현재와 향후 사용자들에게 도움 제공
2) 주요 활동
- 코딩, 테스팅, 설치
- 문서화, 사용자 교육, 지원
- 유지보수
1.2 코딩, 테스팅, 설치
- 코딩
- 물리적 설계 내역을 작동되는 컴퓨터 코드로 변환
- 산출물 : 코드, 프로그램 문서
- 테스팅
- 다양한 방법들로 코딩과 병행해서 수행 가능
- 산출물 : 테스트 시나리오 및 테스트 데이터, 프로그램과 시스템 테스팅 결과
- 설치
- 산출물 : 사용자 지침, 사용자 교육계획, 설치 및 전환 계획
1.3 시스템 문서화/교육 및 지원
- 시스템 문서화
- 생명주기 전 과정을 통해 정보시스템을 유지 관리할 정보시스템 인력 ➡️ 시스템 문서
- 시스템을 일상 업무에서 사용할 사람들 ➡️ 사용자 문서
- 사용자 교육 및 사용자 지원
- 교육기관을 통해 주로 상용 SW에 집중
- 산출물 : 사용자 교육 자료, 교육 계획(수업, 튜토리얼), 사용자 지원계획(온라인 도움말 등)
1.4 정보시스템 유지보수 과정
- 시스템 변경을 위해 SDLC의 초기 단계로 돌아가서 변경이 구현되기까지의 단계들을 반복하는 과정
- 4가지 주요 활동
- 유지보수요청 접수
- 요청 사항을 변경 사항으로 전환
- 변경 사항 설계
- 변경 사항 구현
- 산출물 : 새로운 버전의 소프트웨어 등
2. 소프트웨어 테스트
2.1 소프트웨어 테스트
- 소프트웨어 품질 ➡️ SW공학기법 적용 (결함 예방)
- 유입된 결함 제거 ➡️ 테스트 필수
- SW 테스트
- SW의 정확성을 확증하는 과정
- 결함이나 원치 않는 동작을 찾는 것
- SW 테스트의 목적 ; 개발된 소프트웨어의 신뢰성을 높이기 위한 작업
- 소프트웨어 내에 존재하는 오류 발견
- 소프트웨어 요구사항에 충족하는지 확인
- 소프트웨어 명세에 충족하는지 확인
- 소프트웨어 출시 이후 발생할 수 있는 결함을 예방
2.2 소프트웨어 테스트 유형
- 인스펙션(inspection)
- 프로그램 언어상의 예견되는 오류들에 대한 프로그램 코드를 참여자들이 직접 검사하는 테스팅 기법
- 코드 실행 없이 하는 산출물에 대한 동료검토(Peer Review) 활동
- 특정 언어에 대해 잘 알려진 오류들의 체크리스트를 검토하여 코드를 비교
- 소프트웨어 결함 중 60~90% 정도 발견 가능
- 정적 테스팅 vs. 동적테스팅
- 정적(static) 테스팅
- 소스 코드 구조를 확인하거나 컴파일러가 구문 및 데이터 흐름을 분석하는 것
- ex. 워크스루(informal), 인스펙션(formal)
- 동적(dynamic) 테스팅
- 프로그램 자체를 실행하여 출력이 예상대로인지 확인하는 것
- ex. 단위테스트, 통합테스트, 시스템테스트, 승인테스트
- The ‘box’ approach
- 테스트케이스 설계 시 관점을 기반
- 블랙박스 테스팅 vs. 화이트박스 테스팅
2.3 테스트 단계
- 단위 테스팅(Unit testing)
- 각 모듈에 대해 오류를 발견하기 위한 목적으로만 테스트를 하는 것
- 코드 작성과 병행
- 통합 테스팅(Integration testing)
- 프로그램을 구성하는 모든 모듈들을 함께 테스트하는 기법
- 점진적인 테스팅 : 하향식, 상향식
- 시스템 테스트
- 개발된 시스템을 사용될 하드웨어 플랫폼에 설치한 뒤 수행하는 활동
- 소프트웨어가 제공하는 기능뿐만 아니라 성능 등의 품질 측면에도 관심
- 테스트 종류
- 기능 테스트
- 성능 테스트
- 사용성 테스트
- 인수 테스팅(Acceptance testing)
- 사용자들이 완성된 정보시스템의 수용 여부를 결정하기 위해 직접 그 시스템을 테스트하는 프로세스
- 알파테스팅, 베타 테스팅, 시스템 감사
- 알파(Alpha) 테스팅
- 사용자가 완성된 정보시스템에 대해 가상 데이터를 사용하여 수행하는 테스팅
- 복구테스팅, 보안테스팅, 스트레스 테스팅, 성능테스팅
- 베타(Beta) 테스팅
- 사용자가 실제 업무환경에서 사용되는 실제 데이터를 사용하여 수행하는 테스팅
2.4 소프트웨어 테스트 과정
- 테스팅의 목적 : SW가 요구사항을 만족시키는지 확인
- 테스팅은 계획에 따라 수행되어야 함
- 테스트 케이스(Test cases)
- 시스템의 일반적이거나, 중요하거나, 비정상적인 거래, 질의, 또는 내비게이션 경로에 대한 특정 시나리오
- 테스팅하니스(Testing harness)
- 특별한 목적의 테스팅 소프트웨어
- 단위 시험이나 모듈 시험에 사용하기 위해 만든 임시 모듈
- 시험 드라이버 (test driver) 또는 시험 스텁(test stub)
3. 설치
3.1 설치
- 현재의 정보시스템을 새로운 시스템으로 변환하는 프로세스
- 4가지 접근 방법 : 직접 설치, 병행 설치, 단일장소 설치, 단계별 설치
- 직접 설치 : 새 시스템이 완성되면 바로 기존의 정보시스템을 종료하고 새 시스템으로 대체하는 것
- 병행 설치 : 기존 시스템을 중지할 수 있다고 결정할 때까지 기존 정보시스템과 새 정보시스템을 동시에 운영
- 단일장소 설치
- 새 시스템이 조직에서 효율적으로 사용될 수 있는지, 그리고 어떻게 효율적으로 사용될 수 있는지를 결정하기 위함
- 하나의 장소에서 새 시스템을 설치하고 경험을 얻음
- 단계별 설치
- 새 정보시스템의 일부 기능의 구성요소를 먼저 시작하고 새 시스템이 전부 운영되도록 점진적으로 설치를 확장
- 구 정보시스템에서 새 정보시스템으로 단계별로 변경
4. 시스템 문서화
4.1 시스템 문서화
- 시스템 문서
- 시스템의 내부적 작동과 기능성들을 묘사한 시스템 설계 내역에 관련된 구체적인 정보들
- 사용자 문서
- 애플리케이션 소프트웨어가 작동하는 방법과 그것을 사용하는 방법에 관하여 기술된 문서 또는 비주얼 정보
4.1 정보시스템 사용자 교육
- 가능한 교육 주제들
- 시스템의 사용
- 일반적 컴퓨터 개념
- 정보시스템 개념
- 조직 개념
- 시스템 관리
- 시스템 설치
4.2 정보시스템 사용자 지원
- 지원(support)은 사용자에게 매우 중요
- 대부분의 조직들은 다음과 같은 방법들로 지원 제공
- 자동화된 이슈추적(issue tracking system)
- 지원 자동화하기
- 헬프 데스크 : 특정 정보시스템에 관한 모든 사용자 문의 및 문제, 또는 특정 부서의 모든 사용자들에 대한 단일화된 접촉 포인트
5. 시스템 유지보수 수행하기
5.1 프로젝트 종료
- 팀 평가 : 결과에 따라, 멤버들을 다른 프로젝트에 재배치
- 모든 이해관계자들에게 프로젝트가 종료되었으며 따라서 운영 및 유지보수 상황으로 전환하고 있음을 전달
- 사후 프로젝트 검토를 수행
- 고객사와의 계약을 종료
- 고객의 공식적 서명
5.2 시스템 유지보수 수행하기
- SW 유지보수(maintenance)
- 소프트웨어가 인수 설치된 후 일어나는 모든 작업
- 소프트웨어가 유용하게 활용되는 기간
- SW는 환경과 비즈니스 요구에 따라 진화
- SW 변경의 이유
- 버그 제거
- 운영 환경의 변화
- 정부 정책, 규례의 변화
- 비즈니스 절차의 변화
- 미래 문제를 배제하기 위한 변경
5.3 유지보수 유형
- 교정적(corrective) 유지보수 : 개발과정 상의 오류를 수정하기 위한 시스템 변경
- 적응적(adaptive) 유지보수 : 비즈니스 요구 또는 기술의 변화에 대해 기능성을 발전시키기 위한 시스템 변경
- 개선적(perfective) 유지보수 : 시스템의 성능을 높이기 위해 새로운 특성들을 추가
- 예방적(preventive) 유지보수 : 미래의 가능한 문제점들을 방지하기 위한 시스템 변경
5.4 유지보수 비용
- 일부 조직에서는 정보시스템 예산의 60~80%를 유지보수 활동에 할애
- 시스템 유지보수 능력에 영향을 미치는 요인
- 잠재적 결함의 수
- 시스템을 사용하는 고객의 수
- 시스템문서의 품질
- 유지보수 인력
- 도구
- 잘 구조화된 프로그램(소프트웨어 구조)
5.5 효과 측정
- 유지보수 : 상당한 비용이 드는 작업
- 효과 측정이 중요
- 실패 횟수, 각 실패 간 시간, 실패의 유형
- 실패횟수와 실패 간의 시간 측정
- 시스템 품질을 측정하는데 사용
- 시간이 지나면서 파악되는 오류 발생 측정량
- 실패 간 평균 시간(mean time between failures, MTBF)
- 시스템의 품질을 나타내기 위한 목적
- 실패가 규명된 후 다음 번 실패가 발생할 때까지 걸린 평균 시간
5.6 유지보수 요청 통제
- 유지보수 요청에 대한 관리
- 어떤 요청을 수행하고 거절할지 결정이 필요
- 유지보수 요청 통제에 대한 플로우
5.7 자동화된 개발 도구의 역할
- 도구 사용
- 소스 코드가 아닌 설계 문서들을 유지보수
- 코드는 이러한 설계 문서들을 통해 자동으로 생성
- 유지보수 단계에서 이러한 문서들이 변경되고 관리됨
- 2가지 기존 시스템에 대한 설계 복구 도구(design recovery tools) 유형
- 역공학(reverse engineering)
- 재설계(Re-engineering)