1. 소프트웨어 공학의 개념
(1) 소프트웨어
1️⃣ 소프트웨어의 특징
상품성 : 판매를 통해 수익을 올릴 수 있어야 한다.
복잡성 : 개발 과정이 복잡하고 관리가 어려움
변경 가능성 : 업데이트나 오류 수정을 위해 언제든 변경될 수 있다
복제성 : 한 번 만들면 여러 사용자에게 쉽게 복제·배포할 수 있다.
2️⃣ 시스템의 기본요소 : 입력 - 처리 - 출력 - 제어 - 피드백
3️⃣ 소프트웨어 위기의 원인
소프트웨어가 복잡해짐에 따라 많은 인력이 많이 필요해지고 개발 기간이 지연됨
또한 개발 인력도 부족해졌기에 인건비가 상승됨
➡️ 하드웨어 비용을 초과하는 개발 비용의 증가
성능 및 신뢰성이 부족하고,
유지 보수의 어려움에 따른 엄청난 비용이 발생
(2) 소프트웨어 공학
1️⃣ 소프트웨어 공학의 이해
: 적은 돈으로 빠르고 쉽게 소프트웨어를 개발하기 위한 연구
경제적으로 신뢰도 높은 소프트웨어를 만들기 위한 방법, 도구와 절차들의 체계로,
IEEE(전기/전자기술협회)는 소프트웨어의 개발, 운용, 유지보수 및 파기에 대한
체계적인 접근 방법이라 정의
2️⃣ 소프트웨어 공학의 기본 원칙
현대적인 프로그래밍 기술을 적용
신뢰성이 높아야 함
사용의 편리성과 유지보수성이 높아야 함
지속적인 검증 시행을 해야함
[관련 기출 문제]
2. 재공학
(1) 재공학과 역공학
1️⃣ 재공학의 정의
소프트웨어 개발시 많은 비용이 들어가는 만큼
기존의 소프트웨어를 재사용하여 비용을 절감하려하는 것
2️⃣ 재공학의 장점, 목표, 과정
재공학의 장점
개발 시간 및 비용 감소, 품질 향상, 생산성 향상, 신뢰성 향상, 구축 방법에 대한 지식의 공유, 프로젝트 실패 위험 감소
재공학의 목표
소프트웨어의 유지보수성 향상이 최우선 목표
복잡한 시스템을 다루는 방법 구현, 다른 뷰의 생성, 잃어버린 정보의 복구 및 제거
재사용을 수월하게 하며, 소프트웨어의 수명을 연장하기 위함
기존 시스템을 분석, 개선하는 재공학은
문제가 발생하기 전에 구조를 개선한다는 점에서 예방적 성격을 띤다.
따라서 예방 유지보수(Preventive Maintenance)와 연관이 깊다
재공학의 과정
분석 - 구성 - 역공학 - 이식
3️⃣ 역공학의 개념
기존의 소프트웨어를 다시 분석하는 것
핵심은 문서화
(2) CASE (Computer Aided Software Engineering)
1️⃣ CASE가 제공하는 기능
🔍 CASE의 개념 : 소프트웨어 엔지니어링을 도와주는 자동화 도구
❶ 개발을 신속 정확하게 가능 ➡️ 품질 향상
❷ 소프트웨어 생명주기의 전체 단계를 연결해주고 자동화 시켜주는 통합된 도구를 제공
❸ 소프트웨어 시트템의 문서화 및 명세화를 위한 그래픽 기능 제공
❹ 개발 단계의 표준화를 수행하며, 자료 흐름도 작성 기능 제공
❺ 모델 사이의 모순 검사 기능 제공 & 다양한 소프트웨어 개발 모형 지원
❻ 원천 기술 : 구조적 기법, 프로토 타이핑 기술, 정보 저장소 기술
2️⃣ CASE의 분류
❶ 상위(Upper) CASE : 요구분석 및 설계 단계 지원
❷ 하위(Lower) CASE : 실제 구현(코딩, 테스트, 문서화 과정) 지원
❸ 통합(Integrate) CASE : 소프트웨어 개발 주기 전체 과정 지원
3️⃣ 요구사항 분석을 위한 CASE 도구
📌 SADT(Structured Analysis and Disign Technique)
: SoftTech 사에서 개발한 구조적 분석 및 설계 도구로,
소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 사용되어왔다.
구조적 요구사항 분석을 위해 블록 다이어그램을 채택한 자동화 도구
[관련 기출 문제]
3. 소프트웨어 개발 방법론
(1) 소프트웨어 설계 방법론
1️⃣ 소프트웨어 생명주기
타당성 검토 - 개발 계획 - 요구사항 분석 - 설계 - 구현 - 테스트 - 운용 - 유지보수
2️⃣ 폭포수 모형
: 고전적 생명 주기 모형으로, 개발 단계가 순차적으로 실행, 소규모 개발에 적합
중간에 요구사항이 변경되는 등 이벤트가 발생하면 내용 적용이 불가
3️⃣ 나선형(spiral) 모형
: 반복적으로 작업을 수행하며, 중간에 위험 분석 과정이 존재
계획 수립 - 위험 분석 - 개발 및 검증 - 고객 평가
변경사항 존재
다시 계획 수립 - 위험 분석 - (프로토타입) 개발 및 검증 - 고객 평가
4️⃣ 하향식과 상향식 설계
소프트웨어 설계시
⬇️ 하향식 설계 : 제일 상위에 있는 main User Fucntion 을 먼저 만들고 곁가지를 만들어 가는것
⬆️ 상향식 설계 : 단순한 컴포넌트를 먼저 설계한 후 상위 수준의 컴포넌트를 설계
5️⃣ 프로토 타입 모형
: 실제 개발될 시스템의 견본품
폭포수 모형의 단점을 보완하기 위한 모형으로
고객에게 보여 주어 요구사항을 반영하기 쉽다.
작은 프로젝트에서는 프로토 타입을 개선하는 방향
큰 프로젝트에서는 만들고 폐기하고를 반복
6️⃣ HIPO (Hierarchy Input Process Output)
: 계층적 입력 처리 아웃풋으로, 하향식 소프트웨어 개발을 위한 문서화 도구이다. (hipo : 하마 - 하향)
| 구성요소 | 입력 - 처리 - 출력으로 구성되는 시스템 분석 및 설계와 시스템 문서화용 기법 |
| 가시적 도표 | Visual Table of Contents |
| 총제적 다이어그램 | Overview Diagram |
| 세부적 다이어그램 | Detail Diagram |
7️⃣ V-모델
: 폭포수 모형에서 시스템 검증과 테스트 작업을 강조한 모델
왼쪽의 요구사항 분석 - 기능 명세 분석 - 설계 - 개발 까지는 HIPO이며
이에 따라 테스트를 적용한 것을 v모델
(2) 애자일(Agile) 개발 방법론
1️⃣ 애자일 개발 방법론
: 소프트웨어 개발 시 목표하는대로 만드는 것
2️⃣ 애자일 개발 종류
| 익스트림 프로그래밍 (XP, eXtremeProgramming) |
| 스크럼 (SCRUM) |
| 린 (Lean) |
| DSDM (Dynamic System Development Method, 동적 시스템 개발 방법론) |
| FDD (Feature Driven Development, 기능 중심 개발) |
| Crystal, ASD, DAD |
3️⃣ Agile 선언문
고객과 의사소통을 통해 고객이 원하는 것 만들어주기
[관련 기출 문제]
(3) XP (eXtremeProgramming)
1️⃣ 핵심 가치
❶ 소통 : 애자일은 기본적으로 소통을 함
❷ 단순성 : 부가 기능 등을 제외하여 단순하게 할 것
❸ Feedback : 고객과의 소통이 필요하므로 피드백 필요
❹ 용기 : 고객의 요구사항 변화에 능동적으로 대응
❺ 존중 : 개발 팀원 간의 상호 존중 필요
2️⃣ XP 절차
| Spike | 작게 만들어낸 요구사항을 확인하는 간단한 프로그램 |
| User story | 사용자가 어떻게 사용하는지에 대한 절차 |
| Release planning | 일부 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공 |
| Iteration(반복) | 하나의 릴리즈를 세분화한 단위, 새로운 요구사항이 반복 시 들어가게 됨 |
| Acceptance Test (적응 테스트) |
릴리즈 단위의 개발이 구현되었을 때 진행하는 테스트로, 고객이 직접 테스트 테스트 완료 후 다음 반복을 진행 |
| Small Release | 릴리즈 단위를 기능별로 세분화 |
3️⃣ XP 12 가지 실천 사항
| 구분 | 12 실천 사항 | 설명 |
| Fine Scale Feedback |
Pair Programming (짝 프로그래밍) | 한 사람 개발 - 한 사람 테스트 |
| Planning Game | 게임처럼 선수와 규칙, 목표를 두고 기획에 임한다 | |
| Test Driven Development (TDD, 테스트 주도 개발) | 단위 테스트부터 작성한 후 개발에 진행 | |
| Whole Team | 고객을 프로젝트 팀원으로 간주 | |
| Continuous Process |
Continuous Integration (CI, 지속적 통합) | 상시 빌드 및 배포를 할 수 있는 상태로 유지 |
| Design Improvement | 기능 변경 없이 재구성을 수행 | |
| Small Releases | 짧은 주기로 잦은 릴리즈를 하여 고객이 변경사항 볼 수 있다 | |
| Shared Understanding |
Coding Standards | 스탠다드 코딩 기법에 맞춰 코딩 |
| Collective Code Ownership | 코드는 모든 개발자가 수정 가능 | |
| Simple Design | 간결한 디자인 상태 유지 | |
| System Metaphor | 최종적으로 개발할 시스템의 구조를 기술 | |
| Programmer welfare |
Sustainable Pace | 일주일 간 40시간 이상 작업 금지, 2주 연속 오버타임 금지 |
4️⃣ 효과적인 프로젝트 관리를 위한 3대 요소 (3P)
❶ 사람 (People) : 인적 자원
❷ 문제 (Problem) : 문제 인식
❸ 프로세스 (Process) : 작업 계획
[관련 기출 문제]
4. SCRUM
(1) SCRUM
1️⃣ SCRUM팀의 역할
| 담당자 | 역할 |
| 제품 책임자 |
❶ 개발 목표에 이해가 높은 개발 의뢰자, 사용자가 담당 ❷ 요구사항을 파악하여 기능 목록 작성 ❸ 제품 테스트 수행 및 요구사항 우선순위 갱신 ❹ 업무 관점에서 우선순위와 중요도를 표시하고 신규 항목 추가 ❺ 스프린트 계획 수립까지만 임무를 수행 ❻ 스프린트 시작시 팀 운영에 관여 x |
| 스크럼 마스터 | ❶ 업무를 배분만 하고 강요 x ❷ 개발 과정 장애 요소를 찾고 제거 ❸ 개발 과정에서 스크럼 원칙과 가치를 지키도록 지원 |
| 스크럼 팀 | ❶ 5~9명의 팀원 (개발자, 디자이너 등) ❷ 기능을 작업 단위로 분류 ❸ 요구사항을 사용자 스토리로 도출, 구현 ❹ 일정, 속도를 추정한 뒤 제품 책임자에게 전달 ❺ 스프린트 결과물을 제품 책임자에게 시연 ❻ 매일 스크럼 화의에 참여하여 진행 상황 점검 |
💡 Product Back Log
SCRUM 작업 흐름도에서 제픔 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
(2) SCURM 과정
sprint : 개발 업무를 단기간에 진행 하는 것으로 2-4 주 정도 진행
소멸 차트 : 해야할 것 소거해가면서 진행
매일 약속된 시간에 짧은 시간 동안 서서 진행 상황 점검
[관련 기출 문제]
5. 현행 시스템 분석
(1) 현행 시스템 분석
1️⃣ 현행 시스템 파악 절차
1단계 : 시스템 구성 파악(조직, 업무 등) - 시스템 기능 파악 - 시스템 인터페이스 현황 파악
➡️ 현재 시스템이 어떻게 운영 되고 있는지
2단계 : 아키텍처 파악 - 소프트웨어 구성 파악
3단계 : 시스템 하드웨어 현황 파악 - 네트워크 구성 파악
2️⃣ 시스템 아키텍처
: 상위 & 하위 시스템이 어떤 관계로 상호작용하는지, 동작 원리와 구성을 표현한 것
❶ 단위 업무 시스템별로 아키텍처가 다른 경우, 핵심 기간 업무 처리 시스템을 기준
❷ 시스템의 전체 구조, 행위, 행위의 원리를 나타내고 - 어떻게 작동하는지 설명하는 틀
❸시스템에 구성된 컴포넌트를 식별하고 컴포넌트의 상호작용을 통해 어떻게 정보가 교환되는지 설명
(2) 시스템 및 인터페이스 현황 파악
1️⃣ 시스템 구성 파악
: 조직 내 주요 업무를 기간 업무 & 지원 업무로 구분하여 기술
모든 단위 업무를 파악할 수 있도록 하며, 시스템 내의 명칭, 기능 등 주요 기능을 명시
2️⃣ 시스템 기능 파악
: 단위 업무 시스템이 현재 제공하고 있는 기능을 주요 기능과 하부 기능으로 구분하여
계층형으로 표시
3️⃣ 인터페이스 현황 파악
현행 시스템의 단위 업무 시스팀이 타 단위 업무 시스템과 어떻게 연결되어 있는지
❶ 데이터 연계 유형 : EAI, FEP
❷ 데이터 형식 : XML, 고정 Format, 가변 Format
❸ 통신 규약 : TCP/IP, X.25
4️⃣ EAI (Enterprise Application Integration, 기업 애플리케이션 통합)
: 기업 내 컴퓨터 어플리케이션을 현대화하고 통합하여 조정하는 것을 목표로 세운 후
이를 실행할 계획, 방법 및 도구를 의미
5️⃣ FEP(Front-End Processor, 전위 처리기)
: 입력 데이터를 프로세스가 처리하기 전에 미리 처리하여 (전처리)
프로세서가 처리하는 시간을 줄여주는 프로그램이나 하드웨어
(3) 소프트웨어, 하드웨어, 네트워크 현황 파악
1️⃣ 소프트웨어 & 하드웨어 구성 파악
: 시스템 내의 단위 업무 시스템의 업무 처리용 소프트웨어의 품명, 용도, 라이선스 등을 명시
시스템 구축 시 많은 예산 비중을 차지하므로, 라이선스 적용 방식과 보유한 라이선스 수량 파악이 중요
2️⃣ 하드웨어 구성 파악
: 컴퓨터의 성능등을 파악
서버의 이중화 : 장애 시 서비스를 계속 유지하기 위한 운영 방식
[관련 기출 문제]
(4) 플랫폼
: 응용 소프트웨어 + (하드웨어 + 시스템 소프트웨어)
다양한 어플리케이션이 작동되는 운영 ㅊ제 소프트웨어 (기반 시설)
1️⃣ 플랫폼 성능 특성 분석
: 현행 시스템 사용자가 요구 사항을 통해 시스템 성능상 문제를 요구할 경우
플랫폼 성능 분석을 통해 사용자가 느끼는 속도를 파악하고 개선방향을 제시해야 함
특성 분석 항목 : 응답 시간 (Response Time), 가용성 (Availability), 사용률(Utilization)
플랫폼 성능 특성 분석 방법 : 기능 테스트, 사용자 인터뷰, 문서 점검
(5) 현행 시스템의 OS 분석
1️⃣ 현행 시스템의 OS 분석 항목 및 고려사항
분석 항목 : 시스템의 OS 종류와 버전, 패치 일자, 백업 주기 분석
고려사항 : 가용성, 성능, 기술 지원, 주변기기, 구축비용 (TCO, Total Cost of Ownership)
메모리 누수 여부 : 실행 SW가 정상 종료 되지 않고 남아 있는 증상
🤔 TCO란? (Total Cost of Ownership)
일정 기간 자산 획득에 필요한 직/간접적인 총비용으로
HW, SW 구매비용, 운영 교육, 기술 지원, 유지보수 손실, 에너지 사용 비용
2️⃣ 오픈소스 라이선스 종류
: 소스코드가 공개되어 누구나 제한 없이 소스를 사용하는 것
| GNU(GNU's Not Unix) | 정보를 돈 주고 구매하는것을 반대하는 이념 예) Linux |
| GNU GPLv1(General Public License) | 소스코드는 공개 하지 않고, 바이너리만(실행하는것만) 배포하는 것을 금지 |
| BSD(Berkeley Software Distribution) | 아무나 개작 할 수 있고 수정본을 제한 없이 배포 가능, 수정본의 재배포는 의무사항 아님 |
| Apache 2.0 | Apache 재단 소유의 SW 적용을 위해 제공하는 라이선스로, 소스 코드 수정 배포시 Apache 2.0을 포함해야 함 예) Android, HADOOP |
(6) 현행 시스템 DBMS 분석
1️⃣ DBMS (DataBase Management System)
: 데이터베이스 관리 시스템
❶ 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템
❷ 응용 프로그램이 데이터베이스를 공유할 수 있도록 관리
❸ DB의 구성, 접근고 방법, 관리 유지에 대한 책임을 가짐
종류 : Oracle, IBM, DB2, MySQL, SQ Lite, MongoDB, Redis 등
2️⃣ 현행 DBMS 분석시 고려사항
❶ 가용성
❷ 성능
❸ 기술 지원
❹ 상호 호환성
❺ 구축 비용
[관련 기출 문제]
[참고 영상]
[정보처리기사 필기 절대족보] 핵심이론 1과목-1(소프트웨어 설계)