소프트웨어 공학 정리

7장 소프트웨어 공학

7.1 소프트웨어 공학 개관

 

※소프트웨어 공학과 다른 공학 분야 사이의 차이점

 

  1) 사전 제작된 범용 컴포넌트들을 이용하여 시스템을 구축하는 것고 관련이 있다. 일반 공학분야의 경우와 달리 소프트웨어공학에서는 과거에 설계된 소프트웨어 컴포넌트들의 내부 설계가 특정 응용 분야에 기초하고 있어 범용 컴포넌트로서의 유용성이 제한된다. 따라서 복잡한 소프트웨어 시스템들은 처음부터 새로 개발되어 온 것이 사실이다.

 

  2) 소프트웨어의 경우 그 성질을 측정하기 위해 사용될 수 있는 측도(metric)라고 불리는 정략적 기법이 없다는 것이다.

 

 - CASE(Computer-Aided Software Engineering) : 소프트웨어 개발에 컴퓨터기술을 적용하는 기법

 - CASE도구 : CASE의 발전으로 개발된 다양한 시스템으로 프로젝트계획 시스템, 프로젝트관리시스템, 문서화도구, 프로토타이핑 및 시뮬레이션시스템, 인터페이스 설계 시스템, 프로그래밍 시스템등으 포함한다.

연습문제

 

1) 프로그램에 들어 있는 라인의 수가 프로그램의 복잡도에 대한 정확한 측도가 아닌 이유를 설명하라.

    - 배정문들의 긴 열은 프로그램 설계에서 몇 개의 중첩된 if 문만큼 복잡하지가 않다.

2) 소프트웨어 품질을 측정하기 위한 측도를 제안해보라. 제안된 측도는 어떤 약점을 갖고 있는가?

    - 일정한 사용 기간 후에 발견된 오류의 개수를 생각해 볼 수 있다. 이 측도의 문제점 중 하나는 이 값을 미리 측정할 수 없다는 것이다.

 

3) 소프트웨어 공학 분야에서 발전이 이루어져 왔거나 진행되고 있는 측면 두 가지를 들어보라.

    - 가능한 답에는 측도의 발견, 사전제작 컴포넌트의 개발, CASE의 개발, 표준화 등을 들 수 있다.

 

 

7.2 소프트웨어 생명주기

 

※소프트웨어 생명주기 

  - 소프트웨어 개발 -> 오류수정 or 갱신

 

  1) 오류수정 or 갱신 : 소프트웨어의 경우 유지보수 단계에서 (1)오류가 발견되거나, 소프트웨어의 (2)응용 분야의 변경으로 인해 소프트웨어에 변경이 필요하거나, (3)이전의 변경으로 인해 소프트웨어의 다른 부분에 문제가 생겼거나 등으로 인해 유지보수 단계로 이행한다.

 

  2) 결론 : 오류수정과 갱신은 굉장히 힘든 작업이므로 나중에 고치려하지말고 소프트웨어 개발단계에서 조금만 더 노력해서 개발하자.

 

  3) 소프트웨어 공학 연구의 대부분은 소프트웨어개발 단계에 초점을 맞추고 있으며, 목표는 적은 노력으로 효과를 극대화 하는데 있다.

 

※소프트웨어 생명 주기의 개발단계

 

  1) 요구사항 명세

    - 목표 : 제안 시스템에서 제공할 서비스들을 규정하는 것, 이러한 서비스들에 부과되는 시간 제약이나 보안 등등의 조건을 식별하는 것, 외부 세계와 시스템 사이의 상호작용을 정의하는 것 등

 

    - 제안 시스템의 이해관계자들의 요구사항을 조사하는 일을 포함

 

    - 소프트웨어 요구사항 면세 문서 : 문서 관련 당사자 사이의 서면 합의서에 해당하며, 이러한 합의서는 소프트웨어 개발의 지침으로 사용되며, 개발 과정에서 추후에 발생할지도 모를 분쟁을 해결하는 수단으로 사용될 수 있다.

 

  2) 설계 

    - 목표 : 제안 시스템의 구축을 위한 계획을 만드는 일(요구사항면세는 제안 소프트웨어 제품에 대한 기술을 제공한다)

 

    - 요구사항면세가 해결해야 할 문제를 파악하기 위한 것이라면, 설계는 문제의 해답을 구하는 것이라고 할 수 있다.

 

    - 더 쉽게 요구사항면세는 소프트웨어 시스템이 무엇을 할지 결정하는 것이고, 설계는 소프트웨어 시스템이 그 일을 어떻게 할지 결정하는 일이라 볼 수 있다.

 

    - 소프트웨어 시스템의 내부구조를 확립하는 것, 설계 단계의 결과는 프로그램으로 변환 될 수 있는 소프트웨어 시스템 구조에 대한 세부 기술이다.

 

  3) 구현

    - 목표 : 프로그램을 실제로 작성하고, 데이터 파일을 만들고, 데이터베이스를 개발하는 작업들을 포함한다.

 

    - 소프트웨어 분석가와 프로그래머가 구별되는 단계임. 소프트웨어 분석가는 주로 요구사항면세와 설계단계를 담당하고, 프로그래머는 주로 구현단계를 수행하는 사람을 말한다.

 

    - 하지만 경계는 불분명하다는 것

 

  4) 테스트 

    - 목표 : 최종 소프트웨어 제품이 소프트웨어 요구사항 명세 문서에 합치되는지 확인하는 것에서 벗어나 요즘은 전체 개발 과정의 각 중간 단계 결과물에 대한 정확한지 테스트해야한다.

연습문제

 

2) 소프트웨어 생명 주기의 네 단계인 요구사항 명세, 설계, 구현, 테스트를 요약하여 설명하라.

 

    - 요구사항명세 단계는 제안 시스템이 무엇을 달성해야 할지에 집중하는 반면, 설계 단계는 어떻게 목표를 달성할지 집중한다. 구현 단계의 시스템의 실제 구축에 집중하며, 테스트 단계는 시스템이 의도된 대로 수행되는지를 확인하는데 집중한다.

 

 

7.3 소프트웨어 공학 방법론

 

 - 폭포수모델(waterfall model) : 설계를 시작하기전에 시스템에 대한 요구사항 명세가 완료되어야 하며, 마찬가지로 구현이 시작되기 전에 설계가 완료되어야 한다고 주장, 이렇게 해서 만들어진 개발 방식 : 개발 과정이 한 방향으로만 진행된다는 점에 착안한 이름, 데모버전 등 완전히 개발하는 것에 목적, 그리고 테스트

 

 - 점진적모델(incremental model) : 초창기 방식인 폭포수모델에 의한 엄격한 구조적 환경과 창의적 문제 해결에 핵심적인 "자유분방한" 시행착오 과정 사이의 모순을 극복하는 방향으로 발전. 이러한 사례에 해당하는 것이 소프트웨어 개발을 위한 점진적 모델임.

 

 - 먼저 최종 제품의 기능 중 일부만을 갖는 단순화된 버전이 구축 -> 이 버전에 대해 테스트를 수행하고 잠재적 사용자의 평가를 거친 다음에는, 기능을 추가하고 다시 테스트하는 일이 시스템이 완성될 때까지 점진적으로 이루어짐

 

 - 반복형모델(iterative model) : 폭포수 모델의 엄격한 고수를 벗어난 또 다른 모델로 이 모델은 점진적 모델과 차이는 있지만 비슷한 부분이 많으며 때로 이 둘은 동일시 되기도 한다. 점진적 모델이 제품의 각 예비 버전을 확장하여 더 큰 버전을 마늗ㄹ어나가는 반면, 반복형 모델은 각 버전을 재구축한다는 개념을 함축하고 있다. 현실적으로 점진적 모델은 대개 반복형 과정을 이용하며, 반복형 모델은 종종 점진적 결과를 산출한다.

 

※프로토타이핑(prototyping)

 

 - 프로토타입 : 제안 시스템의 미완성 버전

 

  1) 점진적모델 : 진화적프로토타이핑(evloutionary prototyping)이라는 과정에 의해 완성된 최종시스템으로 발전해간다.

 

  2) 반복형모델 : 최종 설계를 새로 구현하면서 프로토타입을 버리는 폐기형 프로토타이핑(throwaway prototyping) 방식을 사용한다. 

 

 - 단기 프로토타입(rapid prototyping) : 폐기형 프로토타이핑의 범주에 포함되는 방식 중 하나로 개발 초기단계에서 제안 시스템의 단순화된 형태를 단기간에 구축한다. 목표는 실제로 동작하는 제품 버전을 만들어내는 것이 아니라, 소프트웨어 개발 과정에 관련된 당사자들 사이의 의사소통을 명확히 하기 위한 시연용 도구를 확보하는 데 있다. 단기 프로토타입은 요구사항 명세 단계에서 시스템 요구사항을 명확히 하거나 잠재 고객에게 제품 소개를 할 때의 보조도구로 유용하다.

 

 - 공개소스 개발(open-saurce development) : 대개 자신이 사용할 목적으로 개발한 소프트웨어의 소스 코드와 설명문서를 개발자가 인터넷에 올려놓음으로써 시작된다. 다른 사용자들은 자신의 필요에 맞게 그 소프트웨어를 수정하거나 확장할 수 있으며 오류를 찾아 고치기도 한다. 이러한 변경에 대해 원 개발자에게 보고하면, 원 개발자는 이러한 변경을 반영하여 다시 공개한다.

 

 - 기민성 방법(agile method) : 폭포수 모델과 가장 차이가 많이 나는 방식 - 여러 방법론들이 포함되며 각 방법론은 변화하는 요구사항에 맞추어 점진적으로 신속한 조기 구현을 제공한다.엄격한 명세와 설계를 강조하지는 않는다.

 

 - XP(eXtreme Programming) : 기민성 방법의 한 예로 가장 중요한 특성운 유연성이며, 공통의 공간을 사용하는 10여명 이내의 개발자로 이루어진 팀이 자유롭게 생각을 교환하고 개발 프로젝트에서 서로를 돕는 방식으로 소프트웨어를 개발한다. 이는 프로그래머들과 관리자들이 전체 소프트웨어의 개발 업무 중 각자 자신의 맡은 일을 독립적으로 수행하는 폭포수 모델과 대조적이다.

연습문제

1) 소프트웨어 개발을 위한 전통적 방식인 폭포수 모델과 최근의 점진적 및 반복형 패러다임 사이의 차이점을 요약하라

    - 전통적 방식인 폭포수 모델에서는 분석, 설계, 구현, 테스트 등의 단계가 차례대로 수행되도록 정해져있다. 프로토타이핑 패러다임에서는 이보다 완화된 시행착오 방식을 허용한다.

 

2) 폭포수 모델의 엄격한 고수를 지양하는 개발 패러다임 세 개를 들어보라

    - 점진적 모델, 반복형 모델, XP

 

3) 전통적인 진화적 프로토타이핑과 공개소스 개발의 차이는 무엇인가?

    - 전통적인 진화적 프로토타이핑은 소프트웨어를 개발하는 조직안에서 수행되는 반면, 공개 소스 개발은 어느 한 조직으로 제한되지 않는다. 공개 소스 개발의 경우, 개발을 감독하는 사람이 어떤 기능 강화가 보고될지 결정하지 않는 반면, 전통적인 진화적 프로토타이핑의 경우 소프트웨어 개발을 관리하는 사람이 특정 기능 강화에 인원을 배정한다.

7.4 모듈화

 

 - 모듈화(modularity) : 소프트웨어를 관리하기 쉬운 모듈(module)이라는 단위들로 분할하는 것을 말하며, 각 모듈은 소프트웨어의 전체 기능 중 특정 부분만을 담당한다.

※모듈화 구현

 

  1) 명령형 패러다임 : 모듈은 프로시저의 형태로 나타난다.

 

  2) 객체지향 패러다임 : 기본 모듈 요소로 객체를 이용한다.

 

 - 구조도(structure chart) : 프로시저들과 프로시저들 사이의 종속성의 모듈구조를 묘사한 것

모듈화에 대한 발상원리 : 소프트웨어를 만들고 추후의 변경은 몇개의 모듈에 국한될 것이며, 변경 작업을 맡은 사람은 전체 패키지와 씨름하는 대신 해당 부분에만 집중하면 된다는 것

 

 - 모듈간결합도(intermodule coupling) : 모듈사이의 연결정도 - 모듈화 시스템을 설계할 때의 목표는 모듈 사이의 독립성을 극대화하는 것인데 이는 모듈 간 결합도를 최소하 하는 것이다.

 

  1) 제어결합(control coupling) : 프로시저 호출의 경우에서처럼 한 모듈이 다른 모듈에게 실행 제어를 넘길 때 발생 

 

  2) 데이터결합(data coupling) : 모듈 사이의 데이터 공유를 가리킴, 두 모듈이 동일한 데이터 항목을 사용할 경우, 한 모듈의 변경은 다른 모듈에 영향을 미칠 수 있고, 데이터 형식 자체를 변경하면 두 모듈 모두에 영향을 미칠 수도 있다.  - 2가지 형태로 일어남. 하나는 프로시저에서 다른 프로시저에게로 매개변수를 통해 데이터를 명시적으로 전달하는 경우, 다른 하나는 전역 데이터(global data)를 이용하는 것으로 이는 자동적으로 시스템상의 전체 모듈에서 이용할 수 있지만 이를 사용할시 다른 모듈들 사이의 상호작용을 파악하는 일이 어렵다

 

※정보은닉(information hiding) : 정보를 소프트웨어 시스템의 특정 부분에서만 이용될 수 있도록 제한시키는 것을 말한다. 

 

  1) 요지 : 모듈의 동작이 불필요하게 다른 모듈에 종속되거나 영향을 주지 않게끔 하자는 것 - 그렇지 않을 경우 한 모듈의 유효성이 다른 모듈의 개발 과정에서의 오류나 소프트웨어 유지보수 과정에서 실수 등으로 손상될 수도 있다.

 

  2) 실제목표 : 설계 목표로서의 정보 은닉(모듈은 다른 모듈이 그 내부 정보에 접근할 필요가 없도록 설계되어야함) / 구현목표로서의 정보 은닉(그 경계를 확실히 지킬 수 있는 방식으로 규현되어야 한다)

 

  3) ex) 설계 목표로서의 정보은닉 : 응집도의 최대화와 결합도의 최소화 / 구현목표로서의 정보은닉 : 지역변수의 사용, 캡슐화의 적용, 잘 정의된 제어구조의 사용등이 포함

 

※모듈의 응집도

 

 - 응집도(cohesion) : 내부 연결 정도, 모듈의 내부 부분들 사이의 연관성 - 소프트웨어 설계자들은 모듈 간 결합도를 낮추는 일 외에도 모듈 내 응집도를 높이기 위해 노력하게 된다.

 

 - 논리적 응집도(logical cohesion) 모듈 내의 요소들은 사실상 논리적으로 비슷한 활동을 수행한다는 사실에서 도출된 모듈 내 응집도로 약한 형의 응집도이다.

 

 - 기능적 응집도(functional cohesion) 한 모듈 안의 모든 부분은 한 가지 활동의 수행에 초점을 맞추어야함을 의미로 강한 형태의 응집도이다.

 

 - 객체지향 설계의 경우 대개 논리적 응집도만 갖추게 되는데 이는 객체들 수행하는 메쏘드들의 연광이 약한 경우가 있으며 이들 사이의 유일한 연결고리는 동일한 객체에 수행되는 활동이라는 것뿐인 이유가 있다. 하지만소프트웨어 설계자들은 객체 안의 개별 메쏘드가 기능적 응집도를 갖도록 해야한다. 

 

※컴포넌트(component) : 정의상 재사용 가능한 소프트웨어 단위

 

 - 객체들과 클래스들은 소프트웨어 설계에서 사전 제작된 구성요소로 사용될 수 있지만, 이들은 이상적이라고는 할 수 없다. 그 이유는 객체의 단위가 너무 작다는 것이다.

 

 - 실제로 대부분의 컴포넌트들은 객체지향 패러다임에 기반하고 있으며, 각기 독립된 단위로 기능하는 한 개 이상의 객체들이 모여 컴포넌트를 구성한다.

 

컴포넌트구조(component) : 컴포넌트 개발과 사용에 관한 연구로 컴포넌트 기반 소프트웨어 공학으로 불리는 분야가 등장

 

컴포넌트어셈블러(componet assembler) : 많은 개발 환경에서 소프트웨어 시스템을 구축하는 일을 함. 컴포넌트 자체를 작성하기 보다는 사전 정의된 컴포넌트의 집합으로부터 관련 컴포넌터를 선택하고 이들을 연결하면서 원하는 기능을 얻기 위해 필요하다면 약간의 손질도 하는 등의 작업을 수행한다.

연습문제

3) 응집도를 극대화하면서 결합도를 최소화하는 것이 가능한가? 즉. 응집도가 증가하면 결합도는 자연히 감소하는 경향이 있는가?

 

    - 이것은 어려운 문제이지만 관점에 따라서는 모든 것을 한 모듈에 넣는 것으로 시작할 수 있다. 이 경우 응집도는 아주 낮을 것이며 결합도는 아예 없다. 이 모듈을 작은 모듈들로 분할한다면 결과적으로 결합도는 증가할 것이다. 따라서 응집도의 증가는 결합도도 증가시킬 것으로 결론 내릴 수 있다. 

 

4) 결합, 응집, 정보 은닉 등의 용어를 정의하라

    - 결합은 모듈 사이의 연결이며, 응집은 모듈 내부의 연결성을 의미한다. 정보 은닉은 정보 공유를 제한하는 것이다.

 

7) 정통적인 프로그래머와 컴포넌트 어셈블러 사이의 차이는 무엇인가?

   - 정통적인 프로그래머는 6장에서 소개된 것과 같은 문장들을 사용하여 프로그램을 작성하는 반면, 컴포넌트 어셈블러는 컴퓨넌트라고 불리는 사전 제작된 코드 블록들을 연결함으로써 프로그램을 작성한다.

 

 

7.5 설계도구

 

※전통적도구들

 

 - 데이터흐름도(dataflow diagram) : 데이터가 시스템에서 어떻게 움직이는 확인, 데이터 흐름에 대한 분석을 통해 프로시저들을 식별할 수 있게 됨 

 

 - 데이터흐름도는 소프트웨어 개발의 설계 단계에서 프로시저들을 식별하는데 도움이 될 뿐만 아니라 분석 단계에서 제안 시스템을 이해하려 할 때도 유용하다. 고객과 소프트웨어 엔지니어 사이의 의사소통을 개선하기 위한 수단으로 사용될 수 있다.

 

 - 데이터사전(data dictionary) : 소프트웨어 시스템에 나타나는 데이터 항목들에 관한 정보의 중앙 저장소이다. 각 항목을 참조하기 위해 사용되는 식별자, 유효한 데이터에 대한 규정, 저장할 장소, 참조하고 있는 소프트웨어상의 위치 등을 포함함 

 

 - 데이터 사전 구축 목표는 소프트웨어 시스템의 잠재적 사용자와 사용자의 요구를 요구사항면세 문서로 변환하는 작업을 맡은 소프트웨어 엔지니어 사이의 의사소통을 개선하자는 취지, 또 다른 목표는 시스템 전체에 걸쳐 일관성을 확보하자. - 중복정의 방지 및 유사한 이름 사용시 구별 가능

 

※UML(Inified Modeling Language) : 위의 것은 명령형 패러다임용이고 지금은 객체지향 패러다임을 염두에 두고 개발된 현대적인 도구임

 

 - 용례 다이어그램(use case diagram) : UML 도구 중 하나로 사용자의 관점에서 제안 시스템의 모습을 그려보기 위한 것으로 패러다임에 상관없이 유용함. 제안된 소프트웨어 시스템을 외부 시각에서 바라봄

 

 - 클래스 다이어그램(class diagram) : UML 도구 중 하나로 시스템의 내적 객체지향 설계를 표현하기 위한 다양한 도구를 제공함 - 클래스들의 구조와 클래스 사이의 관계를 표현하기 위한 표기 체계임

 

 - 연관 관계(association) : 클래스 사이의 관계

 

 - 클래스 다이어그램은 클래스 사이의 관계를 보여주는 외에도 이러한 관계에 연계된 수량 관계를 표현할 수도 있다. 즉 클래스 다이어 그램은 한 클래스의 인스턴스 몇 개가 다른 클래스의 인스턴스들과 연계될 수 있는지 표현할 수 있다.

 

 - 연관관계의 수량관계는 일대일 관계, 일대다 관계, 다대다 관계 등 세가지 형태로 존재할 수 있음.

 

 - 일반화 : 객체지향 설계에서 한 클래스는 다른 클래스의 보다 구체적인 버전을 나타내는 경우가 종종 있는데 이 경우 후자의 클래스는 전자의 클래스에 대한 일반화라 부른다

 

 - 일반화의 경우 보통 상속을 이용하는데 소프트웨어 엔지니어들 중에는 상속이 모든 경우의 일반화에 적합한 것은 아니라고 경고한다. 소프트웨어 유지보수에서 약간의 수정으로 인해 예상하지 못한 결과를 초래할 수 있기 때문이다.

 

 - 프로그램 설계의 정적인 기능을 표현하지만 실행동안 발생하는 이벤트들의 진행순서를 표현하지는 못한다.

 

 - 상호작용 다이어그램(interaction diagram) : 동적인 기능을 표현하기 위해 UML은 상호작용 다이어 그램으로 총칭되는 다양한 다이어그램 유형을 제공한다. 

 

 - 진행순서 다이어그램(sequence diagram) : 작업수행에 참여하는 객체들 사이의 통신을 묘사함(352페이지의 그림 하나 보는 것이 이해가 더 쉬울 듯)

 

 - CRC(class-responsibility-collaboration) 카드 : UML에 속하지는 않지만 객체지향 설계의 검증에서 중요한 역할을 한다. 설계자가 제안 시스템상의 각 객체마다 카드 한장 씩을 만들어두었다가 시스템에 대한 시뮬레이션에서 객체들을 나타내기 위해 그 카드들을 사용한다. 

 

 - 구조적 예행연습(structured walkthrough) : 이러한 시뮬레이션은 회의용 테이블 상에서 작은 규모로 이루어 질 수 도 있고 설계팀의 각 구성원이 한 장씩의 카드를 들고 그 카드가 기술하는 객체의 역할을 수행하는 "공연" 스타일로도 진행될 수 있다. 이러한 시뮬레이션은 설계를 구현하기 전에 설계상의 결함을 찾아내는 데 도움이 된다.

 

※설계패턴(design pattern) : 소프트웨어 설계에서 자주 나타내는 문제를 위해 이미 개발되어 있는 해결 방법 - 소프트웨어 엔지니어를 위한 강력한 도구 중 하나로 많은 설계 패턴들이 축적되면서 그 효용성이 증대되고 있다. 

 

 -어댑터(adapter) 패턴 : 사전 제작된 모듈들로부터 소프트웨어를 구축할 때 발생하는 문제에 대한 해결방법임.- 당면 문제를 해결하기 위해 필요한 기능은 가지고 있지만 현재 응용프로그램에서는 이용이 불가능함. 이를 가능하게 함

 

 -데코레이터(Decorator) 패턴 : 실행 시점의 상황에 따라 동일한 활동들을 다르게 조합하는 작업을 수행하는 시스템을 설계하기 위한 수단임 - 옵션들이 너무 많아져 엄청나게 복잡한 소프트웨어가 만들어질 수 이는 상황을 위해 표준적인 방법을 제공함

 

 -설계패턴의 목표는 단순히 설계 문제들에 대한 해결 방법을 찾는 것이 아니라, 소프트웨어 생명 주기에서 유연성을 제공하는 고품질의 해결 방법을 찾자는 것이다.

연습문제

6) 설계 패턴들은 소프트웨어 공학 과정에서 어떤 역할을 수행하는가?

    - 설계패턴은 반복되는 소프웨어 유형을 구현하기 위한 잘 개발된 표준적 방법론을 제공한다.

7.6 품질 보증

 

※ 품질보증의 범위

 

 - 소프트웨어 품질 보증 그룹(SQA(software quality assuarance) group) : 소프트웨어 개발업체들이 설립한 자신이 채택한 품질 제어 체계의 감독 및 집행을 담당할 그룹

품질제어노력테마

 

 - 기록정리 : 개발과정의 각 단계를 추후에 참조하기 위해 정확히 문서로 남기는 것 - CASE 도구가 인간의 본성과 충돌하는 면을 막도록 도아줌 - 다이어그램 수정이나 데이터 사전 갱신 등의 작업을 수작업으로 할 때보다 한결 쉽게 만들어줌 이 경우 문서 갱신이 함께 이러우져 최종 문서가 정확할 가능성이 대단히 높아

짐

 

 - 소프트웨어 개발 프로젝트에 관련된 여러 관계자들이 모여 특정 주제를 살펴보는 검토(review) 수행 - 소프트웨어 개발의 전 과정에 걸쳐 검토가 일어날 수 있음 - 큰 문제를 일으키기 전에 착오를 예방하거나 오

류를 고칠 수 있음

 

※ 소프트웨어테스트 - 테스트를 통해 검증하지만 정확할 수는 없음 

 

적은 수의 테스트로 오류를 찾을 확률을 개선하는 테스트 방법론

 

1) 유리박스 테스트 - 대상 소프트웨어의 내부 구성에 대한 지식을 전제로 하는 기법들 - 테스트 하는 사람이 소프트웨어의 내부구조를 잘 알고 있으며 이러한 지식을 테스트의 설계에 이용

 

 - 파레토 원리 : 소프트웨어상의 오류들을 모여서 나타나는 경향이 있다는 관찰에 기초 - 이런 소수의 모듈을 찾아 더욱 철저히 테스트하는 방법이 모든 모듈에 대해 균등하게 테스트하는 것보다 더 많은 시스템 오류를 발견할 수 있음 - 특정부분에 노력을 집중함으로써 보다 빨리 성과를 개선시킬 수 있다

 

 - 기초 경로 테스트 : 소프트웨어 안의 모든 명령이 적어도 한 번씩은 실행되도록 보장하는 테스트 데이터 집합을 개발하는 것

 

2) 블랙박스 테스트 - 소프트웨어의 내부 구성에 대한 지식에 의존하지 않는 테스트 - 사용자 관점에서 수행

 

 - 경계값 분석 : 비슷한 성능을 보이는 데이터 범위를 일컫는 동치 클래스(equivalence class)들을 식별하고 이러한 범위들의 가장자리에 가까운 데이터들에 대해 소프트웨어를 테스트 - ex) 소프트웨어가 특정 범위 값들을 입력받도록 되어 있을 경우, 이 범위의 최대값과 최소값에 대해 소프트웨어를 테스트함 - 동치클래스 안의 데이터 몇 개에 대해 정확한 동작이 검증되면 전체 클래스에 대해 소프트웨어를 검증한 것이 되기 때문에 그리고 어떤 클래스에서 오류를 찾을 가능성은 가장자리의 데이터를 사용했을 때 가장 높아진다는 것으로

 

 - 베타테스트 : 일부 사용자들에게 베타버전이라고 불리는 소프트웨어 예비 버전을 제공함 - 그 목적은 제품의 최종 버전을 확정하여 시장에 내놓기 전에 그 소프트웨어가 실제 상황에서 어떻게 실행되는지 알아보기 위한 것 (알파테스트는 개발자 사이트에서 수행되는 유사한 테스트임) - 오류발견이라는 전통적인 차원을 넘어서 고객의 사용소감 및 시작 전략을 개선하는데 도움이 될 수 있음 - 또한 다른 소프트웨어 개발자들이 호환 제품을 설계하는데 도움이 될 수 있음 - 또한 시장 내에 기대감을 만들어내어 홍보와 매출을 향상시킴

연습문제

 

1) 소프트웨어 개발 기관에서 SQA 그룹의 역할은 무엇인가

    - SQA 그룹은 기관이 채택한 품질 제어 체계를 감독하고 집행한다.

 

4) 성공적인 소프트웨어 테스트란 오류를 발견한 경우인가? 아니면 발견하지 못한 경우인가?

    - 소프트웨어를 테스트하는 목적은 오류를 찾아내기 위한 것이다. 어떤 의미에서 오류를 찾아내지 못한 테스트는 실패라고 볼 수 있다.

 

 

7.7 문서

 

※ 소프트웨어 문서

 1) 사용자문서(user documentation) : 소프트웨어의 기능을 설명하고 이러한 기능들을 어떻게 사용하는지를 기술하는 것 - 전통적으로 책자 형태이지만 소프트웨어의 일부분으로 함께 포함시키는 경우도 있음

 

2) 시스템문서(system documentation) 

    - 소프트웨어 생명 주기에서 유지보수 단계에 도움이 될 수 있도록 소프트웨어의 내부 구성에 대해 기술하는 것 - 시스템문서의 주요 구성요소 중 하나는 시스템을 구성하는 모든 프로그램의 소스 버전들이다. 이러한 프로그램은 읽기 쉬운 형식으로 되어 있어야 한다. 

 

    - 소프트웨어 요구사항 명세 문서를 포함하는 설계문서와 설계 도중 이러한 명세를 얻게 된 과정을 기술한 기록 - 소프트웨어 유지보수 과정에서 유용한데 소프트웨어가 왜 그 상태로 구현되었는지를 밝혀주며 이러한 정보를 통해 유지보수 과정에서의 변경으로 인해 시스템에 결함이 발생할 가능성을 줄일 수 있기 때문이다.

 

3) 기술문서(technicaldocumentation) : 소프트웨어 시스템의 설치와(운영매개변수의 조정이나 업데이트 설치, 문제 발생 시 소프트웨어 개발자에게 보고하는 일 등)의 사후관리 방법 등을 기술한 것

연습문제

 

2) 소프트웨어 생명 주기에서 시스템 문서가 만들어지는 단계는?

    - 개발단계와 수정단게. 

7.8 인간-장비 인터페이스

 

 - 소프트웨어 시스템의 인터페이스가 시스템 자체의 편의보다는 사람의 편의성에 초점을 맞추어 설계되어야 한다

 

사 - 람의 관점에서 두 개의 경쟁 시스템 사이에서 선택할 때 얼마나 똑똑하게 수행하는가 보다는 어떻게 사용할 수 있는지에 따라 시스템을 평가하므로 시스템의 인터페이스에 기초할 가능성이 높다.

 

 - 인체공학(ergonomics) : 사람의 신체 기능과 조화되는 시스템 설계를 다룸

 

 - 인지공학(cognetics) : 사람의 정신 기능과 조화되는 시스템 설계를 다룸

 

 - 인체공학과 달리 인지공학이 연구 된지는 얼마 안 되었다. 여기서 가장 무서운 것은 인간의 습관이다. 재차 확인 하는 작업을 습관으로 인해 하나로 묶일 수 도 있다.

 

 - 인간 본성의 주의력 협소성은 한 번에 일곱 가지 정도의 세부사항 밖에 처리할 수 없다는 것이다. 따라서 어떤 의사결정이 요구될 때 사용자의 기억에 의존하기보다는 필요한 모든 정보를 제시하도록 인터페이스를 설계하여아 한다.

연습문제 

 

3) 인간 - 장비 인터페이스의 설계에서 고려해야 할 인간 본성 문제 세 가지를 들어보라

    -  습관 형성, 주의력 범위의 협소성, 제한된 다중처리 능력, 이외에 가정하는 경향 등도 답이 될 수 있다

7.9 소프트웨어에 관한 소유권과 책임의 문제

 

지적재산권 : 저작권법과 특허법의 원칙들에 기초하여 상품의 개발자가 자신의 소유권을 보호하면서 일반에 상품을 공개할 수 있도록 하기 위해 만들어진 것

필터링 : 저작권 침해와 무관한 특성들을 식별하여 제거하고 남은 부분을 저작권 침해에 대한 판단의 기초로 삼는 것