4 분 소요

Software Engineering

Software Engineering 정의

  • IEEE: 체계적이고 정량화 가능한 방식으로 소프트웨어를 개발·운영·유지보수하는 것
  • Ian Sommerville: 소프트웨어 생산의 모든 측면을 다루는 공학적 분야
  • David Parnas: 다인에 의한 다버전 소프트웨어의 구성

Software Engineering 필요성

  • 소프트웨어 개발은 어렵다.
  • Easy systems: 1인 개발, 실험용
  • Hard systems: 다수의 개발자와 이해관계자, 제품 수준
  • 작은 시스템에서의 경험은 대형 시스템 개발에 도움이 되지 않음

Software Engineering 시작

  • 1968년 NATO 소프트웨어 공학 회의 (독일 Garmisch)
  • 복잡한 시스템에 대한 설계 및 생산의 이론과 기법이 부족함을 인식
  • 진행 상황 측정의 어려움도 주요 문제 중 하나로 언급

Topics in SE

  • 개발 프로세스: 요구 분석, 모델링, 설계, 구현, 테스트
  • 프로젝트 관리: 조직, 도구, 리스크, 일정 계획, 품질 관리
  • 형상 관리: 무엇을 생산했는지보다 어떻게 생산했는지가 중요

SE 오늘날 중요성

  • 소프트웨어의 수요 증가
  • 시스템의 복잡성과 크기 증가
  • 시스템 비용에서 소프트웨어가 차지하는 비중 증가

SW 의 unique한 특성

  • 비가시성 (Invisible)
  • 이해, 분석, 평가하기에 어려움
  • 변경이 쉬움

하드웨어는 쉽게 마모하고 부품의 수명이 끝나면 실패율(Failure Ratio)이 높아짐.

  • Brooks’s Law

: Adding more people then lengthens, not shortens, the schedule!"

(SW에서는 사람을 늘리면 일이 더 많아진다. )

Software Development Process

소프트웨어 개발 절차 : interrelationship among the activities

  • 여러 활동(요구 분석, 설계, 테스트 등)의 순서와 빈도 정의
  • 각 활동의 산출물(workproduct) 정의

Software Modeling

  • 모델 = 시스템의 추상화 (ignoring irrelevant details)
  • 모델링은 복잡성을 줄이기 위한 수단
  • UML이 모델링의 사실상 표준

UML 에 대해서는 다음 포스트 참고

Software Architecture

  • 설계 초기 단계에서 시스템의 성능, 신뢰성, 확장성 등을 고려
  • 시스템의 ‘큰 그림(Big Picture)’ 설계

early stage에서 정하기에 한 번 결정하면 바꾸기가 어려움.

Software Design

  • 핵심 개념: 추상화, 정보 은닉, SOC 인터페이스, 모듈화

SOC(Separation of Concerns) : 한 모듈(클래스, 함수)은 하나의 ‘관심사’만 다뤄야한다.

  • 측정 지표: 응집도(cohesion), 결합도(coupling)
  • 설계 원칙:
    • SOLID (단일 책임 원칙, 개방/폐쇄 원칙 등)
    • 상속보다는 조합 지향

Verification & Validation

  • 제품이 요구사항을 만족하는지 확인
  • Verification: 제대로 만들고 있는가?
  • Validation: 필요한 것을 만들고 있는가?
  • Dijkstra: “테스트는 버그 존재를 보여줄 수는 있어도, 부재를 증명할 수는 없다” => 얼마든지 버그는 있을 수 있다.

Testing 종류

  • Black-box testing : 구성과 로직을 모른채 테스트
  • White-box testing : 과정을 알고 있는 가정하에 테스트

Software Development Process

이 부분에서 자세히 요약해놓았다.

용어 정리

  • Project → 여러 활동(Activities)으로 구성
  • Activity → 여러 작업(Tasks)으로 구성
  • Task → 자원(참여자, 시간, 장비)을 소비하여 작업 산출물(Work Product) 생성
  • Work Product → 시스템, 모델, 문서 등

Software Development Activities 의 절차는 아래와 같다.

software development

Software Development Process

  • 소프트웨어 개발을 위한 활동과 그 관계 정의
  • 무질서한 개발 과정에 질서를 부여
  • 다른 이름: SDLC (Software Development Life Cycle)

Process Model

정의 : 소프트웨어 개발 과정을 추상적으로 표현한 것으로 SDLC 모델이라고도 함.

모델 유형

  • Sequential Models

    • Waterfall Model
    • V Model

  • Iterative Models

    • Spiral Model
    • Unified Process (UP)

Sequential은 작업의 반복을 가정하지 않는 특징이 있다.

Iterative는 요즘의 SW 개발 형식이다.

Plan-driven vs Agile processes

Plan-driven Agile
사전에 계획 수립 점진적 계획 수립
고정된 요구사항에 강함 변화에 유연하게 대응 가능
문서 중심 고객 피드백 중심
대부분의 실무는 혼합 방식 사용  

Waterfall Model

정의 : A classic life cycle model

  • 선형 단계 (분석 → 설계 → 구현 → 테스트 등)
  • 각 단계는 검토 후 다음 단계로 진행 : 전 단계로 loop back 하려면 많은 cost가 사용.
  • 문서 중심, 계약 기반 프로젝트에 적합

장점

  • 명확한 단계 구분, 관리하기에 좋고, 큰 시스템에 적합

요구조건이 이해하기 쉽고, 기술의 변화가 거의 없을 경우에 사용하기에 좋다.

단점

  • 요구사항을 초기에 모두 확정해야 함, 변경에 매우 취약함.
  • 문서량 과다, 리스크 큼 (Big Bang 방식)

V Model

정의 : 개발 단계와 테스트 단계의 1:1 매칭 을 한 모델으로, 각 개발 단계에 해당하는 검증 활동 존재

  • Requirements analysis -> System testing
  • High level design -> Integration testing
  • Detailed design -> Unit testing

장점

  • 테스트 계획이 일찍부터 존재 → 높은 품질

단점

  • Waterfall의 단점을 여전히 가짐 (변화에 약함)

Waterfall과 V model의 차이를 나타내면 다음과 같다.

Model (Waterfall, V)

여기서 중요한 점 : Coping with Change

  • 요구사항은 항상 변한다
  • 변화는 재작업(rework)을 야기하고 비용 상승으로 이어짐
  • 기술, 비즈니스 환경의 변화 대응 필요

Prototype

  • 잘 이해되지 않은 주요 기능만 프로토타입 제작
  • 빠르게 사용자 피드백 획득
  • 품질보다 속도 우선 (“Quick & Dirty”)

장점

  • 요구사항 안정화

  • 본 개발 전에 이해도 상승

단점

  • 비용, 일정 증가 가능

Prototype은 실제 제품에 포함되는 것이 아니기에 따로 하나 더 만든 것과 같음.

Iterative and Incremental Development

정의 : 반복적으로 점진적으로 기능을 추가해가며 개발 (예) UP, Agile.. etc

Delivers a series of releases that provides progressively more functionality for the customer as each increment is delivered.

장점

  • 유연성, 빠른 피드백, 위험 분산, 품질 향상

단점

  • 전체 설계 최적화 어려움
  • 재작업 증가, 비용 증가 가능성

Spiral Model

Spiral model

정의: 위험 중심 개발 모델(Risk-driven software model)

  • 고정된 단계 없이 위험에 따라 유연하게 반복
  • 각 루프마다 목표 설정, 위험 평가, 개발 및 검증, 계획 수립

단계 구성 : Objective setting -> Risk assessment & reduction -> Development and validation -> Planning 의 반복

cycle을 계속 수행한다. (Spiral이라는 이름이 붙은 이유)

프로젝트의 성격에 따라 cycle의 수가 다르다.

UP(Unified Process) & RUP

  • 반복적(iterative), 아키텍처 중심, 유스케이스 기반 개발

  • UP의 4단계 과정

  1. Inception – 범위 정의, 타당성 분석
  2. Elaboration – 위험 완화, 아키텍처 수립
  3. Construction – 전체 시스템 개발
  4. Transition – 사용자에게 시스템 배포

waterfall 단계랑 다른 것이기에 구별 필요하다.

항목 Waterfall Model Unified Process (UP)
개발 흐름 선형적 (일방향 진행) 반복적, 점진적 (Iterative & Incremental)
단계 간 이동 이전 단계로 되돌아가기 어려움 반복(iteration)을 통해 언제든 조정 가능
요구사항 처리 초기에 모든 요구사항을 정의하고 고정 요구사항은 점진적으로 정리, 변경 가능성 반영
위험 대응 위험 대응이 늦음 (문제는 후반에 발견됨) 초기 반복에서 위험 식별 및 완화 가능
개발 산출물 제공 프로젝트 끝에 한 번에 제공 (Big Bang) 각 반복마다 작동 가능한 산출물 제공
  • UML: 시각 언어 (in the next post)
  • UP: 프로세스 프레임워크
  • RUP: 상용화된 UP 확장판

참고

Concurrency, Locks

8 분 소요

이번 포스트는 OS의 Concurrency와 Locks에 대해 다룬다.