01 소프트웨어 개발방법론
1. 소프트웨어 개발방법론 ⭐️⭐️⭐️
소프트웨어 생명주기(SDLC): 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
소프트웨어 생명주기 프로세스
- 요구사항 분석 (기능/비기능 요구사항)
- 설계 (시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계)
- 구현 (인터페이스 개발, 자료 구조 개발, 오류 처리)
- 테스트 (단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트)
- 유지보수 (예방, 완전, 교정, 적응 유지보수)
소프트웨어 생명주기 모델 종류
- 폭포수 모델
- 프로토타이핑 모델
- 나선형 모델: 계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가
- 반복적 모델: 병행 개발
소프트웨어 개발방법론: 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법
소프트웨어 개발방법론 종류
- 구조적 방법론: 분할과 정복, 나씨-슈나이더만(Nassi-Shneiderman) 차트 사용
- 정보공학 방법론
- 객체지향 방법론
- 컴포넌트 기반 방법론
- 애자일 방법론: 사람 중심
- 제품 계열 방법론: 영역/응용 공학
애자일 방법론: 절차보다는 사람 중심, 신속 적응적 경량 개발방법론
애자일 방법론 유형
XP: 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
- 5가지 가치: 용기, 단순성, 의사소통, 피드백, 존중
- 12가지 기본원리
- 짝 프로그래밍
- 공동 코드 소유
- 지속적인 통합
- 계획 세우기
- 작은 릴리즈
- 메타포어
- 간단한 디자인
- 테스트 기반 개발
- 리팩토링
- 40시간 작업
- 고객 상주
- 코드 표준
스크럼: 팀을 위한 프로젝트 관리 중심 방법론
- 백로그: 제품과 프로젝트에 대한 요구사항
- 스프린트: 2~4주의 짧은 개발 기간
- 스크럼 미팅: 매일 15분 정도 미팅 (데일리 미팅)
- 스크럼 마스터: 프로젝트 리더
- 스프린트 회고: 스프린트 주기를 되돌아봄
- 번 다운 차트: 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
린: 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용
- 7가지 원칙: 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화
2. 비용산정, 일정관리 모형 ⭐️⭐️⭐️
비용산정 모형: 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식
비용산정 모형 분류
- 하향식 산정방법: 전문가 판단, 델파이 기법
- 상향식 산정방법: 코드 라인 수(Loc), Man Month, COCOMO 모형, 푸트남 모형, 기능점수(FP) 모형
비용산정 모형 종류
Loc: 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 비용을 산정하는 방식
Man Month: 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식
- Man Month = Loc(라인) / 프로그래머의 월간 생산성(라인)
- 프로젝트 기간 = Man Month / 프로젝트 인력(명)
COCOMO: 보헴이 제안, Man-Month로 산정
- 조직형: 5만 라인 이하
- 반 분리형: 30만 라인 이하
- 임베디드형: 30만 라인 이상
푸트남: 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식, Rayleigh-Norden 곡선의 노력 분포도
기능점수(FP): 요구 기능을 증가시키는 인자별로 가중치 부여
- FP = 총 기능점수 [0.65 + (0.1 총 영향도)]
일정관리 모델: 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델
일정관리 모델 종류
- 주 공정법(CPM): 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
- PERT: 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법
- 중요 연쇄 프로젝트 관리(CCPM): 자원제약사항을 고려하여 일정을 작성하는 기법
02 현행 시스템 분석
1. 현행 시스템 파악 ⭐️⭐️⭐️
현행 시스템 파악: 사용하고 있는 소프트웨어, 하드웨어, 네트워크의 구성 파악
현행 시스템 파악 절차
- 구성/기능/인터페이스 파악
- 아키텍처 및 소프트웨어 구성 파악
- 하드웨어 및 네트워크 구성 파악
소프트웨어 아키텍처: 여러가지 소프트웨어 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체
소프트웨어 아키텍처 4+1 뷰: 4개의 아키텍처 개념을 제시하고, 요구사항 체크 방법으로 유스케이스 사용
- 유스케이스 뷰: 다른 뷰를 검증하는 데 사용되는 뷰 (사용자, 설계자, 개발자, 테스트 관점)
- 논리 뷰: 기능적인 요구사항 (설계자, 개발자 관점)
- 프로세스 뷰: 비기능적인 요구사항 (개발자, 시스템 통합자 관점)
- 구현 뷰: 컴포넌트 구조와 의존성을 보여줌
- 배포 뷰: 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여줌
소프트웨어 아키텍처 패턴: 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식
소프트웨어 아키텍처 패턴 유형
- 계층화 패턴: 시스템을 계층으로 구분하여 구성
- 클라이언트-서버 패턴: 하나의 서버와 다수의 클라이언트로 구성
- 파이프-필터 패턴: 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능
- 브로커 패턴: 분산 시스템에서 사용
- 모델-뷰-컨트롤러 패턴: 대화형 애플리케이션
소프트웨어 아키텍처 비용 평가 모델: 아키텍처의 적합성을 평가하는 모델
소프트웨어 아키텍처 비용 평가 모델 종류
- SAAM: 변경 용이성과 기능성에 집중
- ATAM: 품질 속성들의 이해 상충관계까지 평가
- CBAM: ATAM 바탕, 경제적 의사결정에 대한 요구 충족
- ADR: 응집도 평가
- ARID: 특정 부분에 대한 품질요소에 집중
디자인 패턴: 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
디자인 패턴 유형
- 목적: 생성, 구조, 행위
- 범위: 클래스, 객체
디자인 패턴 종류
생성
- Builder: 복잡한 인스턴스를 조립하여 만드는 구조
- Prototype: 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용
- Factory Method: 상위 클래스에서 객체를 생성하는 인터페이스 정의, 하위 클래스에서 인스턴스 생성
- Abstract Factory: 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공
- Singleton: 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 함
구조 - Bridge: 기능의 클래스 계층과 구현의 클래스 계층을 연결
- Decorator: 기존에 구현되어 있는 클래스에 필요한 기능을 추가
- Facade: 복잡한 시스템에 대하여 단순한 인터페이스 제공
- Flyweight: 모두가 갖는 본질적인 요소를 클래스 화하여 공유 -> ’클래스의 경량화’
- Proxy: ‘실체 객체에 대한 대리 객체’
- Composite: 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현
- Adapter: 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만듦
행위
- Mediator: 중재자에게 모든 것을 요구하여 통신의 빈도수를 줄여 객체지향의 목표를 달성하게 해줌
- Interpreter: 여러 형태의 언어 구문을 해석할 수 있게 만듦
- Iterator: 집합체 안에 들어있는 모든 항목에 접근할 방법 제공
- Template Method: 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꿈
- Observer: 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이 감 -> 자동으로 내용 갱신
- State: 객체 상태를 캡슐화하여 클래스화
- Visitor: 해당 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업 수행
- Command: 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행됨
- Strategy: 알고리즘 군을 정의하고 같은 알고리즘을 하나의 클래스로 캡슐화
- Memento: Undo 기능을 개발할 때 사용
- Chain of Responsibility: 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결함
2. 개발 기술 환경 정의 ⭐️⭐️⭐️
운영체제: 컴퓨터 사용자와 하드웨어 간의 인터페이스를 담당하는 프로그램 (소프트웨어)
운영체제 현행 시스템 분석 시 고려 사항
- 품질 측면: 신뢰도, 성능
- 지원 측면: 기술 지원, 주변 기기, 구축 비용
운영체제 종류 및 특징
- PC: Windows, UNIX, Linux
- 모바일: Android, iOS
네트워크: 컴퓨터 장치들의 노드 간 연결을 사용하여 서로에게 데이터를 교환할 수 있도록 하는 기술
OSI 7계층: 물리, 데이터 링크, 네트워크, 전송, 세션, 표현, 응용
DBMS: 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램
DBMS 현행 시스템 분석 시 고려 사항
- 성능 측면: 가용성, 성능, 상호 호환성
- 지원 측면: 기술 지원, 구축 비용
미들웨어: 운영체제와 소프트웨어 애플리케이션 사이에 위치
미들웨어 현행 시스템 분석 시 고려 사항
- 성능 측면: 가용성, 성능
- 지원 측면: 기술 지원, 구축 비용
03 요구사항 확인
1. 요구사항 ⭐️⭐️⭐️
요구공학: 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동
요구사항의 분류
- 기능적 요구사항: 기능성, 완전성, 일관성
- 비기능적 요구사항: 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항
요구사항 개발 프로세스
- 요구사항 도출(Elicitation): 소프트웨어가 해결해야 할 문제 이해, 수집된 요구사항 구체적으로 표현
- 요구사항 분석(Analysis): 도출된 요구사항에 대해 충돌, 중복, 누락 등 분석
- 요구사항 명세(Specification): 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성
- 요구사항 확인 및 검증(Validation & Verification): 요구사항을 이해했는지 확인, 완전한지 검증
요구사항 도출 단계 기법
- 인터뷰
- 브레인스토밍
- 델파이 기법
- 롤 플레잉
- 워크숍
- 설문 조사
요구사항 분석 단계 기법
- 자료 흐름 지향 분석
- 객체지향 분석
요구사항 명세 단계 기법
- 비정형 명세 기법: 자연어 기반으로 서술
- 정형 명세 기법: 수학적인 원리와 표기법으로 서술
요구사항 확인 및 검증 단계 기법
- 요구사항 검토
- 정형 기술 검토 활용
- 동료 검토: 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태
- 워크 스루: 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태
- 인스펙션: 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
- 프로토타이핑 활용
- 모델 검증
- 테스트 케이스 및 테스트를 통한 확인
- CASE 도구 활용 검증
- 베이스라인을 통한 검증
- 요구사항 추적표(RTM)를 통한 검증
상세 정형 기술 검토 기법
- 관리 리뷰
- 기술 리뷰
- 인스펙션 (동료 검토라고도 함)
- 워크 스루
- 감사
요구사항 관리: 프로젝트 진행 과정에서 발생하는 요구사항의 변경에 대해 일치성과 무결성을 제공하기 위해 일련의 관리를 수행하는 활동
요구사항 관리 단계 절차
- 요구사항 협상
- 요구사항 기준선 설정
- 요구사항 변경관리
- 요구사항 확인 및 검증
2. 요구사항의 시스템화 타당성 분석 ⭐️
04 분석 모델 확인하기
1. 분석 모델 검증 ⭐️
2. 분석 모델의 시스템화 타당성 분석 ⭐️
