1. 소프트웨어 공학 개념

1.1 소프트웨어 공학(Software Engineering)

1.1.1 소프트웨어 공학의 정의

• 소프트웨어 위기를 극복하고 효율적으로 품질 높은 소프트웨어를 개발하기 위한 학문
• 소프트웨어를 개발하는데 있어서, 어떻게 개발할지, 무엇을 개발할지와 같은 방법 도구, 이론을 모두 포함한 포괄적인 개념

1.1.2 소프트웨어의 위기의 원인

• 소프트웨어 특성에 대한 이해 부족
• 소프트웨어 관리 방법론 부재
• 올바른 설계 없이 프로그래밍에만 치중
• 소프트웨어 개발에 대한 전문적 교육 부족
• 작업일정과 비용의 추정치가 부정확

1.1.3 소프트웨어의 위기의 결과

• 개발 인력의 부족과 인건비 상승
• 소프트웨어 성능 및 신뢰성 부족
• 개발 기간 및 비용의 증가
• 소프트웨어 품질저하 및 유지보수 비용 증가
• 소프트웨어의 생산성 저하

1.2 소프트웨어 공학의 3R⭐

1.2.1 소프트웨어 공학의 3R의 정의

완성된 소프트웨어를 기반으로 역공학, 재공학, 재사용을 통해 소프트웨어의 생산성을 극대화하는 기법

1.2.2 소프트웨어 3R의 필요성

• 소프트웨어 유지보수 효율성 향상 및 비용 절감
• 소프트웨어 개발 생산성 향상
• 소프트웨어 이해, 변경 테스트 용이
• 소프트웨어 변경 요구사항에 대한 신속한 대응
• 소프트웨어 위기 극복

1.2.3 역공학(Reverse Engineering)⭐

• 기존 개발된 시스템을 CASE도구를 이용하여 사양서, 설계서 등의 문서로 추출하는 작업
• 개발 단계를 역으로 올라가 기존 개발된 시스템 코드, 데이터로부터 설계 명세서나 요구 분석서 등을 도출하는 작업
• 역공학의 특징
  • 상용화되거나 기술 개발된 소프트웨어의 분석을 도와줌
  • 기존 시스템의 자료와 정보를 설계 수준에서 분석 가능해 유지보수성 향상
  • 기존 시스템 정보를 Repository에 보관하여 CASE의 사용을 용이하게 함
• c.f.) 순공학 : 절차대로 소프트웨어를 만드는 방법
  • 차세대 : 재개발 + 재사용
  • 고도화 : 재공학

1.2.4 재공학(Re-engineering)⭐

• 기존 시스템을 널리 사용되는 프로그래밍 표준에 맞추거나 고수준의 언어로 재구성하고, 이기종에서 사용할 수 있도록 변환하는 작업
• 재공학의 특징
  • 현 시스템의 유지보수성 향상
  • 시스템의 이해와 변형을 용이하게 하며,
  • 표준 준수 및 CASE의 사용 용이

1.2.5 재사용(Reuse)

• 이미 개발되어 그 기능, 성능 및 품질을 인정받았던 소프트웨어의 전체 또는 일부분을 다시 사용
• 재사용의 특징
  • 소프트웨어 생산의 TCO (Total Cost Overhead) 절감
  • 높은 품질의 소프트웨어 생산을 위한 공유 및 활용 효과
• 재사용의 범위
  • 함수와 객체 재사용 : 클래스나 함수 단위로 구현한 소스코드를 재사용
  • 컴포넌트 재사용
  • 애플리케이션 재사용
• 재사용 방법
  • 합성 중심(Composition Based) : 전자 칩과 같은 소프트웨어 부품, 즉 블록(모듈)을 만들어서 끼워 맞추어 소프트웨어를 완성시키는 방법
  • 생성 중심(Generation Based) : 추상화 형태로 쓰여진 명세를 구체화하여 프로그램을 만드는 방법

1.3 소프트웨어 개발 단계

1. 계획

   • 무엇을 개발할 것인지 명확하게 정의
   • 개발 범위를 결정
   • 시스템의 성격을 파악하여 비용과 기간을 예측

2. 요구사항 분석(Requirements Analysis)

   • 개발할 소프트웨어의 기능과 제약조건, 목표 등을 고객과 함께 정의
   • 요구사항의 정확한 이해 및 요구사항 유도
   • 과다하거나 불필요한 요구사항에 대한 협상 및 조율
   • 요구사항의 적합성 검토 및 향후 예측
   • 현재 실행 환경에 대한 분석

3. 소프트웨어 설계(Design)

   • 시스템이 어떻게 동작하는지를 정의
   • 요구사항 분석 단계에서 산출된 요구사항을 기준으로, 입력자료, 처리내용, 출력자료 등을 정의
   • 설계 구분
     • 시스템 구조 설계 : 모듈간의 관계와 구조 설계
     • 프로그램 설계 : 각 모듈의 처리 절차나 알고리즘 설계
     • 사용자 인터페이스 설계 : 사용자가 시스템을 사용하기 위해 보여지는 부분을 설계

4. 구현(Development)

   • 프로그래밍 언어를 이용하여 실제로 프로그램을 작성
   • 코딩과 디버깅이 이루어지며, 단위(모듈) 테스트를 진행

5. 테스트(Testing)

   • 구현된 소프트웨어가 요구사항을 만족하는지 검사(확인 과정)
   • 실행 결과가 예상 결과와 맞는지 검사하고 평가
   • 테스트 계획, 통합 테스트 결과서 등을 작성

6. 유지보수(Maintenance)

   • 소프트웨어를 사용하며 문제점을 수정하고, 새로운 기능을 추가

   • 소프트웨어를 좀 더 발전시키는 단계

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

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

2.1.1 구조적 방법론⭐

• 절차지향 소프트웨어 개발 방법론 (하향식)
• 제한된 구조에서 코드 생성 및 순차적 실행
• 구조적 방법론 기본 개발 과정

• 구조적 방법론 구성요소 : 데이터 흐름도(DFD), 자료사전(DD), 상태전이도(STD), 소단위 명세서(Minispec)

2.1.2 정보공학 방법론

• 기업의 주요 부분을 계획, 분석, 설계 구축에 정형화된 기법들을 상호 연관성있게 통합, 적용하는 데이터 중심 방법론
• 빠른 결과물 확인이 가능하며 단순 S/W 개발이 아닌 기업의 경영전략에 초점을 둔다.
• 정보공학 방법론 기본 개발 과정

2.1.3 객체지향 개발 방법론⭐

• 현실세계의 개체(Entity)를 속성(Attribute)과 메서드(Method)형태로 표현, (상향식)⭐
• 객체, 클래스 간의 관계를 식별하여 설계 모델로 변환하는 방법론
• 분석과 설계, 구현의 전 과정을 객체 중심으로 개발
• 전체 프로세스 방향성 유지와 상속에 의한 재사용성 향상
• 특징 : 캡슐화, 정보은닉, 상속, 다형성, 추상화⭐

2.1.4 CBD( Component Based Development) 분석 방법론

• 재사용 가능한 컴포넌트의 개발 또는 상용 컴포넌트를 조합해 어플리케이션 개발
• 새로운 기능 추가가 쉬운 확장성
• 생산성 및 품질이 향상
• 시스템 유지보수 비용 최소화

2.1.5 애자일(agile, 민첩한) 방법론

• 기존 방법론들이 절차를 중시한 나머지 변화에 빠른 대응을 할 수 없는 단점 개선을 위해 등장
• 애자일 방법론 종류 : XP, SCRUM, FDD, Crystal 방법론 등⭐

💡 애자일 선언문

공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를

왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다.

2.1.6 개발 방법론 선택 기준

• 프로젝트 특성 및 규모
• 프로젝트 참여자의 수준
• 가용 자원의 정도(인력, 장비, 시간, 비용)
• 요구사항의 명확도
• 위험도

2.2 소프트웨어 개발 모델

2.2.1 폭포수 모델(Waterfall Model)⭐

• 계획, 분석, 설계, 구현, 테스트, 운영 등 전 과정을 순차적으로 접근하는 개발모델(=선형 순차 모델)
• 각 단계의 검증 후에 다음 단계를 진행한다.
• 각 단계가 순차적으로 진행되며, 병행되거나 거슬러 반복 진행되지 않는다.
• 가장 오래된 모형으로 적용 경험과 성공사례가 많다.
• 요구사항의 변경이 어렵다.
• 단계별 정의가 분명하고, 단계별 산출물이 명확하다.

2.2.2 프로토타이핑 모델(Prototyping Model)⭐

• 고객이 요구한 주요 기능을 프로토타입으로 구현하여 완성해가는 모델
• 개발자가 구축할 소프트웨어의 모델을 사전에 만들어 요구사항을 효과적으로 유도하고 수집한다.
• 프로토타이핑에 의해 만들어진 프로토타입은 폐기될 수 있고, 재사용될 수도 있다.
• 순서 : 계획수립 → 프로토타입 개발 → 사용자 평가 → 구현 → 인수
• 장점
  • 사용자의 요구사항을 충실히 반영할 수 있다.
  • 비교적 빠른 기간 안에 사용자가 평가할 수 있는 결과물이 만들어진다.
  • 오류를 초기에 발견할 수 있다.
  • 변경이 용이하다.
• 단점
  • 최종적으로 시간과 비용이 훨씬 많이 들 수 있다.
  • 사용자가 실제 제품과 혼동할 수 있다.
  • 문서작성이 소홀해질 수 있다.
  • 프로토타입 폐기에 따른 비용이 든다.

2.2.3 나선형 모델(Spiral Model):계위개고⭐

• 폭포수 모델과 프로토타이핑 모델의 장점을 수용하고, 위험 분석을 추가한 점증적 개발 모델

• 프로젝트 수행 시 발생하는 위험을 관리하고 최소화하려는 것이 목적

• 대규모 프로젝트 및 위험 부담이 큰 시스템 개발에 적합

• 순서 : 계획수립(planning) → 위험분석(Risk Analysis) → 공학적 개발(Development) → 고객 평가(Evaluation)⭐

  • 계의 위, 개고기

• 장점

  • 위험분석 과정으로 위험성이 큰 프로젝트를 수행할 수 있다.
  • 고객의 요구사항을 보다 더 상세히 적용할 수 있다.

• 단점

  • 시간과 비용이 많이 들 수 있다.
  • 반복 단계가 길어질수록 프로젝트 관리가 어렵다.

2.2.4 RAD(Rapid Application Development, 빠르게 앱 개발) 모델

• 매우 짧은 개발 주기를 강조하는 점진적 소프트웨어 개발 방식
• 강력한 소프트웨어 개발 도구를 이용하여 매우 짧은 주기로 개발을 진행하는 순차적 소프트웨어 개발 프로세스
• CASE(Computer-Aided Software Engineering, 컴퓨터 지원 소프트웨어 공학) 도구를 이용해 시스템을 개발
• 개발 기간이 60일~90일 정도로 짧다.
• 기술적으로 위험이 적고 빠른 개발이 요구될 때 사용이 적합

2.2.5 V 모형 : 단통시인⭐

• 폭포수 모델에 시스템 검증과 테스트 작업을 강조
• 높은 신뢰성이 요구되는 분야에 적합함

2.2.6 4세대 기법(4th Generation Techniques)

• CASE 등의 자동화도구를 이용하여 요구사항 명세로부터 원시코드를 자동으로 생성

2.3 애자일(Agile) 방법론

2.3.1 애자일 방법론의 개념

• 애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과, 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론
• 애자일 개발 방법론이란 어느 특정 개발 방법론을 가리키는 말은 아니고 애자일 개발을 가능하게 해주는 다양한 방법론 전체를 일컫는 말
• 경량(Lightweight) 프로세스라고도 함
• 프로젝트를 시작한 후 끊임없이 개선 노력

2.3.2 애자일 프로세스의 등장배경

• 기존 소프트웨어 개발 방법론의 문제점을 개선하기 위해서 등장
• 기존 소프트웨어 개발 방법론의 주요 문제점
  • 계약과 계획준수를 중요시하는 갑과 을의 문화가 지배적
  • 문서를 중시
  • 프로세스나 툴 적용을 중시
  • 성과가 나쁠 때 계획 또는 통제의 실패로 인식함

2.3.3 애자일 선언문

• 공정과 도구보다 개인과 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를
• 계약 협상보다 고객과의 협력을
• 계획을 따르기보다 변화에 대응하기를
• 우리는 왼쪽 항목의 가치를 인정하면서도 오른쪽 항목을 더 중요하게 여긴다.

2.3.4 애자일 특징

• 고객과 개발자의 지속적인 소통을 통하여 변화하는 요구사항을 신속하게 수용
• 개발자 개인의 가치보다는 팀의 목적을 우선시 하며 고객의 의견을 가장 우선
• 팀원들과의 주기적인 회의와 제품을 시연함으로써 소프트웨어를 점검
• 작업 계획을 짧게 세우고, 반복적으로 수행함으로 변화에 유연하게 대처

2.3.5 애자일 방법론 종류

2.3.5.1 XP (eXtream Programming) : 용단의 피존⭐

• 특징
  • 문서보다는 코드를 중시하고, 5가지 핵심가치와 12개 실천 항목이 존재
  • 개발을 세분화 하여 1~3주의 반복으로 개발을 진행
• XP 5가지 핵심 가치⭐
  • 용기 : 고객의 요구사항 변화에 능동적인 대처
  • 단순성 : 부가적 기능, 사용되지 않는 구조와 알고리즘 배제
  • 의사소통 : 개발자, 관리자, 고객 간의 원활한 의사소통
  • 피드백 : 의사소통에 따른 즉각적인 피드백
  • 존중 : 개발자의 역량을 존중하고 충분한 권한과 권리를 부여
• 12가지 실천사항

2.3.5.2 스크럼 (SCRUM)⭐

• 소프트웨어에 포함될 기능·개선점에 대한 우선 순위를 부여
• 개발 주기는 30일 정도(스프린트)로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 작성
• 날마다 15분 정도의 회의
• 항상 팀 단위로 생각한다

2.3.5.3 그 외 애자일 방법론

• 크리스털 패밀리 (Crystal) : 프로젝트의 규모와 영향의 크기에 따라서 여러 종류의 방법론을 제공
• Feature-Driven Development (FDD)
  • feature마다 2주 정도의 반복 개발을 실시
  • 기능 주도 개발
• Adaptive Software Development (ASD) : 합동 애플리케이션 개발을 사용하는 방법론