1. 요구사항 확인

소프트웨어 개발 방법론

소프트웨어 수명주기 SDLC : 시스템 요구사항 분석부터 유지보수까지 전 과정을 체계화하는 절차

소프트웨어 라이프사이클 모델 프로세스(요설구테유)

– 요구사항 분석 : 소프트웨어 대상의 기능 및 제한 사항을 정의합니다.

• 기능적, 기능적이지 않은

– 설계 : 사양화 단계에서 정의된 기능의 논리적 판단 및 설계

• 시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계

– 구현 : 설계 단계에서 지정한 기능을 프로그래밍 언어를 사용하여 개발하는 단계.

• 인터페이스 개발, 데이터 구조 개발, 오류 처리

– 시험 : 규정된 요구사항을 만족하는지 테스트 및 평가하는 단계

• 단위, 통합, 시스템 및 인수 테스트

– 유지

소프트웨어 수명 주기 모델의 유형(Vokfnaban)

– 폭포 모델 : 선형 순차 모델, 클래식 모델, 변경하기 어려운 요구 사항, 각 단계의 명확한 완료 후 다음 단계

– 프로토타입 모델 : 핵심요구사항을 프로토타입으로 구현하여 피드백 반영

– 나선형 모델 : 개발 중 리스크 최소화를 위한 점진적 개발

• 계획 및 정의 – 위험 분석 – 개발 – 고객 평가

– 반복 모델 : 병렬 개발 후 통합, 반복 개발

소프트웨어 개발 방법론: 전체 소프트웨어 개발 프로세스를 구현하는 방법론

– 구조적 방법론 (Nassi-Schneiderman 다이어그램): 기능에 기반한 개발, 통합 및 분할 정복 접근법의 방법론

– 정보 기술 방법론 : 대규모 프로젝트를 수행하기 위한 체계적인 방법론

– 객체 지향 방법론 : 객체를 기반으로 시스템을 분석하고 설계하는 방법론

– 컴포넌트 기반 방법론(CBD) : SW를 구성하는 구성요소들을 조합하여 새로운 응용 프로그램 생성

– 제품 라인 방법론 : 도메인공학 및 응용공학

– 민첩한 방법론 : 절차가 아닌 사람 중심, 변화에 유연하고 빠르게 적응, 기존 방식의 한계 극복

민첩한 방법 유형(XP, Scrum, Lean)

– XP: 소통과 즉각적인 피드백을 통한 품질 중심의 방법론

– XP 값(용감한 생존)

• 용기, 단순함, 소통, 피드백, 존중

– XP 기본

• 페어 프로그래밍: 페어 와이즈 코딩의 원리
• 공유 코드 소유권: 누구나 언제든지 변경할 수 있습니다.
• 지속적 통합(CI): 하루에 여러 번 소프트웨어 통합
• 은유: 일반적인 명명 체계와 시스템 설명을 통해 의사소통을 용이하게 합니다.
• 리팩토링: 프로그램의 기능을 변경하지 않고 중복 제거, 단순화 등을 통해 시스템을 재구성하는 것.

스크럼: 정해진 시간과 장소에서 매일 빠르게 진화하는 프로젝트 지향 방법론

• 백로그: 요구사항
• 스프린트: 1~4주의 짧은 개발 기간 반복
• 스크럼 회의(Daily Meeting): 매일 15분 내외의 짧은 회의를 통해 기획
• 스크럼 마스터: 문제를 식별하고 해결하는 사람
• 스프린트 회고전: 스프린트 주기를 되돌아보고 규칙 및 개선 사항 준수 확인
• 번다운 차트: 남은 백로그까지의 시간을 그래픽으로 나타내는 차트(요구 사항).

린(Lean): Kanban 보드를 사용하여 낭비를 제거하고 JIT를 적시에 제거하여 품질을 개선합니다.

– 7원칙

• 폐기물 처리
• 품질의 내재화
• 지식 창조
• 늦은 확인
• 빠른 배달
• 사람을 존중하다
• 전체 최적화

비용 모델

하향식 계산 방법 : 전문가에게 비용 견적 의뢰

– 전문가 의견

– Delphi Technique : 경험적 전문지식을 바탕으로 한 문제 해결 및 미래 예측 기법

상향식 계산 방법

– LoC(코드 라인 수): 낙관적, 평균적, 비관적 값을 측정하여 비용 계산

• 계산: 낙관적 가치 + 4 중간 가치 + 비관적 가치 / 6

만월 모델

– Man Month 계산: (LOC / Programmer Monthly Production)

– 프로젝트 기간 계산식 : (LOC / 월간 프로그래머 생산량) / 프로그래머 수

COCOMO 모델: 프로그램 규모에 따른 비용 추정

– 유기적 : 50,000(50KDSI) 라인 이하의 SW 개발형

– Semi Detached : 300,000(300KDSI) 라인 이하의 SW 개발형

– 임베디드형 : 300,000(300KDSI) 라인 이상 SW 개발형

Putnam 모델(Rayleigh North): 수명 주기 예측 모델, 개발 주기의 각 단계에 필요한 노동력의 분포를 가정하는 방법

기능 포인트 FP: 필요한 기능을 증가시키는 각 요소에 가중치를 부여하여 비용을 계산합니다.

계획 모델

– CPM(Critical Process Method): 여러 작업의 실행 순서가 얽혀 있는 일정 계산 방식

• 가장 긴 요주의 경로로 경로 계산

– PERT: 비관적 가치, 중앙값, 낙관적 가치 3점 추정 방법

– CCPM: 리소스 제약을 설명하는 방법

현재 시스템 파악

현재 시스템 식별 프로세스

– 1단계: 구성, 기능, 인터페이스 파악

• 구성식별 : 주요업무를 수행하는 핵심업무와 이를 지원하는 지원업무로 나뉜다.
• 기능 식별: 엔티티의 비즈니스 시스템에서 제공하는 기능 식별
• 인터페이스 식별: 다른 시스템과 교환되는 데이터 유형, 형식 및 프로토콜 연결 유형 식별

– 2단계: 아키텍처 및 소프트웨어 구성 식별

• 아키텍처 파악: 업무를 수행하는 데 사용되는 기술 요소를 파악합니다.
• 소프트웨어 식별: 소프트웨어 제품명, 목적, 라이선스 적용 방법 및 라이선스 수 식별

– 3단계: 하드웨어 및 네트워크 구성 식별

• 하드웨어 식별: 단위 시스템의 서버 위치 및 핵심 서버 문제 식별
• 네트워크 파악: 사용하는 네트워크 장치 파악

소프트웨어 아키텍처의 개념: 구성 요소 간의 관계를 표현하는 시스템의 구조

소프트웨어 아키텍처 프레임워크: 아키텍처가 표현하려는 콘텐츠와 이러한 보기 간의 관계를 제공합니다.

Software Architecture 4+1 View(Unonf Gradient): 4가지 관점에서 고객 요구 사항을 보는 접근 방식

• 사용 사례 보기: 다른 보기의 유효성을 검사하는 데 사용되는 보기입니다.
• 논리적 보기: 시스템의 기능적 요구 사항이 표시되는 방법을 설명하는 보기입니다.
• 프로세스 보기: 시스템의 비기능적 속성을 표현하는 보기입니다.
• 구현 보기: 소프트웨어 모듈의 구성을 보여주는 보기입니다.
• 배포 보기: 구성 요소가 배치되는 방식을 보여주는 보기입니다.

소프트웨어 아키텍처 패턴: 소프트웨어를 설계할 때 참조할 수 있는 솔루션

• 계층형 패턴: 시스템을 계층으로 나누기
• 클라이언트-서버 패턴: 하나의 서버와 여러 클라이언트로 구성된 패턴입니다.
• 파이프 필터 패턴: 하위 시스템은 입력을 받아 처리하고 결과를 다음 하위 시스템으로 전달합니다.
• 브로커 패턴: 브로커에 서비스 요청이 이루어지면 해당 서비스로 리디렉션됩니다.
• MVC 패턴: 모델, 뷰 및 컨트롤러의 세 가지 하위 시스템으로 구성된 패턴입니다.

디자인 패턴: 소프트웨어 디자인에서 일반적으로 발생하는 문제에 대해 일반적으로 사용되는 디자인 방법을 요약한 패턴

디자인 샘플 구성 요소(있는 경우): 샘플 이름, 문제 및 배경, 솔루션, 사례, 결과, 샘플 코드

디자인 패턴 유형

– 목적 : 창작, 구조, 행동

– 범위: 클래스, 객체

디자인 패턴 유형

만들기 – Bill Pro Pack App Sing

Rescue – Be de Papel Proc Come A

OSI 7 계층 애플리케이션, 세션, 표현, 네트워크(세그먼트), 전송 계층(패킷), 데이터 링크 계층(프레임), 물리 계층(비트)

운영 체제: 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당합니다.

운영체제(신성기주구) 분석시 고려사항 – 신뢰성, 성능, 기술지원, 주변기기, 구축비용

DBMS 분석 고려 사항(가명) – 가용성, 성능, 상호 호환성, 기술 지원, 구축 비용

Web Application Server WAS: 서버 계층에서 응용 프로그램이 실행될 수 있는 환경을 제공하고 타 이기종 시스템과의 상호 운용성을 지원합니다.

미들웨어(현금 메커니즘) 분석 시 고려 사항 – 가용성, 성능, 기술 지원, 구축 비용

요구 사항 확인

요구 사항 엔지니어링: 사용자 요구 사항을 도출, 분석, 지정 및 확인하는 구조화된 활동

요구사항 분류: 기능적/비기능적 요구사항

– 기능적 요구사항 : 시스템에서 제공하는 기능 및 서비스에 대한 요구사항

• 기능의
• 완전성
• 일관성

– 비기능적 요구사항: 시스템 설계 제약에 대한 요구사항

• 신뢰할 수 있음
• 사용자 친근성
• 능률
• 유지 보수성
• 휴대성

요구 사항 프로세스

CMM 레벨 3(정의)

요구사항 도출 : 해결해야 할 문제를 인지하고 추상적인 요구사항에 대한 정보를 파악하여 수집방법을 결정하여 수집된 요구사항을 구체적으로 표현

– 주요 기술

• 브레인스토밍: 대화하기 좋은 분위기에서 비판 없이 아이디어를 환영하는 회의.
• 델파이 기법: 경험적 전문 지식을 통해 문제를 해결하고 미래를 예측하는 방법
• 역할극: 역할을 선택하고 연기하는 방법

요구사항 분석 : 요구사항의 충돌, 중복, 누락 등 분석, 요구사항의 기능적/비기능적 분류

– 주요 기술

• 데이터 흐름 다이어그램
• 데이터 사전

요구사항 명세 : 검토, 평가, 승인이 가능한 문서를 체계적으로 작성하는 단계 – 출력: 요구 사항 사양

– 주요 기술

• 비정형 명세기법 : 자연어 기반 기술
• 공식 명세 기법: 수학적 원리와 표기법을 사용한 설명, Z-scheme, Petri net 및 상태 지도 사용

요구사항 확인 : 요구사항 명세의 요구사항이 정확히 기술되었는지 확인하고 기준선을 설정하는 활동

– 주요 기술:정형 외과 기술 검토

• Peer Review: 요구사항 명세 작성자가 다른 이해관계자에게 설명하고 오류를 찾아내는 형식.
• Walk-Through: 사전에 검토 자료를 배포하여 검토 후 회의를 통해 오류를 포착
• 점검: 오류를 찾기 위해 다른 전문가나 팀이 점검하는 방법

CMM 레벨 2(비기간 변경): 프로젝트 과정에서 발생하는 변경을 제어, 추적 및 관리하는 활동

출력: 요구 사항에 대한 변경 요청, 변경 승인, 추적 테이블

– 협상: 구현할 수 있는 기능을 협상합니다.

– 기준선 설정 : 요구사항 명세, 형상관리를 통한 기준선 설정

– 변경관리 : 요구사항 기준에 따른 변경을 공식적으로 통제하고 CCB 형상관리위원회를 운영

– 형상관리위원회 CCB : 형상관리에 대한 중요한 정책을 설정하고 결과를 검토하여 의사결정하는 조직

– 검증 및 검증 : 요구사항 준수 여부 확인