다양한 교재로 내용 익히는 거 괜찮은 듯 🥪
Software 소프트웨어
상품성, 복잡성, 변경 가능성, 복제성
System 시스템
기본요소 : 입력 처리 출력 제어 피드백
Software Crisis
소프트웨어 위기
- 개발비용 증가
- 개발 기간 지연
- 개발 인력 부족 인건비 상승
- 성능 및 신뢰성 부족
- 유지보수의 어려움과 유지보수의 엄청 큰 비용
Software Engineering 소프트웨어 공학
- 현대적인 프로그래밍 기술
- 신뢰성 높아야
- 사용 편리성, 유지보수성 높아야
- 지속적인 검증 시행
소프트웨어 공학 기본원칙
- 품질 높은 Software 상품 개발
- 지속적인 검증 시행
- 결과에 대한 명확한 기록 유지
Software Reengineering 소프트웨어 재공학
- Software 위기를 개발의 생산성이 아닌 유지보수의 생산성으로 해결하려는 방법
- 현재 시스템 변경하거나 재구조화 Restructuring
- 재구조화는 재공학의 한 유형으로 사용자의 요구사항이나 기술적 설계의 변경 없이 프로그램을 개선하는 것
- 솦웨어 재공학 관점에서 가장 연관 깊은 유지보수 유형은 예방 유지보수Preventive Maintenance
개발 시간 비용 감소, 품질 향상, 생산성 향상, 신뢰성 향상, 구축 방법 지식 공유, 프로젝트 실패 위험 감소
분석Analysis → 구성Restructuring → 역공학Reverse Engineering → 이식Migration
Reverse Engineering 역공학
SW 분석, 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를
재발견하거나 다시 만들어내는 작업 과정
역공학의 가장 간단하고 오래된 형태는 재문서화
CASE Computer Aided Software Engineering
SW 개발 과정에서 사용되는 요구분석, 설계, 구현, 검사 및 디버깅 과정을 컴퓨터와 전용 SW 도구를 사용하여 자동화 하는 작업
자료 흐름도 등의 다이어그램을 쉽게 작성하게 해주는 SW CASE 도구
작업 과정 및 데이터 공유를 통해 작업자 간 커뮤니케이션 증대
CASE 제공 기능
개발 신속, 오류 수정 쉬움, SW 품질 향상
SW 생명주기의 전체 단계를 연결해주고 자동화시켜 주는 통합 도구 제공
SW 시스템의 문서화 및 명세화를 위한 그래픽 기능
SW 개발 단계의 표준화를 기할 수 있음
자료흐름도 작성 기능 있음
모델들 사이의 모순 검사 기능
다양한 SW 개발 모형 지원
원천 기술 : 구조적 기법, 프로토타이핑 기술, 정보 저장소 기술
CASE 장점
기간 단축 / 비용 절약 / 생산성 향상
자동화 검사 SW 품질 향상
유지보수 간편
SW 모듈 재사용성 향상
개발주기 표준안 확립
개발 기법 실용화
문서화 용이성 제공
시스템 수정 및 유지보수 축소 등등
CASE 분류
상위: Upper CASE : 요구분석, 설계 단계 지원 (모델 간 모순 검사, 모델 오류 검증, 자료 흐름도 작성 기능들)
하위: Lower CASE : 실제 구현, 소스 코드 작성, 테스트, 문서화 과정 지원
통합: Integrate CASE : 솦트웨어 개발 주기 전체 과정 지원
CASE 분석 및 설계 도구들 프로그램명들
SADT Structured Analysis and Design Technique
REM Software Requirements Engineering Methodology = RSL/REVS
PSL/PSA
TAGS Technology for Automated Generation of Systems
Software Life Cycle 소프트웨어 생명주기
SW 제품의 개념 형성에서 운용 유지보수에 이르기까지의 변화의 모든 과정
타당성 검토 → 개발 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 운용 → 유지보수
폭포수 모형 Waterfall Model 고전, 소규모 적합
고전적 생명주기 모형으로 선형 순차적 모델이라고도 하며, 타당성 검토, 계획, 요구사항 분석, 구현, 테스트, 유지보수의 단계를 통해 SW를 개발하는 모형
나선형 모형 Spiral Model 프로토타입(시제품)을 지속적으로 발전시켜 최종 SW 개발까지 이르는 개발 방법으로 위험관리가 중심인 SW 생명주기 모형, (평가 검증 후 실제 개발)
하향식 설계 : 제일 상위에 있는 Main User Function 에서 시작하여 기능을 하위 기능들로 나눠가면서 설계
상향식 설계 : 기본 컴포넌트를 먼저 설계해서 이것을 사용하는 상위 컴포넌트를 설계
Prototype Model
프로토타입 모형
견본을 미리 만들어 최종 결과물을 예측하는 모형
폭포수 모형 단점 보완하기 위해 만든 모형임
고객과의 커뮤니케이션을 충실하게 해야 할 때 좋음
요구사항들을 보다 충실하게 반영할 수 있다
HIPO Hierarchy Input Process Output
입력, 처리, 출력으로 구성되는 시스템 분석 및 설계와 시스템 문서화용 기법
일반적으로 가시적 도표 Visual Table of Contents, 총체적 다이어그램 Overview Diagram, 세부적 다이어그램 Detail Diagram으로 구성됨
하향식 SW 개발을 위한 문서화 도구
V-Model
폭포수 모형에 시스템 검증과 테스트 작업을 강조한 모델 (히포에다가 테스트 추가)
세부적인 프로세스, 신뢰도 높은 시스템 개발에 효과적
개발 단계 작업 확인을 위한 테스트 작업 수행
생명주기 초반부터 테스트 작업 지원
코드뿐만 아니라 요구사항, 설계 결과도 테스트 할 수 있어야 함
폭포수보다 반복과 재처리 과정이 명확함
테스트 작업을 단계별로 구분하므로 책임 명확해짐
Agile 개발 방법론
특정 방법론 아님. 계획 중점 아님
SW를 빠르고 낭비없이 제작하기 위해
고객과의 협업에 초점을 두고 SW 개발 중
설계 변경에 신속히 대응하여 요구사항을 수용할 수 있다.
절차와 도구보다 개인과 소통을 중요시 고객과의 피드백을 중요하게 생각함
SW가 잘 실행되는데 가치를 두며, SW 배포 시차를 최소화할 수 있다.
- 특징 : 짧은 릴리즈와 반복, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적인 커뮤니케이션 변화
- 종류 : XP eXtremeProgramming 익스트림프로그래밍, SCRUM 스크럼, Lean 린, DSDM Dynamic System Development Method 동적 시스템 개발 방법론, FDD Feature Driven Development 기능 주도 개발, Crystal, ASD Adaptive Software Development 적응형 SW 개발 방법론, DAD Disciplined Agile Delivery 학습 애자일 배포
XP 핵심가치 : 용기 / 의사소통 / 피드백 / 단순성 / 존중
Communication 의사소통 : 개발자, 관리자, 고객 간의 원활한 소통 지향
Simplicity 단순성 : 부가적 기능 또는 미사용 구조 알고리즘 배제
Feedback 피드백 : SW 개발에서 변화는 불가피. 지속적 테스트와 통합, 반복적 결함 수정 등 빠르게 피드백 지속
Courage 용기 : 고객 요구사항 변화에 능동적으로 대응
Respect 존중 : 개발 팀원 간의 상호 존중을 기본으로 한다
XP Process
User Story : 일종의 요구사항. UML의 유즈케이스와 같은 목적으로 생성되나 형식이 없고 고객에 의해 작성된다는 것이 다르다
Release Planning : 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것으로 부분/전체 개발 완료 시점에 대한 일정을 수립한다.
Iteration : 하나의 릴리즈를 세분화한 단위이며 1~3주 단위로 진행된다. 반복(Iteration) 진행 중 새로운 스토리가 추가될 때 진행중 반복이나 다음 반복에 추가될 수 있다.
Acceptance Test : 릴리즈 단위의 개발이 구현되었을 때 진행하는 테스트로 사용자 스토리에 작성된 요구사항을 확인하여 고객이 직접 테스트한다. 오류가 발견되면 다음 반복에 추가한다. 테스트 후 고객의 요구사항이 변경되거나 추가되면 중요도에 따라 우선순위가 변경될 수 있다. 완료 후 다음 반복(iteration)을 진행한다.
Small Release : 릴리즈 단위를 기능별로 세분화하면 고객의 반응을 기능별로 확인할 수 있다. 최종 완제품일 때 고객에 의한 최종 테스트 진행 후 고객에 제공한다.
XP 12가지 실천사항 Practice
Fine Scale Feedback
1. Pair Programming
: 두 사람이 짝이 되어 한 사람은 코딩을 다른 사람은 검사를 수행하는 방식
코드에 대한 책임을 공유하고 비형식적인 검토를 수행할 수 있다.
코드 개선을 위한 리팩토링을 장려하며 생산성이 떨어지지 않는다
2. Planning Game : 게임처럼 선수와 규칙, 목표를 두고 기획에 임한다.
3. Test Driven Development : 실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드를 작성
4. Whole Team : 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킨다
Continuous Process
5. Continuous Integration : 상시 빌드 및 배포를 할 수 있는 상태로 유지
6. Design Improvement : 기능 변경 없이 중복성/ 복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성을 수행한다.
7. Small Releases : 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 한다.
Shared Understanding
8. Coding Standards : 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성한다.
9. Collective Code Ownership : 시스템에 있는 소스 코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정할 수 있다
10. Simple Design : 가능한 가장 간결한 디자인 상태를 유지한다
11. System Metaphor : 최종적으로 개발되어야 할 시스템의 구조를 기술한다.
Programmer Welfare
12. Sustainable Pace : 일주일에 40시간 이상 작업 금지. 2주 연속 오버타임 금지한다.
효과적인 프로젝트 관리를 위한 3대 요소
사람 People : 인적 자원
문제 Problem : 문제 인식
프로세스 Process : 작업 계획
SCRUM
소규모 팀원 간 활발한 소통, 협동심이 필요한 팀 중심의 SW 개발 방법론
신속하게 반복적으로 실제 작동하는 SW를 제공한다.
개발자들의 팀 구성과 각 구성원의 역할, 일정 결과물 및 그 외 규칙을 정하는 것을 말함
기능 개선점에 우선순위 부여, 개발주기 동안 실제 동작 가능한 결과를 제공한다.
개발 주기마다 적용된 기능이나 개선점 리스트 제공함
커뮤니케이션을 위해 개방된 공간에서 개발하고 매일 15분 정도 회의를 한다.
팀원 스스로 팀을 구성해야 한다 Self Organizing
개발 작업에 관한 모든 것을 팀원 스스로 해결해야 한다 Cross Functional
SCRUM 기본 원리
기능 협업 기준으로 배치된 팀은 스프린트 단위로 SW를 개발
스프린트는 고정된 30일의 반복이며, 스프린트를 행하는 작업은 고정됨
요구사항, 아키텍처, 설계가 프로젝트 전반에 걸쳐 잘 드러나야 한다.
정해진 시간을 철저히 지켜야 하며, 완료된 모든 작업은 제품 백로그에 기록된다.
가장 기본적인 정보교환 수단은 일일 스탠드업 미팅, 또는 일일 스크럼이다.
SCRUM 팀의 역할
제품 책임자 Product Owner
- 개발 목표에 대해 이해도가 높은 개발 의뢰자, 사용자가 담당
- 제품 요구사항을 파악하여 기능 목록 Product Backlog를 작성한다
- 제품 테스트 수행 및 요구사항 우선순위를 갱신한다
- 업무 관점에서 우선순위와 중요도를 표시하고 신규 항목을 추가한다.
- 스프린트 계획 수립까지만 임무 수행
- 스프린트가 시작되면 팀 운영에 관여하지 않는다
스크럼마스터
- 업무를 배분만 하고 일은 강요하지 않으며 팀을 스스로 조직하고 관리하도록 지원, 개발 과정 장애 요소를 찾아 제거한다.
- 개발 과정에서 스크럼의 원칙과 가치를 지키도록 지원한다.
스크럼팀
- 제품 책임자, 스크럼 마스터를 제외한 팀원(개발자, 디자이너, 제품검사기 등 모든 팀원)이 해당하고 팀원은 5~9명 내외로 구성한다.
- 기능을 작업 단위로 분류하며, 요구사항을 사용자 스토리로 도출, 구현한다.
- 일정, 속도를 추정한 뒤 제품 책임자에게 전달한다.
- 스프린트 결과물을 제품 책임자에게 시연한다.
- 매일 스크럼 회의에 참여하여 진행 상황을 점검한다.
SCRUM 과정, 작업흐름도
Product Backlog : SCRUM의 작업 흐름도에서 제품 개발에 필요한 모든 요구사항User Story을 우선순위에 따라 나열한 목록
작업목록을 만들어 두고 소멸차트를 만들어서 삭제해나간다.
Sprint 스프린트
- 사전적으로 전력 질주란 의미가 있다
- 작은 단위의 개발 업무를 단기간에 전력질주하여 개발한다는 의미
- 반복주기(2~4주) 마다 이해관계자에게 일의 진척도를 보고한다
현행 시스템 분석
현행 시스템 분석의 정의와 목적
현행 시스템이 어떤 하위 시스템으로 구성되어 있는지 파악하는 절차를 의미한다.
현행 시스템의 제공 기능과 타 시스템과의 정보 교환 분석을 파악한다.
현행 시스템의 기술 요소와 SW, HW를 파악한다.
목적 : 개발 시스템의 개발 범위를 확인하고 이행 방향성을 설정한다.
현행 시스템 파악 절차
1단계 (시스템 구성 파악 - 시스템 기능 파악 - 시스템 인터페이스 현황 파악)
2단계 (아키텍쳐 파악 - SW 구성 파악)
3단계 (시스템 HW 현황 파악 - 네트워크 구성 파악)
※ 여기서 시스템은 컴퓨터가 아니라 조직이나 업무 시스템을 말함
시스템 아키텍처
- 시스템 내의 상위 시스템과 하위 시스템들이 어떠한 관계로 상호작용하는지 각각의 동작 원리와 구성을 표현한 것이다.
- 단위 업무 시스템 별로 아키텍처가 다른 경우 핵심 기간 업무 처리 시스템을 기준으로 한다.
- 시스템의 전체 구조, 행위, 그리고 행위 원리를 나타내며 시스템이 어떻게 작동하는지 설명하는 틀이다.
- 시스템의 목적 달성을 위해 시스템에 구성된 각 컴포넌트를 식별하고 각 컴포넌트의 상호작용을 통하여 어떻게 정보가 교환되는지 설명함
시스템 아키텍처 ↔ SW 아키텍처 → SW 상세 설계
시스템 구성 파악
- 조직 내의 주요 업무를 기간 업무와 지원 업무로 구분하여 기술한다.
- 모든 단위 업무를 파악할 수 있도록 하며, 시스템 내의 명칭, 기능 등 주요 기능을 명시한다.
기간 업무 : 주요 업무
지원 업무 : 서포트
EAI Enterprise Application Intergration 기업 애플리케이션 통합
기업 내의 컴퓨터 애플리케이션들을 현대화하고, 통합하고, 조정하는 것을 목표로 세운 계획, 방법 및 도구 등을 의미한다
인터페이스 현황 파악
현행 시스템 분석 단계 중 현행 시스템의 단위 업무 시스템이 타 단위 업무 시스템과 서로 주고 받는 데이터의 연계 유형, 데이터 형식과 종류, 프로토콜 및 주기 등을 명시하는 단계
FEP Front-End Processor 전위 처리기
- 입력 데이터를 프로세서가 처리하기 전에 미리 처리하여
프로세서가 처리하는 시간을 줄여주는 프로그램이나 하드웨어이다.
- 여러 통신 라인을 중앙 컴퓨터에 연결하고
터미널의 메시지가 보낼 상태로 있는지 검색한다.
통신 라인의 에러를 검출한다.
데이터 파일의 영구 보전은 back-end 에서..
SW 구성 파악
시스템 내의 단위 업무 시스템의 업무 처리용 SW의 품명, 용도, 라이선스 적용 방식 (돈주고 샀나 업데이트는 언제 하나) , 라이선스 수를 명시한다.
시스템 구축 시 많은 예산 비중을 차지하므로 라이선스 적용 방식과 보유한 라이선스 수량 파악이 중요하다.
라이선스 적용 방식 단위 : 사이트, 서버, 프로세스, 코어, 사용자 수
HW 구성 파악
각 단위 업무 시스템의 서버 위치 및 주요 사양, 수량, 이중화 여부를 파악한다.
서버 사양 : CPU 처리 속도, 메모리 크기, 하드 디스크의 용량
서버 이중화 : 장애 시 서비스의 계속 유지를 위하여 운영
기간 업무의 장애 대응 정책에 따라 필요 여부가 달라진다.
현행 시스템에 이중화가 적용되어 있다면 대부분 목표 시스템도 이중화가 요구되므로 그에 따른 기술 난이도, 비용 증가 가능성 파악한다.
네트워크 구성 파악
현행 업무 처리 시스템의 네트워크 구성 형태를 그림으로 표현
장애 발생 시 추적 및 대응 등의 다양한 용도로 활용됨
서버의 위치, 서버 간 연결 방식 등을 파악함
물리적인 위치 관계, 조직 내 보안 취약성 분석 및 대응 방안을 파악함
개발 기술 환경 분석
개발 대상 시스템의 플랫폼, OS, DBMS, Middle Ware 등을 분석한다.
Platform 플랫폼
응용 SW + (HW + 시스템 SW)
다양한 애플리케이션이 작동하는 기본이 되는 운영체제 SW를 의미함
종류 : JAVA 플랫폼, .NET 플랫폼, IOS, Android, Windows
플랫폼 성능 특성 분석
현행 시스템의 사용자가/ 요구사항을 통하여/ 시스템 성능 상의 문제를 요구할 경우/ 플랫폼 성능 분석을 통하여/ 사용자가 느끼는 속도를 파악하고/ 개선 방향을 제시할 수 있다.
특성 분석 항목 : 응답시간 Response Time, 가용성 Availability, 사용률 Utilization
플랫폼 성능 특성 분석 방법
기능 테스트 Performance Test : 현재 시스템의 플랫폼을 평가할 수 있는 기능 테스트를 수행함
사용자 인터뷰 : 사용자를 대상으로 현행 플랫폼 기능의 불편함을 인터뷰함
문서 점검 : 플랫폼과 유사한 플랫폼의 기능 자료를 분석함
현행 시스템의 OS 분석
OS (Operating System 운영체제) 정의 및 기능
HW, SW 자원 관리 및 공통 서비스 제공, 사용자와의 인터페이스를 제공함
종류 : Windows, Android, iOS, UNIX, LINUX, Mac OS 등
현행 시스템의 OS 분석 항목 및 고려사항
분석 항목 : 현재 정보 시스템의 OS 종류와 버전, 패치 일자, 백업 주기 분석
고려 사항 : 가용성, 성능, 기술 지원, 주변 기기, 구축 비용(TCO Total Cost of Ownership 자산획득에 필요한 직간접총비용)
현행 환경 분석 과정에서 라이선스의 종류, 사용자 수, 기술의 지속 가능성 등을 고려해야 함
메모리 누수 : 실행 SW가 정상 종료되지 않고 남아 있는 증상
오픈소스 라이선스 종류
소스 코드가 공개되어 누구나 특별한 제한 없이 소스를 사용할 수 있으며 대표적으로 Linux가 있음
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(다수의 저렴한 컴퓨터를 하나처럼 묶어 대량 데이터를 처리하는 기술)
현행 시스템 DBMS 분석
DBMS DataBase Management System
- 종속성과 중복성의 문제를 해결하기 위해서 제안된 시스템이다.
- 응용 프로그램과 데이터의 중재자로서 .........
이어지는 내용은 아래 동영상에서 확인.
시험용 요약으로 좋았다.
https://youtu.be/JhKOsZuMDWs?si=X4pjzU7OWtFDbi0a
다양한 영상이나 책이나
글들 보면서 공부 중인데
이 방식이 비교적 잘 맞는 것 같다.
정처기 필요없다는 분들은
전공자들일 것 같다 ㅎㅎ
아직 한참 더 공부해야하지만,
생각보다 유용한 이야기가 많아서
의외로 즐겁게 공부하고 있다.
특히 소규모 회사 좀 다녀본 사람으로서
요구사항 개발 같은 내용 ㅋㅋㅋㅋㅋㅋ
너무 중요한데 이런 게 도식적으로나마 이론으로 정리되어 있는 걸 보니까 즐겁다
신기한 것들도 있고
애매하게 접했던 용어들도
개념이 좀더 명확해져서 좋다
brooks 법칙의 경우
지연되는 프로젝트에 인력 추가 투입 시 더 지연 ㅋㅋㅋㅋㅋㅋㅋㅋ
아; 듣기만 해도 너무 짜증나는데 웃김 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ