본문 바로가기
반응형

IT 이론/소프트웨어공학29

DSDM 애자일 개발 방법론 RAD를 기반으로 출발하여 분화된, 원칙과 모범 사례 중심의 애자일 방법론 처음엔 Dynamic Systems Development Method의 약자였지만, IT 시스템 개발에 국한되지 않기 위해 해당 풀네임을 버린다고 공표하였다. 종종 Driving Strategy, Delivering More로 불리고 있지만 공식 명칭은 아니다. 스크럼 등에 비해 국내에서 많이 알려진 방법론은 아니지만, Time Boxing, 워크숍 등의 기법은 다른 애자일 방법론에서도 많이 참조되고 사용된다. 1. 특징 RAD 기반 RAD의 세부 실천방안으로 출발, 이후 별도로 분화됨 모범사례 기반 Best Practice를 기반으로 방법론 제시 도메인 독립성 IT 뿐만 아니라 다양한 프로젝트에 적용 가능 2. 8가지 원칙 Fo.. 2019. 12. 14.
리먼의 소프트웨어 변화 법칙 원문 소프트웨어 공학에서 소프트웨어 유지보수 시에 자주 인용되는 리먼의 소프트웨어 번화 법칙(원리)이다. 법칙을 실무에서 바로 적용할 순 없기에 주로 인용되고 가공되어서 사용된다. 애초에 리먼이 말하고자 했던 내용의 의도가 왜곡되기도 한다. 오리지널한 내용은 무엇일까 찾아봐도 대부분은 정리된 자료 뿐이다. 그래서 찾은, 리먼이 직접 작성한 문서를 올려둔다. 본래 의미, 의도가 궁금할 때 참조하면 된다. 한국에선 어째서인지 'Lehman's Laws of Software Evolution"을 "Lehman 소프트웨어 변화 원리"라고 이상하게 번역한다. 마치 Lehman이 한국어로 표현하기 힘든 이름인 것 같다. 그리고 법칙(Law)과 원리(Principle)는 엄연히 다른 말이다. Lehman은 우리가 흔히 알.. 2019. 10. 19.
애자일 개발 방법론: 익스트림 프로그래밍 eXtreme Programming; XP 방법론 애자일 방법론 중 하나로, 비즈니스 상의 요구가 시시각각 변동이 심한 소규모 프로젝트에 적합한 개발 방법론 10~12개 정도의 구체적인 실천 방법(Practice)을 정의 짧은 주기로 여러번 고객에게 납품 반복 개발 문서 보다는 소스코드를, 조직적인 개발 보다는 개개인의 책임과 용기를 중시 1. 장단점 장점 문서 작성 최소화로 개발 효율 증가 의사소통과 빠른 피드백을 통한 소프트웨어 품질 향상 단점 대규모 프로젝트엔 적용 어려움 참여하는 개인의 성향에 따라 프로젝트의 품질 차이 발생 2. 핵심 가치 출처 용기: 문서로 변명하기 보단 진실되고 용기있게 개발 존중: 개발자의 역량을 존중하고 충분한 권한과 권리 부여 의사소통: 이해관계자 모두가 팀원이라는 생각.. 2019. 7. 14.
[PMP] 이해관계자 참여 관리 - PMBOK 시험범위 정리 0. 이해관계자 관리 개요 1. 이해관계자: 고객, 스폰서, 수행조직 등 프로젝트에 적극 가담하거나 주변 개인 등 프로젝트로 인해 영향을 받게 되는 전체 2. 이해관계자 관리 프로세스 ㅇ 착수: 이해관계자 파악(Identify Stakeholder) => 이해관계자 등록부 ㅇ 계획수립: 이해관계자 참여 계획 수립(Plan Stakeholder Management) => 이해관계자 참여 계획서 ㅇ 실행: 이해관계자 참여 관리(Manage Stakeholder Engagement) => 변경 요청 ㅇ 감시 및 통제: 이해관계자 참여 감시(Monitor Stakeholder Engagement) => 작업 성과 정보, 변경 요청 1. 이해관계자 파악 1. 정의: 이해관계자의 관심도(Interest), 상호의존.. 2019. 5. 27.
[PMP] 프로젝트 조달 관리 - PMBOK 시험범위 정리 0. 프로젝트 조달 관리 개요 ㅇ 프로젝트 팀 외부로부터 제품, 서비스 등을 구매하기 위한 프로세스 ㅇ 계약서, 구매 주문서, 양해 각서, 서비스 수준 합의서 등의 협약 관리 ㅇ 구매자 계약서 판매자 - 구매자: 고객, 주 계약자, 계약자, 획득 조직, 서비스요청자, 구매처 - 계약서: 합의서, 양해각서, 하청계약서, 구매주문서 - 판매자: 계약자, 하도급업체, 거래업체, 서비스 제공자, 공급업체 ㅇ 조달을 통해 프로젝트 리스크를 판매자에게 전가(Transfer), 공유(Share) 가능 ㅇ 하부 프로세스 - 계획수립: 조달관리 계획수립(Plan Procurement Management) - 실행: 조달 수행(Conduct Procurements) - 감시 및 통제: 조달 통제(Control Procur.. 2019. 5. 26.
[PMP] 프로젝트 리스크 관리 - PMBOK 시험범위 정리 0. 프로젝트 리스크 관리 개요 1. 프로젝트 리스크관리의 정의 및 용어 ㅇ 개별 프로젝트 리스크들(Individual Project Risks) ㅇ 종합적인 프로젝트 리스크(Overall Project Risk) ㅇ 리스크 대응태도(중립적, 회피, 추구)를 결정 짓는 요소 - 리스크 수용범위(Risk Appetite) - 리스크 임계치(Risk Threshold) - 리스크 허용한계(Risk Tolerance) ㅇ Unknown Risk vs Known Risk 2. 리스크 하부 프로세스들 ㅇ 계획수립(Plan) - 리스크관리 계획수립(Plan Risk Management) - 리스크 파악(Identify Risks) - 정성적 리스크 분석 수행(Perform Qualitative Risk Analys.. 2019. 5. 26.
제안요청서 최소구비요건 요구사항 구성 제안요청서(RFP, request for proposal) 1. 시스템장비구성 요구사항(ECR, Equipment Composition Requirement)구축 장비의 안전성을 위해 필수적인 사항을 기술한 것 2. 기능 요구사항(SFR, System Function Requirement)목표시스템이 반드시 수행해야 하거나 목표시스템을 이용하여 사용자가 반드시 수행할 수 있어야 하는 기능(동작) 개발 요구사항 3. 인터페이스 요구사항(SIR, System Interface Requirement)사용자에게 목표시스템을 편리하게 사용할 수 있는 환경을 제공하는 설계 내용에 대해 기술한 것 4. 데이터 요구사항(DAR, Data Requirement)목표시스템의 서비스에 필요한 DB 설계 등 데이터를 구축하기.. 2018. 11. 12.
블랙박스 테스트(Blackbox Test) 소프트웨어 인터페이스에서 실시되는 검사로, 소프트웨어가 수행할 기능을 중심으로 기능이 완전히 작동되는 것을 입증하는 검사화이트박스 테스트가 소프트웨어의 특정 로직이 제대로 동작하는지 보기 위한 개념이라면 블랙박스 테스트는 그보다 더 거시적으로 스프트웨어가 원하는 방향대로 잘 동작하는지 테스트하는 개념이다. 주로 Development 단계에서 개발자들이 수행하는 테스트가 화이트박스 테스트, 이후 QA단계에서 테스트 전담자(팀)이 수행하는 테스트가 화이트박스 테스트이다. 종류는 아래와 같다. - 동치 분할 검사(Equivalence Partitioning Test)입력 자료에 초점을 맞춰 테스트케이스를 만드는 방법으로, 프로그램 로직의 조건에 타당한 입력자료와 타당하지 않은 입력자료를 균등하게 배분하여 검사.. 2017. 7. 10.
Booch 객체지향 분석 방법 - 미시적 개발 프로세스와 거시적 개발 프로세스를 모두 포함한다. - 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의한다. - 클래스와 객체의 의미를 식별한다. - 각 작업에 대한 다이어그램, 클래스 계층 정의, 클래스들의 클러스터링 작업을 수행한다. - 클래스와 객체를 구현한다. 2017. 7. 10.
HIPO Model(HIPO Chart 또는 HIPO Diagram) HIPO는 Hierarchical Input Process Output의 약자로, Input-Process-Output으로 이루어진 모듈을 계층적으로 나타낸 도표이다.시스템의 분석 및 설계나 문서화에 사용 되는 기법으로 계층을 구성하는 각 모듈별 실행 과정인 입력, 처리, 출력 기능을 나타낸다. HIPO는 3가지 종류가 있다. 3가지를 따로 쓰는 것이 아니라 3가지로 이루어진 것이다. 가시적 도표(Visual Table of Contents) aka.도식 목차시스템의 전체적인 기능과 흐름을 보여주는 Tree형태의 구조도 총체적 도표(Overview Diagram) aka.개요 도표프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표 세부적 도표(Detail D.. 2017. 7. 10.
OMG의 OMA 레퍼런스 모델 OMG(Object Management Group)에서 제시한 OMA(Object Management Architecture) Reference Model은 다음의 5개 구성 요소로 구성된다. - 객체 요구 매개자(Object Request Broker)객체 간의 메시지 송수신을 처리하는 기능, 이 기능의 표준 규격이 CORBA 임 . ORB는 객체 버스이다. 이것은 객체가 다른 지역 객체 또는 원격 객체로부터 투명하게 서비스를 요청하고 응답받을 수 있도록 해준다. - 객체 서비스(Object Services)객체가 실행하는 처리를 지원하는 기본적인 기능의 집합, 그 표준 규격이 CORBA 서비스임 - 공통 기능(Common Facilities)응용 객체를 실행할 때에 제공되는 편리한 공통 기능의 집합 .. 2017. 7. 10.
소프트웨어 재공학(Reengeneering) 재공학은 기존 프로그램의 개선이나 유지보수의 관점에서 작게 볼 수도 있으나 실제로 그보다 큰 규모의 구조적 재설계를 의미하는 경우가 많다. 어찌보면 미묘한 차이일수도 있지만 굳이 구분을 해 보자면 아래와 같다. 오류 투성이의 프로그램을 쓰면서 새로운 기능이 좀 필요하면 추가도 하고 틈틈이 시간이 나면 오류를 수정해 나간다. 이는 유지보수이다.도서히 안되겠다 싶어 프로그램을 갖다 버리고 새로 도입하려다 보니 금전적으로 부담이 되기도 하고 새롭게 개발된 프로그램이 사용성이나 안정성 면에서 더 나을거란 보장이 없다. 그래서 지금 있는 프로그램을 뒤집어 엎어서 구조적인 부분부터 다시 점검해서 오류가 없도록 전면적인 수정을 한 뒤 리뉴얼을 하여 다시 오픈했다. 이는 재공학이다. 물론 재공학은 유지보수의 범주에 포.. 2016. 9. 19.
소프트웨어 재사용(Reuse) 재사용이라고 하면 단순히 예전에 만들어 놨던 것을 다시 또 사용한다는 단순한 느낌이지만, 실제로는 표준화된 솔루션, 라이브러리, 오픈소스 등이 모두 재사용의 범주에 들어간다고 할 수 있다. 개요 : 이미 개발되어 인정받은 소프트웨어의 전체 혹은 일부분을 다른 소프트웨어 개발이나 유지보수에 사용하는 것재사용 요소 : 전체 프로그램, 부분 코드, 응용된 지식, 데이터 모형, 구조, 테스트 계획, 문서화 방법 등 즉, 웹페이지 레이아웃을 비슷하게 구현했다면, 다른 개발건에서 나왔던 메뉴얼이 양식을 그대로 차용했다면 이 또한 재사용이다. 정말 포괄적인 범위의 재사용을 말하는 것이다. 재사용의 이점 - 개발 시간과 비용을 단축시킨다. - 소프트웨어 품질을 향상시킨다. - 프로젝트 실패의 위험을 감소시킨다. - 시.. 2016. 9. 19.
소프트웨어 검사(Test) 전략 순서는 다음과 같다 1. 단위(코드) 검사 - 코딩이 이루어 진 후 모듈 단위로 테스트 - 주로 화이트박스 테스트 2. 통합(설계) 검사 - 단위 검사가 완료된 모듈들을 결합하는 과정에서 수행하는 테스트 - 모듈간의 인터페이스와 연관된 오류를 찾는다. - 하향식 통합 검사 : 상위 모듈에서 하위 모듈 방향으로 통합하여 테스트 한다. Stub가 필요하다. - 상향식 통합 검사 : 하위 모듈에서 올라가며 테스트한다. Stub가 필요 없다. * Stub는 모듈을 대체하는 더미용 출력값, 또는 임시 모듈을 의미한다. * A와 B가 결합된 C모듈이 있을때 하향식 검사는 A와 B에서 옳은 값이 들어온다는 가정 하에 C가 잘 동작 하는 것인지 보는 것이므로, A와 B로부터 와야할 값을 임의로 설정해 두는 것이다. *.. 2016. 9. 18.
소프트웨어 품질관리 활동 품질 관리 = 품질 통제 + 품질 보증 품질이란? 설계 품질 : 얼마나 잘 설계했는가 일치 품질 : 얼마나 설계한대로 잘 만들었는가 품질 통제 : 소프트웨어 개발, 운영, 유지보수 과정에서 품질을 유지하기 위해 조직 내에서 행해지는 품질관리 품질 보증 : 소프트웨어의 신뢰성을 보장해주기 위해 제 3자의 입장에서 수행하는 품질관리 2016. 9. 18.
럼바우의 분석 기법 모델링 - 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법 - 순서는 객체 모델링, 동적 모델링, 기능 모델링 순으로 이루어짐 1. 객체 모델링(Object Modeling) 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 클래스 다이어그램으로 표현한 것. 가장 중요하며 가장 선행되어야 하는 단계이다. 2. 동적 모델링(Dynamic Modeling) 상태도를 이용하여 시간의 흐름에 따른 객체들 사이의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현 한 것 3. 기능 모델링(Fucntional Modeling) 자료 흐름도(DFD) 를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 것. 2015. 10. 18.
결합도(Coupling)과 응집도(Cohension) 모듈의 독립성을 판단하는 두 가지 지표이다. 결합도는 모듈과 모듈간의 상호 의존 정도, 응집도는 모듈 내부의 기능적인 집중 정도라고 할 수 있다.좋은 모듈화는 용도에 맞게 잘 구분된 기능을 가신 모듈들로 세분화 하는 것이다. 즉, 개별 모듈은 독립적으로 자신에게 주어진 기능만을 수행하고 명확한 결과값을 내 놓아야 하고 다른 모듈에 의존성이 높아선 안된다. 즉 결합도는 낮을 수록 응집도는 높을 수록 이상적인 모듈화이다. 물론 결합도가 극단적으로 낮고 응집도가 극단적으로 높다고 다 좋은건 아니다. 데이터베이스 정규화와 마찬가지로 이론적으로 이상적일 수록 현실적으로 적합한건 아니다. 상황에 맞게 적절히 낮고 높을 수록 좋은 것이다. 결합도의 종류 자료 결합도 < 스탬프 결합도 < 제어 결합도 < 외부 결합도 .. 2015. 10. 18.
DFD(Data Flow Diagram)와 DD(Data Dictionary) 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법으로 버블차트라고 부르기도 한다.프로세스, 데이터베이스, 호스트간 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용된다. 자료 흐름도의 일반적인 모습은 아래와 같다. 호스트와 프로세스, 데이터베이스가 노드이고 간선으로 데이터의 이동을 표현한다. 자료 흐름도상에 있는 자료를 더 자세히 정의하기 위해 자료사전(DD)라는 것을 같이 사용한다. 주문서 파일주문번호 = 주문년도 + 일련번호주문회원 = (회원번호) *회원인 경우만 회원번호*회원등급 = [미등급 | 일반회원 | VIP] *회원이 아닐경우 미등급*주문이력 = {주문서} 이런식으로 된, 데이터를 설명하는 데이터로 메타 데이터(Meta Data)라고도 불린다. 2015. 10. 18.
반응형