소프트웨어 생명 주기(Software Life Cycle)
- 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것
대표적인 생명 주기 모형
- 폭포수 모형
- 프로토타입 모형
- 나선형 모형
- 애자일 모형
폭포수 모형(Waterfall Model)
- 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 관계를 진행하는 개발 방법론
프로토타입 모형(Prototype Model)
- 사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형
나선형 모형(Spiral Model)
- 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형
- 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가하였으며, 누락되거나 추가된 요구사항을 첨가할 수 있고, 유지보수 과정이 필요 없다
4가지 주요 활동은 다음과 같다.
- 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가
애자일 모형(Agile Model)
- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
대표적인 개발 모형
- 스크럼(Scrum)
- XP(eXtreme Programming)
- 칸반(Kanban)
- Lean
- 기능 중심 개발(FDD: Feature Driven Development)
애자일 개발 4가지 핵심 가치
- 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
- 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
- 계약 협상보다는 고객과 협업에 더 가치를 둔다.
- 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.
소프트웨어 공학(Software Engineering)
- 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
- 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 한다.
소프트웨어 공학의 기본 원칙
- 현대적인 프로그래밍 기술을 계속적으로 적용
- 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증
- 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록 유지
스크럼(Scrum) 기법
- 스크럼은 팀이 중심이 되어 개발의 효율성을 높이는 기법
- 팀원 스스로가 스크럼 팀을 구성하고 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 한다.
스크럼 팀
제품 책임자(PO; Product Owner)
- 요구사항이 담긴 백로그를 작성하는 주체
- 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람으로 선정
스크럼 마스터(SM; Scrum Master)
- 스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행
개발팀(DT; Development Team)
- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행
스크럼 개발 프로세스
Product Backlog -> Sprint Backlog (스프린트 계획 회의) -> 스프린트 수행 (매일 일일 스크럼 회의) -> 스프린트 검토 회의 -> 스프린트 회고
스프린트 계획 회의(Sprint Planning Meeting)
- 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의
스프린트(Sprint)
- 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행
일일 스크럼 회의(Daily Scrum Meeting)
- 모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 상황을 점검하는 회의
- 남은 작업 시간은 소멸 차트(Burn-down Chart)에 표시함
스프린트 검토 회의(Sprint Review)
- 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의
스프린트 회고(Sprint Retrospective)
- 정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것
XP(eXtreme Programming)
- 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.
XP의 5가지 핵심 가치
- 의사소통(Communication)
- 단순성(Simplicity)
- 용기(Courage)
- 존중(Respect)
- 피드백(Feedback)
XP 개발 프로세스
릴리즈 계획 수립(Release Planning)
- 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것
- 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 한다.
이터레이션(Iteration, 주기)
- 실제 개발 작업을 진행하는 과정으로, 보통 1~3주 정도의 기간으로 진행된다.
승인 검사(Acceptance Test, 인수 테스트)
- 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트
소규모 릴리즈(Small Release)
- 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소
XP의 주요 실천 방법
Pair Programming(짝 프로그래밍)
- 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성
Collective Ownership(공동 코드 소유)
- 개발 코드에 대한 권한과 책임을 공동으로 소유
Test-Driven Development(테스트 주도 개발)
- 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악
- 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구(구조, 프레임워크)를 사용
Whole Team(전체 팀)
- 개발에 참여하는 모든 구성원(고객 포함)들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 함
Continuous Integration(계속적인 통합)
- 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리 될 때마다 지속적으로 통합됨
Refactoring(리팩토링)
- 프로그램 기능의 변경 없이 시스템을 재구성함
- 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위하여 수행
Small Releases(소규모 릴리즈)
- 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응
현행 시스템 파악
1단계
- 시스템 구성 파악
- 시스템 기능 파악
- 시스템 인터페이스 파악
2단계
- 아키텍처 구성 파악
- 소프트웨어 구성 파악: 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시함
3단계
서버의 이중화
- 서비스의 연속성을 보장하기 위해 운용 서버에 장애가 발생했을 때 대기 서버로 서비스를 계속 제공하는 서버 구성 방식으로, 운용 서버의 자료 변경이 대기 서버에서도 동일하게 복제되어 관리되는 방식
개발 기술 환경 파악
- 개발하고자 하는 소프트웨어와 관련된 운영체제(OS), 데이터베이스 관리 시스템(DBMS), 미들웨어 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈 소스를 사용할 때 주의해야 할 내용을 제시
운영체제(OS, Operating System)
- 컴퓨터 시스템의 자원을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어
- 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종
운영체제 관련 요구사항 식별 시 고려사항
- 가용성
- 성능
- 기술 지원
- 주변 기기 (OS만의 고려사항)
- 구축 비용
데이터베이스 관리 시스템(DBMS; DataBase Management System)
- 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어
- 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템
- 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록 관리
DBMS 관련 요구사항 식별 시 고려사항
- 가용성
- 성능
- 기술 지원
- 상호 호환성 (DBMS만의 고려사항)
- 구축 비용
웹 애플리케이션 서버(WAS; Web Application Server)
- 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
- 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리를 제공
WAS 관련 요구사항 식별 시 고려사항
오픈 소스(Open Source)
- 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어
오픈 소스 관련 요구사항 식별 시 고려사항
- 라이선스의 종류
- 사용자 수
- 기술의 지속 가능성
요구사항
- 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건
- 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공
- 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 준다
요구사항의 유형
- 기능 요구사항
- 비기능 요구사항
- 사용자 요구사항
- 시스템 요구사항
기능 요구사항(Functional Requirements)
- 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행에 관련된 요구사항
비기능 요구사항(Non-functional Requirements)
사용자 요구사항(User Requirements)
- 사용자 관점에서 본 시스템이 제공해야 할 요구사항
시스템 요구사항(System Requirements)
- 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
요구사항 개발 프로세스
- 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동
- 요구사항 개발은 요구공학의 한 요소이며, 타당성 조사가 선행되어야 한다.
순서는 도출 -> 분석 -> 명세 -> 확인이다.
요구사항 도출(Requirement Elicitation)
- 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정
- 개발자와 고객 사이의 관계가 만들어지고 이해관계자가 식별됨
- 소프트웨어 개발 생명주기(SDLC) 동안 지속적으로 반복
요구사항을 도출하는 주요 기법
- 청취와 인터뷰
- 설문
- 브레인스토밍
- 워크샵
- 프로토타이핑
- 유스케이스
요구사항 분석(Requirement Analysis)
- 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
- 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
- 서로 상충되는 요구사항이 있으면 이를 중재
요구사항 분석에 사용되는 대표적인 도구
요구사항 명세(Requirement Specification)
- 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미
- 기능 요구사항을 빠짐없이 기술
- 비기능 요구사항은 필요한 것만 기술
- 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 사용될 수 있음
요구사항 확인(Requirement Validation)
- 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 명확하고 완전하게 작성되었는지를 검토하는 활동
요구공학(Requirements Engineering)
- 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문
- 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트 실패를 최소화하는 것을 목표로 한다.
요구사항 명세 기법
정형 명세 기법 vs 비정형 명세 기법
- 수학적 원리 기반, 모델 기반 vs 상태/기능/객체 중심
- 수학적 기호, 정형화된 표기법 vs 자연어를 기반으로 서술 또는 다이어그램으로 작성
- 요구사항을 정확하고 간결하게 표현, 요구사항에 대한 결과가 작성자에 관계없이 일관성이 있으므로 완전성 검증이 가능 vs 내용의 이해가 쉬어 의사소통이 용이
- 종류: VDM, Z, Petri-net, CSP vs FSM, Decision Table, ER모델링, SADT
요구사항 분석
- 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동을 의미
- 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
구조적 분석 기법
- 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
- 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화
- 하향식 방법을 사용하여 시스템을 세분화
주요 구조적 분석 기법 도구
- 자료 흐름도(DFD)
- 자료 사전(DD)
- 소단위 명세서(Mini-Spec.)
- 개체 관계도(ERD)
- 상태 전이도(STD)
- 제어 명세서
자료 흐름도(DFD; Data Flow Diagram, 버블 차트)
- 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
- 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용
자료 흐름도 기본 기호
- 프로세스(Process): 자료를 변환시키는 시스템의 한 부분을 나타낸다.
- 자료 흐름(Data Flow): 자료의 이동이나 연관관계를 나타낸다.
- 자료 저장소(Data Store): 시스템에서의 자료 저장소를 나타낸다.
- 단말(Terminator): 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받는다.
자료 사전(DD; Data Dictionary)
- 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
- 데이터를 설명하는 데이터로, 데이터의 데이터 또는 메타 데이터(Meta Data)라고도 한다.
자료 사전에서 사용되는 표기 기호
- 자료의 정의: =
- 자료의 연결: +
- 자료의 생략: ( )
- 자료의 선택: [ ]
- 자료의 반복: { }
- 자료의 설명: * *
요구사항 분석 CASE와 HIPO
- 요구사항 분석용 CASE는 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구를 의미한다.
대표적인 요구사항 분석용 CASE
- SADT: SoftTech 사에서 개발, 구조적 요구 분석을 위해 블록 다이어그램을 채택한 자동화 도구
- SREM = RSL/REVS
- PSL/PSA
- TAGS: 시스템 공학 방법 응용에 대한 자동 접근 방법, 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구
- 시스템의 분석 및 설계, 또는 문서화에 사용되는 기법으로, 시스템 실행 과정인 입력-처리-출력의 기능을 표현한 것이다.
- 하향식 소프트웨어 개발을 위한 문서화 도구
- 기능과 자료의 의존 관계를 동시에 표현 가능
- 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉽다.
- 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 한다.
HIPO Chart의 종류
- 가시적 도표(Visual Table of Contents)
- 총체적 도표(Overview Diagram)
- 세부적 도표(Detail Diagram)
UML(Unified Modeling Language)
- 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어이다.
- Rumbaugh, Booch, Jacobson 등의 객체지향 방법론의 장점을 통합하였다.
UML의 구성 요소
- 사물(Things)
- 관계(Relationships)
- 다이어그램(Diagram)
사물(Things)
- 사물은 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말한다.
- 모델을 구성하는 가장 중요한 기본 요소이다.
사물의 종류
- 구조 사물(Structural Things): 시스템의 개념적, 물리적 요소를 표현
- 행동 사물(Behavioral Things): 시간과 공간에 따른 요소들의 행위를 표현
- 그룹 사물(Grouping Things): 요소들을 그룹으로 묶어서 표현
- 주해 사물(Annotation Things): 부가적인 설명이나 제약조건 등을 표현
UML - 관계(Relationships)
- 관계는 사물과 사물 사이의 연관성을 표현하는 것
관계의 종류
연관(Association) 관계
- 2개 이상의 사물이 서로 관련되어 있는 관계
- 사물 사이를 실선으로 연결하여 표현
- 방향성은 화살표로 표현
- 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결
- 다중도를 선 위에 표기
집합(Aggregation) 관계
- 하나의 사물이 다른 사물에 포함되어 있는 관계
- 포함하는 쪽(전체)과 포함되는 쪽(부분)은 서로 독립적이다.
- 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 빈 마름모를 연결하여 표현
포함(Composition) 관계
- 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
- 포함하는 쪽(전체)과 포함되는 쪽(부분)은 서로 독립될 수 없고 생명주기를 함께한다.
- 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 채워진 마름모를 연결하여 표현한다.
일반화(Generalization) 관계
- 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
- 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다.
- 구체적인 사물에서 일반적인 사물 쪽으로 속이 빈 화살표를 연결하여 표현한다.
의존(Dependency) 관계
- 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
- 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
- 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현
실체화(Realizaion) 관계
- 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화 할 수 있는 관계
- 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현
UML - 다이어그램(Diagram)
- 사물과 관계를 도형으로 표현한 것
- 여러 관점에서 시스템을 가시화한 뷰를 제공함으로써 의사소통에 도움을 준다.
구조적(Structural) 다이어그램의 종류
클래스(Class) 다이어그램
- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
객체(Object) 다이어그램
- 클래스에 속한 객체들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현함
- 럼바우 객체지향 분석 기법에서 객체 모델링에 활용됨
컴포넌트(Component) 다이어그램
- 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
- 구현 단계에서 사용됨
배치(Deployment) 다이어그램
- 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현함
- 구현 단계에서 사용됨
복합체 구조(Composite Struture) 다이어그램
- 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
패키지(Package) 다이어그램
- 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현
행위(Behavioral) 다이어그램의 종류
유스 케이스(Use Case) 다이어그램
- 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용
- 사용자(Actor)와 사용 사례(Use Case)로 구성
시퀀스(Sequence) 다이어그램
- 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현
커뮤니케이션(Communication) 다이어그램
- 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현
상태(State) 다이어그램
- 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현
- 럼바우 객체지향 분석 기법에서 동적 모델링에 활용
활동(Activity) 다이어그램
- 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
상호작용 개요(Interaction Overview) 다이어그램
타이밍(Timing) 다이어그램
- 객체 상태 변화와 시간 제약을 명시적으로 표현
스테레오 타입(Stereotype)
- UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것
- 겹화살괄호(<<>>) 사이에 표현할 형태를 기술
<<include>> // 포함 관계
<<extends>> // 확장 관계
<<interface>> // 인터페이스 정의
<<exception>> // 예외 정의
<<constructor>> // 생성자 역할을 수행
기능 모델링
- 사용자의 요구사항을 분석하여 개발될 시스템이 갖춰야 할 기능을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 그림으로 표현하는 것
기능 모델링의 종류
- 유스케이스(Use Case) 다이어그램
- 활동(Activity) 다이어그램
유스케이스(Use Case) 다이어그램
- 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것
- 외부 요소와 시스템 간의 상호 작용을 확인
- 사용자의 요구사항을 분석하기 위한 도구로 사용
- 시스템의 범위를 파악할 수 있음
유스케이스 다이어그램의 구성 요소
시스템(System) / 시스템 범위(System Scope)
- 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현
액터(Actor)
- 시스템과 상호작용을 하는 모든 외부 요소
- 주로 사람이나 외부 시스템을 의미
- 주액터: 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당
- 부액터: 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템
유스케이스(Use Case)
- 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현
관계(Relationship)
- 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있음
- 포함, 확장, 일반화 관계가 나타날 수 있음
활동(Activity) 다이어그램
- 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
- 하나의 유스케이스 안에서 혹은 유스케이스 사이에 발생하는 복잡한 처리의 흐름을 명확하게 표현
- 자료 흐름도와 유사
활동 다이어그램의 구성 요소
액션(Action) / 액티비티(Activity)
- 액션: 더 이상 분해할 수 없는 단일 작업
- 액티비티: 몇 개의 액션으로 분리될 수 있는 작업
시작 노드
종료 노드
- 액티비티 안의 모든 흐름이 종료됨을 표현한 것
조건(판단) 노드
- 조건에 따라 제어의 흐름이 분리됨을 표현한 것
- 들어오는 제어 흐름은 한 개이고 나가는 제어 흐름은 여러 개임
병합 노드
- 여러 경로의 흐름이 하나로 합쳐짐을 표현한 것
- 들어오는 제어 흐름은 여러 개이고 나가는 제어 흐름은 한 개임
포크(Fork) 노드
- 액티비티의 흐름이 분리되어 수행됨을 표현
- 들어오는 액티비티 흐름은 한 개이고 나가는 액티비티 흐름은 여러 개임
조인(Join) 노드
- 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한 것
- 들어오는 액티비티 흐름은 여러 개이고 나가는 액티비티 흐름은 한 개
스윔레인(Swim Lane)
- 액티비티 수행을 담당하는 주체를 구분하는 선
- 가로 또는 세로 실선을 그어 구분
정적 모델링
- 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현
- 시스템에 의해 처리되거나 생성될 객체들 사이에 어떤 관련이 있는지를 구조적인 관점에서 표현
- 객체들을 클래스로 추상화하여 표현
- UML을 이용한 정적 모델링이 대표적인 것이 클래스 다이어그램
클래스(Class) 다이어그램
- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것
- 시스템 구성 요소를 문서화하는 데 사용
클래스 다이어그램의 구성 요소
클래스(Class)
- 각각의 개체들이 갖는 속성과 오퍼레이션을 표현한 것
- 일반적으로 3개의 구획으로 나눠 클래스의 이름, 속성, 오퍼레이션을 표기
- 속성(Attribute): 클래스의 상태나 정보를 표현
- 오퍼레이션(Operation): 클래스가 수행할 수 있는 동작으로, 함수(메소드, Method)라고도 함
제약 조건
- 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적음
- 클래스 안에 제약조건을 기술할 때는 중괄호{}를 이용함
관계(Relationships)
연관 클래스
- 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스
- 두 클래스의 연관 관계를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시
- 연관 클래스의 이름은 연관 관계의 이름을 이용해 지정
동적 모델링
- 시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것
- 시스템 내부 구성 요소들 간에 이루어지는 동작이라는 관점에서 표현
- 시스템이 실행될 때 구성 요소들 간의 메시지 호출, 즉 오퍼레이션을 통한 상호 작용에 초점을 둔다.
동적 모델링의 종류
- 시퀀스 다이어그램
- 커뮤니케이션 다이어그램
- 상태 다이어그램
시퀀스(Sequence) 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호 작용하는 과정을 그림으로 표현한 것
- 각 동작에 참여하는 시스템이나 객체들의 수행 기간을 확인
- 클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현
시퀀스 다이어그램의 구성 요소
액터(Actor)
- 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미
객체(Object)
생명선(Lifeline)
- 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현
- 객체 소멸이 표시된 기간까지 존재
실행 상자(Active Box)
- 객체가 메시지를 주고받으며 구동되고 있음을 표현
메시지
객체 소멸
- 해당 객체가 더 이상 메모리에 존재하지 않음을 표현한 것
프레임(Frame)
- 다이어그램의 전체 또는 일부를 묶어 표현한 것
커뮤니케이션(Communication) 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호 작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것
- 시퀀스 다이어그램과의 차이: 객체들을 연결하는 링크가 추가되어 동작에 참여하는 객체들 사이의 관계를 파악하는 데 사용
- 클래스 다이어그램에서 관계가 제대로 표현됐는지 점검하는 용도로도 사용
커뮤니케이션 다이어그램의 구성 요소
액터(Actor)
- 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미
객체(Object)
링크(Link)
- 객체들 간의 관계를 표현한 것
- 액터와 객체, 객체와 객체 간에 실선을 그어 표현
메시지(Message)
- 객체가 상호 작용을 위해 주고받는 내용
- 화살표의 방향은 메시지를 받는 쪽으로 향하게 표현
- 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서를 표시
상태(State) 다이어그램
- 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것
- 객체의 상태란 객체가 갖는 속성 값의 변화를 의미
- 특정 객체가 어떤 이벤트에 의해 상태 변환 과정이 진행되는지 확인하는 데 사용
상태 다이어그램의 구성 요소
상태(State)
시작 상태
종료 상태
상태 전환
- 상태 사이의 흐름, 변화를 화살표로 표현한 것
이벤트(Event)
프레임(Frame)
패키지(Package) 다이어그램
- 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것이다.
- 패키지는 또 다른 패키지의 요소가 될 수 있다.
- 대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용한다.
패키지 다이어그램의 구성 요소
패키지(Package)
- 객체들을 그룹화한 것
- 단순 표기법: 패키지 안에 패키지 이름만 표현
- 확장 표기법: 패키지 안에 요소까지 표현
객체(Object)
- 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들
의존 관계(Dependency)
- 패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현
- 스트레오타입을 이용해 의존 관계를 구체적으로 표현할 수 있음
- 의존 관계의 표현 형태는 사용자가 임의로 작성할 수 있으며, 대표적으로 import와 access가 사용됨
<<import>> // 패키지에 포함된 객체들을 직접 가져와서 이용하는 관계
<<access>> // 인터페이스를 통해 패키지 내의 객체에 접근하여 이용하는 관계
소프트웨어 개발 방법론
- 소프트웨어 개발, 유지보수 등에 필요한 여러가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각정 기법 및 도구를 체계적으로 정리하여 표준화한 것
- 목적은 소프트웨어의 생산성과 품질 향상
주요 소프트웨어 개발 방법론
- 구조적 방법론
- 정보공학 방법론
- 객체지향 방법론
- 컴포넌트 기반(CBD) 방법론
- 제품 계열 방법론
- 애자일 방법론
구조적 방법론
- 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론
- 쉬운 이해 및 검증이 가능한 프로그램 코드를 생성하는 것이 목적
- 복잡한 문제를 다루기 위해 분할과 정복(Divide and Conquer) 원리를 적용
구조적 방법론의 개발 절차
- 타당성 검토 단계
- 계획 단계
- 요구사항 단계
- 설계 단계
- 구현 단계
- 시험 단계
- 운용/유지보수 단계
정보공학 방법론
- 정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료 중심의 방법론
- 정보 시스템 개발 주기를 이용하여 대규모 정보 시스템을 구축하는데 적합
정보공학 방법론의 개발 절차
- 정보 전략 계획 수립 단계
- 업무 영역 분석 단계
- 업무 시스템 설계 단계
- 업무 시스템 구축 단계
객체지향 방법론
-
현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
-
구성요소: 객체, 클래스, 메시지 등
-
기본원칙: 캡슐화, 정보 은닉, 추상화, 상속성, 다형성 등
객체지향 방법론의 개발 절차
- 요구 분석 단계
- 설계 단계
- 구현 단계
- 테스트 및 검증 단계
- 인도 단계
컴포넌트 기반(CBD; Component Based Design) 방법론
- 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
- 컴포넌트의 재사용이 가능하여 시간과 노력을 절감
- 새로운 기능을 추가하는 것이 간단하여 확장성이 보장
- 유지 보수 비용을 최소화하고 생산성 및 품질을 향상시킬 수 있다.
컴포넌트 기반 방법론의 개발 절차
- 개발 준비 단계
- 분석 단계
- 설계 단계
- 구현 단계
- 테스트 단계
- 전개 단계
- 인도 단계
제품 계열 방법론
- 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
- 임베디드 소프트웨어를 만드는데 적합
- 제품 계열 방법론은 영역공학과 응용공학으로 구분
- 영역공학: 영역 분석, 영역 설계, 핵심 자산을 구현
- 응용공학: 제품 요구 분석, 제품 설계, 제품을 구현하는 영역
S/W 공학의 발전적 추세
소프트웨어 재사용(Software Reuse)
- 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
- 소프트웨어 개발의 품질과 생산성을 높이기 위한 방법
소프트웨어 재사용 방법
- 합성 중심(Composition-Based): 블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법으로, 블록 구성 방법이라고도 함
- 생성 중심(Generation-Based): 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법으로, 패턴 구성 방법이라고도 함
소프트웨어 재공학(Software Reengineering)
- 새로운 요구에 맞도록 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것
- 유지보수 비용이 소프트웨어 개발 비용의 대부분을 차지하기 때문에 유지보수의 생산성 향상을 통해 소프트웨어 위기를 해결하는 방법
소프트웨어 재공학의 이점
- 소프트웨어의 품질 향상
- 소프트웨어의 생산성 증가
- 소프트웨어의 수명 연장
- 소프트웨어의 오류 감소
CASE(Computer Aided Software Engineering)
- 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
- 소프트웨어 개발 도구와 방법론이 결합되었으며, 정형화된 구조 및 방법을 소프트웨어 개발에 적용하여 생산성 향상을 구현
CASE의 주요 기능
- 소프트웨어 생명 주기 전 단계의 연결
- 다양한 소프트웨어 개발 모형 지원
- 그래픽 지원
비용 산정 기법
소프트웨어 비용 산정
- 개발에 소요되는 인원, 자원, 기간 등으로 소프트웨어의 규모를 확인하여 개발 계획 수립에 필요한 비용을 산정하는 것
- 너무 높게 산정할 경우 예산 낭비와 일의 효율성 저하를 초래, 너무 낮게 산정할 경우 개발자의 부담이 가중되고 품질 문제가 발생
- 하향식 비용 산정 기법과 상향식 비용 산정 기법이 있다.
소프트웨어 비용 결정 요소
프로젝트 요소
자원 요소
생산성 요소
하향식 비용 산정 기법
- 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법
- 프로젝트의 전체 비용을 산정한 후 각 작업별로 비용을 세분화한다.
하향식 비용 산정 기법
전문가 감정 기법
- 조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법
델파이 기법
- 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법
- 한 명의 조정자와 여러 전문가로 구성
상향식 비용 산정 기법
- 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
주요 상향식 비용 산정 기법
- LOC(원시 코드 라인 수) 기법
- 개발 단계별 인월수 기법
- 수학적 산정 기법
LOC(원시 코드 라인 수, source Line Of Cord) 기법
-
각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
-
예측치: (a + 4m + b) / 6 (a: 낙관치, b: 비관치, m: 기대치(중간치))
개발 단계별 인월수 기법
- 각 기능을 구현시키는 데 필요한 노력을 생명 주기의 각 단계별로 산정한다.
- LOC 기법보다 더 정확하다.
수학적 산정 기법
- 상향식 비용 산정 기법으로, 경험적 추정 모형, 실험적 추정 모형이라고도 한다.
- 개발 비용 산정의 자동화를 목표로 하며, 비용의 자동산정을 위해 사용되는 공식은 과거의 유사한 프로젝트를 기반으로 유도된 것이다.
주요 수학적 산정 기법
- COCOMO 모형
- Putnam 모형
- 기능 점수(FP) 모형
COCOMO(COnstructive COst MOdel) 모형
- 원시 프로그램의 규모인 LOC에 의한 비용 산정 기법
- 개발할 소프트웨어의 규모를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 산정
- 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력으로 나타난다.
COCOMO의 소프트웨어 개발 유형
조직형(Organic Mode)
- 기관 내부에서 개발된 중소규모의 소프트웨어
- 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리용 등의 5만 라인 이하의 소프트웨어를 개발
- 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합
반분리형(Semi-Detached Mode)
- 조직형과 내장형의 중간형 소프트웨어
- 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만 이하의 소프트웨어를 개발
- 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합
내장형(Embedded Mode)
- 초대형 규모의 소프트웨어
- 트랜잭션 처리 시스템이나 운영체제 등의 30만 라인 이상의 소프트웨어를 개발
- 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합
COCOMO 모형의 종류
기본형(Basic) COCOMO
- 소프트웨어의 크기와 개발 유형만을 이용하여 비용 산정
- 기본형 COCOMO의 공식을 토대로 사용하나 제품, 컴퓨터, 개발 요원, 프로젝트의 특성을 고려
발전형(Detailed) COCOMO
- 중간형 COCOMO를 보완하여 만들어진 모형
- 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용 산정
- 소프트웨어 환경과 구성 요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 사용
Putnam 모형
- 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
- 생명 주기 예측 모형이라고도 한다.
- 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
- 대형 프로젝트의 노력 분포 산정에 이용된다.
- 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소한다.
기능 점수(FP; Function Point) 모형
- 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며, 총 기능 점수와 영향도를 이용하여 기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정하는 기법
소프트웨어 기능 증대 요인
- 자료 입력
- 정보 출력
- 명령어
- 데이터 파일
- 필요한 외부 루틴과의 인터페이스
비용 산정 자동화 추정 도구
- SLIM: Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구
- ESTIMACS: 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구
프로젝트 일정(Scheduling) 계획
- 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여 소작업의 순서와 일정을 정하는 것
- 프로젝트 일정 계획에 사용되는 기능: WBS, PERT/CPM, 간트 차트 등
PERT(Program Evaluation and Review Techinque, 프로그램 평가 및 검토 기술)
-
프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크
-
각 작업별로 다음과 같이 단계를 나누어 종료시기를 결정: 낙관적, 가능성이 있음, 비관적
-
개발 경험이 없어 소요 기간 예측이 어려운 프로젝트 일정 계획에 사용
-
노드와 간선으로 구성되며 원 노드에는 작업을, 간선에는 낙관치, 기대치, 비관치를 표시
-
결정 경로, 작업에 대한 경계 시간, 작업 간의 상호 관련성 등을 알 수 있다.
-
작업 예측치 계산 공식: (비관치 + (4 * 기대치) + 낙관치) / 6
CPM(Critical Path Method, 임계 경로 기법)
- 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
- 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타냄
- 간선을 나타내는 화살표의 흐름에 따라 각 작업이 진행되며, 전 작업이 완료되어야 다음 작업을 진행할 수 있다.
- 임계 경로 = 최장 경로
간트 차트
- 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표
- 시간선(Time-Line) 차트라고도 한다.
- 수평 막대의 길이는 각 작업(Task)의 기간을 나타낸다.
소프트웨어 개발 방법론 결정
- 프로젝트 관리와 재사용 현황을 소프트웨어 개발 방법론에 반영하고, 확정된 소프트웨어 생명 주기와 개발 방법론에 맞춰 소프트웨어 개발 단계, 활동, 작업, 절차 등을 정의하는 것
프로젝트 관리
- 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동
관리 유형
- 일정 관리
- 비용 관리
- 인력 관리
- 위험 관리
- 품질 관리
소프트웨어 개발 표준
- 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준을 의미
주요 소프트웨어 개발 표준
- ISO/IEC 12207
- CMMI(능력 성숙도 통합 모델)
- SPICE(소프트웨어 처리 개선 및 능력 평가 기준)
ISO/IEC 12207
- ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스
- 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공
ISO/IEC 12207 구분
- 기본 생명 주기 프로세스
- 지원 생명 주기 프로세스
- 조직 생명 주기 프로세스
CMMI(Capability Maturity Model Integration)
- 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델
CMMI의 소프트웨어 프로세스 성숙도
- 초기(Initial)
- 관리(Managed)
- 정의(Defined)
- 정량적 관리(Quantitatively Managed)
- 최적화(Optimizing)
SPICE(Software Process Improvement and Capability dEtermination)
- 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
- 공식 명칭은 ISO/IEC 15504
SPICE의 구성
- 고객-공급자(Customer) 프로세스: 소프트웨어를 개발하여 고객에게 전달하는 것을 지원
- 공학(Engineering) 프로세스: 시스템과 소프트웨어 제품의 명세화, 구현, 유지보수를 하는데 사용
- 지원(Support) 프로세스: 소프트웨어 생명 주기에서 다른 프로세스에 의해 이용되는 프로세스로 구성
- 관리(Management) 프로세스: 소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성
- 조직(Organization) 프로세스: 조직의 업무 목적 수립과 조직의 업무 목표 달성을 위한 프로세스로 구성
SPICE의 프로세스 수행 능력 단계
- 불완전(Incomplete)
- 수행(Performed)
- 관리(Managed)
- 확립(Established)
- 예측(Predictable)
- 최적화(Optimizing)
소프트웨어 개발 방법론 테일러링
- 프로젝트 상황 및 특성에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업
소프트웨어 개발 방법론 테일러링 수행 절차
- 프로젝트 특징 정의
- 표준 프로세스 선정 및 검증
- 상위 수준의 커스터마이징
- 세부 커스터마이징
- 테일러링 문서화
소프트웨어 개발 방법론 테일러링 고려사항
내부적 기준
외부적 기준
소프트웨어 개발 프레임워크
- 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템
- 선행 사업자의 기술에 의존하지 않는 표준화된 개발 기반으로 인해 사업자 종속성이 해소
소프트웨어 개발 프레임워크의 주요 기능
- 예외 처리
- 트랜잭션 처리
- 메모리 공유
- 데이터 소스 관리
- 서비스 관리
- 쿼리 서비스
- 로깅 서비스
- 사용자 인증 서비스
소프트웨어 개발 프레임워크의 종류
- 스프링 프레임워크
- 전자정부 프레임워크
- 닷넷 프레임워크
스프링 프레임워크(Spring Framework)
- 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크
- 동적인 웹 사이트의 개발을 위해 다양한 서비스를 제공
- 전자정부 표준 프레임워크의 기반 기술로 사용
전자정부 프레임워크
- 대한민국의 공공부문 정보화 사업 시 효율적인 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍처를 제공하는 프레임워크
- 개발 프레임워크의 표준 정립으로 응용 소프트웨어의 표준화, 품질 및 재상용성의 향상을 목적으로 함
- 공개된 기술을 활용함으로써 특정 업체의 종속성을 ㅐㅂ제하고 사업별 공통 컴포넌트의 중복 개발을 방지
닷넷 프레임워크(.NET Framework)
- Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크
- 코드 실행을 관리하는 CLR(Common Language Runtime, 공영 언어 런타임)이라는 이름의 가상머신 상에서 작동
소프트웨어 개발 프레임워크의 특성
모듈화(Modularity)
- 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 소프트웨어의 품질을 향상시킴
- 개발 표준에 의한 모듈화로 인해 유지 보수가 용이
재사용성(Reusability)
- 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능함
확장성(Extensibility)
- 다형성을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능
제어의 역흐름(Inversion of Control)
- 개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 남김으로써 생산성을 향상