정보처리기사 2일차

1.소프트웨어 설계

 1.1 요구사항 확인

  1.1.3 요구사항 확인

 

---

- 요구사항 확인

 

1. 요구분석기법

 

1.1 요구분석의 개념

도출된 요구사항들 간의 상충을 해결하고 소프트웨어의 범위를 파악하며 소프트웨어가 환경과 어떻게 상호작용하는지를 분석하는 과정을 말한다.

외부사용자와의 인터페이스 및 내부시스템 구성요소간의 인터페이스를 정확히 분석하여 시스템을 계층적이고 구조적으로 표현한다.

 

1.2 요구분석 기법

1.사용자그룹 인터뷰

요구사항을 도출한 사용자를 대상으로 인터뷰를 수행한다.

많은 사용자로부터 인터뷰를 하는 것이 좋고 회의록 작성은 필수이다.

필요시 인터뷰 내용을 녹음하여 반복 청취하는 것이 좋다.

2.이해관계자 설문조사

사용자와 대면 조사가 어려울 때에 설문 형식으로 조사한다.

현행 시스템의 개선 의견을 끌어낸다.

3.문헌 조사

유사 프로젝트 및 업무 문서나 양식을 조사하여 현재 시스템 정보에 대한 이해를 도출한다.

산업 및 기업표준, 정부 정책, 규제 및 법규도 조사한다.

개발팀은 업무 도메인 교육이나 튜토리얼에 참가한다.

4.프로토타이핑

요구사항에 대한 이해를 하기 위하여 기본적인 기능만 빠르게 구현하여 사용자로부터 피드백을 받는 기법이다.

개발자의 아이디어를 사용자로부터 조기에 피드백 받고자 할 때 사용한다.

프로토타이핑 전용언어로 모의 사용자 인터페이스를 사용한다.

5.사용자 스토리텔링

사용자의 요구사항을 이야기 형식으로 기술하여 자연스럽게 개발자가 요구사항에 대한이해가 가도록 구성하는 기법이다.

주로 애자일 방법에서 사용하는데 개발자와 사용자가 서로 긴밀히 대화하면서 요구사항을 함께 만들어간다.

 

2. UML

 

2.1 UML의 개념

객체지향 소포트웨어 개발과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합하여 만든 표준화된 범용 모델링 언어이다.

특징으로는 

가시성 : 반복적/점진적으로 구체화하여 소프트웨어의 가시성을 제공한다.

문서화 : 개발규모, 개발 프로세스 및 언어와 무관하게 개발자간 의사소통 도구를 제공한다.

명세화 : 단순 표기법이 아닌 구현에 필요한 개발적 요소 및 기능에 대한 명세를 제공한다.

구성요소

View : 모델화된 시스템의서로 다른 모형 제공

Diagram : View의 내용을 나타내기 위한 9가지 다이어그램 제공

모델요소 : 객체지향 개념을 표현하기 위해 사용되는 요소 ( 클래스, 속성, 오퍼레이션으로 구성 )

General Mechanism : 모델 요소에 대하여 주석 정보와 의미 제공

 

2.2 UML 다이어그램 종류

3. 애자일

 

3.1 애자일 방법론의 개념

1.애자일 방법론 정의

전체 개발 단계에서 변화에 대한 신속한 대응으로 요구사항을 지속적으로 분석,반영하여 배포 시간차를 최소화하는 개발방법론이다.

2.애자일 방법론의 등장배경

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자하는 방법론이다.

계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 비효율적인 점에서 취약점을 가짐 계획에 의존하는 경우는 그 형식적인 절차를 따르는데 필요한 시간, 비용을 무시할 수 없고 전체적인 개발 흐름을 느리게하는 단점보유

계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하여 개발하지 않고 일정한 주기를 가지고 끊임없이 프로토타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해나가는 방식

3.애자일 선언문

소프트웨어를 개발하고 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있으며 이를 통해 다음을 가치있게 여기게 되었다.

공정과 도구보다 개인과 상호작용

포괄적인 문서보다 작동하는 소프트웨어를

계약 협상보다 고객과의 협력을

계획을 따르기보다 변화에 대응하기를 가치있게 여긴다.

 

3.2 애자일 개발 프로세스

어느 특정 개발 방법론을 가리키는 말은 아니며 "애자일 : 기민한 ,좋은것을 빠르고 낭비없게 만드는것 " 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다. 과거에는 애자일 개발 프로세스는 "경량 프로세스" 로 불림

익스트림 프로그래밍이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있음!

 

3.3 애자일 방법론의 종류

종류	내용
XP	의사소통 개선과 즉각적인 피드백에 의한 단순한 코딩으로 SW품질을 높이기 위한 방법론이다.
SCRUM	매일 정해진 시간에 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론이다.
Lean	린시스템의 품질 기법을 소프트웨어 개발 프로세스에 적용하여 프로세스의 낭비요소를 제거 후 결과를 측정, 성과를 분석하여 소프트웨어의 품질을 향상시키는 개발방법론이다.

3.4 애자일 방법론과 전통 방법론 비교

항목	애자일 방법론	전통적 방법론
요구사항의 베이스라인	프로젝트 전과정에 걸쳐 진화하는 요구사항	초기 요구사항에 대한 Base line을 설정
아키텍처 정의방법	실제 기능 구현을 통하여 빠른 시간 내에 아키텍쳐의 실현 가능성을 증명해 보이고자 한다.	모델과 사양을 보다 상세화하는 과정을 통해 어플리케이션과 데이터 아키텍쳐를 초기에 정의하고자 한다.
테스트 방법	빈번한 개발-테스트 주기를 통해 많은 시간과 비용이 투입되기 전 기능을 검증한다.	특정 기능이 구현도니 이후 단위-통합-시스템 테스트로 확장해 나가는 방식이다.
표준 프로세스 적용	잦은 Inspection을 토대로 프로세스를 유연하게 개발에 적용	개발 착수 전에 표준화된 프로세스 제정이 중요
릴리즈	빠른 릴리즈	BigBang 릴리즈
중심사상	학습중심	계획중심

---

오답풀이

설계 기법 중 하향식 설계 방법과 상향식 설계 방법에 대한 비교설명으로 가장 옳지 않은 것은?

1.하향식 설계에서는 통합 검사 시 인터페이스가 이미 정의 되어 있어서 통합이 간단하다.

2.하향식 설계에서 레벨이 낮은 데이터 구조의 세부 사항은 설계 초기 단계에서 필요하다.

3.상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다.

4.상향식 설계에서는 인터페이스가 이미 성립되어있지 않더라도 기능 추가가 쉽다.( 정답 )

 

상향식 설계와 하향식 설계에 대한 개념이 잡혀있지 않은 상황이라 구글링을 통해 공부를 하였다!

- 상향식 설계(Bottom-up Design)

1. 세부 기능의 구현을 초기에 강조

2. 결과 프로그램 = 세부 기능들의 조합

3. 단점: 주어진 문제의 고유 특성을 고려하지 않는 설계가 될 위험이 있음.

※ 최하위 단계에 있는 작은 단위를 먼저 결정하고 이를 이용하여 좀 더 큰 단위인 상위 단계의 문제를 해결하는 방법이다. 최하위 단위의 문제들에 대해 기존에 개발되어 있는 문제해결 도구(알고리즘)를 재사용할 수 있는 경우에는 개발기간과 비용을 단축하고 신뢰성을 확보할 수 있다.

 

- 하향식 설계(Top-down Design)

1. 프로그램을 관리 가능한 세그먼트들로 분할

2. 단점: "도미노 효과"가 발생 가능

※ 도미노 효과: 한가지를 수정할 때 연관되어 있는 다른 것들도 다 같이 수정해야 될 수 있음

※ 무엇을 수행할 것인지 정의하는 단계에서 시작하여 다음 단계에서 어떻게 수행할 것인지를 구체적으로 정의하고, 그 다음 단계에서 더 세분화하여 정의하는 방식으로서 하위 단계로 갈수록 좀 더 구체적으로 세부 문제를 정의한다. 마지막으로 최하위 단게로 분할된 작은 단위의 문제들을 각각 처리함으로써 전체 문제를 해결한다. 이러한 방식은 분할 정복이라고도 한다. 출처: https://berapp.tistory.com/entry/기본-개념 [Bera의 개발 이야기]

 

상향식 설계에서는 세부 기능의 구현을 초기에 강조하기 때문에 4번이 정답이 아닐까 .... 하는 생각이다 

 

효과적인 모듈화 설계 방법으로 가장 거리가 먼 것은?

1.Coupling은 강하게 Cohesion는 약하게 설계한다.(정답)

2.Complexity와 Redundancy를 최대한 줄일 수 있도록 설계한다.

3.Maintenance가 용이하도록 설계한다.

4.Module 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 설계한다.

 

이문제는 원어를 잘 몰라서 어려웠다.. 내가아는 것이라곤 Maintenance와 Module 뿐..

Coupling : 결합도

Cohesion : 응집도

Complexity : 복잡성

Redundancy : 불필요한 중복

 

2번은 무조건 맞는말이고... 결합도와 응집도에 대해서 공부해보았다!

 

결합도와 응집도는 모듈의 독립성을 판단하는 두 가지 지표이다.

결합도(또는 의존도)는 어떤 모듈이 다른 모듈에 의존 정도를 말한다.

응집도는 모듈 내부의 기능적인 집중 정도라고 할 수 있다.

이상적인 모듈화는 결합도는 낮을 수록, 응집도는 높을 수록 "유지보수성이 높다"라고 할 수 있다.

 

결합도가 높은 클래스의 문제점

• 연관된 다른 클래스가 변경되면 더불어 변경이 필요하다
• 수정하려는 클래스를 이해하기 위해 연관된 클래스를 함께 이해해야한다.
• 다른 프로그램에서의 클래스를 재사용하기 힘들다.

 응집도가 낮은 클래스의 문제점

• 이해하기 어려움
• 재사용하기 힘듦
• 유지보수가 어려움
• 다른 클래스의 변화에 민감함

출처 1000hg.tistory.com/32

결합도(Coupling)과 응집도(Cohesion)