1 소프트웨어 분류 및 특성
시스템의 기본요소 : 입력(input), 출력(output), 처리(process), 제어(control), 피드백(feedback)
플랫폼의 성능 특성 분석 항목 : 가용성(availability), 응답 시간(response time), 정확성(accuracy), 사용률(utilization)
소프트웨어 프레임워크의 특징 : 모듈화(modularity), 재사용성(reusability), 확장성(Extensibility), 제어의 역 흐름(inversion of control)
##플랫폼과 프레임워크의 차이 : 플랫폼은 서비스제공자&사용자 모두 동시에 운영 / 프레임워크는 서비스 제공자는 제공만(사용자가 뭘 하든 관여하지 않음), 사용자는 사용
프레임워크의 기대 효과 : 개발 용이성, 품질 보증, 변경 용이성, 유지보수, 재사용성, 상호 운용성
기업용 소프트웨어 : 오피스웨어, ERP(enterprise resource planning), SCM(supply chain management), BI(business intelligence), CRM(customer relationship management)
컴포넌트 : 라이브러리의 집합, 독립적으로 사용 가능
컴포넌트 설계시 협약(contract)에 의한 설계를 따를 경우의 조건 : 사용전 참이 되어야 할 선행조건 / 사용후 만족할 결과 조건 / 실행되는동안 항상 만족 되어야 할 불변조건
소프트웨어 공학의 기본 원칙 : 현대적인 프로그래밍 기술 적용 / 지속적인 검증 / 결과에 관한 기록 유지 / 품질 높은 소프트웨어 개발
1-2) 소프트웨어 개발 방법론
운영체제의 종류 : 윈도우, 유닉스, 리눅스, iOS, 안드로이드
운영체제 분석시 고려사항 : 신뢰도(수명), 성능, 기술 지원, 주변기기 지원 여부, 구축 비용
CISC(complex instruction set computer)와 RISC(reduced instruction set computer)의 차이
ㄴCISC : 복잡 / 가변길이의 많은 종류의 명령어(100~250개) / 소프트웨어적 제어방식의 호환성의 좋음 / 속도느림 / CPU에 사용 / 명령어 해석후 실행(컴파일)
ㄴRISC : 간단 / 고정길이의 적은 종류의 명령어 / 하드웨어적 제어방식 호환성 떨어짐 / 속도빠름 / GPU에 사용
DBMS 분석시 고려사항 : 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용
미들웨어의 종류
ㄴDBMS(데이터 베이스 / database management system)
ㄴRPC(원격 / Remote procedure call)
ㄴMOM(메세지 전달 / Message Oriented Middleware)
ㄴTP-Monitor(트랜잭션 모니터링)
ㄴORB(객체 지향 / Object Request Broker)
ㄴWAS(웹서비스 / Web application server)
WAS : DB 접속등의 동적 데이터 처리(이미지등의 정적 데이터는 웹서버가 처리), 데이터접근&세션&트랜잭션 관리
WAS의 종류 ##제공하는 회사랑 특징 하나씩##
ㄴGlassfish : glassfish에서 제공, netbeans 개발툴과 연동시
ㄴJBoss : 레드햇, jboss에서 제공, 오픈소스 이용시
ㄴjetty : 이클립스에서 제공, 빠른 처리 속도
ㄴjeus : 티맥스제공, 기술지원
ㄴresin : caucho 제공, 빠른처리속도
ㄴWeblogic : 오라클제공, 대량의 안정적인 거래 처리
ㄴWebsphere : IBM 제공, 대량의 안정적인 거래 처리
WAS 분석시 고려사항 : 가용성, 성능, 기술 지원, 구축 비용
소프트웨어 개발 방법론
ㄴ구조적 방법론(1970년도) : 프로그램을 구분하여 개발(모듈화)한 후 조립하듯이 개발하는 방법, 이해쉬움, 문서화, 프로세스 중심, 재사용성&유지보수성이 낮음
ㄴ정보공학 방법론(1980년도) : 정보 시스템 개발에 필요한 절차와 기법을 체계화한 방법, 생명주기를 이용해 대형 프로젝트 수행, 데이터 중심, 재사용성 낮음, 기능별로 유지보수 필요
ㄴ객체지향 방법론(1990년도) : 데이터&관련되는 동작을 포함하는 방법, 정보시스템&데이터베이스 설계, 객체지향기법, 캡슐화&추상화 기술 필요, 재사용성 높음
ㄴ컴포넌트 기반 방법론 : 소프트웨어 위기를 극복하기 위한 방법론으로 상용화 돼 있거나 재사용이 가능한 컴포넌트를 조합해서 새로운 애플리케이션을 작성하는 방법론, 공공 행정 정보 시스템 개발에 많이 활용, 개발비용 저렴하고 유지보수 비용 낮음, 반복적&점진적으로 개발, 테스트 환경 미흡
ㄴ애자일 방법론(2000년 이후)
[요구사항 > 설계 > 구현 > 시험]단계를 통해 개발
고객의 지속적인 요구사항에 신속하게 대처(출시 주기 짧음)하기 위한 방법론으로 개발 과정의 소통&협력을 중요시하고 극대화한다
계획이 없거나 혹은 계획이 너무 많은 방법론 사이에서 타협점을 찾은 방법론
가볍고 실용적이며 인간의 수행능력을 높이기 위한 현실적인 방법론
소프트웨어를 점증적으로 개발
기존모형(폭포수(watarfall), 프로토타입, 나선형(spiral)으로 추후에 나옴)의 문제점을 보완
애자일 선언문 : 개인과 상호 작용을 프로세스와 도구보다 중시 / 동작하는 소프트웨어를 포괄적인 문서보다 중시 / 고객과의 협력을 계약의 협상보다 중시 / 변화의 대응을 계획의 수행보다 중시
애자일 방법론의 원칙 : 소통, 협력, 적응, 지속, 가치 전달, 피드백
애자일 방법론의 5가지 가치 : 의사소통, 용기, 피드백, 단순함, 존경
애자일 방법론의 종류
ㄴXP(익스트림 프로그램) : 애자일의 대표적인 방법
ㄴscrum(스크럼) : 매일 정해진 시간과 장소에서 단기간에 개발하는 방법, 5가지 가치(확약,전념,정직,존중,용기) 추구한다.
4가지요소(백로그, 스프린트 , 미팅, 스크럼 마스터)가 있다.## youtu.be/oS5lQi72OVM 설명 잘 돼 있음
ㄴLean(린) : 개발 프로세스의 낭비적인 부분을 제거한 방법으로 7가지 원칙(낭비요소 제거, 품질 내재화, 지식 창출, 가능한 늦게 결정, 가능한 빠르게 인도, 사람 존중, 전체 공정 최적화)이 잇다.
테일러링 개발 방법론
ㄴ서로 다른 개발 환경에서 개발되는 다양한 종류의 프로젝트를 하나의 일관된 개발 방법론으로 적용하기 위해 등장. 프로젝트 여건에 맞게 수정&보완하는 융통성있는 방법론
ㄴ가장 중요시하는 부분은 프로젝트 분석으로 프로젝트의 다양한 특성을 분석하여 쉽게 해결하고 진행이 용이하도록 해야 함
보안 개발 방법론
ㄴMS-SDL(마이크로소프트 시큐어 디벨롭 라이프사이클) : MS사에서 수립한 SDLC(소프트웨어 디벨롭 라이프 사이클)
ㄴSeven touchpoints : 소프트웨어 보안의 모범사례(실무적으로 검증)를 SDLC에 통합한 보안 방법론, 7가지 체크 포인트가 있음
ㄴCLASP : 개발 초기 단계에서 보안 강화를 위한 활동 중심 역할 기반의 정형화된 프로세스, 이미 운영중인 시스템에 적용하기 용이함
ㄴCWE : 보안 취약점을 유발하는 원인을 7가지로 정리한 방법론
1-3) 프로젝트 관리 및 생명주기 모형
프로젝트의 곤리 : 일정 관리, 예산 관리, 인력 관리, 위험 관리, 품질 관리
프로젝트 관리의 3P : 사람(People), 문제(Problem), 프로세스(Process)
프로젝트 계획 수립 목적 : 범위, 자원, 비용측정을 통하여 위험성을 최소화
프로젝트 범위(영역, Range, scpoe) 측정 요소 : 처리기능, 성능, 제한 조건, 개발 인원, 일정 계획
개발자팀의 구성 방법
ㄴ책임 프로그래머 팀 : 1인 독재 체제. 한명(책임(chief)프로그래머 : 요구분석 설계, 판단, 작업지시 배분)을 3명(backup : chief 보좌, 기술자문, chief감도하에 분석 설계 구현 / programer : 코드작성&디버깅&문서작성 / librarian : 문서관리)이 보조.
ㄴ민주주의식 팀 : 책임 프로그래머팀이랑 반대되는 특징이 있음
ㄴ혼합형팀
위험 관리 순서 : 위험 식별, 위험 분석 및 평가, 위험 관리 계획, 위험 감시 및 조치
비용 측정 요소
ㄴ직접 측정 요소 : 인월(사람인, 달월. 한사람이 한달 작업량), 비용, LOC(Line Of Code), 투입 인원 등 바로 측정이 가능한 요소
ㄴ간접 측정 요소 : 생산성, 품질, 기능점수(FP),문서화 비율 등 비교 대상이 있어야 측정 가능한 요소
비용측정의 원칙
ㄴ비용 측정은 최대한 늦게 : 최대한 마지막에 할 수록 놓치는 부분이 없다.
ㄴ분해 기술 이용 : 기능별로 최대한 분리해서 각각 비용 측정후 더해서 전체비용을 측정해야 함
ㄴ실험적 비용 측정 모델 이용 : 사전에 개발된 소프트웨어 비용 참고
ㄴ자동화 도구 이용 : SLIM과 같은 비용 측정 프로그램 이용
개발 비용과 개발 기간은 반비례 : 개발 기간 짧으면 비용 증가, 개발기간 증가하면 비용 감소
비용 측정 방법론의 종류
ㄴ전문가 측정 : 개발 비용을 전문적으로 측정하는 사람에게 의뢰
ㄴ델파이(delphi) 측정 : 1.여러 전문가에게 의뢰 > 2.전문가는 비용 제출 > 3.비용을 전체 공개 > 1~3 반복하여 평균치를 최종 비용으로 결정
ㄴLOC 측정 : 소프트웨어 기능별(입력, 출력, 처리)로 나눠서 [낙관치 + ( 4 * 기대치) + 비관치 / 6 = 예측치] 공식 사용
ㄴ단계별 인월 측정 : LOC 측정의 단점을 보완한 방법으로 라인수 대신 기능별 중요도에 따른 인월수로 계산
ㄴWaslston 측정 : 미국의 60개 개발업체에서 자료 수집하여 만든 공식으로 단점이 많음
ㄴCOCOMO 모형 : Walston 측정의 단점을 보완하여 소프트웨어의 규모에 따라 3가지로 분류.
유기형(organc) : 5만라인 이하의 중소 규모 비즈니스 처리용
준 분리형(semi-detached) : 30만 라인 이하의 데이터베이스 관리 시스템
내재형(embedded) : 최대형 규모
ㄴPutnam 모형 : 대형 프로젝트에서 이용되는 기법, Rayleigh-norden 곡선의 노력 분포도 곡선 이용, SLIM이 Putnam 모형을 기초로 함
ㄴ기능 점수 모형 : 국제 표준. 개발자가 아닌 사용자 관점의 5가지(입력, 출력, 사용자 명령어, 데이터 파일, 인터페이스)의 갯수를 산정 요소로 사용
형상 관리 : 개발과정에서 산출물의 변경사항을 버전관리하기 위한 일련의 활동으로으로 비용은 관리 항목이 아님, 절차 : 형상 식별 > 변경 제어 > 형상 상태 보고 > 형상 감사
비용은 형상관리 항목이 아님
소프트웨어 개발의 생명 주기 모형
ㄴ폭포수(워터폴) 모형 : 많이 사용된 오래된 전통 기법, 단계별&순차적 작업, 현작업이 제대로 완료되야만 다음으로 넘어감, 단계별 무서화 작업 필요, 새로운 요구를 반영하기 어려움, 고객의 만족도는 결과물이 나와야만 확인 가능
ㄴ프로토타입 모형 : 고객의 요구에 맞게 빠르게 프로토타입 구축 후 고객의 요구사항에 맞게 다시 설계하는 방식, 요구사항의 변경이 용이, 요구사항이 불명혹한 경우 적용하기 좋음, 최종 결과물에 대한 예측 가능한 모형. 요구사항 관리가 중점
ㄴ나선형 모형 : 계획 수립 > 위험 분석 > 개발 및 검증 > 고객 평가 > 계획 수립... 반복, 위험 관리가 중점, 폭포수 모형과 프로토타입 모형의 장점을 살림. 대규모 시스템 개발에 용이
ㄴV 모형 : 검증을 강조한 기법. 오류 발생시 각 단계별로 매칭되는 단계로 돌아가서 다시 작업, 높은 신뢰성을 필요로 하는 의료 제어 시스템 개발에 용의
품질 관리 모델 종류
ㄴISO 12207 표준 : 개발 프로세스를 정의하고 향상시키기 위한 프로세스로 기본공정 / 지원공정 / 조직공정으로 구성
ㄴISO/IEC 품질 특성 : 기능성(Function), 신뢰성(reliable), 사용성(usable), 효율성(efficiency), 유지보수성(maintain), 이식성(portable)
각 특성별로 하위 특성이 있는데 그중 준수성은 신뢰성을 제외한 모든 특성의 하위 특성임
ㄴCMM : 소프트웨어 개발과 유지보수에 대한 프로세스 개선과 능력 향상을 위한 실용화된 모델
5가지 단계[초기 > 반복 > 정의 > 관리 > 최적] 와 5가지 Level별[1:혼돈 / 2:경험 / 3:정성 / 4:정량 / 5:최적]관리 평가 기준이 있음
ㄴSPICE 모델 : 소프트웨어의 품질 및 생산성 향상을 위해 프로세스를 평가 및 개선하는 모델
6가지 단계[불안정 > 수행 > 관리 > 확립 > 예측 > 최적화]로 구분
ㄴCMMI : CMM의 후속모델로 4가지 관리 영역(프로세스 / 프로젝트 / 엔지니어링 / 지원)으로 나눔
요구사항 개발 프로세스 : 도출 > 분석 > 명세 > 확인
자료 흐름도(DFD)표기법
외부 입출력(terminal) : 네모 / 처리 과정(process) : 동그라미 / 자료 흐름(data-flow) : 화살표 / 자료 저장소(data-store) : 작대기 두줄
자료 사전(DD)의 표기법
정의 : =
연결 : +
선택 : [ | ]
반복 : {}n
생략 : ()
설명 : **
요구사항 분석 자동화 도구(CASE)
ㄴSADT : softect사에서 개발된 대규모 프로젝트용 분석 자동화 도구, 요구분석과 설계 분석, 설계 명서세를 동시에 표현, 블록 다이어그램을 채택
ㄴBS : 사용자의 의견을 듣는 개발자의 자세 및 규칙, 비판금지&자유분방&다수환영&연쇄개선
ㄴPSL/PSA : 미시간 대학의 ISDOS 프로젝트에서 개발된 자동화 도구,PSL 언어로 작성&PSA로 DB에 저장-분석
ㄴSREM,RSL/REVS : TRW사에서 개발
요구사항의 기술적 타당성 검토
ㄴ성능 및 용량 산정 적정성 > 시스템 간 상호 운용성 > IT시장 성숙도 및 트렌드 부합성 > 기술적 위험 분석(복잡성&검증여부&의존성)
에플리케이션 설계
모듈의 5가지 기본요소 : 입력, 출력, 기능, 기관, 내부자료 요소
모듈의 공유도(Fan-in)와 제어도(Fan-out)
ㄴ공유도 : 상위 모듈의 수, 공유도가 높을 경우 해당 클래스를 사용하는 클래스의 수가 많다는것을 의미
ㄴ제어도 : 하위 모듈의 수, 제어도가 높을 경우 하나의 모듈이 많은 수의 다른 모듈을 사용한다는것을 의미
공통 모듈의 원칙 : 정확성(correctness), 명확성(clarity), 완전성(completeness), 일관성(consistency), 추적성(traceability)
모듈 결합도(결합도가 낮을 수록 높은 품질) : 자료 결합도 > 스탬프 결합도 > 제어 결합도 > 외부 결합도 > 공통 결합도 > 내용 결합도
ㄴ자료 결합도(data) : call by value 가장 좋음, 두 모듈간의 인터페이스가 자료 요소만으로 구성된 결합, 모듈간 인터페이스로 전달되는 파라미터를 통해서만 상호 작용이 일어남
ㄴ스탬프 결합도(stamp) : 두 모듈간 동일한 자료 구조를 조회하는 경우의 결합성,객체나 구조적인 데이터등이 전달
ㄴ제어 결합도(control) : 처리하는 방법을 제어 요소로 전달되는 경우로 모듈간에는 제어변수로 종속적인 관계를 갖음
ㄴ외부 결합도(extern) : 외부 변수에 의해 영향을 받는 경우,
ㄴ공통 결합도(common) : 모듈이 다른 모듈의 내부 자료를 참조하는 경우 call by reference
ㄴ내용 결합도(content) : 다른 모듈의 내부 기능 및 자료를 참조하는 형태, 가장 안좋음
모듈 응집도(응집도가 낮을수록 낮은 품질) : 우연적 > 논리적 > 시간적 > 절차적 > 통신적 > 순차적 > 기능적
ㄴ우연적(coincidental) : 어떤 의미 있는 연도 없고 관계 없이 묶인 가장 안좋은 응집도
ㄴ논리적(logical) : 모듈 내부의 루틴들이 같은 범주에 속하는 기능끼리 묶인 경우
ㄴ시간적(temporal) : 시간적으로 수행시기가 같은 기능끼리 묶인 모듈
ㄴ절차적(procedure) : 수행 시기의 순위가 있는 기능끼리 묶인 모듈,순차적으로 수행하는 경우
ㄴ통신적commucation) : 작업 대상이 같은 기능끼리 묶인 모듈
ㄴ순차적(sequetial) : 구성요소들이 이전의 명령어로부터 나온 결과를 다음 명령어의 입력자료로 사용하는 경우
ㄴ기능적(function) : 모듈내부가 하나의 단일 기능으로 존재, 프로그래밍 언어의 라이브러리같은 것
