1-1 소프트웨어 종류 및 개발 방법론 - 소프트웨어 개발 방법론

소프트웨어 개발 방법론

 

1. 소프트웨어 개발 환경

 

 

운영 체제(OS: Operating System)

 

정의	H/W, S/W 자원 관ᄅᆘ, 프로그램 위한 공통 서비스 제공
종류	Windows UNIX Linux iOS Android
운영 체제 분석 시 고려 사항	신뢰도 성능 기술 지원 주변 기기 구축 비용
운영 체제 현황	32bit - 4GB 메모리(사용자: 2), 64bit - 4GB 이상까지 엑세스 가능 CISC 설계 방식의 인텔 x86 아키텍처 기반 칩 H/W: Windows, Linux 기반 체제 설치 RISC 설계 방식의 칩: UNIX HP, Intel 협력의 IA-64 칩: 여러 운영체제 RISC 설계 방식의 ARM 칩: iOS, Android

 

 

 

CPU(중앙 처리 장치)

 

	CISC(Complex Instruction Set Computer)	RISC(Reduced Instruction Set Computer)
명령어/주소 지정 모드	복잡하고 많은 종류	간단하고 적은 종류
명령어 형식	가변 길이(100-250개)	고정 길이(CISC보다 수 적음)
제어 방식	마이크로 프로그래밍(소프트웨어적)	하드웨어적
장점	호환성, 컴파일 과정 쉬움	파이프라이닝 구조, 빠른 해석 속도, 많은 범용 레지스터, 간단한 하드웨어 구조, 적은 전력 소모
단점	느린 속도(명령어 해석 후 실행)	호환성 떨어짐
사용	인텔사 CPU	고성능 워크스테이션/그래픽용 컴퓨터

 

 

DBMS(DataBase Management System)

 

정의	DB 생성, 조회, 병경 등의 관리 사용자, 다른 애플리케이션, DB와 상호 작용하여 데이터 저장, 분석
종류	Oracle IBM DB2 SQL server MySQL SQLite MongoDB Redis
DBMS 분석 시 고려 사항	가용성 성능 기술 지원상호 호환성 구축 비용

 

 

 

미들 웨어(Middleware)

 

정의

S/W 애플리케이션에게 운영체제가 제공하는 서비스를 추가 및 확장하여 제공하는 S/W 운영체제와 소프트웨어 애플리케이션 사이에 위치 분산 컴퓨팅 환경에서 서로 다른 기종 간 하드웨어나 프로토콜, 통신환경 등을 연결하여 응용프로그램과 운영 환경 간에 원만한 통신이 이루어질 수 있게 서비스 제공 클라이언트-서버간 통신 담당

종류

DBMS(DataBase Management System) : 데이터 베이스 벤더에서 제공하는 클라이언트에서 DB와 연결(2-Tier 아키텍처) RPC(Remote Procedure Call) : 원격 프로시저를 로컬처럼 호출 MOM(Message Oriented Middleware) : 메시지 기반의 비동기형 메시지 전달 TP-Monitor : 온라인 트렌젝션이 올바르게 처리되고 있는지 데이터 감시/제어, 사용자 수 증가해도 빠른 응답 속도, 은행 계정, 항공기/버스 예약 업무 ORB(Object Request Broker) : 코바(CORBA) 표준 스펙 구현한 객체 지향 미들웨어 WAS(Web Applicationi Server) : 서버 계층에서 웹 환경 구현(EJB: Java 컴포넌트 설정 아키텍처)

 

 

 

WAS(Web Application Server)

 

개념	동적 웹 사이트/애플리케이션/서비스 개발 지원 위해 설계된 소프트웨어 데이터 접근/세션/트랜잭션 관리 등을 위한 라이브러리 제공 HTTP 세션 처리 위한 웹 서버 기능, 필수적 기업 업무를 Java, EJB 컴포넌트 기반으로 구현 가능 사용자가 웹 브라우저로 요청 시 정적 데이터(이미지, 자바스크립트 코드 등)는 웹 서버가 직접 처리 동적 데이터(DB와 접속, 외부 시스템과의 연동 등)는 WAS에서 지원받아 처리
종류	GlassFish : GlassFish Community(애플리케이션 서버 개발 위한 Java 공동체)에서 제공, NetBeans(Java 개발자 플랫폼) 개발 툴과 연동하여 사용 Jboss : Red Hat, Jboss(Java 기반 오픝 소스 미들웨어 총칭)에서 제공, 오픈 소스 제품 이용 시 사용 Jetty : Eclipse Foundation에서 제공, 빠른 처리 속도 요구시 사용 JEUS : TmaxSoft에서 제공, 대량의 안정적 거래 처리 요구, 적시의 기술 지원 필요 시 사용 Resin : Caucho Technology에서 제공, 빠른 처리 속도 요구시 사용 WebLogic : Oracle Corporation에서 제공, 대량의 안정적 거래 처리 요구되는 경우 사용 WebSphere : IBM 제공, 대량의 안정적 거래 처리 요구되는 경우 사용
분석 시 고려사항	가용성 성능 기술 지원 구축 비용

 

 

 

2. 소프트웨어 개발 방법론

 

	시대	절차	특징
구조적 방법론 (Structured Development)	1970년대	타당성 검토 → 계획 → 요구사항 → 설계 →구현 →시험 → 운용/유지보수	- 구조적인 프로그램 - 정형화된 분석 절차로 문서화하는 체계적 분석 방법 - 쉽게 이해/검증 가능한 코드 생성 - 모듈(부품) 중심 개발 - 분할과 정복 방법으로 하향식으로 기능 분해 - 프로세스 중심 방식의 개발에 유용 - 재사용성, 유지보수성 낮음 - 나씨-슈나이더만 차트
정보 공학 방법론 (Information Engineering Development)	1980년대	수직적: 정보 전략 계획 → 업무 영역 분석 → 업무 시스템 설계 → 기술 설계 →업무 시스템 구축 → 업무 시스템 실행 수평적: 데이터 → 업무 활동 → 상호 작용	- 정보 시스템 개발에 필요한 관리 절차/작업 기법 체계화 - S/W 공학 기술 발전에 따라 활용위한 개발 방법론 - 생명 주기 이용해 대형 프로젝트 수행 - 기업 정보 시스템에 공학적 기법 적용하여 계획, 분석, 설계 및 구축 - 자료 구조 중심의 방법론으로 안정적 - 데이터와 프로세스가 균형적 - 기능적 설계를 벗어나지 못함 - 기능별로 유지보수 필요하며 재사용성 낮음
객체 지향 방법론 (Object-Oriented Development)	1990년대	요구분석 → 설계 → 구현 → 시험 → 인수	- 객체라는 기본 단위로 시스템 분석/설계 - 데이터(실체), 관련 동작(절차, 방법, 기능) 모두 포함 - 정보 시스템, DB 설계 - 객체 중심으로 캡슐화, 추상화 기술 필요 - 분석 초점 명확 - 자연스럽고 유연, 재사용 용이 - 개발 전문가 부족
컴포넌트 기반 방법론 (CBD; Component Based Development)	2000년대	개발 준비 → 분석 → 설계 → 구현 → 시험 → 전개 → 인도	- s/w 구성하는 컴포넌트  조립하여 하나의 새로ᄋᆕᆫ 애플리케이션 작성 - 모듈: 기능 구현하기 위한 최소 단위 - 공공 행정 정보 시스템 개발에 활용되는 표준 프로세스 - 재사용 가능한 컴포넌트 개발 또는 상용 컴포넌트 들 조합하여 개발하는 방법론 - 생산성, 품질 높이고 유지보수 비용 최소화(재사용성 높임) - 반복적, 점진적 개발 - 비용 저렴, 위험 개선 - s/w 위기 극복컴포넌트 유통 환경 개선 - 테스트 환경 부족, 컴포넌트 평가, 인증 환경 미흡

 

 

 

애자일(Agile) 방법론(2000년 이후)

 

정의	절차보다 사람이 중심이 되어 변화에 유연/신속하게 적응하며 효율적으로 시스템 개발 요구사항, 설계, 구현, 시험 단계 계획이 없거나 많은 방법 사이의 타협점 요구사항 지속적으로 분석, 반영하여 시간 지연 최소화
특징	개발 과정 소통을 중요시하며 반복적 개발을 통한 잦은 출시 목표 기존 모형의 문제점 보완 S/W 점중 개발 인간 수행능력 높이기 위한 현실적 방법 제시 가볍고 실용적
종류	익스트림 프로그래밍(XP), 스크럼, 린, DSDM, FDD(기능 개발 중심), Crystal, Kanban 등
선언문	개인과 상호 작용을 프로세스와 도구보다 중시한다 동작하는 소프트웨어를 포괄적인 문서보다 중시한다 고객과의 협력을 계약의 협상보다 중시한다 변화의 대응을 계획의 수행보다 중시한다
요구사항 원칙	소통한다 협력한다 적응한다 지속한다 가치를 전달한다 피드백한다
5가지 가치 용단의피존	용기 단순함 의사소통 피드백 존경

 

 

 

XP(eXtreme Programming)

 

특징	문서화 강조하지 않고 변경 추구 개발 초기부터 s/w 검사 병행 강력 권고
12개 실천 항목(기본 원리)	Pair Programming: 짝 프로그래밍 Planning Game: 게임처럼 목표 Test Driven Development: 단위 테스트 후 실제 코드 Whole Team: 고객도 프로젝트팀원 Continuous Integration: 상시 빌드/배포 가능 상태 Design Improvement: 불필요한 기능 제거 및 리팩토링 Small Releases: 간단 시스템 빠르게 배포 Coding Standards : 코딩 표준화 Collective Ownership: 모든 개발자가 항시 수정 가능 Simple Design: 간단한 디자인 System Metaphor: 최종 개발 시스템 구조 조망 Sustainable Pace: 오버타임 지양

 

 

 

SCRUM(스크럼)

 

특징	상호 점진적 개발 방법론 매일 정해진 시간/장소에서 단기간 개발을 위한 프로젝트 관리 중심 추정 및 조정 기반의 경험적 관리
5가지 가치	확약 전념 정직 존중 용기
요소	백로그(Backlog): 요구사항 스프린트(sprint): 2-4주의 짧은 개발 기간의 반복적 수행으로 개발 품질 향상 스프린트 회고(spring retrospective): 해당 스프린트가 끝난 시점이나 일정 주기로 스프린트 주기 되돌아보며 정해놓은 규칙 준수 여부 , 개선점 등 확인 및 기록 스크림 미팅: 5분 정도의 계획 미팅 스크림 마스터: 팀 리더 번 다운 차트(Burn Down Chart): 그래픽적 표현

 

 

 

제품 계열 방법론(2010년대)(Product Line Development)

 

특정 제품에 적용하고 싶은 공통된 기능 정의하여 개발

 

 

 

 

테일러링(Tailoring) 개발 방법론

 

특징	개발하려는 S/W 특성에 맞게 융통성있게 적용 표준 프레임워크 기반으로 업무 분야별로 여건에 맞게 수정, 보완 커스터마이징 작업 반복 프로젝트 분석이 가장 중요 개발 프레임 워크: ISO/IEC 12207, CMMI 모델, SPICE 등
필요성	내부 기준 목표 환경 요구 사항 프로젝트 규모 기술 환경 외부 기준 법적 제약 사항 표준 품질 기준

 

 

 

보안 개발 방법론(Secure SDLC)

 

MS-SDL (Microsoft Security Development Lifecycle)	보안 수준 높이기 위해 MS사가 자체적으로 수립
Seven Touchpoints	s/w 보안 모범 사례 SDLC에 통합 - 코드 검토, 아키텍처 위험 분석, 침투 테스트, 위험 기반 보안 테스트, 악용 사례, 보안 요구, 보안 운영
CLASP (Comprehensive Lightweight Application Security Process)	개념, 역할 기반, 활동 평가, 활동 구현 취약성의 5가지 관점에 따라 개발 보안 프로세스 수행
CWE (Common Weakness Enumeration)	보안 취약점 유발 원인 - 입력 데이터 검증 표현, 보안 기능, 시간 및 상태, 오류 처리, 코드 품질, 캡슐화, API 악용
BSIMM (Building Security In Maturity Model)	미국 국토안보국 지원받아 수행된 소프트웨어 보증 프로젝트 결과물 중 하나 보안 활동의 성숙도 수준을 영역별로 측정함으로써 소프트웨어 개발에 필요한 보안 능력 향상 목표로 하는 개발 프레임워크
Open SAMM (Software Assurance Maturity Model)	OWAPSP에서 개발한 개방형 보안 프레임워크 개방 원칙으로 소/중/대규모 점진적 확대가 가능한 융통성 있는 프레임워크 BSIMM과 달리 설계 리뷰/코드 리뷰/보안 테스팅을 중요 검증 활동으로 정의하여 활동 간 연계성 강조

 

 

 

Reference

https://book.naver.com/bookdb/book_detail.naver?bid=17134434 

이기적 정보처리기사 필기 기본서