[정처기 개념] 1. 요구 사항 확인

Chapter1. 소프트웨어 개발 방법론

1. 소프트웨어 생명 주기 모델

• 개념 : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
• 프로세스 : 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
• 소프트웨어 생명주기 모델 종류
  • 폭포수 모델 : SW 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델
  • 프로토타이핑 모델 : 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 SW를 만들어가는 모델
  • 나선형 모델 : 시스템 개발 시 위험을 최소하하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
    • 절차 : 계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가
  • 반복적 모델 : 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델

 

2. 소프트웨어 개발 방법론

• 개념 : SW 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법
• 종류
  • 구조적 방법론 : 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
    • 프로세스 중심의 하향식 방법론
    • 구조적 프로그래밍 표현을 위해 나씨-슈냐이더만 차트 사용
  • 정보공학 방법론 : 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
  • 객체 지향 방법론 : 객체라는 기본 단위로 시스템을 분석 및 설계하는 방법론
  • 컴포넌트 기반 방법론(CBD) : SW를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
    • 개발 기간 단축(생산성 향상), 새로운 기능 추가 쉬움(확장성), SW 재사용 가능
  • 애자일 방법론 : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
    • 개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론 -> 개발과 함께 즉시 피드백을 받아서 유동적 개발 가능
    • 유형
      • XP : 5가지 가치 및 12가지 기본원리
      • 스크럼(SCRUM) : 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
      • 린(Lean)
  • 제품 계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론

 

3. 객체 지향 분석 방법론

• 개념 : 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법
• 구성 요소

구성요소	설명
클래스	- 특정 객체 내에 있는 변수와 메서드를 정의하는 일종의 틀 - 객체 지향 프로그래밍에서 데이터를 추상화하는 단위 - 하나 이상의 유사한 객체들은 묶어서 하나의 공통된 특성을 표현 - 속성은 변수의 형태로, 행위는 메서드 형태로 선언
객체	- 물리적, 추상적으로 자신과 다른 것을 식별 가능한 대상 - 클래스에서 정의한 것을 토대로 메모리에 할당됨 - 객체마다 각각의 상태와 식별성을 가짐
메서드	- 클래스로부터 생성된 객체를 사용하는 방법 - 객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산 - 전통적 시스템의 함수 또는 프로시저에 해당되는 연산 기능
메시지	- 객체 간 상호 작용을 하기 위한 수단 - 객체에게 어떤 행위를 하도록 지시하는 방법 - 객체 간의 상호 작용은 메시지를 통해 이루어짐 - 메시지는 객체에서 객체로 전달됨
인스턴스	- 객체 기향 기법에서 클래스를 통해 만든 실제의 실형 객체 - 클래스에 속한 각각의 객체 - 실제로 메모리상에 할당
속성	- 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의 - 성질, 분류, 식별, 수량, 현재 상태 등에 대한 표현값

• 객체 지향 기법
  • 캡슐화 : 서로 연관된 데이터와 함수를 묶어 외부와 경계를 만들고 필요한 인터페이스만 밖으로 드러내는 기법
  • 상속성 : 상위 클래스의 속성과 메서드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법
  • 다형성 : 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
    • 오버로딩(메개변수 유형과 개수를 다르게, 이름 같게), 오버라이딩(완전 재정의 가능)
  • 추상화 : 공통 성질을 추출하여 추상 클래스를 설정하는 기법
  • 정보 은닉 : 코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근 가능하도록 하는 코드 보안 기술(모듈 사이 독립성 유지하는데 도움)
  • 관계성 : 연관화(is member of), 집단화(is part of), 분류화(is intance of), 일반화(is a), 특수화(is a)
• 객체 지향 설계 원칙(SOLID)

원칙	설명
단일 책임 원칙(SRP)	하나의 클래스는 하나의 목적을 위해 생성, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 것에 집중되어 있어야 함
개방 폐쇄 원칙(OCP)	SW 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 하는 원칙
리스코프 치환의 원칙(LSP)	서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 변경할 수 있어야 한다는 원칙
인터페이스 분리의 원칙(ISP)	- 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다 - 객체 설계 시 특정 기능에 대한 인터페이스는 그 기능과 상관없는 부분이 변해도 영향을 받지 않아야한다는 원칙
의존성 역전의 원칙(DIP)	객체에서 어떤 클래스를 참조해서 사용하는 경우, 그 클래스를 직접 참조하는 것이 아니라 그 대상의 상위 요소인 추상 클래스나 인터페이스로 참조하라는 원칙

 

• 객체 지향 분석 : 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 속성과 연산, 관계를 정의하여 모델링하는 기법
  • 방법론
    • OOSE(야콥슨) : 유스케이스
    • OMT(럼바우) : 객체 모델링 -> 동적 모델링 -> 기능 모델링 순서 그래픽 표기법
    • OOD(부치) : 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론
    • 코드-요든 방법론 : E-R 다이어그램
    • 워프-브록 방법론 : 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 분석 방법

 

4. 프로젝트 관리

• 비용 산정 모형
  • 하향식 산정방법 : 전문가 판단, 델파이 기법
  • 상향식 산정방법 : 코드 라인 수(LoC), Man Month, COCOMO 모형, 푸트남 모형, 기능점수(FP) 모형
    
    • COCOMO 모형 : 조직형(5만 라인 이하), 반 분리형(30만 라인 이하, 단순형과 임베디드형의 중간), 임베디드형(30만 라인 이상)
• 일정관리 모델
  • 주 공정법 
  • PERT : 비관치, 중간치, 낙관치
  • 중요 연쇄 프로젝트 관리

 

 

Chapter2. 현행 시스템 분석

1. 현행 시스템 파악

• 절차 : 구성/기능/인터페이스 파악 -> 아키텍쳐 및 SW 구성 파악 -> HW 및 네트워크 구성 파악
• 소프트웨어 아키텍쳐(4+1 뷰)
  • 유스케이스 뷰 
  • 논리 뷰 : 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
  • 프로세스 뷰 : 비기능적인 속성
  • 구현 뷰 : 개발 환경 안에서 정적인 SW 모듈 구성을 보여주는 뷰
  • 배포 뷰 : 컴포넌트가 물리적인 아키텍쳐에 어떻게 배치되는가를 매핑해서 보여주는 뷰
• 소프트웨어 아키텍쳐 패턴 유형
  • 계층화 패턴 : 시스템을 계층으로 구분, 서로 마주 보는 두 계층 사이에서만 상호작용
  • 클라이언트-서버 패턴 : 하나의 서버와 다수 클라이언트로 구성됨
  • 파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴
    • 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정 반복
    • 필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확장 용이
  • 브로커 패턴
  • 모델-뷰-컨트롤러 패턴
• 디자인 패턴
  • 생성 패턴 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴
  • 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
  • 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

출처 : https://velog.io/@bonni/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC-%EC%8B%A4%EA%B8%B0-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-%EC%A0%95%EB%A6%AC

2. 요구사항

• 분류

구분	기능적 요구사항	비기능적 요구사항
개념	시스템이 제공하는 기능, 서비스에 대한 요구사항	시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항
도출 방법	- 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대한 기술 - 특정 상황에 대해 시스템이 어떻게 동작해야 하는지에 대한 기술	- 품질 속성에 관련하여 시스템이 갖춰야 할 사항에 관한 기술 - 시스템이 준수해야 할 제한 조건에 관한 기술
특성	기능성, 완전성, 일관성	신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항
사례	- 온라인 홈페이지에서는 쇼핑카트에 주문하고자 하는 품목을 저장할 수 있는 장바구니 기능 제공해야 함	- 특정 함수의 호출시간은 2초를 넘어가면 안됨 - 시스템은 운영되는 중에 패치 및 업그레이드가 가능해야 함

 

• 요구사항 개발 단계 구성
  1. 요구사항 도출 단계 : 인터뷰, 브레인스토밍, 델파이 기법, 롤 플레잉, 워크숍, 설문조사
  2. 요구사항 분석 단계 : 데이터 흐름도(DFD), 자료 사전, UML
  3. 요구사항 명세 단계 : 비정형 명세 기법(자연어 기반 서술), 정형 명세 기법(수학적인 원리와 표기법 사용)
  4. 요구사항 확인 및 검증 단계
     • 동료 검토 : 2~3명에서 진행, 요구사항 명세서 작성자가 설명하고 이해관계자들이 들으면서 결함을 발견하는 형태로 진행되는 검토 방법
     • 워크 스루 : 오류를 조기에 검출하는 데 목적이 있는 검토 방법
       • 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태(비공식적인 검토 방법)
     • 인스펙션 : 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적인 검토 방법
       • 계획 -> 사전 교육 -> 준비 -> 인스펙션 회의 -> 수정 -> 후속 조치