Software Engineering

Software Engineering

Requirements Engineering Process

요구공학 프로세스는 사용환경, 개발 방법론, 조직의 역량에 따라 천차만별로 달라진다.

그럼에도 그 각각은 다음 4가지 공통 수행 단계를 공통적으로 갖는다.

• 1. Requirements elicitation (요구사항 끌어내기)

  Elicitation = discovery + identification (from stakeholders)

  Req elicitation 은 다음 4가지 활동을 순차적으로 반복하는 식으로 진행된다.

  • 1. Requirements discovery

    이해관계자들이 요구사항을 도출할 수 있도록 자극한다. 도메인 수준의 요구사항 또한 여기서 발견된다.

    • Req discovery 의 방법들
      • Requirements workshop
      • brainstorming
      • storyboards(Use case scenario)
      • Interviews (잘 알고 있는 전문가 인터뷰)
      • Role playing
      • Questionnaires
      • Prototypes
      • Customer requirement specification review
  • 1. Requirements classification and organization

    서로 연관이 있는 요구사항들을 공통적 요소를 중심으로 통일한다.

  • 1. Requirements prioritization and negotiation

    요구사항의 우선순위를 정해서 그것들 간의 충돌을 방지한다.

  • 1. Requirements specification

    요구사항들을 문서화하고, 다음 단계의 요구사항들을 찾는데 베이스로 사용한다.

• 1. Requirements analysis (분석, SRS를 만들기 위한 초기단계수준으로 정리)

  유저와 시스템의 요구사항을 문서화 하는 과정

  • user req를 작성할 때는 소프트웨어를 사용하는 기술적 지식이 없는 end user가 보아도 알아볼 수 있도록 작성
  • sys req를 작성할 때는 좀 더 디테일하고 기술적인 내용을 담아야 한다.

  여기서 작성된 문서들은 계약서의 일부가 될 수 있다.

  (SRS (IEEE 830 1998 형식 준수))

  주의할 점: req는 시스템이 무엇을 하는지에 초점을 두고, 뒤에 나올 design은 어떻게 하는지에 초점을 두어야 한다.

  • 좋은 Specification의 특징들

    Valid - stakeholder들 의 real needs를 표현해야 한다.

    Unambiguous - 해석의 여지 없이 명확해야 한다.

    Complete - 완벽함 (시스템이 해야 할 것, 하지 말아야 할 것, 등 부터 명세의 구조적 완벽함, 내용적 완벽함이 있어야 한다.)

    Understandable (Clear) - 비전문가가 보고도 이해할 수 있어야 한다.

    Ranked - 중요도가 나타나 있어야 하며 req들 간의 서열이 명확해야 한다

    Verified - 검증을 할 수 있도록 테스트에 대한 명세가 있어야 한다.

    Modifiable - 구조적으로 잘 짜여 있어 큰 어려움 없이 다른 형태로 변경 가능한

    Traceable - req들의 근원이 라벨링 되어 있어야 한다.

  • SRS를 작성하는 방법들

    • Natural language
      1. 단점들
         • Lack of clarity -명료하지 않음
         • Requirements confusion -NFR FR이 뒤섞여 있어 햇갈림
         • Requirements amalgamation
           -서로 다른 요구사항이 분리되지 않고 한뭉텅이로 표현됨
    • Structured natural language (=Structured Specifications) -예시
      • Form-based specification
      • Tabular specification
      • Use-case (UML에 포함되어 있음, use-case 한다발로 시스템의 가능한 모든 기능들을 표현하는 것이 가능)
    • Design description languages
    • Graphical notations -UML, sequence diagrams
    • Mathematical specifications
• 1. Requirements validation (Req가 제대로 뽑혔는지 검증)

  수행 목적

  • 작성한 Req가 C&C가 되는지 (Consistancy & Completeness)
  • 정제한 결과가 유저가 요구한 것 과 달라지지 않았는지

  검사 요소

  • Validity: 고객이 진정으로 원하는 것을 시스템이 제공하는지
  • Consistency: 요구사항에 결점이 없는지
  • Completeness: 모든 이해관계자가 요구사항에 포함되었는지
  • Realism: 실현가능한 기술과 예산안에서 구현이 가능한지
  • Verifiability: 요구사항의 검증이 가능한지

  수행 방법들

  • Requirements review (요구사항 문서들을 분석)
  • Prototyping (프로토타입 제작)
  • Test-case generation (테스트케이스 제작)
• 1. Requirements change management (위 1, 2, 3을 내가 원하는 수준의 SRS가 나올때 까지 반복)

  관련 도구를 사용하여 요구사항 명세 과정이나 개발 도중에 발생하는 Req의 변화 과정을 기록, 관리하는 것.

System Modeling

시스템 모델링은 시스템을 개략적으로 다양한 관점에서 표현할 수 있는 여러 모델을 만드는 단계이다.

대부분 Unified Modeling Language (UML)을 기반으로 하는 notation을 갖는다.

• 4가지 관점(Views)에 따른 모델 분류

  • External perspective - High level

    우리 시스템의 바운더리에 대해 시스템 외부에서 저변 시스템과의 관계등을 표현한 관점

    • External Models 예시

      • Context Models

        시스템이 동작하는 환경(동작 범위)에 대해 표현한다.

        • External Perspective
        • 시스템 바운더리 바깥에 어떤 것들이 있는지 보여준다.
        • Architecture model의 경우 시스템과 다른 시스템이 어떤 관계인지 표현한다.

        

      • Process Models

        비즈니스 관점에서 내 시스템의 내부 프로세스들이 (필요하다면 외부 프로세스도) 어떤 상호작용을 하는지 표현한다.

        

  • Interaction perspective - High level

    -External perspective와 경계가 모호함. External은 외부 요소들에 대한 소개라면 얘는 그들 과의 상호작용에 초점을 두었다.

    시스템과 외부 환경 또는 다른 시스템 내부의 구성요소들 간의 상호작용을 보는 관점

    Model 종류

    • Modeling user interaction

      user req를 식별하는데 도움을 준다.

    • Modeling system-to-system intercation

      시스템간 정보전달에 문제가 생길 요소들을 식별하는데 도움을 준다.

    • Modeling component interaction

      시스템의 구조가 시스템의 동작이나 신뢰성에 어떤 영향을 줄지 식별에 도움을 준다.

    • Interaction Models 예시

      • Use Case Modeling

        시스템에 맡겨진 task들에 대해 표현한다. (외부 시스템과의 상호작용 포함)

        • Use case - Text로 표현된 시나리오다. (상호작용 대상은 user나 다른 시스템이 될 수 있다.

          

        • Use case diagram - Use case를 도식화 한 것.

          

      • Sequence Diagrams

        특정한 Use case 1개가 수행되기 위한 일련의 상호작용들에 대해 표현

        오브젝트 수준

        

  • Structural perspective - Low level

    -내부 모듈(컴포넌트)간의 Intercation 중 high level

    시스템의 구조나 시스템이 다루는 데이터의 구조에 대한 관점

    시스템 아키텍처를 구상할 때 만들고, 개선시킴.

    • Static models - 클래스들로 구성

      • Class diagram

        시스템에 있는 클래스(Object)들과 그것들 간의 연관에 대해 보여준다.

        객체지향 방법으로 시스템 개발시 사용된다.

        

    • Dynamic models - 객체들로 구성
      • Object diagram
      • Component diagram
      • Composite structure diagram

  • Behavioral perspective - Low level

    -내부 모듈간의 Interaction 중 low level

    시스템이 실행중(Dynamic) 어떻게 동작하는지, 이벤트를 어떻게 처리하는지에 대한 관점

    Behavioral models 종류

    • Data-driven model (DFD)

      인풋된 데이터를 어떻게 처리하고, 어떻게 그것에 맞는 아웃풋을 만드는지 보여준다.

      UML의 Activity diagram이 DFD의 일종이다.

      아래 그림 중 사각형 박스는 데이터, 둥근 박스는 데이터 프로세싱

      

    • Event-driven model (State machine model, Finite State Machine)

      실행시 시스템 내, 외부 이벤트들에 대해 어떻게 시스템이 대응하는지에 대해 보여준다.

      

• UML
  • Level (완성까지의 3가지 Level)

    • Comunication (Sketch 수준)

      구현할 또는 구현된 시스템에 대한 논의를 용이하게 하기 위해 사용될 수 있는 수준

      미완의 상태이고, 정확도 또한 낮은 상태

    • Documentation (Blueprint 수준)

      시스템 전체에 대한 완성단계 까지는 아니지만 시스템을 오류없이 표현할 수는 있어야 한다.

    • System generation (Code generation 수준)

      오류가 없으면서 완전해야한다.

  • 종류 (주로 사용하는 5개)
    • Activity diagram: 실행시 어떤 동작이 이루어 지는지, 데이터가 어떻게 처리되는지 보여줌 Ex) Flow Chart
    • Use case diagram: 시스템과 실행 환경과의 상호작용을 보여준다.
    • Sequance diagram: 외부 요소와 시스템 또는 시스템 구성 요소간의 상호작용을 보여준다.
    • Class diagram: 오브젝트들 간의 관계에 대해 보여준다.
    • State diagrams: 시스템 내부 또는 외부에서 사건이 발생할 경우 시스템이 어떻게 반응하는지에 대해 보여준다.

• Model-Driven Engineering (MDE = MBD)

  프로그램 보다 모델이 결과물이 되도록 하는 개발 방법론이다.

  실행 가능한 프로그램은 모델로부터 자동적으로 생성된다. (99%의 완성도)

  • 장점
    • 시스템이 모델을 100% 반영하기에 불순물 없이 그대로 모델을 반영한 코드가 나온다.
    • 모델은 언어나 플렛폼에 독립적이기 때문에 간단한 수정만으로도 각기 다른 환경에 적용할 수 있는 프로그램으로 찍어내는게 가능하다.
  • 단점
    • 모델을 코드로 번역하는 번역기를 개발하거나 빌려쓰는데 비용이 막대하다.
  • 한계
    • 지원되는 도구가 있어야 개발이 가능한데 그 도구가 매우매우 비싸다.
    • SW 디자인에는 상당히 좋은데 레거시 시스템 기반으로 돌아가는 SW를 만드는덴 사용하기 어렵다.
    • 이러한 개발 방법을 사용하는것은 도구의 가격 등을 고려했을 때, 오래 두고 사용해야 하거나 거대하고 복잡한 프로그램, Safety Critical SW 의 개발에만 적합하다.

  • Model-Driven Architecture (MDA)

    OMG 그룹이 표준으로 제시한 소프트웨어 디자인과 구현을 할 때 모델에 초점을 둔 개발 방법

    3가지 레벨으로 구분된 모델들을 모두 완성하면 비로소 하나의 프로그램이 만들어진다.

    • 3가지 레벨
      • CIM (Conputation Independent Model)
        • 구현하려고 하는 도메인을 모델링한다.
      • PIM (Platform Independent Model)
        • 플렛폼에 대해 독립적인 요소들에 대한 모델링
        • UML의 모델 중 static상태를 보여주는 모델, 내 외부 이벤트에 대한 대처를 보여주는 모델을 사용하기도 한다.
      • PSM (Platform Specific Models)
        • PIM을 특정 플렛폼에 적용하기 위한 요소들에 대한 모델링이다.

    

토막 정리- Design과 Modeling의 관계

• 서문

  강의가 상당히 두서 없이 진행되어 각 단원의 내용 파악도 어렵지만, 단원간 관계에 대해 파악하는 것은 더 어렵다….

  Modeling이 나온 뒤에 Design이 따로 나와 둘의 관계에 대해 개인적으로 교통정리를 하고자 한다.

• Design과 Modeling의 관계

  modeling 단원에 SASD가 나오고, design 단원에 OOAD가 나오고 혼란스러운 구성이었기 때문에 처음엔 둘이 같은 개념인데 그냥 표현만 다른것이 아닌가 싶었다.

  조금 시간을 갖고 생각해보니 둘은 위상이 다른 개념인 것으로 결론이 났다.

  design은 행위, Model은 도구, modeling은 도구의 사용이 되겠다.

  예를 들어 그림을 그리기 위해 어떤 그림을 그릴지, 어떤 내용을 그릴지는 req에 담겨온다. 이를 바탕으로 구도를 어떻게 짜고, 각 요소를 어디에 배치하고, 배경색, 질감은 어떻게 하고 등… 그것을 문서로 표현하든 생각으로만 갖고 있든 그림의 구성들을 설계 하는 것이 Design이다. 그 Design을 하는 과정에서 스키마를 그릴 수도 있고, 머릿속에 저장할 수도 있는데 그 Design이라는 행위로 탄생한 무형의 개념을 유형으로 시각화하여 표현하는 것이 Modeling이다. 최종 결과를 정리하는 도구로써 Modeling을 사용하든, 결과로 향해가는 과정속 미완의 개념을 표현하는 것 또한 Modeling이다.

High Level Design -(Architectural Design)

• 개요

  • High Level Design

    다음 두 요소에 대한 이해를 바탕으로 진행되어야 한다. (또는 Design을 진행하면서 알아가도 좋다.)

    • 소프트웨어가 어떤 것들로 구성되어야 하는지
    • 소프트웨어의 구조를 어떻게 디자인 해야 하는지
  • Architecture model
    • 여러 상호작용하는 components로 이루어진 시스템이 어떻게 구성되어야 하는지에 대해 표현한다.
    • Block 다이어그램으로 표현됨

    • 예시

      

  • 범주별 Architecture 구분
    • Architecture in the large
      • 여러개의 프로그램과 시스템들로 구성된 시스템
    • Architecture int the small
      • 단일 프로그램으로 구성된 시스템을 대상으로 한다.
      • 시스템은 다시 내부구성(Component)들로 어떻게 쪼갤지에 대해 초점을 둔다.
  • Architecture Design의 장점
    • 이해관계자들과 의 소통을 원활하게 해줄 도구로 사용가능
    • 시스템이 NFR들을 만족할 수 있을지에 대한 진단 가능
    • 한번 설계된 Architecture은 High Level Design의 산물이기에 여러 범주에서 재사용이 가능하다.
      • 동일한 도메인 내의 시스템들은 도메인의 속성을 반영한 서로 유사한 Architecture을 갖는 경우가 있다.
      • †새로운 Architecture을 설계하기 위해 기존의 Architecture을 참고하여 그 패턴이나 스타일을 채용하기도 한다.
        • 본질을 포착하고, 그것을 다른 방향으로 인스턴스화 하는 방법도 가능하다.
  • 표현 방법들
    • Simple, informal Block diagrams
      • 구성 요소들과 관계에 대해 매우 간략히 표현한다.
      • 가장 많이 사용된다.
    • Box and Line Diagrams
      • 상당히 추상적이고, 구성 요소간 관계나 서브 시스템의 자원들에 대한 표현도 없다.
    • Extensions of UML models
      • Class diagram이나 object diagram, structure diagram 들을 변형해 사용
  • Architecture model 사용 용례
    • 의사소통을 원활하게 하는 도구로써
      • 고객과, 개발 관련자들과의 소통 수단으로써 사용가능
    • 아키텍처에 대한 문서로써 사용가능
• 용어 설명

  • Architecture

    <외부환경과 시스템="">, <시스템 내부 구성들간 관계, 결합>, <시스템의 디자인과="" 향후="" 발전방향="">에 대한 가장 근본적인 수준의 컨셉, 구성 요소들을 뜻한다.

  • Architecture Description

    아키텍처를 표현하기 위한 작업의 결과물

  • Architecture Framework
    • 아키텍처 구현에 영향을 주는 {시스템이 자리할 도메인 환경, 이해관계자가 속한 사회적 제약(기관, 개인 등)} 에 대한 컨벤션, 원칙, 그외 세부사항
  • Stakeholder
    • 시스템에 이해관계를 갖는 {개인, 팀, 단체}
    • Ex) user, acquirers, developers, maintainers
  • Architecture View
    • 특정한 관점에 입각해 시스템 아키텍처를 묘사하는 작업의 결과물
  • Architecture Viewpoint
    • 특정한 관점에 입각해 시스템 아키텍처를 묘사하기 위해 선정한 컨벤션, Architecture View의 활용과 해석 방법을 규명하는 작업의 결과물
  • Concern
    • 이해관계자와 관련된, 신경 쓰는 시스템의 요소

    • Concern은 시스템이 영향을 주는 여러 영역에 걸쳐 존재한다.

      예를 들어 개발, 기술적, 비즈니스적, 사용시, 정치적 영역 등등

  • Model Kind
    • 모델링 타입에 대한 컨벤션.
    • Ex) DFD, Class diagram, balance sheets(!), organization chart(!) 등
• Architectural Design에서 결정해야 할 것들
  • 이 디자인 단계는 상당히 추상적인 과정이기에 시스템의 타입에 따라 수행 동작들이 달라진다.
  • 그럼에도 다음의 몇 가지 공통적인 디자인 과정에서의 결정 요소가 존재한다.
    • 현재 설계하고 있는 시스템에 특화된 범용 architecture template이 존재하는지
    • 시스템이 어떻게 하드웨어상에서 작동하는지
    • 이 시스템에 어떤 architecture 개념적 틀이 적용할 수 있는가
    • 시스템과 그 구성요소들의 실행을 제어하기 위해 어떤 전략을 사용할 것인가
    • Architecture Design한 것을 어떻게 문서화 할 것인가
    • NFR 들을 반영하기에 가장 최적의 architectural design이 무엇인가
    • 시스템의 구성요소들을 어떤 구조단위로 쪼갤 수 있는가
    • 시스템 구조 설계에 어떤 기반적 접근을 해야 하는가
      • Ex) 원전 sw는 방사선에 데이터가 훼손돼도 복구 가능해야 함.
• Architecture가 영향을 주는 시스템의 Characteristics(NFR)
  • Performance
    • 주요 동작들은 local에서 수행, 외부와의 정보 교환을 최소화, 구성 요소들을 큼지막하게 설계
  • Security
    • 계층 구조로 설계하여 중요한 자산은 inner layer에 보관
  • Safety
    • 안정성에 중대한 영향을 줄 수 있는 요소들은 서브 시스템 내부에 보관
  • Availability
    • 오류 대응을 위해 잘 사용되지 않더라도 도움이 되는 구성 요소들을 시스템에 포함시키는 것
  • Maintainability
    • 잘게 소분된, 교체가능한 구성요소들로 시스템을 구성
• Architecture Views
  • 개요
    • 각각의 Architectural model은 한가지의 관점으로 본 architecture만 보여준다.
      • 시스템이 어떤 구성으로 쪼개져 있는지
      • 실행시 프로세스들이 어떻게 상호작용하는지
      • 네트워크 상에서 각 시스템 구성요소들이 어떻게 흩어져 있는지
    • Architecture을 정확히 표현하기 위해선 여러가지 모델을 통해 여러 관점으로 보여줘야 한다.
      • 어떤 관점이 시스템을 효율적으로 표현할 수 있을지 고려하여 View 선정
      • 어떤 notation이 선택된 모델을 표현하는데 적합할지 고려
  • 4 + 1 View Model
    • Logical view
      • 시스템의 핵심 요소들에 대해 오브젝트(static) 형식으로의 관점
      • UML의 Class diagram에 대응
    • Process view
      • 시스템의 실행시 다른 프로세스들과 어떻게 상호작용을 하는지의 관점
      • Object diagram dp eodmd
    • Development view
      • 개발시 시스템을 어떻게 소분할 지에 대한 관점
      • deployment diagram에 대응 (physical view와 겹침)
      • component diagram에 대응 (physical view와 겹침)
    • Physical view
      • 시스템의 하드웨어와 소프트웨어 구성요소들이 어떤 구성으로 배치되어 있는지에 대한 관점
      • deployment diagram에 대응 (Development view와 겹침)
      • component diagram에 대응 (Development view와 겹침)
    • • 1 = Usecase Scenario
  • Describing Architectures
    • Model Notations
      • Unified Modeling Language (UML - 4%)
      • Architectural discription languages (ADLs - 1%)
      • Naive diagrams (95%)
    • Document
      • ISO/IEC/IEEE 42010:2011 Systems and Software Engineering -Architecture Description (AD)
        • AD 작성시 표준 원칙
          • 시스템이 다양한 이해관계자들의 니즈를 어떻게 만족시킬 것인지에 대한 설명이 있어야 한다.
          • 이해관계자들의 걱정(요구)들에 대해 기술되어야 한다.
          • architecture view선정시 그 view가 제공하는 정보들은 완전하고, 검증가능하며, 목적적합해야 한다.
            • viewpoint에 대한 문서엔 어떤 모듈을 어떤 notation으로, 어떤 analysis 방법을 사용할지 정리되어 있어야 한다.
• Architectural Patterns $\simeq$ (Architectural Viewpoint)
  • 개요
    • 상당히 High Level의 개념으로 정확한 지시보단 개념에 가까움
    • 여러 환경에서 시도되고, 시험을 거친 좋은 디자인 습관에 대한 description
    • 어떤것을 언제, 왜 하지 말아야하는지 에 대한 기술도 포함한다.
  • TODO 세부 패턴들에 대한 문서도 읽고 정리할 것
• Apllication Architectures
  • 개요
    • 추상적인 Architecture pattern을 구체화 한 것
    • 특정 타입의 시스템에 대한 요구사항들을 충족할 수 있는 시스템을 만들 수 있도록 세부 구현한Architecture
    • 특정 비즈니스 영역 내에선 여러 공통점이 있기 때문에 해당 비즈니스 영역 내에서 그 비즈니스가 요구하는 것들을 충족할 수 있는 범용적인 아키텍처를 공유하기도 한다.
  • 종류
    • Data processing applications
      • interruption 없이 하루종일 데이터만 연산하는 프로그램
    • Transction processing applications
      • 데이터베이스에서 유저의 요청을 받아 정보 제공, 업데이트 등의 기능을 갖는 프로그램
      • 유저의 요청을 동시에 처리하지 않고, 순차적으로 처리하여야 한다. (동기화 문제)

      • TPS 프로그램의 개략도

        

        [ user ] → [ 단말 ] n → 1 [ 서버 ] n → 1 [ DB ]

    • Information System Architecture
      • 정보제공 시스템은 여러 계층의 개별 Architecture으로 구성된 범용적 Architecture 를 갖고 있다.
      • 계층의 일부로 Transaction bases system을 보유한다.

      • 개략도

        

      • 하위 사례
        • Web-Based Information System
    • Event processing systems
      • 시스템의 외부의 이벤트에 따라 시스템의 동작이 달라지는 프로그램
    • Language processing systems
      • 사용자의 비정형 입력으로부터 의도를 파악하여 정형화된 데이터로 변환하는 프로그램
      • 하위에 Interpreter 를 두어 언어 처리에 사용한다.

      • 개략도

        

Low Level Design -(Design and Implementation)

• Design and Implementation 개요
  • 실행 가능한 소프트웨어가 탄생하는 단계
• Implementation
  • 디자인한 것을 바탕으로 실제 프로그램으로 실체화 하는 행위
  • Issues (고려해야 할 것)
    • Reuse (cots SW…)
      • 이미 존재하는 소프트웨어를 기반으로 개발하는 것.
      • reuse cost
        • 어떤 외부 SW를 사용할지 고르고 저울질하는 데 드는 시간, 비용
        • 내 시스템에 적용하기 위해 동작을 조정하고, 설계하는 비용
        • SW를 검수하는데에 드는 시간, 비용을 고려해야 한다.
      • Reuse levels
        • object level
          • class level
        • component level
          • class보다 상위
        • system level - cots
          • 개별 동작이 가능한 시스템
        • abstraction level
          • sw를 재사용 하는게 아니라 sw의 컨셉과 본질을 재사용
    • Configuration management
      • 형상관리의 개념
      • 세부 동작들
        • Version management
          • 소프트웨어 의 버전들의 히스토리 보관
        • System integration
          • 프로그래머가 어떤 버전의 컴포넌트를 기반으로 개선해야 할지에 결정할 때 유용한 정보 제공
        • Problem tracking
          • 유저가 버그나 오류들을 제보할 수 있도록 하고, 어느 개발자가 해당 문제 해결에 착수했는지, 언제 그것이 고쳐질지 등
    • Host-target development
      • 대부분의 SW는 그것이 실행될 환경에서 개발되지 않는다. (개발 환경과 사용 환경의 차이)
        • 환경은 하드웨어적인 요소 뿐만 아니라 OS, 지원 SW (DB managing system 등)을 포함한다.

      • Host-target problem에 대한 전방위적 해결법 -CTIP

        

• Build or Buy
  • COTS (commercial off-the-shelf systems)를 구매하여 tkdydgksms rjtdl rksmdgkek.
  • 이를 위해선 Design 단계에서 COTS가 제공하는 기능들을 시스템 req를 충족하는 방향으로 사용할지에 대해 고려해야 한다
• Open-Source Development
  • 개요
    • 소프트웨어의 소스코드를 공개하는 개발 방법
    • sw 개발과 유지보수에 volunteer들이 인터넷을 통해 참여할 수 있다.
    • Free Software Foundation이 선구자
    • 여러 예시 사례들
      • Linux OS
      • JAVA
      • Apache web server
  • principal
    • Source code should be freely available
  • License Models
    • GNU General Public License (GPL)
      • GPL 라이센스를 갖는 코드를 가져와 사용하면 그걸 사용한 sw 전부가 GPL 라이센스를 갖게되어 공개해야 함.
    • GNU Lesser General Public License (LGPL)
      • GPL을 사용한 부분에 한정하여 공개의무를 갖는다.
    • Berkley Standard Distribution License (BSD)
      • 사용에 아무런 의무가 없다.

SASD (Structured Analysis and Structured Design)

C를 이용해 개발하기위한 구조적 분석 설계 방법론

Essential Model(SA) 을 기반으로 Implementation Model(SD)를 만든다.

• SA (Structured Analysis)
  • 개요
    • 시스템 Specification에 대해 사용자의 이해를 용이하게 하기 위한 일련의 설계 기술과 그래픽 도구들의 집합이다.
    • 크고 복잡한 문제들을 작고, 해결하기 쉬운 문제들로 분할하는 Top-Down Divide and Conquer approach
    • 복잡한 SR을 한번에 문서화 하는 것은 어렵기 때문에 순서대로 차근차근 잘라서 표현한다.

  • Essential Model

    시스템이 반드시 해야 할 것에 대한 모델 -어떻게는 관심 없고, 무엇에 초점을 둔다.

    • Environmental model

      시스템의 스코프를 정의한다.

      시스템의 바운더리와 외부 시스템, 환경과의 상호작용에 대해 정의한다.

      • 구성요소
        • Statement of Purpose
          • 개발하려는 시스템의 목적에 대해 간결하고 명확하게 기술된 문서이다.
          • 상위수준(user 등)의 req이다.

          • 예시

            

        • System Context diagram
          • DFD의 일종이다.
          • 시스템과 외부의 경계를 한정짓는 역할, 그들간의 상호작용을 규명한다.

          • 예시

            

        • Event list
          • 시스템에 영향을 주는/받는 외부 이벤트, 자극들에 대한 리스트이다.
          • 종류
            • Flow-oriented event: 입력된 데이터에 의해 촉발되는 이벤트
            • Temporal event: 내부 시계에 의해 촉발되는 이벤트
            • Control event: 외부의 예측 불가능한 이벤트에 의해 촉발되는 이벤트

          • 예시

            

    • Behavioral model

      시스템 내부의 활동과 데이터 구조에 대한 모델이다.

      Functional Requirements에 대해 모델링한다.

      • 구성요소
        • Data Flow Diagram (DFD)
          • 여러 레벨의 DFD로 이루어져 있으며
          • 각 레벨은 전체 시스템의 기능을 분해하여 그것들의 동작을 세부적으로 관찰할 수 있게 한다. (레벨이 높아질수록 기능이 잘게 쪼개진다.)

          • 예시

            

        • Process Specification
          • DFD에 함의되어 있지만, 명시적으로 드러나지 않았던 디테일들을 표현하는 부분이다.
          • 입력, 출력, 알고리즘을 표현하며 슈도코드 형식으로 작성된다.
          • 각 레벨의 DFD를 이루는 모든 프로세스에 대해 작성되어야한다.

          • 예시

            

        • Data Dictionary
          • 데이터에 대한 오해석을 막기 위해 작성된 문서

          • 예시

            

        • State Transition Diagram
          • FSM과 유사하다.
          • 프로세스간 명령흐름을 보여준다.

          • 예시

            

        • Entity Relationship Diagram (ERD)
          • 데이터를 기준으로 시스템과 데이터의 상호작용을 표현한 다이어그램
          • SQL이 그 예시가 될 수 있다.

    • Environmental model과 Behavioral model의 3 + 5개의 구성요소 중 필요한 것을 골라 그리면 된다.

• SD (Structured Design)
  • 개요
    • SA에서 만든 DFD를 Structured Chart로 변환해야한다.
      • DFD의 데이터의 입력과 프로세싱이 어떻게 이루어지는지에 대해 초점
      • DFD에선 말 그대로 지 알아서 데이터가 행동했지만, 실상은 그걸 구현해야 하기에…
    • SA에 입각해 다음과 같은 기능들을 디자인, 구현해야 한다.
      • 예시
        • Information hiding
        • Modularity
        • Low coupling
        • High internal cohesion

  • Structured Chart 예시

    

OOAD (Object Oriented Analysis and Design)

• 개요
  • 여러 시스템을 설계하는 모델을 포함하고 있으며
  • 작은 시스템 개발에 적용하기엔 비효율적이나
  • 여러 그룹이 참여하는 대규모의 시스템을 Design 하는데 적합하다.
    • Design model이 중요한 의사소통 방법이 되어준다.
  • OOA
    • 도메인 컨셉과 그 구성 클레스/오브젝트를 규명하는 단계
    • 뭘 만들어야 하는지 req를 규명하는것도 포함
    • OOA 단계 까지는 시스템의 구조에 대해 확정되지 않은 Black Box 상태
  • OOD
    • 프로그램의 Static 한 오브젝트를 규명
    • req를 만족하기 위해 어떻게 그들이 상호작용을 하는지 규명
    • OOD에서 시스템의 구조에 대해 설계가 이루어짐.

• 프로세스

  다양한 OOAD 프로세스가 있지만 그들은 다음 5가지를 공통적으로 보유한다.

  • 1. Define the contect and modes of use of the system (OOA)
       • 개발할 소프트웨어와 외부 환경경과의 관계를 파악하는것이 중요하다.
       • 시스템이 의도된 동작을 어떤 방식으로 할지에 대해 정하기
       • 시스템이 외부 환경과 의사소통하는 방식에 대한 구조를 설계
       • 시스템이 커버할 영역에 대해 규정 - 도구
       • System Context model
         • 시스템이 속한 환경에 존재하는 다른 외부 시스템들에 대해 표현
         • Ex) System context diagram

         • 예시

           

       • Interaction model
         • 시스템이 동작중에 외부환경과 어떻게 상호작용을 하는지에 대해 표현
         • Ex) Use-case model

         • 예시

           

  • 1. Design the system architectures (OOA)
       • 시스템과 그 상호작용들을 구성하는 주요 components들에 대해 규명

       • architectural pattern을 사용하여 components들을 조직

         예를 들어 layered 구조로 할지, client-server 구조로 할지…

  • 1. Identify the principal system objects(OOA)
       • 시스템을 구성하는 오프젝트들을 규명하는 것.
       • 이 단계는 어떤 왕도가 없다. 도메인에 대한 이해 등 개인의 능력이 중요 - 사용 도구
       • Domain Model - 접근 방법들
       • 시스템에 대한 기술서에 문법적 접근하여 오브젝트를 규명하는 방법
       • 관습에 입각한 접근법
       • use-case 분석을 통한 시나리오 기반 접근법
  • 1. Develop design models
       • 오브젝트간 관계(상속 등)에 대해 디자인하는 모델
       • 2가지 타입의 모델
       • Structural model
         • Class diagram, Object diagram, Package diagram
         • 시스템의 static한 구조를 오브젝트와 그들간 관계를 통해 묘사
         • Subsystem Models
           • 오브젝트보다 상위 개념인 class들간의 논리적 연관 관계에 대한 모델
           • Logical model, Package diagram 등 이 사용될 수 있음

           • 예시

             

       • Dynamic model
         • 시스템의 실행시 오브젝트 간 상호작용에 대한 묘사
         • Sequence diagram, State chart diagram
         • Sequence Models
           • 오브젝트간 상호작용에서 발생하는 사건들에 대한 모델
           • UML의 Sequence diagram이 사용될 수 있다.

           • 예시

             

         • State Machine Models
           • state 기반 시스템엔 유용하나
           • 시스템, 오브젝트의 runtime 동작들에 대해 High Level로 묘사할 때 유용하다.
           • Activity 기반 시스템에선 이것 보다 Activity diagram을 사용
  • 1. Specify object intefaces
       • 오프젝트의 interface들이 명시되어야만 다른 오브젝트를 디자인하는 것을 동시에 진행할 수 있다.
       • UML의 Class diagram 이 사용될 수 있다.
       • 예시

       

Software Testing ($\in$ Validation & Verification)

• 개요
  • Testing의 목적
    • 프로그램이 의도대로 동작을 하는지 검사
    • 프로그램이 실전에 투입되기 전에 그 것의 결함을 잡아내기 위해
  • Verification & Validation process 의 일환이다.

• Two types of Program Testing

  

  • Validation testing
    • 소비자의 진짜 니즈를 기준으로 스펙과 코드가 작성되었는지 검사 (진짜 니즈는 자기도 모를 수 있다…)
    • 좋은 test는 프로그램이 소비자의 의도대로 작동하는가에 대해 검증을 하는 test이다.
  • Verification testing
    • 스펙을 기준으로 프로그램이 구현되었는지 검사
    • 좋은 test는 프로그램이 spec에 명시되지 않은 동작을 하거나 부정확한 동작을 한다는 것을 증명하는 test이다.
    • Defect testing
      • Defect: spec 대로 동작하지 않는 것
      • 원인: 1. 코드가 잘못 작성됨
        1. spec이 잘못 작성됨(아주 가끔)
• V-Model of V&V Activities

  • 개략도

    

    

  • V&V confidence ( $\simeq$ quality level )
    • V&V의 목표
      • 시스템이 목적적합함을 증명하는 것
    • confidence 결정 요소
      • Software purpose
        • 소프트웨어가 사용집단에게 얼마나 중요한지
      • User expectation
        • 유저가 소프트웨어에 갖는 기대가 다르다.
      • Marketing environment
        • 시장은 완벽한 동작을 하는 소프트웨어보다 당장 사용할 수 있는 소프트웨어를 원할 수도 있다.
  • SW V&V의 테크닉 3 + 1
    • 3 Axes of V & V
      • Optimistic Inaccuracy (Testing)
        • 테스팅은 청소와 같다. 끝이 없다. 모든 경우의 수를 testing 하는 것은 불가능하다는 것이 증명되었기에 완벽한 테스팅은 불가능하다. 그렇다면 어떤 수준에서 어느 정도로 테스팅을 해야 하는 가? 가 중요하다. 이러한 기준을 V&V confidence 라고 한다. V&V confidencerk 높을 수록 테스트 강도가 강해지고, 해야할 테스트가 많아진다. 결과적으로 양질의 SW가 탄생한다.
        • Optimistic 인 이유
          • Fail이 나오면 fail이 맞고 pass가 나오면 pass가 맞다.
        • 모든 오류를 잡지는 못한다.
        • 구성
          • Unit testing
          • Intergation testing
          • System testing
      • Pessimistic Inaccuracy (Static code analysis)
        • 코드가 실행되지 않는 상태에서도 Testing은 할 수 있다는 장점이 있다.
        • Pessimistic(염세적인)이유
          • false alarm이라는 요소가 있다.
            • 문제가 있다고 경고를 받아도 문제가 없는 경우가 30%나 된다.
      • Simplified Properties (Model checking)
        • 평소의 작동에서는 문제를 발생하지 않다가 특정 조건들이 만족되면 발생하는 오류들을 잡아 낼 수 있다.
        • 수학적으로 모델링을 하여 SW의 빈틈을 찾는 것 같다.
    • +1: Review
• Software testing stages 종류
  • Development testing
    • 개발 중 지속적으로 하는 테스팅
    • bug와 defect를 적발하는게 목적
  • Release testing
    • 어떤 기점마다 하는 테스팅
    • 시스템의 버전이 나올때마다 실행됨
      • user 릴리즈의 버전말고 내부 버전을 뜻함
  • User testing
    • 거의 완성단계에서 user의 사용환경에서 테스팅 하는 것

  • Testing Process 개략도

    

• Software testing stages
• Development testing 상세
  • 개요
    • 모든 테스트는 시스템을 개발하는 팀에 의해 진행된다.
  • 구성
    • Unit testing $\in$ Verification = module testing = component testing
      • 개요
        • 테스팅의 기준이 되는 문서가 없는 경우가 많다. 있으면 process specification 같은 것 정도
        • Individual program unit or object classes are tested
        • Unit testing should focus on testing the functionality of objects or methods.
        • Testing 범위
          • 상기 언급된 바와 같이 Unit을 단위로 하며 Unit은 다음을 지칭한다.
            • Object 내의 Individual function or methods
            • Object classes 전체가 되기도 한다.
            • 인터페이스와 결합한 Unit: Composit components
      • Automated Testing
        • unit testing은 가능하다면 automate할 것을 권장한다.
        • 이를 돕기 위해 여러 Unit testing Frameworks들이 있다.
      • Unit Test Case
        • Two types of unit test cases
          • Positive -정상적인 입력에 대한 테스트
            • 프로그램의 일반적인 동작에 대한 케이스
            • Unit의 동작이 정상적으로 이루어지고 있는지를 보여줄 수 있는 케이스
          • negative - 비정상적인 입력에 대한 테스트
            • 경험적으로 작성되어 오류가 있을 법한 특정 상황에 대한 케이스
            • Unit의 동작이 정상적이다는 것을 증명하기 위한 의도적으로 설계한 정상입력들로 구성된 케이스
      • Unit Testing Strategies
        • Partition testing
          • 데이터의 처리에 구간을 나누어 처리하는 Unit 들에 대해 구간과 그 경곗값들을 테스팅하는 전략
        • Guideline-based testing
          • 가이드라인에 참고하여 테스팅 케이스를 정하는 테스팅
          • 경험적으로 어떤 어떤 부분에서 오류가 발생할 수 있다, 자주 발생하더라 등의 내용을 담은 가이드 라인을 참고하여 테스팅 케이스를 설계
    • Integrated testing $\in$ Verification
      • 개요
        • SDS를 기준으로 그것을 충실히 반영하는지 검사한다.
        • Component 들의 복합체 단위로 테스팅이 이루어진다.
        • 컴포넌트간 동작이 원활하게 이루어지는지, 둘 을 중개하는 interface가 정상적으로 일을 수행하는지 검사한다.
      • Test 중점 사안
        • Components 간의 상호작용에 초점을 둔다.
        • Component Interface가 의도한대로 작동하는지 테스팅한다.
        • 당연하게도 이 단계에서 검사되는 Components들은 모두 Unit test를 통과했어야 한다.
    • System testing $\in$ Verification
      • 개요
        • SRS를 기준으로 그것을 충실히 반영하는지 검사한다.
        • 시스템을 구성하는 컴포넌트의 전체 또는 일부를 묶어서 테스팅 한다.
        • 시스템의 부분을 테스팅하는게 아니라 온전한 하나의 시스템 전체의 동작을 테스팅한다.
      • Testing 중점 사안
        • Tests the emergent behavior of a system
          • 전에 언급되었던 내용! 시스템을 한꺼번에 뭉쳐놓고 보아야 관측되는 req → Emergent behavior
      • System testing 은 Collective process로 Cots SW나 다른팀에서 개발한 시스템 파츠들이 모두 한데 묶여서 테스팅을 하는 단계이다.
      • 테스팅만 전문적으로 하는 비개발자 팀에 의해 테스팅이 될 수 있다.
      • Use Case와 Sequence diagram들이 System testing 단계에서 사용될 수 있다.
    • Regression testing
      • 시스템이 이전에 system testing을 통과한 적이 있고, 이후 변경사항이 있을때 실행되는 테스팅이다.
      • 모든 테스팅을 다 할수 없기에 변경으로 영향을 받는 기능들을 체크한다거나 변경으로 추기된 기능을 테스팅하게 된다.
      • development 에서도 할 수 있고 maintenance시에도 수행될 수 있다.
      • 어려운 이유
        • 수정으로 영향을 받는 부분들(Dependency)을 찾는게 어렵다.
        • 테스트 케이스가 수정으로 인해 변경되어야 할지 측정하고 어떻게 변경해야할지 판단해야 한다.
• Software testing stages
• Release Testing 상세
  • 개요
    • 개발팀 외부에서 사용되기 위한 프로그램의 릴리즈를 테스팅하는 것
    • 주로 Black-box testing 으로 이루어진다.
      • 시스템의 내부구조를 알고 테스팅하기보단 외부로 드러나는 feature들을 테스팅
    • System testing의 일종으로 볼 수도 있다.
  • System testing 과 차이
    • 릴리즈 테스팅은 - 시스템 개발에 참여하지 않은 개발팀과 독립적인 인원들에 의해 테스트 되어야 한다.
    • 시스템 테스팅은 - 시스템 의 bug와 defect를 찾는 verification에 집중하여야 한다.
    • 릴리즈 테스팅은 - 시스템이 req를 충족하는지에 대한 validation에 집중한 테스트여야 한다.
  • Performance tests
    • 시스템의 퍼포먼스가 저하되는 지점을 관측하기 위해 테스팅 강도를 점차 높혀가는 테스트
  • Stress test
    • 어느 정도의 부하에서 시스템이 망가지는지에 대해 알아내기 위한 테스트
• Software testing stages
• User Testing 상세
  • User Acceptance testing
  • 세가지 구분
    • Alpha testing
      • 개발팀에서 개발자의 환경에서 유저가 테스팅하는 것
    • Beta testing
      • 사용자가 자신의 환경에서 테스팅을 하는 것
    • Acceptance testing
      • SW가 배포될만한 수준인지에 대해 고객이 테스팅하는 것
      • 커스텀된 시스템 환경에서 이루어진다.

Software Evolution (maintenance)

• 개요
  • Software change 는 다음과 같은 이유로 불가피하다.
    • SW가 사용되며 새로운 req가 발생한다.
    • 사용되는 비지니스 환경이 변화한다.
    • Error가 발생하면 당연히 고쳐야 한다.
    • 새로운 장치가 시스템에 추가될 수 있다.
    • 시스템의 퍼포먼스나 안정성이 개선되어야 한다.

  • 소프트웨어 생명주기

    

    • Evolution
      • 새로운 기능이 추가되는 것
    • Sevicing
      • 버그 픽스 정도의 변경
      • 새로운 기능의 추가는 없음
    • Phase-out
      • 사용은 되지만 더이상 아무런 유지보수가 없는 상태
• Evolution Processes
  • Software evolution process는 다음의 순환적인 과정을 거쳐 진행된다.
    1. Change identification process
       • 뭘 고칠지 정한다.
    2. Change proposals
       • 고칠것에 대한 Committee의 허가를 받아야한다.
         • Committee는 변경 비용, 시간 등을 Matric & Measurement 방법으로 측정하고 판단한다.
    3. Software evolution process
    4. New system

  • 개략도

    

• Urgent Change Request
  • 긴급하게 수정해아 할 것이 있으면 절차를 간소화하여 신속하게 수정한다.
  • impact Analysis 없이 일단 급한불을 끄는 식으로 진행된다.

  • 개략도

    

• Agile 에서의 Evolution
  • 에자일은 기본적으로 Incremental 개발 방법을 추종하기에 개발과정과 evolution과정의 전환이 seamless 하다.
    • 개발 도중에도 evolution이 일어난다.
  • 개발하는 팀과 Evolution하는 팀이 다른경우에 문제가 발생할 수 있다.
    • agile 방법론 자체가 문서화된 자료가 없기에 인수인계가 어려워질 수 있다. → Handover Problem
• Legacy Systems
  • 개요
    • 옛날 기술 옛날 언어로 만들어진 SW인데 잘돌아가는 시스템
    • 레거시 시스템은 코드 요소요소에 비즈니스에 종속적인 코드들이 박혀있어서 해당 코드를 수정할 경우 그 영향이 어디까지 미칠치 비즈니스 종속적인 feature의 영향을 파악하는게 매우 힘들다. →이를 Socio-technical system이라고 지칭한다.
  • Legacy System Replacement or Change 가 어려운 이유
    • Legacy System을 새것으로 갈아치우는 것은 매우 위험하고 비용이 많이 든다.
      • 이유
        • 아직 시스템을 사용하고 있기 때문
        • System specification이 없다.
        • 비즈니스 프로세스와 프로그램간의 유착
        • 새로운걸 개발하는것은 원래 비쌈…
    • Legacy System을 수정하는 것 조차도 비싸다.
      • 이유
        • 일정한 코딩스타일이 없다. (Art!)
        • 구시대의 프로그래밍언어를 사용하고 개발진들은 모두 퇴사하거나 사망
        • 시스템 구조가 옛날것
        • 문서가 없다.
  • 4가지 대응 방법
    • A. Scrap the system completely
      • 더이상 필요하지 않는 시스템일 경우 싹 들어낸다.
    • B. Continue maintaining
      • 버틸만 하면 유지보수로 버틴다.
    • C. Transform the system by re-engineering
      • 부분적으로 다시 만들어 바꿔낀다.
    • D. Replace the system
      • 아예 해당 시스템을 다시만든다.
  • Legacy system assesment
    • 위 4가지 대응방법 중 무엇을 선택할지 결정하는 것
    • 선정기준
      • Business value
      • System quality
    • 기준에 따른 4가지 카테고리
      • Low quality Low business value
        • Scrap해버려
      • Low quality High business value
        • 최악, 중요한데 유지비용이 비싸다.
        • 부분적으로 다시 만드는 re-engineering
        • 또는 적절한 SW가 있을 경우 replace
      • High quality Low business value
        • Cots로 replace 하거나 scrap 또는 maintain
      • High quality High business value
        • maintain
• Software Maintenance
  • 개요
    • 소소한 기능 추가
    • 환경변화에 대한 adaptation
    • 버티기 단계
    • 주로 한번 만들면 오래 사용하는 custom SW에서 이루어진다.
  • Maintenance의 종류
    • Fault repairs
      • 버그 수정, defect 수정
      • 항상 해야한다.
    • Environmental adaptation
      • 자바 버전업 등 open source SW의 업데이트가 있을 시 수행
      • 실행 환경의 변화(OS, 하드웨어 변경 등)
    • Functionality additionand modification
      • 새로운 req가 추가되어 그것을 충족하기 위한 수정…
  • Maintenance cost 는 개발 비용보다 월등히 높다.
    • 2 ~ 100 배 정도…
    • 오래된 SW일 수록 높은 유지비용이 들어간다.
• Software Reengineering
  • Reengineering 이란?
    • 기능에 일절 변경없이 legacy system을 다시 작성하는 것
    • 새로운 기능의 추가는 되는데! 기존 기능의 변경은 절대 허용되지 않는다.

  • 개략도

    

  • Process 들
    • Source code translation
      • 기존 코드를 새로운 언어로 번역한다.
    • Reverce engineering
      • 프로그램을 이해하기 위해 프로그램을 분석
      • 자기보다 상위단계의 어떤 것에서 자기 단계의 것을 끌어 내는것 Ex. 코드 → req
    • Program structure improvement
      • 기존 프로그램의 구조를 이해하기 쉽게 재설계
        • 이걸 기계가 아닌 사람이 하면 refactoring이라고 한다. refactoring: 기능은 그대로 두고 코드의 퀄리티 (understandability, maintenability) 를 높이는 것
    • Program modularization
      • 문서와 Program structure improvement의 결과를 가지고, 총괄적으로 프로그램을 재편하는 것
    • Data reengineering
      • 시스템의 data 구조를 clean up또는 재설계하는 것
  • Refactoring과 Reengineering의 차이
    • Reengineering은 개발 완료 후 maintenance 단계에 수행되지만
    • Refactoring은 전 development부터 evolution까지 단계에서 지속적으로 이루어진다.