1. 요구사항 확인

1. 현행 시스템 분석

1-1. 현행 시스템 파악

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

 

 

1-2. 개발 기술 환경 정의

1. 운영체제
   • Windows
   • UNIX
   • Linux
   • IOS
   • Android
2. DBMS
3. 미들웨어(약어로 연습)
   • 소프트웨어 애플리케이션에게 운영체제가 제공하는 서비스를 추가 및 확장하여 제공하는 컴퓨터소프트웨어
     • RPC(Remote Procedure Call) - 클라이언트가 원격에서 동작하는 프로시저를 호출하는 시스템
     • MOM(Message Oriented Middleware) - 분산 응용 프로그램 간에 메시지를 보내고 받으면서 데이터를 전달하고 교환할 수 있게 해줌
     • ORB(Object Request Broker) - 객체지향 시스템에서 객체 및 서비스를 요청하고 전송할 수 있도록 지원
     • DB 접속 미들웨어 - 애플리케이션과 데이터베이스 서버를 연결해줌
     • TP 모니터(Transaction Processing monitor) - 분산 시스템의 애플리케이션을 지원한다. 
     • 웹 애플리케이션 서버(WAS) - 웹 애플리케이션을 지원한다.
4. 오픈소스

 

 

2. 프로젝트 관리

2-1. 프로젝트의 정의

• 프로젝트는 사업의 목적에 맞게 미리 계획된 일정과 금액 범위에서 정해진 목적을 달성하기 위한 모든 활동
• 시간이 정해져 있고, 업무마다 개발 방법이 다르며, 단계적으로 진행되는 특성

 

 

2-2. 프로젝트의 관리

1. 일정관리
   • CPM 네트워크(모든 경우의 수 작성)
     • 임계경로: 여러 경로중 가장 많은 시간이 걸리는 경로
   • 비용 산정 모델
     • 하향식 방법
       • 전문가의 감정에 의한 방법: 2인 이상의 전문가에 비용 산정 의뢰 하여 산출하는 방법
       • 델파이 방법: 감정의 편차를 줄이기 위해 단계별로 전문가들의 견해를 조정자가 조정하여 최종 견적을 결정
     • 상향식 방법
       • 원시 코드 라인 수(LOC)기법: 비관치, 낙관치, 기대치를 측정 후 예측치로 비용을 산정
       • 개발 단계별 노력기법(M/M): LOC를 보완한 것, 각 단계에 적용하여 단계별로 산정
     • 수학적 방법
       • COCOMO 모형: 보헴(Boehm)이 제안한 방법으로 원시 프로그램의 라인 수에 따라 비용 산정, LOC기법
         • 조직형(Organic, 5만 라인 이하) - 응용시스템
         • 반결합형(Semi-Detached, 30만 라인 이하) - 운영체제, 데이터베이스 관리 시스템
         • 내장형(Embedded, 30만 라인 이상) - 하드웨어가 포함된 실시간 시스템
         • 공식 PM = 2.4 X (KDSI)^1.05 -> 2.4 & 3.0 & 3.6 
       • Putnam 모형: 각 단계 마다 비중을 다르게 하여 비용 산출
         • 단계별로 요구할 인력의 분포를 가정하는 모형
         • 대형 프로젝트의 노력 분포 산정에 이용
         • 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소한다.
       • 펑션 포인트(FP) 모형: 각 기능에 따라 가중치 부여하여 요인별 가중치 합산하여 규모, 복잡도, 난이도 산출
         • FP = 전체 기능 점수 * [0.65 + (0.1 * 총 영향 정도)]
     • Man Month: LOC, 전체 라인 /(라인 X 인수)
2. 예산관리
3. 인력관리
4. 위험관리
5. 품질관리

 

 

 

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

3-1. 프로세스와 방법론

프로세스 모델

• 설명
  • 소프트웨어를 개발하는 작업이나 단계
  • 무엇을 할 것인가에 중점을 둔다
  • 결과보다 과정이 중요하다
• 예
  • 폭포수 프로세스
    • 앞 단계가 완료될 때까지 대기 상태
    • 완성된 모습을 후반부가 되기 전엔 볼 수 없다.
    • 고객이 원하는 모습이 아니라면 수정이 어렵다.
  • 프로토타입 프로세스
    • Prototype(시제품)을 가능한 빨리 개발한 후 고객과 검증하는 것이 목적
  • 나선형 프로세스
    • 나선형 모델(아래 단계들 반복)
      1. 계획 및 정의
      2. 위험 분석
      3. 개발
      4. 고객 평가 
    • 고비용의 시스템 개발이나 큰 시스템 구축 시 효과적
    • 프로젝트 수행 시 발생하는 위험을 최소하려는 목적
    • 개발자가 위험을 정확하게 분석하지 못했다면 심각한 문제
  • 4세대 기법
  • 통합 프로세스

방법론

• 설명
  • 프로세스의 체계적 수행 방법
  • 어떻게 할 것인가에 중점을 둔다
  • 각 단계별 문서화, 징행방법, 평가기준을 구체적으로 제시한다
  • 결과를 중시한다
• 예
  • 구조적 방법론(1970년대)
  • 정보공학 방법론(1980년대)
  • 객체지향 방법론(1990년대)
    • 용어
      • 클래스: 공통 속성과 행위를 가진 객체를 묶어 추상화한 개념(과일)
      • 객체: 업무수행을 위한 대상이 되는 사람, 장소, 사물, 사건 및 개념(사과, 배, 바나나)
      • 캡슐화: 데이터와 메서드를 묶어 외부에 노출되지 않게 만든 상태로 인터페이스를 통해 접근 가능
      • 데이터 은닉: 각각의 객체가 자신의 속성(데이터)과 메서드(행위)응 다른 객체에게 숨기고 있는 것
      • 상속: 클래스가 가진 속성과 행위를 객체가 물려 받는 것
      • 추상화: 객체의 공통적인 속성과 기능을 추출하여 정의하는 것
      • 다형성: 같은 메서드에 다르게 반응하는 것(Overloading, Overriding)
    • SOLID(객체 지향 설계)
      • S(SRP): 단일 책임 원칙(Single responsibility principle) - 한 클래스는 하나의 책임만 가져야 한다
      • O(OCP): 개방-폐쇄 원칙(Open/closed principle) - 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다
      • L(LSP): 리스코프 치환 원칙(Liskov substituation principle) - 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
      • I(ISP): 인터페이스 분리 원칙(Interface segretion principle) - 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 않아야 한다
      • D(DIP): 의존관계 역전 원칙(Dependency inversion) - 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다
    • 객체지향 분석 방법론
      • Rumbaugh(럼바우)의 OMT(=정보모델링, 클래스 다이어그램 or ERD로 표현)
        • 클래스의 외부 명세를 정의함
        • 객체 모델링(객체다이어그램), 동적 모델링(상태다이어그램), 기능모델링(자료흐름도)으로 분류함
      • Booch(부치)의 OOD(Object Oriented Design) 방법론
        • 시스템 형성 구조를 모형화하는 DFD 사용
        • 클래스 다이어그램, 객체 다이어그램, 모듈 다이어그램, 프로세스 다이어그램
      • Coad/Yaurdon 방법론
        • 객체지향 특징을 가장 충족시키는 방법
        • E-R 다이어그램 사용
  • 컴포넌트 기반 방법론(CBD)(2000년대)
  • Agile 방법론(2000년대)
    • 20001년 모임 결성, 원칙 - 가볍지만 충분한
    • -
      • 프로세스와 도구
      • 문서화
      • 고객과의 계약 협상
    • +
      • 개인과의 상호작용
      • 제대로 동작하는 소프트웨어의 개발에 집중
      • 고객과의 협력
    • 유형
      
      • XP(eXtreme Programming)
        • 의사소통 개선과 즉각적 피드백
        • 5가지 가치
          • 용기: 모르는 것을 묻는 용기, 새로운 방법에 도전하는 용기
          • 단순성: 현재 시점에서 필요한 것만 간결하게
          • 의사소통: 개발자, 사용자, 관리자 서로의 소통
          • 피드백: 고객의 빠른 피드백
          • 존중: 구성원 간의 협력
        • 용어
          • 스토리: 요구사항(고객)
          • 스토리 추정: 스토리를 보고 기간과 강도 결정(개발자)
          • 릴리즈: 고객에게 구현괸 제품 배포
          • 반복: 릴리즈 안에서 반복되는 작업
          • 드라이버: 코드 작성자
          • 파트너: 드라이버를 도와 조언 
        • 12가지 실천사항
          1. 계획게임
          2. 짧은 릴리즈 주기
          3. 메타포: 공통적인 이름 체계와 시스템 서술서 공유
          4. 단순 설계
          5. 테스트 주도 개발
          6. 리팩토링
          7. 짝 프로그래밍
          8. 코드 공동 소유
          9. 지속적인 통합, CI
          10. 주당 40시간 작업
          11. 고객의 참여
          12. 코딩 표준
      • 스크럼(SCRUM)
        • 매일 정해진 시간에 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론
        • 5가지 가치 - 확약, 전념, 정직, 존중, 용기
        • 용어
          • 백로그: 제품과 프로젝트에 대한 요구사항, 요구사항 리스트
          • 제품 백로그: 전체 기간 동안 개발할 백로그
          • 스프린트: 팀이 일정량의 작업을 완료해야 하는 시간이 정해진 짧은 기간(1~4주)
          • Scrum Master(SM): 스크럼팀의 문제를 해결하는 역할
          • Product Owner(PO): 제품 책임자, 백로그를 작성하는 주체
      • 린(LEAN)
        • 도요타사의 생산방식
        • 인력, 생산 설비 등을 필요한 만큼만 유지하면서 생산효율을 극대화하는 방식
        • 낭비요소를 제거하여 품질을 향상시킴
  • 제품 계열 방법론(2010년대)

 

 

4. 요구공학

4-1. 요구사항 개발 프로세스

1. 도출
   • 다양한 이해관계자와 효율적인 의사소통이 중요
2. 분석
   • 요구사항들간 상충되는 것 해결 및 범위파악
   • 개념모델링
3. 명세
   • 문서 작성
   • 시스템 정의서
   • 시스템 요구사항 명세서
   • 소프트웨어 요구사항 명세서
4. 확인
   • 문서가 완전한지 검증
   • 분석가가 요구사항을 이해했는지 확인

 

 

4-2. 요구사항 분석 기법

1. 요구사항 분류
   • 기능인지 비기능인지
   • 범위
   • 우선순위
2. 개념 모델링(Conceptual Modeling)
   • 실세계 문제에 대한 모델링이 핵심
   • 대부분 UML을 사용
   • 시나리오로 나타내기 위해 유스케이스 다이어그램이 많이 사용
3. 요구사항 할당
   • 요구사항 만족을 위해 아키텍처 구성 요소 식별
4. 요구사항 협상
   • 두 명의 이해관계자가 합의
5. 정형 분석
   • 형식적으로 정의된 시맨틱을 지닌 언어로 요구사항을 표현한다.
   • 정확하고 명확하게 표현하여 오해를 최소화시킬 수 있다.
   • 요구사항의 마지막 단계에서 이루어진다.

 

4-3. 요구사항 확인

• 요구사항 검토: 정의서 및 명세서를 완성한 시점에서 이루어짐
• 프로토타이핑: 시제품, 견본품
• 모델 검증: 분석단계에서 개발된 모델의 품질 검증 필요
• 인수 테스트: 최종 제품이 요구사항을 만족하는지 확인(확인 계획도 포함)

 

 

 

 

5. UML

5-1. 정의

Unified Modeling Language: 표준화된 범요어 모델링 언어

• 객체지향 설계를 위한 표준언어
• 시스템을 시각적으로 모델링하기 위한 모델링 언어
• 시스템 개발 과정의 광범위한 분야에 활용 가능

 

5-2. 구성요소

• 사물(Things) - 기본요소
  • 시스템의 구조
  • 시스템의 행위
  • 개념의 그룹화
  • 부가적인 개념설명
• 관계(Relationship) - 사물관의 관계
  • 의존관계
  • 연관관계
  • 일반화관계
  • 실체화관계
• 다이어그램(Diagram) - 사물과 관계를 도형으로 표현
  • 구조 다이어그램
    • 클래스 다이어그램 - 클래스 이름, 속성, 메서드
    • 컴포넌트 다이어그램 - 반드시 인터페이스를 거쳐서 컴포넌트끼리 연결, 화살표로 의존관계 표시
    • 배치 다이어그램 - 노드와 커넥션이라는 두 가지 요소를 사용해 시스템을 구성
    • 패키지 다이어그램 - 다이어그램의 요소들을 그룹화
  • 행위다이어그램(유스케이스, 순차, 통신, 상태, 활동)
    • 유스케이스 다이어그램 - 선으로 관계 표시
      • 액터와 유스케이스 사이의 관계
        1. 연관 관계
           • 유스케이스와 액터간의 상호작용을 표현
           • 실선으로 연결
        2. 의존 관계(포함 관계, 확장 관계)
           • 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때
           • '포함하는 유스케이스'에서 '포함되는 유스케이스'방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기(글을 등록한다 -> 로그인한다)
             • 확장 관계
               • 특정 조건에 따라 확장 기능 유스케이스를 수행하기도 하는 경우
               • '확장 기능 유스케이스'에서 '확장 대상 유스케이스'방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기
        3. 일반화 관계
           • 유사한 유스케이스들 또는 액터들을 모아 추상화한 유스케이스 액터와 연결시켜 그룹핑
           • '구체적인 유스케이스'에서 '추상적인 유스케이스' 방향으로 끝부분이 삼각형의 테두리인 화살표를 실선으로 연결
    • 시퀀스 다이어그램 - 기능 수행을 위해 시스템 내의 객체들이 다른 객체들과 어떻게 교류하는지를 보여주는 다이어그램
      • 구성항목
        • 객체 - 사각형 박스 안에 밑줄 친 이름
        • 생명선 - 객체에서 아래로 뻗어 나가는 쇄선
        • 실행 - 실행되고 있음을 나타냄
        • 메시지 - 객체 간 상호 작용은 메시지 교환으로 이루어짐
        • 시간 - 수행 순서는 위에서 아래로 표시
    • 통신 다이어그램 - 객체 사이에 주고 받는 메시지가 중요
    • 활동 다이어그램 - 일어나는 일들을 단계적으로 표현(시스템 전체 흐름의 표현이 중요)
    • 상태 다이어그램 - 특정 객체 내부의 자세한 동작을 기술(객체 하나의 흐름 표현이 중요)

 

 

5-3. 인터페이스

• 객체가 해야 하는일
• 클래스에서 사용하는 사각형 사용, 인터페이스 이름 위에 스테레오 타입으로 표시
  • 확장 모델에서 스테레오 타입 객체 표현: 길러멧 = <<>>