새 창을 열다

HanContacts.apk

 

스마트폰을 쓰시는 부모님께서 돋보기 안경을 쓰고 주소록을 찾으시는 모습이 참 안쓰럽더군요.
요새 스마트폰은 보통 화면이 크긴 하지만, 저희 부모님이 쓰시는 옵티머스Z는 그다지 큰 화면은 아닙니다.

나름 안드로이드 개발한다면서 이런 간단한 어플 정도 만들어 드리지 못했다는게 죄스럽네요, 그래서 잠깐 시간을 내서 주소록을 글자 크게(32sp) 보이도록 만들었습니다.

조금이라도 빨리 쓰시게 하려고 일단 간단히 만들었습니다. 오로지 전화번호가 저장되어 있으면 목록에 표시됩니다.  다음에 또 시간이 나면 기능을 추가해봐야겠습니다. 혹시 혹시 혹시라도 쓰실 분 있으면 쓰셔요~^^;;;

부푼 기대를 안고 개발환경 설정하고 이것 저것 해보는데,
뻑하면 Eclipse가 죽어서 도저히 진행이 안된다. 몇일째 삽질하다가 결국은 해결.
서치하면 대부분 eclipse를 갈릴레오로 변경하라고 나오고, ini 도 수정해보라고하고 여러가지가 나오는데 내 경우는 결국 JDK 문제였던 것 같다.

Eclipse : Helios 에서 Galileo 로 변경
JDK : jdk1.6.0_21 에서 jdk1.6.0_20으로 변경

안드로이드 개발을 하다보면 XML 파일을 수정할 일이 많은데 이클립스 기본 Fomatter은 웬지 이쁘지가 않다.
그래서,
Window-> Preferences-> XML-> XML Files-> Editor 에서 "Split multiple attributes each on a new line" 만 체크로 변경해줘도 XML 파일이 휠씬 아름다워 보인다.

http://www.androidpolice.com/2009/11/04/auto-formatting-android-xml-files-with-eclipse/

지난 포스트에서는 파일이 어디에 설치될 것인지를 구성했었지요. 이번 포스트에서는 실제 설치 파일을 만들어 보도록 하지요. 빌드는 Media의 Releases 메뉴에서 이루어집니다.



Releases 메뉴를 선택한 후, 새로운 릴리즈를 만듭니다. 주로 'CD-ROM'을 선택합니다.



새로 만든 릴리즈를 선택하면 오른쪽 패널에 탭들과 함께 많은 설정 항목들이 보입니다. 여기있는 값들 변경하여 설정할 수도 있고, 아래 처럼 릴리지를 선택하여  'Release Wizard..'를 사용할 수도 있습니다. 저는 이 방법이 더 편하더라구요.

Release Wizard를 실행하면 아래 그림과 같은 대화상자들이 나타납니다.

Media Type
우리는 CD-ROM 타입으로 릴리즈를 만들었기 때문에 Media Type이 CD-ROM으로 선택되어 있습니다.


General Options

• Create a single fie executable : 하나의 파일로 설치 파일을 만들려면 선택합니다.
• File : 파일의 이름을 적어줍니다.
• Icon : 설치 파일의 아이콘을 정의합니다.

Platforms
지원할 플랫폼을 선택합니다. 프로젝트 설정에서 선택한 플랫폼과 동일하게 사용할 것인지, 아니면 이 릴리즈에서 지원할 플랫폼을 따로 정의할 것인지 선택할 수 있습니다.


Setup Languages
지원할 언어를 선택합니다.

• Display the Setup Languages Dialog : 이 옵션을 선택하면 설치 단계중에 언어를 선택할 수 있는 대화상자가 나오게 됩니다

Features
이 릴리즈에 포함시킬 Feature를 선택해 줍니다. Features를 기능별로 구성해 놓으면, 릴리즈에서 포함시킬지 아닐지 여부를 결정할 수 있습니다.


Media Layout


User Inaterface


Postbuild Options
빌드가 끝난 후에 해야 할 일을 설정해줍니다.

• Upload release files to the FTP site specifed below : 빌드 후에 설치 파일을 FTP 사이트에 파일을 업로드합니다.
• Copy the bild mdedia fiels to the folder specified below : 빌드 후에 설치 파일을 다른 폴더로 복사해줍니다.
• Execute the batch or executble fiel specified below after building the media files : 빌드 후에 배치 파일을 실행시키거나  혹은 특별히 해주어야 할 일들을 설정합니다.

Summary
앞 단계에서 설정할 값들을 요약해서 보여줍니다.

• Build the Release : 마침을 누르면 빌드할 것인지를 선택합니다.
  

마침을 누르거나 릴리즈를 선택하고 마우스 우클릭하여 Build 메뉴를 누르거나, F7를 누르면 해당 릴리즈가 빌드됩니다.
Tools-Open Release Folder 메뉴를 선택하면 빌드된 결과 파일을 볼 수 있답니다. General Options에서 single file를 선택했다면, 하나의 실행 파일만 보일 것입니다.


이제 빌드가 끝났습니다. setup.exe를 실행해서 적절하게 실행파일이 만들어졌는지 확인해보세요~^^

2010/03/26 - [IT/Lecture] - InstallShield 2008 3. Organization
2009/10/20 - [IT/Lecture] - InstallShield 2008 2. Installation Information
2009/10/12 - [IT/Lecture] - InstallShield 2008 1.소개

하하, 세번째 글은 더 늦었네요. 딴 소리 안하고 바로 본론입니다.


자, 이제 설치하고 싶은 파일들이 컴퓨터의 어디에 설치되어야 할 지 설정해 주는 부분이 필요하죠. 대부분 Organization의 Setup Design에서 설정할 수 있습니다. Features메뉴는 Feature들만 보여주고, Components메뉴눈 Component들만 보여주니, Setup Design에서 한꺼번에 보고 구성하는게 더 편합니다.

이제 Feature와 Component를 구성해 보도록하겠습니다. 왼쪽 패널에서 Setup Design을 선택해 줍니다. 두번째 패널에 DefaultFeature와 DefaultComponet가 보입니다. Feature에서 오른쪽 클릭하여 다음과 같은 메뉴를 사용합니다.



1.     New Feature : 새로운 Feature를 생성한다.
2.     New Component : 새로운 Component를 생성한다.
3.     Associate Components : 선택된 Feature에 포함되어야 할 Components를 설정한다.

※ Feature는 다른 Feature와 Component를 포함할 수 있고, Component는 Component만 포함할 수 있습니다. Feature로 구성하면 릴리즈(빌드)할 때 포함할지 안할지 결정할 수 있고, 또한 설치 중간 단계에서 설치할지 말지 여부를 선택하는 다이얼로그에 보이도록 할 수 있습니다.



1.        Remove foram feature : 포함된 Feature에서 제거됩니다.
2.        Delete from project : Componet가 삭제됩니다.
3.        Rename

※ Component를 'Delete' 키로 삭제한다고 해서 바로 삭제되는 것이 아니라 포함되어 있던 Feature에서 제거만 되는 것입니다. Delete from project메뉴를 이용해야 실제로 삭제됩니다. 제거된 Component를 다른 Feature에 포함시키고 싶으면 Associate Components 메뉴를 이용할 수 있습니다.

이제 Component를 클릭하여 세세한 설정을 해야 합니다.

1.     Destination : 파일이 설치되어야 위치를 표시한다.
※  <WINDIR>은 \windows 폴더,  <WINSYSDIR> \system32 폴더 등 기타 특수한 폴더는 도움말을 참고해서 설정합니다.

2.     Uninstall : 제거 시 포함된 모듈을 지울 것 인지 여부를 설정한다.
3.     .Net Scan Build :.Net관련 설정으로 보인다.
4.     Languages : 해당 Components에 포함된 모듈이 설치될 언어를 설정한다.
5.     Operationg systems : 해당 Components에 포함된 모듈이 설치될 OS를 설정한다.
       

※  언어와 플랫폿은 Project Properties에서 추가한 것 중에서 선택할 수 있다.

6.     Self-Register : 해당 Components에 포함된 모듈이 레지스트링이 필요한 모듈이면 Yes로 설정한다.
7.     Overwrite : 파일이 이미 존재할 때, 어떻게 할지 설정하는 항목이다. 상황에 맞게 설정해주고 특별하지 않으면 Always로 설정한다.
8.     Link Type : 패킹 되어야 할 모듈의 위치를 설정한다. 
Static Link은 패킹 되어야 할 각각의 파일을 탐색기에서 드래그하여 링크시켜주어야 하고, Dynamic Link는 패킹 되어야 할 폴더 위치를 설정하여, 폴더의 모든 파일을 링크시켜준다.

        
          i.         include subfolders : 설정한 폴더의 하위 폴더까지 링크시켜준다.
          ii.         Wildcard(s) : 포함하거나 제외하고 싶은 파일을 설정한다.        
                 1.      Inclusion : 모든 파일을 링크시키기 위해서 *.*로 설정한다.
                 2.      Exclusion : 링크를 원치 않는 파일이나 확장자를 설정한다.

링크까지 걸어주고 나서, Component 하위 트리의 Dynamic File Links를 클릭하면 설치되어야 할 파일들의 목록이 들어와 있는 것을 확인할 수 있습니다. Dynamic Link일 때, 가끔 파일이 잘 안들어 갈 때가 있기도 한데, 이때는 다시 Folder 선택을 해주고 OK를 누르면 리플레시되어서 파일들이 나타나는 것을 볼 수 있지요. (인스톨쉴드는 버그가 참 많은 프로그램이예요^^;;)



이렇게해서 설치 구성까지 완료했습니다. 그래도 중간까지는 달린 느낌입니다.
다음 글은 더 빨리 쓸 수 있으려나요 ^^ 그럼 이만..

* 관련 글 링크
2009/10/20 - [IT] - InstallShield 2008 2. Installation Information
2009/10/12 - [IT] - InstallShield 2008 1.소개

지난 10월 21~22일에 제13회 소프트웨어 품질관리 심포지엄이 섬유센터에서 있었습니다.
무려 10만원이나 하는 세미나였는데, 사장님의 특별(?)지시로 다녀올 수 있었습니다. 품질에 관한 세미나가 10회 이상씩 지속적으로 열리고 있었다는 것을 미쳐 모르고 있었는데 나름 고무적이었습니다. 하지만 대부분의 세션이 문제점만 이야기하고 해결방안은 내놓지 못하는 발표가 많아 아쉬었습니다. 물론 문제를 이야기하기란 쉽지만 역시 해결책을 내기는 어렵다는 것을 알지만요.

개발자 입장에서 참여하는 개발 세미나와 QA 입장에서 참여하는 품질 세미나는 느낌이 살짝 달랐습니다. 지극히 개인적인 느낌이지만 말이니다. 품질 또는 개발은 지식이 아니라 관리 이슈라는 말도 와닿았습니다. 관리되지 않은 모듈과 소스코드는 없는 것이나 마찬가지이기 때문이지요.

또한, 대부분의 회사에서 수행하고 있지못하는 자동화, 정적분석, 화이트박스 테스트 등에 대해 먼저 시행하면서 어려웠던 점과 좋았던 점을 고루 나눌수 있었던 것 같습니다. 많은 세션이 있었지만 그중에 기억에 남는 세션 몇개만 정리했습니다.

Issues and Challenges in S/W Development & quality - 유인경 원장(LG전자 기술원)

     ♣  구체적인 해결방법을 제시하지 못해서 아쉬움, 개발자의 높은 개발 능력이 요구됨을 어필

 

IT/SW융합에서의 품질 확보를 위한 테스팅 방안 - 최병주 교수(이화여대)

• 카 인포테인먼트 시스템 테스트 자동화 도구 AMOS 개발

  • 분석 로봇이 시스템 구조 분석을 통해 테스트 위치(리스크존)을 식별하고 테스트 결과 분석, 결과를 내주는 시스템

  • 짧은 개발 기간과 개발 후반에 테스트가 집중되는 문제

    • Interface Based Test (개발 모듈의 인터페이스화 선행)
    • 블랙박스 테스트 하되, 화이트 박스 테스트로 확인
    • SW 개발자는 최초의 테스터

      ♣  자동화 도구를 개발하여, 결함의 원인을 분석하며, 코드 레벨의 화이트박스의 좋은 예.

 

IT차량 분야 임베디드SW 테스트 프레임워크 구축 및 시범 적용 사례 - 정태하 수석(오토에버시스템즈)

• V-모델(Multiful V-모델) 에 근거한 테스트 프레임워크를 구축함.

• Verification & Validation의 각 레벨의 세부 활동 정의

  • Verification 

    • 사양서 Inspection
    • 설계서 Walkthrough
    • 소스코드 Static Analysis : 자동화 도구 활용

  • Validation

    • 단위 Test : Fuction 단위의 기능성 검증, 자동화 마련, 단위함수레벨의 테스트 커버리지 측정
    • 통합 Test : 구성요소의 Integration Set에 대해서 기능시험, 자동화
    • 시스템 Test : 요구사항기반의 테스트

    ♣ 개발 이전의 사양서, 설계서, 소스 레벨의 테스트가 이뤄지며 모두 자동화되어 있음.
    ♣ 문서 및 사용 변경에 대한 업데이트미 미비하며, 시간이 오래걸린다는 단점이 잇음
    ♣ 테스트 케이스를 소스 코드 기반에서 추출하고 개발자 리뷰를 같이 하는 것으로 보안 노력.

 

국내  SW QA시장 활성화를 위한 소루션 배포 및 기술지원 방안

• 외산 솔루션의 문제점

  • 국내 현실과 다른 프로세스
  • 언어 문제
  • 고가의 도입과 유지보수 비용

•  소프트웨어 테스트 관리시스템 WATT(와이즈와이어즈)

  • 요구 사항관리
  • 테스트케이스관리
  • 결함관리
  • 보고서 기능
• 무료 다운로드 : http://watt.wisewires.com

    ♣ 자사 툴 선전하는 시간이었으나, 외산 툴의 장단점을 소개하고 현실을 이해시키는 세션이었음.

 

ITNHN Quality Practice 적용 사례

• QP(Quality Practice) 도입하여 개발 단계의 Defect Prevention을 강화하고, 품질 활동을 정령화 시킴

  • 도입배경

    • 개발 라이프 후반에 몰아 닥치고, 제대로 테스트 되지않은 모듈이 QA 단계로 넘어옴
    • 단순 기능 테스트 위주의 검증과 버그는 QA가 잡는다는 안일한 마인드가 팽배
    • 개발 품질보다는 개발 진척도에만 관심을 가짐.

  • Quality Practice 활동

    1. Coding Convention : 코드이 가독성 및 유지 보수성 향상을 목표

       • 신규/수정되는 코드에 코딩표준을 준수시키도록 함

    2. Unit Test Coverage

       • 구현단계에서 필수 수행 Unit Test 대상 정의(QA불가한 기능,DB쿼리,데이터가공 등)
       • Unit Test Coverage를 QA 테스트의 Entry Criteria로 사용
    3. Code Inspection : 대상 소스에 대한 리뷰, 공통 협업도구 제공
    4. Static Code Analysis : 결함 사전 제거

    5. Code Complexity : QA 테스트 단계의 Entry Criteria로 지정

       • Critical한 정적 분석 결함을 모두 제거

• Quality Practice 적용 절차
  1. 개발자

  • 코딩 표준 준수
  • Unit Test

  2. 개발팀

• 주기적인 통합빌드
• 5가지 QP 항목 필수적

3.QA

• 구현 단계 말 코드 품질 확인하여 QA 가능 수준인지 판단
  중점적으로 테스트할 부분 식별

• Quality Practice 활동 지표 수립

  • 대시 보드를 구성하여 품질지표를 정량화 하여 표현(Gold, Green, Yellow 등으로 시각화하여 잘하고 있는지 여부를 표시)
  • 수준과 목표를 설정하여 개발자 스스로 도전하게 동기부여
  • KPI 등에 반영하지 않으므로 반발 감소시킴

• 개선 효과 측정 방법

  • QA 단계 완료 및 릴리즈 이후 안정화 시점에서 3가지 빌드 품질 지표를 측정하여 개선효과를 검증
  • 사내 BTS을 이용하여 Build Quality를 측정
  • Quality Practice 활동을 한 소스와 하지 않은 소스를 비교하여, 추후 장애 심각도 등을 측정

• 조직차원의 지원활동

  • 표준 환결 설정, 교육, 기술지원
  • 자동화 도구 지원
  • 커뮤니케이션 강화 및 피드백 활동(사내 Q&A, FAQ, Best Practice 공유)

• 기타 (사용하고 있는 툴 등 구두로 소개해 줌)

• • Style checker
  • Google Test Frameworks
  • Visual Studio tools
  • JUnit, CPPUnit
  • Clover(code coverage tool) : http://www.atlassian.com/software/clover/
  • Hudson : 오픈 소스 CI 서버

    ♣ 구현단계의 품질을 위해 애씀, 전사적인 지원과 노력을 엿볼 수 있음
    ♣ 유/무료 도구의 적극적인 이용과 통합적인 관리가 돋보임

이 글은 스프링노트에서 작성되었습니다.