2016년 5월 22일 일요일

임베디드 소프트웨어 설계 시 고려해야 할 사항(1/3) - 유연한(flexible) 소프트웨어의 필요성

1.
임베디드 시스템 엔지니어링에는 제약사항이 많다. 여러 제약 중 어떤 제약이 나중에 프로젝트 개발에 문젯거리가 될지를 파악하는 일은 쉽지 않다. 앞으로 발생할 변화를 예측해서 애플리케이션에 발생하는 변화를 충분히 수용할 수 있도록 소프트웨어를 유연하게(flexible) 설계해야 한다.

2.
소프트웨어를 설계할 때 시스템을 좀 더 유연하게 할 수 있는 몇몇 훌륭한 원칙이 있다.

모듈화 원칙을 이용해 하위 시스템별로 기능을 분리하고 각 하위시스템이 사용하는 데이터를 감출 수 있다.

캡슐화 원칙을 이용해 서로에 대해 알지 못하도록 하위 시스템 간의 인터페이스를 만들 수 있다. 하위시스템(또는 객체)의 결합을 약한 상태로 유지하면 한 부분을 고치더라도 다른 부분에 영향을 주지 않을 것이라는 확신을 가질 수 있으므로 쉽게 코드를 고칠 수 있다. 따라서 필요에 따라 일부 시스템을 분리했다가 수정하고 다시 제자리에 넣을 수 있다.

시스템을 어떻게 분리해야 하는지를 잘 판단하려면 연습이 필요하다. 최선의 방법은 독립적으로 변경될 수 있는 부분을 찾는 것이다.

3.
이 원칙들은 이론부터 나온 것이 아니라 컴퓨터나 만들어지고 프로그램을 만들면서 생긴 시행착오에 의해 적립이 된 것으로 이것들을 후에 체계적으로 정리한 것이 디자인 패턴 이다.

4.
디자인 패턴에 관심을 가진지는 오래 되었지만, 제대로 적용해 본적이 없었기 때문에 가장 대표적인 패턴인 MVC(Model, View, Controller) 를 간단한 프로그램을 통해 직접 구현해야 할 필요가 생겼다.


참조:
디자인 패턴을 적용한 임베디드 시스템


2016년 5월 18일 수요일

Robot Framework 이해를 위한 정리(2/3)

테스트 자동화 도입 시 얻을 수 있는 것들 및 경계해야 하는 것들
이해하기 쉽습니다.

1. Common test automation promises
테스트 자동화가 약속하는 것들.

1) Run existing regression tests on a new version of a program
새롭게 변경된 프로그램에 회귀 테스트를 실행할 수 있다.

Being able to run previously created tests without extra effort clearly makes testing more efficient.
이전에 만들어져 있는 테스트를 간단하게 실행할 수 있도록 하여 효율적으로 테스트를 수행할 수 있도록 한다.

2) Run more tests more often
많은 테스트들을 자주 실행할 수 있도록 해준다.

Automation means faster test execution which means more test rounds. Automation should also make creating new test cases easy and fast.
자동화는 빠른 테스트 실행을 의미하기 때문에 테스트를 여러번 할 수 있다는 것을 의미하며, 또한 자동화는 새로운 테스트 케이스를 쉽고 빠르게 만들 수 있도록 한다.

3) Perform tests which would be difficult or impossible to do manually
수동으로 할 때는 어렵거나 아예 못할 것 들도 수행할 수 있다.

For example performance and stress tests are nearly impossible to conduct without automation.
예를 들어 성능 테스트나 스트레스 테스트 같은 것들은 자동화가 없다면 하기 어렵다. 왜냐하면 정말 다양하고 많은 테스트를 수행해야 하기 때문이다.

4) Better use of resources
자원을 효율적으로 사용할 수 있게 된다.

Automating repeating and boring tasks releases test engineers for more demanding and rewarding work.
반복적이고 지루한 일을 자동화 하는 것은 테스트 엔지니어가 의미있는 일을 할 수 있도록 만들어 준다.

5) Consistency and repeatability of tests
일관적이고 반복적인 테스트가 가능하게 된다.

Tests are always run the same way so test results can be consistently compared to previous results from previous testing rounds. Tests can also be easily repeated on different environments.
테스트들은 항상 같은 방식으로 실행기 되기 때문에 그 결과는 이전의 테스트들과도 일관성이 있게 나타난다. 테스트들은 다른 환경에서도 쉽게 실행될 수 있다.

6) Reuse of tests
재 사용성이 높다.

Reusing tests from earlier projects gives a kick start to a new project.
재 사용성은 새 프로젝트의 빠른 출발을 돕는다.

7) Earlier time to market
빠른 출시

Reusing tests and shortening test execution time fastens feedback cycle to developers. In the end that shortens the time to market.
테스트 재사용과 빠른 실행은 개발 주기를 더욱 빠르게 한다. 그래서 시장에 빨리 출시할 수 있게 한다.

8) Increased confidence
자신감 상승

Running an extensive set of tests often, consistently and on different environments successfully increases the confidence that the product really is ready to be released.

넓은 범위의 테스트를 자주, 일관성 있게 그리고 다양한 환경에서 성공적으로 실행할 수 있다는 것은 제품의 출시에 대한 자신감을 만들어줄 수 있다.



2. Common test automation problems
테스트 자동화의 문제점

1) Unrealistic expectations
실현 가능하지 않은 기대
Managers may believe test automation will solve all their testing problems and magically make the software quality better. Automation experts should help managers setting their expectations right.
매니저들은 테스트 자동화가 모든 문제를 해결해 주고 마법처럼 소프트웨어의 품질을 향상시켜 줄 것이라고 믿는다. 자동화 전문가들은 매니저들이 기대치를 올바르게 가지도록 도와야 한다.

2) Poor testing practice
낮은 테스트 경험
If testing practices and processes are inadequate it is better to start improving them than bringing in test automation. Automating chaos just gives faster chaos.
테스트에 대한 경험이나 테스트 프로세스가 제대로 갖춰지지 않았다면 그것을 먼저 향상시킨 다음에 테스트 자동화를 논의하는 것이 낮다. 혼란을 자동화 한다면 이해할 시간이 없어 혼란이 먼저 빠르게 찾아올 것이다.

3) Expectation that automated tests will find a lot of new defects
자동화된 테스트가 새로운 문제점을 찾아낼 것이라는 기대
After automated test has been run successfully once it is not very likely to find new bugs unless the tested functionality changes. Automators normally find more defects while they are developing tests than when tests are re-executed.
테스트가 자동화 되고 성공적으로 실행되고 난 다음에는 기능이 변경되지 않는 한 새로운 버그를 찾을 가능성이 낮다. 자동화 하는 사람들은 이미 실행된 테스트를 재 테스트 할 때보다 새로운 테스트를 만들 때 문제점을 더 찾는다.

4) False sense of security
보안에 대한 잘못된 인식
Just seeing a test report with no failures does not mean that the SUT did not have any. Tests may be incomplete, either not testing all features or not able to see failures when they occur. Tests may also have defects and show wrong results.
테스트 리포트에 fail 항목이 없다고 해서 테스트 대상에 버그가 없다는 것은 아니다. 테스트는 완벽하지 않으며, 전체를 다 테스트 하지 못했거나 fail이 발생했을 때 제대로 보지 못했을 수도 있다. 테스트 자체가 문제가 있거나 결과가 잘못되었을 가능성이 있다.

5) Maintenance
유지보수
When the SUT changes also its tests change. Human test engineers are able to handle even major changes without problems but automated tests can fail after a slightest change. If maintaining test automation system takes more time than testing manually it will surely be abandoned. The same will happen also if adding new features to the automation system is too cumbersome.
테스트 대상에 변경사항이 생기면 테스트도 변해야 한다. 테스트 엔지니어 들은 중요한 변경사항을 문제없이 다룰 수 있다. 하지만 자동화된 테스트는 작은 차이점에도 문제가 생길 수 있다. 만약에 테스트 자동화 시스템을 유지보수 하는데 수동으로 하는 것보다 더 많은 시간이 들어간다면 자동화를 하지 않는것이 낮다. 테스트 대상에 새로운 기능이 들어갈 때 다루기가 어렵울 때도 자동화를 하지 않는 것이 낮다.

6) Technical problems
기술적 문제
Building and taking test automation system to use is a technical challenge which is unlikely to proceed without problems. Tools may be incompatible with the tested system and they also often have defects themselves.
테스트 자동화를 구축하고 실행하는 것은 문제점을 만날수 밖에 벗은 기술적인 도전이다. 기존에 만들어진 도구들은 테스트 되는 시스템들에 호환될 가능성이 적으며, 그 자체도 문제가 있을 수 있다.

7) Organizational issues
관리적인 이슈
Successful test automation project requires both high technical skills and support from management. Test automation has also big impact on the organization and requires changes in many processes.
성공적인 테스트 자동화 정착되기 위해서는 기술의 수준이 높아야 함은 물론이고 경영진의 지원이 필요하다. 테스트 자동화는 단체에 큰 영향을 주며 프로세스들의 변경을 초래하기 때문이다.

*단어의 뜻
regression test
회귀 테스트는 회귀 버그를 찾는 테스트를 의미한다.
회귀 버그는 이전에 제대로 작동하던 소프트웨어 기능에 문제가 생기는 것을 가리킨다. 일반적으로 회귀 버그는 프로그램 변경 중 뜻하지 않게 발생한다.
회귀 테스트로는 이전의 실행 테스트를 재 실행하며 이전에 고쳐졌던 오류가 재현되는지 검사하는 방법이 많이 사용된다.
 버그가 발생했을 경우 이를 수정하면서 해당 버그를 발견할 수 있는 테스트 케이스를 작성하고 이를 이용해 프로그램을 변경할 때마다 테스트를 다시 수행하는 것이 좋다. 수동으로 할 수도 있지만, 보통은 테스트 자동화 툴을 사용한다.

이전글
Robot Framework 이해를 위한 정리(1/3)

참조
1. Robot Framework의 첫 제안이었던 헬싱키 대학 Laukkanen, Pekka 의 석사논문


2016년 5월 15일 일요일

Robot Framework 이해를 위한 정리(1/3)


정의
Robot Framework는 테스트 자동화를 위한 툴이다.

기원
기본 아이디어는 헬싱키 대학에 다니던 Pekka Laukkanen 의 2005년 석사 논문 'Data-Driven and Keyword-Driven Test Automation Frameworks'  에서 채택 되었으며  Nokia Siemens Networks 에서 첫번째 버전을 개발 하였다. 2008년부터 오픈소스가 되었다.

배경
1. 프로그램은 계속 커지고 있다.
2. 소프트웨어 품질은 더욱 중요해진다.
3. 소프트웨어 테스트를 잘 해야 한다는 압박이 더 커지고 있다.
4. 테스트 자동화는 분명히 이런 일의 크기를 줄여줄 수 있는 방법이다.
5. 하지만 테스트를 위한 시스템(System Under Test, SUT)이 변경되면 많은 걸 새로 작성해야 하고, 컴퓨터가 필요한 일을 해야 하는 것은 어려운 일이다.
6. 이런 상황에서 편리한 테스트 자동화를 위하여 Robot Framework를 제안한다.

테스트의 종류



Static






SW
Test









Dynamic


Non
Functional

















Functional


Unit

















Component


















System









테스트 자동화 Framework의 발전 3단계
1. 
테스트 데이터가 테스트 스크립트 안에 있다.
하나의 테스트 스크립트는 하나의 테스트를 수행한다.
시스템이 변경 된다면 테스트를 다시 써야 한다.

2. 
잘 디자인 되고, 모듈러 특성, 탄탄한 테스트, 문서화 되어 유지보수 가능
테스트 스크립트는 테스트의 수행만 하는 것이 아니라 테스트 전 기본 셋팅 수행, 테스트 초기화, 에러를 잡아서 원상복구 진행 가능 
여전히 테스트 데이터는 테스트 스크립트 속에 있다. 셋팅하는 스크립트는 테스트 케이스 마다 있다.
3. 
테스트 데이터는 테스트 스크립트와 분리된다. 이것은 두가지 분명한 이득이 있다.
1) 하나의 드라이버 스크립트로 여러 테스트 케이스에 사용할 수 있다.
2) 테스트 디자인과 Framework의 구분 해준다.
 - 테스트 될 특정 분야 지식
 - 프로그래밍 기술
이 3단계의 테스트 자동화 Framework는 Keyword Driven, Data Driven Framework 라고 불리며 이것은 이 논문의 제목 이다.


이후 진행
1. 설치(python, wxPython-unicode, robotframework(RIDE에서 바로 실행가능), robotframework-ride 설치, 이후 필요에 의해 pySerial 등 설치)
2. 실제 테스트케이스를 통한 분석


다음글
Robot Framework 이해를 위한 정리(2/3)

참조
1. Robot Framework 홈페이지
2. Robot Framework의 첫 제안이었던 헬싱키 대학 Laukkanen, Pekka 의 석사논문




2016년 5월 8일 일요일

내가 성장 가능하다고 생각하는것의 힘! - Carol Dweck: The power of believing that you can improve

현재의 내가 해결하기에는 조금 역부족인 일을 만났을 때 어떻게 생각하시나요?

크게 두 가지 반응을 보입니다.

1. 이거 풀기에는 내 능력이 부족하구나.
2. 아직은 내가 못푸는구나.

둘다 비슷한 반응이라고 생각할 수 있지만
1번은 능력이 부족한 것에 초점을 두는 것이고,
2번은 '아직'은 못풀지만 조금 더 성장하면 풀 수 있다는 것에 초점을 두는 것이라고 합니다.

스탠포드의 캐롤 드웩교수는 이 두가지의 마음가짐이 얼마나 학생들의 미래에 영향을 주는지 여러 연구결과를 통해서 증명해 줍니다.

"어떠한 상황에서도 나는 성장할 수 있습니다!" 라고 몸으로 이해했으면 좋겠네요.


두 유형의 사람 비교
자신의 능력이
성장할 수 있음을
알고 있는 사람
모르고 있는 사람
뇌의 활동
뇌 안의 전기 활동이 활발
뇌 활동이 거의 없음
실수에 대처하는 법
실수를 분석, 실수를 통해 배우고 개선
자신의 실수에서 도피
진학(과목이 어려움)
시 성적 변화
성적이 떨어져도 금방 회복
점점 성적이 떨어짐
어려운 과제에 대한
반응
스스로 멍청하다고 느끼고,

스스로 포기하고 싶게 한다.
머릿속의 뇌세포가 새롭거 더 강한 연결고리를 만드는 과정이라고 인식.
문제가 어려울 때가 똑똑해지고 있는 때라고 인식

아이들에게 성장 가능성을 알려주기 위한 방법
지혜로운 칭찬을 해야 합니다.
지능이나 재능을 칭찬하는 대신,
아이들이 거치는 과정을, 그들의 노력, 계획, 집중, 인내, 향상됨을 창찬해야 합니다.
이런 “과정에 대한 칭찬”은 어려움에 쉽게 굴하지 않는 강인한 아이들을 길러 냅니다.



2016년 5월 3일 화요일

사용할 Python GUI 비교 및 선택하기

하나의 필요(python에서 어떤 GUI를 주로 사용할 것인가)가 생겨 고민 과정을 정리해 보았습니다. 정리를 해 놓아야. 왜 그런 생각을 했는지, 돌아볼 수 있기 때문입니다.


목적: Python에서 주로 사용할 GUI 선택


검토 자료
검색을 통해서 동영상, 여러 비교 웹페이지 들을 돌아 다녔고, 그 결론으로
1. 'stackoverflw' 의 한 질문과 답변 (링크)
2. wxPython과 PyQt 를 둘다 처음 사용해본 개발자 의견 (링크)
3. 동일한 고민을 하고 wxPython을 고른 분의 글 (링크)


개인적 요구 사항
1. 사용성(짧은 시간에 결과 확인)
2. 범용성(어느 OS에서나 사용 가능)
3. PC에서 사용
이었습니다.


간략하게 정리하면
1. PyQt, pyGTK, wxPython 이 유명도 면에서 선정 대상이 되었고
2. 그중 pyGTK 가 범용성 면에서 점수가 낮아 먼저 탈락 되었습니다.
3. PyQt 와 wxPython 중 어떤 것을 선택하는지 문제인데,
   위 검토자료의 2, 3 이 다른 의견을 주었습니다.
4. 하지만 2번의 개발자가 직접 두 라이브러리를 가지고 직접 동일한 GUI를 구현을 해 보았고 PyQt 가 1일 걸리는 일을 wxPython으로 일주일이 걸리고, 코드의 이해도도 PyQt 가 wxPython에 비해서 높다고 하였습니다.

결론
PyQt 공부하기로 했습니다.


추가로
python korea 에 비슷한 질문이 있고, 답변이 좋아서 기록해 둡니다.

170925 update
  - GUI 는 PyQt 를 사용하는게 제일 편합니다. 이유는 Designer Tool 때문
  - GUI 를 구성할 때는 원하는 모습으로 만들 수 있어야 하는데 이 때 바탕의 배치(layout)를 잘 활용하고 각 Widget의 Minimum, Maximum 크기를 설정하고, Dock Widget 을 활용하면 가능합니다.
  - 보통 버튼을 누르면 특정 동작을 진행해야 하는데 이 때 thread 를 사용해야 GUI 가 멈추지 않습니다. QThread를 활용 하는것이 편리해서(pyqtsignal) 저는 간단한 것만 사용했는데 내부에 bug가 많다는 글을 본적이 있어 신경쓰고 있습니다.


2016년 5월 1일 일요일

Arduino 실습 1 - 외부 LED 1개 동작하기

목적: 아두이노 보드의 외부에 LED를 연결하여 동작하게 할 수 있다.

순서
    1. 실험에 필요한 준비물 이해
    2. 하드웨어 연결
    3. 소프트웨어(Arduino 내부 마이크로컨트롤러에 쓰일) 작성
    4. 실행결과 확인


1. 실험에 필요한 준비물 이해
    a. LED 의 동작 원리: 짧은 쪽이 캐소드(Cathode), 긴 쪽이 에노드(Anode), 짧은 쪽은 GND(그라운드), 긴 쪽을 VCC(전원)에 연결.
    b. 저항(1K) 가 필요한 이유: 저항은 밝기의 조절과 제품의 보호(여기서는 LED)를 위한 것이며, 여기서는 1k 사용.
    c. 아두이노 UNI R3 에서 필요한 부분: VCC(전원), GND(그라운드), Digital Output(여기서는 8번 1개 사용)
        - Digital 출력의 의미: 마이크로 컨트롤러 내부 값 셋팅에 의해 특정 핀의 값을 0 또는 1로 줄 수 있는 것.













   d. 브레드 보드: 부품들 간의 연결을 점프 케이블이라는 것을 이용해서 간편하게 연결하도록 도와주는 도구.
아래 진한 빨간색 선처럼, 각 칸들의 연결이 고정되어 있으며 그 칸들에 점프케이블을 꽂아서 각 부품들을 연결할 수 있는 도구
        











2. 하드웨어 연결
    a. Arduino(Arduino UNO 3 이며 앞으로 Arduino 로 표시) 의 GND 에 하얀색 선(Jump Wire 이며 앞으로 선 표시)을 LED의 캐소드에 연결
    b. LED 의 에노드와 연결된 곳에 1k 저항선을 연결
    c. 1k 저항선의 다른쪽에 노란색 선을 꽂은 다음 Arduino 의 Digital Output  8번과 연결
하드웨어 연결 완료












3. 소프트웨어(Arduino 내부 마이크로컨트롤러에 쓰일) 작성
    a. Sketch 의 동작원리 이해
        ① 아두이노 IDE 에서 기본코드에는 setup 과 loop 함수가 기본 작성되어 있으며 그 안에 코드를 추가 가능

          ② Setup은 Arduino 가 처음 구동될 때(프로그램이 처음 설치될 때, 업로드 될 때) 기본 셋팅을 해 주는 것으며,
          ③ Loop는 계속 무한반복하며 실행하는 곳이다.
    b. 필요한 코드 작성
    c. UNO R3에 작성된 코드 넣기
        - 업로드(위 화살표, 빨간색 네모) 클릭하여 Arduino 에 새로운 프로그램 전송

















4. 실행결과 확인




2016년 4월 26일 화요일

린(Lean) 전략의 핵심

Lean 이 적용된 이야기 하나

  월요일이면 모든 직원들은 무시무시한 상대와 겨루기 위해 링에 오르는 권투 선수처럼 비장한 모습으로 출근 도장을 찍었다. 새로 도착한 부품들을 처음 조립하는 날이니만큼 아무래도 서툴고 작업시간이 더딜 수밖에 없었기 때문이다. 그래서 그들은 최대한 그날의 할당량을 채우기 위해 점심도 허겁지겁 먹으며 일에 매달렸다.
  그러나 할아버지는 달랐다. 자신만의 방식이 있었다. 할아버지는 월요일을 실험일로 정했다. 그리고 어떻게 시간을 효율적으로 쓸 수 있는지 공작기계를 이리저리 조정해서 최적화된 생산 방법을 찾아내려 애썼다. 다른 사람들과 달리 정신없이 바쁘게 일하지도 않았고 옆에 놓인 상자에 조립품을 채워 넣지도 않았다. 그저 생각하고 실험했다. 할아버지에게 월요일은 앞으로의 시간을 효율적으로 쓰기 위해 계획을 짜는 날이었던 것이다.
  할아버지의 동료들은 가장 바빠야 할 월요일마다 시간을 '낭비'하는 할아버지를 힐끗거리며 걱정했다. 할아버지와 달리 중산층에서 자란 우리 할머니가 생계를 제대로 꾸려갈 수 있을지 걱정했고, 한창 자랄 나이였던 우리 아버지가 분유도 제때 먹지 못할까봐 걱정했다.
  하지만 그런 걱정은 매주 금요일이면 사라졌다. 할아버지는 월요일에는 상자를 거의 비워 둔 채로 퇴근했지만 화-수-목 3일이면 일주일치 생산량을 모두 끝마쳤기 때문이다. 월요일 늦은 오후부터 할마버지의 움직임은 점점 빨라졌고 마치 손과 기계가 하나가 된 듯 정확하게 움직였다.


린(Lean) 전략의 핵심

  주어진 과제를 미리 파악하여 성과를 극대화 할 수 있는 가장 효율적인 실행방법을 찾는 것이다. 이것은 새로 나온 디지털 기기를 다룰 때도, 새로운 프로젝트를 맡았을 때도, 새로운 인간관계를 맺을 때도, 새로운 공부를 시작할 때도 도움이 된다.
  자신에게 가장 잘 맞는 방법을 찾기 위해 투자하는 시간을 아까워하지 마라. 임기응변도 중요하긴 하지만 그보다 더 중요한 것이 체계적인 사고다. 그런 체계적 사고를 익히기 위해 더 많은 시간을 써야 질적으로 만족도가 높은 삶을 살아갈 수 있는 것이다.

「스마트한 성공들」 마틴 베레가드, 조던 밀튼


예전에 잘나가는 컨설팅 사장님이 강연하는 것을 들었는데,
어떤 걸 공부해야 회사에서 효율적으로 일할 수 있나요? 라고 질문한 적이 있습니다.
그때 그분이 "당연히 Lean" 이죠 라고 이야기를 해 주셨습니다.
그때 이후로 지금까지 Lean이 도대체 무엇인지 생각해 봤지만 이해가 잘 가지 않았는데, 이 책을 읽고 이해가 된 것 같은 느낌 입니다.

복잡한 것이 아니라,
조급하지 않게, 전체를 보며, 효율성을 찾는것에 일정 시간을 들이며, 신속하게 행동하는 것!
항상 효율성을 생각할 것! 생각을 멈추지 않을 것!

메뉴얼이 존재하는 것이 아니므로 현재 상황을 명확하게 파악하여 효율적인 지점을 찾는다! 그리고 그렇게 하려면 찾을 수 있는 기초 체력(논리력, 진짜 체력)이 필요하다.