1. 요구사항 확인

 개발 방법론 (중요도: ★★★)

◆ 소프트웨어 생명주기 (SDLC): 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

◆ 소프트웨어 생명주기 모델 종류

• 폭포수 모델: 가장 오래된 모델로, 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감
• 프로토타이핑 모델: 주요기능을 프로토타입으로 구현해, 고객의 피드백을 반영하여 S/W 만듦
• 나선형 모델: 위험을 최소화하기 위해 점진적으로 시스템 개발
• 반복적 모델: 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발

◆ 소프트웨어 개발 방법론: 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론

◆ 소프트웨어 개발 방법론 종류

• 구조적 방법론: 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 방법론
  • 나씨-슈나이더만 차트: 논리의 기술에 중점을 둔 도형식 표현방법
• 정보공학 방법론: 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
• 객체 지향 방법론: ‘객체’라는 기본 단위로 시스템을 분석 및 설계하는 방법론
• 컴포넌트 기반 방법론 (CBD): 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
• 애자일 방법론: 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적인 시스템 개발할 수 있는 신속 적응적 개량 개발 방법론
• 제품 계열 방법론: 특정 제품에 적용하고 싶은 공통괸 기능을 정의해 개발하는 방법론, 임베디드 S/W작성에 유용

◆ 애자일(Agile) 방법론 유형

• XP(eXtreme Programming): 의사소통 개선과 즉각적 피드백으로 스프트웨어 품질을 높이기 위한 방법론
  • XP 5가지 가치: 용기, 단순성, 의사소통, 피드백, 존중
• 스크럼(Scrum): 매일 정해진 시간, 장소에서 짤은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
• 린(Lean): 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
  • Lean 7가지 가치: 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

◆ 객체 지향 분석(OOA): 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의

◆ 객체 지향 분석 방법론 종류

• OOSE(Object Oriented Software Engineering): 유스케이스를 모든 모델의 근간으로 활용되는 방법론, 야콥슨 만듦
• OMT(Object Modeling Technology): 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링, 럼바우 만듦
  • 분석 절차: 객체 모델링 → 동적 모델링 → 기능 모델링
  • 객체 모델링: 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링, 객체 다이어그램 활용
  • 동적 모델링: 시간의 흐름에 따라 객체들의 동적인 행위를 표현하는 모델링, 상태 다이어그램 활용
  • 기능 모델링: 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링, 자료 흐름도(DFD) 활용

◆ 비용산정 모형 분류

• 하향식 산정방법: 경험이 많은 전문가에게 비용산정 의뢰 또는 전문가와 조정자를 통해 비용산정
  • 전문가 판단
  • 델파이 기법: 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법
• 상향식 산정방법: 세부적인 요구사항과 기능에 따라 필요한 비용 산정
  • 코드 라인 수(LoC: Lines of Code): 원시 코드 라인수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구해 비용산정
  • Man Month: 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 비용산정
  • COCOMO 모형: 보헴이 제안한 모형으로 프로그램의 규모에 따라 비용산정
    • 조직형(Organic Mode): 5만(50KDSI)라인 이하
    • 반 분리형(Semi-Detached Mode): 30만(300KDSI)라인 이하
    • 임베디드형(Embedded Mode): 30만(300KDSI)라인 이상
  • 푸트남(Putnam) 모형: 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
  • 기능점수(FP) 모형: 소프트웨어 기능을 증대시키는 요인별로 가중치를 부여하여 비용산정

◆ 비용 산정 자동화 추정 도구

• SLIM: Rayleigh-Norden곡선과 Putnam예측 모델을 기초로 하여 개발된 자동화 추정 도구
• ESTIMACS: 다양한 프로젝트와 개인별 요소를 수용하도록 FP모형을 기초로 하여 개발된 자동화 추정 도구

◆ 일정관리 모델: 프로젝트가 일정 기한 내에 완료될 수 있도록 관리하는 모델

• 주 공정법(CPM): 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
  • 주 공정(Critical Path: 임계 경로): 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로
• PERT: 일의 순서를 계획적으로 정리하기 위한 수렴 기법. 비관치, 중간치, 낙관치 이용
• 중요 연쇄 프로젝트 관리(CCPM): 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법

 

Chapter02 현행 시스템 분석 (중요도: ★★★)

◆ 현행 시스템 파악: 현행시스템의 어떤 기술 요소 사용을 하는지 파악하는 활동

◆ 현행 시스템 파악 절차

• 구성/기능/인터페이스 파악 → 아키텍처 및 소프트웨어 구성 파악 → 하드웨어 및 네트워크 구성 파악

◆ 소프트웨어 아키텍처: 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체

◆ 소프트웨어 아키텍처 4+1 뷰: 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

• 유스케이스 뷰: 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰
• 논리 뷰: 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
• 프로세스 뷰: 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
• 구현 뷰: 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰, 컴포넌트 구조와 의존성을 보여주고 부가적인 정보 정의
• 배포 뷰: 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

◆ 소프트웨어 아키텍처 패턴 유형

• 계층화 패턴(Layered Pattern): 시스템을 계층으로 구분하여 구성하는 패턴
• 클라이언트-서버 패턴(Client-Server Pattern): 하나의 서버와 다수의 클라이언트로 구성된 패턴
• 파이프-필터 패턴(Pipe-Filter Pattern): 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴, 재사용성이 좋고 추가가 쉬워 확장에 용이
• 브로커 패턴(Broker Pattern): 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌들 원격 서비스 실행을 통해 상호작용이 가능
• 모델-뷰-컨트롤러 패턴(MVC, Model-View-Controller Pattern): 대형 애플리케이션을 3개의 서브 시스템으로 구조화한 패턴, 컴포넌트로 분리되어있어 서로 영향을 받지 않고 개발 작업 수행 가능
  • 모델(Model): 핵심 기능과 데이터 보관
  • 뷰(View): 사용자에게 정보 표시
  • 컨트롤러(Controller): 사용자로부터 요청을 입력받아 처리

◆ 소프트웨어 아키텍처 비용 평가 모델 종류

• 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, Chain of Responsibility

◆ 운영체제 (Operating System): 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램

• 운영체제 종류
  • PC: 윈도즈, 유닉스, 리눅스
  • 모바일: 안드로이드, iOS

◆ OSI 계층: 네트워크 통신에서 충돌 문제를 완화하기 위해 국제 표준화 기구(ISO)에서 제시한 모델

• 응용 계층(Application Layer): 사용자와 네트워크 간 응용서비스 연결, 데이터 생성
• 표현 계층(Presentation Layer): 데이터 형식 설정과 부호교환, 암/복호화
• 세션 계층(Session Layer): 연결 접속 및 동기 제어
• 전송 계층(Transport Layer): 신뢰성 있는 통신 보장. 데이터 분할과 재조립, 흐름제어, 혼잡제어 등 담당,
• 네트워크 계층(Network Layer): 단말 간 데이터 전송을 위한 최적화된 경로 제공
• 데이터 링크 계층(Data Link Layer): 인접 시스템 간 데이터 전송, 전송오류 제어
• 물리 계층(Physical Layer): 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환

◆ DBMS(Database Management System): 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램

◆ 미들웨어(Middleware): 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어. 대표적인 미들웨어: WAS

• 웹 애플리케이션 서버(WAS: Web Application Server): 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버

 

Chapter03 요구사항 확인 (중요도: ★★★)

◆ 요구공학(Requirements Engineering): 사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 호가인 및 검증하는 구조화된 활동

◆ 요구사항의 분류

• 기능적 요구사항: 시스템이 제공하는 기능, 서비스에 대한 요구사항
  • 특정 입력/상황에 대해 시스템이 어떻게 반응/동작 해야 하는지에 대한 기술
  • 특성: 기능성, 완전성, 일관성
• 비기능적 요구사항: 시스템 구축에 대한 제약사항에 관한 요구사항
  • 품질 속성에 관련하여 시스템이 갖춰야할 사항에 관한 기술, 시스템이 준수해야 할 제한 조건에 관한 기술
  • 특성: 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항

◆ 요구공학 프로세스: 도출 → 분석 → 명세 → 확인 및 검증

◆ 요구사항 도출 단계 주요 기법

• 인터뷰, 브레인스토밍, 델파이기법, 롤 플레잉, 워크숍, 설문조사
  • 델파이기법: 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법

◆ 요구사항 확인 및 검증 단계의 주요 기법

• 요구사항 검토: 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토
• 정형 기술 검토 활용
  • 동료 검토: 2~3명 리뷰 진행, 요구사항 명세서를 설명하고 이해관계자들이 들으면서 결함을 발견하는 형태로 진행
  • 워크 스루: 검토 자료를 회의 전에 배포하여 짧은 시간동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화
  • 인스펙션: 소프트웨어 요구, 설계 원시 코드 등의 저작자 외의 다른 전무가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토방법
• 프로토타이핑 활용: 프로토파입(견본품)을 통해 효과적으로 요구 분석을 수행하면서 명세스를 산출하는 작업
• 모델 검증: 분석단계에서 개발된 모델의 품질 검증 필요
• 테스트 케이스 및 테스트를 통한 확인: 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 수립하고 테스트 케이스 작성
• CASE 도구 활용 검증: 자동화된 일관성 분석을 제공하는 CASE도구 활용
• 베이스라인을 통한 검증: 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검증 수행
• 요구사항 추적표(RTM)를 통한 검증: 요구사항 정의서를 기준으로 개발 단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인이 가능한 문서

 

Chapter04 분석 모델 확인하기 (중요도: ☆)

◆ 분석 모델 검증 방법: 유스케이스 모델 검증, 개념수준의 분석 클래스 검증, 분석 클래스 검증