1. 폭포수 모형(Waterfall Model)
  : 가장 보편적인 모델이다. 이전단계로 다시 돌아갈 수 없다
  => - 각 단계를 확실히 매듭지어야 한다.
     - 2개 이상의 과정을 병행할 수 없다.
     - 메뉴얼 작성이 필요하다.
     - 개발 완료 후 발견된 오류 해결불가능 하다.

2. 프로토타입 모형(Prototype Model)
  : 원형모델
  => - 기능적 인터페이스중심으로 견본 개발 후 최종 개발한다 => 추 후 발견 될 오류 방지
     - 프로토타입을 만들어서 문제점을 파악하고  프로토타입을 기초로 한 완전한 소프트웨어를 개발하는 형태이다
     - 시제품이나 견본이라고도 한다.
     - 빠른개발을 위 디자인이나 마감처리 등을 무시하고 최대한 기능적인 부분 구현한다
     - 인터페이스 중심 개발 ==> 폭포수 모형의 단점을 보안할 수 있다.

3. 스파이럴(나선형) 모형(Spiral Model)
  : 계획 - 분석(검증) - 개발 - 평가(오류방지)의 단계 여러번 반복하여 소프트웨어의 완성도를 점진적으로 향상시킨다.
  => - 유지보수를 할 필요가 없는 수준까지 완성도를 높이는게 목적이다.
     - 폭포수와 프로토타입의 장점을 흡수하여 점진적 개발
     - 대규모 소프트웨어 개발에 용이하다.

4 애자일 모형(Agile Model)
  : 절차와 문서보다 고객과의 상호작용과 협업을 중점으로 두고 변화에 빠르게 반응할 수 있도록 개발의 방향을 잡는다.

 ** 스크럼(Scrum) 기법 : 팀을 중심으로 진행된다.
     - 제품책임자,스크럼 마스터, 개발팀 으로 구성된다.
       * 제품 책임자(po) => 의사결정권이 있다.백로그의 우선순위 지정
       * 스크럼마스터 => 개발팀을 지원, 조율 한다.일일 회의 주관,개발가이드
       * 개발팀 => 디자이너 및 테스터를 전부 포함.
     - 우선순위는 제품책임자에 의해서만 변경될수 있다.
     순서
     : 1.소통을 통해 개발에 필요한 사항을 백로그(Backlog)에 기록한다.
       2.백로그가 준비되면 스크럼 마스터는 계획 회의를 진행한다.
       3.회의를 통해 각 개발자들은 세부 개발목표와 시간을 할당 받는다.=>스프린트
       4.팀원들은 스크럼 마스터와 함께 매일 회의를 열어 계획에 방해가 되는 요소들을 스크럼 마스터에게 알리고 스크럼마스터는 장애요소 해결을 위해 노력한다.
       5.소멸차트를 통해 일의 진행이 매끄러운지 판단할수 있다 => 예상기간 대비 실제 작업진행량을 비굫여 문제점을 파악한다.
       6.제품 책임자는 매주 검토회의를 통해 필요한 내용을 백로그에 업데이트 한다.

                                       ↓

     <정리>
       1. 백로그 : 개발자와 사용자들이 모두 형식없이 편하게 이야기형식으로 되어있어 스토리라고 부른다.
       2. 계획 회의 : 개발자 별로 스프린트 백로그 작성
       3. 스프린트 :  할일, 진행, 완료의 상태
       4. 일일 회의: 소멸차트 활용,장애요소 해결 - 스크럼 마스터 주도
       5. 검토 회의 :  전체인원, 주별진행,po피드백,백로그 업데이트
       6. 회고 : 지난 일정 되돌아보기 개선점찾기

    * 각각의 스프린트에 대한 개별 백로그 =>  스프린트 백로그
    ★ 회의 주체가 다르다는 점 기억한다.★

 ** XP(eXtrem Programming) 기법
    - 개발주기를 짧고 반복적으로 만들어 고객의 적극적인 참여 유도한다. => 고객은 좀더 자주 프로그램의 개발과정을 직접 확인할 수 있게 된다 => 가시성이 향상된다
    - 주로 소규모 개발에 사용된다
  * 핵심가치 : 피드백,존중,용기,단순,의사소통
    - 개발 프로세스
      1. 사용자 스토리 : 고객의 요구사항
      2. 릴리즈 계획 수립 : 부분과 전체의 개발 일정 수립
      3. 스파이크 : 기술 및 기능확인을 위해 간단히 만드는 프로그램 => 전체 기능과 상관없이 오로지 특정 기능 하나에 대한 테스트를 하기 위해 작성되는 프로그램
      4. 이터레이션 : 릴리즈를 좀더 세분화 한 단위 => 1~2주의 시간으로 완성가능한 기능을 모아 고객이 직접 평가할 수 있도로 프로그램을 만드는 과정
      5. 승인검사 : 부분 소프트웨어가 릴리즈 되면 고객이 직접평가
      6. 소규모 릴리즈 : 릴리즈 별로 고객의 피드백 확인 가능

  * 릴리즈 : 프로그램을 배포하는 단위 => 프로그램 버전 1.0,2.0 등 => 릴리즈 단위
  * 릴리즈 규모를 작게하면 좀 더 완성도 높은 소프트웨어를 기대할 수 있다.

  1. 구 : 업무 시스템(구성) 파악 => 주요 업무와 지원 업무로 구분하여 각 시스템별 주요 기능을 명시한다.
    * 기간 업무 : 주요 업무 담당 / 지원 업무 : 지원 업무 담당
  2. 기 : 해당  업무의 세부적인 기능을 파 => 계층형 표시 : 세부 기능 파
  3. 인 : 시스템 인터페이스 파악
    * 인터페이스 : 업무시스템 간에 주고받는 데이터의 종류 및 형식, 프로토콜(규칙과 약속) 등
  4. 아 : 시스템 아키텍처 파 => 주요 업무를 기준으로 각 시스템이 어떤 원리로 동작을 하는지를 구서오 형식으로 표현, 계층적으로 나타난다.
  5. 소 : 소프트웨어의 구성을 파악한다. => 각 소프트웨어의 용도,라이선스의 적용방식, 라이선스 개수 파악
    * 라이선스 :  해당 저작물의 사용범위 => 일부 사용 OR 전체 사용 OR 상업적 사용여부 및 소프트웨어 재구성 가능 여부 등
  6. 하 : 하드웨어의 구성 파악 => 서버의 주요 스펙과 수량, 이중화 적용 여부를 명시
    * 이중화 : 데이터를 하나더 복사 하는 것 => 복사본, 백업
  7. 네 : 네트워크 구성 파악 => 네트워크의 물리적 위치를 구성도로 작성 => 위치파악 및 보안이 취약한 곳을 파악하는데 유용, 추 후 유지보수에도 활용 가능

  * 운영체제(OS - Operation System)
    - 컴퓨터 시스템 자원관리
    - 컴퓨터 시스템 리소스 : 하드웨어를 관리해준다.
    - 사용자와 하드웨어 사이의 인터페이스 제공한다.=> 하드웨어 제어를 위한 인터페이스
    - 종류 : window,ios,android,linux 등
    - 고려할 요소 : 주변기기 지원여부
  * 데이터페이스 관리 시스템(DBMS - Data Base Management System)
    - 사용자가 데이터베이스를 좀 더 쉽고 체계적으로 다룰 수 있다
    - 종속성과 중복성을 해결 할 수 있게 한다.
      * 종속성 : 데이터가 항상 다른 고유한 데이터에 붙어다니는 것 EX)학번-이름
    - DBMS 는 DB에 대한 모든 관한과 책임이 있다.
    - 종류 : Oracle,Ms-SQL,My-SQL,MonggoDB 등
    - 고려할 요소 : 서버와 클라이언트의 상호 호환성,백업,이중화 가능여부
  * 웹 어플리케이션 서버(WAS)
    - 동적 콘텐츠 처리를 위한 미들웨어
    - 서버와 클라이언트 사이에서 작동한다 => 미들웨어 라고 도  부른다
      * 미들웨어 : 서버와 클라이언트 중간에 위치,클라이언트 대신 복잡한 처리를 하기 위함
    - 정적/동적인 콘텐츠를 따로 관리하기 위해 사용한다.
      * 정적 콘텐츠 : 웹사이트의 이미지 등
      * 동적 콘텐츠 : 주식,날씨정보 등 실시간으로 변동되는 데이터
    - 동적 콘텐츠에 대한 로직을 대신 수행해주기 때문에 클라이언트는 좀 더 가벼운 로직을 수행 할 수 있게 된다.=> DB와 연동하여 사용한다.
    - 종류 : Tomcat,Websphere 등
    - 고려할 요소 : 다양한 기능 여부

  * 개발기술 환경 선택시 공통 고려사항
    1. 가용성 : 현재 내가 하고 싶은 작업을 진행 할 수 있는지
    2. 성능
    3. 기술지원 : 개발에 필요 메뉴얼이나 레퍼런 관련 커뮤니티 등을 아우르는 개 => 무언가 막혔을 때 해결가능한 루트가 얼마나 풍부한지
    4. 비용
    5. 오픈소스 : 개발소스가 공개 된 무료 기술 => 무료의 개념이 라이선스 종류별로 다르기 때문에 종류를 정확하게 파악해야 한다.
      ==> 추가로 사용가능한 라이선스의 개수,인원수 를 파악해야 하고 해당 기술이 지속 가능성이 있는지 반드시 검토해야 한다.

  * 요구사항 확인
    1. 기능 : 원하는 기능 자체에 대한 서술 ex)로그인,회원조회
    2. 비기능 : 기능에 대한 품질,제약사항 서술 ex) 최대100명,1시간 이내
    3. 사용자 : 사용자 입장 => 쉬운 표현 사용
    4. 시스템 : 개발자 입장 => 전문 용어 사용

  * 요구사항 개발 프로세스 : 도출-분석-명세-확인
    1. 도출 : 요구사항을 수집하는 단계
    => 이해관계자 간의 의사소통 중요
    2. 분석 : 도출된 요구사항의 타당성 조사
    => 분석 단계
       1. 요구사항 분류 : 득정한 기준으로 분류(기능과비기능,우선순위,과정과결과)
       2- 개념 모델링 : 요구사항을 단순화 시켜 개념적으로 표현,객체(개체) 간의 관계와 종속성 분석, 다양한 관점으로 표현할 수 있다, 모델링 표기는 주로 UML을 사용
       3. 요구사항 할당 : 요구사항을 만족 시키기 위한 요소들을 할당
       4. 요구사항 협상 : 충돌되는 요구사항 해결(서로의 요구사항,필요자원,기능과비기능 요구사항이 충돌하는경우) => 우선순위가 문제 해결에 도움이 될 수 있다.
       5. 정형 분석 : 구문과 의미를 갖는 언어를 이용, 수학적 기호로 표현
    3. 명세 : 분석한 내용을 문서화 한다.
    => 빠르고 명확하고 이해하기 쉽게 기록
    4. 확인 : 명세서를 검증하는 단계,형상관리를 확실하게 수행해야 한다
              * 형상 :  어떠한 작업의 결과물을 통칭하는 단어


    => <확인 단계>
       1. 요구사항 확인 : 문서화 된 요구사항을 검증 => 요구사항 검토(가장 일반적,훑어보기)
                        - 검토자 그룹에는 고객 대표 등이 꼭 포함 되어야 한다.
       2. 프로토타이핑 : 지속적으로 프로토타입을 재작성
          => 장점 : 빠른제작,사전피드백,문제점 사전 식별
             단점 : 프로토타입에만 집중이 될 수 있다,과대평가,비용부담
       3. 모델 검증 : 요구사항 충족 여부 검증 => 정적분석을통한 검증
                    * 정적분석 : 논리적인 검증(실행X)
       4. 인수 테스트 : 사용자 입장에서 요구사항 체크(계획 필요)

 * UML의 구성요소 : 사물,관계,다이어그램
    - 사물: 특정 대상을 의미 , 이 사물을 기준으로 관계가 형성 된다.
      => 종류 : 구조(요소),행동(행위),그룹(묶음),주해(설명)
    - 관계 : 사물 사이의 관계를 표현
      => - 연관 관계 : 영향을 주는 관계를 실선 화살표로 표현 -> 서로에게 영향을 주는 경우 : 화살표 생량 => 관련되 객체수를 의미하는 다중도를 나타낸다.
      < * = 다수/ .. = 또는> 의미를 나타낸다.
         - 의존 관계 : 점선 화살표로 표현
         - 일반화 관계 : 여러 사물의 공통적인 상위 개념을 실선 화살표로 묶음
         - 실체화 관계 : 여러 사물의 공통적인 기능을 점선 화살표르 묶음
         ★ 실선 : 평생 / 점선 : 필요에 의해 묶이는 일시적인 관계
         - 집합 관계 : 화살표가 아닌 마름모로 표현 전체와 부분 中 전체 쪽에 마름모를 붙혀 관계를 나타낸다.=> 비어있는 마름모로 나타낸다
         - 포함 관계 : 화살표가 아닌 마름모로 표현 전체와 부분 中 전체 쪽에 마름모를 붙혀 관계를 나타낸다.=> 꽉 차있는 마름모로 나타낸다