현행시스템 파악 개념
현행시스템이 어떤 하위시스템으로 구성되어있고, 제공 기능 및 연계정보는 무엇이며 어떤 기술요소를 사용하는지를 파악하는 활동
현행시스템 파악 절차
구성/기능/인터페이스 파악 -> 아키텍처 및 소프트웨어 구성 파악 -> 하드웨어 및 네트워크 구성 파악
소프트웨어 아키텍처
- 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소간의 관계를 표현하는 시스템의 구조나 구조체
- 소프트웨어를 설계하고 전개하기 위한 지침이나 원칙
소프트웨어 아키텍처 프레임워크 구성요소
- 아키텍처 명세서
- 이해관계자
- 관심사
- 관점
- 뷰
소프트웨어 아키텍처 4+1 뷰
고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법 -> 유스케이스 사용
운영체제의 개념
컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용 할 수 있도록 해주고, 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램
OSI 7계층 ( 아파서 티내다, 피내다 )
DBMS (Database Management System)
- 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리 할 수 있는 기능들을 제공하는 응용 프로그램
- 기능 : 중복제어, 접근 통제, 인터페이스 제공, 관계 표현, 시딩/파티셔닝/무결성 제약조건, 백업 및 회복
JDBC (Java Database Connectivity)
- 자바에서 데이터베이스를 사용할 수 있도록 연결해주는 응용 프로그램 인터페이스
- SQL을 사용하여 DBMS에 질의하고 데이터를 조작하는 API 제공
ODBC (Open Database Connectivity)
데이터베이스를 액세스하기 위한 표준 개방형 응용 프로그램 인터페이스
미들웨어
- 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어
- OS와 SW사이에 위치한다. ex) WAS
웹 어플리케이션 서버 (WAS)
웹 어플리케이션 서버는 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜젝션 처리와 관리, 다른 기종 시스템과의 애플리케이션 연동을 지원하는 서버
요구사항
문제의 해결 또는 목적 달성을 위하여 고객에 의해 요구되거나, 표준이나 명세 등을 만족하기 위하여 시스템이 가져야 하는 서비스 또는 제약사항
■ 기능적 요구사항
개념 : 시스템이 제공하는 기능, 서비스에 대한 요구사항
도출방법 : 특정 입력/상황에 대해 시스템이 어떻게 반응/동작해야 하는지에 대한 기술
특성 : 기능성, 완전성, 일관성
사례 : 최종주문 완료되면 배송추적 가능해야 함
■ 비기능적 요구사항
개념 : 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항
도출방법 : 품질 속성에 관련하여 시스템이 갖춰야할 사항에 대한 기술
특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성
사례 : 특정 함수의 호출시간은 3초가 넘지 않아야 한다.
요구사항 개발 프로세스
요구사항 도출 -> 요구사항 분석 -> 요구사항 명세 -> 요구사항 확인 ( 도분명확 )
동료검토 - 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행한다.
워크스루 - 검토 자료를 회의 전에 배포해서 사전검토 한 후 짧은 시간 동안 회의를 진행하는 형태, 리뷰로 오류검출 문서화한다.
인스펙션 - 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토방법.
요구사항 관리 프로세스
요구사항 협상 -> 요구사항 기준선 -> 요구사항 변경 관리 -> 요구사항 확인 및 검증
CCB(Configuration Control Board: 형상 통제 위원회)
형상 항목에 대한 형상 베이스라인이 승인된 후, 발생되는 형상 항목의 변경에 대하여 평가, 조정, 승인/보류/기각을 결정하는 심의 조직
요구사항 분석기법
요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석
요구사항 확인기법
요구사항 검토, 프로토타이핑, 모델검증, 인수테스트
프로토타이핑
사용자가 요구한 주요 기능을 Prototype으로 구현하여, 사용자의 피드백을 통해 개선, 보완하여 완성 소프트웨어를 만들어가는 기법
UML
객체지향 소프트웨어 개발과정에서 산출물을 명세화, 시각화, 문서로 만들 시 사용되는 모델링 기술과 방법론을 통합해 만든 표준화된 범용 모델링 언어
요구사항 확인 프로세스
- 요구사항 목록 확인
- 요구사항 정의서 작성 여부 확인
- 비기능적 요구사항의 확인
- 타 시스템 연계 및 인터페이스 요구사항 확인
비용 산정 모델
소프트웨어 규모 파악을 통한 투입자원, 소요 시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 기법
■ 하향식 산정방법
경험 많은 전문가에게 비용산정을 의뢰, 여러 전문가와 조정자를 통해 산정하는 방식 (전문가 판단, 델파이 기법)
■ 상향식 산정방법
세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식 (코드 라인 수(Loc), Man Month, COCOMO 모형, Putnam 모형, FP 모형)
예) Loc=500,000 => 한 프로그래머 한달에 25,000라인 개발
Man Month => 500,00 / 25,000 = 50개월
Man Month가 50개월 일 때, 10명이 프로젝트를 수행한다면 총 기간은 ? => 50/10=5개월
하향식 산정방법 종류
전문가 판단 - 조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용산정을 의뢰하는 기법
델파이 기법 - 전문가의 경험적 지식을 통한 문제해결 및 미래 예측을 위한 기법
상향식 산정방법 종류
LoC - 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측지를 구하고 이를 이용하여 비용 산정 => 이해 쉽고 측정이 쉽다.
Man Month - 한 사람이 1개월동안 할 수 있는 양을 기준으로 프로젝트 비용을 산정하는 기법
COCOMO - Constructive cost Model의 약자
- 보헴이 제안, 프로그램 규모에 따라 비용을 산정
- 개발 노력 승수를 결정
