공부 블로그

ESLint란

• JavaScript 코드를 분석하여 문법 오류와 안티 패턴을 찾아내는 정적 분석 도구
• 검사 조건에 다양한 옵션 부여 가능

1. 설치

npm i eslint

2. 파일 설정

npx eslint --init

3. 룰 설정

// eslintrc.js

module.exports = {
    "env": { // 사전 정의된 전역변수 지정
        "es2021": true,
        "node": true
    },
    "extends": "eslint:recommended",
    "parserOptions": {
        "ecmaVersion": 13 // ecmaScript 버전
        "ecmaFeatures": { // 확장 기능 설정
      		"jsx": true
    	}
    },
    "rules": {
    	// rule example
    }
};

4. ESLint 체크

npx eslint <Your file name.js>

5. ESLint 룰을 사용하여 코드 수정

npx eslint --fix <your file name.js>

Rules

룰에는 3가지 종류가 있다

• OFF
• WARN
• ERROR

Example

세미콜론이 존재하는지 검사

module.exports = {
    "env": {
        "es2021": true,
        "node": true
    },
    "extends": "eslint:recommended",
    "parserOptions": {
        "ecmaVersion": 13
    },
    "rules": {
        "semi": ["error", "always"],
    }
};

React.js란

• 사용자 인터페이스를 만들기 위한 JavaScript 기반 라이브러리

특징

• Virtual DOM 사용
• 컴포넌트를 사용하여 상태를 관리(component-based)
• 다른 라이브러리나 프레임워크와 병행 사용 가능

단순 예시

ReactDOM.render(
  <h1>Hello, world!</h1>,
  document.getElementById('root')
);

설치 ~ 개발 환경 세팅

1. Node.js 설치

https://nodejs.org/ko/

cmd(명령 프롬프트)에서 node-v로 Node.js가 제대로 설치되었는지 확인

2. Visual Studio Code 설치

https://code.visualstudio.com/

3. React 설치

cmd에서 React 설치

npm install -g create-react-app

4. Create React App

 VS Code의 Terminal에서 새로운 React 프로젝트 생성

npx create-react-app [App Name]

5. npm start

해당 프로젝트가 있는 디렉토리에서 실행

npm start

6. 웹 브라우저의 http://localhost:3000/ 에서 확인

사용자 인터페이스(User Interface)

• 사용자-시스템 간의 상호작용이 원할하게 이루어지도록 돕는 장치 또는 소프트웨어
• 분야
  • 정보 제공과 전달을 위한 물리적 제어
  • 콘텐츠의 상세적인 표현과 전체적인 구성
  • 모든 사용자가 편리하고 간편하게 사용하도록 하는 기능
• 특징
  • 사용자의 만족도에 가장 큰 영향을 줌
  • 소프트웨어 영역 중 가장 많은 변경 발생
  • 최소한의 노력으로 원하는 결과를 얻게 해줌
  • 사용자 중심으로 설계
  • 수행 결과의 오류를 줄임
  • 막연한 작업 기능에 대한 구체적인 방법 제시
  • 정보 제공자-정보 공급자 간의 매개 역할
  • UI 설계를 위해서는 소프트웨어 아키텍처를 반드시 숙지
• 구분
  • CLI(Command Line Interface) - 명령과 출력이 텍스트 형태
  • GUI(Graphical User Interface) - 아이콘 또는 메뉴를 선택하여 작업을 수행하는 그래픽 환경
  • NUI(Natural User Interface) - 사용자의 말 또는 행동으로 조작
• 기본 원칙
  • 직관성 - 누구나 쉽게 이해하고 사용
  • 유효성 - 사용자의 목적을 정확하게 달성
  • 학습성 - 누구나 쉽게 배우고 익힘
  • 유연성 - 사용자의 요구사항을 최대한 수용 & 실수 최소화
• 설계 지침
  • 사용자 중심 - 사용자가 쉽게 이해하고 편리하게 사용할 수 있는 환경 제공
  • 일관성 - 조작 방법을 일관성 있게 제공하여 사용자가 쉽게 사용할 수 있도록 설계
  • 단순성 - 조작 방법을 단순화시켜 인지적 부담 감소
  • 결과 예측 가능 - 기능만 보고 결과를 예측 가능하도록 설계
  • 가시성 - 메인 화면에 주요 기능을 노출시켜 조작이 쉽도록 설계
  • 표준화 - 기능 구조와 디자인을 표준화하여 한 번 학습 이후에는 쉽게 사용 가능하도록 설계
  • 접근성 - 사용자의 성별, 연령에 상관없이 다양한 계층이 사용할 수 있도록 설계
  • 명확성 - 사용자가 개념적으로 쉽게 인지할 수 있도록 설계
  • 오류 발생 해결 - 오류 발생 시 사용자가 쉽게 인지할 수 있도록 설계
• 인터페이스 개발 시스템의 기능
  • 사용자의 입력 검증
  • 에러 처리와 에러 메시지
  • 도움과 프롬프트(Prompt) 제공

UI 표준 및 지침

• UI 표준
  • 전체 시스템에 포함된 모든 UI에 공통적으로 적용될 내용
  • 화면 구성, 화면 이동 등
• UI 지침
  • UI 개발 시 꼭 지켜야 할 공통의 조건
  • UI 요구사항, 구현 시 제약사항 등
• 웹의 3 요소
  1. 웹 표준 - 웹에서 사용되는 규칙 또는 기술 / 웹 페이지가 다른 기종이나 플랫폼에서 구현되도록 제작하는 기법 등
  2. 웹 접근성 - 누구나, 어떠한 환경에서도 사이트에서 제공하는 모든 정보를 접근하여 이용할 수 있도록 보장
  3. 웹 호환성 - 다른 환경에서도 모든 이용자에게 동등한 서비스 제공
• 한국형 웹 콘텐츠 접근성 지침(KWCAG; Korean Web Content Accessibility Guidelines)
  • 사이트 저작자, 사이트 설계자 등이 접근성이 보장된 웹 콘텐츠를 쉽게 제작할 수 있도록 도움을 줌
  
• 네비게이션(Navigation)
  • 원하는 정보를 쉽게 찾을 수 있도록 다양한 경로나 방법 제공
  • 요소
    • 메뉴 - 계층 구조를 표현하는 기본 요소
    • 링크 - 하이퍼링크
    • 이미지 맵 - 그림에 하이퍼링크 연결
    • 사이트 맵 - 사이트의 전체 구조를 한 눈에 알아볼 수 있는 트리 구조
    • 사이트 메뉴바 - 사이트의 좌측이나 우측에 있는 메뉴, 링크 모음
    • 내비게이션 바 - 메뉴를 한 곳에 모아 놓은 그래픽 또는 문자열
    • 디렉터리 - 항목을 카테고리별로 표현
• 전자정부 웹 표준 준수 지침
  • 정부기관의 홈페이지 구축 시 반영해야 할 최소한의 규약
  

UI 설계 도구

• 사용자의 요구사항에 맞게 UI의 화면 구조 또는 화면 배치 등을 설계할 때 사용
• 작성된 결과물은 요구사항이 실제 구현되었을 때 어떻게 화면이 구성되는지, 어떤 방식으로 수행되는 지 등을 기획단계에서 미리 보여주기 위한 용도로 사용
• 와이어프레임, 목업, 스토리보드, 프로토타입, 유스케이스 등
  1. 와이어프레임(Wireframe) - 손 그림, 파워포인트, 스케치, 포토샵 등
     • 기획 단계의 초기에 제작
     • 개략적인 레이아웃이나 UI 요소에 대한 뼈대 설계
     • 레이아웃을 협의하거나 현재 진행 상태 등을 공유하기 위해 사용
  2. 목업(Mockup) - 파워 목업, 발사믹 목업 등
     • 와이어프레임보다 더 실제 화면과 유사하게 만든 정적인 형태의 모형
     • 시각적으로만 구성 요소 배치 → 실제로 구현되지는 않음
  3. 스토리보드(Story Board) - 파워포인트, 키노트, 스케치, Axure 등
     • 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름을 추가
     • 최종적으로 참고하는 작업 지침서
     • 좌측에는 UI 화면, 우측에는 디스크립션 기입
     • 디스크립션은 명확하고 세부적으로 작성
  4. 프로토타입(Prototype) - HTML/CSS, Axure, 프로토나우 등
     • 와이어프레임이나 스토리보드에 인터랙션(상호작용)을 적용한 동적인 형태의 모형
     • 사용성 테스트나 작업자 간 서비스 이해를 위해 작성
     • 페이퍼 프로토타입, 디지털 프로토타입으로 나눠짐
  5. 유스케이스(Use Case)
     • 사용자 측면에서의 요구사항
     • 사용자의 요구사항을 빠르게 파악하여 시스템의 기능적인 요구를 결정하고 결과를 문서화
     • 자연어로 작성된 사용자의 요구사항을 구조적으로 표현하여 다이어그램으로 묘사
     • 각각의 유스케이스에 대해 유스케이스 명세서 작성

UI 요구사항 확인

• 새로 개발할 시스템에 적용할 UI 관련 요구사항을 다양한 경로로 조사해서 작성하는 단계
• 목표 정의 → 활동 사항 정의 → UI 요구사항 작성 순으로 진행
  1. 목표 정의
     • 사용자들을 대상으로 인터뷰를 진행하여 의견이 수렴된 비즈니스 요구사항 정의
     • 인터뷰 진행 시 가능하면 개별적으로 1시간을 넘지 않도록 진행하고 다양한 사람의 의견을 수렴하되, 개인의 의견도 빠트리지 않도록 주의한다
     • 인터뷰 진행은 반드시 사용자 리서치를 시작하기 전에 해야 한다
  2. 활동 사항 정의
     • 조사한 요구사항을 토대로 앞으로의 활동 사항을 정의
     • 각각 필요한 예산과 일정을 결정
     • UI 디자인의 방향 제시
     • 우선순위 선정, 책임자 선정, 개별적인 단위 업무를 구분한다
  3. UI 요구사항 작성
     • 실사용자 중심으로 작성
     • UI 요구사항을 바탕으로 UI의 전체적인 구조를 파악 및 검토
     • 요구사항 요소 확인 → 정황 시나리오 작성 → 요구사항 작성 순으로 진행
       • 요구사항 요소 확인
         1. 데이터 요구
            • 사용자가 요구하는 모델과 객체의 주요 특성을 기반으로 데이터 객체 정리
            • 반드시 초기에 확인
         2. 기능 요구
            • 사용자의 목적 달성을 위해 무엇을 실행해야 하는 동사형으로 설명
            • 최대한 철저하게 정리
         3. 제품/서비스의 품질
         4. 제약 사항
            • 데드라인, 필요한 비용, 시스템 준수에 필요한 규제 등
            • 사전에 제약사항 변경 가능 여부 확인
       • 정황 시나리오 작성
         • 사용자의 요구사항을 도출하기 위해 작성
         • 목표 달성을 위해 수행하는 방법을 순차적으로 묘사
         • 사용자 관점에서 간결하고 명확하게 시나리오 작성
         • 주로 사용하는 기능 위주로 작성하되, 함께 발생되는 기능은 하나의 시나리오에 통합
       • 요구사항 작성
         • 정황 시나리오를 토대로 작성

품질 요구사항

• 소프트웨어의 품질은 기능, 성능, 만족도 등 요구사항을 충족시킴으로써 확립
• ISO/IEC 9126
  • 소프트웨어의 품질 특성과 평가를 위한 표준 지침
  • 요구사항을 기술하거나 소프트웨어의 품질 평가 등에 사용
  • ISO/IEC 9126의 호환성과 보안성을 강화하여 ISO/IEC 25010으로 개정
  • ISO/IEC 12119: ISO/IEC 9126을 준수한 품질 표준으로, 테스트 절차를 포함하여 규정
  • ISO/IEC 9126에서 제시한 품질 특성을 다음과 같다
    • 기능성(Functionality) - 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부

      품질 요구사항	설명
      적절성/적합성(Suitability)	지정된 작업과 사용자의 목적 달성을 위해 적절한 기능 제공
      정밀성/정확성(Accuracy)	사용자가 요구하는 결과를 정확하게 산출
      상호 운용성(Interoperability)	다른 시스템과 서로 어울려 작업하는 능력
      보안성(Security)	정보에 대한 접근을 권한에 따라 허용하거나 차단
      준수성(Compliance)	기능과 관련된 표준, 관례 및 규정을 준수

    • 신뢰성(Reliability) - 요구된 기능을 오류 없이 수행할 수 있는 정도

      품질 요구사항	설명
      성숙성(Maturity)	결함으로 인한 고장을 피해갈 수 있음
      고장 허용성(Fault Tolerance)	결함이 있을 때도 규정된 성능 수준 유지
      회복성(Recoverability)	고장 시 규정된 성능 수준까지 회복하고 영향 받은 데이터를 복구하는 능력

    • 사용성(Usability) - 사용자-컴퓨터 간의 행위에 대해 사용자가 쉽게 배울 수 있고 다시 사용하고 싶은 정도

      품질 요구사항	설명
      이해성(Understandability)	적합성, 사용 방법 등을 사용자가 이해할 수 있는 능력
      학습성(Learnability)	애플리케이션을 학습할 수 있도록 하는 능력
      운용성(Operability)	운용하고 제어할 수 있도록 하는 능력
      친밀성(Attractiveness)	재사용하고 싶어 하도록 하는 능력

    • 효율성(Efficiency) - 요구하는 기능을 할당된 시간 동안 한정된 자원으로 얼마나 처리할 수 있는가

      품질 요구사항	설명
      시간 효율성(Time Behaviour)	특정 기능을 수행할 때 적절한 반응 시간, 처리시간 등을 제공하는 능력
      자원 효율성(Resource Behaviour)	기능을 수행할 때 적절한 자원의 양과 종류를 제공하는 능력

    • 유지 보수성(Maintainability)

      품질 요구사항	설명
      분석성(Analyzability)	결함, 고장의 원인 등의 식별을 가능하게 하는 능력
      변경성(Changeability)	결함 제거 또는 수정 등을 쉽게 구현할 수 있는 능력
      안정성(Stability)	예상치 못한 결과를 최소화하는 능력
      시험성(Testability)	변경이 검증될 수 있는 능력

    • 이식성(Portability)

      품질 요구사항	설명
      적용성(Adaptability)	원래 목정 이외에 다른 환경으로 변경될 수 있음
      설치성(Installability)	임의의 환경에 설치
      대체성(Replaceability)	동일한 환경&동일한 목적을 위해 다른 소프트웨어를 대신하여 사용될 수 있음
      공존성(Co-existence)	자원을 공유하는 환경에서 다른 소프트웨어와 공존

UI 프로토타입

• 사용자의 요구사항을 기반으로 실제 동작하는 것처럼 만든 동적인 모형
• 최대한 간단하게 개발
• 일부 핵심적인 기능 & 최종 제품의 작동 방식을 이해시키는 데 필요한 기능 반드시 포함
• 실제 사용자를 대상으로 테스트
• 장,단점
  • 장점
    • 사용자 설득이 쉬움
    • 개발 시간 단축 가능
    • 사전에 오류 발견 가능
  • 단점
    • 반복적인 작업으로 인한 작업 시간 증가
    • 필요이상의 자원 소모 가능성
    • 부분적인 작업으로 인해 중요한 작업이 생략될 가능성
• 종류
  • 페이퍼 프로토타입
    • 손으로 직접 작성
    • 제작 기간이 짧고 비용이 적을수록 사용
    • 즉시 변경이 가능하고 비용이 저렴하지만, 테스트하기에 적당하지 않고 공유가 어려움
  • 디지털 프로토타입
    • 아크로뱃 등 프로그램으로 작성
    • 재사용이 필요하고 전문가가 있을 경우 사용
    • 최종 제품과 비슷하게 테스트 할 수 있고 재사용이 가능하지만, 프로그램의 사용법을 알아야 함
• UI 프로토타입 제작 단계
  1. 사용자의 요구사항을 분석하는 단계
     • 기본적이 요구사항이 확정될 때까지 수행
  2. 프로토타입 작성
     • 핵심적인 기능을 중심으로 개발
  3. 작성된 프로토타입이 요구사항을 잘 수행하는지 사용자가 확인
     • 의견 추가 및 수정 가능
  4. 수정과 합의
     • 사용자가 요청한 제안 사항을 수용하여 보완 작업 수행
     • 작업 완료 후, 3단계로 돌아가 최종 승인이 완료될 때까지 반복
• 고려사항

  계획 시 고려사항	- 개발 목적 확인 - 필요한 환경 마련 - 프로토타이핑 일정은 아키텍처가 확정된 이후 실제 - 분석 작업이 완료되기 전에 진행 핵심이 되는 UI 요소를 범위로 설정 -개발 인원 확인 - 프로토타입 아키텍처를 검증 - 표준 가이드 확정 - 가장 많은 시간이 소요된 구간을 찾고 원인을 분석하여 해결 방법 제시
  작성 시 고려사항	- 작성 계획 수립 - 얻고자 하는 목표 확인 - 최소한의 기간과 비용 확인 - 완성된 프로토타입이 실제 개발에 참조될 수 있는지 확인

UI 설계서 작성

• 사용자 요구사항을 바탕으로 UI 설계를 구체화하여 작성하는 문서
• 개발자, 디자이너, 기획자의 원활한 의사소통을 위해 작성
• UI 설계서 표지 → UI 설계서 개정 이력 → UI 요구사항 정의서 → 시스템 구조 → 사이트 맵 → 프로세스 정의서 → 화면 설계 순으로 작성
  1. UI 설계서 표지
     
     • 프로젝트명 또는 시스템 명을 포함하여 작성
  2. 개정 이력
     • 처음 작성 시 첫 번째 항목은 '초안 작성', 버전은 1.0으로 설정
     • 이후 변경 사항이 있을 때마다 변경 내용을 작성하고 버전은 0.1씩 증가
  3. UI 요구사항 정의서
     • 요구사항의 UI 적용 여부를 요구사항별로 표시
  4. 시스템 구조
     • UI 요구사항과 UI 프로토타입에 기초하여 전체 구조를 설계
  5. 사이트 맵
     • 시스템 구조를 바탕으로 표시할 콘텐츠를 한 눈에 알아 볼 수 있도록 메뉴별로 구분하여 설계
     • 사이트 맵 작성 후, 상세 내용을 표 형태로 작성
  6. 프로세스 정의서
     • 사용자 관점에서 사용자가 요구하는 프로세스를 진행 순서에 맞춰 정리
     • 전체적인 흐름 파악 가능
  7. 화면 설계
     • UI 프로토타입과 UI 프로세스를 참고하여 필요한 화면을 페이지별로 설계
     • 화면별 고유 ID를 부여하고 별도 표지 작성
     • 주요 흐름을 스토리보드 형태로 작성

UI 상세 설계

• UI 설계서를 바탕으로 실제 설계 및 구현을 위해 자세한 설계 진행
• UI 시나리오 작성 필수
  • 사용자 인터페이스의 기능 구조, 인터랙션 흐름, 예외 처리 등을 문서로 정리
  • 사용자가 최종 목표를 달성하기 위한 방법이 순차적으로 정리되어 있음
  • UI 설계자 또는 인터랙션 디자이너가 UI 시나리오 문서를 작성하면 그래픽 디자이너가 디자인 후, 개발자가 UI 구현
  • 작성 원칙
    • 계층 구조나 플로차트로 작성
    • 공통적으로 적용될 UI 요소와 인터랙션을 일반 규칙으로 정의
    • 인터랙션의 흐름을 정의하고 인터랙션의 순서, 분기, 조건, 루프 등을 명시
    • UI 시나리오 규칙을 지정
  • 일반 규칙

    주요 키의 위치와 기능	모든 화면에 공통적으로 배치되는 키의 위치와 기능 설명
    공통 UI 요소	UI 요소를 언제, 어떤 형태로 사용할 것인지, 조작 시 어떻게 반응하는지 설명
    기본 스크린 레이아웃	모든 화면에 공통적으로 나타나는 Title, Option 등의 위치와 속성 정의
    기본 인터랙션 규칙	제스처에 사용되는 조작 방법, 화면 전환 효과 등을 설명
    공통 단위 태스크 흐름	많은 기능에 공통적으로 사용되는 인터랙션 흐름 설명
    케이스 문서	공통적으로 사용되는 시스템의 동작 정의

  • 요건

    완전성(Complete)	최대한 상세하게 기술 사용자의 태스크에 중점을 둠
    일관성(Consistent)	스타일, 요구사항, 목표 등이 모두 일관성을 유지해야 함
    이해성(Understandable)	누구나 이해하기 쉽도록 추상적인 표현은 지양
    가독성(Readable)	템플릿 등을 사용하여 문서를 쉽게 읽을 수 있도록 작성 문서 인덱스에 대한 목차 제공
    수정 용이성(Modifiable)	시나리오 수정이나 개선이 용이
    추적 용이성(Traceable)	변경 사항 추적이 용이

HCI / UX / 감성공학

• HCI(Human Computer Interaction or Interface)
  • 인간이 시스템을 보다 편리하고 안전하게 사용할 수 있도록 연구하고 개발하는 학문
  • 최적의 사용자 경험(UX) 제작을 목표로 함
• UX(User Experience)
  • 사용자가 시스템을 이용하면서 느낀 총체적인 경험
  • 사용자의 감정 중시
  • 특징
    • 주관성(Subjectivity)
    • 정황성(Contextuality)
    • 총체성(Holistic)
• 감성공학
  • 제품이나 작업 환경을 사용자의 감성에 맞게 설계 및 제작
  • 삶을 편리하고 쾌적하게 만드는 것을 목표로 함
  • HCI 설계에 인간의 감성 반영
  • 요소기술
    • 기반 기술
    • 구현 기술
    • 응용 기술

소프트웨어공학(Software Engineering)

• 여러 방법론, 도구, 관리 기법을 통해 소프트웨어의 품질과 생산성을 향상시키는 목적
• 기본원칙
  • 현대적 프로그래밍 기술을 계속해서 적용
  • 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증
  • 소프트웨어 개발 결과에 대한 기록 유지
• IEEE의 소프트웨어 공학 표준 용어사전
  • 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안
• Fairley
  • 지정된 비용과 기간 내에 소프트웨어를 생산하고 유지보수
• Boehm
  • 과학적 지식을 소프트웨어 설계와 제작에 응용

소프트웨어 생명 주기(소프트웨어 수명 주기)

• 소프트웨어를 개발하기 위해 운용, 유지보수 등의 과정을 단계별로 나눈 것
• 개발 단계, 단계별 주요 활동, 활동의 결과에 대한 산출물로 표현
• 소프트웨어 생명 주기 모형(소프트웨어 프로세스 모형 / 소프트웨어 공학 패러다임)
  • 소프트웨어 생명 주기를 표현하는 형태
  • 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등

폭포수 모형(Waterfall Model)

• 전통적인(고전적) 소프트웨어 생명 주기 모형 - 가장 오래되고 폭넓게 사용 → 적용 사례 많음
• 소프트웨어 개발은 이전 단계로 돌아갈 수 없다는 전제 → 선형 순차적 모형
• 각 단계를 확실하게 매듭짓고 결과를 검토하여 승인 과정을 거친 후 다음 단계로 진행
• 제품의 일부가 되는 매뉴얼 작성
• 다음 단계를 수행하기 위한 결과물이 명확하게 산출
• 두 개 이상의 과정은 병행되지 않는다

타당성 검토 → 계획 → 요구분석 → 설계 → 구현 → 시험 → 유지보수

프로토타입 모형(Prototype Model, 원형 모형)

• 실제 개발될 소프트웨어에 대한 프로토타입을 제작하여 최종 결과물 예측
• 프로토타입은 사용자-시스템 사이의 인터페이스에 중점을 두고 개발

요구 수집 → 빠른 설게 → 프로토타입 구축 → 고객 평가 → 프로토타입 조정 → 구현

나선형 모형(Spiral Model, 점진적 모형)

• 개발 과정에서 발생할 수 있는 위험을 관리하고 최소화하는 목적 - 위험관리에 중점을 둔다
• 폭포수 모형, 프로토타입 모형의 장점에 위험 분석 기능 추가
• 소프트웨어 개발 과정을 여러 번 거쳐 점진적으로 완벽한 최종 소프트웨어 개발
• 요구사항 업데이트 가능
• 유지보수 과정이 필요 없다

계획 수립 → 위험 분석 → 개발 / 검증 → 고객 평가

애자일 모형(Agile Model)

• 요구사항 변화에 대응할 수 있도록 일정한 주기를 반복하여 진행
• 고객과의 소통에 중점을 둔 방법론을 통칭
• 기업 활동 전반에 걸쳐 사용
• 소규모 프로젝트, 숙달된 개발자에 적합
• 스프린트(Sprint) 또는 이터레이션(Iteration)이라 불리는 개발 주기 반복
• 고객의 평가와 요구 적극 수용
• 각 주기마다 요구사항에 우선순위를 부여하여 개발 진행
• 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, ASD, DSDM, DAD, 기능 중심 개발 등
• 핵심 가치
  • 개인, 상호작용 > 프로세스, 도구
  • 실행되는 SW > 방대한 문서
  • 고객과의 협업 > 계약, 협상
  • 변화에 반응 > 계획

전략 수립 → 반복주기 1 → 반복주기 2 → ... → 마지막 반복주기

스크럼(Scrum)

• 팀이 중심이 되어 개발의 효율성을 높임
• 팀원 스스로가 스크럼 팀을 구성 → self-organizing
• 개발 작업에 관한 모든 것을 스스로 해결 → cross-functional
• 구성원
  • 제품 책임자(PO)
    • 주로 개발 의뢰자나 사용자가 담당
    • 요구사항이 담긴 백로그를 작성하고 우선순위 지정
    💡 백로그(Backlog) - 제품 개발에 필요한 모든 요구사항을 모아 우선순위를 부여한 목록
    • 테스트를 수행하면서 주기적으로 요구사항의 우선순위 갱신
    • 팀원은 백로그에 스토리 추가 가능(우선순위는 부여할 수 없다)
    💡 스토리(Story) - 백로그에 작성되는 요구사항으로 서술하는 형태로 표현
  • 스크럼 마스터(SM)
    • 객관적인 시각에서 조언을 하는 가이드 역할 - 통제하는 것이 아님
    • 일일 스크럼 회의 주관
  • 개발팀(DT)
    • PO, SM을 제외하고 개발자, 디자이너, 테스터 등 제품 개발에 참여하는 모든 사람
    • 최대 인원은 7~8명이 적당

스프린트 계획 회의 → 스프린트 → 일일스크럼 회의 → 스프린트 검토 회의 → 스프린트 회고

• 제품 백로그(Product Backlog)
  • 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 리스트
  • 지속적으로 업데이트
  • 백로그에 작성된 요구사항을 기반으로 릴리즈 플랜(Release Plan) 수립
• 스프린트 계획 회의(Spring Planning Meeting)
  • 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정 수립
  • 요구사항을 태스크(Task) 단위로 분할하여 개발자별로 수행할 작업 목록인 스프린트 백로그(Sprint Backlog) 작성
• 스프린트(Sprint)
  • 실제 개발 작업으로 2~4주 정도 진행
  • 개발자가 원하는 태스크를 직접 선별하여 담당할 수 있도록 하는 것이 좋다
  • 할당된 태스크는 할 일(To Do), 진행중(In Progress), 완료(Done)의 상태를 갖는다
• 일일 스크럼 회의(Daily Scrum Meeting)
  • 매일 약속된 시간에 짧은 시간동안 진행사항 점검
  • 남은 작업 시간은 **소멸 차트(Burn-down Chart)**에 표시
  💡 소멸 차트 - 진행 상황을 확인할 수 있도록 시간의 경과에 따라 남은 작업 시간을 그래프로 표현
  • 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와준다
• 스프린트 검토 회의(Sprint Review)
  • 제품이 요구사항에 잘 부합되는지 사용자를 포함한 참석자 앞에서 테스팅 수행
  • 스프린트의 한 주당 한 시간 내에서 진행
  • 제품 책임자는 개선할 사항에 대한 피드백 정리 후, 제품 백로그 업데이트
• 스프린트 회고(Spring Retrospective)
  • 주기를 되돌아보며 규칙을 준수했는지, 개선할 점은 없는 지 등을 확인하고 기록
  • 해당 스프린트가 끝난 시점에서 수행 or 일정 수기로 수행

XP(eXtreme Programming)

• 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성 향상
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 빠르게 개발
• 릴리즈 기간을 짧게 반복 → 고객의 요구사항 반영에 대한 가시성을 높인다
• 릴리즈 테스트마다 고객이 직접 참여 → 요구사항이 제대로 작동하는 지 직접 확인 가능
• 소규모 인원의 개발 프로젝트에 효과적
• 핵심 가치
  • 의사소통(Communication)
  • 단순성(Simplicity)
  • 용기(Courage)
  • 존중(Respect)
  • 피드백(Feedback)
• 주요 실천 방법
  • 짝 프로그래밍(Pair Programming) → 다른 사람과 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경 조성
  • 공동 코드 소유(Collective Ownership) → 개발 코드에 대한 권한과 책임을 공동으로 소유
  • 테스트 주도 개발(Test-Driven-Development) → 테스팅 도구(프레임워크 등)를 사용하여 테스트가 지속적으로 진행될 수 있게 함, 실제 코드 작성 전 테스트 케이스를 작성하여 자신의 역할을 정확히 파악
  • 전체 팀(Whole Team) → 개발에 참여하는 모든 구성원들은 각자의 역할이 있고 역할에 대한 책임을 가져야 함
  • 계속적인 통합(Constinous Intergration) → 모듈 단위로 나눠서 개발된 코드는 하나의 작업이 마무리될 때마다 지속적으로 통합
  • 디자인 개선 또는 리팩토링(Design Improvement or Refactoring) → 기능의 변경 없이 단순화, 유연성 강화 등을 통해 시스템 재구성
  • 소규모 릴리즈(Small Release) → 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속하게 대응

사용자 스토리(User Story) → 릴리즈 계획 수립(Release Planning) → 스파이크(Spike) → 이터레이션(Iteration) → 승인 검사(Acceptance Test) → 소규모 릴리즈(Small Release)

• 사용자 스토리(User Story)
  • 고객의 요구사항을 간단한 시나리오로 표현
  • 내용은 기능 단위로 구성, 필요한 경우 간단한 테스트 사항(Test Case) 기재
• 릴리즈 계획 수립(Release Planning)
  • 부분적으로 기능이 완료된 제품 제공
  • 부분 또는 전체 개발 완료 시점에 대한 일정 수립
• 스파이크(Spike)
  • 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 만드는 간단한 프로그램
  • 처리할 문제 외의 다른 조건은 모두 무시
• 이터레이션(Iteration)
  • 하나의 릴리즈를 세분화 한 단위
  • 1~3주 정도의 기간으로 진행
  • 새로운 스토리가 작성될 수 있으며, 작성된 스토리는 진행 중이거나 다음 이터레이션에 포함
• 승인검사(Acceptance Test)
  • 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행
  • 사용자 스토리 작성 시 함께 기재한 테스트 사항에 대해 고객이 직접 수행
  • 발견한 오류 사항은 다음 이터레이션에 포함
  • 테스트 이후 새로운 요구사항이 작성되거나 상대적 우선순위가 변경될 수 있음
  • 테스트 완료 후에는 다음 이터레이션 진행
• 소규모 릴리즈(Small Release)
  • 고객의 반응을 기능별로 확인할 수 있어 고객의 요구사항에 유연하게 대응 가능
  • 계획된 릴리즈 기간 내의 이터레이션이 모두 완료되면 최종 테스트 수행 후 최종 결과물(Release)를 고객에게 전달

현행 시스템 파악

• 새로 개발하려는 시스템의 개발 범위를 명확하게 설정하기 위해 현행 시스템의 구성과 제공 기능, 전달 정보, 사용되는 기술 요소 등을 파악

시스템 구성/기능/인터페이스 파악 → 아키텍처 구성, 소프트웨어 구성 파악 → 하드웨어 구성, 네트워크 구성 파악

• 시스템 구성 파악
  • 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술
  • 각 업무에 속하는 단위 업무 정보시스템들의 명칭, 주요 기능 명시
• 시스템 기능 파악
  • 단위 업무 시스템이 현재 제공하는 기능을 주요 기능, 하부 기능, 세부 기능으로 구분하여 계층형으로 표시
• 시스템 인터페이스 파악
  • 단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시
• 아키텍처 구성 파악
  • 기간 업무 수행에 어떠한 기술 요소들이 사용되는 지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성
  • 아키텍처가 단위 업무 시스템별로 다른 경우, 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 표현
• 소프트웨어 구성 파악
  • 소프트웨어의 제품명, 용도, 라이선스 적용 방식(사이트, 서버, 프로세서, 동시 사용, 코어, 사용자 수 등), 라이선스 수 등을 명시
  • 상용 소프트웨어의 경우 라이선스 적용 방식의 기준과 보유한 라이선스의 파악이 중요
• 하드웨어 구성 파악
  • 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수향, 이중화의 적용 여부 명시
  • 서버의 이중화는 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요 여부가 결정
  • 현행 시스템의 이중화가 적용된 경우 대부분 새로 구성될 시스템에도 이중화가 필요 → 비용 증가와 시스템 구축 난이도가 높아질 가능성 고려
  💡 서버의 이중화(Replication) - 운용 서버의 장애 시 대기 서버로 서비스를 계속 유지할 수 있도록 운용 서버의 자료 변경이 예비 서버에도 동일하게 복제되도록 관리
• 네트워크 구성 파악
  • 업무 시스템들의 네트워크 구성을 파악할 수 있도록 서버의 위치, 서버 간 네트워크 연결 방식을 네트워크 구성도로 작성
  • 네트워크 장애가 발생할 경우 원인을 찾아 복구하기 위한 용도로 사용 가능
  • 서버의 물리적 위치 관계를 파악할 수 있고 보안 취약성을 분석하여 적절한 대응 가능

개발 기술 환경

• 개발할 소프트웨어와 관련된 OS, DBMS, Middle Ware 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈 소스 사용 시 주의해야 할 내용을 제시

💡 미들웨어(Middle Ware) - 운영체제와 해당 운영체제에 의해 실행되는 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어

• 운영체제(Operating System)
  • 컴퓨터 시스템의 자원을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할수 있도록 환경을 제공하는 소프트웨어
  • Windows, UNIX, Linux, Mac OS, iOS, Android 등
  • 운영체제 관련 요구사항 식별 시 고려사항
    • 가용성: 메모리 누수로 인한 성능 저하 및 재가동, 발견된 허점을 보완하기 위한 지속적인 패치 설치로 인한 재가동, 운영체제 고유의 장애 발생 가능성
    • 성능: 대규모 및 대용량 파일 작업에 대한 처리, 지원 가능한 메모리 크기(32bit, 64bit), 대규모 동시 사용자 요청에 대한 처리
    • 기술 지원: 여러 사용자들 간의 정보 공유, 오픈소스 여부(Linux), 제작업체의 안정적인 기술 지원
    • 주변 기기: 여러 주변기기 지원 여부, 설치 가능한 소프트웨어
    • 구축 비용: 설치할 응용 프로그램의 라이선스 정책 및 비용, 총 소유 비용(TCO), 유지관리 비용, 지원 가능한 하드웨어 비용
• 데이터베이스 관리 시스템(DataBase Management Service
  • 사용자와 DB 사이에서 사용자의 요구에 따라 정보를 생성해 주고 DB를 관리하는 소프트웨어
  • 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제 해결을 위해 제안된 시스템
  • DB의 구성, 접근 방법, 유지관리에 대한 모든 책임을 짐
  • Oracle, MariaDB, Redis, MySQL, IBM DB2, Microsoft SQL Server, SQLite 등
  • DBMS 관련 요구사항 식별 시 고려사항
    • 가용성: 백업, 복구의 편의성, DBMS 이중화 및 복제 지원
    • 성능: 대용량 트랜잭션 처리 성능, 최소화된 설정과 비용 기반 질의 최적화 지원, 튜닝 옵션의 다양한 지원,대규모 데이터 처리 성능
    • 기술 지원
    • 상호 호환성: JDBC, ODBC와의 호환 여부, 설치 가능한 운영체제의 종류
    • 구축 비용: 라이선스 정책 및 비용
• 웹 애플리케이션 서버(WAS)
  • 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
  • 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공
  • 주로 DB 서버와 연동해서 사용
  • Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등
  • WAS 관련 요구사항 식별 시 고려사항
    • 가용성: 안정적인 트랜잭션 관리, WAS 이중화 지원, WAS 결함 등으로 인한 패치 설치를 위한 재가동
    • 성능: 가비지 컬렉션(GC)의 다양한 옵션
    • 기술 지원
    • 구축 비용

💡 가비지 컬렉션(GC) - 실제로는 사용되지 않으면서 가용 공간 리스트에 반환되지 않는 메모리 공간인 가비지를 강제로 해제하여 사용할 수 있도록 하는 메모리 관리 기법

• 오픈소스 사용에 따른 고려사항
  • 라이선스의 종류
  • 사용자 수
  • 기술의 지속 가능성

요구사항 정의

• 요구사항 - 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 운영되는데 필요한 제약 조건
• 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거 제공
• 이해관계자들 간의 의사소통을 원할하게 하는 데 도움을 줌
• 요구사항이 제대로 정의된 후 이를 토대로 이후 과정의 목표와 계획 수립

1. 기능 요구사항(Functional Requirements)
   • 시스템이 무엇을 하는지, 어떤 기능을 하는지
   • 입출력으로 무엇이 포함되는지, 어떤 데이터를 저장하거나 연산을 수행해야 하는지
   • 반드시 수행해야 하는 기능
   • 사용자가 시스템을 통해 제공받기를 원하는 기능
2. 비기능 요구사항(Non-functional Requirements)
   • 시스템 장비 구성
   • 성능 - 처리 속도 및 시간, 처리량 등
   • 인터페이스 - 다른 소프트웨어, 하드웨어 및 통신 인터페이스, 정보 교환에 사용되는 프로토콜과의 연계
   • 데이터 - 초기 자료 구축 및 데이터 변환을 위한 대상, 방법, 보안이 필요한 데이터 등 데이터를 구축하기 위해 필요한 요구사항
   • 테스트 - 도입되는 장비의 성능 테스트(BMT) 등
   • 보안 - 시스템의 데이터 및 기능, 운영 접근을 통제
   • 품질 - 관리가 필요한 품질 항목 / 가용성, 정합성, 상호 호환성, 대응성, 신뢰성, 사용성, 유지관리성, 이식성, 확장성, 보안성 등으로 구분하여 기술
   • 제약사항 - 시스템 설계, 구축, 운영과 관련하여 사전에 파악된 기술, 법, 제도 등
3. 사용자 요구사항(User Requirements)
   • 사용자 관점에서 본 시스템이 제공해야 할 요구사항
   • 친숙한 표현으로 이해하기 쉽게 작성
4. 시스템 요구사항(System Requirements, 소프트웨어 요구사항)
   • 개발자 관점에서 시스템이 사용자와 다른 시스템에 제공해야 할 요구사항
   • 전문적이고 기술적인 용어로 표현

도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 확인(Validation)

• 요구사항 개발 프로세스가 진행되기 전에 개발 프로세스가 비즈니스 목적에 부합되는지, 예산은 적정한지 등에 대한 정보를 수집, 평가한 보고서를 토대로 타당성 조사(Feasibility Study)가 선행되어야 함

1. 요구사항 도출(Requirement Elicitation)
   • 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계
   • 개발자 - 고객 사이의 관계 생성 & 이해관계자 식별
   • 다양한 이해관계자 간의 효율적인 의사소통이 중요
   • 소프트웨어 개발 생명 주기 동안 지속적으로 반복
   • 주로 청취, 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스(Use Case) 등
2. 요구사항 분석(Requirement Analysis)
   • 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 발견하고 걸러내는 과정
   • 도출된 요구사항을 토대로 소프트웨어의 범위 파악
   • 소프트웨어와 주변 환경이 상호 작용하는 방법을 이해
   • 자료 흐름도(DFD), 자료 사전(DD) 등의 도구 사용
3. 요구사항 명세
   • 분석된 요구사항을 바탕으로 모델을 작성하고 문서화
   • 기능 요구사항은 완전하고 명확하게 기술
   • 비기능 요구사항은 필요한 것만 명확하게 기술
   • 사용자가 이해하기 쉽고 개발자가 효과적으로 설계할 수 있도록 작성
   • 설계 과정에서 잘못된 부분이 확인될 경우 그 내용을 요구사항 정의서에서 추적할 수 있어야 함
   • 구체적인 명세를 위해 소단위 명세서(Mini-Spaec) 사용 가능
   • 명세 기법
     1. 정형
        • 수학적 원리 기반
        • 수학적 기호, 정형화된 표기법
        • 요구사항을 정확하게 간결하게 표현 가능
        • 요구사항에 대한 결과가 작성자에 관계없이 일관성이 있어 완전성 검증 가능
        • 사용자가 이해하기 어려움
        • VDM, Z, Petri-net, CSP 등
     2. 비정형
        • 상태/기능/객체 중심
        • 자연어를 기반으로 서술 또는 다이어그램
        • 요구사항에 대한 결과가 작성자에 따라 다를 수 있어 일관성 하락
        • 내용이 쉬워 의사소통 용이
        • FSM, Decision Table, ER 모델링, State Chart 등
4. 요구사항 확인
   • 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하게 작성되었는지 검토
   • 실제 요구를 반영하는지, 상충되는 요구사항은 없는지 점검
   • 요구사항 문서는 이해관계자가 검토
   • 검증 과정을 통해 모든 문제를 확인 가능한 것은 X
   • 요구사항 관리 도구를 이용하여 정의 문서들에 대해 형상 관리 수행

요구사항 분석

• 소프트웨어 개발의 실제적인 첫 단계
• 개발 대상에 대한 사용자의 요구사항을 이해하고 명세화 하는 활동
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약 설정
• 요구를 정확하게 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정
• 요구사항을 정확하고 일관성 있게 분석하여 문서화
• 소프트웨어 분석가에 의해 요구사항 분석 수행
• 구조적 분석 기법
  • 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
  • 도형 중심의 분석용 도구와 분석 절차 이용 → 분석가 - 사용자 간의 대화가 용이
  • 하향식 방법을 사용하여 시스템을 세분화하고 분석의 중복 배제
  • 요구사항을 논리적으로 표현하여 전체 시스템을 일관성 있게 이해 가능
  • 시스템 분석의 질 향상 & 시스템 개발의 모든 단계에서 필요한 명세서 작성 가능
  • 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec) 등의 도구 사용

1. 자료 흐름도(Data Flow Diagram, Bubble Chart, 자료 흐름 그래프)
   • 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술
   • 프로세스와 데이터 저장소 사이에 자료의 흐름을 나타내는 그래프
   • 단계적으로 세분화
   • 자료는 처리(Process)를 거쳐 변환될 때마다 새로운 이름 부여
   • 제어의 흐름은 중요하지 X
   • 시간의 흐름은 명확하게 표현 불가능
   • 프로세스(Process, Bubble), 자료 흐름(Data Flow), 자료 저장소(Data Store), 단말(Terminator) 네 가지 기본 기호로 표시
2. 자료 사전(Data Dictionary)
   • 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
   • 자료 흐름도에 시각적으로 표시된 자료에 대한 정보를 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게 사용할 수 있음

     =	자료의 정의: ~로 구성되어 있다(is composed of)
     +	자료의 연결: 그리고(and)
     ( )	자료의 생략: 생략 가능한 자료(Optional)
     [	]
     { }	자료의 반복: Iteration of
     * *	자료의 설명: 주석(Comment)

요구사항 분석 CASE

• 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구를 요구사항 분석을 위한 자동화 도구라고 한다
  • 표준화와 보고를 통한 문서화 품질 개선
  • 데이터베이스가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정 가능
  • 교차 참조도와 보고서를 통한 결함, 생략, 불일치 등 발견
  • 변경이 주는 영향 추적이 용이
  • 명세에 대한 유지보수 비용 축소 가능
  • SADT, SREM, PSL/PSA, TAGS, EPOS 등
  1. SADT(Structured Analysis and Design Technique)
     • SoftTech사에서 개발
     • 시스템 정의 ,소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용되어 온 구조적 분석 및 설계 도구
     • 구조적 요구 분석을 위해 블록 다이어그램 채택
  2. SREM(Software Requirements Engineering Methodology) 
     • TRW사가 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히기술하도록 할 목적으로 개발
     • RSL / REVS 사용
       • RSL(Requirement Statement Language) - 요소, 속성, 관계, 구조를 기술하는 요구사항 기술 언어
         

         요소	요구사항 명세를 개발하기 위해 사용되는 개체와 개념
         속성	요소를 수정하거나 수식하기 위한 것
         관계	개체들 간의 관계
         구조	정보 흐름 묘사

       • REVS(Requirement Engineering and Validation System) - RSL로 기술된 요구사항을 자동으로 분석하여 요구사항 분석 명세서를 출력하는 요구사항 분석기
  3. PSL/PSA
     • 미시간 대학에서 개발
     • PSL / PSA 사용
       • PSL(Problem Statement Language) - 문제(요구사항) 기술 언어
       • PSA(Problem Statement Analyzer) - PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서를 출력하는 문제 분석기
  4. TAGS(Technology for Automated Generation of Systems)
     • 시스템 공학 방법 응용에 대한 자동 접근 방법
     • 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구
     • IORL(요구사항 명세 언어), IORL 처리를 위한 도구, 기초적인 TAGS 방법론으로 구성

HIPO(Hierarchy Input Process Output)

• 시스템의 분석 및 설계나 문서화할 때 사용
• 시스템 실행 과정인 입출력, 처리의 기능을 나타냄
• 기본 시스템 모델은 입력, 처리 출력으로 구성
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기호, 도표 등을 사용하여 이해가 쉬움
• 기능과 자료의 의존 관계를 동시에 표현 가능
• 변경, 유지보수 용이
  1. 가시적 도표(Visual Table of Contents, 도식 목차)
     • 시스템의 전체적인 기능과 흐름을 보여주는 계층(Tree) 구조도
  2. 총체적 도표(Overview Diagram, 총괄 도표, 개요 도표)
     • 프로그램을 구성하는 기능을 기술
     • 프로그램을 구성하는 기능을 기술
  3. 세부적 도표(Detail Diagram, 상세 도표)
     • 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술

💡 HIPO Chart - 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것

UML(Unified Modeling Language)

• 개발자-사용자 또는 개발자 간의 의사소통이 원할하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• Rumbaugh, Booch 등의 객체지향 방법론의 장점을 통합
• 6개의 구조 다이어그램와 7개의 행위 다이어그램
• 사물과 사물 간의 관계를 용도에 맞게 표현
• 사물(Things), 관계(Relationships), 다이어그램(Diagram)으로 구성
  1. 사물(Things) - 모델을 구성하는 가장 기본적인 요소
     • 구조 사물
       • 개념적, 물리적 요소
       • 클래스, 유스케이스, 컴포넌트, 노드 등
     • 행동 사물
       • 요소의 행위
       • 상호작용(Interaction), 상태 머신(State Machine) 등
     • 그룹 사물
       • 요소를 그룹화
       • 패키지(Package)
     • 주해 사물
       • 제약 조건이나 부가적인 설명
       • 노트(Note)
  2. 관계(Relationships)
     • 연관 관계(Association)
       • 2개 이상의 사물이 서로 관련되어 있음
       • 사물 사이를 실선으로 연결하여 표현
       • 방향성은 화살표로 표현
       • 양방향 관계일 경우 화살표를 생략하고 실선으로만 연결
     • 집합 관계(Aggregation)
       • 하나의 사물이 다른 사물에 포함
       • 포함하는 쪽 - 포함되는 쪽은 서로 독립적

         

     • 포함 관계
       • 집합 관계의 특수한 형태
       • 포함하는 사물의 변화가 포함되는 사물에게 영향을 미침
       • 포함하는 쪽 - 포함되는 쪽은 독립될 수 없고 생명주기를 함께함

         

     • 의존 관계
       • 사물 사이에 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관 유지
       • 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계
       • 화살표가 있는 점선으로 표시
     • 실체화 관계
       
       • 사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계
       • 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계
       • 속이 빈 화살표가 있는 실선으로 표시
     • 일반화 관계
       
       • 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현
       • 일반적인 개념을 상위(부모), 구체적인 개념을 하위(자식)라고 부름

         

  3. 다이어그램(Diagram)
     • 사물과 관계를 도형으로 표현
     • 여러 관점에서 시스템을 가시화한 뷰(View)를 제공함으로써 의사소통에 도움을 줌
     • 정적 모델링에서는 구조적 다이어그램을, 동적 모델링에서는 행위 다이어그램을 사용
     • 스테레오 타입(Stereotype) - UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용, 길러멧(Guilemet)이라고 부르는 겹화살괄호 << >> 사이에 표현할 형태를 기술

       <<include>>	연결된 다른 UML 요소에 대해 포함 관계에 있는 경우
       <<extend>>	연결된 다른 UML 요소에 대해 확장 관계에 있는 경우
       <<interface>>	인터페이스를 정의
       <<exception>>	예외를 정의
       <<constructor>>	생성자 역할을 수행하는 경우

       
       
       • 구조적 다이어그램(Structural Diagram)
         1. 클래스 다이어그램(Class Diagram)
            • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계 표현
            • 시스템의 구조를 파악하고 구조상의 문제점을 도출
         2. 객체 다이어그램(Object Diagram)
            • 클래스에 속한 객체들, 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
            • 럼바우(Rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용
         3. 컴포넌트 다이어그램(Component Diagram)
            • 컴포넌트 간의 관계나 인터페이스 표현
            • 구현 단계에서 사용
         4. 배치 다이어그램(Deployment Diagram)
            • 물리적 요소의 위치를 표현
            • 노드와 의사소통 경로로 표현
            • 구현 단계에서 사용
         5. 복합체 구조 다이어그램(Composite Structure Diagram)
            • 클래스나 컴포넌트가 복합 구조를 갖는 경우에 그 내부 구조를 표현
         6. 패키지 다이어그램(Package Diagram)
            • 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계 표현
       • 행위 다이어그램(Behavioral Diagram)
         1. 유스케이스 다이어그램(Use Case Diagram)
            • 사용자의 요구 분석
            • 사용자(Actor)와 사용 사례(Use Case)로 구성
         2. 시퀀스 다이어그램(Sequence Diagram)
            • 상호 작용하는 시스템이나 객체들이 주고받는 메시지 표현
         3. 커뮤니케이션 다이어그램(Communication Diagram)
            • 객체들이 주고받는 메시지와 객체들 간의 연관 표현
         4. 상태 다이어그램(State Diagram)
            • 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현
            • 럼바우 객체지향 분석 기법에서 동적 모델링에 활용
         5. 활동 다이어그램(Activity Diagram)
            • 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
         6. 상호작용 개요 다이어그램(Interaction Overview Diagram)
            • 상호 작용 다이어그램 간의 제어 흐름을 표현
         7. 타이밍 다이어그램(Timing Diagram)
            • 객체 상태 변화와 시간 제약을 명시적으로 표시
  •  

주요 UML 다이어그램

• 유스케이스(Use Case) 다이어그램
  • 사용자와 다른 외부 시스템들이 개발될 시스템을 이용하여 수행할 수 있는 기능을 사용자의 관점에서 표현
  • 외부 요소와 시스템 간의 상호 작용 확인 가능
  • 시스템의 범위 파악 가능
  • 시스템 범위, 액터, 유스케이스, 관계로 구성

    시스템/시스템 범위	시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스를 사각형으로 묶어 범위를 표현
    액터	시스템과 상호작용을 하는 모든 외부 요소로, 시스템을 사용하여 이득을 얻는 대상(사람 등)인 주액터와 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템(조직, 기관 등)인 부액터가 있음
    유스케이스	사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능
    관계	액터-유스케이스, 유스케이스-유스케이스 사이의 관계로, 포함, 확장, 일반화 관계의 3종류 존재

  • 관계
    1. 포함
       • 두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스를 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계를 포함 관계라 함
       • 원래의 유스케이스에서 새롭게 만든 유스케이스 쪽으로 점선 화살표를 연결한 후, 화살표 위에 <<include>>라고 표기
    2. 확장
       • 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계를 확장 관계라 함
       • 확장될 유스케이스에서 원래의 유스케이스 쪽으로 점선 화살표 연결 후, <<extends>>라고 표기
• 클래스(Class) 다이어그램
  
  • 시스템을 구성하는 클래스, 클래스의 특성인 속성과 오퍼레이션, 속성과 오퍼레이션에 대한 제약 조건, 클래스 사이의 관계를 표현
  • 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램
  • 시스템 구성 요소를 문서화하는 데 사용
  • 객체의 속성, 함수 등의 정보를 잘 표현 → 시스템 모델링에 자주 사용
  • 클래스, 제약조건, 관계로 구성

    클래스(class)	각각의 객체들이 갖는 속성과 오퍼레이션(메소드) 표현
    제약조건	속성에 입력될 값에 대한 제약조건 또는 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 적음
    관계	클래스와 클래스 사이의 연관성 표현

    접근제어자	표현법	내용
    public	+	어떤 클래스라도 접근 가능
    private	-	해당 클래스 내부에서만 접근 가능
    protect	#	패키지 내의 클래스 또는 해당 클래스를 상속 받은 외부 패키지의 클래스에서 접근 가능
    package	~	동일 패키지 내부에 있는 클래스에서만 접근 가능

• 시퀀스(Sequence) 다이어그램
  • 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현
  • 시스템 또는 객체들의 상호작용(오퍼레이션)을 표현
  • 클래스 내부의 객체들을 기본 단위로 상호 작용 표현
  • 주로 기능 모델링에서 작성한 유스케이스 명세서를 하나의 표현 범위로 하지만, 하나의 클래스에 포함된 오퍼레이션을 하나의 범위로 표현하기도 함
  • 액터, 객체, 생명선, 실행, 메시지 등으로 구성

    액터(Actor)	시스템으로부터 서비스를 요청하는 외부 요소
    객체(Object)	메시지를 주고받는 주체
    생명선(Lifeline)	객체가 메모리에 존재하는 기간
    실행 상자(Active Box)	객체가 메시지를 주고받으며 구동되고 있음을 표현
    메시지(Message)	객체가 상호 작용을 위해 주고받는 메시지

HTML - Hypertext Markup Language

Hypertext: 하이퍼 링크로 문서를 연결하여 다른 문서로 이동을 가능하게 하는 텍스트

Markup: 태그를 사용하여 메타 정보 표현

웹페이지의 내용과 구조를 나타낸다

기본구조

<!DOCTYPE html> //문서 종류 지정
<html lan="ko"> //한글 문서
	<head>
    	<meta charset="utf-8"> //인코딩
        ...
    </head>
    <body>
    	...
    </body>
</html>