소프트웨어공학 (12) 썸네일형 리스트형 [소프트웨어 설계론] 아키텍처 설계 원리 좋은 설계의 조건사용자의 비기능 요구사항(품질)을 달성할 수 있는 설계변경 용이성이 높은 설계설계 원칙변경되는 것과 변경되지 않는 것을 구별하자변경이 쉽다 = 변경이 되어도 다른 클래스 및 모듈에 영향이 없다.의존성 끊는 법B 가 변경되면 A가 변경되는 모습 (A->B) 일 때, A -> B' (추상 클래스) SDP (Stable Dependency Principle) : 안정된 의존성 원칙불안정한 컴포넌트가 상단에 위치하고, 상대적으로 안정된 컴포넌트로 의존하기다른 컴포넌트에 의존하지 않을수록 안정되어 있다.불안정성 (I) = Fan-out / (Fan-in + Fan-out)Fan-in : 다른 컴포넌트가 나에게 의존SAP (Stable Abstractions Principle) : 안정된 추상화 원.. [소프트웨어 프로젝트 관리] 변경 관리 사전에 정해진 룰에 따라 변경을 제한하고, 통제해야 한다. 변경을 없애라는 것이 아닌, 통제를 하라는 것 형상관리 통제 개발 중인 시스템에 변경이 함부로 일어나지 않게 통제 변경이 될 때는 항상 baseline을 그어야한다 CCB (Change Commit Board, 변경위원회) 를 구성하면 좋다. [소프트웨어 프로젝트 관리] 프로젝트 단계 소프트웨어 프로젝트의 개념적 단계 : 발견 - 발명 - 구현 단계를 분명하게 긋는 계획은 좋은 것이 아니므로, 어느정도 겹치게 두는 것이 좋음 발견, 발명 : 불확실한것을 확실한 것으로 바꾸는 과정 구현 : 확실한 가능성을 실현하는 과정 단계별 납품 계획 각 단계에서 적극적으로 리스크 관리하여 리스크 요인 제거 다음 단계를 위한 상세 계획 수립 소프트웨어 프로젝트 단계 사전 계획 프로젝트 비전 및 목표 수립 프로젝트를 하는 이유 제시 계획 및 진척도 공개 리스크 관리 소프트웨어 프로젝트는 Complexity 특성을 가지므로, 복잡하고 위험하여 예산, 일정 초과 등의 가능성이 높아 리스크 관리가 필요 전체 5% 정도의 노력을 리스크 관리에 투자하면 프로젝트를 성공할 확률이 50 ~ 75% 정도 높아짐 리스.. [소프트웨어 프로젝트 관리] 프로젝트 가시성 프로젝트 가시성 : 프로젝트 현황을 정확하게 판단할 수 있는 정도 가시성을 높여 리스크 관리를 할 수 있음 가시성을 높이기 위한 방안 프로젝트의 비전이나 목표 설정 --> 같이 가야할 방향을 공유하여 팀워크 향상 계획 대비 실적을 정기적으로 비교 상세한 마일스톤 (binary milestones : 정해진 일정을 했는지 안했는지 True/False 로 관리하는 기법) 설정 정기적으로 제품 Release 코딩 진척률 프로젝트 상황 파악에 도움이 됨 S 곡선을 그리는 것이 이상적 참고 - 스티브 맥코넬 저, 『소프트웨어 프로젝트 생존전략』 [소프트웨어 프로젝트 관리] 소프트웨어 프로젝트 정의 소프트웨어를 생산하는 과정 성공 비법 성공 = 뛰어난 개발자의 역량 + 협업 협업을 통해 프로젝트 생존을 하고, 개발자의 역량을 통해 성공할 수 있다. 생존 비법 프로젝트 생존 : 프로젝트가 취소 및 해체되지 않는 것 문명화된 방식(civilized way)으로 소프트웨어 프로젝트 관리가 되어야 생존이 가능 문명화된 방식(civilized way) : 서로의 권리를 존중하는 것 잘 정의된 개발 프로세스는 상류(upstream) 활동에 많은 투자를 진행 상류(upstream) : 기획/요구사항 분석/설계 단계 특징 데모가 불가능하여 invisible 한 상태 --> 잦은 review 를 통해 visible 화 필요 버그 생성의 약 80% 원인 상류 단계에서 문제 발생 시 '단계 내 봉쇄'를 통해 프로.. [요구사항분석론] Requirement Engineering (요구공학) - Requirement Engineering 정의 stakeholder 의 needs 와 프로젝트 constraint 사이에서 조율하여, Elicitation / Analysis / Specification / Verification 을 통해 requirement 를 도출해내고, requirement 변경관리까지 진행하는 프로세스 기반의 활동 Not What, Why 프로젝트의 목적 (goal)을 우선시하여야 함 Goal 을 구체화 --> Scope 설정 requirement 속 business value 도출 가능 Consideration (고려 사항) Customer & User needs Understanding (Not developer needs) Business & Market Underst.. [요구사항분석론] Requirement Management - Requirement (요구사항) 정의 시스템 개발에서 stakeholder 가 중요하다고 생각하는 조건 또는 기능 stakeholder 의 real expectation 을 도출하는 과정을 통해 needs 와 결과물의 gap 을 최소화 Find Real Requirement! 약 20%만이 자주 쓰이고, 45%는 아예 안쓰는 기능 focus on real requirement - Requirment Management (요구사항 관리) 정의 communication & precise data 기반으로 요구사항 추출/분석/추적을 진행하는 과정 RM Steps Decision making Communication Value Estimation Negotiation Trace Risk Management.. [소프트웨어공학] 소프트웨어공학(Software Engineering) - 정의 software problem 에 대한 cost-effective solution 을 얻기 위해 컴퓨터공학적, 수학적인 이론을 적용하는 공학 software를 개발, 운영, 유지보수에 대한 systematic, disciplined(규칙화 되어있는), quantifiable(정량화할 수 있는) approach를 적용하는 공학 - 특징 소프트웨어 역할의 변화 비즈니스 지원 -> 비즈니스 핵심 complexity Stakeholder 가 다양해지면서 개발 복잡도 증가 개발환경의 복잡도 증가 공학(Engineering)이란, 항상 일정한 output 을 내야하는데, SW의 complexity 때문에 소프트웨어공학이 어려움. Open source 오픈 아키텍처 기반 및 플랫폼 기반의 환경 구축으로 인한.. 이전 1 2 다음
