[소프트웨어공학] Chapter2-2. 소프트웨어 공학 개요(2)

chapter 2에서는 소프트웨어공학에 관해 다룬다. 즉, 우리가 3,4 .. 장에서 차차 배워갈 내용을 쭉 다룬다. 소프트웨어의 정의와 역할과 진화 그리고 이 소프트웨어의 문제점, 응용분야를 다루어봤고 이번 포스팅에서는 소프트웨어공학을 단계별로 접근하는 방식에 관해 배운다. 

---

우선 소프트웨어 공학의 정의부터 다시 상기시켜보자 ! 

소프트웨어 공학, Software enginerring

 

소프트웨어 공학이란 신뢰성있고 실제 기계에서 효율적으로 작동하는 소프트웨어를 경제적으로 구현하고 사용하기 위해 건전한 공학 원칙을 수립하고 적용하는 것을 의미한다. 이 때 공학 원칙이란 앞서 말한 오류가 없고 효율적이라는 뜻을 내포하고 있다. 

 

1) 소프트웨어 개발, 운영 및 유지보수에 체계적이고 집중된, 측정 가능한 방법론을 적용하는 것

2) 1)에 접근하는 학문

 

한마디로 소프트웨어 공학은 소프트웨어를 체계적이고 효율적으로 개발하고 유지보수하기 위한 학문 및 기술이다 ! 

---

소프트웨어공학, 단계적 접근

이제 소프트웨어 공학의 정의에 대해서는 어느정도 알겠고... 그럼 이 소프트웨어 공학의 접근 방식에 대해서 알아보도록 하자 

소프트웨어공학에서는 주로 5가지 단계적인 접근 방식을 사용한다. 

 

① 철학 : 소프트웨어의 존재 이유, 그 목적, 그리고 이를 위한 철학적 가치 고민 ('good' product 철학)

② 품질 : 신뢰성, 성능, 사용성 등에서 얼마나 우수한지

    - Bedrock(SW품질 보장을 위한 기초적인 단계)

 

③ 프로세스 : SW개발과정에서 어떤 작업들이 수행되어야 하는지 

    - Frame work Activities(뼈대) 

    - Umbrella Activities(보호활동) 

그림에서 눈치챘을것 같지만.. 프로세스단계의 하위 목록이 꽤나 많다.. 차근차근 살펴보도록 하자 

 

④ 방법 : SW개발에 대한 최신 방법들과 기술들 탐구(이를 적용하여 개발 수행)

     - "how to's"

 

⑤ 도구 : 개발을 지원하는 다양한 도구들 사용 → 생산성 높이고, SW품질 높이자 ! 

     - 프로세스와 방법을 위한 자동(or 반자동) 지원 

     - Computer-aided software engineering-CASE tool : 컴퓨터웨어 공학에서 사용되는 컴퓨터 지원 도구 

 

---

소프트웨어 ③ 프로세스 단계에서 조금 더 자세히 ! 알아보자 ~ 

소프트웨어 프로세스 5단계는 소프트웨어 공학에서 핵심적인 역할을 담당하고 있다. 강의자료에서도 이 프로세스 단계를 특히나 강조하고있는데 이 활동이 프로젝트의 성공과 소프트웨어 제품의 품질을 보장하기 위한 중요한 역할이기에 아마도 .. 이렇게 강조를 하고 있지 않나 ~ 싶다. 필자의 생각이 어쨌건 저쨌건, 프로세스 단계가 매우 중요하다는 것 ! 

 

소프트웨어 프로세스 : 프레임워크 활동 

소프트웨어 개발의 다양한 단계에서 수행되는 다양한 활동들을 조직하고 관리하기 위한 구조 제공

1) 대화 (Communication)

: 이 프레임워크 활동은 고객 및 이해 관계자와의 밀접한 커뮤니케이션과 협력을 포함하여 요구 사항 수집 및 기타 관련 활동을 포함한다. 

2) 계획수립 (Planning)

: 이 활동은 이어지는 소프트웨어 공학 작업을 위한 계획을 수립한다. 기술적으로 수행할 작업, 예상되는 위험, 필요한 자원, 생성해야할 작업 결과물 및 작업 일정 등을 기술한다. 

3) 모델링(Modeling) 

: 이 활동은 개발자와 고객이 소프트웨어 요구 사항 및 해당 요구 사항을 충족하는 설계를 더 잘 이해할 수 있도록 하는 모델 생성을 포함한다. 

4) 구축(Construction) 

: 이 활동은 코드 생성(수동 또는 자동화)과 코드의 오류를 발견하기 위한 테스트를 결합함 

5) 설치(Deployment) 

: (entity or 부분적으로 완료된)소프트웨어가 고객에게 전달되며, 고객은 전달된 제품을 평가하고 해당 평가를 기반으로 피드백을 제공한다. 

 

소프트웨어 프로세스 : 보호 활동 

소프트웨어 개발 프로세스에서 소프트웨어 제품과 품질과 안전성을 보장하기 위한 다양한 활동을 의미 

1. 통제 - 팀 스케쥴에 맞출 수 있게 

2. 위험 관리 

3. 품질 보증 

4. 기술 검토 

5. 측정(process, project, product + people) 

6. 형상 관리 (변화의 효과(성능) 관리)

7. 재사용 

8. 산출물 

 

---

우리는 지금까지 이론에 대해서 배웠다. 근데? 일할때는 뭐다 ? 실무다 ~ 

그럼 이론을 실무에 어떻게 연결할 것인가를 배워보자 

 

소프트웨어공학 실무 
<문제해결 방법론>

1. 문제 이해(대화 및 분석 모델링)

   - 문제의 이해도와 관계자들 

   - 문제를 쪼갤 수 있는가? 더 작은 문제로 나타낼 수 있는가?

   - 문제를 정형화하여 나타낼 수 있는가 ? 분석 모델이 생성될 수 있는가?

 

2. 해결방안 계획(프로젝트 계획 및 설계 모델링)

    - 이와 유사한 문제를 과거에 본 적 있는가? 문제의 패턴은 어떤가? 

    - sub-problem이 정의되었는가? 

    - 효과적인 구현방안이 있는가? 디자인 모델이 나올 수 있는가? 

 

3. 실행(코드 생성)

    - 해결책이 plan을 따르는가? 소스 코드가 디자인 모델을 추적할 수 있는가? 

    - 해결책 각각의 컴포넌트 부분이 올바른가? 

 

4. 검토(테스트와 품질보증) 

     - 각각의 컴포넌트를 각각의 해결책으로 테스트 가능한가? 구현할때 합리적인 testing전략이 있는가 ?

     - 해결책이 데이터, 함수, 특징 등을 따라 만든 결과가 자격이 있나 ?

 

---

뭐.. 실무에서는 이런 질문들을 던져서 답을 해결해나간다고 한다. 그런데 언제나 원칙이 있어야겠지 ?

 

일반 원칙

제 1원칙 : The Reason It All Exists, 모든것이 존재하는 이유 

 - user에게 가치를 제공하기 위해

 

제 2원칙 : KISs(Keep It Simple, Stupid!)

 - 모든 디자인은 가급적 단순해야하지만 단순해서는 안된다.. 

→ 단순함이라는 이름으로 기능, 내부 기능을 버리라는 뜻이 아님 ! 

 

제 3원칙 : Maintain the Vision 

 - 명확한 비전은 성공적인 소프트웨어 프로젝트에서 필수적이다 

 

제 4원칙 : What you Produce, Others will Consume 

 - 언제나 다른 사람이 당신이 하는 일을 이해하는 것을 지정하고 설계하고 구현해야한다

 

제 5원칙 : Be Open to the Future 

 - 구석에서 설계하지 마라

 - 일반적인 문제를 풀어라, 특정한 문제 말고 ! 

 

제 6원칙 : Plan Ahead for Reuse 

 - 재사용을 미리 계획하면 재사용 가능한 구성요소와 통합된 시스템의 비용을 줄이고 가치를 높일 수 있다. 

 

제 7원칙 : Think! 

 - 행동하기 전 명확하고 완전한 생각을 두어라 ! 더 나은 결과 나올 것임 

ex. computer thinking, design thinking, system thinking .. 

 

---

그런데 .. 실무에서 한번쯤 마주할 만한 문제점이 있다. 

바로 편견( Myth )! 

 

소프트웨어에 대한 편견 

관리자의 편견 

Myth: Standards, Procedures
Reality: No!

 

 

Myth : If behind schedule, then more programmers and catch up 

Reality: Software developments is not a mechanistic process like manufacturing 

프로그래머와 일은 비례관계가 아님 → 기계적 처리 ㄴㄴ

 

Myth : Outsource (외주 ㄱ?) 

Reality: Invariably struggle 

(컴포넌트) (substructure)가 끼워맞춰지지 않음 

 

고객의 편견

Myth: A general statement of objectives is sufficient (일반적 설명 ㄱㄴ)
Reality: Ambiguous statement makes disaster (모호한 진술 에바임)

 

Myth: Change can be easily accommodated (변화쯤이야- 쉽게 수용 oo)
Reality: Impact of change; time, (if early, then small), but as time passes, cost impact grows rapidly

비용문제 발생할수도 .. 

 

실무자의 편견 

Myth : If it works, Job is done (작동하면 끝임 ~ ) 

Reality: Sooner you begin writing code, the longer it'll take you to get done 

(코드 작성을 빨리 시작할 수록 완료하는데 더 오래 걸림) 

 

Myth : No way of assessing its quality 

Reality: Formal technical review 

 

Myth : Only deliverable work is working program

Reality: Software configuration (소프트웨어 구성, 형상물) 

 

Myth : Creating voluminous and unnecessary documentation will invariably slow us down

(방대하고 불필요한 문서 만들면 항상 속도가 느려질거야 ! ) 

Reality : Creating quality, reduce rework, faster delivery times 

(ㄴㄴ 오히려좋아)

 

이런 편견들이 존재한다 ~  ! 

 

---

마지막으로 나무그네 만들기 비유는 소프트웨어 개발 과정에서 변경 요구사항에 대처하는 방법을 설명하는 일반적 비유이다 ! 

이를 통해 초기에 소프트웨어 설계와 개발이 충분한 여유를 가지고 계획되어야하며, 변경 요구사항이 생길 경우 SW를 수정하는 것이 아니라, 초기 설계와 개발 과정에서 충분한 여유를 가지고 새로운 요구사항을 수용할 수 있는 유연성을 가지도록 해야함 ~~ 

---

[참고 및 출처]

한국항공대학교 「소프트웨어 공학」 강의자료