*문* 스토어

*문*

개인

팔로워0 팔로우

소개

등록된 소개글이 없습니다.

전문분야 등록된 전문분야가 없습니다.

판매자 정보

학교정보

입력된 정보가 없습니다.

직장정보

입력된 정보가 없습니다.

자격증

입력된 정보가 없습니다.

판매지수

판매중 자료수

4개
전체 판매량

44개
최근 3개월 판매량

0개
자료후기 점수

-
자료문의 응답률

-

전체자료 4개

agile방법론에 대한 문서

Agile 의 Scrum ?1. Agile 개발의 구성요소 - Values - Principles - Practices 2. Efficiency Team 은 ? - 투명성 : 모르는 것 인정 / 지원요청 - 공동 책임감 : 모든 문제는 우리의 시스템에서 발견된 우리의 문제 ( 모두가 문 제 에 대해서 책 임감을 가짐 ) 3. Program 의 입장이 아닌 고객의 입장에서 성공여부를 평 가할 것 - 외과의사가 “ 수술은 성공적이나 환자는 죽었 다 ” 라는 것과 똑 같음 . . 자신의 경험사례를 기반으로 성공적 프로젝트를 위한 기준 제시 . 최신 기술보다 ‘ 원칙 , 가치 ’ 에 대한 개념 요구 - TDD 는 천공카드 시절에도 쓰였던 잊혀진 원칙 Agile 란 ?스크럼 Scrum 은 반복적이고 점진적인 프로세스다 . 반복적 (Iterative) 팀은 먼저 제품을 만들어 본다 . 당연히 불안정하고 취약한 부분이 있다 . 만족스런 부분이 나올 때 까지 그러한 부분들을 반복적으로 정리해 나간다 . 반복적 프로세스는 조각에 비유할 수 있다 . 뭉뚱그려 사람 모양을 만들고 점차 세밀하게 조각해 나간다 . 각 반복 중 증가분은 그 자체로서 온전한 기능을 수행한다 . 프로젝트 전 기간에 걸쳐 완성된 부분들을 배포하기 때문에 점진적 이다 .스크럼의 기본 스크럼 프로젝트는 스프린트 (sprint) 라 불리는 30 일 단위의 iterative 을 통해 진행된다 . 수행할 작업들은 제품 (product) backlog 라 불리는 우선순위가 매겨진 목록에서 선택한다 . 스크럼 팀이 해당 스프린트 동안 완료하기 위해 선택한 작업들은 제품 backlog 에서 스프린트 (Sprint) backlog 라는 목록으로 옮겨진다 . 매일 열리는 일일 스크럼 회의 (daily scrum meeting) 에서는 현재 진행 상황을 파악하고 대처할 수 있도록 한다 .스크럼 팀 팀의 크기는 7 명이 이상적이며 , 5 명 미만이거나 , 9 명을 초과해서는 안 된다 . 8 명 이상의 인력이라면 여러 개의 작은마스터 (scrum master) 의 보조가 필요하다 . 제품 소유자는 고객에 해당한다 . 주된 역할은 필요한 기능들을 제품 backlog 에 추가하고 우선순위를 부여하는 것이다 . 스크럼 마스터는 관리자라기보다 리더에 가깝다 . 프로젝트의 진행에 방해되는 장애물을 제거하거나 팀이 스크럼 프로세스에서 규정하는 몇 가지 간단한 규칙들을 잘 따르도록 도움으로써 팀에 봉사한다 .제품 B ackLog 제품이나 프로세스에 관심이 있는 사람이 필요하다고 생각하거나 혹은 제품에 있으면 좋을 것 같다고 생각하는 모든 것을 말한다 . 장래의 제품 릴리즈들에 포함될 모든 특징 , 기능 , 기술 , 개선 사항 및 오류 수정을 정리한 목록이다 . 제품과 관련해서 해야 할 일을 의미하는 것은 무엇이나 제품 backlog 에 포함된다 . 제품을 성장시켜 나가고 자신에게 필요한 것이 무엇인지에 대한 고객의 이해가 깊어짐에 따라 제품 backlog 는 허술한 초기의 목록에서 시작해 점점 발전해 나간다 . backlog 는 역동적이다 . 제품 backlog 는 우선순위에 따라 나열된다 . 최우선 제품 backlog 가 당면한 개발 활동을 결정한다 . backlog 의 우선순위가 높을 수록 더 시급히 처리해야 하고 더 많이 숙고해야 하며 , 그 가치에 대해서 더 많은 합의를 이끌어 내야 한다 . backlog 항목에는 문제가 될 만한 이슈들도 포함된다 . 제품 책임자 (Product Owner) 한 사람만이 제품 backlog 를 관리한다 . backlog 가 만들어지면 제품 책임자는 다른 사람들과 함께 그것을 개발하는 데 얼마나 걸릴지 추정한다 . 번호 설명 1 데이터베이스 버전 관리를 끝마쳐라 2 데이터베이스에서 불필요한 자바 코드를 제거하라 3 Login 클래스가 예외를 던지도록 리팩터링하라 4 동시 사용자 라이선스에 대한 지원을 추가하라 5 평가판 라이선스에 대한 지원을 추가하라 6 검색 시 와일드카드를 사용할 수 있게 하라 7 사용자 설정을 저장하라 8 설치화면에서 실행취소가 가능하야 한다 . 스프린트가 끝날 무렵이 되면 팀은 제품 증분을 인도해야 한다 . 일일 빌드는 팀의 진척도를 측정하는 훌륭한 수단이다 . 빌드하기에 앞서 Test Suite 를 갱신하고 각 빌드마다 smoke, regression test 를 수행해야 한다 . 기존 스프린트 목표가 쓸모업게 된 경우 , 회사 전체가 방향을 바꾸거나 시장상황이나 기술적인 요구사항이 변경된 경우 등 일반적으로 기존 스프린트 목표가 더 이상 현재 사항에 적합하지 않으면 스프린트를 취소해야 한다 . 스프린트 팀에서 스프린트 목표를 달성할 수 없다는 사실을 깨닫게 되거나 , 심각한 난관에 직면하면 스프린트를 취소할 수 있다 .스프린트 계획 회의 스프린트 계획 회의 (sprint planning meeting) 는 스프린트를 시작할 때마다 열린다 . 회의는 보통 하루 종일 한다 . 제품 소유자 , 스크럼마스터 , 팀의 개발자 전체가 회의에 참석한다 . 관심 있는 관리 부서 소속이나 고객 대표가 참석할 수도 있다 . 회의의 전반부는 제품 소유자가 팀에게 제품 backlog 에 남아 있는 항목 중에서 우선순위가 높은 항목들을 설명한다 . 팀원들은 회의 후반부에 스프린트 backlog 로 옮길 항목들을 결정할 수 있도록 충분한 질문을 통해 각 항목들을 숙지한다 . 제품 소유자가 제품 backlog 의 모든 항목을 설명할 필요는 없다 . 현재 팀의 속도를 고려하여 우선순위가 높은 항목들만을 설명하고 낮은 항목들은 다음 스프린트 회의로 연기 할 수 있다 . 제품 소유자가 설명하는 중에 개발 팀이 판단하여 이번 스프린트의 작업량으로 충분하다고 여겨질 때 제품 소유자에게 알려주게 된다 . 팀원들과 제품 소유자는 함께 스프린트 목표 (sprint goal) 를 정의한다 . 해당 스프린트 동안 팀이 이루고자 하는 것을 간략히 기술한 것이다 . 스프린트 종료 시점에 하는 스프린트 검토 회의 (sprint review meeting) 에서 해당 스프린트의 성공 여부는 제품 backlog 의 개별 항목들을 구현 했을 것이라는 약속을 받는다 . 스프린트를 변경해야 할 만큼 중요한 일이 발생한다면 진행중인 스프린트 자체를 취소하고 스프린트 계획 회의를 다시 열어서 새로운 스프린트를 시작한다 .스프린트 검토 회의 각 스프린트에서는 잠재적으로 출시 가능한 형태의 증가분을 제품 소유자에게 인도해야 한다 . 스프린트 검토 회의는 스프린트 종료 시점에 열린다 . 해당 스프린트 동한 수행한 일을 보여준다 . 보통은 새로 추가된 기능들을 데모하는 식으로 진행한다 . 스프린트 검토 회의는 의도적으로 비공식적임을 표방한다 . 이를 위해 파워포인터 사용을 금지 한다거나 회의를 준비하는데 두 시간 이상 걸리지 않도록 하는 등의 규칙을 정하기도 한다 . 스프린트 검토회의가 팀에 추가적인 부담이 되어서는 안 된다 . 해당 스프린트의 자연스러운 마무리가 되어야 한다 . 스프린트 회의에는 전체 팀원뿐만 아니라 제품 소유자와 스크럼마스터도 참석한다 . ( 관심 있는 사람들도 원한다면 참석 할 수 있다 .) 스프린트 검토 회의에서는 스프린트 계획 회의에서 정의한 스프린트 목표를 대상으로 프로젝트를 평가한다 . 해당 스프린트에 계획된 작업들을 모두 완료하면 좋겠지만 , 더욱 중요한 것은 스프린트 목표를 완수하는 것이다 .일일 스크럼 회의 스크럼은 짧은 일일 회의를 하도록 문서화한 최초의 프로세스일 것이다 . 일일 스크럼은 짧은 시간 내에 업무에 큰 지장 없이 프로젝트의 진행 상황을 체크 할 수 있게 해 준다 . 보통 하루 중 가장 이른 시각에 열린다 . 프로그래머 , 테스터 , 제품 소유자 , 스크럼마스터 등 팀 내의 모든 사람이 참석해야 한다 . 회의는 짧게 진행한다 . 보통 15 분 남짓 진행하며 절대 30 분을 넘기지 않는다 . 회의를 짧게 하기 위해 기립 회의를 하는 팀도 있다 . 일일 스크럼에서 각 팀원들은 다음 세 가지 질문에 대답한다 . 어제 무엇을 했는가 ? 오늘 무엇을 할 것인가 ? 장애요소는 무엇인가 ? 일일 스크럼이 스크럼마스터에 의해 진행되어서는 안 된다 . 회의의 목적 중 하나는 해라 . 팀 외부인을 일일 스크럼에 초대할 때는 규칙을 정하여 회의 중에는 프로젝트와 관련된 사람들만 질문할 수 있게 하라 . 일일 스크럼을 통해 모든 팀원이 현재 프로젝트가 어디까지 왔는지 알 수 있다 . 팀원들의 작업 분배를 재고 할 수 있는 장을 마련하도록 한다 . 누군가 일정이 빨리 진행되고 있고 , 누구는 밀리고 있다면 둘이서 짝을 하던지 혹은 작업 자체를 빠른 쪽으로 넘길 수 있다 .스크럼 마스터는 일일 스크럼 동안 위험한 줄타기를 해야만 한다 . 회의를 활기차게 이끄는 한편 참가자들에게 회의가 스크럼 마스터만을 위해 열린다는 느낌을 갖게 해서는 안 된다 . 회의는 Red-Light 방식으로 진 행 한다 . 절대 질문하면 안 되는 것 중 하나는 ' 책을 주문한다 ' 는 스토리를 완성하려면 얼마나 남았습니까 ? 와 같은 것이다 . 일정에 대한 추정은 하지 않는다 . 추정은 공용 화이트보드를 이용해서 팀원들이 추정치를 갱신하도록 유도한다 .스크럼의 주요 규칙 스프린트를 시작할 때 스프린트 계획 회의를 연다 . 각 스프린트에서는 최종 사용자나 고객에게 가치를 제공하는 , 온전히 동작하며 테스트까지 완전히 마친 코드를 만들어야 한다 . 제품 소유자는 제품 backlog 항목에 우선순위를 부여한다 . 팀 전체가 참여하여 해당 스프린트에서 수행할 작업량을 결정한다 . 스프린트가 시작되면 개발 팀만이 스프린트 backlog 에 새로운 항목을 추가할 수 있다 . 제품 backlog 에 언제라도 새로운 항목을 추가할 수 있다 . 또 backlog 내의 항목들은 언제라도 우선순위를 변경할 수 있다 . 짧은 스크럼 회의를 매일 한다 . 회의 참가자들은 각자 다음 질문들에 답한다 . 어제 무엇을 했는가 ? 오늘 무엇을 할 것인가 ? 장애요소는 무엇인가 ? 일일 스크럼 회의에서는 ( 관찰자 혹은 제외된 이해관계자가 아닌 ) 오직 현재 프로젝트에 직접 참가하는 사람들만 발언할 수 있다 . 스프린트의 결과물은 스프린트를 종료할 때 열리는 스프린트 검토 회의에서 시연된다 . 스ow}

공학/기술| 2012.10.31| 15페이지| 1,500원| 조회(250)

방법론, agile, 애자일, Agile 개발의 구성요소, Efficiency ..

미리보기

닫기
요구사항에 대한 패턴

요구사항 패턴기술 시스템간 인터페이 스 시스템간 연 동 표준준 수 요구사항 참 조 문서화 데이터 형 식별자 ID 데이터 구 조 계산 공식 데이터 아카이빙 데이터 수 명 데이터 엔터티 정보 저장 소 살아있 는 엔터티 트랜잭 션 구성 ( 파라미터 ) 시스템 로그 질 의 리포팅 보고 서 접근 성 사용자 인터페이 스 응답 시 간 효율 (TPS,TPMC) 동적 용 량 정적 용량 가용성 ( 무장애 ) 전역성 확 장성 다중성 연장성 ( 연동성 ) 다중언어 설치 성 요금 / 세금 다중 조직단위 사용자 등 록 승인 사용자 인 증 특정 허 가 구성가능한 허 가 사용자 허 가 작업범위기술문서 및 총합 동작하는 방법을 통제 ※ 아카이빙 : 영구적인 한 저장매체에서 다른매체로 데이터를 이동하거나 옮김 . 엔터티 (entity) : 객체로 해석하기도 하는데 , 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 기능 화면 display 기능 정의 여러환경 설 치 설치 및 upgrade{nameOfApplication=Show}

공학/기술| 2012.10.31| 2페이지| 1,000원| 조회(94)

패턴, 엔터티, 요구사항, 요구사항에 대한 패턴, 아카이빙 엔터티

미리보기

닫기
Java 성능 튜닝

Java 성능 튜 닝컴포넌트의 모니터링과 로깅 그리고 인터페이스 J2EE 도구는 J2EE 시스템의 모든 중요한 관점에 따라 모니터링과 로깅을 수행해야한다 . 성능 병목지점일 가능성이 있는 곳은 주로 세 군데로서 , 컴포넌트 내의 처리 , 컴포넌트 사이의 인터페이스 그리고 컴포넌트 사이의 통신 ( 네트워크 전송 같은 ) 이 그것이다 . 컴포넌트 사이의 통신 과부하는 ( 마샬링 같은 ) 인터페이스 과부하나 (SQL 요청 생성 같은 ) 변환과는 별개의 것이다 . 낮은 과부하 J2EE 모니터링은 J2EE 시스템에 과부하를 적게 줘야 한다 . 쓸만한 모니터링을 위해서는 5 % 미만의 과부하가 요구되며 , 1% 의 과부하가 이상적이다 . 낮은 과부하의 모니터링은 , 프로파일링 과부하가 서버의 동작에 어떤 영향을 미치는지를 걱정할 필요 없이 일관성 있게 모니터링만 할 수 있게 해준다 . 낮은 과부하는 ( 개발 시스템 , 테스트 시스템 그리고 production 시스템에서 ) 심각한 성능 저하없이 모니터링을 항상 할 수 있다는 것을 뜻한다 . 이러한 상황은 J2SE 프로파일러에서는 발생하지 않는데 , 만약 , J2SE 프로파일러를 같이 실행시키면서 그렇게 큰 과부하가 발생한다면 프로젝트가 죽기 때문이다 . J2SE 프로파일러로는 그 사용패턴이 명시된다면 높은 과부하도 수용이 가능하기 때문에 과부하가 높은 경향이 있다 . J2EE 모니터링은 개발 시스템과 생산 시스템 양쪽에서 똑같은 목표를 가지고 똑같이 동작하므로 일반적으로 좀더 낮은 과부하를 갖도록 디자인된다 . 메소드에 대응되는 요청 모니터링은 들어오는 요청을 즉시 모니터링되는 메소드 , 컴포넌트 , 통신에 상호 연결시켜야 한다 . 어떤 요청이 어떤 병목현상을 유발하는지를 알 수 있게 , 빈즈에서 데이터베이스 질의로의 요청같은 것들을 쉽게 처리할 수 있어야 한다 . 이러한 능력이 없다면 , 필요 이상으로 훨씬 많은 병목현상을 보게 되거나 , 어떤 요청이 어떤 병목현상을 유발하는지를 결정하는 데 상당한 시간을 소비해야 할 는 것보다 로깅을 하는 것이 훨씬 더 중요하다 . 애플리케이션이 사용하는 자원들을 모니터링하라 . 성능 문제를 유발하는 지점과 경향을 확인하고 , 그 문제들을 제어하도록 애플리케이션을 수정하라 . 그러나 너무 미세하게 로깅을 수행하는 것은 너무 큰 과부하를 유발한다 . 로깅 과부하를 1% 대로 유지하도록 노력하라 . 확장성 모니터링 도구는 생산 환경에서 애플리케이션 모니터링을 수행할 수 있게 애플리케이션과 비슷한 확장성을 유지해야 한다 .자바 가상 머신 힙 크기 튜닝에 드는 노력의 낭비를 피하기 위해 , 다른 튜닝을 하기 전에 먼저 메모리 누수를 제거하라 . 메모리 누수를 제거하는 것은 J2EE 애플리케이션에 반드시 필요하며 , 이러한 누수를 제거했을때에 병목현상이 바뀔 수 있다 ( 제거되거나 혹은 더 커진다 ). 전체 응답 시간 프리젠테이션 시작에서 프리젠테이션 종료까지의 시간을 측정하라 ( 즉 , 모의 사용자가 버튼을 클릭했을 때부터 정보가 표시될 때까지의 시간을 측정하라 ). 서버 요청까지 걸린 총 시간서버에서 요청을 제공하기까지 걸린 총 시간을 측정하라 . 클라이언트로 , 또는 클라이언트로부터의 전송 시간을 포함하려고 하지 말라 . doGet ( ) 이나 doPost ( ) 서블릿 메소드를 둘러싸거나 , 런타임로그를 남기는 ServletFilter 를 사용해서 이 측정값을 얻을 수 있다 . 다음은 그러한 필터의 예다 . public void doFilter ( ServletRequest request, ServletResponse response, FilterChain chain) throws IOException , ServletException { long before = System.currentTimeMillis (); chain.doFilter (request, response); long after = System.currentTimeMillis (); ... // 로그에 시간을 남긴다 . 물론 , 이 필터는 필터 체인의 맨 처음에 있어야만 위해 스마트 프록시를 사용하는 것이다 . 이기법은 , 원격 호출을 하는 객체를 , 원격 호출을 시간측정 로직으로 감싸는 ( java.lang.reflect.Proxy 의 ) 프록시 객체로 대치한다 . 파일 디스크립터 사용 가능한 파일 디스크립터의 개수는 , 각 프로세스마다 그리고 , 전체 시스템에 대해서 제한되어 있다 . 각각의 열린 파일과 열린 소켓은 파일 디스크립터를 필요로 한다 . linux 에서는 ulimit 를 사용해 프로세스에서 사용 가능한 파일 디스크립터의 개수를 확인하고 , 이 개수가 모든 연결을 제공할 수 있을 만큼 많은지 확인한다 . 윈도우즈에서는 성능 모니터에서 열린 파일과소켓의 개수를 알 수 있다 . 빈즈의 라이프 사이클 본질적으로 , 빈즈의 라이프 사이클을 제어하는 메소드 , 즉 빈즈의 생성자 , setEntityContext ( ), Home ( ), Create ( ), Activate ( ), Load ( ), Store ( ), Passivate ( ), Remove ( ), Find ( ) 와 unsetEntityContext ( ) 는 모두 랩핑되어야한다 . 객체가 과도하게 순환되거나 너무 많은 생성은 과도하게 수동적이 되므로 , 이러한 메소드들이 너무 많이 호출되지 않는지 살펴보라 . 트랜잭션 범위 트랜잭션 시작 , 커밋 , 중단 호출은 랩핑되어야한다 . 컨테이너가 이러한 호출의 원인이 될 수 있으므로 랩핑이 어려울 수도 있다 . 트랜잭션 범위를 얻기 위해 JDBC 랩퍼에 의존하는 것이 가장 쉬운 방법일 수 있다 . 먼저 , 데이터베이스 트랜잭션 범위와 일치하는 모든 트랜잭션 범위를확인해야 할 것이다 . 캐시 크기 캐시 크기 ( 가지고 있는 객체의 개수와 사용된 물리적 크기 ) 를 모니터링 해야한다 . 이 과정에는 일반적인 해법이 없으며 , 서버 및 어플리케이션에 맞게 설정해야 한다 . RMI 개념 분산 시스템을 자바에서 지원해 주는 패키지가 rmi 이다 . RMI 란 원격 메서드 호출로 네트워크상에서 떨어져 있는 객체의 메 . 스택 덤프는 현재 실행 중인 모든 스레드의 상태와 자바 스택 목록을 보여 준다 . 데드락 상태에서는 , 두 개 또는 그 이상의 스레드가 ‘ W( 기다리기 ,Wait ) ’ 상태에 있을 것이며 , 이것은 그 스레드들이 락이 해제되기를 기다리고 있다는 것을 가리킨다 . 스택 목록의 꼭대기 (top) 에 있는 메소드가 ‘현재’ 메소드 ( 즉 , 락을 요청하고 대기 상태로이동해 그 락이 승인되기를 기다리고 있는 메소드 ) 다 . 따라서 어떤 메소드가 데드락을 유발하는지를 쉽게 알 수 있다 . GC 중단 가비지 컬렉션이 죽어 버리면 , 현재 가상 머신은 다른 프로세싱 활동을 멈춘다 . 이러한 인식 가능한 중단은 용납하기 어려운 성능 저하를 유발할 수 있다 . 최신의 가상 머신을 사용해서 , ‘ 모든 것을 멈추는’ 중단이 최소화되도록 가비지 컬렉션을 튜닝하라 . 동시 가비지 컬렉션은 중단 시간이 최소화되도록 한다 .객체 Casting 사용은 자제한다 . 객체 타입 캐스팅은 컴파일 시점이 아닌 런타임 시점에 그 형이 결정되므로 불필요한 캐스팅은 수행시간을 느리게 한다 . Primitive Type 를 사용한다 . Primitive Type 들의 Wrapper Class 인 Integer, Double, Character 등등 사용을 자제한다 . Primitive Type( char,byte,int , long,double,boolean,short,float ) 를 사용한다 . I/O Buffering 은 상황에 맞도록 사용 하세요 . Java 의 Buffered* Class 의 기본 버퍼 사이즈는 512 byte 이며 , 1MB 이하 크기의 스트림을 다룰 경우 오히려 버퍼의 초기화 작업 으로 인해 성능이 하락할 수 있다 . 스트림의 크기가 큰 경우에 적절한 버퍼링을 하는것이 바람직하다 . synchronized 는 병목현상을 피하기 위해서 , 가능한한 짧게 유지하며 , 비 synchronized 를 사용한다 . 다중 쓰레드 환경에서의 데이터 공유가 아니라면 , 비 s산은 반복 수행문의 외부로 이동 . Unrolling Loops : 추출가능한 공통적인 수식은 반복 수행문의 외부로 이동 . Design Pattern 적용 : 성능은 떨어질 수 있으나 효율적인 객체지향적 코딩을 권장한다 . Field encapsulation: 직접 접근하지 않고 Set~, Get~ 등의 메소드를 이용해 접근 . Type generalization : 코드가 여러곳에 쓰일 일이 많다고 판단되면 하나의 데이터 타입으로 작성하지 않고 일반화 시킨다 . 예를 들어 정렬 함수를 만든다 하면 int 로만 만드는것이 아니라 int , float 등 더 다양한 타입으로 수행될 수 있도록 만든다 . 모든 소스의 타입을 일반화 시키면 오히려 독이 될 수 있습니다 . 자바 코딩Pull Up : 서브클래스의 메소드를 슈퍼클래스로 옮긴다 . Push Down: 슈퍼클래스의 메소드를 서브클래스로 옮긴다 . Rename method : 메소드의 이름은 현재 메소드가 하는 행동을 최대한 표현할 수 있도록 작성되어야 합니다 . Extract class 한 클래스에 너무 많은 메소드가 있고 하는 일이 명확히 구분되지 않는 상황이 발생할 때 공통된 메소드를 묶어 하나의 클래스로 만들어 사용한다 . Extract method 한 메소드에 너무 많은 코드가 작성되어 있어 스크롤을 과도하게 해야함은 물론 이해도 되지 않을 경우 기능 , 절차에 따라 코드들을 여러개의 메소드로 만들어 사용한다 . Static Method 를 사용한다 . 객체 생성없이 static method 로 접근 가능하여 원하는 결과를 얻을 수 있는 경우 , static method 사용 . Quickly Variable Type 를 사용한다 . 빠른 변수타입을 사용한다 . 기본적으로 가장 액세스가 빠른 변수는 지역 변수이며 int , reference 타입의 변수가 빠르다 . 객체의 직렬화 ( Serializable ) 및 역직렬화 선언은 회피하라 객체를 메모리에 stream 형태로 저장됨으로 , 어플리케이션}

공학/기술| 2012.10.31| 9페이지| 1,500원| 조회(174)

튜닝, 자바성능, 자바 코딩, 자바 튜닝

미리보기

닫기
휴넷 팀장리더십 최강 팀장의 조건 - 사람관리 과제-100점

1.사람관리의 의미팀장으로써, 사람관리는 팀원들에게 목표를 달성하기 위한 동기를 부여하여 팀원의 역량을 최대한 활용하고 팀원들 스스로 문제를 발견하게 하여 원인을 찾게 하고 스스로 해결하도록 긍정적 영향을 주도록 팀원과 팀조직을 관리하고, 팀 외부이해관계자와의 관계를 관리한다.팀원관리는 자아실현과 동시에 높은 성과를 창출하도록 하는 기본 조건으로서팀원에게 목표달성을 향한 개인의 의지(열정), 지향, 노력의 끈기를 유발하도록동기를 부여하고, 사람의 능력을 최대한 이끌어 내기위한 임파워먼트를 활용하여, 구성원 각자 스스로 육성하도록 지원하여 팀원을 성장시킴으로써, 팀 전체를 성장시키는 것이다.2. 사람관리의 4가지 범주1) 팀원들를 동기부여하라동기부여(motivation)란 구성원 스스로 일할 맛이나고, 업무를 즐길수 있도록 하는데 있다.동기부여 되는 구성원은 특정 목표를 향해 일정 기간 동안 특정한 수준의 노력을 투자하기 때문에 기대이론, 개인-조직환경 적합, 내용 이론, 조직 공정성, 목표설정 이론, 직무설계에 의한 동기부여를 한다.따라서, 동기부여는 개인과 상황의 상호작용의 결과이며 개인적 특성이 아니다.2) 임파워먼트를 활용하라!임파워먼트는 권한위임를 포함하는 구성원 능력을 증진 시키는 것이다..즉, 수동적, 상황 적응적 관리를 지양하여 능동적, 상황 창조적 관리를 추구하고 능동적인 행동을 하도록 하고 조직의 지속적인 성장을 추구하며, 팀원들에게 권한을 주어 가장 효과적으로 power가 쓰이는 곳에 power를 이양하고 키워줌으로써, 실질적인 power를 부여하는 것이다.3) 팀원들을 성장시켜라!팀 개개인의 역량을 향상시키고 구성원 스스로 문제를 해결할 수 있도록 지원하는 역할로써, 따팀장은 개인에 대한 이성적 접근인 코칭(coaching)을 해야한다.코칭이란 조직구성원의 목표 설정과 과제 수행을 적극 격려하거나 도전 의지를 촉구하면서 도와주고, 현재의 업무 성과를 개선하여 회사에 대한 공헌도를 높이는 동시에, 장래의 가능성을 이끌어 내는 활동이며, ‘역량’개발, 목표설정과 평가 결과의 피드백이다.코칭의 4가지 모델인 4E Model은 Educate(교육부터), Empower(위임하라), Endow(부여하라), Energize(활력을 줘라)로 분류된다.4)팀의 이해관계자를 관리하라!팀장과 팀원, 팀 전체의 성과에 영향을 미칠 수 있는 이해관계자와의 효율적인 경계관리를(Boundary management) 통하여 성과를 이루며 이해관리자와 관계를 관리하다.경계관리에 대한 4S는 감지력, 화술, 예단력, 결단력 이며 이를 기반으로 이해관계자와 관계를 향상시킬 때 성과를 극대화 할수 있다.본인의 동기부여 혹은 저하 상황 제시- 전년도 목표대비 달성 성과는 상당히 좋았으나 회사가 상위 거래처와 약속한 기술 인력 보강 및 기술적인 능력 저하가 문제가 되어 상위거래처로부터 경고를 받는등 미래 상황이 나빠져 약속한 인센티브를 미지급 받아 동기부여가 상당히 저하되었던 상황이 발생하였다.- 그리고 회사는 상위거래처와의 지속적인 거래가 이루어지지 않을 것에 대한 불안감으로 전년도 달성과는 상관없이 인센티브를 미지급하고 거래처와 지속거래 여부에만 노력을 집중했다.- 기대이론에 맞추어 해석해 보면 전년도 목표 달성을 위해 상당히 노력하여 높은 성과를 받았음에도 평가와 보상의 공정성에 어긋나는 적정 보상을 받지 못해 개인적인 목표 달성을 이루지 못했다.3. 동기부여/저하의 원인을 동기부여의 주요 이론(6가지)을 적용하여 해석- 6가지 이론 중 허쯔버그2요인 이론을 적용해보면 동기요인인 개인적 명성과 개인적 성장과 관련된 요인인 목표를 달성하여 명성과 성장은 이루었으나 위생요인인 직무의 안정성, 업무환경인 주 거래처와의 지속적인 거래 불투명, 인센티브 미지급이 적용되었다.- 동기요인과 위생요인 두 가지가 다 적용되었으나 향후 또한 주 거래처와의 거래관계의 문제가 발생할 가능성이 있어 인센티브 또한 미지급할 가능성이 있다고 미뤄보면 위생요인이 더 크게 느껴지고 올해 또한 업무의 불안함이 강해 전반적으로 동기부여가 약하게 발생되고 있다.- 결론적으로 위생요인인 회사의 불안함은 존재하겠지만 목표달성에 따른 약속의 불이행등으로 공정성 결여에 의한 보상이 작용되면 향후 동기부여에 많은 악영향을 끼치게 된다.- 또한 맥클랜드의 욕구이론에 의하면 높은 성취욕구를 가진 사람은 목표 달성에 대한 피드백은 맞는 것 같으나 중간 정도의 목표달성 가능성 선호는 나에게는 맞지 않는 것 같다.4. 팀원이 같은 상황을 겪고 있을 때 팀장으로서 동기부여 강화를 위해 실행 할 수 있는 실천방안- 팀원이 같은 상황을 겪고 있다면 허쯔버그2요인 이론 중 동기요인을 적용하여 팀원의 목표달성이 팀 전체의 목표달성에 상당한 기여를 하였기에 회사전체의 실적 공유시 팀원의 성과를 회사 전체에 알림으로 팀원의 명성을 높여줄 것이다.- 그리고, 업무성과가 높음을 칭찬하고 성과로 인해 개인적인 성장도 많이 되었다고 인식시키면서 동기부여를 하면 업무 충실도가 높아 질것이다.- 그러나 회사의 위생요인인 상위 거래처와의 지속적인 거래 불투명은 회사의 입장을 이해시키면서 Boundary Management인 팀 외부이해관계자와의 관계를 철저히 관리하여 코칭을 시킬 것이다. 팀 외부이해관계자를 설득시켜 공정성 결여에 의한 보상을 바로 적용시키고(전체 인센티브가 아닌 부분 인센티브 적용) 팀원을 이해 시키겠다. 또한 당해 년도 동기부여는 공정성을 기본으로 약속하고 높은 성과 달성 시 전년도 공정성 결여에 의한 미지급 보상(일부)까지 공정하게 부여한다고 동기 부여하면 좋은 성과를 가져올 것이다.(3) 어려움을 겪고 있는 팀원의 코칭 계획 수립개발지원부서에서 Q/A업무를 5년 동안하고 있지만, 업무에 대한 피로감 및 기획업무에 대한 열망으로 업무에 흥미를 느끼지 못하고 있는 박D는다음과 같은 어려운 문제를 수반하고 있다.1. 지속적이고 반복적인 품질관리 업무에 대해서 업무 열의가 떨어짐-> 타 구성원에게도 영향을 미칠 것으로 보여짐2. 기획업무에 대한 열망이 강하고, 성격도 기획업무에 적합할 것으로 보여짐-> 업무 집중도 하락으로 업무 평가 약화 예상3. 품질기획에 대한 업무에 집중으로 타 구성원 및 상급자와 불화예상-> 팀 전체의 분위기를 망치는 상황 발생예상1) 4E Model 적용Educate : 기획 업무 /훈련 코칭, 업무의 전진 상태, 학습 수준을 보면서 통제를 줄일 것Empower : 품질기획관련 목표를 제시하고, 기획업무를 지양하도록 함.Endow : 열의 강화 : 조직 개편시 팀이동도 가능성 명시 , 숙련도 제고 및 지속적 관찰Energize : 업무에 대한 자부심 재고, 작은 향상이라도 칭찬/인정 하도록 한다.Monitoring과 Feedback을 지속4. 팀원이 같은 상황을 겪고 있을 때 팀장으로서 동기부여 강화를 위해 실행 할 수 있는 실천방안- 팀원이 같은 상황을 겪고 있다면 허쯔버그2요인 이론 중 동기요인을 적용하여 팀원의 목표달성이 팀 전체의 목표달성에 상당한 기여를 하였기에 회사전체의 실적 공유시 팀원의 성과를 회사 전체에 알림으로 팀원의 명성을 높여줄 것이다.- 그리고, 업무성과가 높음을 칭찬하고 성과로 인해 개인적인 성장도 많이 되었다고 인식시키면서 동기부여를 하면 업무 충실도가 높아 질것이다.- 그러나 회사의 위생요인인 상위 거래처와의 지속적인 거래 불투명은 회사의 입장을 이해시키면서 Boundary Management인 팀 외부이해관계자와의 관계를 철저히 관리하여 코칭을 시킬 것이다. 팀 외부이해관계자를 설득시켜 공정성 결여에 의한 보상을 바로 적용시키고(전체 인센티브가 아닌 부분 인센티브 적용) 팀원을 이해 시키겠다. 또한 당해 년도 동기부여는 공정성을 기본으로 약속하고 높은 성과 달성 시 전년도 공정성 결여에 의한 미지급 보상(일부)까지 공정하게 부여한다고 동기 부여하면 좋은 성과를 가져올 것이다.

기타| 2012.10.31| 4페이지| 1,500원| 조회(1,403)

휴넷, 사람관리, 사람관리의 의미, 팀장관리, 사람관리의 4가지 범주

미리보기

닫기