본문 바로가기
몰라 컴퓨터 일반/소프트웨어 공학

소프트웨어공학(정처기 위주 정리)

by 몰라닉네임 2024. 4. 23.
- 회귀 테스트 : 한 모듈의 수정이 다른 부분에 미치는 영향을 고려하여 관련 모듈을 함께 검사

 

 

더보기

폭포수 모형 

- 소규모 시스템에 적합

- 다시 거슬러 올라갈 수 없는 모형

 

프로토타이핑 모형 

- 가장 적절한 때는 구축하고자하는 Syst의 요구사항이 불명확한 경우

- 사용자의 요구부넉의 어려움을 해결하기 위해 실제 개발될 소프트웨어의 견본품을 만들어 의사소통 도구로 사용

 

나선형 모델 

- 폭포수 모형의 제어와 프로토타입 모형의 반복적 특성을 수용

- 위험관리 측면에서 바라본 모델이다.

- 대규모 Syst에 적절

- 4단계(수분증가): 계획 립 - 위험 석 - 개발 및 검 - 고객 평

 

XP(eXtreme Programming)

- 애자일 기법을 제안 

- 고객의 참여를 극한 수준까지 유도

의사소통, 단순함, 피드백, 용기, 존증 5가지에 기초(정처기)

 

V모형 

- 폭포수 모델에 Syst검증과 테스트 작업을 강조한 것

- 작업과 결과의 검증에 초점

 

UP(Unified Process)

Use Case(사용사례) 기반, 반복적이고 점증적인 소프트웨어 프로세스

 

컴퍼넌트 기반 개발(CBD : Component Based Development)

- 이미 만들어진 컴포넌트를 사용하여 어플리케이션을 구성 (재사용성이 중요)

- 컴포넌트는 독립적인 업무의 단위로 개발된 것이므로 사용자가 필요한 기능만을 취합하여 사용하여 재사용할 있게끔 독립적으로 배포하는 것도 가능해야 한다

 

CASE 자동화 도구 
1) 통합 CASE SW 개발 주기의 전체 과정을 지원
2) 상위 CASE 요구분석과 설계 단계를 지원
3) 하위 CASE  코드 작성 및 문서화 등을 지원 

 

 

비용계획 - 비용 산정 방법

- LOC : 원시코드 라인 수를 기반으로 비용 산정

- COCOMO모델 :

 1) Organic(유기형, 5만 라인 이하)

 2) Semi - detached (30만 라인 이하)

 3) Embeded (30만 라인 이상)

- FP (기능 모델, Function Point) : 소프트웨어 각 기능에 대하여 가중치를 부여하여 규모나 복잡도를 산출하는 모형

일정계획 

- WBS (업무 분류식 구조) 세분화

 

- CPM : 임계경로 방법에 의한 프로젝트 최단 완료시간(최장경로)를 구하는 방법

 

- 간트 차트 : 막대 도표로 표시, 개발 과정 전 단계를 한 눈에 파악할 수 있으며 자원의 활용 및 인원 배치에 도움

 

CMMi 

성숙도 단계

더보기

- 0단계 : 실행되지 않음

- 1단계 : 실행됨

- 2단계 : 추적 가능한 문서화된 계획이 존재

- 3단계 : 조직차원의 표준 프로세스 존재

- 4단계 : 프로세스의 정량적 측정, 관리 

형상관리

-  변경에 대한 보호활동이며 변경의 원인을 알아내고 변경을 제어하며 적적히 변경되고 있는지 확인하고 변경에 관심을 가지고 있는 사람들에게 통보하는 작업 

 

구조적 분석

- 구조적 분석은 요구사항 분석의 방법으로 요구사항 분석은 사용자의 뜻을 이애하고 목적을 발견해 나가는 과정으로써 가장 전문적인 인력이 필요한 단계 

 

- 자료흐름중심 (Data Flow Oriented) 분석 기법

-자료 사전

  •  [ ] 선택
  • {} 반복
  • == 정의
  • + 구성(연결)
  • () 생략 가능
  • ** 설(주석)
결합도 

자스제외공내 

모듈화

우리 논산 시절 교자 순대 기억나

 

설계 기법

- N-S Chart 는 설계기법이다. (비용계획, 일정계획과 헷갈리기 쉽다.)

도형 사용

 

객체지향 설계 원칙

1. 단일 책임 원칙 (SRP, Single Responsibility principle) 

하나의 클래스는 하나의 책임만을 가진다.

 

2. 개방 폐쇄 원칙 (OCP, Open Closed Principle)

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

 

3. 리스코프 교환 원칙 (LSP, Liskov Substitution Principle)

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 상위 타입을 대체할 수 있어야 한다.

 

4. 인터페이스 분리 원칙 (ISP, Interface Segregation Principle)

하나의 일반적인 인터페이스보다 여러개의 구체적인 인터페이스가 낫다.

 

5. 의존관계 역전 원칙 (DIP, Dependency Inversion Principle) 

의존 관계를 맺을 때 자신보다 변화하기 쉬운 것에 의존하지 않아야 한다.( 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다. )

 

오바로딩 VS 오버라이딩

- 오버로딩은 함수명은 같으나 매개변수 타입 또는 개수가 다름 (리턴타입 관계 없음)

- 오버라이딩은 상속관계에서 함수 재정의. 함수명, 매개변수 모두 똑같음. 

객체 지향 분석 방법론

-Coad와  Yourdon 방법 : ER 다이어그램 사용

-Booch 방법 : 거시적/미시적 개발 프로세스를 모두 사용하는 방법 

-Jacobson(j를 u로 연상하기) : UseCase 강조하여 사용하는 방

-럼바우 방법 : 객체, 동적, 기능 모델링을 나누어 수행하는 방법 

객체 지향 분석 기법 중 럼바우 분석 기법

 객체 모델링 = 객체다이어그램

 동적 모델링 = 상태 다이어그램

 기능 모델링 = 자료 흐름도

 

UML 다이어그램 : 객체 지향 개발 

- 정적 모델: 클객배복패 (이런식으로 앞글자 외우기)

- 동적 모델: 그 외..

1) 사용사례 다이어그램 (Use Case)   Actor위주로, 외부에서 보는 시스템 동작
2) 클래스 다이어그램 클래스들의 정적 구조를 나타냄
3) 객체 다이어그램 객체 사이의 관계를 표현
4) 순서(Sequence) 다이어그램 - 객체들간의 메시지 교환을 시각화하여 나타냄 
-  유즈케이스가 처리되는 시나리오를 시간과 순서에 따라 묘사

 그외에도 많음

 

 

Use Case 다이어그램 구성요소 단

<<Include>> 포함 관계 :  하나의 유스케이스가 다른 유스케이스를 반드시 실행해야 한다는 전제 하에 형성되는 관계

<<Extend>>  확장 관계 :  기본 Use Case 수행 시 특별한 조건을 만족할 때 수행하는 것

 

- '글 등록' 전에 '로그인'이 반드시 수행되어야 한다는 것을 의미 <<Inclue>> 포함 관계

- '글 등록' 전에 '파일 첨부' 를 선택적으로 수행할 수 있다는 것을 의미 <<Extend>>  확장 관계

 

 

- B 사용 사례를 사용하는 중 특정 조건을 만족하면 A 사용 사례를 수행, <<Extend>>  확장 관계

- B 사용 사례를 수행하기 전 반드시 C 사용 사례를 수행해야 함  <<Inclue>> 포함 관계

 

 

검토방법

- 확인 : 사용자 관점. 기능 위주 

- 검증 : 개발자. 명세서 위주

 

워크 스루 인스펙션 동료검토
검토 회의 전 요구사항 명세서를 미리 배포하여 사전 검토한 후에 짧은 결함을 발견. 즉, 오류 조기검출이 목적 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견

 

시험의 기법 중 화이트 박스 시험 

-  화이트 박스 시험 (기.조.루.데): 프로그램의 구조를 파악하거나 경로들의 복잡도를 계산하는 시험

 예) 기초 경로 검사, 조건 검사, 루프 검사, 데이터 흐름 검사

- 테스트 검증 기준

 1) 문장 검증 기준

 2) 분기 검증 기준

 3) 경로 검증 기준 

 4) 조건 검증 기준

 

시험의 기법 중 블랙 박스 시험

- 블랙 박스 시험: 원시 코드는 보지 않은 채 목적 코드를 수행시켜 가면서 결함을 발견할 수 있는 시험 방식

동등분할

 

 

1) 경계값 분석 : 예) Test Case 1 ~ 99 유효범위를 갖는다.

  ( 1 , 99 )는 True 테스트

  ( 0, 100)은 True 테스트 

  (70)은 테스트 불가능

2) 원인 - 결과 그래프

3) 오류 예측

4) 조건 검증 기준

 

소프트웨어 시험의 종류

 

단위시험(모듈 검증) , 통합 시험(모듈간의 인터페이스), 인수시험(알파, 베타)이 있다.

 

단위 테스트

 설계의 최소 단위인 모듈의 검증에 초점 

Driver 과 Stub이 필요

통합 테스트

각 모듈간의 인터페이스와 관련된 결함을 검사

- 하향식 통합 테스트   (stub) : 모듈이 통합될 때 마다 실시, 테스트 초기부터 사용자에게 시스템 구조를 보여줄 수 있다.

- 상향식 통합 테스트    (Driver) : 하위 레벨 모듈부터 점진적으로 모듈을 통합하는 것, 인터페이스가 이미 성립되어 있지 않더라도 기능 추가가 쉽다(X) 

인수 시험

사용자 관점에서 SW가 요구를 충족시키는가를 평가

- 알파시험: 사용자를 개발자 환경으로 초대해 프로그램을 수행하고 테스트

- 베타시험 : 다수의 사용자들이 사용자 환경에서 테스트

 

유지보수의 종류

...

소프트웨어 역공학 

- (코드 TO 문서) 기존 코드와 데이터로부터 요구분석서를 복구 시키는 개념 

리팩토링

기능의 변경없이 내부 구조를 변경 및 개선하는 것 

 

(직전 한 번만 보고 들어가면 됨 )

디자인패턴이란?

유사한 문제를 해결하기 위해 설계들을 분류하고 각 문제 유형별로 가장 적합한 설계를 일반화하여 쳬계적으로 정리해놓은 것으로 SW 개발에서 효율성과 재사용성을 높임

- 절차형 언어와 함께 사용시 효율 극대화(X)

 

- 생성 패턴 ,구조 패턴 ,행위 패턴이 있다.

 

1) 생성패턴 : 프로토 팩토리에서 빌더싱글추상화 그려줌 (암기 방법)

 

2) 구조패턴 : A B C D F F P (암기방법)

Adaptor

Bridge

Composite

Decorator

Facade

Flyweight

Proxy(대리) 

 

 

참고

  • 정처기 필기 기출 문제
  • '컴퓨터일반 달달노트' 박태순 이성행 공저
  • '컴퓨터일반 기출문제집' 박미진 편저