개발 기술 환경의 정의

• 개발하고자하는 소프트웨어와 관련된 운영체제, 데이베이스 관리 시스템(DBMS), 미들 웨어 등을 선정할 때 고려해야 할 사항을 기술, 오픈 소스 사용시 주의해야 할 내용을 제시

운영 체제(OS; Operating System)

• 운영 체제 -> 컴퓨터 시스템 자원 효율적 관리
• 사용자와 하드웨어 간 인터페이스

운영체제 관련 요구사항 식별 시 고려사항

• 가용성: 장시간 운영으로 인한 장애, 메모리 누수 , 보안/에러 패치로 인한 재가동
• 성능: 대규모 사용자 처리, 대용량 파일 처리, 지원가능한 메모리 크기(32bit, 64bit)
• 기술 지원: 제작자의 기술지원, 여러 사용자간 커뮤니티, 오픈소스 여부
• 주변기기: 설치 가능한 하드웨어, 주변 기기 지원 여부
• 구축 비용: 히드웨어 비용, 라이선스, 유지관리 비용, 총 소유비용(TCO)

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

• 사용자와 데이터 베이스 사이에서 사용자의 요구에 따라 정보를 생성, 데이터베이스를 관리
• 기존 파일 시스템(각 응용 프로그램들이 개별적으로 자기 데이터를 file로 관리)의 데이터 종속성과 중복성 문제 를 해결하기 위해 제안됨
• 데이터 종속성: 데이터의 구성방식이나 접근 방법에 대한 응용 프로그램과 데이터 간의 상호 종속 관계
• 데이터 중복성: 같은 데이터를 여러 응용 프로그램에서 이용해야 하는 경우
• 모든 응용 프로그램이 데이터베이스를 공용 할 수 있도록 관리
• 데이터베이스 구성, 접근 방법, 유지관리 에 대한 모든 책임을 짐
• Oracle, DB2, MS SQL Server, MySQL, SQLite, MongoDB, Redis

DBMS 관련 요구사항 식별 시 고려사항

• 가용성: 백업/복구의 편의성, DBMS 이중화 지원 여부
• 성능: 대규모 데이터 처리, 분할 테이블 지원 여부, 대용량 트랜잭션 처리, 다양한 튜닝 옵션, 비용기반 질의 최적화(질의의 대한 다양한 실행방법을 만들고 각각의 방법에 대한 비용을 추정)
• 기술지원: 제작자의 기술지원, 커뮤니티, 오픈소스
• 상호 호환성: 설치 가능한 운영체제, JDBC/ODBC 여부(JDBC: 자바와 DB를 연결해주는 인터페이스, ODBC: 응용 프로그램과 DB를 연결해주는 인터페이스)
• 구축 비용: 라이선스,, 유지관리, 총 소유비용

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

• 정적인 콘텐츠 -> 웹서버, 동적인 콘텐츠 -> 웹 어플리케이션 서버
• 데이터 접근, 세션 관리, 트랜잭션 관리 를 위한 라이브러리
• 주로 데이터베이스 서버와 연결
• TomCat, GlassFish, JBoss, Jetty, JEUS, Resin,, Web Logic, Websphere

웹 어플리케이션 서버 관련 요구사항 식별 시 고려사항

• 가용성: 고유적인 장애, 안정적 트랜잭션, WAS 이중화 지원여부
• 성능: 대규모 트랜잭션 처리 여부, 다양한 설정 옵션, 가비지 콜렉션(사용하지 않는 메모리 공간을 강제로 해제하는 기법) 지원
• 기술지원: 안정적인 기술지원, 커뮤니티, 오픈 소스 여부
• 구축 비용: 라이선스, 유지/보수 비용, 총 소유 비용

오픈 소스 사용에 따른 고려사항

• 오픈소스: 누구나 별 다른 제한 없이 사용할 수 있도록 소스코드를 공개한 것, 오픈소스 라이선스를 만족하는 소프트웨어
• 라이선스의 종류, 사용자 수, 기술의 지속 가능성 을 고려

현행시스템 파악 절차

• 왜 현행 시스템을 파악해야 하는가?: 새로운 소프트웨어의 시스템 개발 범위 를 명확히 설정하기 위해
• 절차: 시스템 구성, 기능, 인터페이스 파악 -> 아키텍처, 소프트웨어 구성 파악 -> 하드웨어, 네트워크 구성 파악

시스템 구성 파악

• 현행 시스템의 구성 -> 기간 업무(조직의 주요업무) + 지원 업무
• 단위 업무 정보시스템들의 명칭, 주요기능 명시

시스템 기능 파악

• 현행 시스템의 기능을 주요기능 > 하부기능 > 세부기능 으로 계층형으로 구분

시스템 인터페이스 파악

• 시스템 간 주고 받는 데이터의 종류, 형식, 프로토콜, 연계유형, 주기 등을 명시

아키텍처 구조 파악

• 아키텍처 구성도 로 기술 요소들을 계층별로 표현
• 업무별로 아키텍처가 다를 땐 가장 핵심이 되는 기간 업무 처리시스템의 아키텍처를 기준으로 한다.

소프트웨어 구성 파악

• 업무별로 설치되어 있는 소프트웨어 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시한다.
• 시스템 구축 비용 중 소프트웨어 비용이 비중 多 -> 라이선스 적용 방식의 기준과 보유한 라이선스의 파악이 중요

하드웨어 구성 파악

• 서버의 주요 사항과 수량, 이중화 작용 여부 명시
• 이중화(Replication): 서버에 문제가 생겨도 대기서버로 서비스할 수 있도록 서버의 자료변경을 대기서버에도 적용하게 하는 것
• 서버의 이중화는 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요 여부가 결정 된다.
• 현행 시스텡메 이중화가 적용되면 새로 구성될 시스템에도 필요하므로, 이로 인한 비용 증가와 시스템 구축 난이도가 높아질 가능성을 고려해야 함

네트워크 구조 파악

• 서버의 위치, 네트워크 연결 방식을 네트워크 구성도 로 작성
• 서버의 물리적 위치 파악 가능, 보안 취약점 분석
• 네트워크 장애시 발생원인을 찾아 복구하기 위한 용도

XP (eXtream Programming)

• 뜻: 생산성 향상을 위해 고객의 참여와 개발과정 반복을 극대화

• 특징

  • 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여 -> 소프트웨어 빠르게 개발
  • 릴리즈 기간 ↓, 요구반영 가시성 ↑
  • 테스트 마다 고객 직접 참여
  • 소규모 인원 개발 프로젝트에 효과적

• XP의 5가지 핵심가치

  • 의사소통
  • 단순성
  • 용기
  • 존중
  • 피드백

XP 개발 프로세스

사용자 스토리(User Story)

• 요구사항 시나리오(ex. 고객은 상품 주문을 위해 로그인을 수행해야 한다)
• 기능단위로 구성, 테스트 사항 기재

릴리즈 계획 수립(Release Planning)

• 부분 혹은 전체 개발완료 시점에 대한 일정을 수립

스파이크(Spike)

• 요구사항 대한 신뢰성을 높이고 기술문제에 대한 위험을 감소시키기 위해 별도로 만드는 프로그램
• 처리할 문제 외의 다른 조건은 무시

이터레이션(iteration)

• 하나의 릴리즈를 더 세분화한 단위
• 새로운 스토리가 작성될 수 있음

승인 검사(Acceptance test, 인수 테스트)

• 소규모 릴리즈 -> 고객의 반응을 기능별로 확인
• 릴리즈 기간이 완료되면 고객에 의한 최종 테스트 후 릴리즈

XP의 주요 실천 방법

• Pair Programming: 다른 사람과 같이 프로그래밍하고 개발에 대한 책임을 나눔
• Collective Ownership: 코드에 대한 권한과 책임을 공동 소유
• Test-Driven Development: 코드 작성전 테스트 케이스를 먼저 작성, 자동화된 테스트 도구 사용
• Whole Team: 모든 구성원은 역할에 대한 책임을 져야 함
• Continuos integration: 모듈 단위로 구성된 코드들을 지속적으로 통합
• Design improvementL 기능 변경 x, 단순화와 유연성 강화로 시스템 재구성
• Small Release: 릴리즈 기간 짧게, 요구변화 신속 대응