• 검색 결과가 없습니다.

12장 소프트웨어 공학

N/A
N/A
Protected

Academic year: 2023

Share "12장 소프트웨어 공학"

Copied!
40
0
0

로드 중.... (전체 텍스트 보기)

전체 글

(1)

12장 소프트웨어 공학

컴퓨터공학 개론

(2)

학습 목표

응용을 개발할 때 소프트웨어 공학이 어떻게 이용되는지 배운다

몇 가지 서로 다른 소프트웨어 공학 프로세스 모델에 대해 배운다

설계 문서가 무엇인지와 이 문서가

소프트웨어 개발에 적용되는 방법을 배운다

응용의 생성 시 사용되는 설계 문서를

체계화하는 올바른 절차에 대해 경험해 본다

(3)

학습 목표 (계속)

UML(Unified Modeling Language)

다이어그램이 응용의 생성 시 청사진으로 사용되는 방법에 대해 배운다

소프트웨어 개발 시 접할 수 있는 함정에

대해 알아보고, 피하는 요령에 대해 배운다

응용의 개발 시 팀이 어떻게 활용될 수 있는지에 대한 이해를 구한다

(4)

소프트웨어 공학의 정의

소프트웨어 응용을 생산하는 프로세스

소스 코드와 데이터

UML 다이어그램과 화면 프로토타입

요구사항과 보고서

향후 개발 이슈

최종 사용자는 소프트웨어 개발을 지원하는 추진력

프로그램에 요구되는 기능을 결정한다

(5)

소프트웨어 개발 생명 주기(SDLC)

Software Development Life Cycle

프로그램의 개발, 테스트, 설치, 그리고 유지 관리 등에 걸친 모든 단계들을 포함하는

응용의 주기를 기술한다

SDLC의 요소들

프로젝트의 가능성 검증

소프트웨어 명세

소프트웨어 설계 및 구현

소프트웨어 유효성 검증 소프트웨어 진화

(6)

소프트웨어 개발 생명 주기(계속)

소프트웨어 개발 프로세스 모델

폭포수 모델

각 개발 단계의 결과가 다음 단계의 입력으로 이용된다

구축 수정 모델

시스템에 기능적이 될 때까지 개발자가 프로그램을 작성한 후에 계속해서 수정한다

신속한 프로토타이핑

최종 완결 전에 최종 사용자가 사용자

인터페이스의 프로토타입을 사용할 수 있도록 해주는 도구가 제공된다

(7)

소프트웨어 개발 생명 주기(계속)

소프트웨어 개발 프로세스 모델 (계속)

점진적 모델

일련의 소프트웨어가 출시되는 형태로 개발

나선형 모델

모든 기능이 완결될 때까지 폭포수 방식의 순환을 계속한다

Extreme programming (XP)

팀워크와 피드백을 강조한다

신속한 소프트웨어 개발

소프트웨어의 지속적인 공급과 수정을 통한 고객의 만족에 초점을 둔다

(8)

그림 12-1

“폭포수” 소프트웨어 개발 모델

(9)

설계 문서의 개발

설계 문서는 응용의 모든 설계 이슈들에 대한 자세한 사항들을 기술한다

이슈들에는 화면 배치, 색상, 보고서, 보안, 파일 경로, 온라인 도움말, 사용자 문서, 향후 계획

등이 포함된다

시스템의 청사진과 같은 역할

요구사항의 결정은 사용자와의 바람직한 커뮤니케이션에 달려있다

(10)

그림 12-2

설계 문서의 생성 과정

(11)

1 단계-현재 시스템과 요구사항의 파악

사례 연구: 음악 상점의 매체 제고 관리

초기 작업은 최종 사용자(음악 상점 사장)의 요구사항과 목표를 설정하는 일이다

고객이 바라는 내용을 보고서로 작성해달라고 부탁한다

고객이 알려주는 정보를 문서화하라

필요하다면 지속적으로 정보를 캐내야 한다

목표, 서론, 세부 명세, 요구 사항들을 기록하라

(12)

그림 12-3

프로젝트의 서론, 세부 명세 및 요구사항을 포함하는 설계 문서

(13)

2단계 – UML 다이어그램의 생성

UML(Unified Modeling Language)는

개발자들에게 시스템 기능에 대한 청사진을 보여 준다

고객과 개발자가 커뮤니케이션하는 방법을 제공

소스 코드를 작성하기 이전에 시각적인 다이어그램이 생성된다

마이크로소프트사의 비지오(Visio)와 같은 도구들이 UML 다이러그램을 생성하는데 이용될 수 있다

(14)

그림 12-4

마이크로소프트의 Visio를 이용한 UML 다이어그램 생성

(15)

UML 다이어그램의 타입

클래스(Class)

여러 객체 클래스들이 서로 어떻게 연관되는지 보여준다

객체(Object)

클래스에서 생성된 객체의 세부사항들을 정의

유즈 케이스(Use case)

사용자 측면에서 시스템의 행위들을 설명

(16)

UML 다이어그램의 타입(계속)

상태(State)

주어진 시간에 객체의 특정 상태를 보여준다

시퀀스(Sequence)

서로 다른 클래스들이 메시지를

주고받음으로써 통신하는 방법을 보여준다

활동(Activity)

유즈 케이스나 객체의 행동 내에서 발생하는 활동들을 보여준다

(17)

UML 다이어그램의 타입(계속)

협력(Collaboration)

시스템 요소들이 시스템의 목표를 달성하기 위해서 함께 작업하는 모습을 보여준다

컴포넌트(Component)

시스템 요소들이 서로 어떻게 연관되는지 보여준다

전개(Deployment)

컴퓨터 기반 시스템의 물리적인 구조를 보여준다

(18)

그림 12-5

음악 재고관리 응용을 위한 유즈 케이스 다이어그램

(19)

그림 12-6

(20)

그림 12-7

음악 재고관리 응용을 위한 시퀀스 다이어그램

(21)

3단계: 데이터 사전의 생성

데이터베이스가 필요하다면, 데이터 사전을 생성하라

프로그램 내에서 사용되는 데이터의 유형을 설명하는 문서

테이블 정의, 인덱스, 그 외 데이터의 관계들을 보여준다

사용자로부터 수집한 정보들을 이용하여 현재

시스템을 파악하고 새로운 응용에 대한 개략적인 계획을 수립하라

최종 사용자가 제공한 보고서들을 검토하여 테이블과 요소들을 파악하라

(22)

그림 12-8

데이터 사전의 생성

(23)

4단계: 보고서의 설계

보고서를 설계할 때 사용자의 도움을 받아라

데이터 사전을 점검하라

통합 개발 환경(IDE)을 이용하라

보고서의 프로토타입을 사용자와 함께 상호적으로 생성하기 위해 통합개발환경 안에 포함된 보고서 도구들을 사용하라

(24)

그림 12-9

보고서 생성기로 생성된 보고서의 예

(25)

5단계: 응용의 논리 흐름의 구조화

소스 코드 작성을 시작하기 전에 응용의 논리 흐름을 생성하라

순서도(Flowcharts)

프로세스를 시각적으로 표현하는 기호들과 텍스트의 집합

의사코드(Pseudocode)

시스템의 주요 기능과 서로 다른

작업들간의 관계들에 대한 자세한 정의를 생성해야만 한다

(26)

그림 12-10 순서도의 예

(27)
(28)

6단계: 프로토타입 구축의 시작

프로토타입: 최종 사용자에게 향후 응용이

완성되었을 때 보게 될 것에 대한 아이디어를 줄 수 있는 표준적인 예제

프로그램의 주요기능을 충분히 이해할 만큼 최종 사용자에게 최대한 많은 질문을 하라

프로젝트 명세가 승인되기 전에는 소스 코드를 작성하지 말아라

화면을 설계할 때 사용자를 참여시키라

시작 화면은 고객의 목적과 프로그램의 주요 기능을 상기시켜줄 수 있어야 한다

(29)

7단계: 모든 결과물의 종합

수집한 모든 정보들을 바탕으로 설계 문서를 생성하라

제품의 완성일이나 예상 비용은 현실적으로 정하라

설계 문서에 사용자가 서명하도록 하여 그들이 프로젝트 범위에서 정해진 최종 인도일에

동의하도록 하여야 한다

설계 문서에 대한 변경이 필요하면 새로운 요소를 설명하는 추가부분을 생성하라

(30)

7단계: 모든 결과물의 종합 (계속)

설계 문서는 다음과 같은 요소들을 포함하여야 한다:

제목 페이지, 목표, 용어 설명

실현 가능성 연구, 명세서, 요구사항, 비용 분석

데이터 사전 및 시각적인 다이어그램

화면 및 보고서의 사본

테스트와 사용자 피드백 수집 계획

회의 일지

(31)

함정의 회피

사용자 기피증

최종 사용자가 설계에 참여하면 응용이 실패하게 될 것이라 생각하는 일종의 두려움

해결방법: 대화를 개방적으로 지속하라

과도한 작업

“작업 부풀리기” 신드롬

해결방법: 관리자에게 정직하고 단호하게 설명하라

범위 확대

시스템에 대한 지속적인 변화와 수정 해결방법: 단계적인 개발 방식

(32)

프로젝트 개발 팀

프로젝트 관리자

적임자를 적재적소에 배치하는 책임을 맡은 사람

프로젝트의 위험부담과 비용, 작업 스케줄을 결정

설계 문서 통합

데이터베이스 생성자 (데이터베이스 관리자)

데이터베이스 구조를 생성하고 관리하는 역할을 맡은 사람

(33)

그림 12-12

(34)

프로젝트 개발 팀 (계속)

개발자 (프로그래머)

최종 사용자의 기능적인 요구사항을 만족시키기 위하여 소스코드를 작성하는 책임을 맡은 사람

고객 (최종 사용자)

프로젝트의 보이지 않는 추진 세력

테스터

프로그램의 기능들이 정확한지, 그리고 설계 문서에서 명시된 기능적인 요구사항들을 모두 충족시키는지를 확인하는 책임을 맡은 사람

모든 가능한 상황에 대해 검사하고 발생한 에러들에 대해 로그 기록을 남겨라

(35)

프로젝트 개발 팀 (계속)

고객 관계 담당자

제품의 생산 및 출시 초기에 테스터, 개발자, 최종 사용자들 사이의 인터페이스 역할을 하는 사람

응용 CD 생성자

필요한 모든 파일들이 디스크에 담겨지도록 개발자와 인터페이스하는 사람

응용 디스크 설치자

최종 사용자의 기계에 디스크를 설치하고 응용을 사용하는 방법을 안내하는 사람

(36)

맺는 말

좋은 설계가 좋은 프로그램을 낳는다

일부 단계를 생략하는 것은 낮은 성능이나 고객의 불만을 야기시키거나 프로젝트가 예산이나 시간을 초과하게 만든다

프로젝트 관리자의 주된 임무는 협조가 잘될 수 있는 팀을 구성하는 것이고, 프로젝트를 주어진 시간과 예산의 범위에서 완수하는 것이다.

완전한 테스트 과정을 포함시켜라

(37)

요약

소프트웨어 공학은 최종 사용자의 요구를 충족시키는 응용을 개발할 때 따를 수 있는 많은 단계들을 포함한다

응용을 구축하는 프로세스는 소프트웨어 개발 생명 주기(SDLC) 프로세스를 구현함으로써

수행된다

각각의 SDLC는 소프트웨어 제품을 생성하는 단계들을 구체화하는 많은 방법을 제공한다

(38)

요약 (계속)

설계 문서는 소프트웨어 개발을 위해 청사진 역할을 한다

설계 문서를 생성하는 단계는 다음과 같다 :

최종 사용자의 요구사항 분석, 대화, 화면, 보고서, 데이터 구조의 논리적인 설계 등.

UML은 개발자들과 최종 사용자가 시스템의 기능을 시각적으로 설계할 수 있게

도와주는 도구이다

(39)

요약 (계속)

UML 다이어그램에는 여러 가지 유형이 있는데, 각각은 특수한 목적 또는 개발될 시스템의 한 부분을 설명하기 위해 사용된다

보고서와 데이터 사전을 이용하면 개발자들이 시스템의 설계 단계에 존재할 수 있는 “헛점”을 평가할 수 있게 해준다

소프트웨어 개발은 보통 팀 작업으로 이루어진다

팀원에는 프로젝트 관리자, 데이터베이스 관리자,

개발자/프로그래머, 고객/최종 사용자, 테스터, 그리고 때로는 고객 관계 담당자 등을 포함한다

(40)

요약 (계속)

응용이 개발되면, 설치 디스크를 생성하여야 한다

시스템이 고객의 시스템에 설치된 후에는 향후 다른 사용자들을 훈련할 초기

사용자들을 훈련하는데 시간을 투자해야 한다

참조

관련 문서

• 사용자의 인지나 허락없이 실행되도록 하기 위해 다른 소프트웨어나 데이터 파일에 첨부시키는 악성 소프트웨어

– 협업활동을 지원하기 위한 기능과 서비스로 문서작성, 논평, 정보공유, 화상회의, 일정관리, 이메일 및 네트워크 기반의 협업 지원 소프트웨어

z 프로그램 + 프로그램의 개발, 운용, 보수에 필요한 정보 일체(소프트웨어 생산 결과물 일체).

정보 시스템 사용자로부터 정보를 입수하고, 이를 가공하여 저장하고 적 절한 양식으로 사용자에게 출력하는 작업이 주인 시스템이 다.. 각종 공공 기관, 금융기관, 회사에서

③ 과업심의위원회는 별표 1 소프트웨어 개발사업의 적정 사업기간 산정기준에 따라 적정 사업기간을 산정하고 별지 제3호서식 소프트웨어 개발사업의 적정 사업기간

소프트웨어 업그레이드는 http://www.comfile.co.kr/download.html 방문하셔서 PIC TOOL 관련 소프트웨어 및 사용설명서 다운로드에서 다운 받을 수

 시스템 소프트웨어는 컴퓨터 하드웨어의 작동을 통제하고 응용 프로그램의 실행을 지원한다.  운영체제는 컴퓨터 하드웨어를 통제하고

실용 연구자: 실생활에 적용가능한 소프트웨어 개발.B. 소프트웨어 수요는