1. 소프트웨어 개발방법론
🔷 소프트웨어 생명주기( SDLC ) 🔔
시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
- 폭포수 모델 : 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감
- 프로토타이핑 모델 : 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백 반영
- 나선형 모델 : 위험을 최소화하기 위해 점진적으로 완벽한 시스템 개발
- 반복적 모델 : 구축대상을 나누어 병렬적, 반복적 개발 후 통합
🔷 소프트웨어 개발방법론 🔔
소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차
- 구조적 방법론 : 전체를 기능에 따라 나누어 개발 + 통합 ( 하향식 접근 & 나씨-슈나이더만 차트 )
- 정보공학 방법론 : 정보시스템 개발에 필요한 관리절차와 작업 기법 체계화 ( 대형 프로젝트 )
- 객체지향 방법론 : '객체'라는 기본 단위로 시스템 분석 및 설계 ( 객체 , 클래스 , 메시지 )
- 컴포넌트 기반 방법론 : 소프트웨어를 구성하는 컴포넌트를 조립해서 SW 개발 ( 확장성 , 재사용 )
- 애자일 방법론 : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응 ( 효율 , 신속 )
- 제품 계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능 정의하여 개발 ( 임베디드 SW )
📝 나씨-슈나이더만 차트 : 논리의 기술에 중점을 둔 도형식 표현 방법
🔷 애자일( Agile ) 방법론 ⭐ 🔔
절차보다는 사람을 중심으로 변화에 유연하고 신속하게 적응 & 개발기간이 짧고 신속
◼ XP ( eXtreme Programming)
의사소통 개선과 즉각적 피드백으로 SW 품질을 높임
[1] XP의 5가지 가치
- 용기
- 단순성
- 의사소통
- 피드백
- 존중
[2] XP의 12가지 기본원리
- 짝 프로그래밍
- 공동 코드 소유
- 지속적인 통합 ( CI )
- 계획 세우기
- 작은 릴리즈
- 메타 포어
- 간단한 디자인
- 테스트 기반 개발 ( TDD )
- 리팩토링
- 40시간 작업
- 고객 상주
- 코드 표준
◼ 스크럼 ( SCRUM )
매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 프로젝트 관리 중심
- 백로그 ( Backlog ) : 제품과 프로젝트에 대한 요구사항
- 스프린트 ( Sprint ) : 2~4주의 짧은 개발 기간의 반복적 수행으로 품질 향상
- 스크럼 미팅 ( Scrum Meeting ) : 매일 15분 정도의 미팅으로 To-Do List 계획 수립 / 데일리 미팅 ( Daily Meeting )
- 스크럼 마스터 ( Scrum Master ) : 프로젝트 리더 / 스크럼 수행 시 문제 인지 & 해결하는 사람
- 스프린트 회고 ( Sprint Retrospective ) : 스프린트 주기를 되돌아보며 규칙 준수 여부, 개선점 등 확인 및 기록
- 번 다운 차트 ( Burn Down Chart ) : 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
◼ 린 ( LEAN )
도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용 -> 낭비요소 제거 및 품질 향상
- JIT ( Just In Time ) 사용
- 칸반 ( Kanban ) 보드 사용
7가지 원칙
낭비 제거 / 품질 내재화 / 지식 창출 / 늦은 확정 / 빠른 인도 / 사람 존중 / 전체 최적화
🔷 비용산정 모형 🔔
소프트웨어 규모파악을 통한 투입 자원, 소요시간을 파악하여 계획의 비용을 산정
- 하향식 산정기법
◼ 전문가 판단
◼ 델파이 기법
전문가의 경험적 지식을 통한 문제 해결 기법
- 상향식 산정기법
◼ 코드 라인 수 ( Loc ; Lines of Code )
각 기능의 원시 코드 라인의 낙관치, 중간치, 비관치를 통해 예측
- 낙관치 : 가장 적게 측정된 코드 라인 수
- 중간치 : 측정된 모든 코드 라인 수
- 비관치 : 가장 많이 측정된 코드 라인 수
- 예측치 = ( 낙관치 + 4*중간치 + 비관치 ) / 6
◼ Man Month ⭐
한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 비용 산정
- Man Month = LoC / 프로그래머의 월간 생산정
- 프로젝트 기간 = Man Month / 프로젝트 인력
◼ COCOMO ( COnstructive COst MOdel ) 모형
프로그램 규모에 따라 비용 산정
- 조직형 : 기관 내부에서 개발된 중/소규모의 SW ( 5만( 50KDSI ) 라인 이하 )
- 반 분리형 : 조직형과 임베디드형의 중간 ( 30만( 300KDSI ) 라인 이하 )
- 임베디드형 : 초대형 규모 시스템 프로그램 개발에 적용 ( 30만( 300KDSI ) 라인 이상 )
◼ 푸트남 ( Putnam ) 모형
개발주기의 단계별로 요구할 인력의 분포를 가정
◼ 기능 점수 ( FP ; Function Point ) 모형
요구 기능을 증가시키는 인자별로 가중치 부여, 총합으로 비용 산정
- 기능점수( FP ) = 총 기능점수 x [ 0.65 + ( 0.1 x 총 영향도 ) ]
🔷 일정관리 모델 🔔
프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델
◼ 주 공정법 ( CPM ; Critical Path Method )
- 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 방법
- 프로젝트의 시작에서 종료까지 가징 긴 시간이 걸리는 경로를 계산
◼ PERT ( Program Evaluation and Review Technique )
- 일의 순서를 계획적으로 정리하기 위한 수렴 기법
- 비관치, 중간치, 낙관치 3점 추정방식을 통해 일정 관리
◼ 중요 연쇄 프로젝트 관리 ( CCPM ; Critical Chain Project Management )
- 주 공정 연쇄법
- 자원제약사항을 고려하여 일정을 작성하는 기법
✔ 주 공정법( CPM )을 이용한 일정 계산
프로젝트의 시작에서 종료까지 가징 긴 시간이 걸리는 경로를 계산한다.
2. 현행 시스템 분석
🔷 현행 시스템 파악
현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 제공 기능 및 기술 요소 등을 파악하는 활동
-
시스템 구성 / 기능 / 인터페이스 파악
-
아키텍처 및 SW 구성 파악
-
하드웨어 및 네트워크 구성 파악
🔷 소프트웨어 아키텍처
여러 가지 소프트웨어 구성요소와 특성, 관계를 표현하는 시스템 구조 또는 구조체
🔷 소프트웨어 아키텍처 4+1 뷰 🔔
고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법
4개의 분리된 구조로 개념을 제시하고, 이들 구조의 충돌 여부 등을 유스케이스로 검증한다.
📝 유스케이스 ( Usecase ) : 시스템이 액터( 사용자 )에게 제공해야 하는 기능
◼ 유스케이스 뷰
- 유스케이스 or 아키텍처 도출 & 설계 + 다른 뷰 검증
- 사용자 & 설계자 & 개발자 & 테스트 관점
◼ 논리 뷰
- 시스템의 기능적 요구사항이 어떻게 제공되는지 설명
- 설계자 & 개발자 관점
◼ 프로세스 뷰
- 시스템의 비기능적인 속성 표현 ( 자원의 이용 , 이벤트 처리 등 )
- 개발자 & 시스템 통합자 관점
◼ 구현 뷰
- 개발 환경 안에서 정적인 SW 모듈의 구성 설명
- 컴포넌트 구조 & 의존성 & 부가적인 정보
◼ 배포 뷰
- 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 설명
🔷 소프트웨어 아키텍처 패턴 🔔
SW를 설계할 때 참조할 수 있는 전형적인 해결방식 ( 일반화 , 재사용 솔루션 )
◼ 계층화 패턴 ( Layered Pattern )
시스템을 계층( Layer )으로 구분하여 구성
◼ 클라이언트-서버 패턴 ( Client-Server Pattern )
하나의 서버( Server )와 다수의 클라이언트( Client )로 구성
◼ 파이프-필터 패턴 ( Pipe-Filter Pattern )
데이터 스트림을 생성하고 처리하는 시스템에서 사용 ( 시스템 → 시스템 )
◼ 브로커 패턴 ( Broker Pattern )
분리된 컴포넌트들로 이루어진 분산 시스템에서 사용 ( 원격 서비스 실행 )
◼ 모델-뷰-컨트롤러 ( MVC ; Model View Controller ) 패턴
모델( Model ) , 뷰( View ) , 컨트롤러( Controller ) 3개의 서브 시스템으로 구조화
- 모델 ( Model ) : 핵심 기능과 데이터 보관 ( ≋ DB )
- 뷰 ( View ) : 사용자에게 정보 표시 ( ≋ Frontend )
- 컨트롤러 ( Controller ) : 사용자의 요청을 입력받아 처리 ( ≋ Backend )
🔷 디자인 패턴 ( Design Pattern ) 🔔
SW 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
효율성 & 유지보수성 & 운용성이 높아지며 최적화에 도움이 된다.
◼ 유형 ⭐
- 목적
- 생성 : 클래스 정의 및 객체 인스턴스 생성
- 구조 : 더 큰 구조 형성을 목적으로 클래스나 객체의 조합을 다룸
- 행위 : 클래스나 객체의 상호작용 및 역할 분담을 다룸 - 범위
- 클래스 : 클래스 간 관련성, 컴파일 타임에 정적으로 결정
- 객체 : 객체 간 관련성, 런타임에 동적으로 결정
◼ 종류 ⭐
❐ 생성 패턴
- Builder : 복잡한 인스턴스를 조립하여 만드는 구조 ( 생성과 표기를 분리 )
- Prototype : 일반적인 원형을 만들어 놓고, 이를 복사하여 필요한 부분만 수정 ( 기존 객체 복제 → 객체 생성 )
- Factory Method : 상위 클래스에서 객체 생성 인터페이스 정의, 하위 클래스에서 인스턴스 생성
- Abstract Factory : 구체적인 클래스에 의존 X , 연관되거나 의존적인 객체들의 조합
- Singleton : 전역 변수를 사용 X , 객체를 하나만 생성 ( 한 클래스에 하나의 객체만 존재하도록 제한 )
❐ 구조 패턴
- Bridge : 기능 클래스 계층과 구현 클래스 계층을 연결
- Decorator : 기존에 구현되어 있는 클래스에 필요한 기능을 추가
- Facade : 복잡한 시스템에 대하여 단순한 인터페이스 제공
- Flyweight : 모두가 갖는 본질적 요소를 클래스와 하여 공유 ( 클래스의 경량화 )
- Proxy : 실제 객체에 대한 대리 객체
- Composite : 객체들의 관계를 트리 구조로 표현
- Adapter : 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할의 인터페이스
❐ 행위 패턴
- Mediator : 객체 수가 너무 많아지면 결합이 강해질 수 있기에, 중재자를 두는 방식 ( 상호작용의 유연한 변경 지원 )
- Interpreter : 언어의 다양한 해석, 구문을 나누고 이를 해석하는 클래스를 각각 작성 ( 문법 자체를 캡슐화 )
- Iterator : 내부구조를 노출하지 않고 집합체 안에 들어있는 모든 항목에 접근
- Template Method : 상위 작업 구조를 바꾸지 않으면서, 서브 클래스로 일부분 수행
- Observer : 한 객체의 상태가 바뀌면 이를 의존하는 다른 객체에게 연락
- State : 객체 상태를 캡슐화
- Visitor : 클래스에서 처리 기능을 분리하여, 메소드가 클래스를 돌아다니며 작업
- Command : 실행될 기능을 캡슐화
- Strategy : 알고리즘 군을 정의
- Memento : 객체를 이전 상태로 복구시켜야 하는 경우, 작업취소( Undo ) 가능
- Chain of Responsibility : 한 요청을 2개 이상의 객체에서 처리
🔷 운영체제 ( Operating System )
컴퓨터 시스템이 제공하는 모든 HW, SW를 사용할 수 있도록 해주며 사용자와 HW간의 인터페이스를 담당
◼ 운영체제 현행 시스템 분석
- 품질 측면
- 신뢰도
- 성능 - 지원 측면
- 기술 지원
- 주변 기기
- 구축 비용
◼ 종류
- PC
- 윈도즈 ( Windows )
- 유닉스 ( UNIX )
- 리눅스 ( Linux ) - 모바일
- 안드로이드 ( Android )
- iOS
🔷 네트워크 ( Network ) 🔔
컴퓨터 장치들의 노드 간 연결( 데이터 링크 )을 사용하여 서로에게 데이터를 교환할 수 있도록 하는 기술
데이터 링크들은 유선 매체( 광케이블 ) 또는 무선 매체( Wi-Fi )를 통해 확립한다.
◼ OSI 7계층 ( Layer ) ⭐
네트워크 통신에서 생긴 여러 가지 문제를 완화하기 위해 국제 표준화 기구( ISO ; International Standardization Organization)에서 제시한 네트워크 기본 모델
❐ 응용 계층 ( Application )
- 사용자와 네트워크 간 응용 서비스 연결, 데이터 생성
- 프로토콜 : HTTP , FTP
- 전송단위 : 데이터 ( Data )
❐ 표현 계층 ( Presentation )
- 데이터 형식 설정과 부호 교환, 암/복호화
- 프로토콜 : JPEG , MPEG
- 전송단위 : 데이터 ( Data )
❐ 세션 계층 ( Session )
- 연결 접속 및 동기 제어
- 프로토콜 : SSH , TLS
- 전송단위 : 데이터 ( Data )
❐ 전송 계층 ( Transport )
- 신뢰성 있는 통신 보장
- 프로토콜 : TCP , UDP
- 전송단위 : 세그먼트 ( Segment )
❐ 네트워크 계층 ( Network )
- 단말 간 데이터 전송을 위한 경로 제어
- 프로토콜 : IP , ICMP
- 전송단위 : 패킷 ( Packet )
❐ 데이터 링크 계층 ( Data Link )
- 인접 시스템 간 데이터 전송
- 프로토콜 : ETHERNET
- 전송단위 : 프레임 ( Frame )
❐ 물리 계층 ( Physical )
- 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환
- 프로토콜 : RS-232C
- 전송단위 : 비트 ( Bit )
🔷 DBMS ( Database Management System )
데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램
◼ 기능
- 중복 제어
- 접근 통제
- 인터페이스 제공
- 관계 표현
- 샤딩 / 파티셔닝
- 무결성 제약조건
- 백업 및 회복
◼ DBMS 현행 시스템 분석
- 성능 측면
- 가용성
- 성능
- 상호 호환성 - 지원 측면
- 기술 지원
- 구축 비용
🔷 미들웨어 ( Middleware )
분산 컴퓨팅 환경에서 응용 프로그램 ↔ 환경(시스템) 간에 원만한 통신이 이루어질 수 있도록 제어해주는 SW
대표적인 미들웨어로는 WAS ( Web Application Server ) 가 있다.
◼ 웹 애플리케이션 서버 ( WAS ; Web Application Server ) ⭐
서버 계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고, 안정적인 트랜잭션 처리와 관리, 이기종 시스템과의 애플리케이션 연동을 지원하는 서버
◼ 미들웨어 현행 시스템 분석
- 성능 측면
- 가용성
- 성능 - 지원 측면
- 기술 지원
- 구축 비용
3. 요구사항 확인
🔷 요구공학 ( Requirements Engineering )
사용자의 요구가 반영된 시스템을 개발하기 위해 요구사항에 대한 도출, 분석, 명세, 확인 및 검증을 하는 활동
◼ 분류
❐ 기능적 요구사항
시스템이 제공하는 기능, 서비스에 대한 요구사항
❐ 비기능적 요구사항
기능 이외의 사항, 시스템 구축에 대한 제약사항에 대한 요구사항
◼ 요구공학 프로세스
요구공학 프로세스는 요구사항 개발 단계와 요구사항 관리 단계로 구성된다.
❐ 요구사항 개발 단계 구성 ( CMM Level 3 프로세스 영역 )
① 도출
- 인터뷰
- 브레인스토밍
- 델파이 기법
- 롤 플레잉
- 워크숍
- 설문 조사
② 분석
- 청취 / 인터뷰 & 질문 / 분석 / 중재 / 관찰 / 작성 / 조직 / 모델 작성
③ 명세
- 산출물 : 요구사항 명세서
- 비정형 명세 기법 ( 자연어 기반으로 서술 )
- 정형 명세 기법 ( 수학적 원리와 표기법으로 서술 )
④ 확인 및 검증
- 요구사항 검토
- 정형 기술 검토 활용 ⭐
- 동료 검토 ( Peer Review ) : 명세서 작성자가 설명, 이해 관계자들이 설명을 들으며 진행 (2~3명)
- 워크 스루 ( Walk Through ) : 검토 자료를 회의 전에 배포하여 사전 검토 후 짧은 시간 동안 회의
- 인스펙션 ( Inspection ) : 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 검사 - 프로토타이핑 활용
- 모델 검증
- 테스트케이스 및 테스트를 통한 확인
- CASE 도구 활용 검증
- 베이스라인을 통한 검증
- 요구사항 추적표( RTM )를 통한 검증
❐ 요구사항 관리 단계 구성 ( CMM Level 2 프로세스 영역 )
- 산출물
- 요구사항 변경 요청서
- 요구사항 변경 승인서
- 요구사항 추적표 - 절차
① 요구사항 협상
② 요구사항 기준성 설정
③ 요구사항 변경관리
④ 요구사항 확인 및 검증
