진진진 개발일지

하드웨어의 경우: TMR(Triple Modular Redundancy), RAID 등 Recobery block: alternative의 적합성 여부를 Acceptance test로 검사 실패한 경우 후보가 있으면 alternative 실행 실패하는 경우를 대비한 checkpoint estabilish / restore 문제점 acceptance test에서 문제가 발생하는 경우 fail-tolerance 불가능. 비교적 시간이 걸리므로 domain dependent(실시간 sw에 영향을 미침). acceptance test와 alternative간의 근본적인 차이가 없음. alternative간의 common mode failure를 피하기 어렵고 우선순위 설정 어려움. 지원하는 언어가 없고 chec..

Test를 pass하는 기준은 expected output: 테스팅을 통해 알 수 있는 것은 expected output과 actual output이 같다는 것 테스팅이 어려운 이유 실제 사용되는 환경에서 검증하기 어려움 소프트웨어가 처리해야 하는 모든 입력값의 범위 및 조합에 대한 테스팅이 현실적으로 불가능 오작동이 입력값외에 환경에 영향을 받을 수 있음 multithread 프로그램인 경우 소프트웨어의 행위 및 출력이 수행할 때마다 달라짐 프로그래밍 언어에 따라 다른 테스팅 기법 적용 결함이 없다고 보장 불가능 Combinatorial testing: 시스템에 대한 입력 매개변수에 대해 모든 가능한 개별 조합을 테스트 Random testing: random possible input을 생성, 모든 ..

Software Cost Estimation: 프로젝트 비용 예측. 프로젝트 관리를 위해 기본적인 데이터가 필요. 요구사항과 개발 환경의 변화가 없다면 일정과 비용에 미치는 영향에 대한 양적인 측정이 가능. Cost Estimation 접근들: Rules of thumb(과거 프로젝트로부터의 짐작), Top-down/Bottom-up estimating, Algorithmic models (COCOMO, Function Point 등) COCOMO(Constructive Cost Model): 데이터를 수집하여 만든 개발 기간과 프로젝트 크기 간의 관계 개발 노력(SM) = 2.4(a) * (프로그램 규모=라인 수)^1.05(b) 개발 기간(TDEV) = 2.5(c) * (SM)^0.38(d) 적정 투입..

Waterfall model 소프트웨어 개발 프로세스 각 단계를 체계적(순차적)으로 거쳐가는 모델 각 단계마다 review와 approval 필요. 필요하다면 "loop-back" 가능 Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance - 장점: 관리와 실행이 간단, 고정된 비용의 프로젝트에 적합, 전체 프로젝트에 대한 예산과 일정 추정이 쉬움 - 단점: 완전한 요구사항을 추출하기 위해서 많은 시간이 필요, 제품이 실패할 확률이 높음(21%), 정적인 시장에만 적합함, 기술적 어려움으로 고객의 예상과 다를 ..

Software Process Improvement(SPI, 프로세스 개선): 개발 속도 향상/제품 품질 향상/비용 절감 등의 특정 목표를 달성하기 위해 개선 활동을 계획하고 구현하기 위한 일련의 작업, 도구 및 기술. 미국 국방성은 소프트웨어 개발프로세스를 개선하고 조직의 역량 및 성숙도를 측정하는 모델인 CMM을 발표 SW-CMM(=CMM, 성숙도 모델)에서 통합모델 CMMI으로 확장 CMMI 조직의 성숙도를 1단계에서 5단계로 정의하고 각 단계마다 만족해야 하는 핵심역량을 Key Process Area(KPA)로 정의 Level 1 Initial: 아무런 인증 x Level 2 Repeatable: 소프트웨어 프로젝트의 기본적인 핵심역량을 갖추었는지 판단하는 것이 목적 기타 용어 Software c..

- 수학적인 이론에 기반하여 소프트웨어와 하드웨어 시스템의 명세, 개발, 형식 검증을 위한 기술 - 안전/보안이 중요한 소프트웨어 및 시스템에서 사용됨 - 명확하고 정형적으로 정의된 semantics를 기반으로 함 - 자동화된 분석이 가능함 (시뮬레이션, 테스트케이스 생성, 정형 검증 등) 장점: 에러를 빨리 발견 가능, 제품 품질 향상 단점: 비용이 많이 들고 어려움 정형 명세(Formal Specification): 수리, 논리를 이용하여 시스템의 기능, 행위, 동작 환경을 기술하는 것. 모호함을 없애는 것이 목적 요구사항 간 inconsistency를 없애고 설계가 요구사항을 만족하는지 증명 가능 Finite State Machine, Statechart, Petri Net 등이 해당됨 정형 검증(..

SRS review의 한 방법 소프트웨어 개발 전 단계에 걸쳐서 두루 적용 가능 문서 공유를 통한 소통과 이를 기록 요구사항의 오류를 소프트웨어 개발 단계 중 뒤에서 고칠 수록 비용이 많이 들기 때문에 필요 Fagan 인스펙션 4~5명이서 적당한 준비 후 결함을 찾기 위한 집중적인 검토 모임을 가짐 한 번에 최대 두 시간, 하루에 최대 두 번씩으로 제한하도록 추천 참여자들은 Moderator, Reader, Inspector, Recorder 등으로 맡은 역할이 있음 오류를 찾는 목적에 집중할 수 있도록 모두 노력 과정 Planning 및 Overview: 검토 대상이 되는 product를 설명하는 단계. 그 대상은 SRS 문서, 소스코드 등 Preparation: 각 참여자들이 개인적으로 자료 검토 등..

UML(Unified Modeling Language, 통합 모델링 언어): 요구 분석, 시스템 설계, 시스템 구현 등의 개발 과정에서 개발자 간 의사소통을 원할하게 이루어지게 하기 위하여 표준화한 범용 모델링 언어. 구성요소: thing, relationship, diagrams 코드의 전체적인 구조를 이해하는 데 도움 knowledge sharing/transfer에 긍정적 많이 사용되는 UML diagrams Class diagram: class들의 타입, 내용, 관계를 표시함으로써 시스템의 구조를 기술. Java나 C++같은 객체지향 프로그래밍 언어가 사용하는 경우 상속 등 객체간의 관계를 분석 Sequence diagram: 시나리오 기능을 수행하는데 필수적인 객체들 간의 교환되는 일련의 메시지..

요구사항은 소프트웨어 설계의 기초적인 문서로서 테스트케이스를 만드는 등의 기초가 됨. 요구사항이 조기에 파악되지 못하면 추가 비용이 매우 크며, 변경된 요구사항이 다른 기능에 영향을 미칠 수 있음. Requirements Management Activities 요구사항에 대한 형상 관리 제안된 변화를 검토하고 그 영향 평가 요구사항 변경으로 예상되는 영향을 기반으로 새로운 약속 및 협상 각 요구사항에 대응되는 설계, 소스코드, 테스트케이스 추적 Source of Requirements: 잠재적 사용자와의 인터뷰, 경쟁사 제품 분석, 유사 시스템 참고, 사용자 업무 시나리오 분석 등 형상관리를 위한 도구 CVS: 무료 서버-클라이언트 형상관리 시스템. 히스토리 보존. 속도 느림 SVN: CVS 단점 보완...

Software Engineering(SE) 소프트웨어의 개발, 작동, 유지, 처분에 대한 체계적인 접근 "Multi-person construction of multi-version software" : 수많은 개발자들이 긴밀하게 협력해야만 개발이 가능할 정도로 복잡한 소프트웨어 개발에 필요한 기술을 연구하는 분야. 소프트웨어의 개발은 지속적인 유지, 보수, 확장을 필요로 하는 일. 여러 버전의 형태로 출시되는 경우가 많음. SE의 중요성 소프트웨어의 품질과 생산성 시스템 비용에 있어 소프트웨어 비용이 지배적인 요소 software-intensive, software-driven economy 소프트웨어 개발 단계: 요구사항 분석 -> 설계 -> 구현 -> 검증 -> 요지보수 소프트웨어 특성: Comp..