본문으로 건너뛰기

"pe/engineering" 태그로 연결된 32개 게시물개의 게시물이 있습니다.

모든 태그 보기

구조적 방법론, 애자일 방법론

· 약 4분

구조적 방법론, 애자일 방법론 개념

  • 구조적방법론: 전체 시스템을 기능에 따라 분할하여 개발하고, 이를 통합하는 프로세스 중심의 하향식 방법론
  • 애자일방법론: SW개발을 반복적이고 점진적으로 진행하고, 변경에 유연하게 대응하는 방법론

구조적 방법론, 애자일 방법론 구성요소, 주요 기법, 적용방안

구조적 방법론, 애자일 방법론 구성요소 비교

구분구조적 방법론애자일 방법론
접근방식계획중심, 단계적반복적, 유연한 방식, 짧은 개발 사이클
문서화모든 단계에서 상세한 문서화문서보다는 동작하는 SW에 가치
고객 참여프로젝트 초기에 요구사항 정의 후 참여 없음지속적인 피드백과 개선
변경관리변경에 유연하지 않음유연한 변경 수용
개발 속도긴 개발 주기빠른 개발 주기
장점명확한 구조와 규정된 프로세스를 통한 크고 복잡한 프로젝트 적합변화하는 시장 요구사항에 빠른 대응
단점유연성 부족, 계획 변경 어려움문서 부족으로 인한 리스크
주요 기법데이터 흐름 다이어그램, 분할 정복, 정형화스크럼, 칸반, TDD

애자일 방법론의 주요 기법 스크럼, 칸반 비교

구분스크럼칸반
개념고정된 역할과 이벤트를 통한 작업관리시각화를 통한 작업 흐름 관리
특징스프린트, 데일리스크럼, 회고칸반보드, 대기행렬, 총 주기 시간
장점명확한 역할분담, 짧은 주기와 반복작업유연한 작업관리, 지속적인 개선
단점초기적응 어려움역할 불명확, 관리 어려움

개발 방법론 선택시 고려사항

  • 레거시시스템 여부, 팀 성숙도 측면을 고려하여 구조적 방법론과 애자일 방법론 중 선택 필요.

차세대시스템과 오픈결함

· 약 4분

차세대 시스템 오픈관련 문제점 개요

  • 사업 사전준비 부족과 프로젝트 관리 역량 부족 등 미진한 대응으로 대국민 서비스 품질 저하 및 공공기관 신뢰성 저하

오픈 관련 문제점의 원인

기술적 원인

구분문제짐내용
데이터데이터 전환 미흡마이그레이션 후 정합성 문제
-도메인 분석 미흡시스템 통합에 딸느 영향도 파악 부족
기능기능 미구현다양한 유저의 필요 기능 불안전 구현
-개발자 역량개발자의 도메인 지식 부족
시스템테스트 부족시스템 통합 후 미구현 기능 발견
-시스템 검수 미흡성능 요구사항 미준수

관리적 원인

구분문제점내용
요구사항불명확한 요구사항일정 지연 원인
-리스크 관리 부족위험 수집, 판별, 분석, 대응 미흡
제도대기업 참여제한프로젝트 관리 경험 부족
-감리체계 미흡산출물 위주 감리로 실무 괴리
적정대가 미지급불공정한 과업 변경이해관계자 협의 없는 변경
-개발자 이탈핵심인력 중 90% 과업 진행 중 이탈

재발 방지를 위한 대책 및 법,제도 보완점

재발 방지를 위한 대책

구분대책내용
요구사항공공 PMO 활용사업의 성공적 수행을 위한 관리
-사전심사제도과제 진행 전 이슈 분석
적정대가 미지급과업심의위원회심의 의무화로 합의 진행
-RFPFP 기반한 대가 산출
데이터데이터 품질 검증마이그레이션 테스트 계획 수립
-전문가 활용업무 도메인, 데이터 전문가 활용

재발 방지를 위한 법, 제도 보완점

구분보완점내용
발주발주 시행근거 마련발주기관 지표 항목 개선
-분리분할발주 강화사업 규모 따른 관리 위험 완화
사업참여대기업 참여제한 완화프로젝트 관리 경험 증가로 안정성 증가
-컨소시엄 구성 체계 변경동일 사업 참여 컨소시엄 책임 조정
제도감리제도 강화업무 부문 감리 항목 강화
-하도급 제도 개선하도급 관리 기준 개정 효율화
-SW산업 진흥법 개선공공 SW사업 기반 제도 수정

오픈준비 점검지표

ISO 25010 기반

기능 점검지표

  • 적합성
  • 정확성
  • 상호운용성
  • 호환성

성능 점검지표

  • 사용성
  • 신뢰성
  • 유지보수성

요구사항 추출

· 약 3분

요구사항 추출의 개념

  • 시스템, 제품, 서비스를 개발하는 과정에서 이해관계자들의 원하는 바를 파악하고 명확하게 정의하는 활동
  • 프로젝트의 명확한 목표 설정, 이해관계자 만족, 리소스 절감, 리스크 관리를 위해 필요.

요구사항 추출 기법, 품질 속성, 개발 프로세스

요구사항 추출 기법

구분내용비고
인터뷰이해관계자와 직접 대화심층적 정보
설문조사설문지 통한 다수 이해관계자 요구사항 확보효율적, 정량적
브레인스토밍다수가 자유롭게 아이디어 제시창의적 아이디어
프로토타이핑시스템 초기 모델 제작, 사용자 피드백사용자 중심 요구사항
워크숍이해관계자가 모여서 토론, 협의합의 도출 효과
역공학기존 시스템 및 문서 분석숨겨진 요구사항 발견

요구사항 품질 속성

구분내용비고
원자성요구사항이 복합 목적이 아닌 단일 목적인지요구사항 충돌 방지
완전성요구사항이 정보의 모든 것을 포함하는지모든 이해관계자 요구 반영
비모호성명확하지 않거나 같은 내용을 다르게 언급했는지오해소지 제거
추적가능성요구사항을 쉽게 추적가능한 고유번호변경관리 대응
테스트가능성요구사항이 검증가능하게 기술되었는지객관적 기준

요구사항 추출 프로세스

요구사항 추출시 고려사항

  • 제한된 리소스 내에서 효율적인 개발을 위해 우선순위 설정 필요

객체지향 방법론

· 약 3분

객체지향방법론의 개념

  • SW 생명주기에 객체지향 개념을 접목시켜 객체를 중심으로 시스템을 모델링하는 방법론
  • 캡슐화, 추상화, 상속, 다형성과 정보은닉을 통해 복잡성을 줄이고, 재사용성과 유지보수성을 극대화하여 비용 절감

캡슐화, 정보은닉의 개념도, 비교, 적용방안

캡슐화와 정보은닉 개념도

  • 캡슐화(수단)는 정보은닉(요건)을 실현하기 위한 수단으로 활용

캡슐화와 정보은닉 비교

구분캡슐화정보은닉
개념객체의 속성과 메소드를 하나의 단위로 묶는 것객체 내부 구현을 감추는 것
목적응집도와 모듈성 향상내부 상태 보호, 변경용이성 확보
수단접근제어자, 접근메소드접근제어자, 인터페이스
효과모듈화, 재사용성안정성, 유지보수성

캡슐화, 정보은닉 적용방안

구분캡슐화정보은닉
설계단계클래스 책임 분배, 접근제어자모듈화, 추상화, 레이어설계
구현단계getter/setter, 생성자의존성 주입, 디자인패턴

객체지향 프로그래밍 고려사항

  • SOLID 원칙 준수, GoF의 디자인패턴 활용, 낮은 결합도, 높은 응집도를 가진 클래스, 모듈 구현

SRS, 요구사항 명세서

· 약 3분

요구사항 명세서 개념

  • SDLC 전 단계에서 검토, 승인, 평가의 기준이 되는 SW가 갖추어야할 기능, 성능, 제약조건 등이 기술된 명세서
  • 요구사항의 애매모호성을 제거하고, FP가 도출 가능한 수준까지 작성하여 의사소통 비용절감 및 변경관리용이성 증대를 위해 필요.

요구사항 명세서의 구성도, 핵심요소, 활용방안

요구사항 명세서의 구성도

요구사항 명세서 핵심요소

구분내용비고
기능요구사항시스템이 수행할 기능, 제공해야할 서비스 요구사항사용자 관점
성능요구사항시스템 속도, 처리량, 응답시간 등 시스템 성능 요구사항측정가능한 구체적 수치
인터페이스요구사항외부시스템 연동, 하드웨어와 상호작용 방식에 대한 요구사항데이터 포맷, 프로토콜
설계 제약조건시스템 설계, 구현에 제약을 가하는 요소 설명개발환경, 표준 준수

요구사항 명세서 활용방안

구분내용비고
설계시스템 아키텍처, 인터페이스, UI/UX요구사항 충족 설계
구현코딩, 단위테스트 기준기능 요구사항 준수
테스트테스트케이스 설계, 요구사항 검증결함 문서화
유지보수변경관리, 사용자 교육, 개선피드백 반영

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

  • 명확하고 일관된 용어를 사용하여 이해관계자 간 의사소통의 투명성 제고

3R, Reuse, Re-engineering, Reverse-engineering

· 약 3분

3R의 개요

3R의 개념

  • Reuse: 기존에 개발된 SW 자산을 새로운 시스템 개발에 재활용하는 것
  • Re-engineering: 기존 시스템을 분석하여 문제점을 파악하고, 개선된 시스템으로 재구축하는 것
  • Reverse-engineering: 소스코드 없이 실행 파일이나 문서 등을 분석하여 시스템의 구조, 동작 방식 등을 파악하는 것

3R의 필요성

  • 유지보수 비용 절감
  • 개발 생산성 향상
  • 시스템 품질 향상
  • 시스템 이해도 향상

3R의 관계도, 상세설명, 핵심기법

3R의 관계도

3R의 상세설명

구분내용비고
역공학소스 코드 없이 시스템 분석 후 설계 정보 추출분석도구 활용(디버거, 디컴파일러), 설계 문서 복구
재공학기존 시스템 분석 결과를 바탕으로 시스템 개선 및 재구축리팩토링, 아키텍처 개선, 성능 최적화
재사용검증된 소프트웨어 자산을 새로운 시스템 개발에 활용컴포넌트, 디자인패턴, 모듈 재사용

3R의 핵심기법

구분내용비고
정적분석코드 실행 없이 바이트코드, 바이너리코드 분석역공학
리팩토링코드 스멜을 제거하여 단순성을 높히는 방법재공학
디자인패턴검증된 설계 패턴을 활용하여 재사용성 향상재사용
MSA모듈화된 서비스를 웹 인터페이스로 호출하여 통합하는 방법재사용

3R의 효과성을 높이기 위한 고려사항

구분내용비고
설계 측면SOLID 원칙 준수로 낮은 결합도, 높은 응집도의 모듈 설계유지보수성, 확장성
도구 측면VCS 를 사용하여 SW 코드 및 자산의 변경 이력 관리유지보수성, 효율성

카나리 테스트

· 약 2분

카나리 테스트 개념

  • 새로운 버전의 소프트웨어나 시스템을 실제 사용자 환경에 배포하기 전에 제한된 사용자 그룹에게 먼저 공개하여 안정성과 성능을 검증하는 방법

카나리 테스트 구성도, 구성요소, 적용방안

카나리 테스트 구성도

카나리 테스트 구성요소

구분내용비고
로드 밸런서사용자 트래픽을 Canary 배포와 기존 배포에 분산트래픽 비율 조절
기존 배포현재 운영 중인 안정적인 버전대부분의 사용자에게 서비스 제공
Canary 배포새로운 버전의 SW 또는 시스템제한된 사용자에게만 공개
모니터링 시스템각 배포 환경의 성능, 안정성, 오류 등을 실시간 추적 및 비교문제 발생 시 즉각적인 대응

카나리 테스트 적용방안

  • 온프레미스 L4, DNS 사용
  • 클라우드 K8S의 Blue, Green 배포 전략을 이용하여 클라우드 기반의 Canary Test 도입 가능

카나리 테스트 고려사항

  • 문제가 발생했을 때 신속하게 이전 버전으로 롤백 가능한 계획 수립 필요

위험관리

· 약 2분

위험관리

  • 부정적 위험에 대한 대응 계획
  • PMBOK 기반

부정적 위험 대응 계획

회전감수이

구분내용비고
회피 Avoidance발생 가능성을 원천적으로 제거계획변경, 외주업체변경, 범위감소 등
전가 Transference조치에 대한 책임을 제 3자에게 넘김보험료, 개런티
감소 Mitigation발생가능성이나 영향력을 줄이는 방안프로토타이핑 개발, 덜 복잡한 프로세스 채택
수용 Acceptance아무런 대책없이 수용, 최소한의 계획으로 수용능동적, 수동적 수용
이관 Escalation프로젝트 범위를 벗어나거나 관리자 권한 초과시 적용이관 후 모니터링 하지 않음

소프트웨어 공학의 모든 것

· 약 19분

특징

  • 복잡성: Complexity
  • 순응성: Conformity
  • 변경성: Changeability
  • 비가시성: Invisibility

종류

  • 주문형: 고객, 기업의 요구사항 만족
  • 패키지형
  • 임베디드형

위기

  • 요구 증가, 복잡도 증가, 난이도 증가

목표

  • 최소 비용
  • 최고 효율

단계

  • 요구 분석
  • 설계
  • 개발
  • 테스트
  • 유지보수

품질 보증

ISO 25010, 기신사효유이호보

  • 기능적절성: Functional suitability
  • 신뢰성: Reliability
  • 사용성: Usability
  • 효율성: Performance efficiency
  • 유지보수성: Usability
  • 이식성: Portability
  • 호환성: Compatibility
  • 보안성: Maintainability

프로젝트 관리

  • 계획
  • 자원 관리
  • 리스크 관리
  • 프로젝트 수행 및 모니터링

연구 결과

  • 방법: Method
  • 도구: Tool
  • 프로세스: Process
  • 패러다임: Paradigm

연관 분야

ISO 24773, SWEBOK

구분내용비고
소프트웨어 공학 전문가 기량소프트웨어 엔지니어링의 전문적 실천에 필요한 지식과 기술윤리, 커뮤니케이션, 팀워크 등 포함
소프트웨어 공학 경제학소프트웨어 공학 프로젝트의 비용과 가치를 평가하는 지식과 기술경제적 분석 기법, ROI, TCO 포함
컴퓨팅 기반소프트웨어 엔지니어링의 기초가 되는 컴퓨팅 이론과 기술데이터베이스, 네트워크, 운영체제 등 포함
수학적 기반소프트웨어 엔지니어링 문제 해결에 필요한 수학적 이론과 기법통계, 확률, 이산 수학, 계산 이론 등 포함
공학적 기반일반 공학 원리를 소프트웨어 개발에 적용하는 지식과 기술시스템 공학, 품질 관리, 성능 최적화 등 포함

vs 컴퓨터 과학

소프트웨어 프로세스

좋은 프로세스

  • 예측 가능성: Predictability
  • 테스팅과 유지보수 용이성: Testability, Maintainability
  • 변경 용이성: Changeability
  • 결함 제거 용이성: Fault Tolerance

프로세스 모델

폭포수모델

V모델

프로토타이핑 모델

나선형모델

  • 프로토타입핑 반복

진화적 모델

  • 점증적: incremental
  • 반복적: iterative

Unified Process

  • 여러 사이클: iteration
  • 도입(inception) -> 정련(elaboration) -> 구축(construction) -> 전환(transition) 반복

애자일 프로세스

  • 2~6주간의 짧은 주기
  • 익스트림 프로그래밍: XP, 사용자 스토리, 매일 빌드/통합, TDD, 페어프로그래밍
  • 스크럼: 프로덕트 백로그 -> 스프린트 백로그 -> 2-4주기 개발, 스크럼미팅 -> 배포 가능 프로덕트 추가

지원 프로세스

ISO 12207, SDLC

  • 계약: 획득, 공급 프로세스
  • 운영: 운영 프로세스
  • 지원: 문서화, 형상관리, 품질 보증, 문제 해결 프로세스
  • 관리: 관리, 개선 프로세스
  • 엔지니어링: 개발, 유지보수 프로세스

관리 프로세스

  • 계획
  • 모니터링
  • 제어, 분석

품질보증 프로세스

  • 인스펙션 프로세스: 전문 인력, 고비용, 해결방법보다 이슈집중
  • 프로세스 관리 프로세스: CMMI

형상 관리 프로세스

  • 원시코드, 목적코드, 스크리븥, 관련 문서 전체 형상 관리

구조적 방법론

  • 분할정복
  • DFD: 배경도

정보공학 방법론

구분내용비고
ISP기업의 장기적 전략 계획 수립전략 계획서
BAA비지니스 영역별 데이터와 프로세스 모델링, 연관성 분석요구사항 명세서
BSD데이터와 프로세스 설계논리 ERD, 프로세스 구조도, 흐름도
SC데이터 상세 설계, 코딩물리 ERD, UI, 코드
  • 기업중심
  • 전략적 시스템 계획중심
  • 데이터 중심
  • 분할 정복
  • 공학적 접근
  • 사용자의 적극 참여

객체지향 방법론

  • 실세계를 객체로보고 객체사이 인터랙션을 모델링하는 방법
  • 대규모 시스템을 클래스로 모듈화하고 캡슐화
  • OMT: Object Modeling Technique, Booch, Usecase -> UML: Unified Modeling Language, UP: Unified Process

프로젝트 계획

  • 목표설정
  • 프로젝트 범위 설정
  • WBS작성
  • 작업별 소요시간 및 노력 예측
  • 작업 의존관계 정의
  • 자원 할당
  • 마일스톤 설정
  • 일정 개발

CPM 네트워크

  • Critical Path Method
  • Critical Path: 가장 오래 걸리는 경로

비용 예측 기법

  • 전문가 판단
  • PERT: Program Evaluation and Review Technique, 낙관적, 보통, 비관적
  • 알고리즘식 방법: 코코모, FB

COCOMO

  • Constructive Cost Model
  • LOC등 단계에 따라 값 예측하고 노력 추정
구분1단계2단계3단계
단계프로토타이핑초기설계설계이후
크기application pointsFP, 언어 종류FP와 LOC
요구변경비용모델에 포함변경 비율 반영변경 비율 반영
프로덕트 비용없음복잡도, 재사용요구도신뢰도, DB규모, 문서화요구정도, 재사용 요구도, 복잡도
플랫폼 비용없음플랫폼 난이도실생시간, 기억공간 제약
인력 비용없음개인능력, 경험분석능력, 응용경험, 프로그래머 능력/경험, 언어/도구 경험
프로젝트 비용없음개발기간, 개발환경 요구SW도구 사용, 개발 기간, 여러 사이트 개발 요구

기능점수

  • Function Point
  • 입력(트랜잭션), 출력(화면 및 출력양식), 질의, 파일, 응용 인터페이스

소프트웨어 대가 산정 가이드

  • 외부 입력: External Input, 내부 파일의 내용에 영향을 주는 사용자데이터 또는 입력을 트랜잭션 단위로 카운터 (입력, 수정, 삭제)
  • 외부 출력: External Output, 소프트웨어 외부로 표출되는 사용자 데이터 또는 제어 출력을 트랜젝션 단위로 카운트 (계싼, 통계 그래프 등)
  • 내부 논리 파일: Internal Logical File, 소프트웨어에 의해 생성, 사용, 관리되는 파일을 포함하여 시스템 내 존재하는 사용자 데이터 및 제어 정보의 그룹 카운트
  • 외부 인터페이스 파일: External Interface File, 소프트웨어 시스템 사이에 전다로디거나 공유된 파일 카운트
  • 외부 조회: External Query, 중간 출력을 생성하는 외부 조회를 카운트

프로젝트 모니터링

  • 어닝 밸류 분석: Earning Value Analysis, 비용과 일정 통합 모니터링
  • BAC: 프로젝트 예산
  • AC: 실제 비용
  • PV: 계획된 비용
  • EV: 어닝 밸류
  • PV - EV: 일정 차이
  • AC - EV: 비용 차이

리스크 관리

  • 6M: Machine, Method, Materials, Measurement, Man, Mother nature, 기계, 방법, 재료, 측정, 사람, 환경
  • 8P: Price, Promotion, People, Process, Place/Plant, Policy, Procedure, Product, 가격, 광고, 인력, 프로세스, 장소, 정책, 절차, 제품
  • SW프로젝트(Boehm): 인력부족, 비현실적 일정 및 예산, 잘못된 기능과 특징 개발, 잘못된 인터페이스 개발, 과포장, 계속적 요구변경, 외부 노출 컴포넌트 빈약, 실시건 성능 빈약, 녹슨 컴퓨터 분야 기술

요구

  • 시스템에 대한 고객의 요청을 확정한 것

기능 요구

기능, 데이터, 입출력, 사용자

  • 시스템과 외부 요소들 간의 인터렉션
  • 입력 검증
  • 정확한 작업 순서
  • 비정상적 상태에 대한 응답 및 복구
  • 매개변수 유효성
  • 입출력 관계

비기능 요구

성능, 품질, 안전, 보안, 사용성

  • 시스템 구축에 대한 성능, 보안, 품질, 안전 등에 대한 요구 사항
  • 외부 인터페이스
  • 메모리 제약
  • 성능 요구
  • 사용자 특성과 가정
  • 설치 환경의 적합성

요구 추출

  • Requirement Elicitation
  • 요구에 대한 정보 출처 파악 > 요구에 대한 정보 취합 > 요구와 제한 사항 정리

요구 정보 출처

  • 고객
  • 도메인 전문가
  • 이해당사자
  • 사용자
  • 역공학
  • 기존 문서
  • 인터뷰
  • 설문
  • 브레인스토밍
  • 프로토타이핑

요구 품질

  • 원자성: atomic, 요구사항이 복합 목적이 아니라 단일 목적인지
  • 완전성: complete, 요구 사항 안에 정의된 것이 정보의 모든 것을 포함하는 것인지
  • 비모호성, 통일성: unambiguous, consistent, 명확하지 않거나 같은 내용을 다르게 언급하지 않는 것
  • 추적성: traceable, 요구 사항을 쉽게 추적할 수 있도록 고유번호
  • 우선순위화: prioritize: 요구 사항의 중요도를 파악하는 성질
  • 테스트 가능성: testable, 요구 사항이 검증 가능하도록 기술되어있는 특성

유스케이스

  • 찾아낸 각 액터에 대해 시스템과 관련된 작업은 무엇인가?
  • 시스템에서 발생하는 특정 사건에 대해 액터에게 알려야 하는가?
  • 액터가 갑작스런 외부 변화에 대해 시스템에 알려야 할 것인가?
  • 시스템이 비지니스에 정확한 동작을 제공하나?
  • 찾아낸 유스케이스로 모든 기능을 수행할 수 있는가?
  • 어떤 유스케이스가 시스템을 지원하고 유지보수하나?
  • 시스템에서 어떤 정보를 수정하거나 만들어야하나?

요구분석 명세서

  • SRS: Software Requirement Specification
  • 소개
    • 목적
    • 제품 범위
    • 정의, 동의어, 약어
    • 참조문서
    • 개요
  • 일반적인 기술사항
    • 제품의 개관
    • 제품의 기능
    • 사용자 특성
    • 제약사항
    • 가정 및 의존성
  • 상세한 요구사항
    • 외부 인터페이스
    • 기능요구
    • 성능요구
    • 논리 데이터베이스 요구
    • 설계 제약사항
    • 소프트웨어 시스템 속성
    • 상세요구 사향의 구성
  • 부록
  • 색인

요구 검증

  • 이해용이성: comprehensibility, 요구 명세서를 읽을 떄 요구의 의미를 잘 이해할 수 있는가?
  • 중복: redundancy, 필요없이 중복된 부분이 없는가?
  • 완전성: completeness, 빠진 요구가 없는지, 요구 기술시 빠진 정보가 없는가?
  • 일관성: consistency, 요구사항이 모순되지 않는가?
  • 모호성: ambiguity, 요구분석 내용이 모호함 없이 모든 참여자들에 의해 명확하게 이해될 수 있는가?
  • 검증가능성: verifiable, 요구분석 명세서에 기술된 내용이 사용자의 요구를 만족하는가? 개발된 시스템이 요구사항 분석 내용과 일치하는지 검증할 수 있는가?
  • 추적가능성: traceable, 시스템 요구사항과 시스템 설계문서 및 구현과 매핑되어 추적할 수 있는가?

요구 모델링

  • 도메인지식을 체계화하는 과정
  • 도메인지식: 업무 프로세스, 기능, 역할, 업무 규칙
  • 기능적 모델링: 유스케이스 다이어그램, 액티비티 다이어그램
  • 정적 모델링: 클래스 다이어그램, ERD
  • 동적 모델링: 시퀀스 다이어그램, 협동 다이어그램
  • 제어 모델링: 액티비티 다이어그램

UML

  • 구조다이어그램: 클래스, 객체, 컴포넌트, 배치, 패키지, 컴포지트 구조
  • 동작 다이어그램: 유스케이스, 액티비티, 상태
  • 인터랙션 다이어그램: 시퀀스, 커뮤니케이션, 인터랙션 오버뷰, 타이밍

아키텍처 평가 모델

SAAM

  • Software Architecture Analysis Method
  • 이해관계자 품질 민감 시나리오 도출, 시나리오 우선순위, 시나리오 기반 아키텍처 평가

ATAM

  • Architecture Trade-off Analysis Method
  • 업무 배경 및 요구사항으로 품질 속성 도출, 시나리오 기반 아키텍처 절충점, 리스크 분석, 아키텍처 반영 및 평가
    • 품질속성: 유지보수성, 성능, 가용성, 보안성, 사용용이성

UI

  • 관련 분야
    • HCI 인간 컴퓨터 상호작용
    • 인터렉션 디자인, 사용자 중심 디자인, 상황별 디자인, 참여 디자인, 목표지향 디자인
    • 사용자 경험
    • 인간 공학
  • 사용성 (효과적 -> 쉬움 -> 즐거움)
    • 학습용이성
    • 효율성
    • 기억용이성
    • 낮은 오류율

참조

MAS, 상용SW 다수 공급자 계약 제도

· 약 4분

MAS 개념

  • 공공기관이 다양한 수요 충족을 위해 2인 이상(다수)을 대상으로 단가 계약을 체결하는 제도
  • 조달제품 다양화수요기관의 선택권 확대

MAS의 특징

  • 여러 공급자와 계약을 체결하여 수요기관의 선택 폭을 확대
  • 기업에게 정부조달시장 참여 기회 제공
  • 업체 간 경쟁의 확대

MAS 의 평가 절차, 항목, 2단계 경쟁

MAS의 평가 절차

  • 조달사업법 제13조 기반하여 계약 진행

MAS의 절차 세부 항목

구분내용비고
구매입찰공고나라장터 입찰공고규격확정, 상용화, 경쟁성 확보
적격성평가가격 기초자료 제출결격사유 확인, 협상품목대상 규격서 제출
가격협상적격자와 가격 협상실거래가의 가중평균, 최빈가격 기반 작성
계약체결나라장터 전자계약기본계약 3년
  • 5천만원 이상의 경우, 2단계 경쟁으로 투명성, 경쟁성 강화

MAS 2단계 경쟁 제도

구분내용비고
대상1회 구매애정 금액 5천만원 이상중소기업제품은 1억 이상
기본평가항목SW특성 반영한 기본 평가항목가격, 기능성, 사용성
선택평가항목유지보수 상품 등록, 국산SW 우대 등 반영유지관리성, 혁신 우수성
예외사항본상품 구매에 따른 제외 범위유지관리, 계속계약, 증설 등

제3자 단가계약과 MAS차이점

구분제3자단가계약다수공급자계약
계약방법수의경쟁
계약수량업체계약수량업체계약수량
계약자단일업체다수업체
가격자료동일품목 3건 이상 구매실적규격별 최근 1년간 전자세금계산서, 유사 거래 실적
2단계 경쟁없음1회 구매예정 일정금액 이상
납품업체 선정수요기관 지정일정금액 미만 수요기관 지정, 일정금액 이상 2단계 경쟁 통한 평가

참조