250x250
Notice
Recent Posts
Recent Comments
«   2024/10   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
Archives
Today
Total
관리 메뉴

SYDev

[오픈소스SW개발방법및도구] Lecture 02. Problem Definition 본문

3학년 2학기 전공/오픈소스SW개발방법및도구

[오픈소스SW개발방법및도구] Lecture 02. Problem Definition

시데브 2024. 9. 19. 15:55
728x90
경희대학교 이성원 교수님의 오픈소스 SW 개발 방법 및 도구 수업을 기반으로 정리한 글입니다.

 

Problem Definition(software layer)

  • System software
  • Application sofrware

 

1. Software Stack

Reference: https://www.techtarget.com/whatis/definition/system-software

- Firmware

  • Firmware: 컴퓨팅과 공학 분야에서 특정 hardware 장치(ROM)에 포함된 software로, software를 읽어 실행하거나, 수정하는 것도 가능한 영구적 소프트웨어
  • hardware의 low-level control -> os 없이 한정된 resource로 단순한 logic 혹은 micro fucntion(미세 기능)만을 수행하는 micro program
  • 펌웨어의 일종인 BIOS -> hardware abstraction(하드웨어 추상화) 작업 수행
  • device driver: computer 외부에 연결된 device를 pc에서 인지하고 제어하는 역할

- OS

  • 컴퓨터를 제어하고 운용
  • 네트워크 관련 기능
  • 사용자 서비스

- Middleware

  • software를 개발하기 위한 tools
  • python 언어, python library

2. System Software

  • system software: application software를 실행하기 위한 플랫폼을 제공하고, computer hardware를 동작, 접근할 수 있도록 설계된 computer software
  • OS를 포함한 아래 영역 - Firmware, Hypervisor, OS
  • hardware 위에 os, compiler, linker, builder, database 통신
    • general-purpose software -> 어떤 software가 올라올지 모름
    • written in low-level assembly language or machine code
    • hardware와 직접적으로 상호작용
    • OS와 같이 설치됨 -> 제조업자에 의해 설치
    • computer가 켜져있으면 언제든 실행됨
    • background에서 동작, user는 보통 접근 X
    • 독립적으로 실행 -> safety, 꺼지면 안 됨
    • system이 동작할 때 중요

3. Application Software

  • application software: operating system에서 실행되는 모든 software
  • 좁은 의미 -> os 위에서 사용자가 직접 사용하는 software
    • user의 특정 요구를 수행하기 위한 software
    • written in higher-level languages -> python, javascript, ...
    • hardware와 직접적으로 상호작용 X
    • user or admin은 필요할 때 software를 설치
    • user가 program을 시작하고 멈출 수 있음
    • foreground의 user가 specific tasks를 수행하기 위해 software를 직접적으로 사용
    • system software가 실행된다는 전제조건
    • system 동작과 관련 X

 

Probelm Definition (purpose)

  • purely your own purpose
  • based on other person's request

 

1. Customer Requirement Analysis

  • Used Case Diagram - program의 용도
  • Focus Group - 프로그램 의뢰한 대상
  • Brainstorming - 토론
  • Observation - 관찰
  • Interview 
  • Survey
  • Join Application Method 
  • Interface Analysis
  • Prototyping

- Requirement Analysis

  • Customer domain
  • Requirement elicitation(유도) 
  • Requirement analysis(분석) 
  • Requirement specification - 요구에 따라 자세한 구현을 고려

Reference: https://www.semanticscholar.org/paper/Customer-Requirement-Management-in-Product-A-Review-Jiao-Chen/4e4b12e567a65761f8f7bdc73ea8b9165430c9fb/figure/0

 

 

Problem Definition (legacy)

  • from scratch - 백지부터 시작
  • based on existing platform(s) - 기존에 존재하던 base에서 시작

1. Reverse Engineering (Reengineering)

  • case 1) 동작되는 file은 있는데 source code는 X -> 이걸 유지보수하는 방법 Reverse Engineering
  • case 2) 악성 코드 분석 -> machine language code를 high-level language로 역변환 가능
  • 실행파일에서 시작

Reference: https://www.researchgate.net/figure/Software-engineering-reverse-engineering-and-reengineering_fig1_2799789

 

 

2. Software Reuse

  • function과 class -> 재사용이 목적
  • Design patterns -> 특정 application의 설계에 일정한 형태 존재 -> 많은 사람들이 만들어놓은 설계 구조도 일정한 패턴이라 지칭하고 reuse

Reference: https://www.researchgate.net/figure/Software-engineering-reverse-engineering-and-reengineering_fig1_2799789

 

- Design Patterns

  • Programming Paradigms: function 재사용
  • Object-Oriented Programming: class 재사용
  • Design Patterns, Architectural Patterns: 프로그램 설계에 대한 재사용 -> client의 경우 MVVP, MVC

 

3. Refactoring

  • Refactoring: 소프트웨어 공학에서 결과의 변경 없이 코드의 구조를 재조정함을 뜻함
  • 둘이 묶여서 같이 쓰이는 함수, 많이 쓰이는 함수, .. -> 이런 요소들을 compact하게 다시 정리하는 행위
  • refactoring을 하는 이유
    • Redability
    • Complexity
      • 호출을 너무 많이함
      • n^2 알고리즘 -> 더 효율적으로 변경
    • Maintainability - 재사용
    • Extensibility - 확장성
    • Performance - 성능 향상
    • Execution - 실행속도 계산

 

Problem Definition (project characteristics)

  • Due (service deployment date)
  • Performance (Capacity, Response Time, etc.) -> 더 작은 memory, cpu에서 돌아가게
  • Resource (Number of developers, Developer skill, Money, etc) -> 개발자 숫자, 개발 능력, 돈, ...

1. Performance indicator (or KPI)

  • performance indicator or key performance indicator (KPI) -> performance measurement
  • 조직 혹은 특정 활동의 성공을 평가(projects, programs, products, ...)

2. KPI example

Reference: https://www.scnsoft.com/blog/software-development-kpis

  • Lines of code
  • Mean Time Between Failure(MTBF): 장애와 장애 사이에 시간 
  • Page Load Time: 페이지 로딩 시간

Reference: https://www.mediacategory.com/

 

 

Problem Definition (hardware dependency)

  • Hardware dependent
  • Hardware in-dependent

1. Hardware dependent problem

- Case Study

  • Arduino -> ATmega, C, Sketch IDE -> 누가 짜도 똑같은 성능 -> 기능이 중요
  • RaspberryPi -> ARM Processor, GPIO, USB -> hardware 입출력 장치에 제한 -> hardware가 낼 수 있는 성능이 이미 드러남
  • CUDA -> NVIDIA GPU, C/C++/Fortran -> 병렬프로그래밍이 목적 -> 호출 프로그램 중요 X 
  • hardware가 주어졌을 때, hardware를 개발하기 위한 언어가 정해지는 경우

 

2. Hardware independent problem

- Case Study (web server)

  • C++ & Proxygen -> 성능을 최대한으로, 구현이 어려움
  • Python & Django 
  • Javascript & Node.js 
  • Apache/Nginx (tools, non-programming) -> 작동만 하면 됨
  • 요구에 따라 적절하게 선택

- 일반적으로 KPI가 고려됨

  • Due 
  • Performance
  • Resource

 

- Case Study (mobile application development)

  • Native platform
    • iOS -> material design
    • Android -> 주수입: 광고 수익
  • Cross platform
    • HTML/CSS/JavaScript -> CORDOVA, ..
    • Dart/Flutter -> Dart/Flutter - 화면에 띄울 수 있는 material design(google standard) 관련 도구를 control하는 library

- Consideration on General Criteria

Reference: https://medium.com/tech-in-200-words/cross-platform-vs-native-apps-comparison-in-200-words-2498acd2480b

  • Architecture: platform 마다 다른 app vs multiple platform에 하나의 app
  • Development Time: platform 마다 개발하는 시간 vs 현저히 줄어든 개발 시간
  • Cost: multiple native 개발에 따른 비용 발생 vs lower cost
  • Target audienceplatform으로 한정 vs 많은 수의 users
  • User experience우수 vs UX 결집의 신뢰성이 떨어짐
  • Code reusability: 거의 불가능 vs 60% reuse
  • Hardware accessibility완벽한 hardware 지원 vs 제한됨

 

- 고려할 지표

  • Github stars
  • Github commits
  • Stackoverflow watchers
  • Stackoverflow questions
  • Google Trend
  • Time - CPU, Memory intensive test with algorithm
  • 고용 인원

 

결론 (Problem Definition)

  • 만들어야 하는 program이 있을 때, 의사 결정을 정성적, 정량적, hardware dependency, ..에 따라서 판단하여, 최적의 결정을 내려라 -> 판단에 근거를 둬라
  • 프로젝트가 실패하더라도, 의사 결정 근거에 따라 정성적, 정량적 교훈을 얻을 수 있음

 


참고자료

 

펌웨어 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 일상에서 쉽게 볼 수 있는 텔레비전 리모컨은 펌웨어로 동작하는 기기의 하나이다. 펌웨어(firmware)는 컴퓨팅과 공학 분야에서 특정 하드웨어 장치(read-only memory,

ko.wikipedia.org

 

시스템 소프트웨어 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 시스템 소프트웨어(system software, 문화어: 체계소프트웨어)는 응용 소프트웨어를 실행하기 위한 플랫폼을 제공하고 컴퓨터 하드웨어를 동작, 접근할 수 있도록

ko.wikipedia.org

 

리팩터링 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 리팩터링(refactoring)은 소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애

ko.wikipedia.org

 

Code Refactoring Best Practices

Why do programmers regularly rewrite other people's ready-made code? It is all about refactoring. Discover what code refactoring is, its benefits, and the best practices for it.

maddevs.io

 

 

728x90