1요구사항 확인

1. 소프트웨어 개발 방법론

소프트웨어 생명주기

• 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

소프트웨어 생명주기 모델의 종류(폭프나반)

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

소프트웨어 개발 방법론

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

소프트웨어 개발 방법론 종류 (구정/객컴/애제)

• 구조적 방법론
  • 전체 시스템을 기능에 따라 나누어 개발하고 이를 통합하는 분할과 정복 접근 방법론
  • 프로세스 중심의 하향식 방법론
  • 나씨-슈나이더만 차트 : 논리의 기술에 중점을 둔 도형식 표현 방법
• 정보공학 방법론
  • 정보시스템 개바레 필요한 관리 절차와 작업 기법을 체계화한 방법론
  • James Martin이 비즈니스 시스템 즉, 정보시스템 개발을 공학적으로 접근하기 위해 체계화시킨 개발 방법론
• 객체지향 방법론
  • '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론
  • 현실 세계의 개체(Entity)를 속성(Attribute)과 메서드(Method)가 결합된 형태의 객체(object)로 표현하는 개념, 객체간의 메시지를 통신을 통해서 시스템을 구현하는 개발 방법
  • 규모가 큰 대형 프로젝트에 적합
  • 재사용률 확장성 유지보수 향상
  • 사용자 타입 중심
  • 대화식 프로그램 개발 용이
• 컴포넌트 기반 방법론(CBO)
  • 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
•  
• 애자일 방법론
  • 절차보다 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적인 시스템 개발할 수 있는 신속 적응적 개량 개발 방법론
• 제품 계열 방법론
  • 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발하는 방법론, 임베디드 SW 작성에 유용

애자일 방법론 유형 :

• XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
  • XP 5가지 가치(용단의피존) : 용기, 단순성, 의사소통, 피드백, 존중
  • XP의 주요 실천 방법
    • Pair Programming(짝 프로그래밍) - Collective Ownership(공동 소유 코드)
    • Test Driven Development(테스트 주도 개발) - Whole Team(전체 팀)
    • Refactoring(리팩토링) - Small Release(소규모 릴리즈)
• 스크럼 : 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
• 린 : 도요타의 린 시스템 품질법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
  • 린의 7가지 가치 : 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른인도, 사람존중, 전체 조직화

객체지향 분석

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

객체지향 분석 방법론 종류

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

비용 산정 모형 분류

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

비용 산정 자동화 추정 도구

• SLIM : Rayleigh-Norden 곡선과 putnam 예측모델을 기초
• ESTMACS : 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발

일정관리 모델

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

 

2. 현행 시스템 분석

현행 시스템 파악

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

현행 시스템 파악 절차

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

소프트웨어 아키텍처

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

소프트웨어 아키텍처 4+1 뷰 (유논프구배)

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

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

• 계층화 패턴 : 시스템을 계층으로 구분하여 구성하는 패턴
• 클라이언트-서버 패턴 : 시스템을 계층으로 구분하여 구성하는 패턴
• 파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴, 재사용성이 좋고 추가가 쉬워 확장에 용의 (대표 : UNIX의 쉘)
• 브로커 패턴 : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌트들 원격 서비스 실행을 통해 상호작용이 가능
• 모델-뷰-컨트롤러 패턴 : 대형 애플리케이션을 3개의 서브 시스템으로 구조화한 패턴, 컴포넌트로 분리되어있어 서로 영향을 받지 않고 개발 작업 가능

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

• SAAM : 변경에 용이성과 기능성에 집중 경험이 없는 조직에서도 활용 가능 비용 평가 모델
• ATAM : 아키텍처 품질 속성을 만족시키는지 판단 및 품질들의 이행 상충관계까지 평가
• CBAM : ATAM 바탕의 시스템으로 경제적 의사결정에 대한 요구를 충족하여 평가
• ADR : 소프트웨어 아키텍처 구성요소간 응집도 평가
• ARID : 전체 x, 특정 부분에 대한 품질요소에 집중하여 비용 평가

디자인 패턴

• 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주쓰이는 설계 방법을 정리한 패턴

디자인 패턴 유형

• 목적(생구행)
  • 생성(생빌프로 팩앱싱) : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화
  • 구조(구 브데 퍼플 프록 컴 어) : 클래스나 객체의 조합을 다루는 패턴
  • 행위(행 미인이 스테비커스트 메체) : 클래스나 객체의 상호 작용하는 방법과 역할 분담을 다룸
• 범위(클객)
  • 클래스 : 상속 관계를 다루는 패턴, 컴파일 타임에 정적으로 졀정
  • 객체 : 객체 간 관련 성을 다루는 패턴, 런타임에 동적으로 결정

운영체제

• 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램

OSI 계층

• 네트워크 통신에서 충돌 문제를 완화하기 위해 국제표준화기구에서 제시한 모델
  • 응용 계층 : 사용자와 네트워크 간 응용 서비스 연결, 데이터 생성
  • 표현 계층 : 데이터 형식 설정과 부호 교환, 암/복호화
  • 세션 계층 : 연결 접속 및 동기 제어
  • 전송 계층 : 신뢰성 있는 통신 보장, 데이터 분할, 재조립, 흐름제어, 혼잡 제어
  • 네트워크 계층 : 단말기간 데이터 전송을 위한 최적화된 경로 제공
  • 데이터링크 계층 : 인정 시스템 간 데이터 전송, 전송 오류 제어
  • 물리 계층 : 0과 1비트 정보를 회선에 보내기 위한 전기적 신호 변화

DBMS

• 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능 제공

미들웨어

• 분산 컴퓨팅 환경에서 응용프로그램과 프로그램이 운영되는 환경 간에 원밀한 통신이 이루어질 수 있도록 제어
  • 웹 애플리케이션 서버(WAS) : 서버계츠에서 애플리케이션이 동작할 수 있는 환경제공, 안정적인 트랜젝션 처리와 관리, 다른 이기종 시스템과의 연동 지원

 

3. 요구사항 확인

요구공학

• 사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

요구사항의 분류

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

요구공학 프로세스(도분명확)

• 도출 → 분석 → 명세 → 확인 및 검증

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

• 인터뷰 : 이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집 방식
• 롤플레잉 : 현실에 일어나는 장면을 설정하고, 여러사람이 각자 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법
• 설문조사 : 설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집하는 방법
• 워크숍 : 단기간 집중적인 노력으로 다양하고 전문적인 정보 획득 공유 방법
• 브레인스토밍 : 말꺼내기 쉬운 분위기를 만들어 회의 참석자들이 아이디어들을 비판없이 수용할 수 있도록하는 회의
• 델파이기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법

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

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

 

4. 분석 모델 확인하기

분석모델 검증 방법

• 유스케이스 모델 검증, 개념수준의 분석 클래스 검증, 분석 클래스 검증