소프트웨어 개발 방법론

소프트웨어 개발 방법론

1. 소프트웨어 개발 방법론 종류

종류	내용
구조적 방법론 (Structured)	- 전체 시스템을 기능에 따라 나눠 개발하고, 이를 통합하는 분할과 정복접근 방식의 방법론 - 하향식 방법론 - 나씨-슈나이더만 차트 사용     ※ 나씨-슈나이더만 차트         - 논리의 기술에 중점을 둔 도형식 표현 방법         - 연속, 선택 및 다중 선택, 반복 등 제어 논리 구조로 표현         - 조건이 복합된 곳의 처리를 시각적으로 명확히 처리하는 데 적합
정보공학 방법론 (Information Engineering)	- 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법
객체 지향 방법론 (Object-Oriented)	- 객체를 기본 단위로 시스템을 분석 및 설계하는 방법론 - 객체, 클래스, 메시지를 사용
컴포넌트 기반 방법론 (Component Based)	- SW를 구성하는 컴포넌트를 조립해 새로운 응용 프로그램을 작성하는 방법론     ※ 컴포넌트 : 원하는 DB와 SW의 개발된 모듈 단위
애자일 방법론 (Agile)	- 절차보단 사람이 중심. 변화에 유연하고 신속 적응하며, 효율적 시스템 개발 가능한 신속 적응적 경량 개발 방법론
제품 계열 방법론 (Product Line)	- 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발하는 방법론 - 임베디드 SW를 작성하는데 유용 - 영역 공학과 응용 공학으로 구분

 

2. 애자일(Agile) 방법론

 - 절차보단 사람이 중심. 변화에 유연하고 신속 적응하며, 효율적 시스템을 개발 가능한 신속 적응적 경량 개발 방법론

 - 즉시 피드백을 받아 유동적으로 개발 가능

 - 요구사항은 기능 중심 정의

 

 - 애자일 방법론 유형

종류	내용
XP (eXtreme Programming)	- 의사소통 개선과 즉각적 피드백으로 SW 품질을 높이기 위한 방법론 - 1~3주의 반복 개발 주기     - XP의 5가지 가치         - 용기 : 용기를 가지고 자신감 있게 개발         - 단순성 : 필요한 것만 하고 그 이상은 X         - 의사소통 : 개발자, 관리자, 고객 간의 원활한 소통         - 피드백 : 의사소통에 대한 빠른 피드백         - 존중 : 팀원 간의 상호 존중     - XP의 12가지 기본원리         - 짝 프로그래밍 (Pair Programming)             - 개발자끼리 짝으로 코딩하는 원리         - 공동 코드 소유 (Collective Ownership)             - 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리         - 지속적인 통합 (Continuous Integration)             - 매일 SW를 통합 & 빌드해야 하는 원리          - 계획 세우기 (Planning Process)             - 고객이 요구한 가치를 정의하고, 개발자가 한 것은 무엇인지, 어떤 부분에 지연될 수 있는               지 알려 줘야 한다는 원리         - 작은 릴리즈 (Small Release)            - 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리         - 메타포어 (Metaphor)             - 고객과 개발자간의 의사소통을 한다는 원리         - 간단한 디자인 (Simple Design)            - 가장 단순한 시스템을 설계한다는 원리         - 테스트 기반 시스템 (TDD : Test Driven Develop)            - 테스트를 먼저 수행후, 테스트를 통과할 수 있도록 실제 프로그램 코드를 작성한다는 원리        - 리팩토링 (Refactoring)             - 프로그램 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리         - 40시간 작업 (40-Hour Work)            - 일주일에 40시간 이상 일하지 않는다는 원리         - 고객 상주 (On Site Customer)            - 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리         - 코드 표준 (Coding Standard)             - 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리
스크럼(SCRUM)	- 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론     - 주요개념         - 백로그 : 제품과 프로젝트에 대한 요구사항         - 스프린트 : 2~4주의 짧은 개발 기간에 반복적 수행으로 개발품질 향상         - 스크럼 미팅 : 매일 15분 정도 To-Do List 계획 수립 (데일리 미팅이라고도 함)         - 스크럼 마스터 : 프로젝트 리더         - 스프린트 회고 : 스프린트 주기를 되돌아 보며, 규칙 준수 여부, 개선점을 확인 및 기록         - 번 다운 차트 : 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
린 (LEAN)	- 도요타의 린 품질기법을 적용해 낭비 요소를 제거하여 품질을 향상시킨 방법론

 

3. 객체 지향

- 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법

 

4. 객체 지향 구성요소

- 클래스, 객체, 메서드, 메시지, 인스턴스, 속성

 

5. 객체 지향 기법

기법	설명
캡슐화 (Encapsulation)	외부에서의 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉
상속성 (Inheritance)	상위 클래스의 속성과 메서드를 하위 클래스가 물려받음
다형성 (Pdymorphism)	하나의 메시지에 대해 각 객체가 갖고 있는 고유한 방법대로 응답
추상화 (Abstraction)	불필요한 부분을 생략하고, 객체 속성 중 가장 주요한 것에 중점을 주어 모델화
정보은닉 (Information Hiding)	다른 객체로부터 자신의 자료를 숨기고 자신의 연산만을 통하여 접근을 허용
관계성 (Relationship)	두 개 이상의 객체들이 상호 참조하는 관계

 

5. 객체 지향 설계 원칙(SOLID)

원칙	설명
단일 책임의 원칙 (SRP : Single Responsibility Principle	하나의 클래스는 하나의 목적을 위해 생성. 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는데 집중
개방 폐쇄 원칙 (OCP : Open Close Principle)	SW의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려 있고, 변경에는 닫혀있어야 함
리스코프 치환의 원칙 (LSP : Liskov Substitution Principle)	서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 함
인터페이스 분리의 원칙 (ISP : Interface Segregation Principle)	한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 함
의존성 역전의 원칙 (DIP : Dependency Inversion Principle)	실제 사용관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만듦