요구사항 확인
소프트웨어 생명주기 모델(SDLC: Software Development Life Cycle)
- 소프트웨어 생명주기 : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
- 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화 한 것
- 프로세스 : 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
- 모델 종류 : 폭프나반
- 폭포수 모델(Waterfall Model)
- 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델(고전적 생명주기 모형)
- 절차 : 타당성 검토 -> 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
- 프로토타이핑 모델(Prototyping Model)
- 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델
- 나선형 모델(Spiral Model)
- 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
- 절차 : 계위개고 (계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가)
- 반복적 모델(Iteration Model)
- 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델
- 폭포수 모델(Waterfall Model)
소프트웨어 개발 방법론(Software Development Methodology)
- 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법
- 종류
- 구조적 방법론(Structured Development) : 전체 시스템을 기능에 따라 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
- 정보공학 방법론(Information Engineering Development) : 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
- 객체 지향 방법론(Object-Oriented Development) : '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론
- 컴포넌트 기반 방법론(CBD; Component Based Development) : 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
- 애자일 방법론(Agile Development) : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적용하면서 효율적으로 개발할 수 있는 신속 적응적 경량 개발 방법론
- 제품 계열 방법론(Product Line Development) : 특정 제품에 적용하고 싶은 공통된 기능을 정의하며 개발하는 방법론
애자일(Agile) 방법론
- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
- 종류
- XP(eXtreme Programming)
- 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
- 5가지 가치
- 용기(Courage)
- 단순성(Simplicity)
- 의사소통(Communication)
- 피드백(Feedback)
- 존중(Respect)
- 12가지 원리
- 짝 프로그래밍(Pair Programming)
- 공동 코드 소유(Collective Ownership)
- 지속적인 통합(CI; Continuous Integartion)
- 계획 세우기(Planning Process)
- 작은 릴리즈(Small Release)
- 메타포어(Metaphor)
- 간단한 디자인(Simple Design)
- 테스트 기반 개발(TDD; Test Driven Develop)
- 리팩토링(Refactorig)
- 40시간 작업(40-Hour Work)
- 고객 상주(On Site Customer)
- 코드 표준(Coding Standard)
- xp의 주요실천 방법 : 짝프로그래밍(Pair Programming), 공동 코드 소유(Collective Ownership), 테스트 주도 개발(Test-Driven Development), 전체 팀(Whole Team), 계속적인 통합(Continuous Integartion), 리팩토링(Refactoring), 소규모 릴리즈(Small Release)
- 스크럼(SCRUM)
- 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
- 주요 개념
- 백로그(Backlog) : 제품과 프로젝트에 대한 요구사항
- 스프린트(Sprint) : 2~4주의 짧은 개발 기간의 반복적 수행으로 개발품질 향상
- 스크럼 미팅(Scrum Meeting) : 매일 15분 정도 미팅으로 To-Do List 계획 수립(=데일리 미팅)
- 제품 책임자(PO; Product Owner) : 백로그를 작성하는 주체
- 스크럼 마스터(Scrum Master) : 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
- 스프린트 회고(Sprint Retrospective) : 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
- 소멸차트, 번 다운 차트(Burn Down Chart) : 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
- 린(LEAN)
- 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
- XP(eXtreme Programming)
객체 지향 분석(OOA; Object Oriented Analysis)
- 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법
- 객체지향분석 방법론 종류
- OOSE(Object Oriented Software Engineering)
- 야콥슨(Jacobsn)
- 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용하는 방법론
- OMT(Object Modeling Technology)
- 럼바우(Rumbaugh)
- 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론
- 분석 절차 : 객동기
- 객체 모델링(Object Modeling)
- 정보 모델링(Information Modeling)
- 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링
- 객체 다이어그램 활용
- 동적 모델링(Dynamic Modeling)
- 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현
- 상태 다이어그램 활용
- 기능 모델링(Functional Modeling)
- 프로세스의 자료흐름을 중심으로 처리 과정 표현
- 자료 흐름도(DFD) 활용
- 객체 모델링(Object Modeling)
- OOD(Object Oriented Design)
- 부치(Booch)
- 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론
- OOSE(Object Oriented Software Engineering)
비용산정 모형
- 소프트웨어 규모 파악을 통한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식
- 하향식 산정방법
- 전문가판단
- 델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법
- 상향식
- LoC(Lind of Code) : 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정해 예측치를 구해 비용을 산정하는 방식
- Man Month : 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정하는 방식
프로젝트 기간 = man month(LoC/프로그래머 월간 생산성)/프로젝트 인력 - COCOMO 모형 : 보헴이 제안, 프로그램 규모에 따른 비용 산정
- 조직형(Organic Mode) : 5만 라인 이하
- 반 분리형(Semi-Detached Mode) : 30만 라인 이하
- 임베디드형(Embedded Mode) : 30만 라인 이상
- 푸트남 (Putnam) 모형 : 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식, 생명주기 예측 모형, Rayleigh-Norden 곡선
- 기능점수(FP; Function Point)모형 : 요구 기능에 따른 가중치 부여
일정관리 모델
- 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델
- 주 공정법(CPM)
- 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정 계산(임계 경로는 가장 오래 걸리는 경로)
- 프로젝트의 시작에서 종료가지 가장 긴 시간이 걸리는 경로를 계산
- PERT(Program Evaluation and Review Technique) : 의 순서를 계획적으로 정리하기 위한 수렴 기법, 비관치, 중간치, 낙관치의 3점 추정방식 이용
- 중요 연새 프로젝트 관리(CCPM; Critical chain Project Management) : 주 공정 연쇄법으로 자원 제약 사항을 고려하여 일정을 작성하는 기법
현행 시스템 파악
구성/기능/인터페이스 파악 -> 아키텍처/소프트웨어 구성 파악 -> 하드웨어 및 네트워크 구성 파악
소프트웨어 아키텍처
여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구초체
소프트웨어 아키텍처 4+1뷰
- 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근방법
- 체크 방법으로 유스케이스를 사용한다
- 유스케이스(Usecase) : 시스템이 액터에게 제공해야 하는 기능으로서 시스템 요구사항이자, 사용자 입장에서 바라본 시스템의 기능
- 1(유스케이스 뷰) + 4(논리뷰, 프로세스 뷰, 구현 뷰, 배포 뷰)
- 구성 요소
- 유스케이스 뷰(Usecase View)
- 유스케이스 또는 아키텍처를 도출하고 설계하며 다른뷰를 검증하는데 사용되는 뷰
- 사용자/설계자/개발자/테스트 관점
- 논리 뷰(Logical View)
- 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
- 설계자/개발자 관점
- 프로세스 뷰(Process view)
- 시스템의 비기능적 요구사항
- 개발자/ 시스템 통합자 관점
- 구현 뷰(Implementation View)
- 개발 환경안에서 정적인 소프트웨어 모듈의 구성을 보여줌
- 배포 뷰(Deployment View)
- 어떻게 배치되는가
- 유스케이스 뷰(Usecase View)
소프트웨어 아키텍쳐 패턴(Software Architecture Pattern)
- 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결방식
- 유형
- 계층화 패턴(Layere Pattern) : 시스템을 계층으로 구분하여 구성하는 패턴
- 클라이언트-서버 패턴(Client-Server Pattern) : 하나의 서버와 다수의 클라이언트로 구성된 패턴
- 파이프-필터 패턴(Pipe-Filter Pattern) : 데이터 스트림을 생성하고 처리하는 시스템에서 사용
- 브로커 패턴(Broker Pattern) : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포넌트들은 원격 서비스 실행을 통해 상호 작용이 가능한 패턴
- 모델-뷰-컨트롤러 패턴(MVC; Model View Controller Pattern) : 대화형 애플리케이션을 모델, 뷰, 컨트롤러의 3개의 서브 시스템으로 구조화하는 패턴
- 모델 : 핵심 기능, 데이터 보관
- 뷰 : 사용자에게 정보 표시
- 컨트롤러 : 사용자로부터 요청 입력 받아 처리
소프트웨어 아키텍처 비용 평가 모델
- 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델
- SAAM : 변경 용이성, 기능성에 집중
- ATAM : 아키텍처 품질 속성을 만족시키는지 판단
- CBAM : 경제적 의사결정에 대한 요구를 충족하는지
- ADR : 응집도 평가 모델
- ARID : 특정 부분 품질 요소
디자인 패턴 (Desing Pattern)
- 소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
디자인 패턴 유형
- 목적에 따른 구분
- 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴
- 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
- 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴
- 범위에 따른 구분
- 클래스 : 클래스 간 관련성(상속 관계)을 다루는 패턴, 컴파일 타임에 정적으로 결정
- 객체 : 객체 간 관련성을 다루는 패턴, 런타임에 동적으로 결정
디자인 패턴 종류
- 생성 패턴
- Builder : 복잡한 인스턴스를 조립해 만드는 구조
- prototype : 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정해 사용하는 패턴
- factory method : 상위 클래스에서 인터페이스 정의, 하위클래스에서 인스턴스 생성
- abstract factory : 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공
- singleton : 전역 변수 사용하지 않고 객체 하나만 생성, 그 객체는 어디서든지 참조할 수 있음
- 구조
- adapter : 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
- birdge : 기능 계층과 구현 계층을 연결, 구현부에서 추상 계층 분리
- composite : 객체들의 관계를 트리 구조로 구성
- decorator : 기존에 구현되어 있는 클래스에 필요한 기능 추가해 나감
- facade : 복잡한 시스템에 대해 단순한 인터페이스 제공, 시스템 구조에 대한 파악 쉽게
- flyweight : 메모리 절약, '클래스의 경량화'목적
- proxy : 실체 객체에 대한 대리 객체
- 행위
- Mediator : 중간에 통제 중재자
- Interperter : 언어의 다양한 해석, 구문의 해석을 맡는 클래스 각각 작성
- Iterator : 컬렉션 구현 방법 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공
- Template Method : 상위 클래스-추상, 하위클래스-구체
- Observer : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락
- State : 상태에 따라 다르게 처리할 수 있도록 행위 내용 변경
- Visitor : 클래스의 메소드가 각 클래스를 돌아다닌며 특정 작업 수행
- Command : 명령어 들어오면 그에 맞는 서브 클래스 선택되어 실행
- Strategy : 알고리즘 군 정의하고(추상클래스), 같은 알고리즘을 각각 하나의 클래스로 캡슐화한 다음, 필요할때 서로 교환해서 사용할 수 있게 하는 패턴
- Memento : Undo(작업취소) 기능 개발
- Chain of Responsibility : 정적으로 어떤 기능에 대한 처리의 연결이 하드코딩되어 있을 때, 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 디자인
운영체제(0S; Operating System)
- 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고, 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램
- 사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원하는 소프트웨어
운영체제 현행 시스템 분석 시 고려사항
성능, 기술지원, 구축비용, 신뢰도, 주변기기
- 품질 측면
- 신뢰도 : 장기간 시스템 운영 시 운영체제의 장애 발생 가능성
- 성능 : 대규모 및 대량 파일작업(배치 작업)처리
- 지원 측면
- 기술 지원
- 주변 기기
- 구축 비용
OSI 7계층
- 물리 계층(Physical Layer)
- 0과 1의 비트정보를 회선에 보내기 위한 전기적 신호 변환
- 프로토콜 : RS-232C
- 전송 단위 : 비트(Bit)
- 데이터 링크 계층(Data Link Layer)
- 인접 시스템 간 데이터 전송, 전송 오류 제어
- 동기화,흐름제어 등의 전송 기능 제공
- 오류 검출/재전송 등의 기능 제공
- 프토토콜 : 이더넷
- 전송 단위 :프레임(Frame)
- 네트워크 계층(Network Layer)
- 단말 간 데이터 전송을 위한 최적화된 경로 제공
- 프로토콜 : IP, ICMP
- 전송 단위 : 패킷(Packet)
- 전송 계층(Transport Layer)
- 신뢰성 있는 통신 보장
- 데이터 분할과 재조립, 흐름제어, 오류제어, 혼잡제어 등을 담당
- 프로토콜 : TCP, UPD
- 전송 단위 : 세그먼트(Segment)
- 세션 계층(Session Layer)
- 연결 접속 및 동기 제어
- 프로토콜 : SSH, TLS
- 전송 단위 : 데이터(Data)
- 표현 계층(Presentation Layer)
- 데이터 형식 설정과 부호 교환, 암/복호화
- 프로토콜 : JPEG, MPEG
- 전송 단위 : 데이터(Data)
- 응용 계층(Application Layer)
- 사용자와 네트워크 간 응용서비스 연결, 데이터 생성
- 프토토콜 : HTTP, FTP
- 전송단위 : 데이터(Data)
DBMS 현행 시스템 분석시 고려사항 : 가성호기구
성능, 기술지원, 구축비용, 가용성, 상호호환성
- 성능 측면
- 가용성
- 성능
- 상호 호환성
- 지원 측면
- 기술 지원
- 구축 비용
미들웨어(Middleware)
- 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어
- 운영체제와 소프트웨어 애플리케이션 사이에 위치하고 있다.
- 대표적인 미들웨어로 WAS가 있다.
웹 애플리케이션 서버(WAS; Web Application Server)
- 서버 계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버
- 미들웨어 현행 시스템 분석 시 고려사항 : 성능 기술지원 구축비용 가용성
- 성능 측면
- 가용성
- 성능
- 지원 측면
- 기술 지원
- 구축 비용
- 성능 측면
요구공학(Requirements Enginerring)
- 사용자의 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동
- 요구 공학의 분류
- 기능적 요구사항 : 시스템이 제공하는 기능, 서비스에 대한 요구사항
- 비기능적 요구사항 : 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항
요구사항 개발 단계 구성 (도분명확)
- 도출
- 인터뷰 : 이해관계자와 직접대화
- 설문조사 : 설문지, 여론조사
- 브레인스토밍 : 말을 꺼내기 쉬운 분위기로 만들어 비판 없이 수용할 수 있도록 하는 회의
- 델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 방법
- 롤 플레잉 : 여러 사람이 각자가 맡은 역을 연기
- 워크숍 : 단기간에 다양하고 전문적인 정보를 흭득하고 공유
- 분석
- 청취 기술
- 인터뷰와 질문 기술
- 명세
- 비정형 명세 기법
- 자연어 기반
- 사용자와 개발자 이해 용이
- 명확성 및 검증 문제
- 정형 명세 기법
- 수학적인 원리와 표기법, Z-스키마, Petri Nets
- 표현 간결, 명확성 및 검증 용이
- 기법 이해 어려움
- 비정형 명세 기법
- 확인 및 검증
- 동료 검토 : 2~3명이 진행, 작성자가 명세서 설명하고 이해관계자들이 설명을 들으면서 결함 발견
- 워크스루 : 검토자료를 회의전에 배포해서 사전검토한 후 짧은 시간동안 회의 진행
- 인스펙션 : 저작자 외의 다른전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
'정보처리기사 > 실기' 카테고리의 다른 글
| 정보처리기사 정리본(1,2,4) (0) | 2023.04.17 |
|---|---|
| 정보처리기사 - 7. 애플리케이션 테스트 관리 (1) | 2023.04.16 |
| 정보처리기사 - 4.서버 프로그램 구현 (2) | 2023.04.16 |
| 정보처리기사 - 2.데이터 입출력 구현 (0) | 2023.04.14 |
| 정보처리기사 - 6.화면설계 (0) | 2023.04.14 |
