소프트웨어 공학 1

소프트웨어 기초

프로그램 그리고, 프로그램의 설계, 운용, 유지/보수에 필요한 제반 정보(주로, 문서(설계 명세), UML + TEXT 작업)

• 소스코드 + 각 개발단계마다 생성되는 문서 (계획/설계 문서, 자료구조, DB구조, 테스팅 결과 등) + 매뉴얼 + …
  • 자료구조 : 메모리 구조
  • DB 구조 : 하드디스크 구조

소프트웨어 유형

• 시스템 SW : 컴퓨터 자원을 관리하는 SW(HW 관리)
• 응용 SW : 시스템 SW위에서 비즈니스 업무 등 한 회사 또는 기관의 내부에서 사용하는 시스템
• 임베디드 SW : 컴퓨터가 아닌 특정 디바이스에 내장된 SW

하드웨어 VS 소프트웨어

SW 공학

특정 도메인의 문제를 해결해주기 위해 대규모의 품질 좋은 SW 시스템을 정해진 시간과 비용으로 개발하거나 발전시키는 체계적인 방법

• 고품질↑
• 정해진 시간↓
• 비용↓

좋은 SW의 조건

• 사용용이성(usability) :빨리 배우고 작업을 쉽게 하는 성질
• 효율성(efficiency) : CPU 시간과 메모리 같은 자원을 낭비하지 않음(시간복잡도, 공간복잡도..)
  • ex) 스마트폰은 메모리를 적게 쓰기위해 노력
• 신뢰성(reliability) : 요구한 기능을 실패 없이 할 수 있는 성질
• 유지보수성(maintainability) : 쉽게 변경할 수 있음
• 재사용성(reusability) : 부품이 다른 프로젝트에서 사용될 수 있는 성질.

 

소프트웨어공학의 차별성

• 설계/개발과정에서 대부분의 비용이 소요됨
  • 한번 찍어내면 대량생산
• 물리적인 부품이 없음
  • 신뢰도가 생산과정이 아닌 설계과정에 의해 결정
• 가시성(visibility)이 낮음
  • 제품의 구조가 쉽게 드러나지 않음
• 특성상 설계와 구현이 연쇄적이 아님

 

SW 개발 작업의 특징

• 명세화의 어려움
• 재사용의 어려움
• 예측의 어려움
  • 개발 비용, 개발 시간
• 유지보수의 어려움

 

고비용

LOC(Lines of Code) : 소프트웨어의 규모를 측정하는 데 가장 널리 사용(라인수)

MM(Man-Month) : 소프트웨어 개발에 드는 비용(한사람이 한달간 일하는 양(PM))

생산성 : MM당 생산하는 프로그램의 LOC

• 5만줄의 프로그램 – 4천만원 내지 1억 2천 정도의 비용

 

소프트웨어 개발의 특수성

• 요구사항이 항상 잘 정의되어 있는것은 아님(요구자가 정확한 명세를 해주진 않음)
  • 요구사항을 잘 분석, 정리하여 요구자에게 해당 요구사항이 맞는지, 추가사항은 없는지 확인 필요
• 오류가 늦게 발견될수록 수정비용이 커짐
• 지연된 프로젝트에 인력을 투입하는 것은 완성을 더 느려지게 함
• 소프트웨어가 적절한 유지보수 정책하에 관리되지 않으면 “dirty system” 으로 변모

 

소프트웨어 프로세스

단계적 개발 프로세스

계획(Planning): 비용, 일정에 대한 계획 및 위험관리

• 해당 프로젝트를 수행할 수 있는가?
• 개발 비용 산정: COCOMO 모델, 기능점수(Function Point) 모델 활용
• 일정 계획 수립: 작업분할구조도(WBS), CPM 활용

 

요구분석(Requirement Analysis) : 소프트웨어 시스템이 풀어야 할 문제를 이해하기 위한 작업(중요)

• 시스템이 목표를 어떻게 성취? vs 시스템으로부터 무엇이 필요한가?
• 문제를 분석 : 문제와 그 배경을 잘 이해하고 개발할 시스템의 요구 찾기
• 요구를 정리 : 요구분석 명세서(requirement specification)
  • 구조적 방법론: DFD 다이어그램
  • 정보공학 방법론: ER 다이어그램
  • 객체지향 방법론: UML의 Usecase 다이어그램(사용자 시나리오)

📌요구사항 분석

• 기능적 요구사항 : 서비스
• 비기능적 요구사항 : 품질, 성능

설계 : 요구문서명세에 기술된 문제의 솔루션을 계획(중요)

• 요구분석(명세)를 만족시키기 위한 2단계 설계과정
• 설계 원리
  • 분할정복(Divide&Conquer), 추상화, 모듈화, 정보은닉 등
• 아키텍처 설계 : 시스템을 여러 컴포넌트의 집합체로 보고 각 컴포넌트들이 요청한 결과를 위하여 어떻게 상호작용 하는지에 초점(큰 그림)
  • 도메인 및 용도에 맞춘 아키텍처 스타일 적용
• 상세 설계 : 각 모듈의 내부 논리를 작성 (클래스 하나하나) - 특정 서브기능을 수행하는 단위체 잘 만들기
  • 디자인 패턴
  • 모듈 평가: 응집도(cohesion)와 결합도(coupling)

 

코딩

• 시스템 설계를 프로그래밍 언어로 변환
• 코딩 작업 중에는 읽기 쉽고 이해하기 쉬운 프로그램이 되어야 함
• 단순함과 명확성을 추구

 

테스팅 : 소프트웨어의 결함을 찾아냄

• 소프트웨어 개발 단계에서 사용되는 중요한 품질 제어 수단
• 프로그램에 포함된 요구, 설계, 코딩 오류를 밝힘
• 단위 테스팅(unit testing) : 모듈이나 컴포넌트를 개별적으로 시험
• 통합 테스팅(integration testing) : 모듈 사이의 연결을 시험
• 시스템 테스팅 : 모든 모든 모듈이 하나의 완전체가 됨, 시스템 전체적으로 요구사항을 만족하는지 테스트
• 인수 테스팅(acceptance testing) : 시스템이 잘 실행되는지 고객에게 데모

 

유지보수(Maintenance)

• 문제점(오류) 해결 - bug 수정
• 새로운 환경/HW에 적응 - 새로운 OS...
• 새로운 기능 보강 - 새로운 feature
• 미리 오류 예방

 

프로그래밍 언어

=> 명령(함수) + 데이터(클래스, 객체)

 

구조적 프로그래밍

• 함수의 집합체
• 명령 중심 언어

객체지향 프로그래밍

• 데이터 중심의 언어
• 클래스의 집합체
• 데이터와 해당 데이터에 접근(조회)하는 메서드를 데이터와 결합 = 캡슐화
  • 데이터 오류가 발생시 해당 데이터 접근 메서드만 수정(오류 effect 수정 감소)

객체지향언어(OOP)의 특징

1. 클래스와 인스턴스(객체)

• 클래스
  • 어떤 문제를 해결하기 위해 데이터를 만들기 위해 추상화를 거쳐 집단에 속하는 속성(attribute)과 행위(behavior)를 변수와 메서드로 정의한 것
• 인스턴스
  • 클래스에서 정의한 것을 토대로 실제 메모리상에 할당된 것으로 실제 프로그램에서 사용되는 데이터

 

2. 캡슐화

• 데이터와 코드의 형태를 외부로 부터 알 수 없게 함
• 데이터의 구조와 역할, 기능을 하나의 캡슐형태로 만드는 방법

 

📌참고
추상화와 캡슐화가 어찌보면 헷갈리는 부분일 수 있다.
추상화는 구현 세부 사항을 포함하지 않고 필수 기능을 나타내어 일반화하는데 초점이 맞춰져있다.
캡슐화는 구현에 대한 세부정보를 은닉화하고 데이터에 접근을 일관된 형식으로 유지하여, 사용되는 기능과 특징을 모아두는데에 초점이 맞춰져있다.

 

3. 상속

• 부모클래스의 속성과 기능을 그대로 이어받아 사용할 수 있게하고 기능의 일부분을 변경해야 할 경우 상속받은 자식클래스에서 해당 기능만 다시 수정(정의)하여 사용할 수 있게 하는 것
• 다중 상속은 불가
  • 클래스의 상속 관계에서 혼란을 줄 수 있기 때문에, 상속은 반드시 하나만 가능하고 필요에 따라 인터페이스를 사용

 

4. 추상화

• 공통의 속성이나 기능을 추출하여 정의
• 공통적인 특성을 파악해서 필요없는 특성을 제거하는 과정
• abstract와는 무관

 

5. 다형성

• 하나의 변수명, 함수명 등이 상황에 따라 다른 의미로 해석
• 오버라이딩(Overriding)
  • 부모클래스의 메서드와 같은 이름, 매개변수를 재정의 하는 것.
• 오버로딩(Overloading)
  • 같은 이름의 함수를 여러 개 정의하고, 매개변수의 타입과 개수를 다르게 하여 매개변수에 따라 다르게 호출할 수 있게 하는 것.

 

프로세스

• 프로세스 : SW 시스템을 구축하기 위해 수행되는 작업의 단계(Object)
• 프로세스 모델 : 프로세스를 생성하는 틀(Class)
  • Class가 틀이고 클래스로 여러개의 Object를 찍어내는 개념과 유사
  • 기본적으로 여러 프로세스 모델이 있고 그 프로세스 모델로 실제 SW 구축을 위한 작업 단계 설계

 

프로세스 모델

• 단계적인 작업의 틀을 정의
• 무엇(WHAT)을 하는가에 중점
• 추상화된 작업의 절차

 

방법론

• 프로세스의 구체적인 구현에 이름
• 어떻게(HOW TO)에 중점
• 프로세스 모델을 구체적으로 명세

 

바람직한 SW 특징

• 예측 가능성 : 비용, 기간, 품질예측이 개발 project에 종속적
• 시험 및 유지보수 용이성 : SW 품질이 좋으려면 가장 중요한 요소

 

프로세스의 종류

• 프로젝트 중심 프로세스
  • 개발 프로세스 (SW 상품을 만들기 위한 절차)
  • 프로젝트 관리 프로세스(개발 프로젝트 관리 - 프로젝트 진행이 원활하도록 관리)
    • 인적관리, 비용관리...
• 기타 프로세스
  • 형상 관리 프로세스 (버전 관리)
  • 프로세스 관리 프로세스 (각각의 프로세스들이 잘 돌아가는지 관리)

 

개발 프로세스

폭포수(waterfall) 모델

각 단계의 흐름이 이전단계가 끝나야(문서나 코드같은 산출물이 나와야) 다음단계 진행

• 결과물 정의가 중요(계획서 = 비용, 기간, 품질, 위험관리 등이 명세되어야 함)
• waterfall 모델의 과정 암기

 

특징

• 요구사항 명확, 변경이 없는 경우 활용
• 문서 중심 주의(결과물 정의)
• 개발 지연의 가능성이 높음
• 최종단계까지 가 봐야 결과물 확인 가능

 

장점

• 심플함
• 중간 산출물이 명확, 관리하기 편함
• 충분한 연구와 분석

 

단점

• 코딩, 테스트가 지연됨
• 각 단계의 전환에 많은 노력 필요
• 프로토타입과 재사용의 기회가 줄어듦

 

적용

• 요구사항이 변경이 적은 프로젝트
• 이미 잘 알고있는 문제나 연구 중심 문제

 

V 모델

검증을 강화하는 관점(폭포수 모델 확장)

단위 테스팅 : 모듈 검증(상세설계)

통합 테스팅 : 모듈을 붙여보면서 인터페이스 검증

시스템 테스팅 : 완성된 시스템 전체를 가지고 요구사항이 제대로 충족되었는지 테스팅

특징

• Waterfall 모델 + 작업 결과의 검증(테스팅)에 초점
• v 모델의 테스팅이 각각 어떤걸 테스트 하는지 암기

장점

• 높은 신뢰성(테스트 많이함) - 모든 경우의 수를 다 테스팅함

단점

• 반복이 없어 변경에 취약

적용

• 신뢰성이 높이 요구되는 분야(의료제어, 원전제어)
• 미사일 방어 시스템, 원전 관리 시스템, 돈관리 시스템

 

프로토타이핑 모델

요구사항을 명확히 도출하기 위해 실험적으로 만들어 보여주는 것

프로토타이핑 : 요구사항에 대한 피드백을 받기 위해 실험적으로 만들어 사용자에게 피드백 받는 방법(껍데기 UI만 만들기)

프로토 타이핑의 2가지 종류

Evolutionary 프로토타이핑: 프로토타입을 진화적으로 발전시켜서 시스템 완성

Throw-away 프로토타이핑: 프로토타입은 요구사항 분석만을 위해 만든 것(실제 개발시에는 버림) -요구사항 도출만이 목적

 

장점

• 사용자의 의견 반영

 

단점

• 프로토타입이 최종결과라 믿음
• 오해, 기대심리 유발
• 요구사항이 과다 위험, 기간단축 요구 우려

 

적용

• 요구사항 도출이 쉽지 않은 도메인
• 요구사항이 불투명한 경우
• 혁신적인 기술 사용시

 

진화적 모델

개발 사이클이 짧은 환경(개발시간을 줄이는 법 - 시스템을 feature별로 나눠 release)

릴리스 구성

incremental : 기능별로 서브시스템 release(배포) 구성 납품 - 기능별로 쪼개서 배포

ex) release1: 인덱싱, release2: 질의분석 기능, release3: 랭킹 기능

iterative : 성능을 점진적으로 업그레이드

ex) 편집기능 => 더 빠른 편집기능

장점

• 몇 가지 기능이 부족하더라도 초기에 사용 교육 가능
• 사용자의 요구를 빠르게 반영
• 새로운 기능을 가진 소프트웨어에 대한 시장을 빨리 형성
• 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속하고 꾸준하 게 고쳐 나갈 수 있음

**단점**

• 프로젝트 관리가 복잡해지기 때문에 큰 프로젝트 부적합 - 관리의 부담
• 끝이 안보일 수 있어 실패의 위험이 커짐
• 프로젝트의 진행이 위험 분석에 크게 의존

 

적용

• 나중에 기능추가의 가능성이 많은 경우
• 품질향상

 

나선형(spiral) 모델

위험분석을 각 release마다(기능마다)

특징

• Incremental 진화 모델 + 위험분석 + etc
  • 반복 순환 단계
    • 계획 수립(planning): 목표, 기능 선택, 제약 조건의 결정
    • 위험 분석(risk analysis): 기능 선택의 우선순위, 위험요소의 분석 - 이때 계획, 요구분석을 끝내고 차선책 검토
    • 개발(engineering): 선택된 기능의 개발
    • 평가(evaluation): 개발 결과의 평가
    • 다음 단계의 planning
  • 위험관리가 있는것이 특징

 

장점

• 진화 모델의 장점
• 반복적인 개발 및 테스트 - 강인성 향상
• 한 사이클에 추가 못한 기능은 다음 단계에 추가 가능

단점

• 관리가 복잡
• 위험 분석을 잘못하여 지나친 경우 피해가 큼
• 성공 사례가 많이 알려지지 않음

적용

• 성능 문제, 기술 문제 등으로 실패할 수 있는 시스템의 개발
• 재정적 또는 기술적으로 위험 부담이 큰 경우
• 요구 사항이나 아키텍처 이해에 어려운 경우
  • 즉, 기술적 위험요소(비용 및 기간)가 크거나 난이도가 높은 SW 개발

 

Unified 프로세스

4번의 사이클 존재

도입(inception) = 요구사항 분석 중점

• 1, 2회 정도 반복으로 도입 단계를 진행
• 간단한 유스케이스 모델과 소프트웨어 구조, 프로젝트 계획을 작성

정련(elaboration) = 설계 중점

• 여러 번의 반복 과정으로 이루어짐
• 대부분의 유스케이스를 작성
• 아키텍처 설계

구축(construction) = 코딩 중점

• 남아 있는 유스케이스에 대하여 구현하고 통합
• 시스템을 목표 환경에 점증적으로 설치

전환(transition) = 테스팅 및 인수 중점

• 시스템을 배치, 사용자를 교육
• 베타 테스팅, 결함 수정, 기능 개선

형상 및 변경관리 : {소스코드 + 문서}(SW) + 버전 정보(configuration) = 형상(버전 release 마다 관리)

아키텍처 및 Usecase 중심으로 반복적/점진적 개발

각 프로세스 단계를 도입(Inception)/ 정련(elaboration)/구축(construction)/ 전환(transition) 단계로 구별

반복적/점진적 개발 -> 진화적 모델과 유사, but Release 출시는 아님

단계별로 중점이 다름(어느 사이클에서는 어떤걸 중점으로?)

• Inception: Usecase model, architecture, planning 에 집중
• Elaboration: Usecase 기반 UML 작성, 요구사항 분석, 아키텍쳐
• Construction: 개발에 집중(상세 설계 + 코딩)
• Transition: 시스템 배치에 집중(테스팅 + 배포) => 프로그램을 요구자에거 넘기고 문제 없는지 체크

규모가 큰 프로젝트에 적합

 

• 장점
  • 방법론과 프로세스가 잘 문서화 되어 있어 교육받기 좋음
  • 고객의 요구 변경과 관련된 리스크를 적극적으로 해결
  • 통합을 위한 노력과 시간을 줄일 수 있음
  • 쉽고 빠르게 코드를 재사용
• 단점
  • 프로세스가 너무 복잡, 이해하기 어렵고 정확히 적용하기가 어려움
  • 소프트웨어 프로젝트 참여자들의 협동, 의사소통에 대한 가이드가 없음
  • 조직화되지 않은 개발로 완전히 알려지지 않은 형태의 소프트웨어 개발로 이어질 수 있음

 

📌USECASE

• 사용 시나리오(요구사항 분석때 함)
  • UML
  • 시나리오 명세
  • 개발방법은 고려하지 않고 뭐를 누르면 뭐가 나오고 등등

 

📌진화모델과의 차이

• 진화모델 : 기능 완성의 목적
• Unified : SW 완성에 목적(아키텍쳐, Usecase 중심)

 

애자일(Agile) 프로세스

폭포수 프로세스의 단점 (고객의 변경요청 처리에 많은 시간과 비 용을 초래)을 해결

=> “짧은” 개발 사이클을 반복 (2~6주간의 짧은 주기)

=> 진화형 모델보다 더 짧은 개발 사이클이 필요

문서보다는 실행되는 소프트웨어에 더 큰 가치를 두고 있음

• 사용사례 또는 사용자 스토리나 피처 단위 (Usecase or Usestory 중심 개발)
• 테스트 중심 개발(Test Driven Development) - 기본 소스코드 + 테스트 코드 추가(품질저하 막기)

2~6주간의 짧은 주기로 개발을 반복

실행되는 소프트웨어를 개발하여 단계적으로 시스템 전체를 완성

 

애자일 선언

1) 형식적인 문서보다는 커뮤니케이션을 통하여 프로젝트가 목표를 향하여 나아가게 함
2) 사용자는 문서가 아니라 실행되는 소프트웨어를 통하여 요구를 확인
3) 사용자의 요구는 비즈니스 환경에 따라 프로젝트 중간에 바뀔 수 있음을 고려
4) 짧은 주기 동안 요구분석, 구현, 테스팅 단계 수행, 각 반복 주기의 개선 의견을 다음 계획에 포함

 

• Usecase
  • 기능하나(위 그림 기준 동그라미 하나)당 표와같은 Usecase 명세
  • 기능명, 사용자, 설명, 사전조건, 사후조건, 절차, 예외등을 명세
  • 내가 만드는 기능(system)이 아닌경우 user(actor)로 관리
• Userstory
  • 표의 한줄이 userstory
  • 하나의 함수를 만들기 위한 usecase(작은규모의)

 

익스트림 프로그래밍(XP)

사용자 스토리

매일 빌드와 통합 - 실행 파일 단위로 매일 관리

• 빌드 : 실행파일을 만드는 것

테스트 주도 개발(Test-Driven Development)

페어 프로그래밍 - 품질저하 막기, 놓친 버그를 막기위해 기능구현 개발자와 테스팅 개발자를 구분

 

프로젝트 관리 프로세스

• 비용과 품질 목표를 달성하기 위하여 프로젝트 관리하는 데 필요한 모든 작업
  • 계획, 모니터링과 제어, 분석
  • 각 단계별 산출물을 check => ok or 수정지시
  • 가장 긴 기간동안 이루어짐(개발 프로세스의 단계를 검증하기 때문에)

품질 보증 프로세스(품질이 유지되도록)

• 프로세스와 프로덕트에 대한 품질을 관리하고 향상시키는 것
  • 속도, 문서, 퀄리티, 기능완성도
• 인스펙션 프로세스 (검사 - 정적인 문서, 코드를 보며 분석)
  • 개발 결과에서 결함을 찾거나 방지하기 위한 노력
  • 정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사하는 것
• 프로세스 관리 프로세스에 포함

 

형상관리 프로세스(버전관리)

• 개발 중에 발생하는 변경을 체계적으로 컨트롤 하는 것
• 개발작업과 독립적인 작업(특정 도구의 힘을 빌림)
• 형상 관리 기능
  • 프로그램의 최신 버전 유지
  • 지정된 버전으로 되돌아 갈 수 있는 기능
  • 무허가 변경이나 삭제를 방지
    • checkin - checkout
    • locking(한명이 수정 시 다른사람이 접근 못하도록)
  • 현 시스템에 대한 모든 정보, 문서 등의 정보를 모아 보관
• 형상관리 메커니즘
  • 프로젝트에서 변경이 발생되었을 때 처리하는 시나리오를 다루는 메커니즘 을 제공
    • 형상 관리 대상 파악과 베이스라인 지정
    • 버전관리
    • 접근제어
  • 형상 관리 아이템의 생명 주기
  • 

핵심 : 버전관리, 접근제어(Check - in/out)

요구사항 => 설계 문서(거시적, 미시적) => 구현(code)

• 설계문서에 맞게 되었는지 형상관리에서 체크

방법론

• 프로세스 모델을 수행하는 것(추상화된 것을 수행하는 것)
• 프로세스 : 단계별 작업을 명시
• 방법론 : 단계별 작업을 어떻게 수행할지 정의(즉, 프로세스의 구현)

구조적 방법론

• Divide & Conquer 원리

객체지향 방법론

• SW 시스템 = 객체의 모임
• 객체간 메시지 교환을 통한 SW구현