추정 기법 조직은 소프트웨어 노력과 비용 추정치를 만들어야 함 두 종류의 기법을 사용하여 추정치를 구함 경험 기반 기법 관리자의 과거 프로젝트 경험과 애플리케이션 도메인을 근거로 노력 요구사항을 추정 알고리즘 비용 모델 프로젝트 노력을 계산하기 위해 크기와 같은 제품 속성의 추정치, 프로세스 특성, 참여한 직원들의 경험을 근거로 하는 공식적 접근법 사용 추정 불확실성 경험 기반 접근법 관리자의 경험, 이 프로젝트에서 소프트웨어 개발에 관련된 활동들을 위해 투입된 실제 노력에 의존 전형적으로 프로젝트에서 생성되는 산출물들과 개발될 여러 소프트웨어 컴포넌트 또는 시스템 식별 스프레드 시트로 문서화, 개별적 추정, 필요한 총 노력 계산 그룹 내의 멤버들에게 자신의 추정치를 설명할 것을 요청하는 것은 도움이 됨..

프로젝트 일정관리 다음의 항목들을 결정 프로젝트 내용을 분리된 작업들로 조직하는 방법 각각의 작업들이 실행되는 시점 각각의 작업들을 실행할 방법 다음의 업무를 수행 각각의 작업을 완료하는데 필요한 시간과 노력 추정 작업 수행 인원 제안 각 작업을 완료하는데 필요한 하드웨어와 소프트웨어 자원들 추정 → 초기 프로젝트 일정은 프로젝트 시동단계에서 생성되며, 자주 갱신되고 수정됨 계획 주도 및 애자일 프로세스에서의 프로젝트 일정 두 경우 다 초기 프로젝트 일정 필요 계획 주도 프로젝트 프로젝트 관련 업무를 분리된 작업들로 나누고 각각의 작업을 완료하는데 필요한 시간 추정 애자일 프로젝트 계획 주도 프로젝트보다는 덜 상세한 내용 프로젝트 주요 단계들이 언제 완료될지 식별하는 전반적인 일정이 있어야 함. 프로젝트..

프로젝트 계획 수립 프로젝트 계획 수립은 프로젝트 생명 주기의 세 단계에서 일어남 소프트웨어 프로젝트 관리자의 가장 중요한 업무 중 하나 작업들을 작은 작업들로 나눔 나눈 작업들을 프로젝트 팀 멤버들에게 할당 발생할 수 있는 문제들에 대해 예측 문제들에 대한 잠정적인 해결책 준비 프로젝트 계획 작업이 진행될 방법을 보이고 프로젝트의 진척사항을 평가하기 위해 사용 프로젝트를 시작하면서 생성하고 프로젝트가 진행되면서 수정 프로젝트 계획 수립은 프로젝트 생명 주기의 세 단계에서 일어남 제안 단계 소프트웨어 시스템을 개발 또는 공급하는 계약을 수주하기 위해 응찰할 때 작업 완수를 위한 자원을 가지고 있는지 판단하는 것을 돕는다 언급해야 하는 가격 측정 계획을 위해 필요 프로젝트 시작 단계 누가 프로젝트에서 작업..

프로젝트 관리 소프트웨어 공학의 본질적인 부분 전문적인 소프트웨어 공학은 항상 조직의 예사과 일정에 대한 제약조건의 영향을 받음 프로젝트 관리자의 임무 제약조건을 만족하고 극복하면서 고품질의 소프트웨어를 인도하도록 보장 프로젝트 주요 목표 약속된 기한까지 고객에게 소프트웨어 인도 전체 비용을 예산 범위 이내에서 지출 고객의 기대치를 충족하는 소프트웨어 인도 일관적이고 잘 운영되는 개발팀 유지 소프트웨어 관리가 어려운 점 소프트웨어 제품은 형체가 없음 관리자는 개발 중인 제품에 대한 진척사항을 볼 수 없음 대형 소프트웨어 프로젝트는 종종 일회성 프로젝트임 대형 프로젝트는 개발되는 환경이 다른 것들과는 어느 정도 다르기 때문에 고유함 소프트웨어 프로세스는 변동이 심하고 조직마다 다름 소프트웨어 기업들은 완전..

소프트웨어 유지보수 시스템을 인도한 후에 변경하는 일반적인 프로세스 변경의 범위 코딩 오류 설계오류 요구사항 오류 소프트웨어 유지보수 유형 버그와 취약점을 고치기 위한 결함 수리 수리의 종류에 따라 비용 상이(코딩 오류/설계 오류/요구사항 오류) 소프트웨어를 새로운 플랫폼과 환경에 맞추기 위한 환경적 적응 새로운 기능을 추가하고 새로운 요구사항을 지원하기 위한 기능성 추가 유지보수 비용 분포 유지보수 비용 개발비용보다 많이 필요 기술적/비기술적 요인 둘 다 영향받음 소프트웨어가 유지보수됨에 따라 증가 → 소프트웨어 구조가 망가짐에 따라 유지보수가 힘듦 오래된 소프트웨어의 경우 높은 비용 필요 유지보수 비용이 높은 이유 유지보수 과정에서 새로운 기능 추가가 초기 개발과정에서 동일한 기능을 구현하는 것보다 ..

소프트웨어 진화 개발과 진화의 나선형 모델 소프트웨어 공학은 나선형 프로세스로 생각할 수 있음 시스템의 수명동안 요구분석, 설계, 구현, 테스팅이 반복 지난 10년 동안 나선의 반복 사이 시간은 극적으로 줄어듦 경쟁자들의 압박과 사용자들의 피드백에 빠르게 반응해야 함 동일한 회사가 소프트웨어의 수명 동안 책임을 지는 경우에 적용 가능 맞춤식 소프트웨어의 진화 나선형 모델을 따르지 않음 고객이 소프트웨어 지원과 진화를 감당 고객이 시스템 지원과 진화를 담당하는 외부 회사와 별도 계약을 체결 진화 프로세스가 불연속적일 가능성 있음 요구사항과 설계 문서가 한 기업에서 다른 기업으로 전달되지 않을 수 있음 소프트웨어 유지보수 소프트웨어가 개발에서 진화로 매끄럽게 전이되지 않을 때, 사용자에게 인도된 이후의 소프..

소프트웨어 테스팅 목적 : 잘 수행되는지 확인 및 프로그램 사용 전 결함 발견 테스팅 방법 : 인위적인 데이터를 이용하여 프로그램 실행 점검 대상 : 오류, 이상, 또는 프로그램의 비기능적 속성에 관한 정보 소프트웨어 테스트 종류 검증 테스팅 시스템의 예상된 사용을 반영하는 테스트 케이스 집합 이용 시스템이 정확하게 수행되는 것을 기대 결함 테스팅 테스트 케이스는 결함을 드러낼 수 있도록 설계 소프트웨어의 동작이 부정확하거나, 명세에 따르지 않게 되는 입력 또는 입력 순서를 찾음 두 접근법 간의 명확한 경계는 없음 프로그램 테스팅의 입출력 모델 및 테스트 과정 시스템이 블랙박스로서 테스트되는 경우로 가정 결함 테스팅의 우선순위 집합 l_e에 속한 입력을 찾는 것 시스템에 있는 문제를 드러내기 때문 검증 ..

디자인 패턴 패턴 문제와 그 해법의 핵심을 기술한 것 여러 환경에서 재사용될 수 있음 상세한 명세가 아님 객체 지향 소프트웨어 설계에 큰 영향을 줌 디자인 패턴 객체 지향 설계와 연관 공개된 패턴 - 일반성을 제공하기 위한 상속과 다형성 같은 객체 특성에 의존 패턴 적용 일반 원칙 어떤 종류의 소프트웨어 설계에도 똑같이 적용 가능하게 하는 것 디자인 패턴의 네 가지 핵심 요소 패턴을 지칭하는 의미 있는 이름 패턴이 적용될 수 있는 환경을 설명하는 문제 영역에 대한 서술 설계 해법의 구성요소들에 대한 서술 및 그들의 관계와 책임 구체적 설계 기술이 아닌 다른 방법으로 인스턴스화될 수 있는 설계 해법을 위한 템플릿 패턴을 적용한 결과에 대한 서술 설계자가 특성 상황에 패턴을 사용할 수 있는지를 결정하는데 도..