정처기 실기 요구사항 확인

소프트웨어 생명주기 : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

 - 요설구테유

 - 요구사항 분석

 - 설계

 - 구현

 - 테스트

 - 유지보수

 

소프트웨어 생명주기 모델 종류

 - 폭포수 모델 : 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델, 가장 오래된 모델, 성공 사례 많음

 - 프로토타이핑 모델 : 고객이 요구한 기능을 프로토타입으로 구현하여 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델

 - 나선형 모델 : 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발 (계획 및 정의 - 위험분석 - 개발 - 고객 평가)

 

애자일 : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적용하면서 효율적으로 시스템을 개발할 수 있는 방법론

 - XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

 - XP의 12가지 기본 원리

 - 지속적인 통합(Continuous) : 매일 여러번씩 소프트웨어를 통합하고 빌드해야 한다는 원리

  - 테스트 기반 개발(TDD : Test Driven Development) : 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 실제 프로그램 코드 작성

 - 리팩토링 : 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리

 

스크럼 : 매일 정해진 시간 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

 

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

 

객체지향 설계 원칙(SOLID)

 - 단일 책임의 원칙(SRP : Single Responsibility Principle) : 하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는데 집중되어 있어야 한다는 원칙

 - 개방폐쇄의 원칙(OCP : Open Close Principle) : 소프트웨어의 구성요소는 확장에는 열려있고 변경에는 닫혀있어야 한다는 원칙

 - 리스코프 치환의 원칙(LSP : Liskov Substitution Principle) : 서브타입은 어디서나 자신의 기반 타입으로 교체할 수 있어야 한다는 원칙

 - 인터페이스 분리의 원칙(ISP : Interface Segregation Principle) : 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙

 - 의존성 역전의 법칙(DIP : Dependency Inversion Principle) : 실제 사용 관계를 바뀌지 않으면서 추상을 매개로 메세지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

 

 

OMT (만든이 : 럼바우)

 - 객체 모델링 : 정보모델링이라고 함,시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의하여 ER다이어그램을 만드는 과정까지의 모델링

 - 동적 모델링 : 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링

 - 기능 모델링 : 프로세스들의 자료흐름을 중심으로 처리 과정 표현하는 모델링

 

비용산정

Man Month : (Loc) / (프로그래머의 월간 생산성)

프로젝트 기간 = (Man Month0) / (프로젝트 인력수)

 

델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미애예측을 위한 기법, 전문가 합의법

 

COCOMO 모형 : 보헴이 제안한 모형, 프로그램 규모에 따라 비용을 산정하는 방식

 

기능점수 모형 : 요구 기능을 증가시키는 인자별로 가중치를 부여하고 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용 산정

 

일정관리 모델 종류

 - 주 공정법(CPM) : 여러작업의 수행 순서가 얽혀있는 프로젝트의 일정을 계산

 - PERT : 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리

 

 

 

소프츠웨어 아키텍쳐 4+1뷰 (유논프구배)

 - 유스케이스 뷰 : 유스케이스 또는 아키텍쳐를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰

 - 논리뷰 : 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명

 - 프로세스 뷰 : 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰

 - 구현 뷰 : 개발 환경안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰

 - 배포 뷰 : 컴포넌트가 물리적인 아키텍쳐에 어떻게 배치되는가를 매핑해서 보여주는 뷰

 

 

계층화 패턴 : 시스템을 계층으로 구분하여 구성하는 패턴, 서로 마주 보는 두개의 계층 사이에서만 상호작용이 이루어짐

클라이언트-서버패턴 : 하나의 서버와 다수의 클라이언트로 구성된 패턴

파이프-필터패턴 : 서브 시스템이 입력데이터를 받아 처리하고 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복

모델-뷰-컨트롤러 패턴 : MVC패턴, 모델 : 핵심기능과 데이터 보관, 뷰 : 사용자에게 정보 표시, 컨트롤러 : 사용자로부터 요청을 입력받아 처리, 서로 영향을 받지않고 개발 작업 수행가능

 

목적에 따른 디자인패턴 유형

 - 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴

 - 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴

 - 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

 

생성패턴 - 생빌 프로 팩앱싱

Builder : 복잡한 인스턴스를 조립하여 만드는 구조로, 복합 객체를 생성할 때 객체를 생성하는 방법과 객체를 구현하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현결과를 만들 수 있는 디자인 패턴

Prototype

Factory Method : 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식, 상위클래스에서는 인스턴스를 만드는 방법만 결정하고, 하위 클래스에서 그 데이터의 생성을 책임지고 조작하는 함수들을 오버라이딩 하여 인터페이스와 실제 객체를 생성

Abstract Factory

Singleton

 

구조패턴 - 구 브데 퍼플 프록 컴 어

Bridge : 기능의 클래스 계층과 구현의 클래스 계층을 연결하고 구현부에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장

Decorator

Facade

Flyweigh

Proxy

Composite

Adapter : 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만드는 패턴, 상속을 이용하는 클래스 패턴과 위임을 이용하는 인스턴스 패턴의 두가지 형태로 사용되는 디자인 패턴

 

 

 

요구공학 : 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

요구공학 목적 : 이해관계자 사이에 효과적인 의사소통 수단 제공, 공통된 이해 설정

요구사항은 기능적 요구사항, 비기능적 요구사항으로 분류됨

 

브레인 스토밍 : 말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판없이 수용할 수 있도록 하는 회의

델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법

롤플레잉 : 여러사람이 각자가 맡은 역을 연기

워크숍

: 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법

 

정형 명세 기법 : 사용자의 요구를 수학적인 원리와 표기법으로 서술

비정형 명세 기법 : 사용자의 요구를 표현할 때 자연어를 기반으로 서술