| [대학원] 소프트웨어 공학 개요 및 사회, 기술적 시스템 |
|
| Software Engineering | 2007/06/16 (토) 17:09 |
| |||
 1) 소프트웨어(Software)란 무엇인가?
- 많은 사람들이 소프트웨어(Software)와 컴퓨터 프로그램(Computer program)을 같은 것으로 생각하지만 정확하지는 않음.
- 소프트웨어(Software)는 프로그램(programs)뿐 아니라 관련한 모든 문서(Documents)와 프로그램이 정상적으로 동작하기 위해 필요한 설정 데이터(Configuration data)를 포함함
Software = Programs + Documents + Configuration data
Generic products
- 일반적인 목적으로 사용되는 제품으로, 필요로 하는 사용자가 시장에 나와있는 것을 구입하게 됨.
- Software Specification의 주도권은 개발조직이 가지게 됨.
예 : DB서버, 문서 편집기, 이미지 도구, 프로젝트 관리 도구 등
Bespoke (Or Customized product)
- 특정 고객에 맞도록 개발되는 제품
- Software Specification의 주도권은 사용자가 가지게 됨.
예 : 특정 전자장비의 제어 시스템, 특정 업무를 지원하는 시스템, 항공 운항 통제 시스템 등
2) 소프트웨어공학(Software Engineering)은 무엇인가?
시스템 명세(System Specification)단계와 같은 초기단계부터 시스템이 사용된 후 수행되는 유지보수에 이르기까지 소프트웨어 생산과 관련되는 공학적 분야
- 공학자들은 어떤 문제를 해결함에 있어서 가장 적합한 이론이나 방법론, 도구를 사용하려고 합니다. 기존의 해결책이 없는 경우에는 새로운 시도를 하게 되지만,
문제해결과정에서 조직이나 예산의 제한성도 고려해야 합니다.
- 소프트웨어공학은 소프트웨어를 개발하는데 있어서의 기술적 과정뿐 아니라 프로젝트 관리나 도구, 방법론 및 이론의 개발과도 관련되어 있습니다.
- 문제해결과정에서 조직적이고 체계적인 접근뿐 아니라 비정형화된 접근이 필요한 경우도 있습니다. (예 : 웹 기반 e-Commerce 시스템의 경우는 다양한 소프트웨어 기술과
그래픽 디자인 기술의 융합을 필요로 함.)
3) 소프트웨어공학(Software engineering)과 컴퓨터과학 (Computer science)의 차이점은 무엇인가?
- 소프트웨어 공학 : 소프트웨어를 개발함에 있어서 발생하는 실제적인 문제들과 관련한 것
- 컴퓨터과학 : 컴퓨터나 소프트웨어시스템의 기초가 되는 이론이나 방법론들과 관련된 것
물리학 지식이 전자공학자에게 필요하듯이 컴퓨터과학은 소프트웨어공학자에게 필수적이지만, 항상 컴퓨터과학의 이론에 따르는 것은 아닙니다.
4) 소프트웨어공학(Software engineering)과 시스템공학 System engineering)의 차이점은 무엇인가?
- 소프트웨어 공학 : 소프트웨어기반의 시스템을 주로 다룸.
- 시스템공학 : 하드웨어 개발, 정책, 프로세스 설계, 시스템 배포 및 소프트웨어공학을 포함하는 개념으로 개별 시스템 컴포넌트(하드웨어,
소프트웨어 등) 개발과 관련된 공학이 아님.
시스템공학이 소프트웨어공학에 비해 훨씬 역사가 오래되었지만, 최근 시스템의 대부분이 소프트웨어로 대체되고 있기 때문에 시스템공학에서 소프트웨어공학의 기술을
활용하기도 합니다. (예 : use-case modeling)
5) 소프트웨어 프로세스(Software Process)란 무엇인가?
- 소프트웨어 생산과 관련한 행위들과 관련 결과물의 집합
- 대부분의 소프트웨어 프로세스에 적용되는 기본적인 4단계 프로세스
 l 명세 : 소프트웨어의 기능과 동작에 대한 제약사항 정의
l 개발 : 소프트웨어 요구사항에 맞는 제품 생산
l 확인 : 고객의 요구사항에 맞는 것인지를 확인
l 진화 : 변화하는 고객의 요구사항에 맞도록 소프트웨어 변경
6) 소프트웨어 프로세스 모델(Software process model)이란 무엇인가?
l 소프트웨어 프로세스를 단순화, 추상화시킨 것.
l 소프트웨어 프로세스 모델의 종류
- Workflow model : 순서있는 일련의 활동
- Data-flow (또는 Activity) model : 데이터의 변환 과정
- Role/action model : 누가 어떤 일을 하는가를 표현
일반적인 프로세스 모델
- Waterfall Approach : 요구사항분석, 명세, 설계, 구현, 테스팅 등의 각 단계가 엄격하게 구분되어 순서대로 진행
- Evolutionary development : 명세, 개발, 검증 등을 반복하며, 초기에는 추상적인 명세로부터 시작하여 점점 명확해지며 고객이 만족하는 수준이 될 때까지 계속적으로 개발을 진행
- Formal transformation : 수학적으로 시스템을 명세하여, 정형적인 변환과정을 통해 시스템을 만들게 됨.
- System assembly from reusable components : 기존에 존재하는 컴포넌트 재사용 및 조합을 통해 시스템을 개발
7) 소프트웨어공학의 비용은 어떻게 되는가?
- 대략적으로 60%가 개발비용이고, 40%가 테스트 비용이지만, 커스터마이징이 필요한 소프트웨어의 경우는 개발 비용보다 유지보수 비용이 훨씬 많이 듦.
- 성능이나 신뢰도 수준 또는 개발되는 시스템의 종류에 따라 다양함.
- 사용한 개발 모델에 따라서도 비용이 다르게 나타남.
 8) 소프트웨어공학 방법론(Software engineering methods)은 무엇인가?
- 시스템 모델, 표기법, 규칙, 설계 조언이나 프로세스 길잡이를 포함하는 소프트웨어 개발에 대한 구조적인 접근법
- 방법론 구성요소(Method components)
 시스템 모델 설명(System model description) : 개발되어야 할 시스템 모델과 그 모델을 정의하는데 필요한 표기법에 대한 설명 예, object model, data-flow model, state model 규칙(Rules) : 시스템 모델에 항상 적용되는 제약사항들
예, 시스템 모델에서 entity의 이름은 유일해야 함.
권고사항(Recommendations) : 이 방법론을 올바르게 사용하기 위한 경험적 지침
예, 서브객체는 7개 이하로
프로세스 길잡이(Process guidance) : 시스템 모델을 개발하기 위해 따라야 할 절차들에 대한 정의
예, 속성을 정하고 나서 연산을 정의한다.
9) CASE란 무엇인가?
- Computer Aided Software Engineering의 약자
- 요구사항분석, 시스템 모델링, 디버깅, 테스팅 등의 소프트웨어 프로세스를 지원함.
- 지원하는 개발 시점에 따라 크게 2가지로 나뉨.
; upper-CASE 도구 : 분석 및 설계
; lower-CASE 도구 : 구현 및 테스팅
10) 좋은 소프트웨어의 속성들은 무엇인가?
- Maintainability : 소프트웨어는 변화하는 요구사항을 만족시킬 수 있도록 설계되어야 한다.
- Dependability : 소프트웨어는 신뢰도(reliability)가 높아야 하며, 보안(security)나 안전성(safety)도 뛰어나야 한다.
- Efficiency : 소프트웨어는 시스템의 자원을 낭비하지 않도록 효율적으로 동작해야 한다.
- Usability : 소프트웨어는 의도한대로 사용자가 사용하기 쉬워야 한다. 예: 사용자인터페이스, 문서화
11) 소프트웨어공학이 직면한 주요 과제로는 어떤 것들이 있는가?
- 오래된 시스템(Legacy system) : 수년 전에 개발되어 사용되고 있는 오래된 시스템을 비용 효율적으로 유지보수하고 업데이트 시킬 수 있어야 한다.
- 환경의 이질성 : 네트워크를 통해 분산된 환경에서 다양한 컴퓨터들과 운영체제 등에 독립적으로 동작할 수 있어야 한다.
- 품질과 생산속도 : 품질을 위해 시간을 너무 많이 투자해서는 안된다. 오늘날과 같이 빠르게 변화하는 시장에서 살아남기 위해서는 품질도 충분히
보장하면서 비용을 줄이면서도 빠르게 시스템을 개발할 수 있어야 한다.
Q1.소프트웨어공학 방법론(Software engineering methods)의 정의와 방법론의 4가지 구성요소에 대해 설명하시오.
- 정의 : 시스템 모델, 표기법, 규칙, 설계 조언이나 프로세스 길잡이를 포함하는 소프트웨어 개발에 대한 구조적인 접근법
- 방법론의 4가지 구성요소(Method components) : 시스템 모델 설명(System model description, 규칙(Rules), 권고사항(Recommendations), 프로세스 길잡이(Process guidance)
Q2.다음은 좋은 소프트웨어 속성에 관한 설명입니다. 각 설명에 해당하는 속성을 보기에서 골라 입력해 보세요.
- 설계되어 유지보수가 쉬워야 한다. [Maintainability]
- 소프트웨어는 신뢰도(reliability)가 높아야 하며, 보안(security)이나 안전성(safety)도 뛰어나야 한다. [Dependability]
- 소프트웨어는 시스템의 자원을 낭비하지 않도록 효율적으로 동작해야 한다. [Efficiency]
- 소프트웨어는 의도한대로 사용자가 사용하기 쉬워야 한다. [Usability]
 ACM, IEEE(Institute of Electrical and Electronic Engineers), British Computer Society는 기술전문가가 지켜야 할 8가지 윤리강령을 만들었는데, 그 내용은 다음과 같습니다.
- Public : 소프트웨어공학자는 대중의 이익에 부합하는 행동을 한다.
- Client & Employer : 소프트웨어공학자는 대중의 이익에 부합하는 범위 내에서 그들의 고객과 고용주의 최대 이익을 내기 위한 행동을 한다.
- Product : 소프트웨어공학자는 제품 및 관련 변경이 최대한 전문가적 기준에 부합하도록 한다.
- Judgment : 소프트웨어공학자는 그들의 전문가적 판단 아래 성실하고 독립적으로 행동한다.
- Management : 소프트웨어공학 관리자와 지도자는 소프트웨어 개발과 유지보수를 함에 있어 윤리적 접근을 지향한다.
- Profession : 소프트웨어공학자들은 대중의 이익에 부합하면서 전문가로서의 성실과 평판을 유지·발전시켜 나가야 한다.
- Colleagues : 소프트웨어공학자들은 동료에게 공평하고 협조적이어야 한다.
- Self : 소프트웨어공학자들은 그들의 전문지식을 지속적으로 공부하면서, 윤리적인 접근으로 전문가로서의 실천을 행해야 한다.
Q, 국내의 과학윤리 현황을 살펴보고 앞으로 여러분께서 해 나가야 할 과제를 생각해 보세요.
제시된 자료는 과학의 윤리적 측면에 대한 국내의 제반 활동에 대해 모니터링을 시도한 것으로 국내의 과학윤리 관련 상황이 얼마나 열악한지를 엿볼 수 있습니다. 이런 열악한 상황을 극복하기 위해 과학 연구에서의 객관성 유지, 논문 발표시의 저자 표시 (authorship) 및 공로(credit) 배분, 과학윤리 교육 및 연구 등에 좀 더 관심을 가지고 노력하여야 겠습니다.
- 침입자 경고시스템은 시스템의 한 예
- 시스템이란, 관련 요소들이 체계적으로 조직화된 집합체를 의미한다. 하나의 시스템은 여러 서브 시스템들로 구성되고, 서브시스템은 여러 컴포넌트들로 구성되며, 컴포넌트들은 더 작은 여러 컴포넌트들로 구성된다.
- 우리가 이 과목에서 학습해야 하는 것은 ‘소프트웨어 시스템’이지만 일반적으로 ‘시스템’이라 하면 소프트웨어와 하드웨어 등의 결합체를 의미한다. 최근 들어 시스템을 구성하는 소프트웨어의 비중이 점차 커지고 있으며, 시스템 관점에서의 고려 사항이 소프트웨어 개발에 큰 영향을 끼치므로 먼저 시스템 공학을 이해할 필요가 있다.
 * 시스템이란?
공통의 목적을 달성하기 위해 서로 연관되어 함께 동작하는 컴포넌트들의 집합
* 시스템의 특징?
- 시스템에 존재하는 컴포넌트들 간의 관계가 복잡하며 창발적 속성이 나타남.
- 사회-기술적 시스템은 조직의 정책이나 법률과 같은 변화하는 주변 환경과의 관계도 존재함.
시스템을 구성하는 소프트웨어의 비중이 점차 커지고 있으며, 시스템 공학에서의 문제는 소프트웨어 공학에서의 문제와 유사한 경우가 많으므로 유심히 살펴볼 필요가 있다.
* 기술적 컴퓨터 기반 시스템
하드웨어와 소프트웨어 컴포넌트를 포함하나 사용자나 작업 프로세스를 시스템의 일부로 포함하지 않는다. 즉 어떤 목적을 위해 사용하나, 목적에 대한 지식은 시스템에 포함되지 않는다.
[예] 책을 저술하고자 워드프로세서를 사용하지만 워드프로세서가 책을 저술하는 것에 관해 알 필요가 없다
* 사회-기술적 시스템
-하나 또는 그 이상의 기술적 시스템을 포함하며 또한 기술적 시스템을 이용하는 사람과 작업 프로세스를 포함한다. 중요한 점은 시스템이 어떻게 이용되는지에 관한 지식을 시스템이 포함하고 있다는 점이다.
-시스템이 작업 프로세스(operational process)를 정의하고 있으며 사람을 시스템의 일부로 포함하고 있다.
- 조직의 정책과 규칙에 지배를 받으며 법률이나 규제 정책과 같은 외적 제약사항에 의해서 영향을 받을 수도 있다.
* 사회-기술적 시스템의 특징
1) 창발적 속성을 가진다.
- 창발적 속성은 시스템이 조합된 후에 나타나는 속성이다.
2) 비결정적이다.
- 같은 입력에 대해 항상 같은 출력이 나오지는 않는다. 시스템의 행위가 부분적으로 운용자(operator)에 영향을 받기 때문이다.
3) 조직의 목표와 복잡한 관계가 있다.
- 시스템이 조직의 목표를 얼마나 지원하고 있는가는 단지 시스템만의 문제는 아니다. 목표의 안정성, 목표들 간의 관계와 충돌여부, 목표 해석의 차이도 영향을 줄 수 있다.
여러가지 부품들의 특성과 행위들이 복잡하게 연결되어 있는 시스템이 잘 작동하기 위해서는 다른 부품들과의 기능이 적절하게 연결되어 있어야 합니다. 이러한 시스템의 속성을 창발적 속성(Emergent property)이라고 합니다. 창발적 속성에는 다음 3가지 특징이 있다.
- 서브 시스템이나 컴포넌트들의 경우가 아니라 전체 시스템이 구성되었을 때 나타나는 특성
- 시스템 컴포넌트들의 상호작용 때문에 생기는 특성
- 시스템이 통합(Integration)되기 이전에는 미리 예상하기가 어려우므로 통합된 후에 평가나 측정이 가능함.
* 창발적 속성의 예
시스템의 크기(overall weight) :
- 컴포넌트의 조합 방법에 따라 달라질 수 있음
- (예) 신뢰도(reliability) - 개별 컴포넌트의 신뢰도뿐 아니라 컴포넌트 간의 상호작용에 대해서도 영향을 받음
시스템의 보안성(security)
공격에 대한 방어 능력으로 쉽게 측정할 수 없은 복잡한 속성
시스템의 수리성(repairability)
발견된 문제를 얼마나 쉽게 고칠 수 있는가를 의미
문제를 진단하고 결함이 있는 컴포넌트에 접근하여 수정 또는 교체하는 능력에 따라 좌우됨
시스템의 유용성(usability)
시스템을 얼마나 쉽게 사용할 수 있는가를 의미
시스템 하드웨어나 소프트웨어뿐 아니라 조작수 및 사용 환경까지도 고려해야 하는 복잡한 속성
각 부품이 전체 시스템의 구성요소가 될 때 나타나는 창발적 속성(Emergent property) 은 다음과 같이 크게 두 가지 종류로 나뉠 수 있습니다.
기능적 속성(Functional Properties)
- 특정 목적을 달성하기 위해 시스템의 각 구성 요소들이 협력하는 경우에 생기는 특성
[예] 자전거: 각 구성 요소들이 통합되면 교통도구라는 Functional Property를 가지게 된다.
비기능적 속성(Non-functional Properties)
- 실제 운영 환경하에서의 시스템 행위와 관련됨
- 최소한의 수준이 만족되지 못한다면 시스템 전체가 무용지물이 될 수도 있다.
[예] 신뢰도(reliability), 성능(performance), 안전성(safety), 보안(security).
신뢰도
시스템의 신뢰도에 영향을 주는 요소는 다음 3가지 입니다.
 - 신뢰도는 시스템을 둘러싼 환경에 의해서도 영향을 받습니다.
시스템 환경은 미리 예측하기 힘들며 예측하더라도 제약하기 힘듭니다.
예) 상온에서 정상적으로 동작하도록 설계된 시스템이 주변에 새로 놓인 에어컨때문에 정상 온도 범위를 벗어나게 되어 오동작하는 경우
* Shall-not 속성
앞에서 살펴본 창발적 속성의 종류 중 비기능적 속성에는 신뢰도, 성능, 안전성, 보안이 포함됩니다. 그 중, 성능과 신뢰도는 측정이 가능하지만, 안전성이나 보안과 같은 특성은 측정이 어렵기 때문에 시스템에 대한 제한요건으로서 표현됩니다. “shall-not” properties와 시스템과 환경에 대해 살펴보면 다음과 같습니다.
- 안전성(safety) : 시스템이 사람이나 환경에 위험한 영향을 주도록 동작해서는 안된다.
- 보안(security) : 허가받지 않은 사용자나 외부의 침입에 의해 시스템이 노출되지 않아야 한다.
* 계층구조
시스템은 독립적일 수 없으며 항상 특정 환경에 속하게 된다.
시스템의 동작은 주변의 환경을 변화시킬 수 있다. [예] 온열 시스템에 의한 주변 공기 온도 변화
환경은 시스템의 기능이나 성능에 영향을 미칠 수 있다. [예] 환경으로부터의 전력공급, 번개에 의한 전기 및 자기적 충격 등
물리적 환경뿐 아니라 특정 기관이나 조직과 같은 사회적인 환경도 중요하다.
* 도시에서 건물의 시스템
- 건물은 도시(town)속의 어떤 거리(street)에 위치해 있음.
- 시스템의 지역 환경(local environment)
같은 계층(level) 상의 다른 시스템들, [예] 보안 시스템(security system)의 지역 환경(local environment)은 건물 안에 있는 다른 시스템들
- 총체적 환경(overall environment)
지역 환경과 그것들을 포함하는 시스템의 환경으로 구성, [예] 건물(building)밖의 모든 다른 시스템들을 포함하며 날씨(weather system)까지 포함하는 개념
* 인간 사회적 요소
시스템이 성공적으로 운영되는데 있어서 환경은 매우 중요하며, 인간, 사회, 조직적인 요소들이 환경을 구성하고 있습니다.
- 인간 사회적 요소로 인한 영향력
; 프로세스의 변화 ->시스템이 조직의 권력구조를 변경시킬 수도 있다. 만약 시스템이 의존적인 조직이 있다면 시스템을 사용할 수 있는 사람들은 정치적인 권력을 획득하게 된다.
; 직업의 변화 -> 시스템이 사용자의 직업 능력을 변화시켜서 업무의 효율이 저하되거나 능력이 상실된다면 시스템 사용의 의미가 상실된다.
; 조직의 변화 -> 시스템이 조직의 권력구조를 변경시킬 수도 있다. 만약 시스템이 의존적인 조직이 있다면 시스템을 사용할 수 있는 사람들은 정치적인 권력을 획득하게 된다.
하지만, 엔지니어가 인간, 사회 및 조직적 요소와 시스템간의 영향력 정도를 미리 측정하기는 다소 어려운 감이 있습니다. 따라서 이러한 측도를 위한 방법론이 개발되었습니다.
Tips : 완벽을 기한다면 시스템 명세에 환경적 요인을 포함해야 하나, 사실상 불가능하므로 시스템 설계자는 상식선에서 다른 시스템들과 비교하여 가정할 수 밖에 없습니다.
방법론 1 Mumford’s sociotechnics (Mumford, 1989)
방법론 2 Checkland’s Soft System Methodology
(Checkland,1981; Checkland and Scholes, 1990)
Q1. 시스템 엔지니어가 환경을 이해해야 하는 이유는 무엇입니까?
시스템은 환경을 바꾸어 놓을 수 있으며, 환경에 의해 지배받기도 합니다.
[예] 전열 시스템은 온도를 변화시키며, 전력 공급이 끊기면 작동할 수 없다.
Q2.창발적 속성(Emergent properties)의 의미를 설명하시오.
Emergent properties이란 서브시스템이나 컴포넌트의 경우가 아니라 전체 시스템이 구성되었을 때 나타나는 특성을 의미합니다. 이는 시스템 컴포넌트들의 상호작용 때문에 생기는 것으로, 주로 시스템이 통합된 후에 평가나 측정이 가능합니다.
시스템 공학이란?
- 사회-기술적 시스템을 명세, 설계, 구현, 확인, 배치, 그리고 유지보수하기 위한 활동
- 시스템이 제공하는 서비스, 시스템의 개발과 작동사의 제약 사항, 그리고 시스템이 사용되는 방법을 고려해야 함
시스템 공학 프로세스와 소프트웨어 공학 프로세스의 차이점
- 보통 폭포수 모델을 사용함. 시스템의 여러 부분들을 동시 개발해야 할 필요성 때문임.
- 하드웨어 변경 비용은 매우 비싸기 때문에 개발 작업을 반복하는 경우는 매우 제한적임. 이러한 이유로 시스템에서 소프트웨어의 중요성이 부각됨
- 여러 다른 분야 엔지니어들과의 공동 작업은 불가피함. 타협이 필요하기도 함.
시스템 요구사항과 설계 활동의 결과로 전체 시스템의 구성을 보여주는 시스템 아키텍쳐 모델을 만듭니다. 시스템을 기능에 따라 서브시스템들로 분류하고 관계를 표현하는데 주로 블록 다이어그램으로 나타내고 서브시스템 별로 간단한 설명을 붙입니다.
- 전통적으로 시스템 아키텍쳐 모델은 병행 개발될 수 있는 하드웨어와 소프트웨어 컴포넌들을 구분하기 위한 것이었으나, 오늘날 시스템에서의 하드웨어와 소프트웨어의 구분이 모호해지면서 하드웨어와 소프트웨어의 trade-off에 대해 결정하기 이전에 각 서브시스템들을 기능에 따라 구분을 하기 위한 수단으로 사용되고 있다.
- 하드웨어로 개발할 것인지 소프트웨어로 개발할 것인지에 대한 결정은 기성(commercial-off-the-shelf) 컴포넌트의 가용성과 컴포넌트 개발에 허용된 시간 등을 고려해 차후에 결정
시스템 아키텍처 모델링의 역할
- 시스템을 구성하는 서브시스템들의 추상적인 뷰(abstract view)를 제공한다.
- 서브시스템들 사이에서 발생하는 관계나 주요 정보의 흐름을 보여준다.
- 주로 블록 다이어그램(block diagram)으로 표현된다.
- 모델에서의 컴포넌트의 종류를 구분해준다.
시스템 아키텍처 모델링은 서브시스템들 사이에서 발생하는 관계(주로“uses/used by”관계나 다른“dependency”관계)를 표현하며, 이때 정보의 흐름은 화살표로 나타냅니다.
시스템을 구성하는 서브시스템들은 여러가지 기능 측면을 고려하여 분류할 수 있습니다. 먼저, 단순한 침입 경보 시스템에 대해 살펴보겠습니다.
 
출처 : http://blog.empas.com/shone2210/21682553 |
'UP! > Software Engineering' 카테고리의 다른 글
| 개발의 중요문제 (0) | 2008.08.21 |
|---|---|
| 시스템분석가의 역할 (0) | 2008.08.21 |
| 소프트웨어와 소프트웨어 공학 (0) | 2008.08.21 |
| 시스템의 특성 (0) | 2008.08.21 |
| 분산시스템아키텍처 (0) | 2008.08.21 |
