etc

소프트웨어공학 요점정리

4leaf3 2024. 2. 8. 16:06

 

소프트웨어의 특징

① 유형성 : 분석/설계 산출물로 가시화시킬 수 있으므로 유형이다.

② 동적행위성 : 하드웨어에 의해 수행되고 사용자와 상호작용할 때 비로소 소프트웨어가 되므로 동적이다.

③ 상품성

④ 견고성 : 한번 구성되면 계속 사용하여야 한다.

⑤ 비마모성 : 마모되는 것이 아닌 질이 나빠지는 것이다.

⑥ 비제조성 : 제조, 생산이 아닌 개발된다.

⑦ 비조립성

⑧ 비과학성 : 과학적인 것이 아닌 조직, 인력, 시간 등이 중심이 되는 관리기술이 중요하다.

 

소프트웨어의 생명주기 단계

계획
분석
설계
구현
시험
유지보수
  • 목적성 부여
  • 타당성 분석
  • 사용자 문제정의
  • 개발 계획
  • 비용, 일정 예측
  • 사용자 요구분석
  • DD 작성
  • DFD 작성
  • minispec 작성
  • 내부 및 외부 설계
  • 구조와 알고리즘
기본설계 & 상세설계
  • 프로그래밍 단계
  • 모듈의 코딩, 디버깅
  • 모듈 시험
  • 통합시험
  • 확인시험
  • 시스템 시험
  • 기능 개선
  • 적응
  • 수정
  • 예방

 

소프트웨어 생명주기 모형

① 폭포수 모형 (Waterfall Model, 순차적 모델)

순서
타당성 조사 → 계획 → 요구 분석 → 설계 → 구현 → 검사 → 유지보수
특징
오래되고 널리 사용된 전통적인 기법
각 단계가 순차적 진행, 단계별 산출물이 명확
오류 없이 명확하게 하여 다음 단계로 진행하지만 현실적으로 오류 없이 진행하기 어려움
과정이 병행 수행되거나 이전 단계로 넘어가는 경우가 없음
장점
응용 분야가 단순하거나 내용을 잘 알고 있는 경우 적용
비전문가가 사용할 소규모 시스템을 개발하는데 적합
단점
개발 과정 중에 발생하는 새로운 요구나 경험을 설계에 반영하기 힘들다.
설계와 코딩 및 테스트를 지연시킬 우려가 있다.

 

② 프로토타이핑 모형 (Prototyping Model, 원형)

순서
요구사항분석 → 신속한 설계 → 프로토타입 작성 → 사용자 평가 → 프로토타입의 정제 (세련화) → 공학적 제품화
특징
요구사항을 미리 파악하기 위한 것으로, 개발자가 구축한 SW모델을 사전에 만들어 최종 결과물이 만들어지기 전에
사용자가 미리 최종 결과물의 일부 또는 모형을 볼 수 있다.
시제품을 빨리 완성하기 위해 비효율적인 알고리즘 사용 가능, 프로토타입의 내부적 구조 크게 상관X
사전에 사용자의 요구사항을 신속하고 정확하게 파악한다.

 

③ 나선형 모형 (Spiral Model)

순서
계획수립 → 위험분석 → 개발 → 평가
특징
폭포수 모형과 프로토타이핑 모형의 장점을 수용하고, 새로운 요소인 위험 분석을 추가한 진화적 개발 모델
대규모 시스템 소프트웨어 개발에 가장 현실적인 소프트웨어공학 패러다임
개발 시 생기는 위험을 최소화하여 관리하는 것이 주목적, 개발자나 사용자는 각 과정에 따른 위험을 잘 파악하여
대처 가능하다.
위험성 평가에 크게 의존하고 유지보수 과정이 없다.

 

④ V 모형

특징
개발 작업과 검증 작업 사이의 관계를 명백히 드러내 놓은 폭포수 모델의 변형
생명주기 모든 단계에서 검증과 확인과정이 있어 오류를 줄일 수 있으므로, 높은 신뢰성이 요구되는 분야에 적합하다.
생명주기의 반복을 허용하지 않아 변경을 다루기가 쉽지 않다.

 

V 모델

 

⑤ 애자일 모델 (Agile Model)

정의
고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론을 지칭
애자일 기본가치
프로세스와 도구 중심이 아닌 개개인과의 상호 소통을 중시
문서 중심이 아닌 실행 가능한 소프트웨어를 중시
계약과 협상 중심이 아닌 고객과의 협력을 중시
계획 중심이 아닌 변화에 대한 민첩한 대응을 중시

 

 

프로젝트 관리 대상

  • 3P : 사람(People), 프로세스(Process), 문제(Problem)
  • 4P : 사람(People), 프로세스(Process), 제품(Product), 프로젝트(Project)

* Brooks 법칙 : 인력 추가가 오히려 스케쥴 지연 사태를 악화시킬 수 있다.

/ 소프트웨어 모듈 사이의 상호작용에 대한 복잡도 증가, 사람들간의 의사소통 필요가 증가

/ 신규 프로그래머에게 교육 필요, 소프트웨어 개발 프로세스들 간의 산호의존성이 존재

 

 

프로젝트 계획

1) 비용 측정

LOC
(Line Of Code)
  • 노력 = 개발기간 × 투입인원 = 총 LOC / 1인당 월평균 생산코드 라인 수
  • 개발비용 = 노력 × 단위비용(1인당 월평균 인건비)
  • 개발기간 = 노력 / 투입인원
  • 생산성 = 총 LOC / 노력
COCOMO
원시 프로그램의 규모에 의한 비용 예측 모델
① 단순형 (유기형, Organic) : 일괄 처리나 비즈니스 자료 처리용의 5만 라인 이하의 소프트웨어 평가
② 중간형 (반 내장형, Semi-detached) : 트랜잭션 처리 시스템, 운영체제 등의 30만 라인 이하의
소프트웨어 평가
③ 내장형 (Embedded) : 최대형 규모의 트랜잭션 시스템이나 운영체제 등의 30만 라인 이상의
소프트웨어 평가
기능 점수
( FP-Function Point)
프로그래밍 언어에 비종속적, 즉 라인 수에 기반을 두지 않는 방법

 

2) 일정 계획

  • 일정계획순서 : 규모 추정 (SDLC) → 작업 분해 (WBS) → 상호 의존 관계를 CPM 네트워크 도식 → 간트 차트 (Gantt Chart)
WBS
도표 내에 있는 각 관리 단위의 성분을 밝히고, 각 성분에 비용을 할당하고, 이들을 합산하여 산정
(프로젝트 진행에서 일어나는 모든 작업을 찾아내기 위해 프로젝트의 목표를 작은 중간 목표로 세분화한 것)
CPM
경비와 개발일정을 최적화하려는 일정계획 방법으로, 임계경로 방법에 의한 프로젝트 최단 완료시간(최장경로)을
구함
작업의 의존관계를 파악해 각 작업이 최대로 빨리 끝날 수 있는 시간, 최대로 늦추어 시작할 수 있는 시간 등을
계산할 수 있다.


* 전체 프로젝트의 작업공정은 여러가지 경로가 형성되는데, 이 경로들 중 소요기간이 가장 많이 소요되는 경로가
임계경로이다.
간트 차트
소작업별로 작업의 시작과 끝을 나타낸 막대 도표이다.
프로젝트 개발과정 전 단계를 한눈에 파악할 수 있으며, 프로젝트 일정 계획, 자원 활용 계획을 세우는데 유리하다.
작업들 사이의 관계를 직접 보여주지 못한다.

 

3) 개발 조직 계획

민주적 분산형
팀 구성원 사이의 의사교류를 활성화 시키므로 복잡한 장기 프로젝트에 적합
구성원들의 책임과 권한의 약화로 대규모 프로젝트에는 부적합
(DD, Democratic Decentralized)
중앙 집중형
한 사람에 의해 통제할 수 있는 소규모 프로젝트에 적합
의사결정 경로가 짧아서 프로그램 개발 과정이 신속
(CC, Controlled Centralized)
혼합형
중앙집중형과 분산형 팀의 중간 형태로, 대규모 프로젝트에 적합
(CD, Controlled Decentralized)

 

 

요구분석의 정의 : 자료의 현실세계에서 흐름에 따른 가공 절차 시각에서 사용자 요구를 파악하는 자료흐름중심 분석기법

/ 사용자의 요구사항을 명확히 규정하고, 시스템의 특성을 반영하는 과정이며, 이 단계에서 사용자의 뜻을 이해하고 업무를 분석한다.

/ 요구사항 분석의 최종 목표는 요구사항 명세서이다.

 

요구분석의 특징

① 시스템을 하향식으로 분할

② 시스템 모형 작성에 필요한 도구를 제공

③ 도형 중심의 문서화 도구를 사용하여 분석가와 사용자 간 의사소통이 원활

④ 시스템 개발의 모든 단계에서 필요한 명세서 작성 가능

 

구조적 분석 기법 순서

  • 배경도 작성 → 상위 자료 흐름도 작성 → 하위 자료 흐름도 작성 → 자료 사전 작성 → 소단위 명세서 작성

 

구조적 분석 도구

자료 흐름도
(Data Flow Diagram)
기능 중심의 시스템을 모델링하며, 자료가 소프트웨어 내의 절차에 따라 흐르면서 변화되는 과정을
도형화한 기법
구성요소 : 외부 입출력, 처리, 자료 흐름, 자료 저장소
자료 사전
(Data Dictionary)
자료 흐름도(DFD)의 대상이 되는 자료의 내용을 구체적으로 명세화
(자료 흐름이나 자료 저장소들의 의미를 서술)
데이터 원소를 정의하고 기록하며, 데이터 설계와 프로그램 논리의 구현에 선행
소단위 명세서
(mini-spec)
DFD의 최하위 버블 각각에 대해 하나의 미니명세서 작성, 미니명세서는 구조화된 자연어나
도형으로 작성
최하위 프로세스가 어떤 기능을 하는가를 구조적 영어(순차, 선택, 반복)로 기술
작성도구 : 구조적 문장, 흐름도, N-S도표, 의사결정트리, 의사결정표, 의사코드, 상태전이도

 

요구분석의 명세화가 갖추어야 할 특성

①무결성 ②완벽성 ③일관성 ④명확성 ⑤기능적 ⑥검증 가능성 ⑦추적 가능성 ⑧변경 용이성

 

 

구조적 설계의 기본 원칙

추상화
데이터를 사용하는데 필요한 함수만 알려주는 기법
불필요한 부분을 생략하고, 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화 시키는 것
구조화
문제의 영역들을 각각의 기능 모듈 단위로 세분화하여 모듈간의 관계를 설계
  • 제어도 (Fan-Out) : 하나의 모듈이 직접 제어하는 하위 모듈의 수
  • 공유도 (Fan-In) : 하나의 모듈을 호출하는 상위 모듈의 수
정보 은닉
모듈간의 불필요한 상호작용을 제거하기 위해 최소한의 정보만 보여주고, 그 이외의 상세내용은
모듈에서 접근되지 않도록 하는 것
각 모듈이 다른 모듈에 구애 받지 않고 설계
캡슐화는 정보 은닉을 통해 추상화, 독립성을 향상
단계적 정제
소프트웨어 기능에서 시작하여 그 기능들을 점차적으로 구체화시키는 작업
상세한 내역은 가능한 뒤로 미루어가면서 진행
모듈화
전체 프로그램을 한번에 설계하지 않고 단일 기능을 갖출 수 있도록 부분적으로 묶어서 처리하는 기술
서브 루틴, 서브 프로그램, 함수를 작성하기 위한 설계 기법

 

* 모듈화 : 모듈의 독립성을 보장하기 위해서는 모듈간의 결합도는 최소화, 응집력은 최대화

- 결합도 : 모듈들이 서로 관련되거나 연결된 정도

- 응집도 : 한 모듈 내에 있는 처리 요소들 사이의 기능적인 연관 정도

 

 

구조적 설계 도구

 

구조도
시스템 기능을 몇 개의 기능으로 분할하여 모듈로 나타내고, 모듈간의 인터페이스를 계층구조로 표현한 도형
HIPO
프로그램 논리의 문서화와 설계를 위해 도식적인 방법을 제공하고, 기능 표현 중심이다.
* 계층도표, 총괄도표, 세부도표
N-S Chart
논리 기술에 중점을 둔 도형식 표현 도구로 순차, 선택, 반복의 3가지 제어구조를 표현한다.

 

디자인 패턴의 정의 : 자주 사용하는 설계 형태를 정해서 이를 유형별로 설계 템플릿을 만들어둔 것

 

디자인 패턴의 장단점

장점
단점
  • 개발자간의 원활한 의사소통
  • 소프트웨어 구조 파악 용이
  • 재사용을 통한 개발 시간 단축
  • 설계 변경 요청에 대한 유연한 대처
  • 객체지향 설계 / 구현 위주
  • 초기 투자비용 부담

 

디자인 패턴 분류

① 객체 생성을 위한 패턴 : 객체의 생성과 변경이 전체 시스템에 미치는 영향을 최소화

- 종류 : factory method, singleton, prototype, builder, abstraction factory

 

② 구조 개선을 위한 패턴 : 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계

- 종류 : adapter, composite, bridge, decorator, facade, flyweight, proxy

 

③ 행위 개선을 위한 패턴 : 반복적으로 사용되는 객체들의 상호작용을 패턴화, 여러가지 행위 관련 패턴 사용

- 종류 : template method, interpreter, iterator, observer, strategy, visitor, chain of responsibility, command, mediator, state, memento

 

 

객체지향의 기본 개념

객체 (object)
현실세계에 존재할 수 있는 유­­ㆍ무형의 모든 대상을 말하며, 속성과 메소드로 정의된다.
속성 (attribute)
객체가 가지고 있는 특성으로, 현재 객체의 상태를 의미한다.
클래스
(class)
하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추상화
클래스 내의 모든 객체들은 속성 값만 다를 뿐 동일한 속성과 행위를 갖게 된다.
인스턴스 (instance)
클래스로 정의된 객체의 요소로 객체의 복사본이라고 할 수 있음
메시지
(message)
한 객체가 다른 객체의 메소드를 부르는 과정으로, 외부에서 하나의 객체에 보내지는
메소드의 요구이다.
메시지를 주고받음으로써 객체간의 상호작용을 한다.
메소드 (method)
객체가 어떻게 동작하는지를 규정하고 속성의 값을 변경시킨다.
캡슐화
(encapsulation)
객체를 정의할 때 연관된 자료 구조와 함수를 한 테두리로 묶는 것
장점 : 재사용이 용이, 인터페이스를 단순화, 변경이 발생할 때 오류의 파급 효과가 적음
정보은닉
(information hiding)
캡슐화된 객체 내부의 자료 구조나 함수의 기능을 외부에 영향을 받거나 주지 않도록 설계하는 법
→ 고려하지 않은 여향 (side effect)들을 최소화
상속성
(inheritance)
상위 클래스에서 자료구조나 함수 기능을 필요할 때마다 상속받아 새로운 형태의 클래스와
객체로 확장하여 사용
하위 계층은 상위 계층의 세분화 계층이 되고, 상위 계층은 하위 계층의 일반화 계층이 된다.
추상화
(abstraction)
객체를 설계할 때 자료구조ㆍ 함수를 완전하게 설계하지 않고, 개략적으로 설계하여 점차적으로
완전한 객체를 정의해 나가는 것
다형성
(polymorphism)
상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질
한 메시지가 객체에 따라 다른 방법으로 응답할 수 있도록 설계 → 상이한 클래스들이 동일한
메소드를 이용해야함

 

 

소프트웨어 개발과 시험의 관계

  • 검사 (test) : 노출되지 않은 숨어 있는 결함을 찾기 위해 소프트웨어를 작동시키는 일련의 행위와 절차
  • 디버깅 (debugging) : 개발자의 시각에서 노출된 오류를 고치는 활동, 검증 및 확인 결과 발견된 오류를 제거하는 것
  • 검증 (verification) : 개발자 입장에서 시스템이 명세서대로 만들어졌는지를 점검하는 것
  • 확인 (validation) : 사용자 시각에서 고객의 요구사항이 구현되었는지를 점검하는 것

 

소프트웨어 시험 종류

① 시험 단계에 의한 분류

모듈 (단위) 시험
독립적인 환경에서 하나의 모듈만을 테스트, 컴파일된 독립 모듈의 완전성을 따져보는 모듈시험
드라이버 (상위 가상모듈), 스텁 (하위 가상모듈) 사용
화이트박스 시험 기법을 이용한다.
통합 시험
시스템 모듈간의 상호 인터페이스에 관한 테스트, 모듈을 결합시켜 하나의 시스템으로 만드는 과정의 시험
모듈간의 인터페이스와 관련된 결함들을 발견하고 제거하면서 모듈들을 체계적으로 조합시키는 작업
드라이버 (상위 가상모듈), 스텁 (하위 가상모듈) 사용
상향식통합 검사, 하향식통합 검사, 빅뱅기법, 깊이우선, 너비우선
시스템 시험
시스템이 초기의 목적에 부합하는지에 대한 테스트
소프트웨어가 하드웨어와 결합한 후 수행하는 시험으로, 전체 시스템의 기능 및 성능을 검증하는 시험
종류 : 회복시험, 안전시험, 강도시험, 성능시험, 구조시험 → ③을 참고하기
인수 시험
개발 완료된 시스템이 사용자가 수용할 만한 품질인가 시험, 블랙박스 시험기법을 이용.
  • 알파시험 : 특정 사용자들이 개발자 위치에서 테스트를 수행한다.
  • 베타시험 : 최ㅣ종 사용자가 사용자 환경에서 테스트를 수행한다.
설치 시험
현장에 설치 및 가동시키면서 하는 시험

 

② 시험 방법에 의한 분류

화이트박스 시험
프로그램 내부의 논리적 구조를 파악하거나, 경로들의 복잡도를 계산하는 시험
ex) 기초 경로 검사, 루프검사, 데이터 흐름 검사, 조건 검사
블랙박스 시험
원시코드는 보지 않은 채 목적코드를 수행시켜 가면서 결함을 발견할 수 있는 시험 방식
소프트웨어 외부명세서를 기준으로 기능과 성능을 테스트
ex) 동등분할, 경계값 분석, 오류 예측, 원인-결과 그래프

 

③ 시험 목적에 의한 분류

기능 시험
주어진 입력에 대한 기대되는 출력제공 여부 시험
성능 시험
응답시간, 처리량, 메모리 활용도, 처리속도 등
강도 (스트레스) 시험
정보의 과부하시, 최저조건 미달-최고조건 초과시, 물리적 충격과 변화시 반응속도
구조 (복잡도) 시험
소프트웨어에 내제되어 있는 논리경로의 복잡도를 평가하는 구조시험

 

프로세스 능력 평가 모델

① SW-CMM : 프로젝트 개발 조직에서 프로세스 성숙도가 높은 조직이 성숙도가 낮은 조직보다 높은 품질의 소프트웨어를 생산할 수 있다는 모델

/ CMM은 소프트웨어 공급자의 강점과 약점을 평가하는 수단으로, 개발자가 프로세스의 능력을 스스로 평가하고 평가 결과에 따른 개선 방향을 설정하는데 사용

 

② CMMI : 프로세스 표준화의 기준과 방향을 제시, 조직 프로세스에 능력을 평가하거나 성숙도를 평가

 

 

 

소프트웨어 유지보수

정의 : 소프트웨어가 제품으로 개발된 후 사용자가 사용하기 시작하면서부터 폐기될 때까지 오류를 수정하거나 새로운 기능을 추가하기 위해 소프트웨어를 변경하는 프로세스를 의미

 

종류

① 수정 유지보수 : 검사 단계에서 발견하지 못한 오류를 찾아 수정, 하자의 원인을 찾아 문제를 해결하는 것

② 완전 유지보수 : 본래 기능에 새로운 기능을 추가하거나 성능을 개선하기 위해 소프트웨어를 확장

③ 예방 유지보수 : 미래에 유지보수를 용이하게 하거나 기능 및 신뢰성 향상을 위해 소프트웨어를 변경

④ 적응 유지보수 : 소프트웨어 수명기간 중에 발생하는 환경의 변화를 기존의 소프트웨어에 반영하기 위한 활동

 

소프트웨어의 형상관리 (SCM)

정의 : 소프트웨어에 대한 변경을 철저히 관리하기 위해 개발된 일련의 활동

/ 소프트웨어를 이루는 부품의 Baseline(변경통제 시점)을 정하고 변경을 철저히 통제하는 것

 

형상관리의 항목 (SCI) : 분석서, 설계서, 프로그램, 사용자 지침서

 

형상관리의 기능 : 형상 관리, 버전 관리, 형상 통제, 형상 감사, 형상 보고

 

신뢰도

① MTBF (Mean Time Between Failure) : 고장과 또 다른 고장 사이의 평균 시간, ① = ② + ③

② MTTF (Mean Time To Failure) : 주어진 시각에서 고장이 발생할 때까지의 평균 시간

③ MTTR (Mean Time To Repair) : 고장이 발생한 시점에서 수리 시까지의 평균시간

④ 이용도 (가용도) : 프로그램에서 시간이 주어진 시점의 요구 사항들에 따라 운영되는 확률, ④ = (② / (② + ③)) × 100(%)

 

 

소프트웨어 재공학

  • 소프트웨어 개조 : 기존 소프트웨어에 수정을 가함으로써 이해하기 쉽고 변경이 용이하다. / 미래의 변화에 품질상의 문제를 유발시키는 가능성을 줄이는 작업
  • 소프트웨어 역공학 : 소프트웨어 개발단계를 역으로 거슬러 기존 코드와 데이터로부터 설계사양서나 요구분석을 복구 / 낮은 수준의 추상표현에서 높은 수준의 추상표현을 추출하는 과정

 

리팩토링 (Refactoring)

정의 : 코드스멜을 없애고 코드의 품질을 향상하는 것을 의미, 기능의 변경없이 내부구조를 변경하는 것

 

목적 : 소프트웨어의 디자인 개선, 소프트웨어를 이해하기 쉽게 개선, 버그 찾기, 프로그램을 빨리 작성하는데 도움을 준다.

 

* 코드스멜 : 읽기 어렵거나 복잡하거나 중복된 로직을 가진 프로그램

 

CASE (Computer Aided Software Engineering)

정의 : 소프트웨어공학 도구에 있어 하나의 도구를 이용해 생성된 도구를 다른 도구가 사용가능하도록 여러 도구들이

통합될 때 확립된 개발지원시스템