1. 소프트웨어 설계

1. 소프트웨어 설계.pdf

5.06MB

소프트웨어 설계

요구사항 확인

현행 시스템 분석

플랫폼 기능 분석 (현행 시스템 파악)

현행 시스템 파악 절차

1. 구성, 기능, 인터페이스 파악현행 시스템 기능 현황 : 단위 업무 시스템 제공 기능
2. 현행 시스템 인터페이스 현황 : 데이터 종류, 데이터 형식, 프로토콜, 연계유형, 주기
3. 현행 시스템 구성 현황 : 기간업무, 지원업무
4. 아키텍처, 소프트웨어 구성 파악소프트웨어 구성도
5. 현행 시스템 아키텍처 구성도
6. 하드웨어, 네트워크 구성 파악네트워크 구성도
7. 하드웨어 구성도

플랫폼 성능 특성 분석

개발 기술 환경 요구사항 파악

현행시스템 분석서 작성, 검토

운영체제 분석

고려사항

1. 신뢰도
2. 성능
3. 기술 지원
4. 주변기기
5. 구축비용

네트워크 분석

OSI 참조모델 계층구조

응용

원격 로그인, 파일 액세스, 전송, 관리, 우편 서비스, WWW 접근

사용자에게 서비스 제공

표현

변환, 압축, 확장, 암호화, 복호화

세션

세션관리, 동기화, 대화 제어, 원활한 종료

전송

포트 주소 지정, 분할과 재조립, 연결 제어, 흐름 제어, 오류 제어

다른 프로세스로 메시지 전달

네트워크

발신에서 목적지까지 전달, 논리 주소 지정, 라우팅

최종 목적지 호스트로 패킷 전달

데이터링크

프레임 구성, 물리 주소 지정, 흐름 제어, 오류 제어, 접근 제어

다른 노드로 프레임 전송

물리

인터페이스와 매체의 물리적인 특성, 비트의 표현, 데이터 속도, 비트의 동기화

개별 비트들을 다음 노드로 전달

DBMS 분석

고려사항

1. 가용성
2. 성능
3. 기술지원
4. 상호 호환성
5. 구축 비용

비즈니스 융합 분석

WAS 고려사항

1. 가용성
2. 성능
3. 기술지원
4. 구축비용

요구사항 확인

요구사항 분석 기법

요구사항 개발 프로세스

1. 도출 : 문제를 이해
   • 요구사항 소스
   • 도출 기법
2. 분석 : 요구사항들간 충돌을 해결, 범위 파악, 상호작용 이해
   • 요구사항 분류
   • 개념 모델링
   • 기술 구조 설계 및 요구사항 할당
   • 요구사항 협상
3. 명세 : 검토, 평가, 승인 될 수 있는 문서를 작성
   • 시스템 정의서
   • 시스템 요구사항 명세서
   • 소프트웨어 요구사항 명세서
4. 확인 : 요구사항을 정확히 이해했는지 파악, 요구사항 문서 검증
   • 검토
   • 프로토타이핑
   • 모델 검증
   • 인수 Test

요구사항 분석 기법

• 요구사항 분류
  • 요구사항의 기능, 비기능 여부
  • 요구사항이 유도된 것인지 직접 발생한 것인지 여부
  • 제품, 프로세스에 관한 것인지 여부
  • 우선순위 여부
  • 영향의 범위
  • 요구사항 변경 여부
• 개념 모델링
  • UML 사용
• 요구사항 할당
  • 요구사항 만족을 위한 아키텍처 구성 요소를 식별
  • 상호작용 분석을 통해 추가적 요구사항을 발견할 수 있음
• 요구사항 협상
• 정형 분석
  • 형식적으로 정의된 시맨틱을 지닌 언어로 요구사항을 표현

요구사항 확인 기법

이해관계자들이 문서 검토, 형상관리에 요구사항 관리 툴을 이용

• 요구사항 검토
• 프로토타이핑
• 모델 검증
• 인수 테스트

요구사항 검증하기

1. 요구사항이 모두 반영되었는지 확인
   • ID
   • 이름
   • 유형
   • 품질속성
   • 우선순위
   • 중요도
   • 출처
   • 관련 부서
   • 전제 조건
   • 내용
   • 관련 요구사항
   • 버전
   • 수용 여부
2. 요구사항 목록의 속성
3. 요구사항 정의서 작성 여부 확인
   • 유스케이스명
   • 관련 액터
   • 개요
   • 사전 조건
   • 사후 조건
   • 정상 흐름
   • 대안 흐름
   • 예외 흐름
   • 비기능적 요구사항
4. 유스케이스 명세서 예시
5. 비기능적 요구사항이 명확히 도출되었는지 확인
6. 타 시스템과 연계 및 인터페이스에 대한 요구사항이 적절히 도출되었는지 확인

요구사항의 시스템화 타당성 분석

요구사항의 기술적 타당성 검토

1. 성능 및 용량산정 적절성
2. 시스템 간 상호 운용성
3. IT 시장 성숙도 및 트렌드 부합성
4. 기술적 위험 분석 : 복잡성, 검증여부, 의존성

요구분석 기법

• 사용자 그룹 인터뷰
• 이해관계자 설문조사
• 문헌조사
• 프로토타이핑
• 사용자 스토리텔링

UML

UML 도입 효과

개발 기획과 산출물에 대한 확인

전문가와 비전문가가 서로 대화할 수 있는 수단

UML 다이어그램 유형

• 사용 사례 다이어그램
• 클래스 다이어그램
• 순서 다이어그램
• 상태 다이어그램
• 활동 다이어그램

애자일

애자일 개발 방법론

• 익스트림 프로그래밍 : 고객과 함께 2주 정도의 반복 개발을 하고, TDD를 특징으로 함
• 스크럼 : 20일마다 동작 가능한 제품을 제공하는 스프린트를 중심으로 함
• 크리스털 패밀리 : 프로젝트의 규모, 영향의 크기에 따라 여러 종류 방법론 제공
• Feature-Driven Development : Feature마다 2주 정도의 반복 개발을 실시
• ASD : 소프트웨어 개발을 혼란 자체로 규정, 합동 애플리케이션 개발 방법론을 사용
• 익스트림 모델링 : 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복

기타 개발 방법론

• 폭포수 모델
• 나선형 모델
  • 계획 수립 : 개발 목적, 수정 계획, 제약 조건 등을 설정
  • 위험 분석 : 위험 요소, 타당성을 분석하여 프로젝트 추진 여부 결정
  • 개발 : 개선된 한 단계의 프로토타입 개발
  • 고객 평가 : 개발된 프로토타입 평가나선형 모형의 특징
  • 
  • 위험 분석 단계에서 위험 요소들을 제거해 나감으로 완성도 높은 소프트웨어를 만들 수 있다.
  • 반복적 작업을 수행하는 점증적 생명주기 모델
  • 유지보수는 처리 절차에 포함되지 않는다.
  • 대규모 프로젝트에 유리하다.
• 나선형 모형의 단계별 기능

분석 모델 확인

모델링 기법

분석 모델 검증

검증 방법

1. 유스케이스 모델 검증
   • 액터
   • 유스케이스
   • 유스케이스 명세서
2. 개념 수준 분석 클래스 검증
   • 클래스 도출
   • 클래스명과 속성
   • 클래스들 사이의 관계
3. 분석 클래스 검증
   • 스테레오 타입
   • 경계 및 제어 클래스 도출
   • 관계 및 상세화 정도

유스케이스 모델 검증

개념 수준의 분석 클래스 검증

개념 수준의 주요 분석 클래스를 적절히 도출하였는지, 관련 정보가 명확한지 점검

분석 클래스 검증

하나의 유스케이스를 실현하기 위해 3개 이상의 클래스가 역할 기준으로 도출되어야 함

유스케이스별 실현에 필요한 클래스가 추적 가능해야 함

유스케이스 단위로 분석 클래스를 확인

분석 클래스의 스테레오 타입

경계 및 제어 클래스 도출 및 상세화 정도 확인

분석 클래스 간의 관계, 클래스 정보의 상세화 정도 확인

분석 자동화 도구

분석 모델의 기술적 타당성 검토

필요 자원, 상호 운용성, 시장 성숙도, 기술적 위험 분석 측면에서 타당성 조사

분석 모델의 기술적 타당성 검증 절차

1. 성능 및 용량산정 적정성
2. 시스템 구현시 요구되는 시스템 자원 식별
3. 시스템 간 상호 운용성구체적 정보의 존재 여부, 생성 가능성, 교환 방식 지원 등에 대해 확인
4. 시스템 간 상호 정보 및 서비스 교환 가능성 검토
5. IT 시장 성숙도 및 트렌드 부합성
6. 분석 모델이 트렌드에 부합하는지 확인
7. 기술적 위험 분석추가적 비용 발생 가능성 확인
8. 특정 업체 기술, 특허, 라이선스 의존여부 파악
9. 시스템 기술 구조, 프레임워크, 사용되는 하드웨어 소프트웨어와 부합하는지 확인

요구사항 관리 도구 (IBM Rational DOORS)

서버, 클라이언트 구조로 요구사항을 중앙집중식으로 관리

주요 기능 및 특장점

• Drag&Drop을 통한 추적성 연결
• 의심 링크를 통한 영향 분석
• 요구사항 추적표를 통한 추적성 누락 여부 확인
• 요구사항 변경 이력 관리 및 복원
• 기준선 생성, 조회, 복사, 비교 가능

요구사항 관리 도구의 주요 기능

• 프로젝트 생성
• 요구사항 작성
• 요구사항 불러오기, 내보내기
• 요구사항 이력 관리
• 요구사항 베이스라인 생성
• 요구사항 추적성 관리
• 협업 환경
• 외부 연동 환경
• 확장성

화면 설계

UI 요구사항 확인

UI 표준

UI의 활용

UI 흐름의 이해

UI의 세 가지 분야

• 정보 제공과 기능 전달을 위한 물리적 제어 분야
• 콘텐츠의 상세적 표현과 전체적 구성에 관한 분야
• 사용자의 편의성에 맞춰 쉽고 간편하게 사용 가능하게 하는 기능적 분야

UI의 설계 원칙

• 직관성
• 유효성
• 학습성
• 유연성

UI 스타일 가이드 정의

UI 표준에 맞춰 기본 화면 구조, 액션 인터페이스, 화면 배치, 일반 UI 내비게이션 표준 방식, 화면 구성 요소, 업무별 화면 샘플, 메시지 창, 버튼 목록 배치, 데이터 포맷을 확인

1. 구동 환경 정의
   • 컴퓨터 운영체제 확인
   • 웹 브라우저 확인
   • 모니터 해상도 확인
   • 프레임 세트 확인
   • 
2. 레이아웃 정의
   • 상단 메뉴 구성 : 시스템 전체 페이지에서 동일하게 적용
   • 
   • 좌측 메뉴 구성 정의 : 선택적으로 적용, 서브메뉴, 배너로 구성
   • 내용 구성 정의
   • 하단 메뉴 구성 정의
     
   • 사용 환경에 따른 페이지 Width Size
3. 화면구조 : 일반적으로 Top, Left, Content 3개 부분으로 설계
4. 메뉴 내비게이션 정의
5. 
6. 모듈 뷰의 정의
   • 분할 타입
   • 
   • 사용 타입
   • 
   • 일반화 타입
   • 
   • 레이어 타입
   • 
7. 효과적인 모듈의 분리를 위해 응집력은 최대화하고 결합도는 최소화 해야 한다.
8. 기능 정의
   • 프로세스 모델링업무 기능 정의, Process 분해, 하위 프로세스 인터페이스 정의 등의 작업 수행
   • 업무 기능 모델을 정의한다.
   • 데이터 모델 정의
   • 적용할 업무 영역에 필요한 데이터 엔티티를 식별하고 정의,
     이를 기반으로 데이터 엔티티 및 엔티티 간의 관계를 논리적 데이터 모델로 정의
9. 시스템 요구사항에 대한 개념 모델을 논리적 모델로 상세화
10. 그리드 정의
    
11. 테이블 형태로 UI를 구성하는 방법
12. 버튼 정의
    • 기능 버튼 정의 : 화면마다 공통적으로 사용, 화면 전체에 영향을 미친다.
    • 검색 버튼 정의
    • 그리드 관련 버튼 정의
    • 기타 버튼 정의

UI 패턴 모델 정의

CRUD를 기반으로 데이터 입출력을 처리하는 화면 플로우를 포함해 오퍼레이션 방식에 대한 표준 절차를 표시

UI 패턴 모델을 개발 표준 프레임워크로 개발
유스케이스를 이용해 패턴별 표준 개발 방법을 정의

1. 업무 화면 클라이언트 정의
   • 리치 클라이언트 : 클라이언트 단에서 연산 수행
   • 씬 클라이언트 : 서버 단에서 연산 수행
2. 클라이언트 UI는 리치 클라이언트, 씬 클라이언트 방식이 대표적으로 사용된다.
3. 서버 컨트롤러 정의
4. 서버 메시지 및 예외 처리 정의
5. 
6. 클라이언트 - 서버 간 데이터 변환 정의
7. EP 연계 정의
8. 보고서 정의
9. 씬 클라이언트에 외부 컴포넌트 연계 정의

UI 표준 수립을 위한 조직 구성

• 조직 구성 및 역할 정의
• 커뮤니케이션 방안 수립

UI 표준을 위한 환경 분석

사용자 트렌드 분석

기능 및 설계 분석

• 기능 조작성에 대해 분석
• 오류 방지에 대해 분석
• 최소한의 조작으로 업무처리가 가능한 형태 확인
• UI의 정보 전달력 확인

UI 지침

UI의 설계 지침

• 사용자 중심
• 일관성
• 단순성
• 결과 예측 가능
• 가시성
• 표준화
• 접근성
• 명확성
• 오류 발생 해결

UI 요구사항 정의

품질 요구사항

품질 요구사항 특성

• 기능성
  • 적절성
  • 정밀성
  • 상호 운용성
  • 보안성
  • 호환성
• 신뢰성
  • 성숙성
  • 고장 허용성
  • 회복성
• 사용성
  • 이해성
  • 학습성
  • 운용성
• 효율성
  • 시간 효율성
  • 자원 효율설
• 유지보수성
  • 분석성
  • 변경성
  • 안정성
  • 시험성
• 이식성
  • 적용성
  • 설치성
  • 대체성

UI 요구사항 확인

기능적 요구사항

• 시스템의 입력
• 시스템의 출력
• 시스템이 저장하는 데이터
• 시스템이 수행하는 연산
• 기타 요구사항 (동기화 등)

비기능적 요구사항

• 품질에 관한 요구사항
• 시스템 환경에 관한 요구사항
• 프로젝트 계획에 관한 요구사항

개발하고자 하는 응용 소프트웨어에 적용될 UI 요구사항 확인

비즈니스 요구사항 확인

• 목표 정의
• 활동 사항 정의
• 인터뷰 진행

요구사항 작성

• 요구사항 요소 확인
  • 데이터 요구
  • 기능 요구
  • 제품, 서비스의 품질
  • 제약사항
• 정황 시나리오 작성
  • 이상적인 시스템 작동에 초점을 맞춤
  • 사용자가 주로 사용하는 기능 위주로 작성
  • 정리된 리스트를 기반으로 사용자의 관점에서 서술
  • 작성된 시나리오는 외부 전문가, 경험이 풍부한 사람에게 검토 의뢰

스토리보드

스토리보드의 이해

디자이너와 개발자가 최종적으로 참고하는 산출 문서

정책, 프로세스 및 콘텐츠 구성, 와이어프레임, 기능에 대한 정의, 데이터베이스의 연동 등의 정보가 수록 된 문서

스토리보드 작성 기법

1. 메뉴 구성도 만들기
2. 스타일 확정
3. 설계하기

UI 프로토타입 이해

프로토타입의 의의

요구사항을 반영하고 최종적인 시제품을 완성하기 위해 반복적으로 수행되어야 하는 단계

프로토타입의 활용

고객을 설득하고 이해를 돕기 위해 UI 프로토타입을 만든다.

기술적 검증을 위해 프로토타입을 만드는 경우도 있다.

프로토타입은 최대한 간단히 만든다.

UI 프로토타입 상세

UI 프로토타입 전략

확정된 요구사항을 기반으로 UI 전략을 실체화하는 과정

UI 디자인 작성 이전에 미리 화면을 설계하는 단계

UI 프로토타입 작성 시 고려할 사항

• 프로토타입 계획 작성
• 프로토타입 범위 확인
• 프로토타입 목표 확인
• 프로토타입 기간 및 비용 확인
• 프로토타입 산출물 확인
• 프로토타입 유의사항 확인

UI 프로토타입 계획 시 고려할 사항

• 프로토타입 목표 확인
• 프로토타입 환경 확인
• 프로토타입 일정 확인
• 프로토타입 범위 확인
• 프로토타입 인원 확인
• 프로토타입 아키텍처 검증 확인
• 프로토타입 이슈 및 해결
• 프로토타입 가이드 확정
• 프로토타입 개발 생산성 확인
• 프로토타입 결과 시연

UI 프로토타입 제작, 검토하기

응용 소프트웨어 개발을 위한 UI 표준 및 지침에 의거하여, 소프트웨어 아키텍처 설계 원리 확인

UI 설계 원리를 바탕으로 프로토타입 유스케이스 작성

• 유스케이스 개요 작성
• 액터 정의
• 이벤트 흐름 작성
• 기본 사항 작성
• 추가 사항 작성
• 처리 내용 작성

UI 요구사항을 반영한 프로토타입 제작

1. UI 프로토타입 제작 단계 숙지
   1. 사용자 요구사항 분석
   2. 도출된 요구사항을 충족하는 프로토타입을 핵심적 기능을 중심으로 제작
   3. 개발된 프로토타입을 사용자가 실제로 사용하여 요구사항이 잘 수행되고 있는가를 확인
   4. 프로토타입의 결과를 토대로 수정과 합의
2. 프로토타이핑 작성
   • 페이퍼 프로토타이핑
   • 디지털 프로토타이핑
3. 페이퍼 프로토타이핑 수행화면에 표현되는 각 요소 설계
4. UI 요구사항을 바탕으로 각 화면 구조 구상
5. 디지털 프로토타이핑 수행
6. 디지털 프로토타입을 바탕으로 HTML 기반 디지털 프로토타이핑 상세 수행

작성한 프로토타입을 활용하여 UI/UX 엔지니어와 향후 적용할 UI의 적정성에 대해 검토

실행 차를 줄이기 위한 UI 적정성 확인

• 사용 의도 파악
• 행위 순서 규정
• 행위의 순서대로 실행

평가 차를 줄이기 위한 UI 적정성 확인

UI 설계

감성공학

UI/UX 개념 이해

UI의 형태

• 명령행 기반
• 메뉴 기반
• GUI

WIMP : Window, Icon, Menu, Pointer

GUI의 대표적인 형태

UX

사용자가 시스템, 제품, 서비스를 이용하면서 느끼고 생각하는 총체적 경험

UX의 영역

인터랙션 디자인, 사용성, 정보 구조, 인간공학등 여러 분야를 포괄한다.

UX 영역이 모호한 이유

• 주관성 : 인간의 경험은 주관적
• 맥락성 : 경험이 일어나는 상황 외적 환경의 영향을 받음
• 총체성 : 경험 시점에 개인이 느끼는 총체적인 심리

UX와 UI 비교

• UI경험보다 기능이 중요시되는 상황이나 장치에서 중요시 된다.
• 사용성, 접근성, 편의성을 중시
• UXUI가 조금 복잡해도 매번 이용 시에 몰입할 수 있는 매력을 지니게 되면, UI의 불편함을 불식시킬 정도로 더 중요시 된다.
• UI를 통해 사용자가 느끼는 만족이나 감정을 의미

UI/UX의 구성 요소

UI/UX 개발 프로세스

UI 개발 프로세스

사용자의 요구를 반영한 화면을 설계하는 것을 주요 활동으로 한다.

UX 개발 프로세스

탐색→정의→개발→산출 단계를 거치는 더블 다이아몬드 형태의 프로세스 패턴을 거친다.

• 더블 다이아몬드 모델
• 
• 탐색
  • 조사
  • 분석
  • 리서치
• 정의
  • 사용자 관련 정의 : UI 목표, 사용성 목표를 정의
  • 마케팅 관련 정의 : SWOT, 4P분석 등 마케팅 분석 수행, 제품/서비스에 대한 시장 포지셔닝, 시장 세그멘테이션 설정
  • 분류 : 탐색 결과에 따라 사용자 및 제품 서비스가 제공하는 기능을 분류
• 탐색 단계에서 얻어진 결과들로부터 인사이트를 도출
• 개발
  • 발상
  • 프로토타이핑
  • 시나리오 작성
  • 정보 시각화
• 산출
  • 사용 평가
  • 기준 평가
• 설계 결과물에 대한 완성도를 높이기 위해 결과물을 평가

사용자 라이프스타일 분석

AIO 분석

활동(Activity), 관심(Interest), 의견(Opinion)을 기준으로 분류

장단점 : 시장에 대해 풍부한 정보를 주는 바면 세분화의 경계가 모호하여 측정이 어렵다.

필드리서치를 통한 라이프스타일의 관찰과 분석

특정한 사용자에 대해 장기간 포괄적 관찰을 하는 방법

사용자에 대한 깊은 이해가 가능하나 상대적으로 소수인 특정 사용자 집단에 대해 오랜 시간을 투여해야 한다.

• 과제 중심 필드리서치
  • 제품/서비스를 접하게 된 경로 및 이용 동기 조사
  • 제품/서비스를 시용하는 일상적인 행태 조사
  • 제품/서비스에 대한 사용 평가
• 사용자에게 제품/서비스와 관련된 과제를 부여하여 사용자를 관찰하고 그 결과를 수집하여 니즈를 파악
• 장소(맥락) 중심 필드리서치
  • 맥락과 제품/서비스 간의 관계 파악
  • 제품/서비스가 갖는 평균적인 문제점 파악
  • 구매관찰 분석
  • 피실험자에게 노출되지 않은 상태에서 관찰을 수행하는 조사 방법
• 제품/서비스가 맥락(장소, 시간)과 어떠한 관계를 가지고 사용되는지를 중심으로 특정한 맥락에서의 불특정 사용자를 관찰하는 방법

사용자 니즈 분석

사용자 니즈의 특징

표면적인 사용자 니즈의 이면에는 사용자 경험을 좌우하는 일정한 범주들이 자리잡고 있다.

직접적으로 드러난 것도 있지만 말하지 못하거나 숨겨진 것도 있을 수 있다.

사용자들의 니즈를 제대로 파악하기 위해서는 그들의 전반적인 경험의 파악이 필요하다.

숨겨진 니즈까지 명확하기 규명하기 위해서는 이용동기, 태도, 이용행태에 대한 분석이 필요하다.

요구사항

요구사항은 사용자 차원에서 추상적으로 기술되는데 이를 시스템 차원에서 상세적으로 명세화하는 과정을 거쳐 식별된다.

사용자 니즈 분석 기법

사용자 니즈는 더블 다이아몬드 모델의 확산 단계에 헤당하는 탐색단계에서 아래와 같은 기법들을 적용하여 조사된 결과를 분석하여 도출한다.

• 설문조사
• 다이어리 스터디
• 사용자가 카메라, 비디오 등으로 자신의 일상, 행동, 주변 환경을 스스로 촬영해 기록한 다이어리를회수해 분석하는 기법
• 포커스 그룹 인터뷰
• 주제와 관련해 공통된 특성을 가지고 있는 구성원들로 구성된 소수의 그룹이 개방된 토의를 진행하고 그 결과자료를 분석하는 방법
• AIO분석
• 시장을 동질적인 하나의 집답이 아닌 이질적인 하위집단으로 이루어진 것으로 보고 이를 세밀하게 다룬 것
• 시나리오 분석
• 사용자들의 생활 행태와 예상되는 제품/서비스의 사용 환경의 상황을 시나리오로 기술해 잠재된 니즈를 파악하는 방법
• 관찰법관찰법에서 실험자들은 실험당하고 있다는 것을 의식해 의도적으로 바람직한 답변이나 실험자가 원하는 반응을 하는 경향이 있다.
• 사용자 설문, 사용자 고용, 모의 실험등의 방법은 특정한 실험체계 내의 제한된 인위적 변수만을 고려한다는 제약을 가진다.
• 과업 분석
• 사용자가 실제 주어진 일을 어떻게 수행하는지를 관찰하는 방법

UI/UX 트렌드 분석

UI/UX 트렌드의 이해

트렌드 읽기

• 기사 검색, 동향자료
• 프로젝트 관련 자료
• 신문, 잡지, 책, 보고서, 전시, 세미나에서 소개되는 자료

주변 사용자 경험

사용자를 둘러싼 환경의 연동이 유기적으로 이루어져 하나의 경험을 제공하는 것

UI/UX 시각적 디자인 요소와 관련된 최근 트렌드

• 플랫 디자인
• 고스트 버튼
• 패럴랙스 스크롤링
• 반응형 웹 디자인
• 카드 디자인
• 풀 이미지/영상 배경

트렌드 리포트 작성

트렌드의 파악

• 사용자 니즈 파악
• 사용자 니즈를 반영하기 위한 UI/UX 콘셉트 도출
• UI/UX 트렌드 조사
• 콘셉트에 부합하는 트렌드 적용
• 적용 결과에 대한 평가 및 개선의 반복
• 최종적인 반영

트렌드 적용 기획서 작성하기

1. UI/UX 콘셉트에 대한 재검토 수행
2. UX/UX 트렌드 및 적용 사례 조사
3. UI/UX 콘셉트에 부합하는 트렌드 선별
4. 트렌드 적용 결과 이미지 작성
5. 트렌드 적용 기획서 작성
   • UX/UX콘셉트
   • 선정된 트렌드들과 선정 사유
   • 전 단계에서 작성된 이미지들
   • 트렌드 적용 후 예상되는 효과에 대한 설명
6. 포함내용
7. 기획서 발표 및 토의 진행
   • UI/UX 콘셉트는 서비스 기획서에서 예상한 사용자에게 부합한가
   • 반영된 트렌드는 UI/UX 콘셉트에 부합한가
   • 트렌드들의 선정 사유는 적절한가
   • 트렌드를 반영한 효과에 대한 예상은 적절한가?
   • 발표팀이 예측하지 못한 제약에 대한 의견
   • 수행내용 진행에 대한 소감
   • 기타 의견, 소감
8. 중점사항

제품/서비스/요소 기술 분석하기

제품 분석

3C 분석

동일한 고객을 대상으로 경쟁하고 있는 자사와 경쟁사를 비교, 분석함으로써 자사의 차별화와 경쟁 승리/우위 확보 전략을 찾아낸다.

• 자사 : Corporation
  • SWOT 분석 등을 활용하여 자사의 시장에서의 강약점을 분석한다.
• 고객 : Customer
  • 고객의 범위를 정의하여 대상시장을 명확히 한다.
  • 고객이 원하는 것에 대한 정확하고 객관적인 판단을 통해 새로운 서비스방안을 예측한다.
• 경쟁사 : Competitor
  • 시장의 경쟁상황을 이해한다.
  • 자사와 경쟁사의 시장에서의 유불리를 분석하고, 이의 변화를 파악한다.

SWOT 분석

기업의 환경 분석을 통해 강점, 약점, 기회, 위협 요인을 식별/규정하고 이를 토대로 시장에서의 전략을 수립하는 기법

• 강점 : Strength
• 약점 : Weakness
• 기회 : Opportunity
• 위협 : Threat

SWOT 분석에 따른 전략 수립

• SO전략 : 시장의 기회를 활용하기 위해 강점을 사용하는 전략을 선택
• ST전략 : 시장의 위협을 회피하기 위해 강점을 사용하는 전략을 선택
• WO전략 : 약점을 극복함으로써 시장의 기회를 활용하는 전략을 선택
• WT전략 : 시장의 위협을 회피하고 약점을 최소화하는 전략을 선택

4P

효과적인 마케팅을 위한 상품(Product), 가격(Price), 장소(Place), 홍보(Promote) 네 가지 핵심 요소를 의미

네 가지 핵심 요소를 어떻게 잘 혼합하느냐에 따라 마케팅 효과를 극대화할 수 있다.

포지셔닝

잠재고객의 마인드에 자기 자신을 차별화하는 방식

특성, 편리함, 신뢰도, 혁신성 등 제품/서비스의 무형의 이점들이 제품을 차별화 해 주는 요인이 된다.

포지셔닝의 용도

수집된 이미지를 키워드를 중심으로 분포하여 이미지 간의 차이를 쉽게 이해할 수 있도록 표현하는 방법

클라이언트사와 경쟁사 간의 상관관계와 차이점을 분명히 하는 데 주로 사용된다.

포지셔닝 전략

1. 소비자 분석
2. 제품의 경쟁사 점검
3. 경쟁사의 제품이 어떤 포지션을 차지하고 있는지 분석
4. 자사 제품의 포지셔닝을 결정
5. 리포지셔닝, 소비자와 시장 분석을 통해 제품의 포지셔닝을 조정

서비스 분석

일반적인 구분

물질적인 형태의 유무에 따라 유형의 것을 제품, 무형의 것을 서비스라고 구분한다.

서비스는 물질적인 형태가 없고, 그 부가가치의 모습을 직접 결과물로 관찰할 수 없으며 일정한 기간에 걸쳐서 부가가치가 완성되고 판매된다.

정보기술과 관련한 구분

고객이 구매 후 설치하여 소유권을 갖고 사용하는 형태의 프로그램을 제품,
인터넷을 기반으로 하며 고객이 가입하여 소유권 없이 사용권만을 가지고 제공되는 편익을 이용하며 사용에 따라 과금이 이루어지는 경우 서비스로 구분한다.

4C

콘텐츠(Content), 커뮤니케이션(Communication), 커머스(commerce), 커뮤니티(Community)

인터넷 비즈니스와 관련한 마케팅의 전략적 요소를 의미한다.

웹사이트 운영업체들은 고객들에게 더 나은 4C서비스를 제공하는 것을 전략으로 한다.

4C는 상호 보완적이다.

커넥션(Connection), 커스토마이제이션(Customization)을 추가하여 6C라고도 한다.

UI 흐름 설계

UI 흐름 설계

UI 설계서 구성에 따른 작성 방법

• UI 설계서 표지
• UI 설계서 개정이력
• UI 요구사항 정의
• 시스템 구조
  • UI 프로토타입을 재확인
  • UI 요구사항들과 UI 프로토타입에 기초해 UI 시스템 구조를 설계한다.
  • 사이트 맵을 구성한다.
  • UI 시스템 구조의 내용을 사이트 맵의 형태로 작성한다.
  • 사이트 맵 상세 내용을 표 형태로 작성한다.
• 프로세스 정의
• 화면 설계
• UI 프로토타입과 UI 프로세서 정의를 참고해 각 페이지별로 필요한 화면을 설계한다.

UI 화면 설계의 기본 구성 요소

• 윈도우
• 메뉴
• 아이콘
• 포인터

유용성

유용한 시스템을 설계할 때 고려사항

사용자가 시스템 구조, 기능, 가치 등에 대해 가지고 있는 사용자 모형과 시스템 설계자가 만들고자 하는 개발자 모형 사이의 차이를 최소화하려는 노력이 필요하다.

실행 차를 줄이기 위한 UI 설계 원리

• 사용 의도 파악
• 행위 순서 규정
• 행위의 순서대로 실행

평가 차를 줄이기 위한 UI 설계 원리

• 수행한 키 조작의 결과를 사용자가 빠르게 지각하도록 유도
• 키 조작으로 변화된 시스템의 상태를 사용자가 쉽게 인지하도록 유도
• 사용자가 가진 원래 의도와 시스템 결과 간의 유사 정도를 사용자가 쉽게 파악하도록 유도

UI 흐름 설계하기

유용성을 적용한 UI 설계안의 적정성 확인

• 실행 차를 줄이기 위한 UI 설계 원리를 확인
• 평가 차를 줄이기 위한 UI 설계 원리를 확인

UI 요구사항과 UI 표준 및 지침에 따라, 화면과 폼의 흐름을 설계한다.

1. 화면에 표현되어야 할 기능을 작성한다.
2. 화면의 입력 요소를 확인한다.
3. 유스케이스를 통한 UI 요구사항을 확인한다.
4. UI 유스케이스를 설계한다.
5. 기능 및 양식을 확인한다.

UI 상세 설계

UI 시나리오 작성 원칙

• UI의 전체적 기능과 작동 방식을 개발자가 한 눈에 쉽게 이해할 수 있도록 구체적으로 작성한다.
• 모든 기능은 공통 적용이 가능한 UI 요소와 인터랙션을 일반적인 규칙으로 정의한다.
• 대표 화면의 레이아웃과 그 화면들 속의 기능을 정의한다.
• 인터랙션의 흐름을 정의하며, 화면 내와 화면 간 인터랙션의 순서, 분기, 조건, 루프 등을 명시한다.
• UI 일반 규칙을 지키면서 기능별 상세 기능 시나리오를 정의한다.
• UI 시나리오 규칙을 지정한다.

UI 시나리오 문서 작성 요건

• 완전성
• 일관성
• 이해성
• 가독성
• 수정 용이성
• 추적 용이성

모범적인 UI 시나리오 문서의 효과

• 요구사항 오류 감소
• 의사소통 오류 감소
• 개발 과정에서의 재작업 감소, 혼선 최소화
• 불필요한 기능 최소화
• 시나리오 작성, 소프트웨어 개발시 비용 절감
• 개발 속도 향상
• 유관 부서 만족도 제고

애플리케이션 설계

공통 모듈 설계

설계 모델링

공통 모듈

공통 모듈에 대한 명세 기법

• 정확성
• 명확성
• 완전성
• 일관성
• 추적성

모듈의 재사용

재사용 규모에 따른 분류

재사용을 위해 필요한 항목

재사용 관련 내용이 이해하기 쉽고 사용법이 공개되어야 한다.

결합도는 적어야 하며, 응집도는 높아야 한다.

유스케이스의 포함과 확장 관계

유스케이스의 구성 요소 간 관계는 연관, 확장, 포함, 일반화, 그룹화 등이 있으며 기능 수행 시 반드시 포함하거나 선택적으로 수행할 수 있는 관계를 점선으로 표시한다.

유스케이스의 포함과 확장

공통 모듈 식별 및 명세

1. 전체 시스템 차원과 단위 시스템 차원의 공통 부분을 식별
2. 
3. 단위 시스템의 업무 기능을 분석하여 공통 부분을 식별
   • 업무 기능 정제
   • 업무 기능 누락 및 중복 여부 검토
   • 업무 기능 중 공통부분 식별
   • 
4. 유스케이스를 분석하여 공통 부분을 식별
5. 

공통 모듈 설계

모듈화

시스템을 분해하고 추상화함으로써 성능을 향상시키거나 시스템의 수정, 재사용, 유지 관리를 용이하게 하는 기법

모듈화 필요성

모듈 개수가 많아지면 모듈 간의 통합 비용이 많이 들고 모듈의 크기가 너무 크면 통합 비용이 줄어드는 대신 모듈 하나를 개발하는 데 드는 비용이 커진다.

모듈 개수 및 비용 간 상관관계

공통 기능 모듈화 사례

복잡한 계산식, 자주 사용하는 검증, 연관되어 발생하는 조건식에 대한 입력값 검증 등의 경우 공통 모듈로 구성하여 재사용성을 높일 수 있다.

응집도

응집도가 높을수록 필요한 요소들로 구성되어 있고 낮을수록 관련이 적은 요소들로 구성되어 있다

응집도의 유형 및 설명

응집도와 품질

결합도

모듈과 모듈 간에 어느 정도 관련성이 있는지를 나타낸다.

결합도의 유형 및 설명

결합도와 품질

공통 모듈 설계 진행

공통 기능에 대한 흐름을 도식화

• 레이어별로 흐름 표시
• 클래스 및 메소드 명명 규칙 준수

공통 기능에 대한 화면 설계 진행

• 화면 레이아웃 설계
• 화면 항목에 대한 내용 작성
  
• 화면 항목 및 작성 내용
• 관련 이벤트 항목 작성
  
• 화면 이벤트 및 작성 내용
• 관련 파일 항목 작성

공통 기능에 대한 프로그램 설계서 작성

• 클래스에 대한 설계서 작성
  
• 클래스 설계서 작성 항목 및 내용
• 메소드에 대한 설계서 작성
  
• 메소드 설계서 작성 항목 및 내용
• 프로그램 설계서 작성
• 공통 기능에 대한 쿼리 설계

공통 배치 프로그램 설계

배치 프로그램 설계서 작성 항목 및 내용

1. 배치 수행 방법 검토
2. 선행 조건 및 입력물 검토
3. 작업 주기 및 소요 시간 설계
4. 출력물 검토

공통 모듈에 대한 응집도와 결합도 분석 후 분리/병합

1. 공통 모듈에 대한 응집도 분석
2. 공통 모듈에 대한 결합도 분석
3. 응집도와 결합도 분석 결과에 따라 공통 모듈에 대한 분리 및 병합 작업 진행
4. 팬인/팬아웃을 분석하여 복잡도 조절팬인이 높은 경우 중점 관리 및 많은 테스트를 통한 검증 필요팬아웃이 높은 경우 불필요한 기능을 호출하고 있지 않은지 검토 진행, 업무로직 단순화 방안 검토
5. 팬아웃 : 자신이 사용하는 모듈의 수
6. 팬인 : 자신을 사용하는 모듈의 수

공통 모듈 인덱스 및 기능 코드 설계

코드의 기능

• 식별
• 분류
• 배열
• 기타

코드의 유형 분류

코드의 유형

인덱스의 개념

데이터베이스에서 사용하는 경우 인덱스가 존재하면 모든 블록의 데이터를 조회하지 않고 색인화된 인덱스 파일을 검색하여 검색 속도를 향상시킬 수 있다.

공통 모듈 인덱스 방법

공통 모듈을 유일하게 식별할 수 있는 번호 체계를 부여함으로써 공통 모듈에 대한 그룹화와 식별 및 정보 추출을 용이하게 하는 기법

각 단위 시스템에 대한 코드를 설계하고, 공통 기능은 별도의 코드를 부여한 후 해당 코드를 기준으로 인덱스 번호를 추가한다.

소프트웨어 아키텍처

소프트웨어 아키텍처 정의와 조망도

아키텍처 수준의 관점

지나친 상세 내역은 고려하지 않으며 핵심이 되는 소프트웨어 모듈을 식별

컴포넌트 간의 통신 식별

여러 서브 시스템의 올바른 역할과 책임 명시

아키텍처 역할

시스템 상의 모든 중요 인터페이스 특성 식별, 결정을 도움

특정 하드웨어 의존이 높을 경우 기술

분산 시스템의 경우 최소, 평균 시스템 구성을 고려해야 함

특정 알고리즘이나 데이터 구조가 전체 설계에 영향을 미친다면 기술

조망도

개념 조망도

시스템에서 중요 부분과 상호연결을 보여준다.

구현 조망도

실제로 구현된 모듈을 가지고 제시된다.

프로세스 조망도

시스템의 동적인 구조를 Task, 프로세스, 통신으로 보여준다.

배치 조망도

분산 시스템에서 물리적인 노드에 Task를 어떻게 할당하는지 보여주기 위해 사용된다.

소프트웨어 아키텍처와 코드 설계

소프트웨어 아키텍처

최초로 수행되는 시스템 설계 규격서를 미리 만들어 검증하는 첫 번째 기회

소프트웨어 아키텍처가 사용되는 곳

• 검증
• 의사소통
• 구별

컴토넌트와 연결

• 컴포넌트
• 각각의 컴포넌트는 명료적이고 논리적인 단위로 식별되어야 함
• 연결
• 아키텍처는 컴포넌트 사이의 연결을 모두 식별하고 그 연결의 특성에 대해 기술해야 함

좋은 아키텍처의 조건

• 단순하며 이해하기 쉬워야 함
• 몇 개의 모듈을 선택하여 현명한 의사소통 통로를 만드는 것이 목표
• 너무 많은 컴포넌트로 구조를 불분명하게 만들지 말아야 함
• 모듈의 내부 작업까지 지시하지 않는다.
• 결합도는 낮고 응집력은 높은 모듈을 만들어야 함
• 확장성이 있어야 함

아키텍처의 필요성

• 데이터 표현, 알고리즘, 요구 기능의 변경에 대한 탄력성
• 모듈을 나누는 방법과 연결하는 방법
• 이해의 용이성
• 성능 요구사항의 수용 능력
• 컴포넌트의 재사용에 대한 고려

아키텍처의 종류

• 계층 아키텍처
• 하나의 스택에서 컴포넌트를 벽돌처럼 쌓아 표현한 것
• 파이프와 필터 아키텍처
• 논리적인 흐름을 모델화한 것
• 클라이언트/서버 아키텍처
• 전형적인 네트워크 기반 아키텍처
• 컴포넌트 기반 아키텍처
• 객체지향 접근 방법. 시스템을 몇 개의 컴포넌트로 나누어 처리
• 프레임워크
• 기존에 있는 애플리케이션의 프레임워크를 추가

아키텍처를 고려한 타 시스템 연동 설계

시스템 연동

동일한 기능을 수행하지 않는 단위 시스템 간에 접속을 통하여 업무를 수행하는 것

데이터 연동

데이터베이스를 공유하여 타 시스템과 연계하는 방법

인터페이스 연동

인터페이스 : 서로 독립적인 시스템의 상호 작용을 위한 접속 경계, 규칙
원격 메소드 호출등을 통해 타 시스템과 연동

인터페이스 변경시 해당 인터페이스를 사용하는 다른 시스템에 대한 영향 범위확인이 필요, 인터페이스에 대한 표준화, 연계 목록 및 방식, 처리 내용 등에 대한 지속적인 현행화, 관리, 모니터링 수행 필요

웹 서비스 연동

네트워크상에서 이기종 시스템 간에 표준화된 XML 메시지 및 여러 기술을 이용하여 시스템 간에 연동할 수 있는 기술

웹 서비스 구성도

미들웨어 솔루션 명세 작성

미들웨어 솔루션 개념

클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어 또는 컴퓨터와 컴퓨터의 연결을 담당하는 소프트웨어

미들웨어 솔루션의 유형

타 시스템 연동 목록 작성을 위한 가이드라인 포함 항목

웹 서버와 웹 애플리케이션 서버

웹 서버

웹 브라우저의 요청을 받아 html, 이미지, js의 정적인 콘텐츠를 제공

웹 애플리케이션 서버

서버단에서 애플리케이션이 동작할 수 있는 환경을 제공, 안정적인 트랜잭션 처리 및 관리, 이기종 시스템 간의 애플리케이션 연동을 지원

웹 서버와 WAS 서버의 일반적 구성

정적 데이터는 웹 서버가 처리, 동적 콘텐츠의 경우 WAS로 서비스 요청

오류 예측 및 대응 방안 제시

가용성 향상을 위한 이중화

• 액티브-액티브 방식
• 평상시에도모든 서버가 서비스 제공
• 액티브-스탠바이 방식
• 장애 발생시 다른 서버로 서비스를 이관하여 연속적인 서비스 제공

재해 복구 시스템

재해 복구 시스템의 복구 수준별 유형

복구 목표 시간과 복구 목표 시점

한정된 비용 안에서 데이터 유실 및 다운 타임에 대한 위험을 최소화하기 위한 항목

복구 목표 시간 : 다운타임에 대한 최대 허용 시간

복구 목표 시점 : 데이터 유실에 대한 최대 허용 가능 시점

업무 영향 분석

수행 절차

1. 업무 분류 체계 정의 및 주요 업무 프로세스 식별
2. 각 서비스별 업무 상관관계 분석 및 장애 발생 시 손실 비용 분석
3. 서비스 중요도에 따른 복구 대상 및 우선순위 도출
4. 주요 서비스별 복구 목표 시간 설정

구성 요소

• 핵심 우선순위 결정
• 서비스 중단 시간 산정

객체지향 설계

객체지향

객체지향 언어의 시초

1. 스몰토크
2. 에이다단점 : 상속의 개념을 언어에 반영하지 않음
3. 장점 : 예외처리 기능의 도입
4. C, C++
5. 초기의 C++는 C에 클래스 개념만 도입된 것이었으나 중복, 상속, 가상함수, 추상 클래스, 예외 처리 등의 기능이 추가되며 향상되었다.
6. JAVA
7. 장점 : 언어의 단순성, 플랫폼의 독립성
8. Objective-C
9. C와 객체지향 언어를 혼합한 언어

OOP 기본 구성 요소

• 클래스
• 객체
• 메소드

특징

• 캡슐화
• 연관된 자료 구조와 함수를 한 개로 묶는 것
• 정보 은닉
• 캡슐화된 객체 내부의 자료구조, 함수의 기능이 외부에 영향을 주거나 받지 않도록 설계하는 방법
• 자료 추상화
• 불필요한 정보는 숨기고 중요한 정보만을 표현함으로 프로그램을 간단히 만드는 것
• 상속
• 새로운 클래스가 기존의 클래스의 자료, 연산을 이용할 수 있게 하는 기능
• 다중 상속
• 클래스가 2개 이상의 클래스로부터 상속받을 수 있게 하는 기능
• 다형성
  • 오버라이딩
  • 오버로딩
• 한 요소에 여러 개념을 넣어놓은 것
• 동적 바인딩
• 실행 중에 일어나거나 실행 과정에서 변경될 수 있는 바인딩

디자인패턴

객체지향 개발 5대 원리 : SOLID

• SRP (단일 책임 원칙)
• 작성된 클래스는 하나의 기능만 가지며 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다는 원칙
• OCP (개방 폐쇄 원칙)적용 방법
  1. 변경될것과 아닌 것을 엄격히 구분
  2. 두 모듈이 만나는 지점에 인터페이스 설계
  3. 구현보다는 인터페이스에 의존하도록 코드 작성
• 소프트웨어의 구성 요소는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다는 원리
• LSP (리스코브 치환 법칙)
• 서브 타입은 기반 타입과 호환될 수 있어야 한다.
• ISP (인터페이스 분리 원칙)하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다.
• 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다.
• DIP (의존성 역전 원칙)
• 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위계 관계를 끊는 의미의 역전

인터페이스 설계

인터페이스 요구사항 확인

내 외부 인터페이스 요구사항

인터페이스 요구사항

시스템 인터페이스 요구사항

네트워크를 통한 시스템 간의 접속으로 특정 기능을 수행하기 위해서는 시스템 인터페이스 설계와 개발이 필수적

시스템 인터페이스 요구사항의 구성

• 인터페이스 이름
• 연계 대상 시스템
• 연계 범위 및 내용
• 연계 방식
• 송신 데이터
• 인터페이스 주기

시스템 인터페이스 요구사항의 분류

• 기능적 요구사항
• 비기능적 요구사항

시스템 인터페이스 요구사항 분석

요구 사항 정의 단계에서 정의한 기능 및 비기능 인터페이스 요구 사항을 상세하게 이해하고, 요구 사항을 분류하고 조직화하여 명세를 구체화하는 작업

요구사항 분석

요구사항 분석 기법

• 요구사항 분류
• 개념 모델링을 통한 요구 기능 분석
• 요구사항 할당
• 요구사항 협상

요구사항 명세서

시스템 개발 작업의 기준선으로 활용될 수 있으므로 요구 사항 확인 및 검증, 비용 추정 등의
작업이 가능하도록 명확하고 완전하게 정의되어야 한다.

요구사항 명세서 작성 시 고려사항

개발하고자 하는 시스템이 어떻게 수행될 것인가가 아닌 무엇을 수행할 것인지에 관한 내용을 기술한 것으로, 시스템이 이루어야 할 목표를 기술한다.

• 요구 사항 명세서는 고객과 개발자가 쉽게 이해할 수 있도록 간결하게 작성해야 한다.
• 내용은 사용자와 개발자가 모두 동의한 것이어야 한다.
• 시스템의 모든 기능과 시스템에 영향을 미치는 모든 제약 조건을 기술한다.
• 원하는 시스템의 품질, 품질 측정과 검증 방법, 인수 테스트 기준 등을 기술해야 한다.
• 우선순위에 따른 중요도를 기술한다.
• 요구 사항을 쉽게 참조할 수 있도록 고유 식별자를 기술한다.

인터페이스 요구사항 명세서 작성 시 고려사항

• 연계 대상 시스템, 연계 범위, 연계 방식, 송수신 데이터, 송수신 주기 등을 명시해야 한다.
• 요구사항 명세서를 통해 인터페이스별 연계 방식, 연계 유형, 연계 주기를 식별할 수 있도록 작성한다.
• 교환되는 데이터에 대한 정보를 식별할 수 있도록 작성한다.
• 인터페이스 구현에 필요한 환경 정보와 기술적 요구사항이 포함되어야 한다.
• 인터페이스와 관련된 송수신 시스템의 업무 담당자와 IT 담당자 정보를 확인할 수 있어야 한다.

인터페이스 요구사항 검증

인터페이스 아키텍처, 인터페이스 데이터 설계를 위해 필요한 정보가 도출되었는지 중점적으로 점검

요구사항 검증 절차

• 요구사항 검토 계획 수립
• 요구사항 명세서 검토, 오류 수정
• 요구사항 베이스 라인 설정

인터페이스 요구사항 검증 항목

요구사항 검토 방법

• 동료 검토
• 요구 사항 명세서 작성자가 요구 사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행
• 워크 스루
• 검토 자료를 회의 전에 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화한다.
• 인스펙션
• 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법

프로토타이핑

테스트 설계

테스트 케이스를 생성하여 추후 요구사항이 현실적으로 테스트 가능한지 검토

CASE 도구 활용

구조화된 요구사항 명세서에 대해서는 자동화된 일관석 분석을 제공하는 CASE 도구를 활용한다.

요구공학

요구공학의 개요

시스템 요구사항 문서를 생성, 검증, 관리하기 위해 수행되는 구조화된 활동의 집합

요구사항 명세를 최종 산출물로 생성

요구공학의 목적

• 이해관계자 사이에 효과적인 통신수단 제공, 요구사항에 대한 공통 이해 설정
• 요구사항 손실 방지 및 에러 감지로 불필요한 비용 절감
• 구조화된 요구사항으로 요구사항 변경 추적을 가능하게 한다.
• 프로젝트 비용 초과와 기간 지연을 방지한다.
• CMM Level 2 달성 또는 비즈니스 수행 방법을 개선한다.
  
• CMM 성숙도 레벨

프로세스 구성

• 요구사항 관리
  • 요구사항 협상 : 가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능 협상
  • 요구사항 기준선 : 공식적으로 합의, 검토된 요구사항 명세서
  • 요구사항 변경관리 : 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통계
  • 요구사항 확인 : 구축된 시스템이 이해관계자가 기대한 요구사항에 부합되는지 확인
• 요구사항 개발
  • 요구사항 추출 : 이해 관계자의 니즈와 시스템 개발시 제약사항을 발견하여 검토하고 명확화하는 이해 과정
  • 요구사항 분석 : 추출된 요구사항을 분석, 구조화하고 각종 대안들을 결정하는 피드백 역할 수행
  • 요구사항 명세화 : 분석 과정에서 선별된 기능 기반으로 구축할 시스템 내부 내역 기술
  • 요구사항 확인(검증) : 요구사항의 승인기준은 문서화, 명확성, 간결성, 이해성, 시험성, 사용성, 추적성, 검증성

요구공학 관리 기법

• 시나리오/목표 기반 요구사항 획득
• 유스케이스를 이용한 요구사항 모델링
• 품질 요구사항을 위한 자동 분류
• 유사도 측정을 이용한 요구사항 변경 관리

인터페이스 대상 식별

시스템 아키텍처

시스템의 구조, 행위, 더 많은 뷰를 정의하는 개념적 모형

시스템 아키텍처 정의

• 시스템 구성 및 동작 원리를 내포
• 시스템 구성 요소에 대한 설계 및 구현을 지원하는 수준으로 자세히 기술
• 구성 요소 간의 관계 및 시스템 외부 환경과의 관계 묘사
• 요구 사양 및 시스템의 전체 수명 주기 고려
• 시스템의 전체적인 최적화를 목표로 함

시스템 아키텍처의 실제적인 정의

• 구체적인 컴퓨터 시스템의 조직과 장기적인 개선 계획
• 설계를 효율적으로 구현하기 위한 기본 원리와 과정
• 시스템 구성 요소들의 정보 전달, 관계, 규칙

인터페이스 시스템 식별

연계 시스템

• 송신 시스템
• 수신 시스템
• 중계 서버
  
• 중계 서버를 포함하는 연계 방식 개념도

연계 시스템 분류 체계와 식별 정보

시스템 분류 체계

기업에서 사용하고 있는 시스템 분류 체계를 기반으로 대내외 인터페이스 시스템 식별자 정의

시스템 분류 체계 예시

연계 시스템 식별 정보

대내외 연계를 위한 송신 시스템과 수신 시스템에 대한 상세 식별 정보

내 외부 연계 시스템 식별 정보 설명

인터페이스 상세 설계

내 외부 송수신

식별 대상 데이터

전문 공통부 : 인터페이스 표준 항목 포함

시스템 공통부 : 시스템 간 연동 시 필요한 공통 정보

거래 공통부 : 연동 처리 시 필요한 직원 정보, 승인자 정보, 기기 정보, 매체 정보, 테스트 정보 등으로 구성

전문 개별부 : 업무 처리에 필요한 데이터 포함

전문 종료부 : 전송 데이터 끝 표시문자 포함

대내외 연계 시 사용하는 공통 코드와 연계 시스템 에서 사용하는 상태 코드, 오류 코드

송수신 전문 구성 예시

데이터베이스 산출물

개체 정의서

개체 정의서 구성 내용

테이블 정의서

테이블 정의서 구성 내용

코드 정의서

코드 정의를 문서화한 것

코드는 데이터베이스에서 유일하게 정의해야 한다.

코드 속성은 속성명 뒤에 코드를 붙여서 구별한다.

코드 정의서 구성 내용

데이터 명세화

연계 방식

직접 연계 방식

장점

연산 속도가 빠르고 구현이 단순하다. 개발 기간이 짧다.

단점

송신 시스템과 수신 시스템 간의 결합도가 높아서 시스템 변경에 민감하다.

암복호화 처리와 비즈니스 로직 구현을 인터페이스별로 해야한다.

간접 연계 방식

장점

다양한 환경을 갖는 시스템들을 연계하고 통합 관리할 수 있다.

인터페이스 변경 시에도 유연하게 대처가 가능하고, 업무처리 로직 반영이 용이하다.

단점

인터페이스 아키텍처와 연계 절차가 복잡하고 테스트 기간이 오래 걸린다.

연계 기술

시스템 연계 기술

통신 유형

인터페이스 통신 유형

데이터 암호화 필수 항목

법률에서 정한 암호화 필수 적용 대상 항목

• 정보통신망 이용 촉진 및 정보 보호 등에 관한 법률
  • 주민등록번호
  • 패스워드
  • 공개에 동의하지 않은 개인 정보
• 전자금융 거래법, 신용 정보의 이용 및 보호에 관한 법
  • 주민등록번호
  • 패스워드
  • 계좌 번호

오류 처리 방안

인터페이스 오류 유형

인터페이스 처리 방법

인터페이스 오류 처리 절차

로그 파일에 오류 코드와 상세 내용을 기록하도록 프로그램 작성

인터페이스 오류 코드

오류 유형별로 오류 코드를 정의하고 시스템에서 공통으로 사용할 수 있도록 표준화된 오류 코드를 공통 코드로 등록

인터페이스 오류 식별

인터페이스 사용 시 발생하는 오류를 식별하고 오류 처리 방안을 명세

• 오류 발생 영역을 구분할 수 있는 발생 영역 구분자를 정의한다.
• 
• 오류 유형을 식별할 수 있는 오류 그룹 번호를 정의한다.
• 

인터페이스 설계

인터페이스 설계서 작성 및 구성

인터페이스 목록

연계 업무, 송수신 시스템 정보, 연계 방식, 통신 유형 등의 정보 포함

인터페이스 목록의 주요 항목

인터페이스 정의서

인터페이스 정의서의 주요 항목

연계 방식에 따른 인터페이스 명세서의 주요 항목

미들웨어 솔루션

미들웨어

커널과 사용자 애플리케이션 사이에 있는 모든 소프트웨어

엔터프라이즈 미들웨어

한 장소에서 다른 장소로 데이터를 운반

데이터베이스 미들웨어

클라이언트에서 원격의 데이터베이스와 연결

RPC 미들웨어

원격 프로시저를 로컬 프로시저 처럼 호출

MOM 미들웨어

비동기형 메시지 처리를 전달

TP-모니터 미들웨어

온라인 트랜잭션 업무에서 트랜잭선을 감시

ORB 미들웨어

객체 지향 미들웨어, 코바 표준 스펙을 구현

WAS 미들웨어

웹 환경을 구현하기 위한 미들웨어