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

아키텍처 설계 소프트웨어 설계 프로세스의 첫 단계 시스템의 전체 설계를 이해하는 것 주요 구조 컴포넌트들과 그들 간의 관계 식별 설계와 요구공학 사이의 중요한 연결 결과물 → 아키텍처 모델 시스템이 상호작용하는 컴포넌트들의 집합으로 어떻게 구성되었는지 설명 애자일 프로세스 아키텍처 설계 초기 단계에서 전체 시스템 아키텍처 설계에 초점 맞춤 아키텍처의 점진적 개발은 보통 성공적이지 않음 변화에 대응하여 컴포넌트를 리팩토리항 하는 것이 상대적으로 쉬움 시스템 아키텍처를 리팩터링 하는 것은 비용이 많이 듦 아키텍처 변화에 따라 시스템 컴포넌트들은 수정해야 함 아키텍처 설계의 현실적 측면 주요 아키텍처 컴포넌트들이 시스템의 상위 수준 특징 반영 → 컴포넌트 식별 필요 이상적으로는 시스템 명세에는 설계 정보가 포..

요구사항 명세 — 사용자 요구사항 및 시스템 요구사항을 문서로 작성하는 과정 이상적인 요구사항 작성 조건 대상 : 사용자 요구사항과 시스템 요구사항 모두 특징 : 명확하고, 모호하지 않으며, 이해하기 쉽고, 완전하고, 일관성 있어야 함 실제로 달성 어려움 ← 충돌이나 불일치 자주 발생 ← 이해당사자들 간의 다른 해석 사용자 요구사항 작성 단순한 표, 양식, 직관적 다이어그램을 가지고 자연어로 작성 기술적 지식이 없는 시스템 사용자가 이해할 수 있도록 기능적/비기능적 요구사항을 포함 시스템의 외부 동작에 대해서만 명세 시스템 아키텍처나 설계에 대한 상세한 내용 X 시스템 요구사항 작성 사용자 요구사항에 상세한 내용 추가 시스템의 외부 동작과 운영상의 제약에 대해서만 기술 시스템의 설계와 구현에 대해서는 다..

요구사항 도출 이해당사자들의 업무 지원을 위해 신규 시스템을 활용하는 방식을 이해하는 것 요구사항을 알아내기 위해 소프트웨어 엔지니어는 이해당사자들과 함께 일함 예 ) 응용 도메인, 업무 활동, 이해당사자들이 원하는 시스템 기능, 필요한 기능, 하드웨어 제약 등 요구사항 도출이 어려운 이유 애매하고 비현실적인 요구사항 아주 일반적인 용어로만 표현 타당하고 그른 것을 잘 모름 도메인 경험이 전제된 상태에서의 요구사항 요구사항을 전문용어를 사용해서 표현 → 경험 없는 요구사항 엔지니어는 이해 못 함 여러 명의 이해당사자들의 서로 다른 요구사항 → 요구사항 엔지니어는 요구사항에 대한 모든 잠재적 출처를 찾고 공통점과 상충점을 찾아내야 함 정치적 요소가 시스템 요구사항에 영향을 줄 수 있음 권력을 얻기 위해 관..

요구공학 프로세스에 대한 나선형 뷰 관련 활동들이 나선 형태의 반복 프로세스들로 구성 각 활동에 소요한 시간과 노력의 양은 특성에 따라 달라짐 요구사항 도출 및 분석 시스템 요구사항을 얻어내는 프로세스 기존 시스템 관찰, 업무 분석, 잠재적 사용 자 및 구매자와 토의 하나 이상의 시스템 모델과 프로토타입을 만들기도 함 → 명세할 시스템 이해에 도움 요구사항 명세화 요구사항을 담은 문서 작성 두 가지 유형의 요구사항이 포함될 수 있음 사용자 요구사항 : 시스템 요구사항에 대한 추상적인 문장들(고객과 시스템 최종 사용자용) 시스템 요구사항 : 제공할 기능에 대한 상세한 설명 포함 요구사항 검증 요구사항에 대한 현실성, 일관성, 완전성을 검사 요구사항 문서상의 오류를 발견하고 수정하여 문제를 바로잡아야 함 요..

애자일 기법 등장 배경 예전엔 계획 주도 접근법이 주로 사용됨(1980년대 ~ 1990년대 초) 더 좋은 소프트웨어를 만들기 위해서 대규모의 소프트웨어 제작을 위한 방식이자 그런 시스템을 개발했던 공학단체로부터 비롯됨 예 ) 현대식 항공기 제어 시스템 - 초기 명세부터 배포까지 10년은 족히 걸림 계획, 설계 및 문서화에 오버헤드가 많이 발생 → 애자일 기법 등장 이유 무거운 접근법에 대한 불만 때문에 애자일 기법 등장(1990년대 말) 개발팀이 설계와 문서작업보다 소프트웨어 개발 자체에 더 집중 요구사항이 자주 변경되는 어플 개발할 때 적합한 방식 유용한 소프트웨어를 빠르게 만들 수 있도록 고안(신속한 소프트웨어 개발) 신속한 소프트웨어 개발의 필요성 비즈니스 시스템에서 가장 중요한 요구사항 ← 새로운..

소프트웨어 프로그램과 관련된 모든 사항(관련 문서, 라이브러리, 사이트, 환경설정 데이터) 전문적으로 개발된 소프트웨어는 많은 요소들로 구성(다수의 프로그램, 환경설정, 시스템 문서 등) 소프트웨어 제품 유형 일반 제품 특정 개발 조직이 생산한 독립적 시스템 누구든 구매 가능 개발 조직이 소프트웨어 명세를 관리 데이터베이스, 문서 편집기, 그래픽 패키지, 회계 시스템 등 맞춤식 소프트웨어 특정 고객의 요구에 맞춰 개발 소프트웨어 계약자는 고객만을 위해서 설계하고 구현 구매자가 소프트웨어 명세를 개발하고 관리 항공관제 시스템, 전자기기 제어 시스템 이러한 제품유형의 차이는 점점 희미해지고 있음 소프트웨어 필수 특성 수용성(Acceptability) → 설계한 목적에 부합하는 사용자 유형이 수용할 수 있어야..