구현과 통합 단계

1. 구현과 통합 단계

2. Overview • Implementation and integration • Testing during the implementation and integration phase • Integration testing of graphical user interfaces • Product testing • Acceptance testing • CASE tools for the implementation and integration phase • CASE tools for the complete software process • Integrated environments • Environments for business applications • Public tool infrastructures • Potential problems with environments • Metrics for the implementation and integration phase • Air Gourmet Case Study: Implementation and integration phase • Challenges of the implementation and integration phase Software Engineering

3. 14.0 구현과통합 단계 개요 • 지금까지는 구현과통합을 독립적인 단계로 취급.즉 제시한 접근법에서 각 모듈은ㄴ 프로그래밍 팀의 멤버가 구현하고,SQA가 테스트 했음,그런후 통합단계시에 모듈이 통합되고 테스트 했음.-이것이 졶은 방법이 아니기에 때문에 구현과통합단게는 병렬로 수행되어야 함. • 고로 본장은 “구현과통합 단계”로 간주,이에 관련된 활동들을 설명하기위해 구현과통합 단계란 용어를 사용 Software Engineering

4. 14.1 구현과 통합 • 우측그림에 있는 프로덕트를 보면 고려해 보자. • 이 프로덕트 개발의 한 접근법은 독립적으로 각 모듈을 코딩하고 테스트해서 모든 13개의 모듈을 연계시켜 전체 프로덕트를 테스트 함.이 접근법에는 두가지 어려움이 있음. Software Engineering

5. 구현과 통합 단계 • 접근법의 두가지 문제 1) 모듈 a를 생각해 보자.모듈 a는 자력으로 테스트될 수가 없다 • 왜냐하면 그것은 모듈 b, c, d를 호출하기 때문임 • 그러면 모듈 a를 테스트하기 위해 모듈 b,c,d는 Stub로 코드되어야 함.가장 간단한 형식에서 stub는 빈 모듈이다.보다 효과적인 stub는module displayReadPattern called와 같은 메시지를 출력한다.대부분의 stub는 미리 계획된 테스트사례에 대응되는 값을 반환. 2)독립된 구현과 통합에서 발생하는 문제 • Stub와 driver들을 구축해서 넣어야만 한다는 것이다. 이런 모든 것은 모듈 테스팅이 끝난 뒤에는 폐기되어야 한다 • 구현 단계는 통합이 시작되기 전에 완료될 때 발생하는 어려움은 결함 분리의 부족이다 • 해결 방안 • 모듈과 통합 테스팅 결합 Software Engineering

6. 14.1.1 하향식 구현과 통합 • 하향식 구현과 통합의 강점 • 주요 설계 흠집을 초기에 발견 • 프로덕트 모듈 • 로직(logic) 모듈 • 필수적으로 프로덕트의 제어 측면의 의사 결정 흐름 통합 • 일반 모듈 상호 연계 다이어그램에서 루트의 근방에 위치 • 운영(operational) 모듈 • 모듈 상호 연계 다이어그램의 하단부에 있는 하위 수준에서 발견 • 그림 14.1에서 모듈 e, f, h, i, k, l, m은 운영 모듈 • 재구축 프로덕트에서 재사용 • 프로덕트에 있는 다른 모듈에 상호 연결되는 방법은 불필요한 작업이 있어 변경 요구 발생 Software Engineering

7. 14.1.2 하향식 구현과 통합 • 장점 • 모듈이 하향식으로 구현되고 통합되는 순서에는 로직 모듈이 꼭 운영 모듈 이전에 구축되고 통합되어야 한다. 왜냐하면 로직 모듈은 모듈 상호 연계 다이어그램에서 항상 운영 모듈의 조상이기 때문 • 단점 • 잠재적으로 재사용 가능한 모듈은 적절하게 테스트를 할 수가 없다 • 테스터는 결함은 어디 부분이 있기 때문에 노력이 낭비되는 결과를 가져온다고 생각한다 • 로직 모듈은 어느 정도 문제-특성이 되기 때문에 다른 부분에서는 사용 불가능 • if(x >= 0) y = computeSquareRoot(x, errorFlag); • computeSquareRoot • x의 값이 음수이면 절대로 호출되지 않고, 또 모듈은 이 함수가 정확하다는 것을 보여주기 위해 x의 음수값으로는 절대로 테스트하지 않음 • 방어적 프로그래밍 결과 • 하위 운영 모듈이 만약 하향식으로 구현되고 통합된다면 철저하게 테스트되지 못함 • 대안 • 책임-중심(responsibility-driven) 설계 사용 Software Engineering

8. 14.1.2 상향식 구현과 통합 • 상향식(bottom-up) 구현과 통합 • 만약 모듈 mAbove가 모듈 mBelow를 호출한다면 mBelow는 mAbove 이전에 구현되고 통합 • 운영 모듈은 상향식 전략이 사용될 때 철저하게 테스트 • 주요 설계 결함 : 통합 단계의 후반부에 발견 • 주요 설계 결함 발생시 • 프로덕트의 상당 부분을 재설계, 재코딩하기 때문에 많은 비용과 시간 소요 • 통합 과정 후반부에 많은 어려움 발생 • 해결 방안 • 샌드위치 모양의 구현과 통합 Software Engineering

9. 14.1.3 샌드위치 구현과 통합 • 그림 14.2 모듈 상호 연계 다이어그램 • 6개의 모듈(a, b, c, d, g, j) : 로직 모듈 • 7개의 운영 모듈 • 상향식으로 구현 통합 • 모듈이 적합하게 통합되었을 때 모듈의 두 그룹의 모듈간에 인터페이스도 하나씩 테스트 Software Engineering

10. 하향식, 상향식, 샌드위치 구현과 통합 Software Engineering

11. 14.1.4 객체-지향 프로덕트의 구현과 통합 • 객체들은 상향식이나 하향식으로 구현되고 통합 가능 • 모든 비-객체 모듈은 객체와 함께 통합 • 객체지향 프로덕트의 구현과 통합을 수행할 때 다양한 샌드위치 구현과 통합 사용 • 상향식 구현과 통합 • 다른 객체에 어떤 메시지를 전송하지 않는 개체가 우선 구현되고 통합 • 고전적 파라다임의 운영 모듈에 대응되어 구현되고 통합 • 운영 모듈 • 하향식 구현과 통합 • 객체가 아닌 대부분의 모듈은 로직 모듈을 구현되고 통합 • 다른 모듈들은 상향식으로 구현되고 통합 Software Engineering

12. 14.1.5 구현과 통합 단계시 관리적쟁점 • 관리 문제 • 모듈이 함께 수정되지 않은 것이 통합시 발견 시점 • SQA 그룹은 테스팅을 철저하게 수행하는 것 보장 • 통합 테스팅 태스크를 전담 직원에게 배정할 지 결정 • SPMP에서 통합 테스트 계획을 작성할 SQA 그룹은 해당 계획에 대한 구현 담당 • 통합 단계의 후반부에 모든 모듈은 테스트를 받은 후 단일 프로덕트에 결합 Software Engineering

13. 14.2 구현과 통합 단계시 테스팅 • 구현과 통합 단계시 테스팅 유형 • 각각 새로운 모듈은 이미 통합된 것에 추가할 때 테스트 • 새로운 모듈 테스트 • 부분 프로덕트의 나머지는 새로운 모듈이 하던 일을 계속 수행 Software Engineering

14. 14.3 GUI의 통합 테스팅 • 프로덕트에 GUI가 혼합되어 있을 때 이 접근법은 적용되지 않음 • 동시에 GUI를 수작업으로 테스트하는 것은 시간 소모가 많고 지루한 작업 • 문제 해결 • 전용 CASE 툴 사용 • 프로덕트 테스팅(product testing) • 통합 프로세스가 완성되면 전체적으로 프로덕트 테스트된다 • 인증 테스팅(acceptance testing) • 개발자가 프로덕트의 모든 측면에 정확성에 대해 확신을 갖게되면 클라이언트에게 인계 Software Engineering

15. 14.4 프로덕트 테스팅 • 마지막 모듈이 프로덕트에 성공적으로 통합되었다는 사실이 개발자의 작업이 완료되었다는 의미는 아니다 • 소프트웨어의 주요 타입 • COTS(shrink-wrapped : 포장) 소프트웨어 • 프로덕트가 가능한 한 많은 구매자에게 판매가 보장 • 테스팅 목적 • 전체적으로 프로덕트에 결함이 없다는 것을 보증 • 주문 소프트웨어(custom software) • 다른 유형의 프로덕트 테스팅을 받음 • 프로덕트의 인증 테스트에 실패한 프로덕트는 개발조직의 관리 기능들이 빈약하게 반영 Software Engineering

16. 프로덕트 테스팅 • 성공적인 인증 테스트를 보장하기 위해 SQA 그룹은 프로덕트 테스팅 • 프로덕트에 대한 블랙-박스 테스트 사례가 전체적으로 실행되어야 한다 • 전체적으로 프로덕트의 강건성이 테스트되어야 한다 • SQA 그룹은 프로덕트가 모든 제약 조건을 만족시키는지 체크를 해야 한다 • SQA 그룹은 클라이언트에게 코드와 함께 전달될 모든 문서도 검토해야 한다 Software Engineering

17. 14.5 인수 테스팅 • 클라이언트를 위해서 프로덕트가 개발자가 주장한 대로 명세를 만족시키는지 판단하는데 목적 • 클라이언트 조직, 클라이언트 대표자가 참석한 SQA 그룹이, 또는 이 목적을 위해서 클라이언트가 고용한 독립된 SQA 그룹이 수행 • 정확성 테스팅이 포함 • 인수 테스팅 주요 컴포넌트 네 가지 • 정확성 테스팅, 강건성, 성능, 문서화로서 이들은 프로덕트 테스팅시 개발자가 수행한 일 • 테스트 데이터보다는 차라리 실제 데이터로 실행해야만 한다 • 테스트 데이터는 대응되는 실제 데이터의 반영물 • 두 프로덕트는 클라이언트가 새 프로덕트의 기능이 기존 프로덕트의 기능보다 좋을 때까지 병행 실행 • 성공적인 병행 실행은 인증 테스팅이 결정나면 기존 프로덕트 폐기 • 프로덕트가 인수 테스트를 통과하면 개발자들이 할 일은 완료 • 프로덕트에 어떤 변경이 있으면 이는 유지보수 단계에서 수행 Software Engineering

18. 14.6 구현과 통합 단계용 CASE 툴 • 구현과 통합 단계 통합 컴포넌트 • 버전 관리 툴(version control tool), 구축 툴(build tool), 형상 관리 툴(configuration management tool) 필요 • 주요 버전 관리 툴 • sccs(source code control system) • rcs(reverse control system) • cvs(concurrent version system) • 상업적으로 이용할 수 있는 형상 제어 워크벤치 • ccc와 Aide-de-Camp가 포함 Software Engineering

19. 14.7 완전한 소프트웨어 프로세스용 CSAE 툴 • CASE 툴 • 온라인 인터페이스 체커나 구축 툴과 같은 단일 툴 • 형상 관리나 코딩과 같은 소프트웨어 프로세스 내에 있는 하나 내지 두 개의 활동을 지원하는 워크벤치(workbench)를 이끌어 내기 위해 결합 • 환경(environment) • 모두가 아니라면 프로세스의 대부분에 컴퓨터-보조 지원을 제공 Software Engineering

20. 14.8 통합 환경 • CASE 환경 내에서 통합된다는 단어의 가장 일반적인 의미는 사용자 인터페이스 통합(user interface integration) • Macintosh의 대부분 어플리케이션은 유사 look and feel을 갖고 있다. 비록 이것이 일반적인 의미이지만 다른 타입의 통합 Software Engineering

21. 프로세스 통합 • 프로세스 통합(process integration) • 환경이 하나의 특정 소프트웨어 프로세스를 지원하는 사실을 의미한다. 이러한 환경의 서브세트는 기법-기반 환경(technique-based environment)이라고 부름 • 전체 프로세스보다는 차라리 소프트웨어를 개발하는 특정 기법 지원 • 대다수의 이들 환경은 명세와 설계 단계를 그래픽적인 지원과 데이터 사전에 통합되도록 지원 • Analyst/Designer는 Yourdon의 방법론으로 특화시킨 것이고 Statement는 상태 차트(statechart)를 지원 • 거의 모든 객체지향 환경은 그들이 원래 지원된 방법론처럼 UML 지원 • 기법-기반 환경이 강조하는 것은 소프트웨어 개발을 위한 매뉴얼 프로세스의 지원과 정형화가 기법으로 구축 • 컴퓨터화된 프레임워크는 사용자가 특정 기법을 사용해 그것을 정확하게 사용하게 해주는 것이 기법-기반 환경의 강점 Software Engineering

22. 툴 통합 • 툴 통합(tool integration) • 모든 툴이 동일 데이터 포맷으로 통신하는 것을 의미 • 한 툴에서 나온 출력 스트림(output stream)을 다른 툴의 입력 스트림으로 사용할 수 있게 두 개의 툴이 결합되면 아주 좋다. 이것이 툴의 통합 Software Engineering

23. 툴 통합 • 툴 통합 방법 • Data stream tool integration • 각 개별 툴에 대한 입력과 출력은 ASCII 스트림 • 한 툴의 데이터 스트림을 다른 툴에 전송시키는 효과 • 그림 14.4(a) • Front-end tool integration • 그림 14.4(b) • 모든 툴이 front end에 통합 • 유용한 환경 • SoftBench • metaCASE 툴 • CASE 툴에서 작동되는 CASE 툴 • 통합을 성취하기 위해서 프론트-엔드는 한 툴로만 저장된 데이터가 정보로서 다른 툴에서 사용될 수 있게 변환(장애요소 일 수도 있다) Software Engineering

24. 툴 통합 • Back-End Tool Integration • 그림 14.4(c) • 모든 툴은 자주 저장소(repository)나 백과사전(encyclopedia)이라고 부르는 데이터베이스에 접속 • 저장 장소의 제작자가 저장 장소와 그것에 통합되는 툴들 간에 인터페이스를 세심하게 정의 • 예 • 소프트웨어 개발 프로세스(AD는 어플리케이션 개발을 나타냄) 관련된 저장소 모두를 지원하는 AD/Cycle • AD/Cycle은 결코 완성되지 못함 Software Engineering

25. 통합의 다른 형식 • 팀 통합(team integration) • CASE 환경이 효과적인 팀 조정과 커뮤니케이션을 향상 • 다른 목적은 관리 통합(management integration) • 보고란 프로젝트 매니저가 주관적으로 종합화시킨 것보다 객관적 데이터로 생산 • 사용자 인터페이스 통합은 아주 폭넓게 이용 Software Engineering

26. 툴 기반 구조 • The European Strategic Programme for Research in Information Technology(ESPRIT)는 CASE 툴을 지원하는 기반구조 개발 • PCTE • 폭넓게 인정받기 시작 • Emeraude와 IBM이 포함 • 많은 CASE 툴이 PCTE 표준에 일치되는 것이고 또 PCTE 자체가 다양한 컴퓨터에 구현 Software Engineering

27. 환경이 갖는 잠재적인 문제점 • 모든 프로덕트와 모든 조직에 맞는 이상적인 환경은 없다 • 만약 조직이 전체적으로 조직에 또는 개발 중인 현재 소프트웨어 프로덕트에 부적절한 기법을 강요하는 환경을 사용하기로 선택했다면 CASE 환경의 사용은 반대의 결과를 갖게 된다 • CASE 환경의 사용은 조직이 CMM 수준 3(2.11절 참조)을 얻을 때까지는 분명히 피해야 한다 Software Engineering

28. 구현과 통합 단계용 매트릭 • 구현과 통합 단계를 위한 많은 복잡도 매트릭 • LOC, McCabe의 순환 복잡도, CDM 매트릭 포함 • 테스팅 관점 • 매트릭은 테스트 사례의 전체 수와 실패가 된 테스트 사례 수 포함 • 대표적인 결함 유형 • 설계의 잘못된 이해, 초기화의 결여, 일관성 없는 변수의 사용 포함 • 결함 데이터 • 미래 프로덕트의 코드 감사시 사용될 체크 리스트에 통합 • 구현과 통합 단계 • 매트릭의 유능한 집합은 통계-기반 테스팅(statistical-based testing)(13.13절)과 연계 Software Engineering

29. 구현과 통합 단계용 매트릭 • 테스팅 실행시 실패가 일어날 기회가 지수적으로 감소한다고 합리적으로 가정해도 한 개의 실패도 않는데 요구되는 테스트 시간 수는 다음 공식으로 주어진다 • ftarget : 실패의 대상으로 계획된 수 • Ftotal : 지금까지 발견된 실패들의 전체 수 • Th : 마지막 실패까지 테스트 시간의 전체 수 • Ln : 밑수 e의 로그 Software Engineering