1. 폭포수 모형 (waterfall Model)
: 한 단계가 완전히 끝나야만 다음 단계로 넘어가는 개발 방법론
- 가장 오래되고 폭넓게 사용된 고전적 생명주기 모형
- 제품의 일부가 될 매뉴얼을 작성해야 함.
- 각 단계가 끝난 후 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함.
2. 나선형 모형 (Sprial Model, 점진적 모형)
: 소프트웨어 개발 과정을 여러번 반복하면서 진행하는 개발 방법
- 위험을 관리하고 최소화하는 것이 목적
- 점진적으로 개발과정이 반복되므로 누락되거나 추가도니 요구사항을 추가 할 수 있다.
- 정밀하며, 유지보수 과정이 필요없다.
3. 애자일 모형 (Agile Model)
: 고객의 다양한 요구사항의 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하는 개발 과정.
- 짧은 개발 주기 : sprint, iteration 등을 반복
1. Scrum( 스크럼 ) 기법
: 팀이 중심이 되어 개발의 효율성을 높인다.
구성 | 프로세스(구성요소) |
1. 제품 책임자 (PO; Product Owner) |
제품 백로그 설정 → 스프린트 백로그 설정 → 스프린트 수행 → 데일리 미팅 → 스프린트 회고 ( 스프린트 계획 회의 → 스프린트 → 일일 스크럼 회의 → 스프린트 검토 회의 → 스프린트 회고 ) |
백로그 : 제품 개발에 필요한 요구 사항을 모두 모아 우선순위를 부여해놓은 목록
XP ( eXtreme Programming ) 기법
: 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발의 생산성을 향상
구성 요소) 사용자 스토리 / 스파이크* / 이터레이션* / 테스트 주도 개발
핵심 가치) 의사소통, 단순성, 용기, 존중, 피드백
스파이크 : 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
이터레이션 : 하나의 릴리즈를 더 세분화 한 단위
웹 애플리케이션 서버 ( WAS : Web Application Server )
: 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어*
- 데이터 접근 / 세션 관리 / 트랜잭션 관리 등을 위한 라이브러리 제공
- 데이터베이스 서버와 연동해서 사용
- Tomcat, Galssfish, JBoss, Jetty, JEUS, Resin, WebSphere 등
미들웨어
: 운영체제와 해당 운영체제에 의해 실행되는 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어
기능 요구사항 | 비기능 요구사항 |
- 시스템이 무엇을 하는지, 어떠한 기능을 하는지에 대한 사항 - 시스템이 반드시 수행해야 하는 기능 |
- 품질 / 제약 사항에 관련한 사항 |
프로토타이핑 (Prototyping)
: 초기 도출된 요구사항을 토대로 프로토타입을 만든 후,
대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정.
장점 | 단점 |
- 빠른 제작 가능 / 반복 제작으로 발전된 결과물 - 피드백이 가능 - 서로의 의사소통이 원활 - 시스템의 문제점을 완성 전에 식별 가능 |
- 대상 범위를 잘못 이해하여 사용성이 과대 평가 될 수 있다. - 비용 부담이 생길 수 있다. |
UML ( Unified Modeling Language )
: 개발자 상호간의 의사소통이 원활하게 이루어지오록 표준화한 대표적인 객체지향 모델링 언어 (개념 모델링)
- 6개의 구조 다이어그램 + 7개의 행위 다이어그램
- 구성요소 : 사물 / 관계 / 다이어그램
사물 | 관계 | 다이어그램 |
관계가 형성될 수 있는 대상 [ 구조 / 행동 / 그룹 / 주해 ] |
사물과 사물사이의 연관성을 표현 - 실선으로 연결, 방향성은 화살표. - 양방향의 관계 : 실선 |
정적 모델링 = 구조적 다이어그램 동적 모델링 = 행위 다이어그램 |
사용자 인터페이스의 구분
CLI (Command Line Interface) : 명령과 출력이 텍스트 형태로 이루어지는 인터페이스
GUI (Graphical User Interface) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스
NUI (Natural User Interface) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
기본 원칙 ]
- 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 함.
- 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야 함.
- 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 함.
- 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화.
UI 설계 도구
와이어프레임 ( wireframe ) |
- 기획 단계의 초기에 제작 = 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계 - 화면 단위로 설계 - 개발자/디자이너가 레이아웃을 협의하거나 진행상태 공유 위해 사용 [ 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등 ] |
스토리보드 ( Story Board ) |
- 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서 - 디자이너/개발자가 최종적으로 참고하는 작업 지침서. [ 파워포인트, 키노트, 스케치, Axure 등 ] |
프로토타입 ( Prototype ) |
- 위의 두 가지에 인터렉션*을 적용함으로써 실제 구현된 것 처럼 테스트가 가능한 동적인 형태의 모형 [ HTML/CSS, Axure, Flinto, 네이버 프로토나우, 카카오 오븐 등 ] - 필요한 기능은 반드시 포함되어야 함, - 실제 사용자를 대상으로 테스트 하는 것이 좋음. |
유스케이스 ( Use Case ) |
- 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술. |
인터렉션 : 사용자-시스템을 연결하는 UI, 이를 통해 시스템을 사용하는 일련의 상호 작용을 의미.
소프트웨어 아키텍쳐 설계의 기본 원리
모듈화 | 성능을 향상시키거나 시스템의 수정 및 재사용, 유지관리 등을 위해 시스템의 기능들을 모듈 단위로 나누는 것을 의미 - 재사용성 향상 / 많아지면 개발비용 상승 |
추상화 | 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화 하여 구체화시켜 나가는 것 - 여러가지 요인들을 테스트 할 수 있음. |
단계적 분해 | 하향식 설계전략, 상위 중요 개념으로부터 하위의 개념으로 구체화 시키는 분할 기법 - 반복에 의해 세분화 됨 |
정보 은닉 | 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법 |
아키텍쳐 패턴
레이어 패턴 | 시스템을 계층(Layer)으로 구분하여 구성하는 고전적인 방법 중의 하나. - 각각의 서브시스템들이 계층 구조를 이루며, 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트가 된다. - OSI 참조모델 |
클라이언트-서버 | 하나의 서버 컴포넌트와 다수의 클라이언트로 구성. - 사용자는 클라이언트와만 의사소통. - 서버는 항상 대기 상태를 유지. - 동기화 되는 경우를 제외하고는 서로 독립적. |
파이프-필터 | 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송. - 재사용성이 좋고, 확장이 용이. - 데이터 변환 / 버퍼링 / 동기화 등에 주로 사용. - UNIX, Shell |
모델-뷰-컨트롤러 | 서브시스템을 3개의 부분으로 구조화하는 패턴 - 모델 : 서브시스템의 핵심 기능과 데이터를 보관. - 뷰 : 사용자에게 정보를 표시 - 컨트롤러 : 사용자로부터 받은 입력을 처리. - 서로 독립적인 컴포넌트 - 여러 개의 뷰를 만들 수 있음. |
객체지향
구성 요소)
클래스 | - 공통된 속성과 연산을 갖는 객체의 집합, 객체의 일반적인 타입을 의미. - 각각의 객체를 인스턴스라고 함. |
특징)
캡슐화 | - 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것. - 인터페이스를 제외한 세부 내용이 은폐되어 외부에서 접근이 제한적. |
상속 | - 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려 받는 것. + 나의 기능 추가 가능 - 소프트웨어의 재사용을 높이는 개념. - 다중상속 : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 상속 받는 것 가능. |
다형성 | - 하나의 메시지에 대해 각각의 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할 수 있는 능력 - 동일한 메소드명을 사용하여, 같은 의미의 응답을 함. |
결합도와 응집도
= 결합도는 약하게, 응집도는 강하게, 모듈의 크기는 작게.
결합도 | 모듈 간의 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미. |
자료 결합도 → 스탬프 결합도 → 제어 결합도 → 외부 결합도 → 공통 결합도 → 내용 결합도 |
응집도 | 모듈의 내부요소 들의 서로 관련되어 있는 정도 ( 모듈이 독립적인 기능으로 정의되어 있는 정도 ) |
기능적 응집도 → 순차적 응집도 → 교환적 응집도 → 절차적 응집도 → 시간적 응집도 → 논리적 응집도 → 우연적 |
FAN IN 들어오면 1 / FAN OUT 나가면 1
코드의 종류
순차 코드 | 일정 기준에 따라서 최초의 자료부터 차례로 일련번호를 부여 |
블록 코드 | 공통성이 있는 것끼리 블록으로 구분, 각 블록내에서 일련번호 부여 (구분코드) |
그룹 분류 코드 | 코드화 대상 항목을 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고, 그 안에서 일련번호 부여. |
연상코드 | 코드화 대상 항목의 명칭 등과 관계있는 순자/문자/기호를 이용하여 코드 부여 |
디자인 패턴
생성
: 캡슐화 하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 함.
메소드 ( method ) |
- 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴 - 상위 : 인터페이스 정의 / 하위 : 실제 생성 |
팩토리 ( factory ) |
- 인터페이스를 통해 서로 연관/의존하는 객체들의 그룹으로 생성하여 추상적으로 표현 |
싱글톤 ( singleton ) |
- 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 동시에 참조할 수는 없다. - 클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화 할 수 있다. |
구조
: 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴
퍼씨드 ( facade ) |
- 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 함. - wrapper 객체가 필요하다. (통합 인터페이스) |
프록시 ( proxy ) |
- 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴 - 네트워크 연결, 메모리의 대용량 객체로의 접근에 주로 이용. |
행위
: 서로 상호작용 하는 방법이나 책임 분배 방법을 정의하는 패턴
템플릿 ( template ) |
상위 : 골격정의 / 하위 : 세부 처리를 구체화 - 공통 내용을 묶어 정의하므로, 코드의 양 줄고 유지보수가 쉬움 |
커맨드 ( command ) |
- 요청을 객체의 형태를 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴 |
옵서버 ( observer ) |
- 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴 |
요구사항 검증 방법
동료검토 | 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고, 동료들이 이를 들으면서 결함을 발견 |
워크스루 | 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후에 회의를 통해 결함을 발견 |
인스펙션 | 요구사항 명세서를 작성자를 제외한 다른 검토 전문가들이 확인하여 결함을 발견 |
'IT Programmer > Certification (정보처리기사)' 카테고리의 다른 글
[정보처리기사 필기 대비] 4과목 프로그래밍 언어 활용 (0) | 2020.08.21 |
---|---|
[정보처리기사 필기 대비] 3과목 데이터베이스 구축 (0) | 2020.08.19 |
[정보처리기사 필기 대비] 2과목 소프트웨어 개발 (0) | 2020.08.19 |
[4과목_프로그래밍 언어 활용] 오답노트2 (0) | 2020.08.17 |
[4과목_프로그래밍 언어 활용] 오답노트 (0) | 2020.08.17 |