DEVELOP
article thumbnail

본 게시물은 컴퓨터공학개론 과목의 강의영상과 강의자료를 바탕으로 작성한 학습용 게시물입니다.


소프트웨어 공학 개관 

(p.364)

# 소프트웨어 공학 

  • 대규모의 복잡한 소프프웨어 시스템의 개발에 지침이 되는 원리들을 모색하는 컴퓨터과학의 한 분야
  • 타 공학 분야와의 차이점 
    - 사전 제작 부품의 결여
    - 측도의 결여
  • 실용 연구자 : 바로 응용될 수 있는 기법의 개발 
    이론 연구자 : 보다 안정된 기법들을 구축하는 데 토대가 될 기초원리와 이론들을 모색 
  • 전문가 단체 : ACM, IEEE 
    - 전문가 윤리 강경
    - 표준 

# CASE(Computer Aided Software Enginerriong) 도구 

  • 프로젝트 계획 ㅣ MS project, Teams, Trello Asana
  • 프로젝트 관리 ㅣ MS project, Teams, Trello Asana
  • 문서 작업 ㅣ Teams, IBM, Github, Jira 
  • 프로토타이핑과 시뮬레이션  ㅣ Indigo, Design, Adobe XD
  • 인터페이스 설계 ㅣ Sketch, Adobe XD, Axure RP 
  • 프로그래밍 
  • IDE (Integrated Development Envirnment) ㅣ Eclipse, VS 

소프트웨어 생명 주기 

(p.367)

소프트웨어 생명 주기

 

소프트웨어 생명 주기의 개발 단계

# 요구사항 분석 단계 

  • 목표 : 서비스의 규정, 조건의 식별, 외부와의 상호작용의 정의 
  • 이해관계자들의 요구사항 조사 포함 
    - 이해관계자 ㅣ 사용자 , 구매자 
  • 요구사항 ㅣ 응용 지향
  • 명세 ㅣ 기술 지향 
  • 소프트웨어 요구사항 문서 : 개발의 방향이 될 확고한 목표의 정의 

# 설계 단계 

  • 제안 시스템의 구축을 위한 계획의 수립단계 
    - 문제의 정의 / What : 요구사항 분석
    - 문제의 해답 / How : 설계 
  • 방법론과 도구
  • 휴먼 인터페이스 

# 구현 단계 

  • 결과를 바탕으로 시스템 구성 
    - 프로그램 작성
    - 데이터 파일 생성 
    - 데이터베이스 개발 
  • 소프트웨어 분석가의 역할과 프로그래머의 역할 
    - 소프트웨어 분석가 : 전체 개발 과정에 관련 ㅣ 요구사항 명세, 설계
    - 프로그래머 : 구현 

# 테스트 단계 

  • 1. 검증 테스트: 시스템이 명세를 충족하는지 확인
  • 2. 결함 테스트 : 오류 발견 
  • 각 단계에서 테스트는 중요한 역할
    - 요구사항 명세와 확인 / 설계와 검증 / 구현과 테스트
  • 오류 제거 : 소프트웨어 공학의 목표 중 하나 

소프트웨어 공학 방법론 

(p.372)

  • 폭포수 모델
    : 한 쪽 방향으로만 진행
  • 점진적 모델 
    - 시행착오 과정을 통한 모순의 극복
    - 진화적 프로토타이핑 
    - 단순버젼 -> 테스트와 점진적 기능 추가의 반복 
  • 반복형 모델 
    - 각 버전의 재구축 
    - 폐기형 프로토타이핑 
  • 공개소스 개발 
    - 점진형 / 반복형의 비정형적 변형 
  • 기민성 방법 (팀플과비슷)
    - 공통의 공간을 이용하는 소수의 개발자 
    - 비정형적 요구사항 명세, 설계, 구현, 테스트를 반복
    - 폭포수 모델과 대조적 
  • DevOps  

모듈화 

(p.374)

# 모듈화 

  • 모듈 사이의 독립성의 극대화 / 모듈간 결합도의 최소화 
  • 소프트웨어를 관리하기 쉬운 모듈이라는 단위로 분할
    각 모듈은 전체 기능 중 특정 부분만을 담당 
  • 함수 - 명령형 패러다임 ㅣ 구조도
  • 객체 - 객체지향 패러다임 ㅣ 협력도
  • 컴포넌트 - 컴포넌트 구조 

구조도

# 정보 은닉 

  • 정보를 소프트웨어의 특정 부분에서만 이용될 수 있도록 제한시키는 것 
  • 모듈은 다른 모듈이 그 내부 정보에 접근할 필요가 없도록 설계 : 설계목표 
    - 응집도의 최대화, 결합도의 최소화
  • 모듈 간의 경계를 확실히 지킬 수 있도록 구현 
    - 지역변수, 캡슐화, 잘 정의된 제어구조의 사용 등 

# 결합 

  • 제어 결합
    :
    프로시저 호출, 실행 제어의 전달 시 발생 
  • 데이터 결합
    :
    모듈 사이의 데이터의 공유 (매개변수 or 전역변수)

# 응집 

  • 각 모듈의 내부 연결성, 내부 부분들 사이의 연관성 정도 
  • 논리적 응집 : 성질상 논리적으로 비슷한 활동 (객체단위의 특징)
  • 기능적 응집 : 한 모듈안의 모든 부분은 한가지 활동의 수행에 초점 (객체 내의 각 메소드) 
    - 하나의 메소드들은 기능적 응집을 갖는다. 

객체 내의 논리적 응집도와 기능적 응집도


Tools of the Trade (설계도구)

  • 데이터 흐름도 
  • 개체 관계 다이어그램
  • 데이터 사전
    : 소프트웨어 시스템에 나타나는 데이터 항목들에 관한 정보의 중앙 저장소 

#UML (Unified Modeling Language)

  • 용례 다이어그램 
    - 용례, 행위자 
  • 클래스 다이어그램 

용례 다이어그램

# 상호작용 다이어그램 

  • 클래스 다이어그램
    : 설계의 정적인 기능 표현 
  • 상호작용 다이어그램 
    - 실행 동안 발생하는 이벤트들의 진행순서를 포함하는 동적 기능의 표현 
    - 진행 순서 다이어그램 
  • 생명성, 프레임, 상호작용 구절 등 

테니스에서 일반화된 공방을 표현하는 진행순서 다이어그램

# 설계 패턴 

  • 자주 반복되는 문제를 해결하기 위한 잘 설계된 템플릿
    ex) 어댑터 패턴 : 모듈의 인터페이스를 당면 요구에 맞추기 위해 사용됨
        데코레이터 패턴 : 실행 시점의 상황에 따라 동일한 활동들을 다르게 조합하는 작업을 수행할 때의 복잡성 제어에  사용됨 

# 시스템에 대한 시뮬레이션 

  • 구조적 예행연습 
  • 설계팀의 각 구성원에게 한 장씩의 CRC카드가 주어진다. 
  • Class-responsibility-collaboration cards
    - 각 객체마다 한 장의 카드 
    - 구조적 예행연습에 활용 
    - 객체 지향 설계의 검증 
  • 공연 실험 - 역할 수행 

품질보증 ( Quality Assurance)

(p.392)

  • 유리박스 테스트 : 내부 구성에 대한 지식 전제 
    - Pareto 원리 : 소수의 인구가 대부분의 부를 통제 
    - 기초 경로 테스트 : 모든 명령이 최소 한번씩은 수행되는 테스트 데이터 집합의 개발 
  • 블랙박스 테스트 
    - 경계 값 분석 : 범위의 가장자리에 가까운 데이터들에 대한 테스트 
    - 베타 테스트 

문서 (documentation)

(p.395)

  • 사용자 문서 
    - 모든 고객을 위한 인쇄된 책자 
    - 온라인 도움말 모듈 
  • 시스템 문서 
    - 소스코드
    - 설계 문서
  • 기술 문서 
    - 설치, 커스터마이징, 업데이트 등을 설명 

인간 - 장비 인터페이스

(p.397)

  • 소프트웨어 시스템은 사용하는 사람의 편의성에 초점을 맞추어 설계된 도구라는 개념에 기초 
  • 인체공학 - 사람의 신체 기능 
  • 인지공학 - 사람의 정신 기능 
    - 습관 , 주의력 

소프트웨어에 대한 소유권과 책임의 문제 

(p.401)

  • 저작권 
    - 소유권을 보호하면서 상품을 공개할 수 있게 한다
    - 모든 작업 결과물에 저작권 안내문을 포함시킴 : 명세, 소스코드, 최종제품 

# 지적 재산권

  • 소프트웨어 라이선스 
    - 소유권을 이전하지 않으면서 사용자에게 일정한 허가를 부여하는 법률적 합의서 
  • 특허 
    - 새롭고, 유용하며, 비슷한 배경을 가진 다른 사람들에게 단순한 것이 아니라는 것을 증빙해야함 
    - 특허 획득 과정은 많은 비용과 시간 요함 
profile

DEVELOP

@JUNGY00N