Sommerville 교재 문답 40

1. 아래는 Software engineering 에 대한 정의이다 아래 정의 내에서 밑줄 친 engineering discipline , all aspects of software production 이라는 두 구문이 갖는 의미를 간단히 설명해 보시오

Software engineering is an engineering discipline that is concerned with all aspects of software production.

엔지니어는 언제나 이론과 방법, 도구를 적절하게 선택하고 문제에 적용하여 제약 조건 안에서의 해결책을 얻으려고 하는데, 이를 engineering discipline이라고 한다. 그리고 All aspects of software production이란 소프트웨어 공학이 단지 소프트웨어 개발의 기술적인 절차뿐만이 아니라 소프트웨어 프로젝트 관리와 소프트웨어 생산을 지원하기 위한 도구, 방법, 이론의 개발까지 포함한다는 의미이다.

 

2. 소프트웨어 는 크게 Generic Product 와 Customized Product 의 두 가지 형태로 분류해 볼 수 있다 이들 두 가지 형태가 소프트웨어 개발 과정의 측면에서 보았을 때 가지는 차이점을 설명해 보시오

Generic product는 개발사가 자체적으로 만들어 일반 시장에 판매하는 소프트웨어를 말하고, customized product는 개발사가 고객의 요구에 맞추어 만드는 소프트웨어를 말한다. Generic product의 requirement의 specification은 개발사에 의해 결정되고 소프트웨어 수정이 개발사에 달려있지만, customized product의 requirement의 specification이 고객에 의해 결정되고 소프트웨어 수정이 고객에 달려있다는 차이가 있다.

 

3. 좋은 소프트웨어의 기본적인 속성들에 대하여 설명해 보시오

좋은 소프트웨어는 Maintainability, Dependability, Efficiency, Acceptability를 보장해야 한다. Maintainability는 고객의 변화하는 요구를 만족시킬 수 있어야 함을 의미한다. Dependability는 시스템 실패가 일어나지 않고, 악성 사용자가 시스템에 접근하여 해를 입히지 않도록 하는 것으로, Reliability, Security, Safety와 같은 특성들을 포함한다. Efficiency는 시스템의 자원을 낭비하지 않아야 한다는 특성이다. Acceptability는 사용자가 소프트웨어를 잘 이해하고, 사용하기 쉽고, 다른 시스템과 호환되어야 함을 의미한다.

4. Software Process 는 다양한 형태의 Process가 존재한다 그러나 모든 Process가 공통으로 가지게 되는 Activity 들이 있다 이에 대하여 설명해 보시오

Software Process가 공통적으로 가지게 되는 Activity는 Software specification, Software development, Software validation, Software evolution이다. Software specification에서는 고객과 엔지니어가 앞으로 만들 소프트웨어와 제약 조건들을 정의한다. Software development에서는 소프트웨어를 설계하고 구현한다. Software validation에서는 그 소프트웨어가 고객의 요구사항을 만족하는지 보장하기 위해 확인한다. 마지막으로 Software evolution에서는 소프트웨어가 고객과 시장의 변화하는 요구사항을 반영하도록 수정된다.

 

5. 모든 유형의 소프트웨어에 대해서 항시 공통적으로 적용할 수 있는 소프트웨어 공학 기술이 존재하기는 어려우며, 소프트웨어의 유형에 따라 적용할 수 있는 기술의 종류가 달라지게 된다. 이를 설명하는 간단한 사례를 제시해 보시오

소프트웨어 유형에 상관없이 공통으로 적용할 수 있는 소프트웨어 공학 기술은 존재하기 어렵다.  간단한 사례를 들자면, 항공기에 들어가는 실시간 소프트웨어는 개발이 시작되기 전에 완전하게 명세화되어야 하는 반면, 전자상거래 시스템에서는 명세화와 구현이 보통 함께 일어나야 한다. 소프트웨어의 유형에 따라 이러한 활동들은 다른 방법으로 구성되고 또 다른 세부 수준에서 묘사된다.

 

6. Web 의 발전이 Software engineering에 미치는 영향에 대하여 간단히 설명해 보시오

Web의 발전으로 웹 기반 시스템이 엔지니어링 되는 방식에도 영향을 미쳤다. 첫째로, 소프트웨어 재사용이 웹 기반 시스템을 만드는 지배적인 접근법이 되었다. 둘째로, 모든 요구사항들을 미리 명세화하는 것은 비현실적이라는 것을 인식하게 되었으며, 소프트웨어 개발과 전달이 점진적으로 이루어지게 되었다. 셋째로, 웹 브라우저의 제약으로 유저 인터페이스가 제한을 받게 되었다.

 

7. Software Process 와 Software process Model 에 대하여 설명해 보시오

Software Process는 소프트웨어의 생산으로 이끌어지는 연관된 Activity들의 집합이다. Software Process에는 Software specification, Software Design and implementation, Software validation, Software evolution 등 네 가지 Activity가 있다.

Software Process Model은 Software Process의 단순화된 표현으로, 프로세스를 특정 관점에서 바라본 부분적인 정보만 제공한다. SW Process Model의 예로는 Waterfall Model, Incremental Development, Reuse-oriented Software Engineering 등이 있다.

 

8. Software Process 를 문서로 기술하는 경우 어떤 내용들이 기술되어야 하는지 설명해 보시오

Software Process의 설명은 Products(생산물), Roles(역할), Pre- and Post- Conditions(전후 조건)를 포함하여야 한다. Products는 Process Activity의 결과물이다. Roles는 프로세스에 포함된 사람들의 역할을 반영한다. Pre- and Post- conditions는 Process Activity의 전후나 생산물이 생산되었을 때를 나타내는 문장이다.

 

9. Waterfall model 의 장 단점을 설명해 보시오

Waterfall model은 다른 엔지니어링 프로세스 모델과 일관성이 있으며, 문서화가 각 단계마다 이루어지므로 프로세스가 뚜렷이 보여 관리자가 개발 단계의 진행을 모니터할 수 있다.

그러나 프로젝트가 각 단계로 융통성 없이 분할되고, 프로세스의 초기 단계에서 요구사항이 확정되므로 고객의 요구사항을 즉각적으로 바꾸는 것이 어렵다.

 

10. Incremental development model 의 장단점을 설명해 보시오.

Incremental development model에서는, 고객의 요구사항을 수정할 때의 비용이 줄어들고, 고객의 피드백을 받기 쉬우며, 소프트웨어의 빠른 전달이 가능하여 고객이 더 빠른 시점에 가치를 얻을 수 있게 된다.

그러나 프로세스가 보이지 않아 관리자가 진행을 알 수 있도록 정기적으로 전달을 해야 하며, 정기적인 수정이 시스템 구조를 변질시키는 문제점이 있다. 규모가 크고 복잡하고 수명이 긴 시스템에서는 서로 다른 팀이 서로 다른 부분을 개발하므로 안정된 프레임워크나 아키텍처가 요구되어 Incremental development model은 적합하지 않다.

 

 

11. Software 개발 시 변화에 대처하는 방법으로 Prototyping 과 Incremental delivery 가 있다 이들은 변화에 대처하는 방법의 관점에서 불 때 어떤 차이점이 있는지 설명해 보시오

변화에 대처하는 방법에는 Change avoidance, 즉 변화를 피하는 방법과, Change tolerance, 즉 상대적으로 낮은 비용으로 변화를 수용하는 방법이 있다.

Prototyping은 Change avoidance 방법을 사용한다. Prototyping에서는 소프트웨어를 만들기 전에 프로토타입을 만들어 사용자가 시스템을 미리 경험해 볼 수 있도록 하여 변화를 피한다.

Incremental delivery는 Change avoidance와 Change tolerance 방법을 둘 다 사용한다.  Incremental delivery는 개발된 증분을 고객에게 전달하여 이른 시기에 요구사항을 확정하는 것을 피한다. 그리하여 상대적으로 낮은 비용으로 수정이 가능하게 한다.

 

12. Reuse-Oriented Software Engineering 에서는 하나의 소프트웨어 개발 프로세스 모델에서 기본적으로 두 번의 서로 다른 Requirement Engineering 과정이 필요하게 된다. 그 이유를 설명해 보시오

Reuse-Oriented Software Engineering에서는 Requirement specification을 바탕으로 그 이후에 Requirement Modification이 추가로 일어난다. 재사용할 컴포넌트를 탐색한 후에 그 컴포넌트에 대한 정보를 바탕으로 컴포넌트가 요구사항에 반영될 수 있도록 요구사항이 분석되고 수정되어야 하기 때문이다.

 

13. Software design and implementation activity 에 대하여 설명해 보시오

Software design은 구현되어야 할 소프트웨어의 구조, 시스템에 의해 사용되는 데이터 모델과 구조, 시스템 컴포넌트들 사이의 인터페이스, 사용된 알고리즘에 대한 설명이다. 여기에는 Architectural design, Interface design, Component design, Database design 등이 있을 수 있다.

Software implementation은 Software specification을 프로그래밍을 통해 실제 실행 가능한 시스템으로 바꾸는 것이다.

 

14. Rapid Software development 와 Agile method 와 의 관계를 설명해 보시오

Rapid Software development에서는 Specification, design, implementation이 겹쳐서 일어나고, 시스템은 버전의 연속으로 개발되며, 유저 인터페이스는 IDE와 그래픽 도구로 빠르게 만들어진다.

Agile method는 incremental 개발 방법으로, 증분이 작고 보통 2~3주마다 고객에게 새로운 시스템이 전달된다. 그리고 고객을 개발 단계에 포함하여 수정된 요구사항에 대해 피드백을 빠르게 받을 수 있다. 격식 있는 회의보다는 격식 없는 의사소통을 통해 문서화를 최소화한다. Agile method는 동작하는 소프트웨어를 고객에게 빠르게 전달 가능케 하므로 Rapid software development를 만족하는 방법이다.

 

15. Agile manifesto 란 무엇인지 설명해 보시오

Agile manifesto는 Agile method를 주도하는 많은 개발자가 동의하여 만들어졌다. 이에 따르면, 절차와 도구보다는 사람과 상호작용을, 포괄적인 문서화보다는 동작하는 소프트웨어를, 계약 절충보다는 고객과의 공동 작업을, 계획을 따르기보다는 변화에 반응하는 것이 중요시해야 한다.

 

16. Plan-driven 과 Agile approach 중 어느 쪽을 선택할지에 대한 기준에 대하여 요약하여 설명해 보시오

 구현 전에 명세화가 자세하게 되어야 하고, 많은 분석이 필요하고, 수명이 길고, 개발 팀이 분산되어 있고, 전통적으로 plan-based 개발 문화였고, 시스템이 외부 규제를 받는다면 Plan-driven development가 적합하다.

 고객에게 소프트웨어 전달과 피드백이 빠르게 이루어져야 하고, 시스템 규모가 작고, 설계 진화를 위한 좋은 도구가 있고, 개발 팀의 실력이 높다면 Agile development가 적합하다.

 

17. Extreme programming 을 Software Process model 의 관점에서 설명해 보시오

Extreme programming는 다음과 같은 순환을 반복한다. 우선 User Stories를 선택한다. 그 후 User Stories를 Task들로 나눈다. 계획을 릴리즈하고 개발/통합/테스트를 한다. 소프트웨어를 릴리즈한다. 시스템을 평가하고 다시 User Stories를 선택한다.

 

18. Extreme programming 을 Software Design & Implementation Activity관점에서 설명해 보시오

Extreme programming에서 Design은 현재 요구사항을 만족시키는 선까지만 단순하게 한다. 그리고 테스트가 구현보다 먼저 작성된다. 또한 리팩터링이 자주 일어난다. Implementation에서는 개발자가 짝을 지어 Pair programming을 한다. 이 때 남의 코드를 허락 없이 수정할 수 있으며, task에 대한 일이 끝나자마자 통합된다. 통합된 후에는 시스템의 모든 unit test를 통과해야 한다.

 

 

19. Extreme programming 을 적용하는 경우 자동화된 Test 도구의 도입이 필요하다 그 이유를 설명해 보시오

Incremental Development은 Plan-driven에서보다 testing이 informal하다. 이 문제점을 해결하기 위하여 Extreme programming은 Test-first development를 하는데, 이를 위해서는 자동화된 test 도구가 필요하다. 테스트가 자동화되면 빠르고 쉽게 테스트를 실행할 수 있기 때문이다.

 

 

20. Scrum 방식에서 Scrum master의 역할이 Plan-Driven개발 방식의 프로젝트 관리자의 역할과 다른 점을 설명해 보시오.

Scrum 방식에서는Plan-driven에서의 프로젝트 관리자와 달리 팀 전체에게 결정을 내릴 권한이 주어진다. Scrum master는 관리자라기보다는 중재자의 역할이다. 일일 회의를 주관하고, 앞으로 해야 할 일을 추적하고, 결정을 기록하고, 일이 얼마나 진행되었는지 측정하고, 고객과 의사소통하고 팀 외부의 일을 관리하는 역할을 한다.

 

 

21. Scrum 방식과 Extreme programming 방식을 결합해서 사용한다면 그 형태가 어떤 식이 될지 간단히 설명해 보시오

Scrum은 iterative development를 관리하는 방법이고, Extreme programming은 기술적 접근 방법이다. Scrum을 Extreme programming과 결합해서 사용할 때, Scrum은 프로젝트를 위한 management framework가 되고, 그 안에서 pair programming과 test-first development 같은 extreme programming practice들을 사용하는 형태가 될 것이다.

 

22. 본인이 은행의 자동인출기에 들어가는 소프트웨어 시스템에 대한 Requirement Specification 을 수행하고 있다고 가정하고 소프트웨어 시스템이 만족해야 하는 Functional Requirement 한가지를 임의로 선택하여 User Requirement 수준에서 기술해 보시오. 기술 방식은 자연어 방식이고 2- 3줄 이내의 문장으로 기술하시오

사용자는 사용하고 싶을 때에 자동인출기에 접근하여 출금하고 싶은 액수를 입력하여 자신의 계좌에서 출금을 할 수 있다.

 

23. 22번에서 본인이 기술한 Requirement 가 어떤 이유에서 User Requirement 라고 볼 수 있는지 설명해 보시오

User Requirement를 읽는 사람들은 시스템이 어떻게 구현되는지 신경 쓰지 않는다. 위의 Requirement는 시스템에 관한 것은 기술하지 않고 사용자의 행동만을 묘사하였기 때문에 User Requirement라고 볼 수 있다.

 

24. 본인이 은행의 자동인출기에 들어가는 소프트웨어 시스템에 대한 Requirement Specification 을 수행하고 있다고 가정하고 소프트웨어 시스템이 만족해야 하는 Non-Functional Requirement 중 Operational Requirement 로 분류될 수 있는 Non-Functional Requirement 한 가지를 임의로 선택하여 제시해 보시오

자동인출기 소프트웨어 시스템의 사용자는 체크카드나 통장, 그리고 패스워드 입력을 통해 본인 인증을 거쳐야 한다.

 

25. www.upedu.org 사이트에 제시되어 있는 UP Software Process 에서 Requirement document 는 어떤 Requirement specification 방법에 의하여 어떤 형식으로 작성하는지 간단히 설명해 보시오

UP Software Process에서 Requirement document는 숫자가 붙은 자연어 문장으로 기술되었으므로 Natural language sentences 방법으로 작성되었다고 할 수 있다. 또한 Use Case 부분은 Graphical notations이라고 할 수 있다.

 

26. Requirement management 란 무엇인지 정의해 보고, 자신의 정의에 입각하여 Requirement management 를 위해서는 왜 자동화 도구가 필요한지 설명해 보시오

Requirements management는 System requirements의 변화를 이해하고 컨트롤하는 절차이다. 각 요구사항들을 기록하고 독립적인 요구사항들 간의 연결을 유지해야 한다. 많은 양의 정보 처리를 포함하므로 도구 지원이 필요하다. Requirement을 안전하게 저장하고, Change management를 간편하게 하고, Traceability를 관리하기 위해서 자동화 도구가 필요하다.

 

27. Requirement management 중 Change management process 에 대하여 설명해 보시오

Change management process는 change의 중요성과 비용을 평가하는 일련의 activities의 집합이다. Requirement 수정이 받아들여야 하는지를 결정한다. Change management process는 총 세 단계로 구성되는데, 먼저 문제를 분석하고 수정할 부분을 작성한다. 그 다음 수정할 부분을 분석하고 비용을 계산한다. 그 결과에 따라 필요하다면 구현을 수정한다.

 

28. 일반적으로 Requirement Engineering 을 위해서는 Context Model 을 만들게 된다. 그리고 단순한 Context model과는 별도로 Business process model 을 같이 만들게 된다. 이렇게 하는 이유를 설명해 보시오

Context model은 시스템들 간의 관계의 종류는 보여주지 않는다. 따라서 외부시스템들과의 데이터 공유나 어떤 식으로 연결되어 있는지는 볼 수 없다. 따라서 Business process model과 같은 다른 모델과 함께 사용하면 사람과 특정 소프트웨어 시스템이 사용되는 자동화된 프로세스를 함께 볼 수 있다.

 

29. 특정 System에 대한 Interaction model 은 여러 가지 관점에서 여러 가지 유형의 모델을 만들 수 있다 이에 대하여 설명해 보시오 

Interaction model은 여러 가지 유형으로 만들 수 있다. 우선 Use case modeling처럼 User input과 output을 포함하는 User interaction 모델을 만들 수 있다. 또한 개발되는 시스템과 다른 시스템 사이의 interaction이나 시스템 구성요소 간의 interaction을 나타내는 모델을 만들 수도 있다. 이 둘은 sequence diagram으로 표현할 수 있다.

 

30. 은행의 자동인출기에 들어가는 소프트웨어 시스템에 대하여 Context Model, Structural Model, Behavioral Model 의 세가지 모델을 만드는데 모델은 자연어 문장으로 표현한다고 가정하시오. 이에 대해서 각각의 모델에서 표현하고 있을 것이라고 생각되는 내용 중 한 가지 씩을 임의로 선택하여 제시해 보시오(표현에 사용하는 기능 및 구성 요소는 임의로 선택하시오. 답은 각 모델에 대하여 2 -3 줄 정도의 문장으로 표현할 수 있는 범위의 내용을 선택하시오)

Context Model 은 다음과 같다.

“개발하고 있는 현재 시스템은 은행의 계좌 관리 시스템(은행의 계좌 잔액과 이자율 등을 관리하는 시스템)과 연결되어 있다.”

Structural Model은 다음과 같다.

 “은행 이용자는 한 명당 여러 개의 체크 카드를 가질 수 있다. 체크 카드 하나당 하나의 통장정리가 가능하다.”

Behavioral Model은 다음과 같다.

 “사용자가 출금하고 싶은 액수를 입력한다. 액수를 입력 받으면 화면에 그 액수를 출력한다. 그 액수를 확인하고 확인 혹은 취소를 한다. 그 입력에 따라 출금 절차를 진행한다.”

 

31. MDA(Model Driven Architecture)에 대하여 간단히 설명해 보시오

MDA는 모델에 초점을 맞춘 소프트웨어 설계와 구현에 관한 접근법으로, 시스템을 묘사하는데 UML 모델의 일부분을 사용한다. 다른 레벨의 abstraction들이 생성되며, Computation Independent Model, Platform Independent Model, Platform Specific Model 등을 만드는 것이 추천된다.

 

32. Software Architecture 를 정의해 보시오

소프트웨어 아키텍처는 어떻게 시스템이 구성되는지, 전체적인 시스템 구조를 나타낸 것이다. 아키텍처 설계는 소프트웨어 설계 프로세스의 첫 번째 단계이다. 소프트웨어 아키텍처는 Performance, robustness, distributability, maintainability에 영향을 미치므로 중요하다.

 

33. Software Architecture 를 명확하게 정의함으로써 생기는 장점을 설명해 보시오

소프트웨어 아키텍처는 high-level presentation이고, Stakeholder communication에 사용될 수 있다. 또한 아키텍처를 시스템 개발 초기 단계에서 만들면 analysis를 하게 되고, 주요한 요구사항을 만족하는지 아닌지를 확인할 수 있다. 그리고 시스템 아키텍처는 비슷한 시스템과 요구사항이 같아 재사용이 가능한 장점이 있다.

 

34. Architecture 와 시스템의 Non-functional requirement 관계를 두 가지의 임의로 선택한 Non-functional requirement 를 예로 들어서 설명해 보시오

Security를 보장하기 위해서는 Architecture에 레이어 구조가 사용되어야 한다. 레이어에서 가장 안쪽에는 중요한 자산을 배치하여 Security를 보장한다.

Performance를 보장하기 위해서는 주요 operation들은 분산시키지 않고 몇몇 component로만 localize해야 한다. 구성요소 간 커뮤니케이션을 줄이면 성능을 높일 수 있기 때문이다.

 

35. Model-View-Controller Architecture pattern 에 대하여 설명해 보시오

Model-View-Controller 아키텍처 패턴에서는 Presentation과 Interaction을 System data로부터 분리한다. 이 패턴은 서로 상호작용하는 세 논리적 구성요소로 구성된다. Model은 System data와 연관 operation을 관리한다. View는 data가 사용자에게 보여지는 모습을 정의한다. Controller는 user interaction을 관리하고, View, Model에 interaction을 넘겨주는 역할을 한다.

 

36. Pipe and filter architecture pattern 에 대하여 설명해 보시오

시스템에서 자료 처리는 각 처리 컴포넌트(필터)가 이산적으로 자료 변환의 한 유형을 처리하도록 구성된다. Pipe and filter는 이해하기 쉽고, 변환 재사용을 지원하는 장점이 이다. 하지만 변환 사이에 자료 전달 방식이 동의되어야만 하고 input/output을 parse/unparse할 때 오버헤드가 발생하는 문제점이 있다.

 

37. Application architecture pattern 을 사용함으로써 얻을 수 있는 장점에 대하여 설명해 보시오

Application architecture pattern은 아키텍처 설계의 시작점으로 사용될 수 있으며, 설계의 체크리스트로 쓰일 수 있고, 개발 팀의 일을 구성하는 방법이 될 수 있으며, 재사용을 위한 컴포넌트 평가의 방법으로 사용될 수 있는 장점이 있다.

 

38. Transaction Processing System 에 대한 Application Architecture Pattern 에 대하여 설명해 보시오

Transaction Processing System은 input, processing, output을 거치는 pipe and filter 아키텍처로 구성될 수 있다. TP system에서는 User가 asynchronous한 요청을 보내면 시스템이 처리해야 하므로 pipe and filter 아키텍처가 적절하다.

 

39. 여러 가지 종류의 객체 지향 설계 방법들이 존재하지만 이들 방법들이 공통적으로 가지고 있는 Activity 들이 있다 이중 아래의 Activity 에 대하여 설명해 보시오

"Identify the principal system objects"

이 Activity는 설계하고 있는 시스템의 필수 객체를 생각하는 Activity이다. Use case description이 객체와 operation을 생각해내는 것을 도와줄 수 있다. 객체지향 시스템에서 객체를 도출하는 방법으로는, 자연어로 기술된 문장에서 문법적으로 분석하여 명사는 객체나 특성, 동사는 operation, 서비스로 생각하는 방법과, 시나리오 기반 분석 등이 있다.

 

40. 객체 지향 설계 방법의 결과물로 만들어 지게 되는 설계 모델에 대하여 설명해 보시오

설계 모델은 객체 혹은 객체 클래스를 보여준다. 또한 entity들 사이의 연관과 관계도 보여준다. 설계 모델은 abstract하게 만들어야 하며, 불필요한 것들로 인하여 시스템 요구사항과 설계 모델 사이의 관계가 숨겨지면 안 된다.