[1장] 소개
1. 소프트웨어의 특징과 그 유형에 대하여 설명하시오.
- 소프트웨어의 특징 : 비가시성, 유연성, 순응성, 변경성, 복잡성
- 유형 : 주문형 소프트웨어, 패키지 소프트웨어, 임베디드 소프트웨어
| 소프트웨어의 종류 | 특징 | 사용되는 카피의 수 | 요구되는 하드웨어 성능 |
개발 인력 |
| 주문형 소프트웨어 | 주문형으로 각자에게 맞는 프로그램을 제공하기에 사용되는 범위가 적고, 용도가 한정되어 있다. | 적다 | 낮음 | 많다 |
| 패키지 소프트웨어 | 패키지화해서 상업적으로 판매하는 소프트웨어 (엑셀, 한컴, 워드, notion 등) |
중간 | 높음 | 중간 |
| 임베디드 소프트웨어 | 다른 시스템에 내장된 소프트웨어 | 많다 | 낮다 | 적 |
2. 개발작업의 특징에 대하여 설명하시오.
- 소프트웨어는 단순 공장에서 찍어내는 것이 아니기에 다음과 같은 어려움이 있다.
1) 명세화의 어려움 - 고객의 요구사항을 정확하게 명세화 시키기 어렵다.
2) 재사용의 어려움 - 요구한 코드를 완벽히, 재사용하기 어렵다. <- 그렇기에 java, C#,C++과 같은 객체지향언어가 탄생
3) 예측의 어려움 - 소프트웨어가 현장에서 잘 작동하는지, 어떤 에러가 나는지 예측하기가 쉽지 않다.(Exception 예측의 어려움)
4) 유지보수의 어려움 - 다른 사람이 개발한 소프트웨어를 쉽게 이해하기 어렵고, 고치더라도 다른 부분에서 오작동이 날 가능성이 있다.
5) 고품질의 어려움 - 모든 상황에 맞추어 원하는 품질을 찍어내기가 어렵다.
3. 소프트웨어 위기의 원인은?
- 소프트웨어 위기는 수요가 증가하고 소프트웨어의 복잡성도 증가하였으나, 기존 방법은 충분하지 않아서 벌어지게 되었다. ex) 요구 증가, 복잡도 증가, 난이도 증가, 같은 인력, 같은 방법, 같은 도구
4. 즉흥적인 SW개발의 문제점은?
- 여러 문제점이 있으나 주요 문제는 다음과 같다.
1) 개발 지연과 예산 초과
2) 낮은 품질
3) 유지보수 곤란
4) 재작업으로 인한 손실
5. 소프트웨어공학을 정의하면?
- 소프트웨어의 lifeSycle의 모든 것에 해당하는 것. 즉, 소프트웨어의 개발과 운영, 유지보수, 소멸에 대한 접근 방법
6. SW공학의 목표는?
위의 즉흥적인 SW개발의 문제를 해결하는 내용들이다.
1) 개발 기간 단축과 예산 절감
2) 높은 품질
3) 훌륭한 유지보수
4) 높은 효율
7. Validation과 Verification을 비교하여 설명하면?
Validation, 검사는 사용자의 입장에서의 시스템 검증 과정이며, 사용자의 요구사항을 충족했는지 검사한다.
Verification, 검증은 개발자의 입장에서의 시스템 검증 과정이며, 과정을 잘 지켰는지를 확인한다.
8. 프로젝트 관리 관점에서 프로젝트의 세가지 제약은?
시간, 비용, 범위
9. 방법/도구/프로세스/패러다임의 의미는?
방법(method) : 소프트웨어 제작에 사용되는 기법이나 절차
도구(tool) : 자동화된 시스템
프로세스(process) : 도구와 기법을 사용하여 작업하는 순서
패러다임(paradigm) : 접근 방법, 스타일
- 번외 - 각각의 사례
방법 - 구조적 분석, 설계방법 / 객체지향 분석, 설계방법
도구 - 설계 도구, 프로그래밍 도구, 테스트 도구
프로세스 - Unified Process / eXtreme Programming
패러다임 - 구조적 방법론 / 객체지향 방법론
10. 소프트웨어공학 지식체계(SWEBOK)에 대하여 설명하시오.
Software Engineering Body of Knowledge의 약자로, IEEE 산하의 표소프트웨어 표준위원회가 만든 SW엔지니어링, SW관리측면에 중요한 10개의 주요 지식 영역을 규정하고 있다.
SW 엔지니어링 측면 : SW요구사항, SW 설계, SW개발, SW 테스트, SW유지보수
SW 관리 측면 : SW 형상관리, SW관리, SW프로세스, SW툴, 방법론, SW품질
11. 좋은 소프트웨어가 가져야 할 특성에 대하여 설명하시오.
평가하는 입장에서는 다르나, 품질이 높고 사용자요구를 만족시키며 결함이 포함되지 않아야 한다. 또한 생산 비용이 적고 개발 기간이 짧아야 한다.
[2장] 프로세스와 방법
12. 소프트웨어 생명주기란?
소프트웨어를 계획, 개발, 시험, 채용하는 과정을 포함하는 모델이다.
요구분석 -> 설계 -> 구현 -> 테스팅 -> 유지보수 단계로 이루어져 있으며, 소프트웨어는 계속해서 변형되고 개발되며 사용되다 소멸하는 특징이 있다.
13. 좋은 프로세스의 특징을 설명하시오.
좋은 프로세스의 특징은 다음과 같다.
1) 예측 가능성 : 프로세스에 입력값을 주면 출력값이 명확해야 하며, 이를 근거로 어떤 값을 넣을때 어떤 결과가 나올지 예측 가능해야 한다.
2) 테스팅, 유지보수 용이성 : 전체 비용을 절감하기 위해서는 유지보수가 용이해야 한다. 테스팅도 마찬가지로 테스팅을 하기 편해야 어디를 보수해야할지 명확하기에 테스팅, 유지보수를 하기 용이해야 한다.
3) 변경 용이성 : 소프트웨어는 요구분석, 설계단계의 내용 그대로 구현되는 것이 아니라 중간에 변형되는 경우가 있다. 이 때 변경하기 쉬워야 한다.
4) 결함 제거 용이성 : 오류는 항상 일어날 수 있고, 오류를 수정하기 위한 비용은 시간이 지나 소프트웨어를 완성할 수록 높아진다. 그렇기에 오류를 확인 후 제거하기 쉬우면 프로세스를 개발할 때 비용이 적게 들기에 결함을 제거하기 용이해야 한다.
14. 프로세스 모델들에 대하여 설명하시오. - 폭포수 모델 - V 모델 - 프로토타이핑 모델 - 진화적 모델 - 나선형 모델 - Unified Process - 애자일 프로세스
폭포수 모델 - 개발 단계를 선형적으로 진행하는 방식이다. 요구 사항 분석, 설계, 구현, 테스트, 유지보수 등의 단계를 순차적으로 진행한다.
V모델 -폭포수 모델의 확장판, 각 개발 단계에 대응하는 검증/확인 단계를 갖춘 모델이다. 검증 단계를 가진다
프로토타이핑 모델 - 프로토타입을 만들어서 검증하고 빠르게 제작하는 것이 특징이다.
진화적 모델 - 여러개의 주기로 나눠서 점진적으로 개발해 나간다
나선형 모델 - 위험관리를 강조하였으며 각 원을 그리면서 시스템이 완성된다. 원의 크기가 커질 수록 기간이 길어진다
Unified Process - UML을 사용해서 개발하며 반복적인 개발 주기를 진행한다
에자일 프로세스 - 변화에 빠르게 대응하고 고객의 요구 사항을 최우선으로 하는 방식을 지향합니다. 작은 팀이 협력하여 짧은 주기의 개발 과정을 거치며, 매 주기마다 작동 가능한 제품을 제작하고 이를 고객에게 전달하여 피드백을 받는다.
15. ISO/IEC 12207에서 프로세스 그룹을 설명하시오
ISO/IEC 12207은 소프트웨어 및 시스템 엔지니어링 프로세스 표준으로, 소프트웨어 및 정보 시스템 생명주기의 프로세스와 활동을 정의한다. 공급자 프로세스 그룹, 고객 프로세스 그룹, 지원 프로세스 그룹으로 나눠져 있다.
16. 방법론이란? (프로세스 vs 방법론)
프로세스는 작업을 하기 위한 단계나 절차지만 방법론은 전체적인 접근 방식을 이야기 한다. 따라서 어떻게 만들지 구상하는 것이 방법론이라 할 수 있다.
17. 세가지 방법론에 대하여 설명하시오. - 구조적 방법론 - 정보공학 방법론 - 객체지향 방법론
구조적 방법론 - 개발하는 방법을 놔눠서 설계한다. 여러 모듈로 나눠 개발하며 Top - Down 방식으로 설계된다.
정보공학 방법론 - 전체적인 시스템을 고려하여 개발하는 방법론이며 데이터의 흐름, 저장
객체지향 방법론 - 객체와 상호작용으로 모델링한다. 또한 클래스와 객체를 기반으로 하며 클래스는 속성과 메서드를 가진다. 재사용이 용이하다. UML을 이용하여 문서화 할 수 있다.
[4장] 요구분석
18. 요구란?
소프트웨어나 시스템을 개발할 때, 사용자나 시스템이 가져야 하는 조건, 기능, 특성 등을 명세화한 것
19. 요구를 기능요구와 비기능 요구로 나누어 설명해 본다.
기능 요구 - 시스템이나 소프트웨어가 수행해야 하는 기능적인 측면
비기능적 요구 - 시스템이나 소프트웨어의 품질, 성능, 보안, 사용성 등과 관련된 요구사항
20. 요구분석 단계는?
요구 수집 - 요구 분석 - 요구 명세 단계로 나뉘며 각 단계는 다음과 같다.
요구 수집 - 요구수집을 수집하고 문서화 시킨다.
요구 분석 - 요구사항을 분석하고 시스템의 동작을 이해한다
요구 명세 - 요구사항을 현실적으로 명세하여 개발하도록 명세화한다.
21. 요구추출에 사용하는 방법들은?
인터뷰, 설문조사, 워크샵, 프로토타이핑, 프로토타입
22. Usecase에 대하여 설명하시오.
소프트웨어 시스템의 동작을 나타내는 문서로서 액터, 유즈케이스, 관계로 나눌 수 있다.
액터 - 시스템과 상호작용하는 외부요소이며 Usecase를 통해 시스템과 상호작용한다.
유즈케이스 - 시스템이 수행하는 작업, 행동을 나타내며 액터와 시스템간의 상효작용을 연결한다.
관계 - 유즈케이스와 액터의 관계를 포함한다.
23. 요구분석 명세서 작성에 유의할 사항은?
1. 명확하고 간결해야 한다. 2. 요구사항을 모두 포함해야 한다. 3. 일관성이 있어야 한다. 4. 설계를 할 때 우선순위가 있어야 한다. 5. 기술적인 세부사항을 명확하게 명세해야 한다. 6. UML과 같은 문서화로 시켜야 한다.
24. 요구 검증에 필요한 사항은?
1.목표 설정이 명확하게 되었는가?
2. 액터와 유즈케이스, 관계가 잘 검증되었는가?
3. 요구사항이 다 들어갔는가?
4. 요구사항에 일관성이 있는가?
5. 실용성이 있는가?
등 기본적인 요구에 대한 내용을 검증 할 수 있어야 한다.
[5장] 모델링
25. 모델링의 세가지 관점(viewpoint)은?
기능적 관점, 구조적 관점, 정보적 관점
26. UML Diagram들에 대하여 설명해 본다. - Usecase diagram - Class diagram - Sequence diagram - State diagram - Activity diagram
. - Usecase diagram : 시스템의 요구사항을 시각적으로 표현하기 위함, 액터, 유즈케이스를 통해 다이어그램을 만든다.
- Class diagram : 시스템의 구조와 객체의 관계를 표현하기 위함, 클래스, 관계를 통해 다이어그램을 만든다.
- Sequence diagram : 시스템의 동적인 행동을 확인하기 위해 진행, 객체 간의 상호작용과 메세지 교환을 시간순으로 보여준다.
- State diagram : 객체의 생명주기를 표현, 객체의 상태변화와 이벤트의 응답을 보여준다.
- Activity diagram : 시스템의 프로세스나 알고리즘을 통해 작업흐름과 필요한 조건을 보여준다.
27. 객체 사이의 관계(연관/전체부분/상속/사용)에 대하여 그림과 함께 설명하시오.
28. 다형성이란?
객체가 동일한 메세지를 전송 받았더라도 다른 행동을 하도록 하는 것
29. 주어진 실행모듈(MMS)를 보고 다음과 같은 Diagram을 작성해 본다. - Usecase Diagram - Usecase Specifications for each usecase - Class Diagram - Sequence Diagrams for each usecase
[6장] 설계원리
30. 서브시스템, 컴포넌트, 모듈이란?
서브시스템 : 전체 시스템의 일부분이며 자체적으로 독립된 일을 수행 할 수 있다.
컴포넌트 : 재사용 가능한 독립적인 모듈이다.
모듈 : 소프트웨어 코드의 기능적인 부분이다.
31. 아키텍처 설계과정에 대하여 그림과 함께 설명 하시오.
32. ISO 25010애서 정의한 품질 특성은?
기능적 적합성, 성능 효율성, 호환성, 사용성, 신뢰성, 안정성, 유지보수성
33. 전통적인 설계원리를 나열한다면?
SPR(단일 책임 원칙) , OPC(개방-폐셰원칙), LSP(리스코프 치환 원칙). ISP(인터페이스 분리 원칙), DIP(의존성 역전 원칙)
34. 모듈사이의 결합(Coupling)의 정도를 구분하면?
느슨한 결합, 중간결합, 강한결합
35. 모듈의 응집(Cohesion) 정도를 구분하면?
높은 응집 -> 낮은 응집으로 가며 다음과 같다.
정보적 응집 -> 기능적 응집 -> 교환적 응집 -> 절차적 응집 -> 시간적 응집 -> 논리적 응집 -> 우연적 응집
36. 객체지향의 설계원리 SOLID에 대하여 설명해 보자.
SPR(단일 책임 원칙) - 클래스는 하나의 책임만 가져야 한다
OPC(개방-폐셰원칙) - 확장은 열려야 하고 수정은 닫혀야 한다
LSP(리스코프 치환 원칙) - 자식 클래스는 부모 클래스로 대체할 수 있어야 한다
ISP(인터페이스 분리 원칙) - 클라이언트는 사용하지 않는 인터페이스에 의존하도록 강요하지 말아야 한다
DIP(의존성 역전 원칙) - 고수준 모듈은 저수준 모듈에 의존하면 안되며 추상화에 의존해야 한다
37. 설계 메트릭에는 어떤 것들이 가능한가?
클래스당 가중 메소드 - 복잡도 - 클래스 안의 메소드의 복잡도 메트릭의 합
상속 트리의 깊이 - 상속 깊이 - 상속 트리의 루트로부터 가장 깊은 상속 경
자식 노드의 개수 - 상속 너비 - 클래스의 상속 구조에서 직계 자식 클래스의 수
클래스 사이의 결합 - 결합도 - 당 클래스가 의존하고 있는 개수
클래스의 책임 - 크기 - 클래스의 메소드 개수에 메소드가 호출하는 메소드의 수
메소드의 응집결핍 - 응집도 - 속성을 공유하지 않는 메소드 쌍의 수