소프트웨어 공학의 이해
소프트웨어 공학
소프트웨어 공학 구성
-
소프트웨어 품질
소프트웨어가 준수해야 하는 품질 속성 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 안전성 등 -
소프트웨어 프로세스
소프트웨어를 주어진 목적을 수행하기 위한 일련의 절차 소프트웨어 개발 생명주기 절차 이외에 관련된 인력, 방법, 도구 등을 포함한다
-개발 방법론
소프트웨어를 개발하기 위한 기술적인 "How to"
요구사항분석, 설계, 구현, 테스트 등의 활동들로 구성- 개발 도구
개발프로세스와 방법론을 지원하는 도구
소프트웨어 프로세스
소프트웨어 프로세스 정의
- 소프트웨어 개발에 필요한 절차만이 아니라, 그와 관련된 인력, 방법, 도구 등을 통합하는 수단
- 소프트웨어와 관련된 산출물을 개발, 유지하기위한 활동, 방법, 절차의 집합
소프트웨어 프로세스 - 생명주기 모델
소프트웨어 생명주기
- 순차적 또는 병렬적 단계
- 가장 상위 수준의 프로세스
소프트웨어 생명주기 모델
- 주먹구구식 개발 모델
-
요구사항분석, 설계없이 일단 구현
장점 : 크기가 작은 소프트웨어 개발 유리 단점 : 계획이 정확하지 않다 프로젝트 진행 상황 파악이 어렵다 개발문서가 없기때문에 유지보수가 힘들다 (하지만 지금도 많이 사용)
- 폭포수 모델
-
소프트웨어 개발의 전 과정을 나누어 체계적, 순차적 접근
-
이전 단계의 산출물을 다음 단계의 입력으로 활용한다
장점: 각 단계별로 정형화된 접근이 가능하다 체계적인 문서화가 가능하여 프로젝트 진행을 명확하게 확인 가능하다 단점: 앞 단계가 완료될때까지 뒤 단계는 대기 결과시스템은 개발 후반부에 확인 가능하므로 고객의 요구사항 확인이 오래걸림
- 원형 모델
-
폭포수모델의 단점을 보완하여 점진적으로 시스템을 개발
-
원형모델을 만들어 고객 + 사용자가 함계 평가후 개발될 요구사항을 정제한다
장점: 빠른 고객의 요구사항 확인 검증 가능 기능적인 완성도가 증가한다 단점: 고객의 검증이 없으면 원형 모델 폐기가 불가능하다 (고객의 주기적 참여 필요) 성능, 보안, 견고강에 대한 보장이 어렵다
- 나선형 모델
-
폭포수 모델과 원형 모델의 장점을 수용하고 위험 분석을 추가한 모델
-
프로젝트 수행 시 발생하는 위험을 관리하고 최소화 하려는것이 목적이다.
장점: 프로젝트의 모든 단계에서 기술적 위험을 직접 고려할 수 있어 사전에 위험이 감소 테스트 비용이나 제품 개발 지연등의 문제 해결이 가능하다 단점: 개발자가 정확하지 않은 위험 분석을 했을 경우 심각한 문제 발생가능성 상대적으로 복잡하여 프젝 관리자체가 어려울 수 있다.
- V - 모델
-
폭포수 모델에 검증과 테스트활동을 강조한 모델
-
분석, 설계, 구현 단계마다 대응하는 확인 단계를 두어 정확한 고객 요구사항 확인이 가능하다
장점: 프로젝트 관리가 용이하고 신뢰성이 향상한다 개발 후 발생하는 오류를 줄일 수 있다 (다양한 변형이 가능하다) 단점: 반복이 없이 변경을 다루기가 어렵다.
소프트웨어 개발 방법론
소프트웨어 개발 방법론 의미
- 소프트웨어 개발 생명주기 내의 각 단계에서의 수행활동과 방법을 구체적으로 정의
- 산출물과 수행활동기법등을 체계적으로 정리
- 개발을 표준화 및 체계화하여 제품 개발의 효율성을 향상
- 사용자 및 개발자간 의사소통을 위한 수단으로 활용
개발 방법론 구성요소
- 작업절차, 작업방법, 산출물, 관리, 기법, 도구
구조적 방법론
-
전통적인 Top-Down 방식
-
정보와 정보의 구조를 중심으로 분석, 설계, 구현
-
정형화된 절차 및 도형 중심의 도구를 사용
-
기본원리 : 추상화, 구조화(수평분리, 수직분리), 단계적 상세화, 모듈화
데이터 흐름 다이어그램 (DFD), 데이터 사전(DD), 소단위 명세(Minispec), 의사결정트리
객체 지향 방법론
-
개발 대상을 객체와 메시지로 표현
-
캡슐화와 정보은닉, 상속 등 객체의 특징 사용
-
Bottom-Up 방식의 개발 방법
-
객체(정보)관점, 기능관점, 동적관점
객체(정적)모델링: 객체 및 클래스 정의
동적모델링: 객체의 활동 및 흐름을 분석, 시스템의 동적인 기능 표현
UML 중심 모델링
CBD 방법론
-
독립적으로 실행 가능, 표준 인터페이스를 갖춘 형태의 컴포넌트 중심 개발
-
Use Case 중심의 분석과 아키텍쳐 중심의 설계
-
반복과 점진적 개발
소프트웨어 프로세스
요구사항 분석
요구사항
요구사항 중요성
-
소프트웨어 개발 참여자들로 하여금 개발되는 소프트웨어 제품을 전체적으로 파악하도록 하여 의사소통 시간을 절약
-
상세한 요구사항이 있어야만 산정이 가능하고, 이를 기반으로 계획을 세울 수 있기 때문
요구사항 분류
기능적 요구사항
-
수행될 기능과 관련되어 입력, 출력 및 처리과정 필요
-
목표로 하는 제품의 구현을 위해 소프트웨어가 가져야하는 기능적 속성
비기능적 요구사항
-
제품의 품질기준을 만족시키기 위해 소프트웨어가 가져야하는 성능, 사용의 용이성과 안정성
-
시스템의 기능에 관련되지 않는 사항을 나타냄 (성능, 용이성, 신뢰성, 보안성 등)
인터페이스 요구사항
-
다른조직간 정보를 주고받는 활동을 총칭
-
내부 인터페이스: 모듈, 내부프로그램간의 인터페이스
-
외부 인터페이스: 타 모듈과의 정보 송수신 인터페이스
-
사용자 인터페이스: 레이아웃, 윈도우 등
-
하드웨어 인터페이스: 포트 수, 네트워크 프로토콜, 메모리 용량 등
-
소프트웨어 인터페이스: DBMS, EJB 등
요구사항 분석
요구사항 개발 단계
요구사항 수집 대상
-
시스템 요구사항, 시스템 아키텍처, 시스템 요구사항 및 아키텍처 변경 사항
-
제안서, 계약서, 고객업무 프로파일, 서비스수준 합의서, 작업기술서, 업무규정집
요구사항 수집 방법
- Document-based, Interview, Workshop(Cost-effective, Time-effcient), 설문조사, Role-Playing
요구사항 분석 방법
- 문장분석 (Text), 데이터 흐름 다이어그램 분석(DFD), 스윔 레인 분석(Swim Lane), Use Case 분석, 의사결정 일람표와 의사결정 트리 분석, 이벤트 반응표 분석
(필요한경우 다양하게 조합해서 사용)
소프트웨어 설계
소프트웨어 설계
요구사항과의 연계
- 기능 요구사항 중심으로 시스템 모듈 구성
- 비기능 요구사항에 대한 시스템 내부 구성
- 필요시 "패턴" 적용
소프트웨어 테스트 개요
소프트웨어 테스트
소프트웨어 정적 검증
소프트웨어 동적 검증
소프트웨어 동적 테스트
소프트웨어 품질 기준 사례
소프트웨어 임베디드 테스트 방법 및 사례
