observe_db

11/28 Architecture란 뼈대, 골격 역할 Component: 가장 기본적 기능을 포함하는 단위. 명백한 역할을 가지고 독립적으로 존재할 수 있는 시스템의 부분. Module: 문법구조에서 정의된 컴포넌트(클랫, 패키지, 메서드) Subsystem: 여러개의 컴포넌트로 구성된. 여러 다른 방법으로 구현될 개체 6-1: Architectural Design 전체적 구조를 어떻게 구성하고 설계할지 설계와 요구사항 공학 사이의 중요한 연결점.(원래는 더 먼저 해야함) -주요 구조적 component들을 식별하고 그들 사이의 관계를 정의 정형화된 틀이 없어서 자유로운 형식 전체적인 시스템 architecture는 구성하고 들어간다.(Agile 조차도) Refactoring하는것은 엄청난 비용이 들어간..

5-1: System modeling : 개발 과정에서의 산출물 시스템에 대한 추상적인 모델. 관점이 다양하니 여러가지 모델. 시각적인 표기법을 사용하여 표현 이해를 돕는다-시스템의 기능, 고객과의 소통. 기존 및 계획된 시스템 모델 기존 시스템의 모델은 요구사항 공학에서. -기존 시스템이 무엇을 하는지, 장점과 약점을 논의할 기초로 사용될 수 있음. -새로운 시스템의 요구사항 유도 새로운 시스템의 모델도 요구사항 공학에서 소개된 요구사항을 다른 시스템 stakeholder에게 설명하는것을 도움 -공학자는 이 모델들을 설계 proposal 논의에 사용, 구현을 위한 문서에 사용 모델기반 공학 프로세스에서, 시스템 모델에서 전체 혹은 일부 시스템 구현이 가능하다. System perspectives -ex..

11/14, 11/16 4-1: Requirement Engineering 서비스를 설립하는 단계 -고객이 시스템에 원하는 것 -운영과 개발시의 제약조건 시스템 요구사항 -시스템 서비스에 대한 설명 - 요구사항 공학 단계 동안에 생성되는 제약조건 요구사항 범위 - 최고 수준으로는 서비스의 추상화 상태 or 시스템 제약사항 - 자세한 수학적 기능 명세 요구사항의 타입 -사용자 요구사항: 자연어와 다이어그램. 운영적 제약조건. 고객이 작성 -시스템 요구사항: 시스템의 기능, 서비스, 운영적 제약조건에 대한 자세한 서술. 어떤것이 구현되어야할지 정의. 고객과 contractor의 계약 Reader 사용자요구사항-client manager/system end-users/client engineers/contra..

11/7 3-1 Project Planning : 일을 쪼개고(break down), 멤버 설정, 일어날 수 있는 예상 문제 선정 : 어떻게 일을 끝낼지 팀과 고객과 소통. 진행사항 확인하게. Planning 단계 -Proposal stage: 계약을 위한 비드 대략적 outline을 세움. 요구사항 수집. 가격 책정을 위한 정보 공유.(가격 책정에는 staff 비용, 하드웨어 비용, 소프트웨어비용 등) -Project startup phase: 계획을 세움-누가할 것이고, 어떻게 프로젝트를 나눌 것이고, 어떻게 자원을 할당할지 등등 설계나 구현 정보보다는 시스템 요구사항을 잘 알아야. 계획을 세움-예산과 인력에 대한 결정 모니터링 매커니즘으로 startup plan(아직 agile 개발에 사용-프로젝트..