[ 정보처리기사 실기 요약 ] 1. 요구사항 확인

( 1 ) 소프트웨어 생명주기 (SLC ; Software Life Cycle)

    · 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것

    · 소프트웨어 개발 단계와 각 단계별 주요 활동과 활동의 결과에 대한 산출물로 표현한다.

 

 

  ☁ 폭포수 모형 (Waterfall Model, 고전적 생명 주기 모형)

     · 각 단계를 확실히 마무리 지은 후, 다음 단계를 진행하는 개발 방법론

     · 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 한다.

 

 

☁ 프로토타입 모형 (Prototype Model, 원형 모형)

     · 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형

 

 

☁ 나선형 모형 (Spiral Model, 점진적 모형)

     · 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형

     · 보헴(Boehm) 제안

     · 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형

 

      ◽ 4가지 주요 활동 (계위개고)

          계획 수립 ➡ 위험 분석 ➡ 개발 및 검증 ➡ 고객 평가

 

 

☁ 애자일 모형 (Agile Model)

     · 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형

     · 폭포수 모형과 대조적

     · 특정 개발 방법론이 아닌 고객과의 소통에 초점을 맞춘 방법론

 

    ◽ 핵심 가치

         1 ) 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.

         2 ) 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.

         3 ) 계약 협상보다는 고객과의 협업에 더 가치를 둔다.

         4 ) 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둔다.

 

    ◽ 대표적인 개발 모형

         · 스크럼 (Scrum)

              ▫ 팀이 중심이 되어 개발의 효율을 높이는 기법

              ▫ 스크럼을 진행할 때는 "계획하여 진행(Sprint)한 후 회의와 검토를 거쳐 회고한다."

 

              ▫ 팀 구성

                    - PO (Product Owner, 제품 책임자)  :  요구사항이 담긴 백로그를 작성하는 주체

                    - SM (Scrum Master, 스크럼 마스터) : 스크럼 팀의 가이드 역할

                    - DT (Development Team, 개발팀) : 제품 책임자와 스크럼 마스터를 제외한 모든 팀원, 제품의 개발을 수행

 

              ▫ 과정

                    제품 백로깅(Product Backlog) ➡ 스프린트(Sprint) 계획 회의 ➡ 스프린트 수행(개발) ➡ 검토 ➡ 회고 

 

                      * 스프린트 계획 회의

                               · 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의

                      * 스프린트

                               · 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행함

                      * 일일 스크럼 회의

                               · 모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 상황을 점검하는 회의, 남은 작업 시간은 소멸 차트에 표시함

                      * 스프린트 검토 회의

                               · 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는 지 테스팅하는 회의

                      * 스프린트 회고

                               · 정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것

 

         · XP (eXtreme Programming)

              ▫ 고객의 참여와 개발 과정의 반복을 극대화하여 생산성을 확대

              ▫ "계획하고 진행(Iteration)한 후 검사하고 출시(Release)한다."

 

              ▫ 5가지 핵심 가치 (용단의 피존)

                      1 ) 용기 (Courage)

                      2 ) 단순성 (Simplicity)

                      3 ) 의사소통 (Communication)

                      4 ) 피드백 (Feedback)

                      5 ) 존중 (Respect) 

 

              ▫ Process

                    릴리즈 계획 수립(Release Planing) ➡ Iteration(= 주기) ➡ 승인 검사(Acceptance Test, 인수 테스트) ➡ 소규모 릴리즈(Small Release)

 

                      * 릴리즈 계획 수립
                               · 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것
                               · 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 함.

                      * 이터레이션(=주기)
                               · 실제 개발 작업을 진행하는 과정으로, 보통 1~3주 정도의 기간으로 진행됨

                      * 승인 검사(=인수 테스트)
                               · 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트

                      * 소규모 릴리즈
                               · 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것

 

              ▫ 주요 실천 방법

                    1 ) 짝 프로그래밍 (Pair Programming) : 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경 조성

                    2 ) 공동 코드 소유 (Collective Ownership) : 개발 코드에 대한 권한과 책임을 공동으로 소유함

                    3 ) 테스트 주도 개발 (Test-Driven Development) : 실제 코드 작성 전 테스트 케이스 먼저 작성 ➡ 자신이 무엇을 해야할 지를 정확히 파악

                    4 ) 전체 팀 (Whole Team) : 개발 참여 모든 구성원들(고객 포함)은 각자의 역할이 있고 그 역할에 대한 책임을 가져야 함

                    5 ) 지속적인 통합 (CI ; Continuous Integration) :  모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합됨

                    6 ) 리팩토링 (Refactoring) : 프로그램 기능의 변경 없이 시스템을 재구성 (중복제거, 단순화 등)

                           ➡ 목적 : 프로그램을 쉽게 이해하고 수정하여 빠르게 개발할 수 있도록 하기 위함

                    7 ) 소규모 릴리즈 (Small Release) : 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응

 

         · 칸반 (Kanban)

         · Lean

             ◽ 7가지 원칙 (낭품지 확인사전)

                  1 ) 낭비 제거

                  2 ) 품질 내재화

                  3 ) 지식 창출

                  4 ) 늦은 확정

                  5 ) 빠른 인도

                  6 ) 사람 존중

                  7 ) 전체 최적화

 

         · 기능 중심 개발 (FDD; Feature Driven Development)

 

☁ 소프트웨어 공학 (SE ; Software Engineering)

     · 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문

     · 여러가지 방법론과 도구, 관리 기법들을 통해 소프트웨어의 품질과 생산성 향상을 목적으로 함

 

     ◽ 소프트웨어 공학(SE)의 기본 원칙

         · 현대적인 프로그래밍 기술을 계속적으로 적용해야 함

         · 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 함

         · 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 함

 

( 2 ) 현행 시스템 파악

    ◽ 절차 (구기인 아소 하네)

프로세스	현행 시스템	내용
1단계	시스템 구성 파악	조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술함
	시스템 기능 파악	현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시
	시스템 인터페이스 파악	단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시
2단계	아키텍처 구성 파악	최상위 수준에서 계층별로 표현한 아키텍처 구성도를 작성함
	소프트웨어 구성 파악	소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시함
3단계	하드웨어 구성 파악	단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 서버의 이중화 적용 여부를 명시
	네트워크 구성 파악	서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성함

 

💡 서버의 이중화

운용 서버에 장애가 발생했을 때 대기 서버에서 서비스를 계속 유지할 수 있도록 운용 서버의 자료 변경이 대기 서버에도 동일하게 복제되도록 관리하는 것

( 3 ) 개발 기술 환경 파악

☁ 운영체제 (OS ; Operating System)

     · 컴퓨터 시스템의 자원을 효율적으로 관리

     · 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어

 

     ◽ 운영체제 관련 요구사항 식별 시 고려사항 (가성기구주)

          · 가용성

          · 성능

          · 기술 지원

          · 구축 비용

          · 주변 기기

 

☁ 데이터베이스 관리 시스템(DBMS ; DataBase Management System)

     · 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해주는 소프트웨어

 

     ◽ DBMS 관련 요구사항 식별 시 고려사항 (가성기구호)

          · 가용성

          · 성능

          · 기술 지원

          · 구축 비용

          · 상호 호환성

 

☁ 웹 애플리케이션 서버 (WAS ; Web Application Server)

     · 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어(Middelware)

     · 서버 사이에서 인터페이스 역할을 수행

     · 데이터 접군, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공

     · 데이터베이스 서버와 연동하여 사용

 

     ◽ WAS 관련 요구사항 식별 시 고려사항 (가성기구)

          · 가용성

          · 성능

          · 기술 지원

          · 구축 비용

 

☁ 오픈 소스 (Open Source)

          · 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어

          · 오픈 소스 라이선스를 만족한다.

 

     ◽ 오픈소스 고려사항

          · 라이선스의 종류

          · 사용자 수

          · 기술의 지속 가능성

 

 

( 4 ) 요구사항 정의

☁  요구사항

     · 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약 조건

 

    ◽ 기능 요구사항 (Functional Requirements)

          · 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행에 관련된 요구사항

          · 시스템의 I/O(입출력)으로 무엇이 포함되어야 하는지에 대한 사항

          · 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항

          · 시스템이 반드시 수행해야 하는 기능

          · 사용자가 시스템을 통해 제공받기를 원하는 기능

          💡 ex ) "사용자는 회원 ID와 PW를 입력하여 로그인할 수 있다."

 

    ◽ 비기능 요구사항 (Non-Functional Requirements)

          · 품질이나 제약사항과 관련된 요구사항

          · 시스템 장비 구성 요구사항

          · 성능 요구사항

          · 인터페이스 요구사항

          · 데이터를 구축하기 위해 필요한 요구사항

          · 테스트 요구사항

          · 보안 요구사항

          · 품질 요구사항

                 1 ) 가용성

                 2 ) 정합성

                 3 ) 상호 호환성

                 4 ) 대응성

                 5 ) 이식성

                 6 ) 확장성

                 7 ) 보안성

          · 제약사항

          · 프로젝트 관리 요구사항

          · 프로젝트 자원 요구사항

          💡 ex ) "시스템은 1년 365일, 하루 24시간 운용이 가능해야 한다."

 

    ◽ 사용자 요구사항 (User Requirements)

          · 사용자 관점에서 본 시스템이 제공해야 할 요구사항

          · 사용자를 위한 것으로, 친숙한 표현으로 이해하기 쉽게 작성된다.

 

    ◽ 시스템 요구사항 (System Requirements)

          · 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

          · 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현된다.

          · 소프트웨어 요구사항이라고도 한다.

 

 

( 5 ) 요구사항 개발 프로세스

☁  요구사항 개발 프로세스 (도분명확)

     · 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동

     · 요구사항 개발 프로세스가 진행되기 전에 타당성 조사(Feasibility Study)가 선행되어야 한다.

     · 요구사항 개발은 요구공학(Requirement Engineering)의 한 요소이다.

[도분명확]

 

◽ 요구사항 도출(Requirement Elicitation, 요구사항 수집)

     · 시스템, 사용자, 개발자 등 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정

     · 개발자와 고객 사이의 관계가 만들어지고 이해관계자(Stakeholder)가 식별된다. 

     · 소프트웨어 개발 생명 주기(SDLC) 동안 지속적으로 반복된다.

     · 요구사항을 도출하는 주요 기법

          1 ) 청취와 인터뷰

          2 ) 설문

          3 ) 브레인스토밍(Brain Storming) : 3인 이상이 자유롭게 의견을 교환하면서 독창적인 아이디어를 도출해내는 방법

          4 ) 워크샵(Workshop)

          5 ) 프로토타이핑(Prototyping)

                  - 프로토타입 (Prototype, 견본품)을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출하는 작업

                  - 가장 단순한 형태 : 설명을 위해 종이에 대략적인 순서 형태를 그려 보여주는 것

          6 ) 유스케이스(Use Case) : 사용자의 요구사항을 기능 단위로 표현하는 것

 

 

◽ 요구사항 분석 (Requirement Analysis)

     · 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정

     · 요구 사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정

     · 서로 상충되는 요구사항이 있으면 이를 중재하는 과정

 

     · 소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동

     · 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.

     · 사용자의 요구를 정확하게 추출하여 목표를 정한다.

 

     ▫ 요구사항 분석에 사용되는 대표적인 도구

            - 자료 흐름도(DFD ; Data Flow Diagram)

            - 자료 사전 (DD ; Data Dictionary)

 

     ▫ 구조적 분석 기법

             · 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법

             · 도형 중심의 분석용 도구, 하향식 방법 사용(시스템을 세분화할 수 있음), 분석의 중복을 배제할 수 있음

 

             · 구조적 분석 기법 도구

                    1 ) 자료 흐름도 (DFD, = 버블 차트, 자료 흐름 그래프)

                             · 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법

 

◽ 자료 흐름도 기본 기호 (프플스터)

기 호	의 미	표 기 법
		Yourdon / DeMacro	Gane / Sarson
프로세스 (Process)	자료를 변환시키는 시스템의 한 부분(처리 과정)을 나타내며, 처리, 기능, 변환, 버블이라고도 함
자료 흐름 (Data Flow)	자료의 이동(흐름)이나 연관관계를 나타냄
자료 저장소 (Data Store)	시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄
단말 (Terminate)	시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음

                    2 ) 자료 사전 (DD ; Data Dictionary)

                             · 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것

                             · 데이터를 설명하는 데이터 ➡ 데이터의 데이터, 메타 데이터(Meta Data)라고도 함

 

                              ◽ 자료 사전 기본 기호

기 호	의 미
=	자료의 정의 : ~로 구성되어 있다.(is composed of)
+	자료의 연결 : 그리고 (and)
(  )	자료의 생략 : 생략 가능한 자료 (Optional)
[  ]	자료의 선택 : 또는 (Or)
{  }	자료의 반복 : Iteration of    ① { }n (아래 n) : n번 이상 반복    ② { }ⁿ (위 n) : 최대로 n번 반복    ③ { }ⁿ (위 n, 아래 m) : m 이상 n 이하로 반복
*  *	자료의 설명 : 주석 (Comment)

 

 

     ▫ 요구사항 분석용  CASE (자동화 도구)

             · 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구

             · 대표적인 요구사항 분석용 CASE

SADT	· 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구  · SoftTect 사에서 개발  · 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구
SREM = RSL/REVS	· TRW 사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 도구  · RSL과 REVS를 사용하는 자동화 도구
PSL/PSA	· PSL과 PSA를 사용하는 자동화 도구  · 미시간 대학에서 개발
TAGS	· 시스템 공학 방법 응용에 대한 자동 접근 방법  · 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

 

     ▫ HIPO (Hierachy Input Process Output)

             · 시스템 실행 과정인 입력·처리·출력의 기능을 표현한 것

             · 하향식 소프트웨어 개발을 위한 문서화 도구

             · HIPO Chart의 종류

                 ▫ 가시적 도표 (Visual Table of Contents, 도식 목차)

                 ▫ 총체적 도표 (Overview Diagram, 총괄 도표, 개요 도표)

                 ▫ 세부적 도표 (Detail Diagram, 상세 도표)

 

 

◽ 요구사항 명세 (Requirement Specification)

     · 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것

     · 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계

     · 기능 요구사항을 빠짐없이 기술한다.

     · 비기능 요구사항은 필요한 것만 기술한다.

     · 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 사용될 수 있다.

 

◽ 요구사항 확인(Requirement Validation, 요구사항 검증)

     · 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동

     · 이해관계자들이 검토해야 한다.

     · 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리(SCM)를 수행한다.

 

☁ 요구공학 (Requirement Engineering)

     · 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문

     · 목표 : 요구사항의 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트 실패를 최소화하는 것

 

☁ 요구사항 명세 기법

구 분	정형 명세 기법	비정형 명세 기법
기 법	수학적 원리 기반, 모델 기반	상태/기능/객체 중심
작성 방법	수학적 기호, 정형화된 표기법	일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램으로 작성
특 징	· 요구사항을 정확하고 간결하게 표현할 수 있음  · 요구사항에 대한 결과가 작성자에게 관계없이     일관성이 있으므로 완전성 검증이 가능  · 표기법이 어려워 사용자가 이해하기 어려움	· 자연어의 사용으로 인해 요구사항에 대한 결과가     작성자에 따라 다를 수 있어 일관성이 떨어지고,      해석이 달라질 수 있음  · 내용의 이해가 쉬워 의사소통이 용이함
종 류	VDM, Z, Petri-net, CSP 등	FSM, Decision Table, ER 모델링, State Chart(SADT) 등

 

 

( 6 ) UML (Unified Modeling Language)의 개요

☁  UML (Unified Modeling Language)

     · 시스템 개발 과정에서 의사소통이 원활하게 이뤄지도록 표준화한 대표적인 객체지향 모델링 언어

     · 구성 요소 (사관다)

        ▫ 사물 (Things)

        ▫ 관계 (Relationship)

        ▫ 다이어그램 (Diagram)

 

◽ 사물 (Things)

     · 다이어그램 안에서 관계가 형성될 수 있는 대상들

     · 종류 (구행그주)

사 물	내 용
구조 사물 (Structural Things)	· 시스템의 개념적, 물리적 요소를 표현  · Class, Use Case, Component, Node 등
행동 사물 (Behavioral Things)	· 시간과 공간에 따른 요소들의 행위를 표현  · 상호작용(Interaction), 상태 머신(State Machine) 등
그룹 사물 (Group Things)	· 요소들을 그룹으로 묶어서 표현  · Package
주해 사물 (Annotation Things)	· 부가적인 설명이나 제약조건 등을 표현  · 노트(Note)

 

◽ 관계 (Relationship)

     · 사물과 사물 사이의 연관성을 표현하는 것

     · 종류 (연집포 일의실)

종 류	내 용	표 기
연관(Association) 관계	· 2개 이상의 사물이 서로 관련되어 있는 관계	화살표 생략된 실선 (  ─  )
집합(Aggregation) 관계	· 하나의 사물이 다른 사물에 포함되어 있는 관계	속이 빈 마름모 ( ◇─  )
포함(Composition) 관계	· 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계	속이 찬 마름모 ( ◆─  )
일반화(Generalization) 관계	· 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계	속이 빈 화살표 ( ◁─ )
의존(Dependency) 관계	· 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계	점선 화살표 ( ⇠ )
실체화(Realization) 관계	· 할 수 있거나 해야 하는 기능으로,서로를 그룹화할 수 있는 관계	속이 빈 점선 화살표 ( ◁‐‐‑ )

 

 

◽ 다이어그램 (Diagram)

     · 사물과 관계를 도형으로 표현한 것

     · 정적 모델링 ➡ 주로 구조적 다이어그램 사용

         동적 모델링 ➡ 주로 행위 다이어그램 사용

 

     ▫ 구조적 다이어그램의 종류 (클객컴배복패)

종 류	내 용
클래스 다이어그램 (Class Diagram)	· 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
객체 다이어그램 (Object Diagram)	· 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
컴포넌트 다이어그램 (Component Diagram)	· 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현  · 구현 단계에서 사용됨
배치 다이어그램 (Batch Diagram)	· 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현  · 구현 단계에서 사용됨
복합체 구조 다이어그램 (Composite Structure Diagram)	· 클래스나 컴포넌트가 복합 구조를 갖는 경우, 그 내부 구조를 표현
패키지 다이어그램 (Package Diagram)	· 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

 

     ▫ 행위 다이어그램의 종류 (유시커 상활호타)

종 류	내 용
유스케이스 다이어그램 (Use Case Diagram)	· 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용  · 사용자(Actor)와 사용 사례(Use Case)로 구성
시퀀스 다이어그램 (Sequence Diagram)	· 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현
커뮤니케이션 다이어그램 (Communication Diagram)	· 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현
상태 다이어그램 (State Diagram)	· 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변하는지 표현  · 럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용
활동 다이어그램 (Activity Diagram)	· 시스템이 어떤 기능을 수행하는지 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
상호작용 개요 다이어그램 (Interaction Overview Diagram)	· 상호작용 다이어그램 간의 제어 흐름을 표현
타이밍 다이어그램 (Timing Diagram)	· 객체 상태 변화와 시간 제약을 명시적으로 표현

 

     ▫ 스테레오 타입 (Stereo Type)

        · UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것

        · 길러멧(Guilemet)이라 부르는 겹화살괄호《》 사이에 표현할 형태를 기술

표현 형태	의 미
《include》	포함 관계에 있는 경우
《extends》	확장 관계에 있는 경우
《interface》	인터페이스를 정의하는 경우
《exception》	예외를 정의하는 경우
《constructor》	생성자 역할을 수행하는 경우

 

 

( 7 ) 소프트웨어 개발 방법론

☁  소프트웨어 개발 방법론

     · 소프트웨어 개발, 유지보수 등에 필요한 수행 방법과 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것

     · 목적 : 소프트웨어의 생산성과 품질 향상

 

     · 주요 소프트웨어 개발 방법론

        ▫ 구조적 방법론

             · 사용자 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론

             · 분할과 정복 (Divide and Conquer) 원리 적용

 

        ▫ 정보공학 방법론

             · 계획, 분석, 설계, 구축에 정형화된 기법들을 통합 및 적용하는 자료(Data) 중심의 방법론

             · 대규모 정보 시스템 구축에 적합

 

        ▫ 객체지향 방법론

             · 객체들을 조립해서 소프트웨어를 구현하는 방법론

             · 구성요소 : 객체, 클래스, 메시지

             · 기본 원칙 : 캡슐화, 정보 은닉, 추상화, 상속성, 다형성 등

 

        ▫ 컴포넌트 기반(CBD) 방법론

             · 컴포넌트를 조합하여 새로운 애플리케이션을 만드는 방법론

             · 컴포넌트의 재사용(Reusability) 가능 (= 시간과 노력 절감) ➡ 유지 보수 비용 최소화, 생산성 및 품질 향상

 

 

        ▫ 제품 계열 방법론

             · 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론

             · 임베디드 소프트웨어를 만드는데 적합

 

        ▫ 애자일 방법론

 

( 7 ) 소프트웨어 재사용(Reuse), 재공학(Reengineering)

☁  소프트웨어 재사용 (Software Reuse)

     · 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것

    · 방법

합성 중심 (Composition-Based)	· 블록을 만들어 끼워 맞춰 소프트웨어를 완성시키는 방법으로, 블록 구성 방법이라고도 함
생성 중심 (Generation-Based)	· 추상화 형태로 써진 명세서를 구체화하여 프로그램을 만드는 방법으로, 패턴 구성 방법이라고도 함

 

☁  소프트웨어 재공학 (Software Reengineering)

     · 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것

 

☁  CASE (Computer Aided Software Engineering)

     · 소프트웨어 개발 과정에서 사용되는 과정 전체 또는 일부를 컴퓨터와 응용 소프트웨어 도구를 사용하여 자동화하는 것

 

Ref.

시나공 정보처리기사실기 책