[소프트웨어공학] Lecture 1. SW 공학과 정보 시스템

경희대학교 허의남 교수님의 소프트웨어공학 수업을 기반으로 정리한 글입니다.

 

수업 개요

• 정보 시스템의 개발에 필요한 체계적 단계를 학습함으로써, 올바른 개발자로 성장하게 함
• SW 공학의 학문적 성격과 SW Lifecycle 전 주기적 운영 및 관리 방법 습득
• 시스템을 분석하는 능력을 배양함으로써, 시스템 분석가 또는 SW 아키텍처로서 갖추어야 할 지식 확보
• 각종 분석 방법 및 설계 단계를 프로젝트 수행을 통해 학습

 

1.1. 과학과 공학

• 자연과학(natural science): 자연의 법칙을 탐구하는 것
• 공학(engineering): 자연과학이 발견한 자연의 법칙을 응용 -> 인류의 편익을 위해 무엇인가를 생산하는 전문분야
• 과학기술: 공학 + 자연과학
• 공학 & 자연과학은 서로 보완, 상호 의존적인 관계
• 자연과학 - 근본적인 지식의 탐구에 관련
• 공학 - 실제 문제의 해결과 '더 나은 삶의 추구'를 위한 과학지식의 응용과 관련
• 공학은 당면한 문제를 해결하기 위해, 자연과학의 지식을 필요로 함 -> 이는 다시 자연과학의 분야에 영향 -> 공학과 자연과학은 서로 보완하며 발전

 

1.2. 시스템 공학

• 시스템: 어떤 목적과 기능을 수행하기 위해, 유기적인 관계를 맺으며 함께 작용하는 요소들의 집합
• 시스템은 여러 요소들로 이루어진 특정한 집합
• 각 요소는 다른 요소들과 관계를 가지고, 시스템의 공동 목표를 위하여 함께 작용
• ex) 사람, 컴퓨터 시스템, 자동차 운전 시스템
• 시스템 공학: 시스템의 개발과 운용, 유지보수를 합리적으로 행하기 위한 사고방법, 절차, 조직 및 기법 등을 총칭한 것
• 시스템 공학의 기술적인 측면: 시스템을 구성하는 물적 요소의 적합성과 이의 효과적인 조합에 의한 효율의 극대화를 추구
• 시스템 공학의 관리적인 측면: 시스템 개발에 관련된 업무가 제대로 이루어지도록 인원, 설비, 자재 등에 대한 계획과 통제를 행하는 관리기술

 

1.3. 소프트웨어 공학 정의

• 소프트웨어 공학: 실제 효과적으로 작동할 수 있는 우수한 소프트웨어를 최적의 비용으로 얻기 위해 사용하는 견고한 엔지니어링 원칙
• 경영학, 경제학, 전산학 및 시스템 공학적인 문제 해결 원리에 기초
• 허용하는 예산과 시간 범위 안에서 효과적으로 소프트웨어 제품을 개발하고 유지, 보수하는 활동과 관련된 기술적, 관리적 원리
• 주요 목표: 소프트웨어 제품의 품질 향상 & 생산성 및 사용자 만족도 증진
• 소프트웨어 시스템의 개발, 운용, 관리에 적용되는 체계적인 접근 방법

 

1.4. 정보 시스템

정보 혁명 

• 컴퓨터와 산업화의 결합
• 행정, 금융, 운송, 교육, 문화 등

정보 시스템의 정의

• 업무를 처리하기 위해 정보를 모으고 처리하고 저장하고 제공하기 위한 관련 component의 집합체
• 조직이 기본적인 비즈니스 기능들을 수행하는 정보시스템을 구축하고 유지관리하는 방법
• 주요 목적: 주요한 비즈니스 업무들에 대해 소프트웨어 솔루션을 적용 -> 직원들의 업무 효율성 향상
• 성과를 얻기 위해 -> 구조적인 접근 필요

정보 시스템의 요소

• 시스템 경계
• 입력, 출력
• 서브시스템(process)
• 제어 메커니즘(제약)
• 저장장치

 

• 급여 시스템

정보 시스템 특성 요소

• 구성요소(component)
• 상호연관성(interrelated components)
• 경계선(boundary)
• 목적(purpose)
• 환경(environment)
• 인터페이스(interfaces)
• 제약조건(constraints)
• 입력물(input)
• 산출물(output)

정보 시스템과 비즈니스

• 합리적 활동에 중요한 자산

정보 시스템의 종류

• ERP 시스템
• 트랜잭션 처리 시스템
• 의사결정 지원 시스템

ERP는 전사적 자원 관리(enterprise resource planning)의 약자입니다. 
HR, 제조, 공급망, 재무, 회계 등 성공적 기업 운영에 필요한 도구 및 프로세스 일체가 포함된 소프트웨어 시스템

출처: https://www.oracle.com/kr/erp/what-is-erp/

 

1.5. 분석과 설계

시스템 분석

• 정보 시스템이 "무엇을"해야 하는지 자세히 이해하고 명세로 나타내는 작업
• 시스템 분석가(systems analysts): 아래 정보를 바탕으로 분석과 설계 수행
  • 조직의 목표, 구조, 프로세스에 대한 이해
  • 이익을 위해 어떻게 정보 기술을 활용하는지에 대한 지식

시스템 설계

• 정보 시스템이 "어떻게" 구현되어야 하는지 자세히 나타내는 작업

소프트웨어 개발

• 비즈니스 니즈에 맞도록 설계하고 구축 -> 사용자에게 배포
• 고객이 설명한 요구 - 분석하여 이해한 요구 - 설계한 요구 가 서로 다를 수 있음

IT 프로젝트 실패 사례

• 맥도날드 이노베이트 프로젝트
  • 글로벌 ERP application 개발
  • 120여개국의 3만여 매장 연결
• 영국의 국가 보건 서비스 IT 현대화 프로젝트
  • 100억 달러의 투입
  • 여러 업체에 맡겨 인터페이스 문제
  • 의료 서비스 중단
• 덴버 공항의 자동 수화물 처리
  • 짐 카트와 시스템 동기화 문제
• 한국 통신의 고객 통합 시스템
  • 외주 관리 및 통합의 문제

 

시스템 분석 및 설계: 핵심 개념들

• System: data를 information으로 변화시키며 다음과 같은 요소들과 관련
  
  • hardware 및 system software
  • 문서 및 교육 자료
  • 시스템과 관련된 직무
  • 부정 및 도난 방지를 위한 통제 software
  • 업무 수행을 위해 software를 사용하는 사람들

 

1.6. 시스템 개발 과정

시스템 개발 생명주기(System Development Life Cycle: SDLC)

• 정보 시스템 개발 단계들을 관리하는 데 사용되는 일련의 단계들
  
  • 계획
  • 분석
  • 설계
  • 구현

계획

• 왜 시스템을 구축해야 하나?
• 프로젝트 팀을 어떻게 구성할 것인가?
  • 타당성 분석 - 기술적, 경제적, 조직적 타당성
  • 작업 계획 수립
  • 팀 조직 수립
  • 프로젝트 관리 계획
• 결과물: 프로젝트 계획서

분석

• 시스템을 위하여 무엇을 만들 것인가?
• 질문 - 누가 사용? 시스템이 무엇을 해야 하나? 언제 사용?
• 작업 - 분석 전략 수립(Strength Weakness Opportunity, Threat; SWOT 분석), 요구 수집, 문서화
• 결과물: 시스템 제안서

설계

• 시스템을 어떻게 구축할 것인가?
• 시스템의 동작을 보고 결정
  • UI, 입력 양식, 보고서
  • 프로그램
  • DB, 파일
• 설계 전략 수립
• 아키텍처 설계
• 데이터 설계
• 프로그램 설계
• 결과물: 시스템 설계 명세서

구현

• 완성된 시스템의 설치와 지원
• 구축 또는 패키지 구입으로 설계를 현실화
• 작업 단계
  • 시스템 구축과 테스트
  • 시스템 설치, 전환
  • 지원 계획
• 결과물: 새 시스템, 유지보수 계획

 

1.7. 방법론

모델

• 실세계를 특정한 관점으로 표현한 것
• ex) 지도, 흐름도, 자료흐름도, 엔티티 관계도, 구조도, 사용 사례 다이어그램, 클래스 다이어그램...

도구

• 설계, 구현, 유지보수, 테스트 등 소프트웨어 생산에 도움을 주는 툴

기술

• 작업 단계에 사용하는 기술
• ex) 프로젝트 관리 기술, 인터뷰 기술, 데이터 모델링, 구조적 분석

 

	구조적 방법론	정보공학 방법론	객체지향 방법론
프로그램에 대한 관점	프로그램 = 함수 + 자료	프로그램 = 자료 + 함수 (어떤 자료를 가지고, 뭘 처리하는지)	프로그램 = 클래스 + 클래스 + ... 클래스 = 자료 + 함수
설계 관심사	함수 위주	자료 위주	클래스 위주
설계의 핵심	모듈	엔티티	객체
중심 방법	프로그래밍 기법	기업의 전략 및 산출물 중심	설계의 표현

 

1.8. 프로세스

• 생명 주기 -> software 개발의 성패에 영향을 미치는 중요한 요소
• 소프트웨어를 개발해 나가는 단계나 과정
  • concept를 정하는 것부터 소멸될 때까지
  • 몇 달 또는 몇 년이 걸릴 수 있음
• 각 단계의 목표
  • 명확한 작업 단계
  • 손에 잡히는 결과
  • 작업의 검토
  • 다음 단계의 명시
• Code-and-Fix
  • 생명 주기가 없음

폭포수 모델

• 각 단계까 다음 단계 시작 전에 끝나야 함
  
  • 순서적 - 각 단계 사이에 중복이나 상호작용이 없음
  • 각 단계의 결과는 다음 단계가 시작되기 전에 점검
  • 바로 전단계로 피드백
• 단순하거나 응용 분야를 잘 알고 있는 경우 적합
  • 한 번의 과정, 비전문가가 사용할 시스템 개발에 적합 

 장점

• 프로세스가 단순 -> 초보자 쉽게 적용
• 중간 산출물 명확, 관리하기 좋음
• 코드 생성 전 충분한 연구와 분석 단계

단점

• 처음 단계 지나치게 강조 시 -> 코딩, 테스트가 지연
• 각 단계의 전환에 많은 노력
• prototype & reuse의 기회가 줄어듦
• 소용 없는 다종의 문서를 생산할 가능성 있음

적용

• 이미 잘 알고 있는 문제나 연구 중심 문제에 적합
• 변화가 적은 프로젝트에 적합

 

병렬 개발 모델

• 폭포수 모형의 변형 -> 대규모 시스템을 쪼개어 병렬로 진행

 

프로토타이핑 모델

• 프로토 타입(quick and dirty)의 적용
  
  • 사용자의 요구를 더 정확히 추출
  • 알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작

프로토타이핑 도구

• 화면 생성기
• 비주얼 프로그래밍, 4세대 언어 등

공동의 참조 모델

• 사용자와 개발자의 의사소통을 도와주는 좋은 매개체

프로토타입의 목적

• 단순한 요구 추출 - 만들고 버림
• 제작 가능성 타진 - 개발 단계에서 유지보수가 이루어짐

단점

• 오해, 기대심리 유발
• 관리가 어려움(중간 산출물 정의가 난해)

적용

• 개발 착수 시점에 요구가 불투명할 때
• 혁신적인 기술을 사용해보고 싶을 때

진화적 모형

• 여러 버전으로 나누어 순차적으로개발

장점 

• 유용한 시스템을 빠른 기간 내에 사용자의 손에 들려줌
• 중요한 추가 요구를 조기에 발견

단점

• 의도적인 미완성 시스템을 가지고 작업하기 시작
• 로드맵을 다 그려야 함

 

애자일 모델

• 폭포수 개발 모델이 SW 개발 모델로 적합한가? -> 예정대로 진행되지 않는 상황
  • 사용자 요구 파악과 명세의 어려움
  • 요구 변경을 수용하기 어려움
  • 일정을 못 맞출 위험
  • 품질 확보가 어려움
• 정확한 요구를 상대방에게 전달하기 어려움 -> 요구사항 정의로부터 완제품에 도달할 때까지 여러 과정
• 결함이나 필요한 변경 사항을 추가하는 경우 -> 일정이 지연
• 변경에 필요한 비용 -> 뒤로 갈수록 커짐
• 프로그래밍 단계까지 미루고 있다가 프로젝트 종료 시점에 테스트 -> 품질 확보 어려움
• 요구 분석, 설계 작업에서 누락될 수도 있음
• 설계 중인 시스템이 잘 이해되지 않는 한 폭포수 모델은 일정을 맞추지 못할 위험

애자일 모델

• heavy한 프로세스(water-fall) -> 과다한 단계, 과다한 문서, 코드가 나오기까지 시간이 많이 소요
• 과도한 모델링과 문서화의 짐을 과감히 생략하고 개발에 집중 -> Extreme Programming, Scrum, DSDM(Dynamic systems development method)
• Etreme Programming
  • 의사소통
  • 단순함
  • 피드백
  • 격려
  • 테스팅

폭포수 모델	애자일 모델
필수, 보통 모든 기능을 한꺼번에 만들기 시작	우선순위가 높은 필수 기능부터 만듦
품질, 일정에 대한 위험	요구하는 기능을 순차적으로 추가하면서 개발

 

• 프로젝트 성공을 좌우하는 네 가지 사항 -> 기능 요구(scope), 비용(cost), 납기(delivery), 품질(quality)

-> 비용&일정 고정 -> 비전/가치 중심으로 개발

• 고객 중심 -> 실행되는 SW 기능을 중심으로 프로젝트를 계획
• 큰 프로젝트를 작게 분할

• Scrum: 프로젝트 관리를 위한 상호, 점진적인 개발방법론 (https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%81%AC%EB%9F%BC_(%EC%95%A0%EC%9E%90%EC%9D%BC_%EA%B0%9C%EB%B0%9C_%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4))
• 테스트 반복 및 일상화
• 페어프로그래밍, 테스트 중심 개발 -> SW 개발과 함께 미리 테스트 코드 개발
• 페어 프로그래밍: 하나의 컴퓨터에서 두 사람의 프로그래머가 작업하는 방법 -> navigator가 전략 제시, driver가 코딩 -> 이 역할을 번갈아가며 수행

 

 

1.9. 팀 역할

프로젝트 팀 구성

 

프로젝트 관리자

• 계획 수립, 모니터링
• 인원, 예산, 시간 조절 및 관리
• 제안서 작성

시스템 분석가

• 시스템 개발에서 제기된 이슈를 다룸
• 비즈니스 프로세스 개선
• 분석과 설계 작업에 대한 훈련과 경험

사용자 지원

• 기술적 정보
• 교육, 생산정 지원
• 헬프 데스크, 고객 센터

품질 보증

• 품질 관점에서 모든 결과물을 체크
• 테스트
• 개발과 별도의 조직

데이터베이스 관리자(DBA)

• 데이터베이스 설계 관리
• 보안, 백업, 사용자 접근 제어
• 데이터베이스 튜닝

네트워크 관리자

• 네트워크 장비의 관리 및 유지보수