티스토리 뷰
* 소프트웨어의 특성
- 상품성: 판매할 수 있는 상품임
- 복잡성: 개발과정이 복잡하고 관리가 어려움
- 변경 가능성: 프로그램을 수정하여 업그레이드와 오류수정 등이 가능
- 복제성: 쉽게 복사하여 유통이 가능
* (컴퓨터) 시스템
- 특정한 목적을 위해 다양한 컴퓨터로 처리 가능한 요소가 유기적으로 결합된 정보 체계
- 입력, 처리, 출력, 제어, 피드백으로 구성
* 소프트웨어 위기 (Crisis)
하드웨어는 빠르게 발전하는데 소프트웨어 개발속도는 그것을 따라가지 못하고 고객의 요구사항을 감당하지 못하게 됨
- 개발 기간 지연, 개발 비용 증가, 인력 부족, SW 퀄리티 저하, 유지보수의 어려움...
* 소프트웨어 공학
가장 경제적으로 / 퀄리티 높은 소프트웨어를 만들기 위한 / 방법, 도구, 절차 등의 체계
- SE의 목표
주어진 비용 (돈과 시간) 내에서 사용자의 요구사항을 만족하는 퀄리티 높은 소프트웨어를 만들어내는 것.
- SE의 계층 구조
> 도구
> 방법론
> 프로세스
* 소프트웨어 Lifecycle
- 일반적인 SW 생명 주기
> 타당성 검토 -> 개발 계획 -> (요구사항 분석 -> 설계 -> 구현 -> 테스팅) -> 운영 및 유지보수
- 폭포수 모델 (Waterfall Model)
소프트웨어 개발과정의 각 단계가 순차적으로 진행되는 가장 기본적인 모델 (위의 과정과 같다)
> 장점: 쌓인 성공사례가 많음, 단계별 정의가 명확해 이해가 쉬움, 단계별 산출물이 명확
> 단점: 새로운 요구사항의 반영이 어려움, 이전 단계로 돌아가서 오류 수정하기가 어려움
- 프로토타입 모델 (Prototype Model)
프로토타입을 미리 만들어 최종 결과물을 예측. 다 만들어져야 문제점을 확인할 수 있는 폭포수 모델의 단점 보완
요구 수집 -> (빠르게) 설계 -> 프로토타입 구축 -> 고객 평가 -> 프로토타입 재조정 -> 구현
> 장점: 고객과 개발자 모두에게 참조 모델을 제공, 고객이 결과를 미리 볼 수 있어 더 많은 요구사항 반영 가능
> 단점: 프로토타입과 실제 구현된 SW의 차이 때문에 혼란 발생, 프로토타입 개발에 소요되는 비용
- 나선형 모델 (Spiral Model)
반복적인 작업을 점진적으로 수행함. Risk Analysis에 특화되어 있다.
계획 수립 -> 위험 분석 -> 개발 -> 고객 평가
> 장점: Risk Analysis 단계로 인해 위험요소를 제거, 대규모 프로젝트에 적합
> 단점: 미처 발견 못한 위험요소가 있을 수도 있다. 성공사례가 많이 쌓여있지 않음.
+ WINWIN Spiral Model이라는 것도 있음. 고객과의 협상과정을 통해 Win-Win 컨디션을 찾아내는데 더 비중을 둔다.
* SW 프로젝트 관리
- 3P: People, Problem, Process
- 프로젝트 관리의 대상
1) 일정 관리: 제시된 기간 내에 프로젝트를 완료할 수 있도록
> 활동의 정의, 활동 순서, 활동 기간 예측, 일정 계획 수립, 일정 통제
2) 비용 관리: 제한된 예산으로 프로젝트를 완료할 수 있도록
> 자원 계획, 비용 예측, 비용 예산, 비용 통제
3) 품질 관리: 요구사항을 정확히 적용가능한지 보증하기 위한 절차 기술
> 품질 계획, 품질 보증, 품질 통제
4) 위험 관리: 프로젝트에 내재된 위험요소를 예측, 분석, 대비
> 위험 인식, 위험 계량화, 위험 대응 계획, 위험 대응 통제
--
* 품질 관리
소프트웨어 개발 결과가 요구사항에 적합한지? - 설계 품질, 적합 품질
- IEEE 품질 표준
> 정확성 (Correctness): 요구사항을 얼마나 충족하는가?
> 신뢰성 (Reliability): 정확하고 일관된 결과를 얻을 수 있는가?
> 효율성 (Efficiency): 기능 수행에 얼마나 자원을 소모하는가?
> 무결성 (Integrity): 허가되지 않은 자료 변경을 잘 통제하는가?
> 사용 용이성 (Usability): 적절한 UI와 문서를 제공하는가?
> 유지보수성 (Maintainability): 요구사항이 변경되거나 오류가 발생했을 때 고치기 쉬운가?
> 이식성 (Portability): 다양한 HW 환경으로 쉽게 이식될 수 있는가?
> 재사용성 (Reusability): SW의 전체 또는 일부가 다른 목적으로 재사용될 수 있는가?
> 상호운용성 (Interoperability): 다른 SW와 정보를 교환하며 같이 동작할 수 있는가?
- 정형 기술 검토 (Formal Technical Review)
소프트웨어 품질 보증 활동의 하나.
- SW 신뢰도 (가용성) 메트릭
> MTTF (Mean Time To Failure): 총 가동시간 / n (n: 연속으로 가동중이었던 블록의 수)
> MTTR (Mean Time to Repair): 고장나있던 시간 / n (n: 고장났던 블록의 수)
> MTBF (Mean Time Between Failure): MTTF + MTTR
가용도 = MTTF / MTBF
- 위험 관리 (Risk Analysis)
프로젝트 추진과정에서 예상되는 위험상황을 미리 예상하고 적절한 대책을 수립하는 활동
> 위험의 종류: 인력 부족, 예산 관리, 일정 관리, 사용자 요구사항의 변경
> 위험 관리 절차
1) 위험 식별
2) 위험 분석 및 평가
3) 위험표 (Risk Table): 위험 내용과 종류, 발생확률, 영향력
4) 위험 관리 계획
5) 위험 감시 및 조치
- 형상 관리 (Configuration Management)
개발 과정에서 변경되는 사항을 관리하는 활동. 적절히 변경이 되었는지 확인하고 담당자에게 통보한다.
형상 관리의 대상들:
> 정의 단계의 문서
> 개발 단계의 문서 및 프로그램
> 설계 명세서
> 실행 프로그램
> 유지보수 단계의 변경 사항
* 요구사항 분석
프로젝트의 실질적인 첫 단계로 소프트웨어가 가져야할 기능을 기술
- 요구사항 분석 단계
> 문제 인식 / 수집: 인터뷰나 설문조사 등을 이용해 요구사항을 파악 및 수집
> 전개: 수집한 요구사항들에 대해 자세히 조사
> 평가와 종합: 요구사항을 다이어그램이나 CASE 도구 등을 통해 종합
> 검토: 위의 내용을 검토 및 재정리
> 문서화: 요구사항 분석 내용을 문서화
- 요구사항 분석의 어려움
* 구조적 분석
프로세스 사이의 데이터 흐름에 맞춰서 시스템 모형을 만드는 것.
- 자료 흐름도 (DFD)
> Process: 동그라미
> Data Flow: 화살표 (위에 자료 이름)
> Data Store: 위아래 선 두개
> Terminator: 직사각형 (자료의 출처나 도착지를 나타냄)
- 자료 사전 (Data Dictionary)
DFD에 나타나는 자료를 좀 더 상세하게 정의, 기록한 것
> 정의: =
> 연결: +
> 생략: ( )
> 선택: [ | ]
> 반복: { }
> 설명: * *
ex) 고객명세는 고객성명, 고객번호, 고객주소로 이루어져있고 고객성명과 고객번호는 둘 중 하나만 선택가능함
고객명세 = [고객성명|고객번호] + 고객주소
- 개체 관계도 (E-R Diagram)
> 개체: 데이터를 의미
> 속성: 개체에 포함되어 있는 특성값을 의미
> 관계: 개체, 속성간의 관계
- 상태 전이도 (State Diagram)
시스템 이벤트 발생시 시스템의 상태 변화를 모델링하는 것. 상태는 직사각형으로 표현.
- 소단위 명세서 (Mini-Specification)
DFD의 처리 공정 절차를 기술한 것. 구조적 언어, 의사결정표, 의사결정도, N-S Chart 등을 이용한다.
* 설계 (Design)
- 설계 방법과 계층
1) 자료 설계: 요구사항 명세서의 정보를 SW로 구현하기 위해 필요한 자료구조로 변환
2) 구조 설계: 프로그램의 큰 틀, 모듈간의 관계 등을 정의
3) 인터페이스 설계: SW와 사용자 또는 다른 시스템간의 통신 방법을 기술
4) 절차 설계: 모듈이 수행할 기능을 절차적 기술로 변환
- N-S Chart
위의 4) 절차 설계에서 쓰이는 것 중 하나로 박스 다이어그램이라고도 한다.
절차적 프로그래밍 언어처럼 '순차', '선택', '반복' 3가지 제어구조를 도형으로 표현
- 추상화 (Abstraction)
실세계의 객체를 프로그램으로 갖고오는 것
소프트웨어 개발에 대한 전체적 개념을 설계하고 구체화하는 것
> 기능 추상화, 제어 추상화, 자료 추상화
* 프로그램 구조
모듈들간의 계층적 구성을 나타내는 것
- 주요 용어
> Fan-in: 이 모듈을 제어하는 상위 모듈 수
> Fan-out: 이 모듈이 제어하는 하위 모듈 수
> Depth: 최상위 모듈부터 이 모듈까지의 길이
> Width: 같은 레벨의 모듈 수
> Super-ordinate: 다른 모듈을 제어하는 모듈
> Sub-ordinate: 다른 모듈에 의해 제어되는 모듈
- HIPO (Hierachy + Input Process Output) 기법
> Top-down 개발을 위한 문서화 도구
> 구조도 (가시적 도표), 총체적 다이어그램, 세부적 다이어그램으로 구성
* 모듈
하나의 프로그램을 작은 부분으로 분할한 것
모듈의 이름으로 호출하여 다수가 이용할 수 있으며, 시스템 개발 비용을 절감하고 신뢰성을 향상시키는데 도움이 된다.
효과적인 모듈설계 -> High Cohesion, Low Coupling을 지향
- 응집도 (Cohesion): 모듈 안의 요소들이 서로 관련되어 있는 정도
1) 시간적 응집도 (Temporal): 특정 시간에 처리되는 여러 기능을 모아 모듈로 구성
2) 절차적 응집도 (Procedural): 모듈 내부의 기능 요소들이 여러 관련 기능을 순차적으로 수행
3) 교환적 응집도 (Communicational): 동일한 입력, 출력을 사용하는 기능끼리 모아 모듈로 구성
4) 순차적 응집도 (Sequential): 한 모듈 내의 한 기능에 의한 출력이 다음 기능의 입력으로 사용됨
5) 기능적 응집도 (Functional): 모듈 내의 모든 요소들이 하나의 기능을 수행하기 위해 사용됨
- 결합도 (Coupling): 두 모듈간의 상호 의존도.
1) 내용 결합도 (Content): 한 모듈이 다른 모듈의 일부를 마음대로 참조, 수정. 한 모듈에서 다른 모듈로 제어 이동
2) 공통 결합도 (Common): 여러 모듈이 공통 자료 영역을 사용 (전역 변수 등)
3) 외부 결합도 (External): 어떤 모듈에서 선언한 변수를 다른 모듈에서 참조
4) 제어 결합도 (Control): 한 모듈이 다른 모듈에게 제어 요소를 전달 (Flag 등)
5) 스탬프 결합도 (Stamp): 모듈간의 인터페이스로 배열이나 구조체 등의 복합 자료구조가 전달
6) 자료 결합도 (Data): 모듈간의 인터페이스가 자료 요소만으로 구성
* 구현 (Implementation)
프로그래밍 언어를 사용해서 소스코드를 작성하고 문서화하는 작업
설계 단계에서 산출된 설계 명세서를 바탕으로 모듈 단위로 코딩을 한다.
테스트가 용이하도록 코드를 작성할 것.
- 프로그래밍 언어: 업무의 성격, SW의 실행 환경, 개발자의 경험 및 지식 등에 따라 결정
- 구조적 프로그래밍: 순차, 선택, 반복의 3가지 제어구조. goto는 가급적 쓰지 마라
* 테스팅
요구사항 분석 - 설계 - 구현의 결과를 점검하는 단계. 에러를 찾기 위함.
예상 결과 (Expected) 와 실제 결과 (Actual) 가 같은지 검사하고 평가.
- 단위 테스트 (Unit Test)
SW의 최소구성단위인 모듈별로 테스트하는 것. = 모듈 테스트.
여기까지는 전문 테스터가 아니라 구현한 개발자가 수행하는 것이 보통.
- 블랙박스 테스트
코드를 보지 않고 기능이 제대로 수행되는지 검사하는 기법.
성능 오류, 부정확한 기능, 인터페이스 오류를 잡아낼 수 있음
> 동치분할 검사 (Equivalence Partitioning): 입력 조건을 적절한 범위로 자르고 각 범위마다 나와야 하는 값과 실제 나오는 값을 비교
이걸 하기 위해: 경계값 분석 (Boundary Value Analysis), 원인-효과 그래프 (Cause-Effect Graph), 비교 검사
- 화이트박스 테스트
소스코드를 직접 실행해보면서 모듈 내부의 동작을 자세히 관찰하는 것
> Basic Path Test, Data Flow Test, Loop Test
> Statement Coverage, Branch Coverage, Condition Coverage, Branch/Condition Coverage, Multiple Condition Coverage
* 유지보수 (Maintenance)
SW가 인수, 설치된 후에 발생하는 모든 작업으로 SW의 수명을 연장시키며 모든 프로세스 중 가장 비용이 많이 발생함.
유지보수 과정에서 부작용이 발생할 수 있는데 (ex: 스파게티 코드) 문서화를 철저히 하고 가이드라인을 잘 지켜야 이를 방지할 수 있다.
1) Corrective: 오류를 수정하는 것
2) Adaptive: 환경 변화를 기존 SW에 적용하는 것 (이식 등)
3) Perfective: 성능 개선, 새로운 기능 추가. 가장 큰 비중을 차지
4) Preventive: 오류 방지를 위해 정기적으로 수행 (??)
* 객체지향
60년대 후반부터 대두된 개발 패러다임으로 실세계의 현상을 컴퓨터 시스템에서 '객체' 로 표현
- 객체지향의 구성요소
> 객체: Attribute와 Method로 이루어진 하나의 소프트웨어 모듈
> 속성 (Attribute): 객체의 상태, 데이터
> 메소드: 객체가 실행해야할 구체적인 연산, 동작.
> 클래스: 객체들의 공통된 특성을 표현한 데이터 추상화. 객체들이 갖는 속성과 연산을 정의하고 있는 틀.
> 메시지: 객체들간의 상호작용을 위한 수단.
> 오퍼레이션: 클래스 내 객체에 의한 함수나 그 변형. 오퍼레이션의 구현이 메소드라 할 수 있는데 일반적으로 객체지향에서는 동일하게 본다.
- 객체지향의 기본 원칙
> 캡슐화 (Encapsulation)
데이터와 데이터를 조작하는 연산을 하나로 묶고, 이를 외부로 드러내지 않고 필요한 인터페이스만을 드러내는 것
-> High Cohesion / Low Coupling을 실현, 재사용성 증가
> 정보 은닉 (Information Hiding)
객체가 다른 객체로부터 자신의 자료를 숨기고 자신의 연산을 통해서만 접근을 허용하는 것
> 추상화 (Abstraction)
주어진 문제나 시스템 중에 중요한 부분만을 분리해서 간결하고 이해하기 쉽게 만드는 것
> 상속 (Inheritance)
다른 클래스의 속성, 메소드를 물려받아 재사용하는 것
> 다형성 (Polymorphism)
서로 다른 클래스들이 동일한 메소드명을 이용하고, 한 메시지가 객체에 따라 다르게 응답할 수 있는 특성
* 객체지향 분석
- 객체지향 분석 기법의 종류
1) 코드 & 요든 분석 기법: ER Diagram을 이용해서 개체들을 파악하고 모델링하는데 주안점을 둔 기법
2) 럼바우의 분석 기법: 객체 모델, 동적 모델, 기능 모델의 3개 모형을 이용해 모든 SW 구성요소를 Graphical하게 표현
> 객체 모델링: 객체, 속성, 연산 등의 식별 및 객체간의 관계 정의. 객체 다이어그램 작성
> 동적 모델링: 객체들의 제어흐름, 상호반응, 연산순서를 나타냄. 상태 다이어그램 작성
> 기능 모델링: 입출력 결정 -> DFD 작성 -> 기능의 내용 상세 기술 -> 제약사항 결정 및 최소화
* 재공학 & 역공학
- SW 재사용: SW의 전체 또는 일부분을 다시 사용해서 새롭게 개발하는 기법
> 개발 시간 및 비용 감소, 품질 / 생산성 / 신뢰성 향상, 프로젝트 실패 위험 감소, 지식의 공유
- SW 재공학 (Re-engineering)
> 분석 - 구성 - 역공학 - 이식
> 개발이 아니라 유지보수의 생산성으로 소프트웨어 위기를 해결
> 기존 시스템을 이용해 더 나은 시스템을 구축, 새로운 기능을 추가
> 사용자 요구사항 변경 없이 기술적 설계를 변경하여 프로그램을 개선
> 재구조화: 요구사항이나 기술적 설계 변경 없이 프로그램을 개선
- SW 역공학 (Reverse Engineering)
> 소프트웨어를 분석하여 개발 과정과 데이터 처리 과정을 알아내고 다시 만들어내는 작업
> 재문서화, 설계도 추출
* CASE (Computer-Aided Software Engineering)
SW 개발 과정을 컴퓨터 SW를 이용해 자동화하는 것.
문서화, 명세화, 다이어그램 작성 등을 쉽게 할 수 있도록 Graphical Interface를 제공해주는 프로그램들.
- CASE 사용의 이점
> 개발 기간 단축 및 비용 절약 (CASE 도구 도입을 위한 초기 구축비용이 있지만 그 이상으로 개발비 감축)
> 유지보수를 간편화
> 생산성 향상
> 모듈 재사용성, 효율 증가
> 일관된 방식을 적용하여 SW 개발 가능
> 표준화를 지원
- CASE의 분류
> 상위 (Upper) CASE: 요구분석, 설계 단계 지원
> 하위 (Lower) CASE: 코드작성, 테스팅, 문서화 지원
> 통합 (Integrate) CASE: 개발 주기 전체 지원