소프트웨어 공학 공부 (7)
2025-04-29 17:25:15

디자인 패턴

  • 자주 사용하는 설계 형태를 정형화하여 이를 유형별로 설계 탬플릿을 만들어 둔 것
  • 많은 개발자들이 경험상 체득한 설계 지식을 검증하고, 이를 추상화하여 일반화한 템플릿

장점

  • 개발자(설계자) 간의 원할한 의사소통
  • 소프트웨어 구조 파악 용이
  • 재사용을 통한 개발 시간 단축
  • 설계 변경 요청에 대한 유연한 대처

 

종류 : 27개

  • 기본 패턴 : 4개
  • 생성 패턴 : 5개
  • 구조 패턴 : 7개
  • 행위 패턴 : 11개

 

기본 패턴

  • 객체지향 프로그램 에서 흔해 쓰는 기본적인 패턴
  • 개념 실체 패턴 
    • 개념 클래스를 실체 클래스에서 분리하는 것은 중복되는 정보를 저장하지 않기 위해서이다
  • 플레이어 역할 패턴 : 플레이어가 환경에 따라 다른 역할을 해야 할 때
  • 위임 패턴 : 다른 클래스의 오퍼레이션에 작업을 요청
  • 계층 구조 패턴 : 회사의 조직도, 파일 구조, 구문 트리 등 계층 구조를 다룰 때 필요

생성 패턴

  • 팩토리 패턴
  • 싱글턴 패턴
    1. 생성자를 private으로 선언
    2. 객체 생성을 static으로 선언
    3. getInstance()를 만들어 외부에서 사용하도록 함
    4. getInstance() 메서드를 동기화
  • 프로토타입 패턴
  • 빌더 패턴
  • 추상 팩토리 패턴

구조 패턴

  • 데코레이터 패턴
  • 어댑터 패턴
  • 컴포지트 패턴
  • 브리지 패턴
  • 퍼사드 패턴
  • 플라이웨이트 패턴
  • 프록시 패턴

행위 패턴

  • 전략패턴
  • 반복자 패턴
  • 견본 패턴
  • 책임 체인 패턴
  • 중재자 패턴
  • 통역자 패턴
  • 상태 패턴
  • 옵서버 패턴
  • 방문자 패턴
  • 커맨트 패턴
  • 기념 패턴
2025-04-15 17:44:54

16 : 20분까지 4호관 401호로

이번주 금요일 까지 피드백

 

계산식 3문제 : 소문제 포함 8문제

객관식 4점씩 15문제

 

계산식 1)

cocomo 방법

17, 18페이지 (p/m , tdev 구하기)

p/m의 상수값 알려주신다 하심

문제풀이 다 써야함

 

승수 표시하기 : ^ 사용하기

 

tdev 도 상수값 알려주신다함

 

계산식 2)

표 주신다함

UFP, TCF, FP 구하기

식 다 써야함

 

계산식 3)

cpm 작업 과정

es, ef, ls, lf, st값 구하기 (3개 나온다고 함)

 

 

객관식)

[객관식 문제 - 4지 선다형] 4점씩 15문제

1-1. 소프트웨어 공급방식에 따른 유형 중 특정 고객의 수요를 만족하기 위해 개발 소프트웨어는 무엇인가?  

주문형 소프트웨어


1-2. 소프트웨어 공급방식에 따른 유형 중 일반적으로 공개된 시장에서 판매하며, 범용 소프트웨어라고도 불리는 개발 소프트웨어는 무엇인가? 

패키지형 소프트웨어


1-3. 소프트웨어 공급방식에 따른 유형 중 변경이 어려우며, 개발방법과 프로세스가 달라 별도 분야로 취급 개발 소프트웨어는 무엇인가?

임베디드 소프트웨어

 

1-4. 소프트웨어의 분류 중 각종 센서를 이용하거나 기기들의 동작을 제어하는 소프트웨어는 무엇인가?

제어 소프트웨어


1-5. 소프트웨어의 분류 중 장비나 기기에 내장된 형태의 소프트웨어는 무엇인가?

임베디드 소프트웨어


1-6. 소프트웨어의 분류 중 자료를 받아들여 가공한 후 정보를 제공하는 소프트웨어로, 주로 DB에 자료를 저장한 후 검색을 통해 사용자가 원하는 형태로 정보를 제공하는 소프트웨어는 무엇인가?

관리 소프트웨어

2-1. 요구 사항 검증 내용 중 요구사항 간에 모순되거나 충돌되는 점은 없는지, 산출물 또는 요구사항의 내용이 일관적인지를  나타내는 요구 분석 명세서의 활동 내용은?

일관성


2-2. 요구 사항 검증 내용 중 표현이 애매모호하지 않고 참여자가 명확히 이해할 수 있는가를 나타내는 요구 분석 명세서의 활동 내용은?

명확성


2-3. 요구 사항 검증 내용 중 모든 요구 사항이 누락되지 않고 완전하게 반영되고 있는가를 나타내는 요구 분석 명세서의 활동 내용은?

완전성

3-1. 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론으로 ①프로세스와 도구 중심이 아닌, 개개인과의 상호 소통 중시, ②문서 중심이 아닌, 실행 가능한 소프트웨어 중시 등을 기본가치로 내세우는 모델은?

애자일 프로세스


3-2. 진화적 프로세스 모델의 대표적인 방법으로 소프트웨어 개발에서는 정식 절차에 따라 완전한 소프트웨어를 만들기 전에 사용자의 요구대로 일단 모형을 만들고 사용자와 의사소통 도구로 활용하는 모델은?

프로토타입 모델


3-3. 진화적 프로토타입 모델에 위험 분석을 추가한 모델로 사전 위험 분석을 통한 돌출 위험 요소를 감소시켜 프로젝트 중단 확률을 감소시키고, 사용자 요구가 충분히 반영된 제품을 개발하여 사용자의 불만 감소를 장점으로 가지고 있는 모델은?

나선형 모델

4-1. 설계의 원리 중 큰 문제를 소 단위로 나누고 소 단위 작업을 하나씩 처리하여 전체 일을 끝내는 방법은?

분할과 정복


4-2. 설계의 원리 중 주어진 문제에서 현재의 관심사에 초점을 맞추기 위해, 특정한 목적과 관련된 필수 정보만 추출하여 강조하고 관련이 없는 세부 사항을 생략함으로써 본질적인 문제에 집중할 수 있도록 하는 작업 방법은?

추상화


4-3. 설계의 원리 중 사용자에게 해당 객체의 기능과 사용법만 제공해 사용하기 쉽게 하고 내부는 함부로 변경할 수 없게 감추는 개념의 방법은?

캡슐화


5-1. 추상화 중 주어진 문제에 대해 프로그래밍하기 전 상세 부분은 생략하고 전체 흐름만 파악할 수 있는 알고리즘 형태로 작성하는 추상화는?

과정 추상화


5-2. 추상화 중 단계가 올라갈수록 표현이 더욱 간결해지고 특징만 나타낸다는 장점을 가지고 있으며, 프로그램 언어에서 쓰는 제어 구조를 추상화할 때 사용하는 추상화는?

제어 추상화


5-3. 추상화 중 데이터와 데이터 구조를 감추는 것으로 데이터와 메서드를 클래스 형태로 캡슐화 해 숨겨 놓고 사용자에게는 꼭 필요한 기능만 사용할 수 있게 개방한 구조의 추상화는?

데이터 추상화


6-1. 개발 방법론에 따른 모델링 언어 중 UML 표기법의 모델링 언어를 사용하는 방법론은?

객체지향 방법론


6-2. 개발 방법론에 따른 모델링 언어 중 DFD, DD, 프로세스 명세 등의 모델링 언어를 사용하는 방법론은?

구조적 방법론


6-3. 개발 방법론에 따른 모델링 언어 중 DB 설계 시 표현을 ERD로하는 방법론은?

정보공학 방법론


7-1. 통합프로세스 모델의 단계 중 준비 단계, 인지 단계 등 다양한 이름으로 불리며, 비즈니스 모델링과 요구사항 정의 관련 작업이 가장 많이 이루어지는 단계는?

도입 단계


7-2. 통합프로세스 모델의 단계 중 상세 단계로도 불리며, 보통 2~4개의 반복 단위로 구성되고, 비즈니스 모델링과 요구사항 정의 작업은 점차 줄고, 분석 및 설계 작업이 가장 많이 이루어지는 단계는?

구체화 단계


7-3. 통합프로세스 모델의 단계 중 이행 단계로도 불리며, 사용자를 위한 제품을 완성하는 단계로, 완성된 제품을 사용자에게 넘겨주는 과정에서 수행해야 할 일을 작업하는 단계는? 

전이 단계

 

8번 문제는 옳은 것을 정리해 두었다.
8-1. 소프트웨어 프로세스 모델의 목적으로 볼 수 없는 것은?

주어진 예산과 자원으로 개발하고, 관리하는 방법을 구체적으로 정의

고품질의 소프트웨어 제품을 만드는 것이 목적


8-2. 소프트웨어 프로세스 모델을 정의한 것으로 볼 수 없는 것은?

소프트웨어 개발 프로세스 모델은 소프트웨어를 어떻게 개발할 것인가에 대한 전체 흐름을 체계화한 개념

개발 계획 수힙부터 최종 폐기까지의 전 과정을 순차적으로 다룸


8-3. 소프트웨어 프로세스 모델의 역할로 볼 수 없는 것은?

프로젝트에 대한 전체적인 기본 골격을 세워 일정 계획을 수립할 수 있고, 개발 비용 산정뿐 아니라 여러 자원을 산정하고 분배할 수 있음

참여자 간에 의사소통의 기준을 정할 수 있고 용어의 표준화를 가능하게 함

개발 진행 상황도 명확히 파악할 수 있고 각 단계별로 생성되는 문서를 포함한 산출물을 활용해 검토할 수 있게 함


9-1. 클래스 설계 원칙 중 클래스를 변경해야 하는 이유는 오직 하나여야 한다는 원칙은?

단일 책임 원칙


9-2. 클래스 설계 원칙 중 확장(속성)에는 열려 있어야 하고 변경에는 닫혀 있어야 한다는 원칙은? 

개방 폐쇄 원칙


9-3. 클래스 설계 원칙 중 상위클래스의 객체는 언제나 자신의 하위클래스의 객체로 교제할 수 있어야 한다는 원칙은?

리스코프 교체 원칙


9-4. 클래스 설계 원칙 중 클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스)에 의존해야 한다는 원칙은?

의존 관계 역전 원칙


9-5. 클래스 설계 원칙 중 클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맺으면 안 된다는 원칙은?

인터페이스 분리 원칙


10-1. 개발 프로세스 모델 중 폭포수 모델에 테스트 단계를 추가하여 확장한 모델로 각 개발 단계를 검증하는데 초점이 맞춰진 모델은?

V 모델


10-2. 개발 프로세스 모델 중 선형 순차적 모델의 대표 모델로 관리가 용이하며, 문서를 체계적으로 할 수 있으며, 요구사항의 변화가 적은 프로젝트에 적합한 모델은?

폭포수 모델


10-3. 개발 프로세스 모델 중 진화적 프로토타입 모델에 위험 분석을 추가한 모델로 사전 위험 분석을 통한 돌출 위험 요소 감소시켜 프로젝트 중단 확률 감소시키고, 사용자 요구가 충분히 반영된 제품을 개발하여 사용자의 불만 감소는 장점을 가지고 있는 모델은?

나선형 모델

11-1. 비용 산정 기법 중 과거 유사 경험을 바탕으로 회의를 통해 산정하는 비과학적인 기법은?

하향식 비용 산정 기법


11-2. 비용 산정 기법 중 상향식 비용 산정 기법이며, 경험적 추정 기법 또는 실험적 추정 기법으로 불리며 대표적으로 COCOMO방법을 사용하는 기법은?

수학적 산정 기법


11-3. 비용 산정 기법 중 세부 작업 단위별로 비용 산정한 후 전체 비용 합산 기법으로 대표적으로 LOC기법을 사용하는 기법은? 

상향식 산정 기법


11-4. 상향식 산정 기법 중 하나로 코딩만 대상으로 산정하는 LOC기법보다 더 정확한 방법은? 

개발 단계별 노력(M/M) 기법


11-5. 수학적 산정 기법 중 하나로 SW 규모(LOC) 추정한 후 SW 종류에 따라 각 비용 산정 공식에 대입하여 비용 산정 방법은? 

 COCOMO 방법


11-6. 수학적 산정 기법 중 하나로 기능 점수를 구한 후 이를 이용해 비용을 산정하는 방법은? 

기능 점수 기반 추정 모델


12-1. 타당성 분석 종류 중 현재의 기술로 사용자가 요구하는 기능을 구현할 수 있는지 검토하는 것은?

기술적 타당성

 
12-2. 타당성 분석 종류 중 시장 분석을 통한 시장성 확인을 통해 개발 여부를 판단하는 것은?

경제적 타당성


12-3. 타당성 분석 종류 중 개발용 소프트웨어와 도구의 사용이 법적으로 문제가 없는지 검토하는 것은?

법적 타당성


12-4. 요구 사항 검증 내용 중 사용자 요구 분석 명세서와 설계서등에서 같은 내용을 쉽게 찾을 수 있는가를 나타내는 요구 분석 명세서의 활동 내용은?

추적 가능성


12-5. 요구 사항 검증 내용 중 사용자가 요구하는 내용과 일치하는지를 검증할 수 있는가를 나타내는 요구 분석 명세서의 활동 내용은? 

검증 가능성


12-6. 요구 사항 검증 내용 중 서로 의존 관계가 적어 변경으로 인해 미치는 영향이 적은지에 대한 요구 분석 명세서의 활동 내용은?

변경 용이성

 

13-1. 간이 기능 점수법을 이용한 기능 점수 산정 방법의 측정 유형 결정 방법 중 응용 규모 측정으로 현재 운용 중인 애플리케이션의 기능을 측정하는 기능 점수는? 

애플리케이션 기능 점수


13-2. 간이 기능 점수법을 이용한 기능 점수 산정 방법의 측정 유형 결정 방법 중 개발 규모 측정으로 프로젝트에서 사용자를 위해 제공된 모든 기능을 측정하는 기능 점수는? 

개발 프로젝트 기능 점수


13-3. 간이 기능 점수법을 이용한 기능 점수 산정 방법의 측정 유형 결정 방법 중 변경 규모 측정으로 사용 중인 소프트웨어 변경이 발생했을 때 변경된 부분의 기능을 측정하는 기능 점수는? 

개선 프로젝트 기능 점수

 

14-1. 응집도 중 함수적 응집이라고도 하며 응집도가 가장 높은 경우로 단일 기능의 요소가 하나의 모듈을 구성하는 응집은?

기능적 응집


14-2. 응집도 중 특별한 이유 없이 몇 개의 모듈로 나누는 과정에서 우연히 같이 묶인 것으로 구성 요소 간에 관련이 별로 없어 응집도가 가장 낮은 응집은?

우연적 응집


14-3. 응집도 중 정보적 응집이라고도 하며, 입력을 사용하는 구성 요소가 하나의 모듈로 구성되어 있고, 구성 요소가 동일한 출력을 만들어 낼 때도 응집되어 요소간의 순서가 중요하지 않은 응집은? 

교환적 응집

 

옳은 것을 표기함
15-1. 아키텍처의 시스템 품질 속성이 아닌 것은?

가용성

변경 용이성

성능

보안성

사용성

테스트 용이성


15-2. 아키텍처의 비즈니스 품질 속성이 아닌 것은?

시장 적시성

비용과 이익

예상 시스템 수명

목표 시장

신규 발매 일정

기존 시스템과의 통합


15-3. 아키텍처의 아키텍처 품질 속성이 아닌 것은?

개념적 무결성

정확성과 완전성

개발 용이성


15-4. 아키텍처의 4+1 관점 중 최종 사용자가 인식하는 시스템의 기능을 의미하며, 정적 표현 방법으로 유스케이스 다이어그램을 사용하는 관점은?

시나리오 관점


15-5. 아키텍처의 4+1 관점 중 시스템의 기능에 관심이 있는 유스케이스 관점과 달리 시스템 내부를 들여다보며, 정적 표현 방법으로 클래스 및 객체 다이어그램을 사용하는 관점은?

논리적 관점


15-6. 아키텍처의 4+1 관점 중 개발자와 시스템 통합자를 위한 것으로 실제 구동 환경을 살펴봄으로써 논리적 관점과 같으며, 동적 표현 방법으로 상태, 순차 다이어그램을 사용하는 관점은?

프로세스 관점


15-7. 아키텍처의 4+1 관점 중 물리적 시스템에서 사용하는 소프트웨어 서브시스템의 모듈이 서로 어떤 연관 관계가 있고 또 설계와 어떻게 연결 관계를 나타내는지 관심이 있으며, 정적 표현 방법으로 컴포넌트 다이어그램을 사용하는 관점은?

개발 관점


15-8 아키텍처의 4+1 관점 중 시스템에서 필요한 하드웨어 환경을 포함해 시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점이 있으며, 정적 표현 방법으로 배치 다이어그램을 사용하는 관점은?

물리적 관점

2025-04-15 17:23:21

아키텍처

  • 필요성
    • 복잡하고 규모가 큰 소프트웨어를 개발하여면 전체적인 구조가 유기적으로 잘 구성되어야 함
    • 잘 정의된 구조의 품질 좋은 소프트웨어를 만들려면 소프트웨어 아키텍처가 필요
    • 아키텍처 설계로 소프트웨어가 어떤 구조이고 어떻게 동작할 것인지를 예측할 수 있으며, 변경에 유연하게 대처 가능
  • 품질 속성
    • 사용성, 이식성, 유지보수 용이성과 같이 이해관계자의 요구사항과 관심사를 반영한 것
    • 시스템 품질 속성 
      • 가용성
      • 변경 용이성
      • 성능
      • 보안성
      • 사용성
      • 테스트 용이성
    • 비즈니스 품질 속성 
      • 시장 적시성
      • 비용과 이익
      • 예상 시스템 수명
      • 목표 시장
      • 신규 발매 일정
      • 기존 시스템과의 통합
    • 아키텍처의 품질 속성
      • 개념적 무결성 (일관성)
      • 정확성과 완전성
      • 개발 용이성 (구축 가능성)

아키텍처의 4 + 1 관점

 

  • 시나리오 (유스케이스) 관점
    • 최종 사용자가 인식하는 시스템의 기능을 의미
    • 시스템이 사용자에게 제공하는 기능에 주목하는 관점
  • 논리적 (디자인) 관점
    • 시스템 내부를 들여다 봄
  • 프로세스 관점
    • 개발자와 시스템 통합자를 위한 것으로 실제 구동 환경을 살펴봄으로써 논리적 관점과 같음
    • 모든 클래스에 관심이 있기보단 독자적인 제어 스레드를 가질 수 있는 클래스에 초점
    • 시스템의 동시성과 동기화에 관심이 있어 어떤 프로세스와 스레드가 있는지 식별하고 관계를 표현
  • 개발 (구현) 관점
    • 물리적 시스템에세 사용하는 소프트웨어 서브시스템의 모듈이 서로 어떤 관계가 있고 또 설계ㅘ 어떻게 연결 관계를 나타내는지에 관심
  • 물리적 (배치) 관점
    • 시스템에서 필요한 하드웨어 환경을 포함해 시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점

 

아키텍처 스타일

 

연관 관계

 

 

일반화 관계

 

 

집합 관계

합성 관계

의존 관계

 

실체화 관계

 

 

클래스 설계 원칙

  • 단일 책임 원칙 : 클래스를 변경해야 하는 이유는 단 하나여야 한다.

  • 개방 폐쇄 원칙 : 변경에는 닫혀 있어야 하고, 확장에는 열려 있어야 한다.

  • 리스코프 교체 원칙 : 상위 클래스의 객체는 언제나 자신의 하위 클래스의 객체로 교체할 수 있어야 한다.
  • 의존 관계 역전 원칙 : 클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스) 에 의존해야 한다.

  • 인터페이스 분리 원칙 : 클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맺으면 안 된다.

 

2025-04-08 17:31:15

중간고사 : 객관식 : 4지선다. 3점 20 or 4점 15

                 주관식 : 계산문제 10, 15, 15점

 

설계

분할과 정복

  • 분할 : 큰 소프트웨어 하나를 개발할 때 여러 개의 서브 시스템으로 세분화해 나누는 작업
    • 분할의 기준 : 
      • 분산 시스템은 클라이언트와 서버로 분할
      • 시스템은 여러 서브시스템으로 분할
      • 서브시스템은 하나 이상의 패키지로 분할
      • 패키지는 유스케이스나 여러 클래스로 분할
  • 정복 : 어느 정도 수준까지 분할했다면 말단에 있는 것부터 하나씩 개발하는 작업

 

추상화

  • 과정 추상화
  • 데이터 추상화
  • 제어 추상화

 

캡슐화

정보 은닉

상속

다형성

  • 오버로딩 (중복 정의)
  • 오버라이딩 (재정의)

모듈화

  • 모듈 평가 기준 1 : 응집도
    • 기능적 응집  : 단일 기능의 요소가 하나의 모듈을 구성
    • 순차적 응집 :  두 요소가 하나의 모듈로 구성
    • 교환적 응집 : 입력을 사용하는 구성 요소가 하나의 모듈로 구성
    • 절차적 응집 : 순서가 정해진 몇 개의 구성 요소가 하나의 모듈로 구성된 경우
    • 시간적 응집 : 모듈 내 구성 요소의 기능이 각기 다르고 요소의 출력을 입력으로 사용하는 것고, 요소 간에 순서가 정해진 것도 아님
    • 논리적 응집 : 구성 요소 간에 공톤점이 있거나 관련된 임무가 존재하거나 기능이 비슷해서 하나의 모듈로 구성된 경우
    • 우연적 응집 : 구성 요소들이 우연히 모여 구성

 

  • 모듈 평가 기준 2 : 결합도
    • 데이터 결합
    • 스탬프 결합
    • 제어 결합
    • 공통 결합
    • 내용 결합

 

2025-04-01 17:34:27

요구사항의 정의

  • 사용자와 개발자가 합의한 범위 내에서 사용자가 필요로 하는 기능
    • 시스템이 제공하는 기능 요구와 품질과 같은 비기능 요구로 나뉨

요구분석의 목적

  • 목적 사용자에게서 필요한 요구사항을 추출해 목표하는 시스템의 모델을 만들고, '요구분석명세서'를 작성하기 위해
  • 요구분석명세서
    • 요구분석 단계에서 생성되는 최종 산출물로 시스템의 기능이 무엇인지 에만 초점을 두고 정리
    • 요구분석 단계 후 설계단계에서는 설계서가 만들어지는데 이 문서는 어떻게 구현할지 기술

요구사항 수집

  • 자료 수집
  • 인터뷰
  • 설문 조사

요구분석 절차

  1. 자료 수집
  2. 요구사항 도출
  3. 문서화 
  4. 검증

기능 요구사항

  • 사용자가 원하는 기능
  • 사용자는 시스템을 통해 기능을 제공받기 바라며 시스템은 사용자에게 필요한 기능을 제공
  • 사용자가 원하는 기능은 요구분석 명세서에 완전하고 일관성 있게 표현해야 하며 시스템에도 전부 반영
  • 완전성 : 사용자가 원하는 모든 기능이 포함 / 일관성 : 요구사항 간에 모순이 있어서는 안 됨

비 기능 요구사항

  • 수행 가능한 환경, 품질, 제약 사항 등을 말함
  • 비 기능 요구사항이 매우 중요한 소프트웨어는 군사 무기나 의료 장비 등이 해당

제약 사항

  •  개발 소프트웨어가 수행될 환경에 의한 조건

품질

  • 신뢰성
    • 신뢰성 높은 소프트웨어의 조건
      시스템에 오류가 있더라도 고장을 일으키지 않고 회피할 수 있는 능력이 높아야 함
      고장이 발생하더라도 이전 수준으로 성능이 회복되어야 함
      고장으로 영향을 받은 데이터들이 정상적으로 잘 복구됨
  • 가용성
    • 소프트웨어가 총 운용 시간 동안 얼마나 정상적으로 고장 없이 가동되었는지를 비율로 나타냄
    • MTBF (평균 정상 작동 시간 또는 고장 간 평균 시간)
    • MTTR (평균 수리 시간)
    • MTTR(고장까지의 평균 시간)

2025-03-18 18:21:31

여기서 시험문제 많이 나올거래요

바용 산정 문제의 배점이 크게 나올 예정

 

계획

  • 소프트웨어 개발의 성패는 비용, 기간, 인력과 같은 자원을 토대로 초기에 얼마나 계획을 잘 세우느냐에 달려있음

문제 정의

  • 문제를 정의하려면 개발하고자 하는 영역의 배경 지식이 필요
  • 유사한 프로젝트를 개발한 경험이 있는 분석가가 참여하는 것이 도움이 됨
  • 문제를 파악하기 위해 현재 운영 중인 시스템을 사용해 보고
  • 실무 담당자와 면담해 자료를 수집한 후 면밀히 분석해보는 것이 필요

타당성 분석

경제적 타당성

  • 경영자 입장에서 의사결정을 하는 데 매우 중요한 요소
  • 시장 분석을 통해 시장성을 확인
  • 경제적 타당성 분석으로 투자 효율성과 시장성을 검증한 후 개발 여부를 판단

기술적 타당성

  • 사용자가 요구하는 프로젝트가 최신 기술이 필요하다면 기술적 타당성을 먼저 검토
  • 요구하는 기술을 회사가 가지고 있는지 확인
  • 부족하다면 필요한 기술을 갖고 있는 소프트웨어 개발자를 채용하거나 외주 개발로 해결

법적 타당성

  • 오픈소스는 소프트웨어 분쟁 발생 소지가 높음
  • 법적인 문제가 발생하지 않으려면 오픈소스를 사용할 때 어디까지 무료로 사용할 수 있는지 확인해야 함

개발 비용 산정 : 하향식

전문가 판단 기법 (계산식에 관련된 문제 출제 예정)

  • 경험이 많은 여러 전문가가 프로젝트를 수행하는 데 비용이 어느 정도 들어가는지 평가한 금액을 개발 비용으로 산정
  • 경험이 많은 전문가가 판단을 내린 만큼 신뢰성이 있고 편리하다는 장점
  • 짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우 많이 사용
  • 수학적 계산에 의해 산정하지 않고 경험에만 의존할 경우 부정확할 수 있음

델파이 기법

  • 전문가의 경험을 중요시해 비용을 산정하는 것은 같으나 전문가들의 편견이나 분위기에 영향을 받지 않도록 조정자를둠
  • 여러 전문가가 모여 각자의 의견대로 비용을 산정 후 결과를 공유하고 의견을 조율하여 개발 비용을 산정
    1.  조정자는 전문가가 모여 비용 산정을 하는 회의에서 간사 역할을 수행
    2. 던문가는 비용을 산정할 수 있는 자료를 충분히 검토하고, 필요하다면 의견을 나눌 수 있음
    3. 전문가 각자가 비용을 산정한다. 이떼 계산된 결과를 조정자에게 익명으로 제출
    4. 조정자는 각 전문가가 제출한 자료를 요약 정이
    5. 조정자는 각 전무가가 제출한 자료에서 산정 내용에 차이가 크면 이 문제를 해결하기 위해 회의를 소집
    6. 전문가는 다시 익명으로 비용 산정 작업을 실시

 

개발 비용 산정 : 상향식

원시 코드 라인 수 기법 - LOC 기법

  • 소프트웨어 각 기능의 원시 코드 라인 수 (LOC)의 비관치, 낙관치, 중간치를 측정하여 예측치를 구하고 이를 이용해 노력, 개발 비용, 개발 기간. 생산성 등의 비용을 산정하는 기법

  • 한 모듈에 대해 라인 수 (LOC)를 추정할 때 낙관적으로 볼 때 300LOC, 비관적으로 볼 때 900LOC, 중간이라고 볼 때 600LOC로 생각했다면, 추정  LOC는 얼마인가?
  • (300 + (4 * 600) + 900) / 6 = 600LOC

  • 소프트웨어 개발 기간은 1년(12개월)이다. 5명의 개발자가 12개월 동안, 7명의 개발자가 5개월 동안 참여한다면 이 소프트웨어 개발의 노력M/M는 얼마인가?
  • (5명 * 12개월) + (7명 * 5개월) = 60M/M + 35M/M = 95M/M
  • LOC 기법에 의해 예측한 총 라인이 50,000라인이고, 개발자가 10명 참여한다. 그리고 개발자들이 월 평균 500라인 을 코딩 한다면 개발 기간은 얼마나 되는가?
  • 노력(M/M) = 원시 코드 라인 수 / 1인당 월 평균 생산 코드 라인 수 = 50,000 라인/500라인 = 100M/M
    개발 기간 = M/M / 참여 인원 = 100M/M / 10명 = 10개월

개발 단계별 노력(M/M) 기법

  • LOC 기법은 개발하려는 소프트웨어의 총 코드 라인 수를 예측하여 구현 단계에 대한 M/M를 산정
  • 하지만, 실제 소프트웨어를 개발하디 위해서는 코딩 뿐만 아니라 요구 분석, 설계 등의 단계에서도 인력과 자원이 많이 필요
  • M/M을 소프트웨어 개발 생명주기의 각 단계에 적용하여 단계별로 산정 -> LOC기법 보완
  • 코딩만 대상으로 산정하는 LOC 기법보다 더 정확

 

비용 산정 기법 : 수학적 산정 기법

COCOMO 방법

  • 프로그램 유형에 따른 가중치를 두어야 함
  • 개발아려는 소프트웨어를 제품, 컴퓨터, 개발자, 프로젝트 4가지 특성에 따라 총 15가지로 분류한 후 인건비를 더 보정

가중치 반영하기

  • 단순형 프로젝트 : 50KDSI 이하
  • 중간형 프로젝트 : 300KDSI 이하
  • 내장형 프로젝트 : 300KDSI 이상

보정 계수 반영하기

  • 노력 조정 수치(EAF) : 보정에 사용하는 값, 필요한 각 항목별 승수 값을 모두 곱한 값

노력 조정 수치가 반영된 노력 (P/M)

  • 노력 조정 수치가 반영된 노력(PM) : 프로젝트 유형에 노력 조정 수치를 곱한 것

기능 점수 산정 방법

간이 기능 점수법

  • 프로젝트 초기 단계에서 각 기능의 요소를 모르는 경우에 평균 복잡도 가중치를 사용해 소프트웨어 기능의 크기를 측정

  • 평균 복잡도 가중치

  • 데이터 기능 점수 계산
    • 이번 프로젝트에서 생성해 관리하는 데이터는 내부 논리 파일(ILF)
    • 이번 프로젝트에서 만들지 않고 다른 프로젝트에서 생성했으나 이번 프로젝트에서 참조하는 데이터는 외부 연계 파일(EIF)
    • 데이터 기능 점수는 내부 논리 파일의 개수와 외부 연계 파일의 개수에 각각의 평균 복잡도(가중치)를 곱해 계산
  • 트랜잭션 기능 점수 계산
    • 기능 점수에서 트랜잭션 기능의 복잡도는 입력, 출력, 조회의 개수로 결정
    • 외부 입력 (EI) :  데이터베이스에 데이터를 등록하거나 수정.삭제하는 것
    • 외부 출력 (EO) : 계산하는 로직을 거쳐 데이터나 제어 정보를 사용자에게 보여주는 기눙
    • 외부 조회 (EQ) :  로직이 필요 없고 데이터베이스에 존재하는 데이터를 찾아 그대로 표시만 해주는 기능

  •  

 

 

일정 계획

일정 계획 기법 1 : 네트워크 차트 (PERT/CPM)

CPM 작업 과정

  • CPM으로 네트워크를 그리려면 학사관리 애플리케이션을 수행하는 데 필요한 작업, 선행 작업, 작업의 소요 기간이 필요

 

 

 

2025-03-11 18:21:55

소프트웨어의 정의

  • 프로그램 : 프로그래밍한 원시 코드(source code)
  • 소프트웨어 : 프로그램 뿐만 아니아 그 이상의 것도 포함하는 매우 포괄적인 개념

 

 

소프트웨어의 분류★

  • 관리 소프트웨어 :
    • 자료를 받아들여 가공한 후 정보를 제공하는 소프트웨어
    • 주로 DB에 자료를 저장한 후 검색을 통해 사용자가 원하는 형태로 정보를 제공 ( 인터넷 뱅킹, 종합정보 시스템, 예약 시스템 등)
  • 제어 소프트웨어 :
    • '각종 센서를 이용하거나 기기들의 동작을 제어하는 소프트웨어 ( 교통 신호 제어, 의료기기 제어, 공장장비 제어 등)
    • 사용자 메뉴얼
  • 임베디드 소프트웨어 
    • 장비나 기기에 내장된 형태의 소프트웨어 ( 가전제품 내의 소프트웨어, 각종 공정제어 시스템 네의 소프트웨어)
    • 변경이 어려뭄
    • 개발방법과 프로세스가 달라 별도 분야로 취급
  • 주문형 소프트웨어
    • 특정 고객의 수요를 만족하기 위해 개발된 소프트웨어
    • 웹사이트, 항공 - 교통 제어 시스템, 재정관리 시스템 등
  • 패키지형 소프트웨어
    • 일반적으로 공개된 시장에서 판매, 범용 소프트웨어라고도 함
    • 주문형 대비 저렴하고 신뢰도가 높지만, 특정 기관의 요구에 맞지 않을 수 있음
  • 리얼타임 소프트웨어
    • 제어, 모니터링 소프트웨어
    • 신속한 반응, 안정성 확보가 매우 중요
  • 자료처리 소프트웨어
    • 비즈니스 업무 처리에 사용
    • 자료의 정확성과 보안이 관건
    • 일괄 처리
  • 두 가지 성격 (리얼타임 + 자료처리)을 동시에 지닌 소프트웨어
    • 전화 통신 시스템 : 전화는 리얼타임, 청구는 자료처리

 

소프트웨어의 특징

  • 제조가 아닌 개발
    1. 제조 : 개인 능력에 따라 차이가 크지 않으므로 능력에 따른 결과물의 차이는 크지 않음
    2. 소프트웨어 개발 과정은 제조와 달리 개인 능력에 따라 차이가 큼
  • 소모가 아닌 품질 저하
    • 하드웨어 : 오래 사용하면 부품이 닳고 기능도 떨어짐
    • 소프트웨어 : 닳지 않으며 또한 시간이 지나도 고장 빈도가 높지 않음, 사용 시작 단계부터 사용자의 요구가 계속 발생

 

소프트웨어의 당면 과제

  • 소프트웨어 개발의 느린 발전 속도
    • H/W의 발전 : PC 및 스마트 폰의 발전 속도(크기, 속도, 성능)
    • S/W의 발전 속도 : DOS ~ Windows 11
  • 새로운 소프트웨어에 대한 사용자의 요구의 증가
    • S/W의 발전 속도가 미처 따라가지 못함
    • H/W와 S/W의 개발 방법의 근본적인 차이 때문
    • (해결 방안) CBD 개발 방법론

 

소프트웨어 공학

  • 소프트웨어 공학의 학문적 정의 :
    • 품질 좋은 소프트웨어를 경제적으로 개발하기 위해 계획읳 세우고, 새발하며, 유지 맟 관리하는 전 과정에서 공학, 과학 및 수학적 원라와 방법을 적용해 필요한 이론과 기술 및 도구 들에 관해 연수하는 학문 → 소비자가 만족해야

 

 


 

 

주먹구구식 모델 - Build & fix, Code & fix, 즉흥적 소프트웨어 개발 모델

  • 공식적인 가이드라인이나 프로세스가 없는 개발 방식
  • 즉흥적 소프트웨어 개발 꼬는 코딩과 수정 모델이라고 함
  • 코드를 작성해 제품을 만든 후에 요구분석, 설계, 유지보수에 대해 생각
  • 첫 번째 버전의 코드를 작성해 제품을 완성한 귀 작성된 코드에 문제가 있으면 수정해서 해결하고 문제가 없으면 사용

 

주먹구구식 모델의 단점

  • 정해진 개발 순서나 각 단계별로 문서화된 산출물이 없어 관리 및 유지보수가 매우 어려움
  • 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍퍼를 만들 수도 없음
  • 개발자가 일을 효과적으로 나눠 할 수도 없음
  • 프로젝트 진척 상황을 거의 파악할 수 없음
  • 코딩을 먼저 하므로 수정할 가능성이 많은데, 여러 번 수정하다 보면 사독성이 높았던 프로그램의 구조가 나빠져 수정이 매우 어려워짐

 

선형 순차적 모델 - Classic life cycle

  • 폭포에서 물이 떨어지듯이 다음 단계로 넘어가는 모델
  • 소프트웨어 공학의 대명사로 여겨질 만큼 초기에 개발된 전통적인 모델
  • 공장 생산 라인의 작업 프로세스와 유사한데, 표준 프로세스를 정해 소프트웨어를 순차적을로 개발

 

폭포수 모델의 개발 절차

  • 폭포의 물이 위에서 아래로 떨어지듯이 계획, 분석, 설계,  구현, 테스트, 유지보수의 각 단계가 하향식으로 진행
  • 각 단계가 끝날 때 마다 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 나아감

 

V 모델

  • 폭포수 모델의 변형으로, 테스트 단계를 추가 확장해 테스트 단계가 분석 및 설계와 어떻게 관련되어 있는지를 나타냄
  • 폭포수 모델이 산출물 중심이라면, V 모델은 각 개발 단계를 검증하는 데 초점을 두므로 오류를 줄일 수 있음

 

단계적 개발 모델

  • 개발자가 먼저 릴리스 1을 개발해 사용자에게 제공하면 사용자가 이를 사용
  • 사용자가 릴리스 1을 사용하는 동안 개발자는 다음 버전인 릴리스 2를 개발
  • 개발과 사용을 병행하는 과정을 반복해 진행하면서 완료
  • 릴리스를 구성하는 방법에 따라 점증적 개발 방법과 반복적 개발 방법으로 나뉨

점증적 개발 방법 : 개발 범위의 증가

  • 중요하다고 생각되는 부분부터 차례로 개발한 후 그 일부를 사용하면서 개발 범위를 점차 늘려 가는 방식
  • 돈이 부족 할 경우 사용하기도함
  • 점증적 방법 - 소프트웨어 개발
    • 요구분석 명세서에 명시된 시스템 전체를 기능에 따라 독립성 높은 서브 시스템으로 분할
    • 각 서브 시스템을 단계적으로 하나씩 릴리스 해 완성하는 방법
  • 점증적 방법의 장점과 단점
    • 한꺼번에 많은 비용을 들이지 않아도 됨

반복적 개발 방법 : 품질의 증가

  • 초기에 시스템 전체를 일차적으로 개발해 인도한 후, 각 서브 시스템의 기능과 성능을 변경 및 보강해 완성도를 높임
  • 초기의 요구사항이 불분명한 경우에 적합

 

통합 프로세스 모델

  • 폭포수 모델은 각 단계별로 깔끔하게 정리되어 있지만 사용자의 요구사항이 많으면 민첩하게 대처할 수 없음
  • 폭포수 모델의 문제점을 해결하기 위해 작업을 계속해서 반복 수행하는 반복적 개발 방법론이 등장
  • 통합 프로세스 모델은 반복적 생명주기를 기반으로 하는 모델 중 가장 많이 사용

통합 프로세스 모델의 절차

  • 통합 프로세스 모델의 개발 과정은 크게 4단계 (도이브 구체화, 구축, 전이)로 나뉨
  • 도입 단계
    • 구현, 테스트, 배치 작업은 거의 없고 '비즈니스 모델링'과 요구사항 정의' 관련 작업이 가장 많이 이루어짐
  • 구체화 단계
    • 비즈니스 모델링과 요구사항 정의 작업은 점차 줄고, 대신 분석 및 설계 작업이 크게 이루어짐
    • 설계 결과에 따른 구현(코딩) 작업, 구현에 대한 단위 테스트가 조금씩 시작
  • 구축 단계
    • 구현 작업이 가장 많이 이루어짐
    • 비즈니스 모델링과 요구사항 정의 작업은 점차 줄고, 분석 및 설계 작업도 구체화 단계보가 줄어듦
  • 전이 단계
    • 이행 단계라고도 하며 사용자를 위한 제품을 완성하는 단계
    • 완성된 제품을 사용자에게 넘겨주는 과정에서 수행해야 할 일을 수행

애자일 프로세스 모델

  • 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론
  • 가벼운 프로세스 방법론의 공통적인 특성을 정의

애자일의 기본 가치

  • 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시
  • 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시
  • 계약과 협상 중심이 아닌, 고객과의 협력을 중시

애자일의 원칙

  • 최우선적인 목표는 고객을 만족시키기 위해 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것
  • 동작 가능한 소프트웨어를 짧으면 2주, 길면은 2개월 간격으로 자주 고객에게 전달. 

애자일 프로세스 모델 : 스크럼

  • 소프트웨어 개발 보다는 팀의 개선과 프로젝트 관리에 중점을 둔 애자일 방법론
  • 경험적 관리 기법 중 하나
  • 구체적인 프로세스를 명확하게 제시하지 않음