■ 소프트웨어 공학
- 소프트웨어 공학 구성
- 소프트웨어 품질
-소프트웨어가 준수해야 하는 품질 속성
-기능성, 신뢰성, 사용성, 효율성, 유지보수성, 안전성 등 - 소프트웨어 프로세스
-소프트웨어를 주어진 목정을 수행하기 위한 일련의 절차
-소프트웨어 개발 생명 주기
-절차 이외에 관련된 인력, 방법, 도구 등을 포함 - 개발 방법론
-소프트웨어를 개발 하기 위한 기술적인 "How to"
-요구사항분석, 설계, 구현, 테스트 등의 활동들로 구성 - 개발 도구
-개발 프로세스와 방법론을 지원하는 도구
- 소프트웨어 프로세스 정의
-소프트웨어 개발에 필요한 절차만이 아니라, 그와 관련된 인력, 방법, 도구들을 통합하는 수단
-소프트웨어와 관련된 산출물을 개발, 유지하기 위해 사용하는 활동, 방법, 절차의 집합
■ 소프트웨어 생명주기 모델
-
주먹구구식 개발 모델
→요구사항 분석, 설계 단계 없이 일단 구현에 들어간 후 만족할 때까지 수정
→장정: 크기가 매우 작은 규모의 소프트웨어 개발에 유리
→단점
-계획이 정확하지 않음
-프로젝트 진행 상황 파악이 어려움
-개발문서가 없기 때문에 유지보수가 어려움 -
폭포수 모델
→소프트웨어 개발의 전 과정을 나누어 체계적이고 순차적으로 접근하는 방법
→이전 단계의 산출물을 다음 단계의 입력으로 활용
→장점
-각 단계별로 정형화 된 접근 방법 가능
-체계적인 문서화가 가능하여 프로젝트 진행을 명확하게 확인 가능
→단점
-앞 단계가 완료될 때까지 다음 단계들은 대기
-결과 시스템은 개발 후반부에 확인 가능하므로 고객의 요구사항 확인에 오랜 시간이 걸림 -
원형 모델
→폭포수 모델의 단점을 보완하여 점진적으로 시스템을 개발해 나가는 방법
→원형 모델을 만들어 고객과 사용자가 함께 평가한 후 개발 될 요구사항 정제
→장점
-빠른 고객의 요구사항 확인 검증 가능
-기능적인 완성도 증가
→단점
-고객의 검증이 없으면 원형 모델 폐기 불가 즉, 고객의 주기적 참여 필요
-성능, 보안, 견고성에 대한 보장이 어려움 -
나선형 모델
→폭포수 모델과 원형 모델의 장점을 수용하고 위험 분석을 추가
→프로젝트 수행 시 발생하는 위험을 관리하고 최소화 하려는 것이 목적
→장점
-프로젝트의 모든 단계에서 기술적인 위험을 직접 고려할 수 있어 사전에 위험 감소
-테스트 비용이나 제품 개달 지연 등의 문제 해결 가능
→단점
-개발자가 정확하지 않은 위험 분석을 했을 경우 심각한 문제 발생 가능
-상대적으로 복잡하여 프로젝트 관리 자체가 어려울 수 있음 -
V-모델
→ 폭포수 모델에 검증과 테스트 활동을 강조한 모델
→ 분석, 설계, 구현 단계마다 대응하는 확인 단계를 두어 정확한 고객 요구사항 확인 가능
→장점
-프로젝트 관리가 용이하고 신뢰성 향상
-개발 후 발생하는 오류를 줄일 수 있음
→단점
-반복이 없이 변경을 다루기가 어려움
■ 소프트웨어 개발 방법론
-
의미
-소프트웨어 개발 생명주기 내의 각 단계에서의 수행활동과 방법을 구체적으로 정의
-소프트웨어를 개발하기 위한 산출물과 수행 활동의 기법 등을 체계적으로 정리
-개발을 표준화 및 체계화하여 제품 개발의 효율성을 향상
-사용자 및 개발자간 의사소통을 위한 수단으로 활용
-작업절차, 작업방법, 산출물, 관리, 기법, 도구 -
구조적 방법론
→정형화 된 절차 및 도형 중심의 도구를 사용하여 사용자 요구사항 파악 및 문서화하는 기법
→정보와 정보의 구조를 중심으로 분석, 설계, 구현 진행
→전통적인 Top-Down 방식의 개발 방법
→기본원리
-추상화
-구조화-수평분리: 입력/자료변환/출력
-구조화-수직분리: 상위 제어 모듈과 하위 모듈로 분리
-단계적 상세화
-모듈화
→데이터 흐름 다이어그램(DFD), 데이터 사전(DD), 소단위 명세(Minispec), 의사결정트리
→마치 가공 전 돌을 조각하여 조각상을 만들어내는 것과 같은 원리 -
객체지향 방법론
→개발 대상을 객체와 메시지로 표현
→캡슐화와 정보은닉, 상속 등 객체의 특징 사용
→Bottom-Up방식의 개발 방법
→객체(정보) 관점, 기능 관점, 동적 관점
→객체지향 분석 및 설계
-주어진 요구사항의 문제에 대해 객체를 찾고 객체 간의 관계를 분석
-객체(정적)모델링: 객체 및 클래스 정의, 시스템에 대한 전반적인 개념 모델링
-동적모델링: 객체의 활동 및 흐름을 분석하여 시스템의 동적인 기능 표현
-UML 중심으로 모델링 -
CBD 방법론
→독립적으로 실행 가능하며 표준 인터페이스를 갖춘 형태의 컴포넌트 중심으로 개발
→Use Case 중심의 분석과 아키텍처 중심의 설계
→반복과 점진적인 개발
→객체지향 분석 및 설계
-현황 평가 및 도메인 문석 -> Use Case 도출 -> 요구사항 정의 -> 시스템 구조정의
-반복적 계획수립 -> Use Case 중심의 모델링 -> UI 프로토타이핑 -> 컴포넌트 정의 및 설계 -
비교
-구조적 방법론: Logic 중심, 제어 가능 모듈로 구조화 -> 재사용 및 유지보수성 제고
-객체지향방법론: 고도의 객체화, 상속에 의한 재사용(white box reuse)
-CBD 방법론: black box reuse 지향, 컴포넌트 생산/선택/평가/통합의 개발 방법-구조적 방법론: 접근방법-Top Down, 설계방향-프로세스 중심(기능 위주), 확장성/재사용성-확장어려움,중복 많음
-객체지향 방법론: 접근방법-Bottom Up, 설계방향-데이터 중심(데이터+연산), 확장성/재사용성-확장용이,재사용성 높음-CBD 방법론
→개발프로세스: 소규모 단위의 프로젝트로 나누어 반복과 점진 수행
→아키텍쳐 측면: 프로젝트 시작과 함께 계획 및 표준화 수립 후 지속적 개선
→응용개발 기술: 컴포넌트 단위릐 블랙박스 상태에서 표준 인터페이스 적용(객체지향의 상속 개념 없음)
-객체지향 방법론
→개발프로세스: 전통적 SDLC를 따르며 개발 품질향상을 위해 Prototype 수행 가능
→아키텍쳐 측면: 명확한 아키텍쳐 제시 및 표준화가 미흡
→응용개발 기술: 객체지향 언어 중심 프로그래밍(클래스 수준의 상속, 다형성 접근)
■ 요구사항 분석
소프트웨어 개발 참여자들로 하여금 개발되는 소프트웨어 제품을 전체적으로 파악하도록 하여 의사 소통 시간을 절약
상세한 요구사항이 있어야만 산정이 가능하고, 이를 기반으로 계획을 세울 수 있기 때문
-
기능적 요구사항
-수행 될 기능과 관련되어 입력, 출력 및 처리 과정이 필요
-목표로 하는 제품의 구현을 위해 소프트웨어가 가져야 하는 기능적 속성 -
비-기능적 요구사항
-제품의 품질 기준 등을 만족시키기 위해 소프트웨어가 가져야 하는 성능, 사용의 용이성 안전성과 같은 행위적 특성
-시스템의 기능에 관련되지 않은 사항을 나타냄(성능,용이성,신뢰도 등등) -
인터페이스 요구사항
-다른 조직(또는 다른 시스템이나 모듈) 간의 정보를 주고 받는 활동을 총칭
-내부 인터페이스: 모듈 내부 프로그램 간의 인터페이스
-외부 인터페이스: 타 모듈과의 정보 송수신 인터페이스
-사용자 인터페이스: 레이아웃, 윈도우 등
-하드웨어 인터페이스: 포트 수, 네트워크 프로토콜, 메모리 용량 등
-소프트웨어 인터페이스: DBMS,EJB 등 -
요구사항 개발 단계
-
요구사항 수집 방법
-document-based: 시스템 요구사항, 시스템 아키텍처 문서 및 이에 따른 변경 사항 기반
-interview: 가장 직접적인 요구사항 습득기법. 간단, 실질적으로 모든 상황에서 적용가능
-workshop: 정해진 짧은 기간 안에 고객의 주요 요구사항을 얻을 수 있는 기법, cost-effective, time-efficient
-설문조사: 고객의 비즈니스를 잘 알고 있는 경우 정량적 결과를 얻어 통계적 분석을 하고자 할때 주로 사용. 기초 인터뷰, 분석작업 이후 고객 요구사항 재차 확인 용도가 유용
-role-playing: 고객의 비즈니스가 매우 복잡할 경우, 고객의 입장에서 고객의 실세계를 경험하게 하여 이해를 높이고자 할 때 사용되는 기법
● 요구사항 분석 방법
-
문장 분석 방법
-문서로 제공된 시스템 요구사항, 제안서, 기존 시스템 변경사항 자료 등을 기반으로 요구사항을 분석
-구조적 방법론에서 주로 사용 -
데이터 흐름 다이어그램(DFD) 분석
-구조 분석을 위한 기법으로 시스템이 다루는 데이터나 저장소, 프로세스나 저장소 등을 기반으로 요구사항을 분석
-
스윔 레인 분석
-비즈니스 프로세스나 제안된 소프트웨어 시스템 운영에 필요한 각 단계를 표현하는 방법을 제공
-UML Activity 다이어그램과 유사하며 기능 요구사항을 묶는데 도움이 됨 -
Use Case 분석
-Actor가 어떤 중요한 결과를 성취하는 데 있어 결과를 만들어내는, 시스템과 외부 행위자 간의 상호작용의 순서를 설명함
-사용자의 관점에서 시스템의 서비스 혹인 기능 및 그와 관련한 외부 요소를 보여주는 다이어그램
-고객과 개발자가 함께 보며 요구사항에 대한 의견을 조율할 수 있음
-분석의 결과로 기능 요구사항을 도출
-
의사결정 일람표와 의사결점 트리 분석
-복잡한 논리와 의사결정을 필요로 할 때 시스템이 해야 하는 일을 표현하는 두 가지 대안기법
-의사결정 일람표는 행동에 영향을 미치고 각 요소의 조합에 대한 시스템의 예상 행위를 나타내는 모든 요소에 대한 다양한 값을 나타냄
-의사결정 트리는 프로그램의 분기문과 같은 형태로 의사결정을 표현-의사결정 일람표
-의사결정 트리
-
이벤트 반응표 분석
-실시간 시스템 요구사항 분석 시 이벤트에 따라 시스템이 수행해야 할 반응을 중심으로 분석
-이벤트 주기, 이벤트를 처리하는 데 필요한 데이터 요소, 이벤트 반응 후의 시스템 상태 -
요구사항 명세 방법
-간단한 시스템의 경우 Use Case 사용
-국제표준 IEEE-Std-830 명세 표준 사용
●소프트웨어 설계
- 요구사항과의 연계
-기능 요구사항 중심으로 시스템 모듈 구성
-비-기능 요구사항에 대한 시스템 내부 구성
-필요시 패턴(singleton, observer..) 적용
■ 소프트웨어 테스트 개요
-
소프트웨어 정적 검증
-소스코드 수준에서의 s/w unit 설계와 구현의 원칙
-MISRA-C Rule Set 준수하면 설계원칙 요건을 만족 -
소프트웨어 동적 검증
-V&V(Verification & validation) -
소프트웨어 동적 테스트
-
Requirement Based Test
소프트웨어 단위명세서/아키텍처 설계서로부터 TC를 설계하여 테스트를 수행하는 방법으로 단위명세서와 아키텍처 설계서를 분석하여 주요한 행위에 대해 TC(입력/출력/조건)를 설계하고 테스트를 수행함
-
Interface Test
소프트웨어 단위/통합 수준에서의 interface를 테스트 하는 것으로 단위/컴포넌트 간의 통신 및 데이터 교환이 원활하게 이루어지는지를 확인함
-
Fault injection test
-주입된 결함이 소프트웨어에 어떻게 전파되는 지를 확인하는 테스트의 목적
-전파 절차를 관찰하기 위해서 측정 장치가 반드시 필요
-측정 장치로써 소스코드를 사용할 수 있지만 없어도 가능
-
Resource Usage Test
-소프트웨어 단위/통합 수행에 따른 MCU 사용률 또는 메모리 사용률, 통신 점유율을 측정하여 기준에 적합한지 검증
-
Back to Back Test
-소프트웨어 단위/통합 수준에서의 시뮬레이션 모델과 실제 수행 코드와의 일치성 여부를 검증
-
테스트케이스 개발 기법
-명세기반, 경험기반, 구조기반 -
MIL/SIL/PIL/HIL/Test Bench/In the Vehicle Platform 구분
-model/woftware/process/hardware,,,
-
소프트웨어 품질 기준 사례
→정적검증
-코딩 룰: MISRA-C
-소프트웨어 메트릭: 복잡도, 함수 콜 관계, 재귀함수
-run time 에러 검증: 변수관련 부분, 값 반환, Loop 외
→동적검증
-Coverage
-Logic Based Testing
