소프트웨어 공학 - 요약 #1

---

소프트웨어 공학

체계적이고 훈련되어지고 정량화할 수 있는 접근의 응용, 소프트웨어의 개발, 운용, 유지보수에 대한 학문

• 소프트웨어 시스템 : 프로그램과 프로그램의 개발, 운용, 보수에 필요한 정보 일체

 

현재 코딩 기법보다 10% 정도의 비용이 절약되는 새로운 코딩 기법을 발견하면 사용해야 하는가?

1. 훈련 비용 고려하여 결정
2. 새로운 기술 도입의 영향을 고려
3. 유지 보수에 대한 고려

전통적인 생명주기 모델

---

유지보수

이미 완성된 프로그램을 고치는 것

• 유지보수의 목적 : 기능 향상 (명세를 변경하고 변경된 명세를 구현)

유지보수의 유형

1. 완전적 유지보수
2. 수정적 유지보수 : 옳게 고쳐 내재된 결함 제거
3. 적응적 유지보수
4. 예방적 유지보수

고전적 유지보수의 문제점

• 설치 전 동일한 오류 감지 및 해결
• 설치 후 고객의 기능 추가 요청

현대적 유지보수

• 소프트웨어가 문제점이나 개선 또는 적응에 대한 필요 때문에 실제로 코드가 바뀌거나 문서에 수정이 필요할때는 모두 유지보수로 볼 것
• 설치 전, 후 상관 없음 (어느 시점에서던 진행)

요구사항, 분석, 설계 측면

• 모든 단계가 다 중요
• 요구사항 단계부터 수정해야 할 사항은 계속 발생
• 작은 소프트웨어는 시간이 갈 수록 유지보수 비용 증가
• 큰 소프트웨어의 유지보수 비용은 작은 소프트웨어보다 더욱 가파르게 증가
• 결함을 최대한 빠르게 감지해서 빠르게 수정하는 것이 최선
• 대부분의 프로젝트 결함은 6~70%는 요구사항, 분석, 설계 단계에서 발생

많은 결함들이 소프트웨어 생명주기의 초반에 나타나기 때문에 소프트웨어 공학의 다른 측면에서보다 좋은 요구사항, 분석, 설계들을 만들어내는 기법이 중요

팀 개발 측면

• 소프트웨어는 팀 베이스
• 팀들이 작업할 때 어떻게 해야 요구를 잘 분석하고 변경사항을 잘 파악하는가?
• 팀 구성원간의 의사소통이 제일 중요

개발 패러다임 측면

• C언어는 구조적 패러다임으로 구조적 시스템 분석과 설계를 통해 프로그램 작성
• 규모의 증가에 따라 문제가 발생하기 때문에 객체지향 패러다임 등장

소프트웨어 공학은 큰 소프트웨어를 타겟팅

객체지향 패러다임의 강점

1. 개발을 보다 더욱 쉽게 : 실 세계 문자를 있는 그대로 표현
2. 유지보수를 보다 쉽고 빠르게 : 자기의 책임 아래에 모두 분해를 해 놓았기 때문에 유지보수를 쉽게 진행
3. 잘 설계된 객체는 독립적
4. 소프트웨어 프로덕트의 복잡도 수준을 감소
5. 재사용 촉진

---

소프트웨어 공학의 목표

• 위기를 극복해서 고품질의 소프트웨어를 최소 비용으로 계획된 일정에 맞추어 개발
• 여러 가지의  공학적 원리 및 방법을 적용해서 진행

소프트웨어 공학의 주제

어떤 단계를 거쳐서, 어떤 작업들을 거쳐서 일을 하면 되는지, 실제로 품질을 만족한다는 것을 어떻게 알수 있는지, 과정이나 품질을 어떻게 관리할수 있는지를 연구

---

소프트웨어 개발 과정 (프로세스와 방법론)

• 작은 프로그램을 개발할 때는 특별히 정해진 과정, 절차, 규정 없이도 충분히 작성 가능

Code and Fix : 프로세스가 없는 개발

• 소프트웨어가 커지고, 혼자만의 개발이 아닌 여럿이서 개발을 진행하면서도 프로세스 없이 개발을 진행하면 '사공이 많으면 배가 산으로 간다’ 실현

소프트웨어 생명주기

소프트웨어가 처음 계획된 이후 개발, 운영/유지보수, 폐기까지의 전 과정

• 생명주기 모델 별로 다른 프로세스의 정의 가능

전통적 생명주기 모델

• 기본적으로 요구 분석, 설계, 구현, 테스트, 유지보수의 5개 프로세서로 구성
• 프로세스의 앞, 뒤로 개발과 폐기 존재

계획

1. 개발 범위 정하기
2. 산정
3. 위험 분석
4. 일정 계획
5. 관리 전략 수립

• 위 질문의 대답을 찾는 단계
• 이러한 대답들을 잘 정리해서 문서를 작성하는 것이 소프트웨어 개발계획서
• 개발 단계에서는 위의 5가지 컨셉트 정리 과정이 계획서에 포함이 되어야 함
• 1차적으로 계획서를 세울 때 개발 범위 확장

개발 범위 : 시스템에서 무엇을 제공해야 하는지 대략적으로 나오는데, 이를 토대로 요구 확정 및 분석

요구 분석

요구를 먼저 뽑아내고 그 요구가 맞는지 분석 후 확정하는 단계 → 무에서 유를 창조하는 단계

• 요구(Requirement), 분석(Analysis) 두 개의 단계가 포함된 것

요구 : 소프트웨어 시스템이 가져야 할 능력(Capability)과 조건(Condition)

• What의 단계 = 전문가가 붙어야 하는 단계
• 요구분석 단계에서 나와야 하는 출력 : 요구 규격서(Requirement Specification)

설계

무엇을 할지 결정하였으니 구체적으로 어떻게 개발해야 할지를 알아내는 단계 → How의 단계

• 알고리즘을 어떻게 결정할 것인지, 어떤 데이터를 어떻게 결정할 것인지 결정하는 단계가 상세 설계
• 설계 단계에서 나와야 하는 출력 : 상세 설계 문서(Detailed Design Specification)

구현

• 설계 단계까지가 제일 중요 → 코드 작성은 설계서가 존재하기 때문에 누구나 작성 가능
• Do it의 단계
• 마감 시간이 다가오기 때문에 압력 증가 → 압력 최고조
• 최고의 인력 투입
• 하청 관리

통합 및 테스트

여러 사람들이 각자 개발한 것들을 모아서 하나의 한 시스템으로 유기적으로 돌아가는 프로그램으로 통합

• 시스템 통합 : 개발자는 코드를 모아 하나의 프로그램으로 엮음
• 엮은 후 동작 확인은 QA팀이 담당
• 테스트에는 여러 가지 단계 존재

1. 단위 : 모듈들을 하나하나 테스트하는 단위 테스팅
2. 통합 : 모듈들을 유기적으로 묶는 통합 테스팅 ★
3. 시스템 : 모두 묶인 것들을 가지고 사용자 요구가 제대로 돌아가는지를 보는 시스템 테스팅

• 스트레스 테스트, 성능 테스트, 목적 테스트, 사용자가 원하는 요구 존재 테스트 등

설치와 유지보수

• 운영이 진행될 때 유지보수 단계 들어감
• 개발은 보통 설치 단계까지라고 봄
• 유지보수는 설치가 모두 완료된 후 사용 중에 일어나는 변경

1. 결함 수정
2. 새 기능 추가
3. 성능 향상

• 이후 폐기 과정 수행

---