필넷의 블로그라이프

○소프트웨어 비용산정(Doty, Putnam, COCOMO, COCOMO II, LOC, Function Point) 방식 하향식 상향식 ° 전문가 측정 ° 델파이식(중재자 필요, 감정배제) ° LOC, 수학적 산정기법 ° COCOMO, Putnam, FP 직접측정 간접측정 ° 비용, 속도, LOC, 노력 ° 오류의 수, 메모리 크기 ° 기능(FP), 효율성, 품질 ° 신뢰성, 복잡성, 유지보수성° Basili 자원모델 분류 - 정적 단일변수 모델(COCOMO), 정적 다변수 모델, 동적 다변수 모델(Putnam), 이론적모델 Doty ° 인터뷰와 문헌에 바탕 Putnam ° SW 개발 프로젝트의 생명주기 전 과정 동안에 노력의 특수한 분포(Rayleigh)를 가정해주는 동적 다변수 모델 ° SLIM -..

○ RUP(Rational Unified Process) 정의 ° Rational에서 제안한 객체지향 프로젝트 수행에 맞도록 개발된 UML 기반의 객체지향 방법론(대규모 시스템에 적합) 특징 Usecase Driven ° 개발자는 유스케이스를 실현함으로서 분석, 설계, 테스트로부터 추적성, 일관성 유지 Architecture Centric ° 아키텍쳐 중심으로 복잡한 프로젝트 운영, 시스템의 무결성을 유지하도록 프로젝트 통제를 가능하게 함(4+1 View) Iterative & Incremental ° 요구사항관리, 반복적 점진적 개발, 변화관리, 지속적인 SW 품질 증명 ° 한 사이클이 끝날 때마다 테스트가 완료되어 통합 및 수행 가능한 시스템이 산출되는 모형 ° 여러 번의 릴리스를 거치면서 사용자의 ..

○ 소프트웨어 분석 및 설계 모델 데이터설계 정보영역을 SW 구현에 필요한 데이터 구조로 변환 아키텍쳐설계 프로그램 주요 구조요소들 사이의 관계를 정의 인터페이스설계 SW가 상호작용하는 시스템, 인간과의 교류 프로세저설계 아키텍쳐 구조요소들을 SW 구성요소에 대한 절차 서술로 변환 분석 구조 요구분석 명세 ° 구현방법이 아닌 필요한 기능성 표시한 개념적 모형이며 운용 가능해야 함 ° 불완전성을 수렴할 수 있어야 함 ° 요구명세는 부분적 정의이며 타 요구들과는 느슨하게 연결되어야 함 ° 동작할 시스템 환경에 대한 정보와 SW 컴포넌트에 관한 정보가 포함되어야 함 ° 테스트 데이터에 대해 작동 가능성을 확인할 수 있어야 함 E-R Diagram ° 데이터 객체들 사이의 관계성(Pipe-Filter patte..

[소프트웨어공학-21문제 복원] 26) ATAM(Architecture Tradeoff Analysis Method)에서 주 관심 사항을 묻는 문제였던가?? QAS(Quality Attribute Scenario) ← 다수가 이게 답이라는 군요. 전 틀렸습니당. T.T 27) 유지보수단계 소프트웨어 이해 → 변경요구사항 분석 → 변경 및 효과예측 → 회귀테스트 28) pair-programming, 사용자 파견, 짧은 배포주기, 지속적 통합의 방법론? XP(Extreme Programming) 29) IT성과관리에 포함되지 않는 것? 내부통제관리프로세스?? ← 이게 보기 ④번 이었던 듯 싶은데 답은 정확히 뭔지 잘 모르겠네요. 30) RUP단계를 묻는? Construction 이라고 답했는데 아무래도 E..

○ MDA(Model Driven Architecture) 개요 ° SW 설계모델을 명세하고, 이를 상세설계모델과 코드로 변환하여 프로그램을 자동으로 생성하는 새로운 개발 기술 과정 ° PIM(Platform Independant Model) : 플랫폼에 독립적인 설계모델(기능중심) ° PSM(Platform Specific Model) : mapping을 통해 PIM을 PSM으로 변환 ° UML을 이용하여 PIM, PSM을 기술 ° PIM과 PSM간의 mapping방법은 OMG의 핵심표준인 MOF, UML, CWM, XMI로 기술되는 메타모델을 기반으로 함 핵심기술 UML ° 객체 및 컴포넌트 시스템을 표현하기 위한 표준언어(전체 도면을 설계하는 언어) ° Infrastructure, OCL, Diag..

○ Agile 방법론 등장배경 ° SW 개발 환경의 변화 - 정보시스템의 'time to market'과 ‘적시배포’가 중요해짐 - 사용자 요구가 다양해지고 수명주기가 짧아짐 ° 기존 방법론의 한계 - 문서 및 절차위주의 방법론은 변화에의 신속한 적응이 어려움 - 변화에 빠르게 적응하고 효율적으로 개발할 수 있는 방법론이 필요 정의 ° e-Business, 시장 및 SW개발환경 등 주위변화를 빠르게 수용하고 이에 능동적으로 대응하는 여러 경량 방법론의 통칭 특징 ° Predictive 하기 보다는 Adaptive한 방법론(변화에 반응하는것이 계획을 준수하는 것보다 우선함) ° 프로세스 중심이 아닌 사람중심의 방법론(개인간 상호의사소통이 프로세스나 도구보다 우선함) ° 동작하는 소프트웨어가 포괄적인 문서보..

○ 아키텍쳐 평가 방법론 정의 ° 아키텍쳐 접근법이 품질속성에 미치는 영향을 측정하여 아키텍쳐를 평가하는 표준 절차를 정의 범주 Scenario-based assessment ° 품질요소(Quality attribute)를 위해 정의된 Profile에 의존하여 평가하는 방식 ° ATAM, SAAM Simulation-based assessment ° 일부 또는 추상화된 형태의 구현과 이를 기반으로 한 평가방식 ° BMT Mathematical model-based assessment ° 기준의 모델을 기초로 다른 점들을 수치화하고 이를 기초로 평가하는 방식 ° 품질을 추정하는데 사용될 가능성이 높다 Experience-based assessment ° 품질을 평가하기 위해 정형화된 모델을 갖지 못하고 정..

○ ITIL(IT Infrastructure Library) 정의 ° IT 서비스 관리를 위한 “Best Practice"를 제공하는 세계적인 defacto 표준(방법론이 아니다) ° 최상의 서비스를 제공하기 위한 최적의 비용을 제시 ° IT 서비스 제공 및 관리에 대한 벤더에 종속적이지 않은 포괄적, 공개적인 가이드임(어떤 조직, 기업에도 활용 가능) 구성 내역 ° Service Delivery - IT 서비스 제공자가 고객에게 충족한 지원을 제공하기 위해 필요한 서비스 및 프로세스를 정의함 ° Service Support - IT 서비스 사용자가 서비스를 항상 받을 수 있도록 보장하는 프로세스 ° Application Management - SW 개발 생명주기를 포함하고 있으며 SW 생명주기 지원 및..

○ EA/ITA 정의 ° EA(Enterprise Architecture) - 조직 및 업무활동과 정보기술 간의 관계를 현재모습과 향후 추구할 모습을 별도로 정의한 청사진(Blueprint) - 규칙(Rule) + 모델(Model) + 계획(Plan)으로 구성 ° ITA(Information Technology Architecture) - EA + TRM +SP 구성요소 EA Framework ° EA를 개발하기 위한 의사소통 모델 ° 기업의 비즈니스, 정보, 어플리케이션 및 기술에 대해 명확한 구성요소로 식별, 정의하고 이들간의 관계를 정립한 구조적인 틀 ※ 아키텍쳐 도메인 비즈니스 아키텍쳐 ° 기업의 경영목표 달성을 위해 업무구조를 정의한 영역으로 기업의 업무와 서비스의 실체를 명확히 하는것 데이터 ..

□ UML의 미래 1. UML 2.0 - UML의 진화과정 - UML 2.0에서의 변화 - UML 2.0에 추가된 Diagram - UML Diagram 분류 및 Spec 2. MDA - MDA 배경 - MDA 개요 - MDA 핵심기술 - MDA 모델변환 - 4 Layer Metamodeling Hierarchy - UML Profiles - 결론 [관련 포스트] 2008/09/01 - [IT 노트/소프트웨어공학] - RUP(Rational Unified Process) 2008/08/21 - [IT 노트/소프트웨어공학] - MDA(Model Driven Architecture)