[컴퓨터과학의이해🧮] 소프트웨어 공학 (7장)

교재 : 컴퓨터 과학 총론 (13th Edition)

(배운 내용을 책으로 복습하며 작성한 글입니다. )

1. 소프트웨어 공학 개관

- 소트트웨어 공학은 대규모의 복잡한 소프트웨어 시스템의 개발에 지침이 되는 원리들을 모색하는 컴퓨터과학의 한 분야이다.

- 소프트웨어의 특성과 다른 공학 분야의 특성 사이의 차이

• 사전 제작된 범용 컴포넌트들을 이용하여 시스템을 구축하는 것 (일반 공학의 경우 "규격 부품"을 기초 요소로 사용하는 것은 대단히 유용하지만, 소프트웨어 컴포넌트는 특정 응용 분야에 기초하고 있어서 범용 컴포넌트로서의 유용성이 제한된다.)
• 소프트웨어의 경우 그 성질을 측정하기 위해 사용될 수 있는 측도(metric)라고 불리는 정량적 기법이 없다.

-  소프트웨어 공학 연구

• 실용 연구자 : 바로 응용 가능한 기법 개발
• 이론 연구자 : 훗날 보다 안정된 기법들을 구축하는 데 토대가 될 기초 원리와 이론 모색

- 상황

• 사전 제작된 컴포넌트 및 측도의 결어와 같은 문제를 극복하는 분야에서는 상당한 진전이 이루어지고 있음.
• 소프트웨어의 개발에도 컴퓨터 기술을 적용하는 CASE(Conputer-Aided Software Engineering) 라는 기법이 탄생함.
• CASE 기법의 탄생으로 소프트웨어 개발 과정은 점차 단순해짐.
• CASE 발전으로 CASE 도구라고 불리는 다양한 시스템이 개발됨. (프로젝트 계획 시스템, 프로젝트 관리 시스템, 문서화 도구, 프로토타이핑 및 시뮬레이션 시스템, 인터페이스 설계 시스템, 프로그래밍 시스템 등)
• 통합개발환경(IDE ; integrated development environment) : 소프트웨어 공학 환경을 위해 특별히 개발된 상당히 복잡한 패키지 
• 소프트웨어 개발자들의 전문가 정신을 강화하고, 개인의 책임에 대한 무관심에 대처하기 위한 윤리 강령 채택

 

2. 소프트웨어 생명 주기

1) 전체 주기

- 소프트웨어가 개발되면 사용과 유지보수의 주기에 돌입한다. 

- 소프트웨어의 경우 유지보수 단계의 주요 작업은 오류 수정이나 갱신이다. 

 

2) 전통적인 개발 단계

(1) 요구사항 분석(requirements analysis) 

• 제안 시스템에서 제공할 서비스들을 규정하고, 이러한 서비스들에 부과되는 시간 제약이나 보안 등등의 조건을 파악하는 것, 외부세계와 시스템 사이의 상호작용을 정의하는 것 등이 목표이다.
• 제안 시스템의 이해관계자들의 요구사항을 조사하는 것을 포함한다.
• 소프트웨어 사용자들의 요구사항을 수집하고 분석하는 일, 희망사항, 요구사항, 비용, 타당성 등에 대해 절충하기 위해 프로젝트 이해관계자들과 협상하는 일, 최종 소프트웨어 시스템이 갖추어야 할 기능과 서비스 등을 나타내는 요구사항 모음을 개발하는 일 등으로 이루어진다. 
• 요구사항들은 소프트웨어 요구사항 명세라는 문서에 기록된다.
•  소프트웨어 요구사항 명세는 소프트웨어 개발의 방향이 될 확고한 목표를 정의해야 한다. 

(2) 설계 (design)

• 제안 시스템의 구축을 위한 계획을 만드는 일
• 소프트웨어 시스템의 구조가 정해진다. 
• 설계 단계의 결과는 프로그램으로 변환될 수 있는 소프트웨어 시스템 구조에 대한 세부 기술이다.
• 다이어그램과 모델링 작업이 중요하다.  

(3) 구현 (implementation)

• 프로그램을 실제로 작성하고, 데이터 파일을 만들고, 데이터베이스를 개발하는 작업을 포함한다. 
• 시스템 분석가로 칭하기도 하는 소프트웨어 분석가(software analyst) 와 프로그래머가 구별되는 단계이다. 
• 소프트웨어 분석가는 전체 개발 과정에 관련된 사람이며 주로 요구사항 분석과 설계 단계를 담당하는데, 프로그래머는 주로 구현 단계를 수행한다. 
• 위와 같은 용어는 경계가 불분명한데, 이는 소프트웨어 개발 과정의 단계들이 서로 얽혀있기 때문이다.

(4) 테스트 (testing)

• 과거의 전통적 개발 단계에서의 테스트는 기본적으로 프로그램의 오류를 찾아 고치고, 최종 소프트웨어 제품이 소프트웨어 요구사항 명세에 합치되는지 확인하는 과정이다.
• 오늘날에는 전체 개발 과정의 각 중간 단계 결과물에 대해 정확한지 테스트한다 .
• 테스트를 소프트웨어 개발에서 하나의 분리된 단계로 볼 것이 아니라 다른 단계들에 테스트 요소들이 편입되야 하며, 결과적으로 소프트웨어 개발 과정은 "요구사항 명세와 확인", "설계와 검증", "구현과 테스트" 등 세 개의 단계로 이루어져야 한다고 주장하는 소프트웨어공학자들이 많다.

3. 소프트웨어 공학 방법론

(1) 폭포수 모델 (waterfall model)

- 초창기 방식에서는 요구사항 분석, 설계,구현, 테스트 등을 엄격히 순차적으로 수행할 것을 주장했다. 

- 대규모 소프트웨어 시스템의 개발 과정에서 변화를 허용한다면 너무 많은 위험이 따르기 때문이다. 

- 소프트웨어 엔지니어들은 설계를 시작하기 전에 시스템에 대한 요구사항 명세가 완료되어야 하며, 마찬가지로 구현이 시작되기 전에 설계가 완료되어야 한다고 주장한다. 

- 개발 과정이 한 방향으로만 진행된다. 

- 소프트웨어 공학 기법은 최근에 폭포수 모델에 의한 엄격한 구조적 환경과 창의적 문제 해결에 핵심적인 "자유분방한" 시행착오 과정 사이의 모순을 극복하도록 발전하고 있다. 

 

(2) 점진적 모델 (incremental model)

- 소프트웨어 시스템은 점진적으로 구축되는데, 먼저 최종 제품의 기능 중 일부만을 갖는 단순화된 버전이 구축된다.

- 이 버전에 대한 테스트를 수행하고 잠재적 사용자의 평가를 거친 다음, 기능을 추가하고 다시 테스트하는 일이 시스템이 완성될 때까지 점진적으로 이루어진다. 

 

(3) 반복형 모델 (iterative model)

- 점진적 모델과 차이는 있지만 비슷한 점이 많으며 때로 동일시되기도 한다. 

- 점진적 모델이 제품의 각 예비 버전을 확장하여 더 큰 버전을 만들어나가는 반면, 반복형 모델은 각 버전을 재구축한다는 개념을 함축하고 있다. 

- 현실적으로 점진적 모델은 대개 반복형 과정을 이용하며, 반복형 모델은 종종 점진적으로 기능을 추가하기도 한다. 

- RUP(Ratioanl Unified Process) : 소프트웨어 생명 주기의 개발 과정의 단계들을 세분화하는 패러다임

- UP(Unified Process) : RUP의 공개버전

 

* 프로토타이핑 (prototyping) : 점전적 모델과 반복형 모델이 종종 사용하는 소프트웨어 방식

- 프로토타이핑에서는 프로토타입(prototype)이라는 제안 시스템의 미완성 버전을 구축하고 평가한다. 

- 점진적 모델에서 이러한 프로토타입은 진화적 프로토타이핑(evolutionary prototyping)이라는 과정에 의해 완성된 최종 시스템으로 발전해간다.

- 반복형 모델에서는 최종 설계를 새로 구현하면서 프로토탕비을 버리는 폐기형 프로토타이핑(throwaway prototyping) 방식도 있다. 

 

* 공개소스 개발 (open-source development)

- 점진적 및 반복형 방식의 비정형적 변형의 하나

- 소프트웨어 패키지의 공개소스 개발은 대개 자신이 사용할 목적으로 개발한 소프트웨어 소스 코드와 설명 문서를 개발자 가 인터넷에 올려놓음으로써 시작된다. 

- 이후 다른 사용자들이 무료로 다운로드 받아 사용하는데, 필요에 맞게 소프트웨어를 수정하거나 확장할 수 있다. 

 

 

(4) 기민성 방법(agile method)

- 폭포수 방법과 가장 차이가 많은 방식

- 여러 방법론이 포함되며, 각 방법론은 변화하는 요구사항에 맞추어 점진적으로 신속한 조기 구현을 제공하며 엄격한 요구사항 분석과 설계를 강조하지 않는다. 

- XP(eXtreme Programming) : 개발자로 이루어진 팀이 자유롭게 생각을 교환하고 개발 프로젝트에서 서로를 돕는 방식으로 소프트웨어를 개발한다. 

- 기민성 방식에서 가장 중요한 것은 유연성이다. (프로그래머들과 관리자들이 전체 소프트웨어 개발 업무 중에서 각자 자신이 맡은 일을 독립적으로 수행하는 폭포수 모델과 대조적이다.)

 

4. 모듈화

1) 모듈화

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

- 명령형 패러다임의 경우에는 모듈은 함수 형태로, 객체지향 패러다임에서는 기본 모듈 요소로 객체를 이용한다. 

 

2) 모듈 간의 결합도

- 모듈화 시스템을 설계할 때의 목표 : 모듈 사이의 독립성을 극대화

; 모듈 간 결합도 (intermodule coupling)라 불리는 모듈 사이의 연결 정도를 최소화하는 것이다.

 

- 모듈 간 결합의 형태

• 제어 결합 (control coupling) : 함수 호출의 경우에서처럼 한 모듈이 다른 모듈에게 실행 제어를 넘길 때 발생
• 데이터 결합 (datat coupling) : 모듈 사이의 데이터 공유 (두 모듈이 동일한 데이터 항목을 사용할 경우, 한 모듈의 변경은 다른 모듈에 영향을 미칠 수 있고, 데이터 형식 자체를 변경하면 두 모듈 모두에 영향을 미칠 수 있다. )
• 데이터 결합은 두 가지 형태로 일어날 수 있다. 
• 데이터 결합의 형태 1 ) 한 함수에서 다른 함수에게로 매개변수를 통해 데이터를 명시적으로 전달하는 경우
• 데이터 결합의 형태 2 ) 전역 데이터 (global data) 라는 형태로 모듈 사이에 묵시적 데이터 공유가 발생하는 경우
• 전역 데이터를 사용하는 모듈은 추상적 도구로서의 유용성이 떨어질 수 있다. 

 

3) 정보 은닉

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

- 모듈의 동작이 불필요하게 다른 모듈에 종속되거나 영향을 주지 않게끔 한다. 

- 정보 은닉의 설계 목표로서의 정보 은닉과 구현 목표로서의 정보 은닉이라는 두 가지 측면이 있다.

- 설계 목표로서의 정보 은닉 : 응집도의 최대화,  결합도의 최소화

- 구현 목표로서의 정보 은닉 : 지역 변수의 사용, 캡슐화의 적용, 잘 정의된 제어 구조의 사용

 

4) 모듈의 응집도

- 응집도 (cohesion) : 모듈 내부 부분들 사이의 연관성 정도

- 논리적  응집도 (logical cohesion) : 약한 형태의 응집도

• 모듈 내부의 요소들은 성질상 논리적으로 비슷한 활동을 수행한다는 사실에서 도출된 모듈 내 응집도

-  기능적 응집도 (fuctional cohesion) : 강한 형태의 응집도

• 한 모듈 안의 모든 부분은 한 가지 활동을 수행에 초점을 맞추어야 함을 의미한다. 
• 명령형 설계에서는 서브태스크들을 별도의 모듈에 두고 이 모듈을 추상적 도구로 이용하는 방법을 사용하는 방법으로 기능적 응집도 강화가 가능하다.
• 객체지향 설계의 경우, 객체 단위로는 대개 논리적 응집도만 갖추게 되는데, 이는 객체 안의 메서드들의 연관성이 약한 경우가 있으며 이들 사이의 유일한 연결 고리는 동일한 객체에 수행되는 활동이라는 것뿐일 경우도 있다. 
• 객체 전체로는 논리적 응집도만 갖추고 있지만, 객체 안의 각 메서드는 기능적 응집도를 갖도록 한 가지의 작업만을 수행해야 한다는 것이다. 

 

5) 컴포넌트

- 객체들과 클래스들이 소프트웨어 설계에서 사전 제작도니 구성요소로 사용될 수 있지만, 이상적이지는 않다. 

- 객체가 갖는 문제는 객체의 단위가 너무 작다는 것이다. 

- 객체는 실제로 정의상 재사용 가능한 소프트웨어 단위를 의미하는 컴포넌트(component)라는 보다 일반적인 개념의 특별한 경우로 간주된다. 

- 컴포넌트 구조 (component architecture) : 컴포넌트 개발과 사용에 관한 연구로 등장한 분야

- 컴포넌트 구조에서는 프로그래머의 역하링 컴포넌트 어셈블러(component assembler)로 변한다.

- 컴포넌트 어셈블러는 사전 제작된 컴포넌트들로부터 소프트웨어 시스템을 구축한다. 

 

5. 설계 도구

1) 전통적 도구들

- 데이터 흐름도 (dataflow diagram) : 데이터 흐름에 대한 조사를 통해 얻은 정보를 표현하는 수단

• 데이터 흐름도는 소프트웨어 개발의 설계 단계에서 프로시저들을 식별하는 데 도움이 될 뿐만 아니라 분석 단계에서 제안 시스템을 이해하려 할 때도 유용하다.

- 데이터 사전 (data dictionary) : 소프트웨어 시스템에 나타나는 데이터 항목들에 대한 정보의 중앙 저장소

• 각 항목을 참조하기 위해 사용되는 식별자, 각 항목에서 유효한 데이터에 대한 규정, 항목을 저장할 장소, 항목을 참조하고 있는 소프트웨어상의 위치 등을 포함한다. 
• 시스템 전체에 걸쳐 일관성을 확보한다.

 

2) UML

- UML (Unfied Modeling Language) : 객체지향 패러다임을 염두에 두고 개발된 도구

 

(1) 용례 다이어그램 (use case diagram) : 사용자의 관점에서 제안 시스템의 모습을 그려보기 위한 것

• 제안 시스템을 하나의 큰 사각형으로, 시스템과 사용자 사이의 상호작용을 타원으로 시스템의 사용자들을 막대 인물로 표현한다. 
• 타원으로 표시되는 상호작용은 용례(use case)라 불리고, 시스템의 사용자는 행위자(actor)라 불린다.
• 제안된 소프트웨어 시스템을 외부 시각에서 바라본다. 

(2) 클래스 다이어그램 (class diagram)

• 클래스들의 구조와 클래스 사이의 관계를 표현하기 위한 표기 체계
• 시스템의 내적 객체지향 설계를 표현하기 위한 도구
• 클래스 사이의 관계는 UML 용어로는 연관 관계(association)라 불린다. 
• 클래스들은 사각형으로 표시되며 연관관계는 연결선으로 표시된다. 
• 연결선에는 라벨을 붙일 수도 붙이지 않을 수도 있고, 라벨이 있을 경우, 라벨을 읽는 방향을 나타내기 위해 진한 화살촉 표시를 사용할 수 있다.
• 클래스 사이의 관계를 보여주는 것 이외에도 관계에 연계된 수량 관계를 표현할 수 있다. 
• 클래스 다이어그램은 한 클래스의 인스턴스 몇 개가 다른 클래스의 인스턴스들과 연계될 수 있는지를 표현할 수 있다.
• 연관관계의 수량 관계는 일대일 관계(one-to-one relationship), 일대다 관계(one-to-many relationship), 다대다 관계(many-to-many relationship) 등 세 가지 형태로 존재한다. 
• 객체지향 설계에서 한 클래스는 다른 클래스의 보다 구체적인 버전을 나타내는 경우가 있는데, 후자의 클래스를 전자의 클래스에 대한 일반화라 부른다. 
• 객체지향 프로그래밍 환경에서 일반화를 구현하는 자연스러운 방법은 상속을 이용하는 것이다. 
• 상속으로 인해 발생하는 클래스 사이의 강한 결합은 소프트웨어 생명 주기에서 나중에 바람직하지 않을 수 있다. 
• 단지 편리하다는 이유로 상속을 사용해서는 안 되며, 구현되는 일반화가 절대 변하지 않는 경우에만 상속을 사용해야 한다. 
• 클래스 다이어그램은 프로그램 설계의 정적인 기능을 표현하지만, 실행 동안 발생하는 이벤트들의 진행순서를 표현하지 못한다.

(3) 상호작용 다이어그램 (interaction diagram)

• 동적인 기능을 표현하기 위해 UML은 상호작용 다이어그램이라 총칭되는 다양한 다이어그램 유형을 제공한다. 
• 상호작용 다이어그램의 유형 중 하나 : 진행순서 다이어그램 (sequence diagram)
• 진행순서 다이어그램은 작업수행에 참여하는 객체들 사이의 통신을 묘사한다. 
• 진행순서 다이어그램은 아래쪽으로 그려진 점선을 갖는 사각형이 개체를 나타낸다. 
• 진행순서 다이어그램 속 각 사각형과 그에 연결된 점선을 함께 생명선(lfie line)이라 부르며, 객체들 사이의 통신은 해당 생명선을 연결하는 라벨 붙은 화살표에 의해 표시되며, 라벨은 요청되는 행위를 나타낸다. 
• 전체 진행 순서 다이어그램은 프레임(frame)이라 불린느 사각형으로 둘렀서 표현한다. 
• 사각형 내의 안쪽 사각형들은 상호작용 구절(interaction fragement)이라 불리며 하나의 다이어그램 안에서 택일해야 할 진행순서를 표현하기 위해 사용된다.

 

* CRC (class-responsibilty-collaboration) 카드

- UML에 속하지는 않지만 객체지향 설계의 검증에서 중요한 역할을 하는 도구

- CRC 카드 방법론은 소프트웨어 설계자가 제안 시스템상의 각 객체마다 카드 한 장씩을 만들어두었다가 시스템에 대한 시뮬레이션에서 객체들을 나타내기 위해 카드를 사용한다.

- 구조적 예행연습 (structured walkthrough)라 불리는 시뮬레이션은 설계를 구현하기 전에 설계상의 결함을 찾아내는 데 도움이 된다. 

 

3) 설계 패턴

- 설계 패턴 (design pattern) : 소프트웨어 설계에서 자주 나타나는 문제를 위해 이미 개발되어 있는 해결 방법

ex)

• 어댑터(Adapter) 패턴 : 사전 제작된 모듈로부터 소프트웨어를 구축할 때 발생하는 문제에 대한 해결 방법
• 데코레이터(Decorator) 표현 : 실행 시점의 상황에 따라 동일한 활동들을 다르게 조합하는 작업을 수행하는 시스템들을 설계하기 위한 수단 

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

 

6. 품질 보증

1) 품질 보증 범위

- 소프트웨어 품질 제어의 범위는 디버깅 작업 수준을 훨씬 넘어 소프트웨어 공학 절차의 개선, 인증 제도를 포함하는 관련 훈련 프로그램의 개발, 소프트웨어 공학의 기반 표준 확립 등 다양한 분야를 포함한다. 

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

- 품질 제어의 한 테마 : 기록 정리

• 개발 과정의 각 단계를 추후에 참조하기 위해 정확히 문서로 남기는 것은 매우 중요하다. 
• 기록이 부정확하여 후속 단계에서 사용할 때 사실과 다른 경우가 발생할 수 있다. 
• CASE 도구를 사용해 위의 문제를 해결할 수 있다. 
• CASE 도구는 다이어그램 수정이나 데이터 사전 갱신 등의 작업을 수작업으로 할 때보다 더욱 쉽게 만들어주고, 이 경우 문서 갱신이 함께 이루어져 최종 문서가 정확할 가능성이 매우 높다. 

- 품질 지향의 한 테마 : 검토(review) 

• 소프트웨어 개발 프로젝트에 관련된 여러 관계자들이 모여 특정 주제를 살펴본다. 
• 요구사항 검토, 설계 검토, 구현 검토 등 소프트웨어 개발의 전 과정에 걸쳐 검토가 일어날 수 있다. 

 

2) 소프트웨어 테스트

• 유리박스 테스트 (glass-box testing) : 테스트 대상 소프트웨어의 내부구성에 대한 지식 전제한다. (소프트웨어를 테스트하는 사람이 소프트웨어의 내부 구조를 잘 알고 있으며 이 지식을 테스트의 설계에 이용한다. )
• 유리박스 테스트의 예 ) 파레토 원리에 기초한 기법, 기초 경로 테스트
• 블랙박스 테스트 (black-box testing) : 소프트웨어 내부 구성에 대한 지식에 의존하지 않는다. (사용자의 관점에서 수행,  정확성과 시간을 기준으로 한다. )
• 블랙박스 테스트의 예 )  경곗값 분석, 베타테스트

 

(1) 파레토 원리(Pareto principe) 명제의 한 사례

- 소프트웨어상의 오류는 모여서 나타나는 경향이 있다. 

- 대규모 소프트웨어 시스템에서 소수의 모듈이 나머지 대부분의 모듈보다 더 큰 문제를 가지고 있다는 것을 경험에서 알 수 있다. 

- 소프트웨어 공학 분야에 파레토 원리를 적용해본다면, 특정 부분에 노력을 집중함으로써 보다 빨리 성과를 개선시킬 수 있다.

- 유리박스 테스트의 예

 

(2) 기초 경로 테스트 (basis path testing) 

- 소프트웨어 내의 모든 명령이 적어도 한 번씩은 실행되도록 보장하는 테스트 데이터 집합을 개발한다. 

- 유리박스 테스트의 예

 

(3) 경곗값 분석 (boundary value analysis)

- 소프트웨어가 비슷한 성능을 보이는 데이터 범위를 일컫는 동치 클래스(equivalence class)들을 식별하고, 범위의 가장자리 데이터를 테스트한다. 

- 어떤 클래스에서 오류를 찾을 가능성은 클래스 가장자리의 데이터를 사용했을 때 가장 높아진다는 것을 이용한다. 

- 블랙박스 테스트의 예

 

(4) 베타테스트 (beta testing)

- 일부 사용자들에게 베타버전(beta version)이라 불리는 소프트웨어의 예비 버전을 제공한다. 

- 오류 발견뿐만 아니라 일반 고객의 사용 소감을 얻을 수 있으며 사용 소감은 시장 전략을 개선하는 데 이용할 수 있다. 

- 블랙박스 테스트의 예

 

cf) 알파테스트 (alpha testing) : 개발자 사이트에서 수행되는 유사한 테스트

 

7. 문서

- 소프트웨어 문서 : 사용자 문서, 시스템 문서, 기술 문서

(1) 사용자 문서 (user documentation)

• 사용자들이 읽도록 만들어진 문서이다.

(2) 시스템 문서 (system documentation)

• 소프트웨어 생명주기에서 유지보수 단계에 도움이 될 수 있도록 소프트웨어 내부 구성에 대해 기술한다. 
• 주요 구성요소 중 하나는 시스템을 구성하는 모든 프로그램의 소스 버전이다. 
• 프로그램을 작성할 때 따라야 할 관행을 채택하고 있고, 이러한 관행은 특정 회사의 소프트웨어 전체에 걸쳐 일관성을 확립시키면서 , 궁극적으로 소프트웨어 유지보수 과정을 단순화시키는 데 기여한다. 
• 소프트웨어 요구사항 명세를 포함하는 설계 문서와 설계 도중 이러한 명세를 얻게 된 과정을 기술한 기록도 포함한다. 

(3) 기술 문서 (technical documentation)

• 소프트웨어 시스템의 설치와 사후관리 방법 등을 기술한다. 
• 데스크톱 컴퓨터 영역에서 기술 문서와 사용자 문서 사이의 경계가 불분명한 경우도 있다.

 

8. 인간-장비 인터페이스

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

- 인간-장비 인터페이스는 소프트웨어 개발 프로젝트의 여구사항 분석 단계에서 중요한 고려사항이다. 

- 인간-장비 인터페이스 설계 분야의 연구는 인체공하과 인지공학 등의 공학 등의 공학 영역들의 결과들을 많이 이용한다. 

• 인체공학 (erogonomics) : 사람의 신체 기능과 조화되는 시스템 설계를 다룬다. 
• 인지공학 (cognetics) : 사람의 정신 기능과 조화되는 시스템 설계를 다룬다. 

- 인체공학과 인지공학의 응용으로 인해 인간-장비 인터페이스 설계 분야는 고유한 특성을 갖게 되었지만, 이  분야에는 소프트웨어 공학의 일반적인 주제들도 많이 연관되어 있다. 

- GOMS 모델

• 인간-장비 인터페이스 설계 분야의 측도 모색의 대표적인 사례이다.
• 목표 (goal), 작업 행위(operator), 수행방법(method), 선택 규칙(selection rule)의 머리글자로 이루어진 약어이다. 
• 일련의 기본 단계들로 분석할 수 있는 방법론이다. 
• 각 기본 단계에서는 정확한 시간이 할당되며, 작업을 구성하는 단계뜰에 할당된 시간들의 합을 계산한다. 
• 이를 통해 GOMS는 제안된 여러 인터페이스에 대해 비슷한 작업의 수행에 각기 소요되는 시간으로 인터페이스들을 비교하기 위한 수단을 제공한다. 

 

9. 소프트웨어에 대한 소유권과 책임의 문제

- 소프트웨어 개발자는 자신이 만드는 프로그램에 대해 일정 수준의 소유권을 필요로 하는데, 이러한 소유권을 부여하기

위한 법률적 노력은 지적 재산권 법률의 범주에 속한다.

- 제품의 개발자는 요구사항 명세, 설계 문서, 소스 코드, 시험계힉서, 최종 제품을 포함하는 모든 작업 결과물에 저작권 안내문을 포함시킴으로써 소유권을 주장한다. 

- 개발자의 권리는 소프트웨어 라이선스 (software license) 에서 법률적 조항의형태를 갖추어 공식적으로 표현되어야 한다. 

- 소프트웨어 라이선스는 소프트웨어 제품의 소유자와 사용자 사이의 법률적 합의로서 지적재산에 대한 소유권을 이전하지 않으면서 사용자에게 제품 사용에 대한 일정한 허가를 부여한다. 

- 소프트웨어에 대한 소유권을 보호하기 위해 특허제도를 사용하기도 한다.