• 소프트웨어 공학의 정의와 개발과정

    • 소프트웨어 공학은 인류의 이익을 위해서 소프트웨어와 관련된 원리, 지식, 도구등을 활용하여 새로운 제품, 도구등을 만드는 것
  • 전통적인 소프트웨어 공학의 개발 과정(폭포수모델)

    Untitled

    • 계획, 요구사항 분석, 설계, 구현, 시험 및 유지 보수 과정
    • 프로젝트 계획
      • 문제정의(무엇을 개발할지)
      • 법적, 경제적, 기술적 타당성 조사
      • 일정계획
        • WBS(Work Breakdown Structure)가 대표적

          Untitled

          • 작업 분할 구조도
          • 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업
          • 수행사 및 담당자까지 지정
    • 요구사항 정의
      • 사용자의 요구사항과 시스템의 기능이 문서화되어야 하는 단계
      • 고객과 개발 회사의 계약서로서의 가치를 가짐
    • 설계
      • 시스템 아키텍처 설계
      • 소프트웨어 아키텍처 설계
        • 클래스 관계 설계
        • 데이터 베이스 설계
        • 컴포넌트 설계
    • 구현
      • 실질적인 프로그래밍 단계
      • 일반적으로 전체 개발 기간의 20%정도를 차지
    • 테스팅
      • 요구사항과 설계에 맞는지 점검 과정으로서 전체 개발 기간의 40%가까이를 차지
      • 테스트 유형
        • 유닛테스트(Unit Testing)
          • 프로그램의 기본단위인 모듈에 대한 테스트를 수행하는 단위 시험
        • 통합테스트(Integration Testing)
          • 단위 시험 후 모듈들을 통합하여 테스트를 수행하는 통합 시험
        • 시스템테스트
          • 통합 시험 이후 소프트웨어와 다른 시스템 요소(하드웨어, 정보 등)들과 통합하여 시스템의 기능을 만족하는지 확인하는 시스템 시험
        • 인수테스트
          • 고객이 참여하여 고객 요구사항 만족 여부를 검증하는 인수 시험
    • 유지보수
      • 사용중 발생하는 여러 변경사항에 대해 적응하는 활동이며 변화에 따른 프로그램 추가/수정을 하는 과정
  • 소프트웨어 개발 방법론

    • 폭포수모델(waterfall)
      • 계획, 요구사항 분석, 설계, 구현(프로그래밍), 테스트(시험), 유지보수의 순서로 시스템의 개발되는 전통적인 방법론
      • 개념 정립에서 구현까지 하향식 접근방법을 사용하여 높은 추상화 단계에서 낮은 추상화 단계로 이동하는 모델
      • 폭포수 방법론의 순차적이고 구조화된 접근 방식은 초기 단계에서의 광범위한 계획과 구조화된 개발 프로세스가 중요한 대규모 모놀리식 시스템의 개발에 적합
      • 폭포수 모델의 장점
        • 프로젝트 진행과정을 세분화하기 때문에 큰 프로젝트의 진척과 인력 관리가 용이
        • 개발방법론의 초기 모델로서 많은 수행과 검증을 거쳐왔고, 대규모 시스템 구축에 있어 경험 축적
        • man/month 기반의 비용산정 → 일정산정의 용이
      • 폭포수 모델의 단점
        • 고객이 원하는 요구사항을 초기에 구체화 하기 어려움
        • 오류발견과 수정이 순환적으로 발생하므로, 순차적 개발이 현실적으로 어려움
        • 시스템 구축이 후반부에 가서야 완료 되는 경우엔, 시스템 문제점 파악 어려움
        • 설계한 아키텍처의 문제가 후반부에 가서야 발견되는 경우가 많아, 수정의 어려움
        • man/month 기반의 비용산정의 불합리성과 일정산정의 부정확함
      • wbs 예시 포맷
        • https://docs.google.com/spreadsheets/d/1yy0oIMSzKch00H9vmOVUSVYPmnCTNJy7a7UZGHgPpZg/edit#gid=0
      • (팀실습)
        • 팀장 선정
        • DB프로젝트 관련 세부 일정 작성
        • 작업자 및 구체적인 역할 작성
    • 애자일
      • 기존 방법론은 프로젝트의 본질적인 목표보다 계획 수립, 문서화, 품질 관리 등 추가로 수행되는 작업을 위해 오버헤드 비용을 과다하게 요구

      • 개발자들이 좋은 것을 빠르고 낭비없이 만들기 위해 경량화된 가벼운 개발방법론이 애자일

      • 애자일 방법론의 단계

        • 분석, 설계, 구현, 시험이 끊임없이 반복 진행되는 순환적 개발과정
        • 각 단계를 짧게 1-2주 정도의 짧은 기간(sprint)을 잡고 특정 기능이 동작하는 데모, 즉 최소 기능 제품(MVP-Minimum Viable Product)를 통해 배포후에 고객에게 시연하고 피드백을 통해 다시 반복적으로 분석,설계,구현,시험
        • 요구사항의 변화가 자주 일어나거나 개발자가 소규모인 소형 또는 중간 사이즈의 비즈니스 시스템, 게임 소프트웨어 개발이 적합
      • 애자일 방법론 중 하나로 스크럼(SCRUM) 방식이 널리 사용

        Untitled

        • 스크럼 이란 특정 이슈를 bottom up방식을 통해 발행하여 문제를 공유하고 문제를 짧은 스탭을 통해 해결해 나가는 과정
        • PO, PM(PL), 기획자, 개발자, 디자이너 등이 스크럼의 참여자
        • 일반적으로 개발팀에서 scrum회의라 하면 우선순위별로 발행된 이슈에 대해 논의하고, 스프린트(팀이 일정량의 작업을 완료하는 기간)별로 진척 상황을 회고 하는 것.
        • 스크럼을 위한 툴로서 아틀라시안사의 JIRA라는 툴을 많이 사용
        • JIRA의 활용
          • 회원가입 및 로그인

          • 프로젝트 생성

            • 일반적으로 개발팀에서는 스크럼 방식 선택
            • 키 설정
              • PROJ1, PROJ2 등 앞으로 작업할 프로젝트와 연관성있게 설정
          • 작업 생성 과정

            Untitled

            • 에픽
              • 큰 단위의 업무(여러 Story, Task 등을 묶은 단위)
            • STORY
              • 최종 고객에게 가치를 제공하는 기능을 표현하고 싶을때
              • 예시) 사용자 관리 개발
            • 작업(TASK)
            • 스프린트
            • 진행 과정
          • JIRA는 GITHUB, SLACK 등의 툴과 연계하여 유기적으로 활용

        • jira github연동
        • (팀실습)
      • 애자일 방법론의 작은단위의 기능개발, 팀별 자율성 등의 특징은 모놀리식 아키텍처가 아닌 msa 아키텍처와 적합한 구조

    • 모놀리식 아키텍처
    • msa