[정보처리기사 실기] 1. 요구사항 확인

요구사항 확인

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

• 구조적 방법론 - 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
• 정보공학 방법론 - 정보시스템 개발에 필요한 관리 절차와 작업 기반을 체계화한 방법론
• 객체 지향 방법론 - ‘객체’라는 기본 단위로 시스템을 분석 및 설계하는 방법론
• 컴포넌트 기반 방법론 - 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
• 애자일 방법론 - 절차보다 사람이 중심이 되어 변화에 유연하고 신속하게 적용하면서 효율적으로 시스템을 개발할 수 있는 방법론
• 제품 계열 방법론 - 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
• SDLC (소프트웨어 생명 주기)SDLC 모델 종류
  • 폭포수 모델 Waterfall Model
    • 마무리 지은 후 다음 단계로 넘어가는 모델
  • 프로토타이핑 모델 Prototype Model
    • 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델
  • 나선형 모델 Spiral Model
    • 위험을 최소화, 점진적 모형
    • 계획 수립 → 위험 분석 → 개발 → 고객 평가 (계위개고)
  • 애자일 모델 Agile Model
    • 요구 사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모델
• 시스템 요구분석부터 유지보수까지 전 공정을 체계화한 절차
• 애자일 방법론
  • 의사소통, 용기, 단순성, 존중, 피드백
  • 스크럼 Scrum
    • 팀원들이 스스로 팀을 구성
    • 2~4주 기간
    • 개발에 필요한 요구사항에 우선순위를 부여한 제품기능 목록(Product Backlog)을 작성
    • 스프린트 계획 회의 → 스프린트 → 일일 스크럼 회의 → 스프린트 검토 회의 → 스프린트 회고
    1. 제품 책임자(Product Owner)가 Backlog 작성
    2. 스크럼 마스터(SM; Scrum Master): 가이드 역할
  • XP (eXtreme Programming)
    1. Pair Programming 짝 프로그래밍: 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성
    2. Collective Ownership 공동 코드 소유: 개발 코드에 대한 책임을 공동으로 소유
    3. Test-Driven Development 테스트 주도 개발: 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 무엇을 해야하는지 정확히 파악, 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구를 사용
    4. Whole Team 전체 팀: 개발에 참여하는 모든 구성원 (고객 포함)들은 각자 자신의 역할이 있고 그 역할에대한 책임을 가져야함
    5. Continuous Integration 계속적인 통합: 모듈 단위로 나눠 개발된 코드들은 하나의 작업이 마무리 될 때마다 지속적으로 통합 됨
    6. Refactoring 리팩토링: 프로그램을 쉽게 이해하고 수정하여 빠르게 개발하기 위함, 프로그램 기능의 변경 없이 시스템을 재구성함
    7. Small Releases 소규모 릴리즈: 릴리즈 기간을 짧게 반복함으로써 고객 요구 변화에 신속히 대응 가능
    • 릴리즈 테스트마다 고객을 직접 참여시킴으로써 요구한 기능이 제대로 작동하는지 고객이 직접 확인할 수 있는 모형
    • 릴리즈 계획 수립 → 이터레이션 → 승인 검사 → 소규모 릴리즈

DB 설계 절차

 

객체지향 설계 원칙 SOLID

• SRP 단일책임 (Single Responsibility Principle)

작성된 클래스는 하나의 기능만 가지며 클래스가 제공하는 모든 서비스는 그 하나의 책임을 수행하는데 집중되어있어야 함

• OCP 개방폐쇄 (Open Close Principle)

확장에는 열려있고, 변경에는 닫혀있어야 한다

• LSP 리스코브 치환 (The Liskov Substitution Principle)

서브 타입은 언제나 기반 타입과 호환가능해야함

• ISP 인터페이스 분리 (Interface Segregation Principle)

자신이 사용하지 않은 인터페이스는 구현하지 않아야함

• DIP 의존성 역전 (Dependency Inversion Principle)

하위 모듈의 변경이 상위 모듈이 변경을 요구하는 위계관계를 끊는 의미의 역전

 

리팩토링 Refactoring

소프트웨어를 보다 쉽게 이해하고 수정할 수 있도록 개선하기 위함

소프트웨어 모듈의 외부적 기능은 수정하지 않고 내부적으로 구조, 관계 등을 단순화하여 소프트웨어의 유지보수성을 향상시키는 기법

유지보수성 향상	복잡한 코드의 단순화, 소스의 가독성 향상
유연한 시스템	소프트웨어 요구 사항 변경에 유연한 대응
생산성 향상	정제 및 최적화된 소스의 재사용
품질 향상	소프트웨어 오류 발견이 용이하여 품질 향상

UML (Unified Modeling Language)

개발 과정에서 의사소통을 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

 

Diagram

사물과 관계를 도형으로 표현한 것

• 구조적 다이어그램 - 정적 모델링
  • 클래스 ****(Class) 다이어그램 : 클래스와 클래스가 가지는 속성
  • 객체 ****(Object) 다이어그램 : 특정 시점의 객체와 객체 사이의 관계로 표현, 럼바우 객체지향 객체 모델링
  • 컴포넌트(Component) 다이어그램 : 컴포넌트 간의 관계 / 구현 단계
  • 배치 (Deployment) 다이어그램 : 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현 / 구현 단계
  • 복합체 구조(Composite Structure) 다이어그램 : 복합 구조를 갖는 클래스나 컴포넌트의 내부 구조를 표현
  • 패키지(Package) 다이어그램 : 유스케이스나 클래스 등의 요소들을 그룹화한 패키지들의 의존 관계를 표현
• 행위 다이어그램 - 동적 모델링
  • 유스케이스(UseCase) : 사용자 요구 분석 / 사용자와 공유
  • 시퀀스(Sequence) : 상호 작용하는 시스템이나 객체들이 주고 받는 메시지
  • 커뮤니케이션(Communication): 동작에 참여하는 객체들이 주고받는 메시지뿐만 아니라 객체들 간의 연관 관계를 표현
  • 상태(State): 상태가 어떻게 변화하는지 표현, 럼바우 객체지향 동적 모델링
  • 활동(Activity): 객체의 처리 로직, 처리의 흐름을 순서대로 표현 / 사용자와 공유
  • 상호작용 개요(Interaction Overview): 제어 흐름 표현
  • 타이밍(Timing): 객체 상태 변화와 시간 제약을 명시적으로 표현
• 스테레오 타입
  • <<include>> 포함
  • <<extends>> 확장
  • <<interface>> 인터페이스 정의
  • <<exception>> 예외 정의
  • <<constructor>> 생성자
• UML에서 표현하는 기본 기능 외 추가적인 기능을 표현
• 소프트웨어 개발 프레임워크특성
  • 모듈화 Modularity
  • 재사용성 Reusability
  • 확장성 Extensibility
  • 제어의 역흐름 Inversion Of Control
  종류
  • 스프링 프레임워크
  • 전자정부 프레임워크
  • 닷넷 프레임워크
• 럼바우 객체지향 분석