1. 소프트웨어 공학 개요 - 문경숙

 

 

 

[TOPCIT 목차]

 

목표:
(1) SW 특성, 문제점 설명
(2) SW 공학 배경, 목적 설명
(3) SW 개발 프로세스 모델 설명

핵심키워드:
(1) SW 특성
(2) SW 생명주기
(3) SW 요구관리, 유지관리, 형상관리, 품질관리

1 소프트웨어 공학의 배경과 목적
가) 소프트웨어 공학 소개
소프트웨어공학: sw성공개발위해 전과정  관리와 업무 수행을 지원해 주는 기술

나) 소프트웨어 공학 배경
1950년대: 도입시작
1960년대: SW 수요급증, 인력, 경험, 능력, 수적인 부족으로 인한 위기 발생하면서 본적격적으로 SW 공학도입
1970년대: 선코딩, 후수정 접근방식, 폭포수모델 개발, 사용시작
1980년대: 개발생산성을 높이기 위한 방법연구
1990년대: 동시공학 집중한 모델 활용
2000년대: 애자일 방법론 본격도입

다) 소프트웨어 공학의 4가지 중요요소
소프트웨어 공학정의 : 소프트웨어의 개발, 운용, 유지보수 등의 생명주기 전반을 체계적이고 서술적이며 정량적으로 다루는 학문
목적: 고품질의 소프트웨어를 생산하고 주어진 비용과 일정에 딜리버리

(1) 방법:
-. 프로젝트 계획 수립과 추정, 시스템과 소프트웨어 분석, 자료구조, 프로그램 구조, 알고리즘 코딩, 테스팅, 유지 관리과 같은 작업들로 구성
-. 종종 특수한 언어중심 (예: 객체지향방법) 또는 그래프 표기법을 도입
-. 소프트웨어 품질에 대한 일련의 평가 기준을 도입

(2) 도구:
-. 어떤 일을 수행할 때 생산성 혹은 일관성을 목적으로 사용하는 방법들을 자동화나 반자동화시켜 놓은 것
-. 소프트웨어 개발 생명주기 상 수많은 도구(예: 요구관리도구, 모델링 도구, 형상관리 도구, 변경관리 도구)가 존재
-. 도구들이 통합되어 하나의 도구가 생성한 정보를 다른 도구가 사용할 수 있을 때, 소프트웨어 개발을 지원하는 시스템으로 설정

(3) 절차
-. 절차는 방법과 도구를 결합하여, 그것으로 하여금 소프트웨어를 합리적이고 적시에 개발할 수 있도록 함
-. 절차는 적용된 방법들, 요구되는 결과물(문서, 보고서 등) 품질을 보증하고 변경을 조정하게 도와주는 제어들 그리고 소프트웨어 관리자들이 진행을 평가하게 해주는 마일스톤 등의 순서를 정의함

(4) 사람
-. 소프트웨어 공학에서는 많은 것(수립, 개선, 유지 등)들이 사람과 조직에 의해서 움직이기 때문에 사람에 대한 의존성이 상대적으로 큼
-. 다른 공학의 상황보다 훨씬 다양한 이슈들이 생기기 때문에 소프트웨어 개발을 일목요연하게 공학적으로 정리한다는 것은 현실적으로 불가능

2 소프트웨어 개발 생명주기
가) 정의
-. 사용자 환경 및 문제점 이해에서 시작, 운용, 유지보수에 이르기까지의 모든 과정
-. 구성 : 타당성 검토 -> 개발계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수

나) 목적
-. 프로젝트 비용 산정과 개발 계획 수립, 기본 골격 구성
-. 용어의 표준화
-. 프로젝트 관리

다) 소프트웨어 생명주기 선정
-. 프로젝트 개발 프로세스 테일러링 위한 중요 활동
-. 시스템 개발의 리스트와 불확실성에 대한 이해바탕 수행
-. 리스크/불확실성 최소화하는 모델 선택
-. 폭포수 모델, 프로토타입 모델, 진화 모델, 점증적 모델등이 있음

라) 소프트웨어 생명주기 모델 종류
(1) V 모델
-. 프로젝트에 적용, 관리하기 용이
-. 요구사항이 명확할때 이상적인 생명주기 모델
-. 개발활동의 시작, 종료조건, 관리척도 명확히 정의
-. 검증 및 확인 강조, 개발활동과 테스트 활동 병행
-. 테스트를 통해 결함 발견시 재수행 필요 단계 파악가능

(2) VP 모델(V model with Protytyping)
-. 시스템 이해, 리스크, 불확실성요소 등의 이슈 해결위해 빠르게 개발하는 방법
-. 개발자와 고객이 요구사항에 대한 공통적인 이해 도출가능
-. 폭포수 모델이나 V 모델의 개발 단계에 적용가능, 독립적인 모델로 사용가능
-. 리스크: 요구사항 구현가능성, 시스템 성능 검증 여부, 새로운 도구 구입 외주 개발 시스템 위험요소 등
-. 접근 방법1: 불확실 요소 정의 -> 해결책, 적용방법 정의 -> 해결책 적용(반복가능)-> 불확실성 원인 파악
-. 접근 방법2: 불확실 요소 정의 -> 해결책 나열, 선택기준 정의 -> 기준에 따라 해결책 평가 -> 최적의 해결책 선택

(3) 점증적 모델
-. 시스템 개발 시간을 줄일 필요가 있을 때 유용
-. 핵심 부분 먼저 개발하여 동작확인후 나머지 기능 구현하는 방식
-. 기능확장을 통해 시스템 개발, 마지막 버전은 모든 기능이 구현된 시스템
-. 초기 외부 인터페이스 리스크 감소에 유용
-. 각 기능 확장 개발 단계 요구사항이 명확하여 V, VP 모두 적용 가능

(4) 진화모델
-. 시스템 개발 시간을 줄일 필요가 있을 때 유용
-. 전체 시스템에 대한 개발 단계가 여러번 반복됨(기능이 점차 확장되는 점증적모델과 차이)
-. 시스템 명세가 불분명한 경우나 제품 개선이 지속적으로 요구되는 경우 적합
-. 개발 기간 단축, 시스템 조기 사용, 경쟁력 강화
-. 시스템 문제 도출 및 조기 수정 가능
-. 전문 분야별 나누어서 개발 가능( 예 텍스트기반, 그래픽 기반)

3 소프트웨어 개발 방법론
가) 소프트웨어 개발 방법론의 필요성
(1) 개발 경험의 축적 및 재활용을 통한 개발생산성 향상
(2) 효과적인 프로젝트 관리
(3) 공식 절차와 산출물을 제시하고 표준 용어를 통일하여 의사소통 수단 제공
(4) 각 단계별 검증과 승인된 종료를 통해 일정 수준의 품질 보증

나) 소프트웨어 개발 방법론 비교

구분	구조적 방법론	정보공학 방법론	객체 지향 방법론	CBD 방법론
개요	업무 활동 중심의 방법론	데이터 중심의 방법론	객체 클래스 간의 관계를 식별하여 설계 모델로 변환하는 방법론	재사용이 가능한 컴포넌트의 개발/상용 컴포넌트들을 조합하는 방법론
기본원리	•추상화 •구조화 •단계적 상세화 •모듈화	•정보전략계획 •업무 영역 분석 •업무시스템 설계 •시스템 구축	•요건정의 •객체지향분석(객체모델링, 동적모델링, 기능모델링) •객체지향설계 •테스트/배포	•요구분석 •분석(아키텍쳐정의, 유스케이스모델링) •설계 •개발 •구현(릴리스,교육)
특징	•분할과 정복의 원칙 •프로그램 로직 중심 •컨트롤 가능한 모듈로 구조화	•기업업무 지원시스템 지원방법론 •데이터모델 중시 •프로그램 로직은 데이터 구조에 종속(CRUD) •전사적 통합데이터 모델	•프로그램 단위는 객체 •데이터와 로직 통합 •고도의 모듈화 •상속에 의한 재사용 분석 •설계간 갭(gap) 없음	•객체방법론의 진화 •인터페이스 중시 •인터페이스의 구현은 컴포넌트 •블랙박스 재사용 지향
주요 산출물	•도메인분석서 •데이터흐름도 •구조도 •프로그램사양서	•도메인분석서 •ERD •기능차트 •어플리케이션구조도 •프로그램 사양서 •테이블정의서/목록	•비즈프로세스/개념도 •다이어그램(유스케이스, 시퀀스, 클라스, 컴포넌트 등)	•비즈프로세스/개념도 •다이어그램(유스케이스, 시퀀스, 클라스, 컴포넌트 등) •재사용계획서 •.Net, EJB
지원도구	•Teamwork, SA	•Cool Gen, SA	•Rose, SA, Palstic	•Cool Joe, Together
주요지원언어	•COBOL, C, VB, PASCAL	•COBOL, C, VB, PASCAL	•C++, Java, VB	•원칙적으로 개발언어 무관

다) 소프트웨어 개발 단계
(1) 요구사항 분석 : 초기 사용자 요구 이해 통한 요구사항을 명확히 정의시 기간, 비용 초과, 품질 저하 방지 가능
(2) 설계: 시스템 구조 결정, 물리적 실현의 첫 단계. 설계는 품질, 안정감있는 시스템, 유지보수에 영향 미침
(3) 구현: 설계를 구현, 코딩 표준 정의, 명확하게 코딩 작성하는 것 필요
(4) 테스팅: 요구사항 만족 여부, 예상과 실제 차이를 검사하고 평가하는 과정, 소프트웨어 품질 보증 단계

4 애자일 개발 방법론
가) 애자일 방법론 종류
-. 스크럼(Scrum), 켄 슈와버/제프 서덜랜드
-. 익스트림 프로그래밍(eXtreme Programming, XP), 켄트 벡/에릭 감마
-.린(Lean) 소프트웨어 개발방법론, 메리 포펜딕/톰 포펜딕
-. 애자일 UP(Agile Unified Process, AUP), 스콧 엠블러

나) 애자일 개발 방법론-XP
(1) XP 개요: 테스트주도개발, 일일빌드, 지속적인 통합 등과 연관, 가치와 실천법, 균형위한 원칙 필요

(2) 개발절차 및 용어

-. 유저스토리: 요구사항, 의사소통도구, 기능단위의 필요한 내용 간단 기재
-. 스파이크: 요구사항이나 잠재 솔루션 고려 간단 프로그램
-. 릴리즈계획: 하나의 반복 1~3주로 나눈 전체 프로젝트 배포계획
-. 승인테스트: 인수테스트, 고객수행
-. 작은 릴리즈: 소규모 수차례 배포

(3) XP 가치:
-. 의사소통: 팀빌딩 강화필요
-. 단순성: 불필요한 복잡성 제거
-. 피드백: 팀내 최대한 빨리, 최대한 많은 피드백
-. 용기: 요구사항, 기술변경에 용감하게 대처
-. 존중: 팀원 존중 필요

(4) XP 실천 방법

구분	실천방법	설명
개발	단순한 설계(Simple Design)	가능한 단순하게 설계
	테스트 기반 개발	코드 작성전 테스트케이스 작성, 테스트 도구 사용 자동화
	리팩토링	코드의 중복과 복잡성 제거, 기존 코드의 디자인 향상
	코딩 표준	효과적인 의사소통을 위해 코딩표준 준수
	짝 프로그래밍	두명의 개발자가 소스코드에 대해 공동책임,
	지속적인 통합	작업이 끝날 통합 작업 수행
관리	계획게임	프로젝트 전체 계획과 주기 계획을 비즈니스와 기술측면 고려하여 세우고 실행과 피드백을 통해 업데이트 유지
	작은 릴리즈	실행가능 모듈 가능한 빨리 배포, 고객이 수시로 SW 확인하게 하라
	메타포	시스테에 대한 전체 모습을 이해하기 쉬운 그림과 스토리로 표현하라
환경	주당 40시간 작업	품질의 유지를 위해 주40시간 이상 일하지 마라
	현장 고객	실제 시스템을 사용한 고객이 개발 현장에 상주하게 하라

다) 스크럼( SCRUM)
(1) 스크럼 개요
추정 및 조정 기반의 경험적 관리기법의 대표적 형태
[스크럼 역할자 유형]

역할	업무
제품책임자 (Product Owner)	제품 백로그 생성, 우선순위 조정, 새로운 항목 추가 스프린트 계획수립시는 핵심역할, 스프린트 시작후 팀의 운영에 관여하지 않음
스크럼 마스터 (Scrum Master)	팀의 업무 방해 요소 제거 원칙과 가치를 지키면서 팀개발 진행 지원
스크럼 팀 (Scrum Team)	5~9명 구성, 사용자 스토리를 사용하여 스프린트 개발 동안 개발

(2) 스크럼 프로세스
-. 스프린트: 달력기준 1~4주 단위 반복개발기간
-. 3가지 미팅: 일일 스크럼, 스프린트 계획, 스프린트 리뷰
-. 3가지 산출물: 제품 백로그, 스프린트 백로그, 소멸챠트

[스크럼 프로세스 3가지 산출물]

역할	설명
제품 백로그	제품에 담고자 하는 기능의 우선순위를 정리한 목록 제품 백로그에 정의된 기능은 “사용자 스토리” 사용자 업무량에 대한 추정은 “스토리 포인트”라는 기준 이용
스프린트 백로그	하나의 스프린트 동안 개발할 목록 과업: 사용자 스토리와 이를 완료하기 위한 작업 과업의 크기는 시간단위로 추정
소멸챠트	개발을 완료하기까지 남은 작업량을 보여주는 그래프 스토리포인트 : 각 iteration별 남아있는 작업량

[스크럼 프로세스 3가지 미팅]

미팅	설명
스프린트 계획	스프린트 목표, 스프린트 진행항목 선택, 담당자 배정, 태스크 단위 계획 수립
일일 스크럼	매일 15분간의 프로젝트 진행상호아 공유 회의, 팀원이 한일, 할일, 문제점 이야기
스프린트 리뷰	작업진행과 결과물을 확인하는 회의, 작업결과 데모, 피드백, 고객참여가능, 스크럼 마스터는 잘된점, 아쉬운점, 개선점 찾는 회고 진행가능

(3) 스크럼 특징
-. 투명성: 회의, 소멸챠드, 리뷰 통해 프로젝트 상태, 문제점 파악가능
-. 타임박싱: 시간제한으로 프로젝트 진행 집중 가능, 일일스크럼 15분 진행, 스프린트 리뷰 매이터테이션마다 진행
-. 커뮤니케이션: 문제점 공유, 플래닝 포커로 사용자 스토리 구현난이도, 시간 토론
-. 경험주의 모델: 기본적인 구조 동일, 팀마다 달라지는 것 인정, 개개인의 경험 중시