메리 솔로크리스마스 1. 디자인 패턴 사람들은 일정을 관리하거나, 할 일을 정리하고, 가계부를 작성하는 등 각자의 용도에 맞게 노션을 사용한다. 여기서 주목해야 할 것은 사람마다 노션을 사용하는 용도가 완벽하게 일치하진 않지만 비슷한 용도로 노션을 사용하는 경우가 더러 있다는 것이다. 이에 노션에서는 이용자들이 흔히 필요로 하는 페이지들로 하여금 빠르게 구현할 수 있게 템플릿을 제공한다. 노션뿐만 아니라 소프트웨어를 개발하는 과정에서도 비슷한 설계를 빠르게 구현할 수 있게 템플릿을 제공한다. 소프트웨어를 구현하는 것에 있어서 자주 사용하게 되는 설계 형태를 정형화하여 하나의 설계 템플릿으로 만든 것을 디자인 패턴이라고 한다. 2. GoF 디자인 패턴 Gang of four의 약자로 교수님이 왜 GoF인지..

0. 형상 형상이란 소프트웨어 개발 과정의 산출물(소스코드, 문서 등)이 배치된 모습을 뜻한다. 1. 형상 관리 (configuration management) 형상관리는 … 형상 항목을 식별하여 그 기능적 물리적 특성을 문서화하고, 그러한 특성에 변경을 제어하고, 변경에 관하여 기록 및 보고하고, 명시된 요구사항에 부합하는지 확인하는 기술적이고 관리적인 감독, 감시 활동이다. 프로젝트의 생명주기 동안 제품의 무결성과 변경에 대한 추적성을 확보하는 것이 목적이다. 가. 필요성 프로젝트를 진행하면 요구사항의 변동이 있는 경우가 많다. 이때 형상 관리를 수행하지 않는다면 요구사항 변동에 따른 산출물의 수정 결과가 관련자들에게 제대로 전달되지 않는다. 관련자들의 작업내용이 중복될 수도 있고, 중심이 되는 소스..

1. 검증과 확인 프로세스 시험에 자주 나오는 Software V&V다. 가. 검증 (Verification) 소프트웨어가 요구사항 문서에 부합하여 구현되었음을 보장하는 활동. 요구사항 명세서에 기술된 대로 제품을 만들어지고 있는지 확인 한다. 개발자의 관점에서 제대로 만든 소프트웨어인지 확인. 나. 확인 (Validation) 소프트웨어가 고객의 의도에 따라 구현되었음을 보장하는 활동 쓸만한 제품을 만들고 있는 확인한다. 고객의 입장에서 제대로 된 제품을 만들고 있는지 확인. 2. 검증과 확인 기법 가. 정적 방법 (Static) 소프트웨어를 실행하지 않고 결함을 찾아내는 것 대표적 방법 : 검토(review), 검수(inspection), 워크스루(walk-through) 여러 참여자가 모여 소프트웨..

0. UML 설계 1. 4+1 View 모델 시스템 개발에 참여하는 이해관계자들의 역할에 따른 관점을 제시한다. 가. 논리 관점 유스케이스 다이어그램과 요구사항 기술서에 기술된 기능들을 프로그래밍 시각으로 변경하는 관점 객체를 추출하고, 객체들의 세부적인 속성과 동작에 대해 정의 클래스/상태/오브젝트/시퀀스/커뮤니케이션 다이어그램 등 사용 나. 프로세스 관점 Integrator가 작업을 통합하기 위해 사용한다. 시스템 개발 전반의 작업 수행 주체와 작업의 흐름 정의에 중점 상태, 시퀀스, 액티비티, 컴포넌트 다이어그램 등 사용 다. 개발 관점 개발자들의 관점으로 시스템 개발 방법에 대해 정의 계층구조, 제약사항, 코드 재사용 등 시스템 구현을 위한 요건 정의 컴포넌트 다이어그램(논리적 단위로 정의), 패..

1. 설계 프로세스 소프트웨어를 설계한다는 것은 소프트웨어를 본격적으로 개발하기 이전에 소프트웨어의 뼈대를 잡는 과정이다. 소프트웨어를 설계할 때는… 요구사항 명세서의 모든 내용을 포함해야 한다. 이해하기가 쉬어서 구현 또는 테스트로 추적이 가능해야 한다. 유지 보수 시 변경이 용이해야 한다. 가. 상위 설계과 하위 설계 상위 설계 (high-level design) = 아키텍처 설계, 기본 설계, 외부 설계, 예비 설계 시스템 수준에서 소프트웨어 컴포넌트들 간 관계로 구성된 시스템의 전체적인 구조 시스템 구조도, 외부 파일 및 DB 설계도(레코드 레이아웃, ERD), 인터페이스 설계도 등 하위 설계 (low-level design) = 모듈 설계, 상세 설계, 내부 설계 시스템 구성 요소들의 내부 구조..

1. 리스크 관리 리스크란 프로젝트 결과에 심각한 영향을 미치는 잠재된 요소다. 성공적으로 프로젝트를 끝마치기 위해서 리스크에 대비하고 관리할 필요가 있다. 2. 리스크 관리 절차 리스크 식별 리스크 계량화 리스크 우선순위 선정 리스크 관리 계획 리스크 해결 결과 측정 및 문서화 가. 리스크 식별 PM뿐만 아니라 프로젝트에 관련된 모든 인원이 참여한다. 프로젝트가 가진 리스크를 파악하는 단계다. 일반적인 리스크 리스트와 기존 유사 프로젝트 리스크 리스트를 이용한다. 또한 브레인스토밍, 조사(survey), 인터뷰 등으로 리스크를 도출한다. 식별한 리스크들은 고객, 인력, 기술, 환경 등의 카테고리로 분류하여 원인을 식별한다. 나. 리스크 계량화 식별된 리스크 요소들은 실제 발행할 확률과 발생 시 영향력의..

1. 프로젝트 통제와 EVM(Earned Value Management) 가. 프로젝트 통제 프로젝트가 계획대로 수행되고 있는지 지속적으로 확인하고 필요하다면 시정 조치를 취한다. 나. EVM의 개념 ‘성과 가치 관리’ 혹은 ‘획득 가치 관리’라고 한다. 프로젝트 성과와 진행 상황을 객관적으로 측정하는 프로젝트 관리 기법이다. EVM은… 계획 대비 실적을 비교할 수 있다. 프로젝트 진행 단계 중 특정 시점까지 완료된 작업량을 비용화하여 계획된 비용과 비교 평가. 프로젝트가 계획대로 진행되고 있는가에 대한 성과 측정을 가능하게 함. 비용과 시간을 모두 화폐 단위로 통합하여 정량화한다. 프로젝트의 일정, 비용, 작업 완료 상태를 금액으로 환산하여 관리. EV(Earned Value) 개념을 기본으로 프로젝트..

1. 프로젝트 계획서 프로젝트 계획서는 프로젝트 진행 과정의 주기적 통제하면서 프로젝트의 중심이 된다. 프로젝트 관리자는 프로젝트 계획서를 작성하기 위해서 아래에 나열된 작업을 수행한다. 프로젝트 task를 파악 각 task를 수행하기 위해 필요한 노력 예측 인적 자원 및 기타 자원을 task에 할당 일정 계획 수립 이후 프로젝트 참여자의 검토를 거쳐 합의 하에 채택한다. 당연히 프로젝트 계획서는 현실적으로 전체 프로젝트 진행상황 파악에 문제가 되진 않아야 한다. 또한 프로젝트 점검 및 통제는 주간, 월간 회의를 통해서 주기적으로 수행한다. 국제 표준으로서 IEEE-Std-1058 프로젝트 계획서 양식을 참고할 수 있다. 2. 프로젝트 팀 구성 프로젝트 참여자로는 프로젝트 팀장, 분석 및 설계자, 개발자..