[소프트웨어공학] Chapter 01 - Introduction to SE

1. 소프트웨어란?

- 실행 시 원하는 기능, 함수, 성능을 제공하는 명령어

- 프로그램이 정보를 조작할 수 있도록 하는 데이터 구조

- 프로그램의 작동 및 사용법에 관한 문서

 

- 소프트웨어는 제조(manufacture) 되는 게 아님. 개발(develop), engineer 된다.

- 소프트웨어는 마모(wear out) 되는 게 아니라 악화(deteriorate)된다. 

- 업계는 component 기반 구축으로 변화하고 있지만 대부분의 소프트웨어는 고객 맞춤형으로 개발된다.

  => custom 해서 사용

 

2. Legacy Software

소프트웨어는 왜 변화해야만 하는가?

- 새로운 컴퓨팅 환경이나 기술의 변화에 맞춰 변경되어야 함.

- 새로운 비즈니스 요구사항을 충족해야 함.

- 소프트웨어는 나만 쓰는 게 아니라 다른 시스템이나 데이터베이스와 함께 사용함. 상호운용성을 위해 확장 되어야 함

- 변하는 네트워크 환경에 맞게 재설계 되어야 함

 

3. Software Engineering Layers

- Tools

- Methods

- Process

- A quality focus

 

4. Procecss Framework Activities

- Communication

- Planning

- Modeling

- Construction

- Deployment

 

5. Umbrella(보조) Activities 

=> 설계, 개발 외에 QA, risk 관리 등 범위를 넓히는 활동들

- Software project tracking and control (PM이 하는 것)

소프트웨어 프로젝트 모니터링, 진행도, 무슨 이슈를 해결 중인지

- Risk 관리, Risk를 피해야 함. (PM이 하는 것)

- 소프트웨어 품질 보증

- Technical reviews

- Measurement

- Software configuration management

- Reusability management

- Work product preparation and production

 

6. Software Crisis

발생 원인

projects running over-budget and over-time

software with Inefficiency

Software with Low Quality

Software not Meeting requirements

Unmanageable Projects

- 높은 비용, 늦은 보금

- 부족한 성능

- 불가능한 유지보수

 

7. Causes to Software Crisis

-> 요구사항이 많아서

- 소프트웨어의 Complexity (복잡성)이 증가함

- 소프트웨어의 Cost (비용)이 증가함

- 초기 개발 비용보다 유지보수 비용이 더 큼

 

8. Overcoming Software Crisis 소프트웨어 위기 극복 방법

->소프트웨어 개발에 대한 엔지니어링 접근 방식

- 임시방편 용도의 접근 방식은 피하기

-> 소프트웨어 자산 재사용

- 컴포넌트로 어셈블리하기, 클라우드 서비스 구독하기
- 디자인 패턴 적용하기
- 아키텍처 스타일 및 전략 재사용하기
- 프레임워크 채택 등

-> 모델링, 설계에 더 집중하기

- 좋은 설계는 좋은 구현을 위해 필요함

 

9. 복잡성은 어디에서 오는가

+ Application domain
  - 개발자는 일반적으로 도메인 전문가가 아님
+ 이해관계자(고객, 개발자) 간의 커뮤니케이션
  - 이해관계자들(도메인 전문가 <-> 개발자 <-> 개발자)이 서로 다른 어휘, 단어를 사용하는 경우
  - 이해관계자들은 서로 다른 지식을 가지고 있음
  - 인간의 언어는 본질적으로 모호함
+ 대규모 소프트웨어 개발 프로젝트 관리
  - 프로젝트를 여러 조각으로 쪼개고 다시 합침
  - 다양한 부분과 다양한 사람들을 조율해야 함
+ 소프트웨어 코딩
  - 유용한 소프트웨어를 만드는 것은 복잡한 엔지니어링 프로세스임

 

10. 복잡성으로 인해

+ 소프트웨어 품질 문제

  - 비신뢰성: 소프트웨어는 예상대로 작동해야 함

  - 비안전성

  - 버려짐? 이게 뭔 말이지 방치됨

  - 유연하지 않음

+ 소프트웨어 개발 문제

  - 일정 초과, 예산 초과

  - 사용자의 요구 사항 미충족

  - 작동 코드가 예상보다 느림

  - 진행현황 측정이 어려움

 

11. 소프트웨어 엔지니어

“The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.”        - Fritz Bauer

- 신뢰할 수 있고 효율적으로 작동하는 경제적인 소프트웨어를 개발하기 위해 엔지니어링 원칙을 수립해야 함

“... multi-person construction of multi-version software.”         - Dave Parnas

• engineering principles -> It is a disciplined development effort.
• Economically…reliable…efficiently -> It has built-in quality.
• real machines -> It solves a real user problem (implied).
• multi-person -> It requires a team effort. : 혼자 개발하는 게 아님
• multi-version -> It is not a “one-time” development effort : 한 번에 개발/완성 불가능

 

11-1 소프트웨어 엔지니어는

- communication

애플리케이션 관점에서 사용자와 대화할 수 있어야 하고

- analysis

모호한 요구사항을 구체적으로, 정확하게 표현할 수 있어야 하고

- design

서로 다른 추상화 레벨에서 시스템 모델을 설계할 수 있어야 하고

- development

여러 소프트웨어 개발 프로세스를 사용하고 적용할 줄 알아야 하고

- architecture

설계 대안 중 하나를 택할 수 있어야 하고

- team

팀에서 자신의 역할을 잘 수행해야 한다.

 

=> 이렇게 하면 시스템 설계의 복잡성을 줄일 수 있다!

 

12. 소프트웨어 엔지니어링

+ 모델링
  - 요구사항 모델로 사용자 요구사항 모델링
  - 솔루션 모델로 구축할 시스템 모델링
+ 문제 해결 활동
  - 변화에 따른 적절한 해결책 찾기
  - 따라서 알고리즘까진 아니더라도 체계적이어야 함
+ 지식 습득 활동
  - 선형적인 프로세스가 아니어야한다. 진행하면서 배우는 것도 좋지만 완벽하게 공부한 후에 진행하는 것이 좋다
  - 자칫 잘못하면 처음부터 다시 시작해야할 수도 있다.
+ 근거 관리 활동
  - 문제가 발생하면 어떠한 가정을 하고 문제 해결을 시도함 -> 버그, 기술 등
  - 문제 해결을 시도하면서 내린 결정을 재검토 해야할 수도 있음
  - 그 때 왜 저런 결정을 했었는지 근거를 기억하고 아는 게 중요함

 

13. Essence of Software Engineering Practice

Polya suggests:

- communication과 analysis로 문제를 파악하고

- modeling과 software design으로 해결책을 세우고

- code를 작성하고

- test, QA를 거치면서 정확도를 검사한다.

 

14. Understand the Problem

- 문제를 갖고 있는 사람은 누구인지?

  - 이해관계로 얽힌 사람이 누구인지?

- 알려지지 않은 게 뭔지?

  - 문제를 해결하기 위해 알아야 하는 data, functions, features가 뭔지?

- 큰 문제를 더 쉬운 작은 문제로 쪼갤 수 있는지?

- 문제를 시각화 할 수 있는지?

 

15. Plan a Solution

- 문제 해결 가능한 솔루션 패턴이 있는지?

  이미 비슷한 data, functions, and features를 제공하는 소프트웨어가 있는지?

- 비슷한 문제가 해결된 적 있는지?

  만약 있다면, 해당 솔루션을 재사용할 수 있는지?

- 비슷한 문제가 있고 그것의 솔루션이 있다면 그 문제의 부분 문제를 정의할 수 있는지?

  솔루션은 누가 봐도 그 부분문제를 해결하기 위한 것인지?

- 효과적으로 구현하기 위해 해당 솔루션을 잘 표현할 수 있는지?

 

16. Carryout the Plan

- 솔루션이 계획에 부합하는지?

  소스코드가 design model에 맞게 만들어졌는지?

- 솔루션의 각 컴포넌트가 원하는대로 잘 동작하는지?

  코드, 디자인을 리뷰하고 적용해야 할 알고리즘에 알맞게 증명되었는지?

 

17. Examine the Result

- 솔루션의 각 컴포넌트를 각각 테스트할 수 있는지?

  테스트를 위한 전략이 잘 구현되어 있는지?

- 솔루션이 원하는 결과(data, functions, and features)를 잘 얻었는지?

  소프트웨어가 모든 이해관계자의 요구사항을 충족할 수 있게 검증되었는지?

 

18. The reason why principles are important?

- 원칙은 다른 무엇보다 더 안정적임

- 원칙은 쉽게 바뀌지 않음

  - Methods, 기술들은 원칙에 따라 연구, 개발되는 것이 더 안전함

  - 향후 변화나 진화를 예측할 수 있음

  - 각 프로젝트에 맞는 기술을 선택할 수 있음

 

19. 소프트웨어 원칙

- 소프트웨어 원칙은 소프트웨어 프로세스의 올바른 속성을 설명하는 일반적이고 추상적인 요소임

 

20. 핵심 원칙

• 원칙 1. SoC (관심사 분리)

큰 문제를 여러 작은 문제를 세분화하면 해결하기 더 쉬움

• 원칙 2. 추상화 사용

- 추상화: 시스템의 복잡한 요소를 단순하게 표현한 것

- 단일 문구로 의미를 전달하는 것이 추상화이다.

- 분석 및 설계 작업에서 소프트웨어 팀은 일반적으로 높은 수준의 추상화를 나타내는 모델을 낮은 수준의 추상화로 천천히 구체화함

• 원칙 3. 일관성

- 일관성: 익숙한 맥락은 소프트웨어를 더 쉽게 사용할 수 있게 함. (용어 통일 등..)
- ex. 모바일 앱의 사용자 인터페이스 디자인 - 메뉴 옵션의 일관된 배치, 일관된 색 구성표 사용, 알아볼 수 있는 아이콘의 일관된 사용 등을 고려

• 원칙 4. 정보 전달

- 소프트웨어는

DB에서 최종 사용자로

레거시 시스템에서 웹앱으로

운영체제에서 애플리케이션으로 등

한 소프트웨어 구성 요소에서 다른 소프트웨어 구성 요소로 정보를 전송함.
- 인터페이스의 분석, 설계, 구축 및 테스트를 특별히 주의하기!!

• 원칙 5. 모듈성이 있는 소프트웨어 구축하기

- 원칙1의 관심사 분리(SoC)는 소프트웨어에 대한 철학을 정립, 모듈성은 그 철학을 실현하기 위한 메커니즘을 제공함
- 모듈성은 효과적이어야 함
- 시스템의 잘 제약된 한 가지 측면에만 집중해야 함
- 모듈은 다른 모듈과 비교적 간단한 방식으로 상호 연결되어야 함

• 원칙 6. 패턴 찾기

- 과거에 겪었던 문제에 대한 해결책을 분류하고 재사용하는 수단으로 패턴을 사용

• 원칙 7. 여러 가지 관점에서 문제와 해결책을 표현하기

- 더 큰 통찰력을 얻을 수 있고 오류와 누락을 발견할 수 있음

• 원칙 8. 누군가는 소프트웨어를 유지 관리한다는 사실을 기억하기

- 장기적으로 소프트웨어는 결함이 발견되면 수정되고, 환경 변화에 따라 조정되며, 이해관계자가 더 많은 기능을 요청하면 개선됨

 

21. Hooker's General Principles

1. The Reason It All Exists – provide value to users.
2. KISS (Keep It Simple, Stupid!) – design simple as it can be.
3. Maintain the Vision – clear vision is essential.
4. What You Produce, Others Will Consume.
5. Be Open to the Future - do not design yourself into a corner.
6. Plan Ahead for Reuse – reduces cost and increases value.
7. Think! – placing thought before action produce results.

 

1. 모든 것은 존재하는 이유가 있다. -> 사용자에게 분명 가치 있을 것이다.

2. 가능하면 최대한 단순하게 디자인해라

3. 명확한 비전은 필수

4. 당신이 일단 만들면 사람들은 쓸 것이다...

5. 미래를 열어두기: 스스로를 구석으로 몰아넣지 마세요

6. 재사용하는 방법도 고려해보세요. 비용 절감 효과!!

7. 생각해라: 행동하기 전에 생각하면 결과가 나올 것