(14) 소프트웨어공학

* 프로그래밍이 어려운 이유
  - 사람이 이해하는거랑 컴퓨터가 이해하는거랑 다르기 때문
 
* 사람 vs 컴퓨터
• 사람:
– Interested in modeling the real world
– More interested in “what”(무엇을) computer should do than how
 
• 컴퓨터:
– Only data it can manipulate is sequences of zeros and ones
– Understands low-level “how”(어떻게) instructions.
 
* 소프트웨어 개발의 현실
• 요구사항이 애매함
• 개발 중 요구사항 변경
• 스케일이 더 큽니다
   – 다양한 디자인 기술이 필요합니다
   – 팀워크가 필요합니다
• 개발이 완료된 후 소프트웨어를 변경해야 합니다
• 실패 시 비용이 더 많이 듭니다

   – Business-critical 
    – Safety-critical
 
* 소프트웨어공학의 정의
• IEEE
– “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”
 
•Ian Sommerville
– “An engineering discipline that is concerned with all aspects of software production
 
* 소프트웨어공학 vs 타 공학
   • 비즈니스를 고려
   • 고객을 최우선시함
   • 설계 변경이 용이함
   • 결과물이 무형 (비가시적)임
   • 요구사항 변경이 잦고, 모호함
 
* 소프트웨어 공학의 역할
  - 고객과 프로그래머 이어주는 역할을 함
 
* 소프트웨어 공학이란?
  - engineering discipline + all aspects of S/W
 
<소프트웨어 개발 방법론>
 
* 소프트웨어 개발 절차
• 수집 요구사항
   • 팀 운영
   • 소프트웨어 디자인
   • 개발 (코딩)
   • 테스트
   • (서류화)
   • 전개
   • 유지보수
 
* 소프트웨어 개발 방법론
• Anti Lifecycle
   – Code & Fix
 
• Lifecycle

   – Waterfall
   – Rapid Prototyping
   – Incremental
   – Spiral
   – Agile
 
<Code and Fix> (실습할때 쓰는 방법)
•소규모 개인 개발에 유용함
• 심각한 코딩 작업에서 문제가 명백해집니다
    – 버전 관리, 테스트, 변경 관리 등의 프로세스가 없습니다.
    – 여러 프로그래머의 활동을 조정하기가 어렵습니다
    – 비기술자는 프로그램 작동 방식을 설명할 수 없습니다
    – 프로그래머는 사용자의 요구를 모르거나 이해하지 못합니다

 
<Waterfall Model>
• Proposed in early 70s by Winston Royce
• 요구사항
    – 필요한 정보, 기능, 행동, 성능 및 인터페이스를 정의합니다.
• 디자인
    – 데이터 구조, 소프트웨어 아키텍처, 인터페이스 표현, 알고리즘 세부 정보.
• 구현
    – 소스 코드, 데이터베이스, 사용자 설명서, 테스트

 
<Waterfall 장점>
• 이해하기 쉽고 사용하기 쉽습니다 
• 경험이 부족한 직원에게 구조를 제공합니다
• 마일스톤을 잘 이해하고 있습니다
• 요구사항 안정적이게 설정
• 경영관리(계획, 직원, 트랙)에 적합합니다
• 비용이나 일정보다 품질이 중요할 때 효과가 좋습니다 (good if, quality > cost, schedule)

     (because 한단계 끝날때까지 다음 단계 X)
 
<Waterfall 단점>
• 모든 요구 사항을 미리 알아야 합니다
• 각 단계별로 생성된 결과물은 동결된 것으로 간주됩니다 (동결) –> 유연성 저해
• 진행 상황에 대해 잘못된 인상을 줄 수 있습니다
• 소프트웨어 개발의 문제 해결 특성을 반영하지 않음 –> 단계별 반복

• 통합은 마지막에 하나의 빅뱅이다
• 고객이 시스템을 미리 볼 기회가 거의 없음 (너무 늦을 수 있음, 고객은 제한된 정보를 받음)
 
<Waterfall Model을 사용해야할 때>
• 요구 사항은 매우 잘 알려져있을때

• 제품 정의가 안정적일때
• 기술이 이해되고 있을때
• 기존 제품의 새로운 버전일때
• 기존 제품을 새로운 플랫폼으로 포팅할때(이식)
 
<Rapid Prototyping>
• 프로토타입은 요구사항 사양을 개발하는 데 사용됩니다
    – 요구 사항이 알려지면 waterfall을 사용합니다
• 설계가 시작되면 프로토타입이 폐기됩니다
    – 프로토타입을 구현의 basis로 사용해서는 안 됩니다
    – 프로토타이핑 도구는 생산 품질 코드를 생성하지 않습니다
• 또한 고객은 프로토타입에 대해 "교육"을 받아야 합니다
    – 프로토타입은 요구 사항 관련 질문에 답하는 데 사용된다는 사실을 알아야 합니다
    – 그렇지 않으면 그들은 참을성이 없어집니다
 
<Rapid Prototyping>
 

<Incremental>
• 마이크로소프트에서 사용함 (적어도 윈도우 XP 구축할 당시)
    – 프로그램은 빌드 관리자에 의해 매일 구축됩니다
• 기능에 따라 반복 작업이 계획됩니다
    – 기능 1 및 2는 반복 1에서 작업
    – 특징 3 및 4는 반복 2에서 작업

<Spiral>
• 반복 모델과 유사하지만 다음과 같습니다:
    – 각 반복 작업은 "리스크 관리"에 의해 주도됩니다
        • 목표 및 현황 파악
        • 리스크 파악
        • 리스크가 높은 항목을 해결하기 위한 계획을 수립하고 반복 작업을 진행합니다
    – 반복

 
<Agile>
• 민첩한 개발은 기존 "헤비급" 소프트웨어 개발 프로세스의 문제에 대한 대응입니다
    – 너무 많은 아티팩트
    – 너무 많은 문서
    – 융통성 없는 계획
    – 지연, 예산 초과 및 버그가 많은 소프트웨어
 
<Agile Manifesto> (애자일 선언)
• 우리는 소프트웨어를 개발하고 다른 사람들이 소프트웨어를 개발하는 더 나은 방법을 발견하고 있습니다. 이 작업을 통해 우리는 다음과 같은 가치를 갖게 되었습니다:

• 즉, 오른쪽 항목에는 가치가 있지만 왼쪽 항목에는 가치가 더 있습니다.

 
<Agile Methodology>
• Agile 방법론의 등장 배경
    – SW 개발환경의 변화
        • 짧은 Time to market으로 인한 생산성이 점차 중요해짐
    – 기존 방법론의 한계
        • 문서 및 절차 위주
        • 개발자의 능력 차이 고려 불가능
• 대표적인 Agile 방법론
    – XP(eXtream Programming)
    – Scrum
• Agile이 적합한 환경
    – 작은 팀의 규모로 가까이 위치해 있으며
    – 팀원간 수평 구조로 이루어진 조직에 적합
 

 
* 요구사항 분석
• 요구 사항은 무엇입니까?
• 요구사항 분류
• 요구 사항을 수집하는 방법은 무엇입니까?
 
* 요구사항 분석의 어려움
• 프로젝트 실패의 주요 원인
    – 불완전한 요구사항
    – 요구사항 변경
    – 사용자 입력 불량
• 필수 솔루션
    – 요구사항 분류
    – 요구사항 분석
        • 요구사항 수집, 정제 및 순서 변경
 
* 요구사항 분석을 위한 방법
• 요구사항을 수집하면서 분석
    – 인터뷰
    – 공동 애플리케이션 개발(JAD)
    – 설문조사
    – 문서 분석
    – 관찰
• 요구사항을 직접 찾으면서 분석
    – 기존 시스템 복사
    – 브레인스토밍
 
* 요구사항 분석 절차
• 요구사항 정리
    – UML
    – 사용자 스토리
    – 사용 사례
    – 시제품
    – 요구사항 규격(신속 시제품 제작)
• 검증 및 확인
    – 검증: 우리가 옳은 일을 하고 있습니까?  올바른 것을 만들고 있는지?
    – 확인: 우리가 일을 제대로 하고 있습니까?  올바르게 하고 있는지?
• 변경 요구사항

 

 
* 요구사항의 분류
• 기능성: features, 기능, 보안 → 가장 쉽고 명확함(S/W 의 최소 기능)
    – 나머지 요구사항은 비기능 요구사항이다 

사용성:
• 사용성: 인적 요소, 도움말, 문서화
• 신뢰성: 고장 빈도, 복구 가능성, 예측 가능성
• 성능: 응답 시간, 처리량, 정확도, 가용성, 리소스 사용량
• 지원성: 적응성, 유지 보수성, 국제화, 구성 가능성
 
<비기능 요구사항의 예>