DA: 프로젝트관리

레이블이 프로젝트관리인 게시물을 표시합니다. 모든 게시물 표시

2015년 11월 3일 화요일

협업도구?팀프로젝트관리?3.캔버스

1. 캔버스
1) 의미
캔버스는 그림을 그릴때 쓰는 종이다.

https://ko.wikipedia.org/wiki/%EC%BA%94%EB%B2%84%EC%8A%A4

요즘 협업도구 라는 용어에 관심이 가서 이전부터 쓰이는거 말고
(Office Access 나 jira, redmind 정도) 좀더 간단하고
굳이 it 가 아니더라도 학습 시간을 적게 사용하여
활용할 수 있는게 있을가 싶어서 찾던중 발견하게 된 아이템

2) 특징
(1) 이건 이전에 소개한 트렐로나 콜라비와는 다른 영역임
화이트보드를 큰거 하나주고 도구를 이용해 그리거나
하여 이 큰 판을 구성원들과 공유하고
수정하는 정도의 기능

(2) 물론 일을 받거나 주거나 하지도 않고 할당도 하지 않는다.

(3) 타임라인이 있고 (작업시 팀원들에게 알림이 감)
공동 공간에 작성된 하나의 화면을 팀원과 공유함
+ 팀원간 카톡처럼 채팅 기능이 있음.

(4) 작성이 간단하고 어느 사무실에나 화이트 보드는 많으면
많을수록 좋고 뭔가 구조도를 여기저기 그려놓으면
아직 구현하지 않았지만 마음이 차분해지므로
좋은 툴이라고 생각함

3) 이용방법
여기도 아래 링크로 가서 가입 후 프로젝트를 만들면
프로젝트 밑에 캔버스가 하나 생기며 프로젝트를 클릭시
하얀 판과 좌측에 메뉴를 부여해준다. 이걸로 그리면 됨
사용한도는 생상한 캔버스 + 첨부파일 용량에 따르며 무료
정책으로는 300M까지 사용 가능하다.

https://beecanvas.com/

2. 사용해보기(이용하는 방법)

처음 들어오면 위와 같은 상황 화면이 뜨는데
각 프로젝트 안에 하나 이상의 화이트 보드가 존재하는
형태로 구성되어 있다.

여기서 프로젝트를 만들고 밑에 캔버스를 만들수도 있고
만들어진 프로젝트내에 캔버스를 추가할 수도 있고

탭중에 공유 캔버스를 선택시 다른이가 작성한 캔버스를
볼수도 있다.

캔버스중 하나를 클릭하면

위와 같이 몇가지 도구를 제공하고 빈 화면을 제공한다.
누군가가 열심히 작성하여 내용을 팀원들이 공유하면 끝

공유를 위해서는

캔버스 위의 공유하기 버튼을 누른뒤 해당 링크를 공유하면 된다.

상단의 공유시 권한도 부여가능하다.

3. 결론
화이트 보드로 그리기 좋은 느낌은 살릴 수 없지만
(화이트 보드로 업무를 공유하는 주된 이유가 뭔가
빈 화면에 만들어내는 느낌 아닐까?)
같은 내용을 팀원들 모두 확인 가능하고
다른 장소에서도 확인할 수 있다는 점은 강점으로 보임

2015년 9월 4일 금요일

협업도구?팀프로젝트관리?2.콜라비 살펴보기

1. 콜라비?
1) 의미
양배추에서 분화된 채소인데 잎은 쌈먹고
, 과일같은 줄기는 셀러드로 쓰인다고 함

http://terms.naver.com/entry.nhn?docId=1235388&cid=40942&categoryId=32106

근데 협업 도구 라는 검색으로 보니 광고를 실었는지 구글하고
네이버에 첫번재 검색이 된다.
궁금해서 보는데 기능이 괜찮은것 같아 소개하려고 함.
여기도 프로그램을 설치하는게 아니고 사이트 접속해서
뭔가 사용하면 됨

https://www.collabee.co.kr

2) 특징
(1) 약간 생소하고 과하게 화려하지 않는가? 라는 느낌의 UI이나
생각외로 적응하기 괜찮았다. 기능제한적이긴 하지만
다른데처럼 못쓸 무료버전을 제공하는건 아니고 프로젝트3개,
5기가 이하 메모리 공간 정도를 제공하는데 익숙해져서
꼭 유료결제 해야겠다는 상황까지 쓸 수 있어보인다.

(2) 학습 시간은 필요하다 트렐로보다는 복잡하지만 이정도
기능에 이정도 시간은 투자해도 된다고 봄.

(3) 내가 처리해야할 업무를 확인하고, 다른 구성원들에게도
일이나 결정을 할당할 수 있는 기능이 좋아보인다.

3) 이용방법
여기도 프로그램을 설치하는게 아니고 사이트 접속해서
뭔가 사용하면 됨 런칭한지 얼마 안되서인지 아직은
기능이 부족하다. 그래도 제공되는 기능만으로도

간단한 프로젝트 관리는 가능하다.

https://www.collabee.co.kr

2. 사용해보기(이용하는 방법)
우선 가입은 알아서 하자 간단하다.

1) 프로젝트 만들기
(1) 상단 좌측 메뉴를 누르고 프로젝트+를 누른뒤
제목을 입력하면 끝

2) 구성원 추가
(1) 1)-(1)에서 내공간 누르고 새로만든 프로젝ㅌ 협업도구2를
클릭하면 해당 프로젝트로 들어가진다. 여기서 우측 상단의
파트너 클릭 -> 초대하기 클릭 -> 메일 입력 까지 하면
해당 메일로 초대 메일이 감, 그렇게 해서 알 김경철씨가
들어왔음

(2) 프로젝트에 타임라인이 3개가 있는데 모든게 뜨는 뉴스피드,
뉴스피드에서 체크완료한 확인한피드(확인한 피드틑 뉴스피드에서
제외됨), 시계 표시를 누르면 나중에 확인할 피드 로 나누어진다.

다른분류로 카테고리를 만들어서 거기로 넣을 수 있다. 카테고리
는 타임라인과 별도 관리됨.
내가 쓴글도 또 별도로 관리됨.

현재는 프로그램 내에서 일을 만들고 공유하고 주거니 받거니
하는 형태인데 나중에 메일하고 드라이브 컨텐츠를 업데이트 할
모양인가 보다 이게 중요한데 쩝... 금방 업데이트 될듯

(3) 뉴스피드 우측에는 나에 관련된 정보가 보여지고 여기에는 할일,
결정할일 정도를 볼 수 있다. 이중 체크 버튼을 체크하면
완료된 일은 감추거나 보여지거나 할 수 있다.

팀 구성원에게서 할당받은 일을 완료하면 이런 로고가 뜨는데
책상에 앉아있을때 누군가의 요청 메일이 안오면 f5를 누르듯이
커피 그림 보면서 뭔가 일이 생길때까지 계속 f5를 누르거나
메뉴를 광클릭 하지 않을까 하는 생각이 든다.

(4) 타임라인에 연필 버튼을 눌러서 이슈? 일? 주제? 를 일컫는
큰 덩어리를 등록할 수 있으며 해당 컨텐츠를 클릭해서
일이나 결정을 다른 구성원에게 할당할 수도 있다.
(각각 +버튼으로 추가, 해당 내용을 클릭함으로서 수정)

(5) 내 리스트에서는 나한테 할당된거, 내가 할당한거를

나눠 볼 수 있고 상대방의 피드백을 확인할 수도 있다.

완료는 해당 일의 체크 버튼을
누르거나 결정의 경우 하단 결정을 적어주면 됨.

3. 결론
확실히 편해보임. 다른 컨텐츠(구글독스, 각종 드라이브 등)와

연동이 잘된다면 간단한 프로젝트에서는 트렐로와 같이

뭘로 할지 고민될 것 같다.

2015년 8월 30일 일요일

협업도구?팀프로젝트관리?1. 트렐로 사용방법

1. 트렐로란?
1) 의미

협업 도구이다.(이게 정확한 용어일지는 모르겠지만)

2명 이상 같은 일을 같이 해나갈때
정보를 교환하기 위한 방법의 하나로 프로그램에 의지

하는데 그 툴중에 하나가 트렐로임.

https://trello.com/

2) 특징
(1) 요즘 스타트업에서는 핫하게 사용되는 협업도구.
사용방법도 여러군데서 설명하겠다고 정리하고 있다.
(아래는 이글 작성시 참고한 블로그들)
http://spoqa.github.io/2012/01/02/trello.html
http://clien.net/cs2/bbs/board.php?bo_table=useful&wr_id=245053
....
(아래는 사용방법을 설명한 pt)
http://www.slideshare.net/soymilkvegemil/140109-43340824

(2) 구성이 간단해서 사용이 편리하다. (프로젝트의, 주제의, 할일)

(3) 사용이 편리해서 단순할 것 같지만 쓸만한 기능이 있다.
(할일 안에서 첨부기능이 있는데 이 곳에서는 직접 첨부하거나
구글, bropbox, onedrive 등과 연동해서(선택시 본인 아이디로
연동된 폴더로 이동함) 링크를 거는게 가능하다.

(4) 폰에서도 접속, 작성 가능하다. 그리고 앱도 만들어져 있다.
앱을 설치하면 작업할때마다 팀원들에게도 소식이 가기 때문에
괴롭힐 수 있다. 당신이 팀장이고 트렐로를 쓴다면 반드시
깔게 하는게 좋을듯.
https://play.google.com/store/apps/details?id=com.trello&hl=ko

(5)무료

3) 주로 사용하는 곳
스타트업
내 일기장
학교에서
규모가 작은 회사
새로운걸 잘 시도해보는 회사
빠르게 변화하지만 팀원들과 정보는 꼭 공유해야 하는곳.

4) 이용방법
사이트에서 관리하기 때문에 깔거나 하지 않고 아래 링크로 접속
하여서 가입하면 된다.
https://trello.com/

2. 사용해보기(이용하는 방법)
우선 가입은 알아서 하자 간단하다.

1) 회사 만들기(조직 만들기)
(1) 가운데 트렐로 마크를 누르고

(2) 조직 추가를 누른다.

(3) 입력하라고 하는 제목과 설명을 입력후 create누르면

(4) 이렇게 조직이 하나 만들어졌다.

상단 중앙의 Trello를 다시 누르면 아래처럼

조직이 추가된 걸 볼수 있다.(조직 추가 완료)

2) 조직원 추가하기
(1) 1)-(4)에서 boards, members, settings 중에멤버를 누른다.

(2) add Members 버튼을 누른다.

(3) email을 눌러서(팀원 email은 알아놔야 한다 소식이 일루간다.)
이때 모르는 사용자의 경우 이렇게 나오면서 Send 버튼이 뜨고
Send를 누르면 초대 메일이 가게된다.

이때 한번이라도 다른 Trello프로젝트 참여자는 바로 추가가능하다.

이렇게 조직에 조직원을 끌어들일 수 있다.
모르는 이를 넣게되면 해당 사용자도 remove가 가능하므로
미리 이야기가 된 상태에서 진행해야 된다.

3) 프로젝트(Board) 만들기
(1) 1)-(4) 항목 그림에서 2) 항목에서 만든 조직 란 안에
있는 버튼 Create New Board.. 을 누른다.

(2) Title 항목을 작성한 후 하단 Create버튼을 누른다.
조직은 그대로 둔다.

(3) 정상적으로 Board(프로젝트) 가 생성되었다면
아래처럼 화면이 뜬다.

4) 프로젝트에 멤버 추가하기(조직에 멤버추가하기와 다름)
우측에 <<Show Menu 라는 항목을 클릭하면
프로젝트 상세 메뉴를 볼 수 있다.

근데 아직 멤버에는 나밖에 없는걸 볼 수 있다.
조직에는 추가되어 있지만 해당 프로젝트를 새로 생성 할 경우
프로젝트(board)에도 멤버를 추가시켜야 한다.

(1) Add Members... 를 누르면 조직에 있는 인원의 경우 추가하기
쉽게 보이는걸 알 수 있다. 그 외에 직접 입력해서 추가하는것도
마찬가지로 가능하다. 여기서는 조직에 있는 인원을 추가한다.

(2) 그럼 멤버가 한명 더 추가된걸 확인할 수 있다.

5) 일거리 만들기(큰주제)
(1) 가운데 Add a list... 를 누른다.

(2) 그러면 창이 하나 열리는데 주제를 입력하고
엔터를 누르면 아래처럼 하나의 주제가 생성된다.

6) 일 만들고 할당하기
(1) Add a card... 버튼을 누르면 흰색으로 Title을 추가할 수 있는데
여기에 일을 적을 수 있다.
아래와 같이 적고 엔터를 누른다.
그러면 다른 일을 하나 더 생성해버리는데 아무것도 적지
않으면 그 일은 생기지 않는다. 그렇게 한다.

(2) 여기서는 그냥 1이라고만 적었는데 그 1을 클릭하면 아래와
같이 일에 대한 세부 내용이 뜬다.
세부내용에 대한 설명은 아래와 같다.

(3) 제목, 세부정보, 코멘트는 작성후 엔터 혹은
Comment 버튼을 누른다. 이 세가지는 몇번이고 고칠 수 있다.
코멘트의 경우 작성한 이가 수정 가능하다.

(4) Member 버튼을 통해서 일을 할 사람을 추가하거나 삭제
가능하다. 여기서는 조직, 프로젝트에 추가한 인원을 추가한다.

(5) 라벨은 필수는 아니지만 해당 일이 중요하거나,
회의를 포함하거나 하는 팀내 약속을 정하거나
(텍스를 넣어서) 뺄 수 있다. 색을 추가할 수있고, 연필
버튼으로 텍스트를 넣을 수 있다. 프로젝트별로
색으로 팀 약속을 만들어보자(안해도된다)

(6) 체크 리스트는 팀원들이 읽었을 경우 체크를 하게하는
용도로 쓰이지만 비추다 추가하고 멤버를 넣으면
해당 인원이 체크하도록 자동 설정된다.
해당 인원이 체크할 수도 있고 다른 인원이 할 수도 있으므로
사용은 제한될 것 같지만 결정할 사항이 있을때 물어볼
수 있을 것이다. 체크한 중간과정이 다 로그에 남는다.

(7) 날자를 입력해서 해당 일의 만료일을 정할 수 있다.

(8) 필요한 첨부 파일을 첨부하기 위해 Attachment 버튼을 이용한다.
직접 첨부 이외에 구글 드라이브나 DropBox 등을
연동할 수 있다.

여기서는 MSG 사진을 하나 넣어서 아래처럼 반영되었다.

7) 사용자가 일 넘기기 또는 완료하기
다른 사용자도 일을 만들거나 하는건 6)항목으로 진행 가능하다.
(1) 완료하기
Archive 버튼을 클릭시 해당 일은 완료된다. 그걸 누른다고 바로
화면이 닫히는건 아니지만, 뒤에 프로젝트 안에 해당 일은 없어진
상태로 보인다.
다시 되돌리려면 바로 Send to Board 로 돌리거나
메뉴의 Archive list에서 해당 일을 찾아서 돌리거나
가능하다. Archive 상태에서 Delete를 해버리면 되돌릴수 없다.

(2) 다른 업무로 넘기기
코멘트를 달아서(왜냐면 그래야 다른 사람도 왜 넘겼는지 알수
있으니깐) Move 명령으로 보내면 된다.
담당자가 달라지는게 아니고 (담당자는 담당자 변경으로 진행)(
해당 일의 성격이 주제에 벗어나는 경우 쓰거나 팀 약속에 의해서
정한대로 쓸 수 있을 것이다.
Move 버튼을 누르면 조직, 프로젝트(board), 주제가 뜨고 이를
하나씩 눌러서 다른걸로 선택 가능하다.

8) 해당 프로젝트에서 완료된 사항 확인하기
(1) 7)-(1) 항목에서 완료시 more menu - more - Archived Item
항목을 통해서 지금까지 완료했던 일 항목들을 모두 확인가능하다.
다만 여기서는 분류가 안된채로 나온다.
팀원들이 체크는 했는데 안하거나 안하고 체크도 안하면
갈구자.

3. 결론
협업 이라는 개념이 없다면 이해가 안될수 도 있지만
다른 툴에 비해서는 사용하기 쉬운 편으로 생각된다.
뭔가 소통에 한계점에 부딪친 상황이라면 뭘 해도 안되겠지만
뭔가 시도해보는건 안해보는것 보다 낳다고 생각된다.
최소한 소통이 안되는구나 라는 사실을 알 수 있으니깐.

2015년 4월 9일 목요일

소프트웨어 프로젝트 관리 (FIELD PROJECT CONTROLL FOR SYSTEM STRUCTURE)

Kosta - 2012년 강의중 소프트웨어 시스템 구축을 위한 실전 프로젝트 관리 를 듣고 적음

+ 개인 의견이 다분하게 녹아들어서 작성됩니다.

서두. 프로젝트 관리란?

Teresa S. Stover의 저서 Microsoft® Office Project 2003 Inside Out 에서

발췌한 이 글이 프로젝트 관리 정의에 대해서 틀을 잡아줄 수 있겠어요

http://office.microsoft.com/ko-kr/project-help/HA010014208.aspx

서두-1. 다루는 범위

여기에서는 다음 두가지 사항에 대해서 확인합니다.

- 프로젝트 각 과정별 대괄적인 진행사항

- 프로젝트 중간 시점별로 부족해지거나 챙기기 어려운 부분

(잘 보이지 않는 부분들)

- 산출물은 어느것을 준비해야 하는가

서두-2. 따라서 이번 게시물에서 언급하고자 하는 사항들

- 프로젝트 시작을 위한 주요 활동

- 시작시 해야할 것

- 진행현황 확인방법

- 프로젝트 종료를 위한 준비

* 애자일 프로젝트 관리

차례.

1. 프로젝트 시작을 위한 주요 활동

2. 프로젝트 진행

3. 관리 방법론

4. 개발 방법론

1. 프로젝트 시작을 위한 주요 활동

1-1) 입찰 작업 전 진행되는 사항

※() 묶은 부분은 발주자가 작성함

1-1)-(1) (문제 정의)

발주자가 필요한 부분이 무엇인지 큰 단락을 정해야 함

플잭 컨설턴트 하는 분 내용을 발췌 (http://www.venturesquare.net/39532)

1-1)-(2) (정보요청작업(RFI:Request For Information))

발주자는 필요한 부분에 대하여
이걸 구현하고자 할때 혹은 만들고자 할때 필요한 기술?

알고 있는 대상은 누구인가?

등등 필요한 정보를 얻기위한 목적을 위해 1-1)-(2)를 진행

문서를 받은 입장에서(보통 사업제안자) 제안 회사에서 보유하지 않는
기술이지만 정보요청에 꼭 포함되어야 하는 내용인 경우 해당 기술을
포함하는 업체 등을 확인하여 재요청하는 형태로 정보를 제공해 줘야함

1-1)-(3) 사업계획 수립

(1), (2) 내용을 기초로 사업 제안자가 작성

※ 사업계획서 작성 : (5) 제안 요청서의 내용이 거의다 작성할수 있는 정도의 디테일

1-1)-(4) 사전 규격 검증 기간(현장 설명회)

갑, 을 누구라도 기술 이해 혹은 프로세스 이해를 위한 의견교환이나 구체적인 설명이

필요하다고 판단되면 진행
큰 규모의 프로젝트라면 보통 진행

1-1)-(5) 제안요청(RFP : Request For Proposal)

발주자가 작성 공개 정도를 기준으로 한 분류 방법으로

제한, 공개, 경쟁, 가격 측정 방식으로 나눠짐

※ 제안 요청서 작성시 제안 안내 내용의 스펙 내에 작성해야 함

※ 보통 몇가지 측면으로 측정해 점수화하는데 되도록 많은 득점이 되도록 작성되야함

※ 예정가격 결정방법 :

컨소시엄(지분을 나누는 방법)

하도급 (대장이 받아서 이전에 구두 혹은 문서 약속대로 줌)

공공기관 방식 : 보통 법령에 정한대로 진행함

1-1)-(6) 제안서 수집(현장수집, 제안 설명회)

큰 프로젝트의 경우 제안 요청 이후에도 입찰을 위한 활동들이 진행된다.

1-1)-(7) 입찰 및 계약

입찰되면 계약할때까지 ppt준비하고 보고서 준비하고 조율하고

대상자 선정되면 다시 협상하고 계약하고 계약 안되면... 다른거 입찰하고....

1-2) 입찰부터 계약 진행까지

1-2)-(1) 입찰 참여활동

1-2)-(2) 사전영업

1-2)-(3) 타당성 분석(이익 분석)

1-2)-(4) 제안팀 구성

1-2)-(5) RFP검토

1-2)-(6) 제안서 작성

1-2)-(7) 제안서 제출

1-2)-(8) 제안 설명회 참석

1-2)-(9) 우선 협상 대상자 선정 및 협상(추가 협상 또는 기술협상)

1-2)-(10) 계약

2. 프로젝트 진행

2-1) 개요 및 소프트웨어 개발 프로젝트 이해

3. 관리 방법론

4. 개발 방법론

주로 이 2가지가 프로젝트 구성에 뼈대가 됨

2-1)-(1) 소프트웨어 개발 프로젝트 이해

보통 개발 순서는 진행되는데 : 요구사항 정의 - 분석 - 설계 - 개발 - 테스트

여기서 프로젝트 관리란 : 소프트웨어 구축범위, 개발인력, 개발일정 관리(관리방법론)

이런것들은 관리하겠다 라고 정의하고 여기 정의해놓은거에 의해 활동하는 전체

기간 : 프로젝트 끝날때까지(인도 할때까지)

누가 : pm을 포함한 제품에 발을 담근 모든 관계자

3. 개발 방법론 : ~~한 수행체계

3-1) 개발 방법론 역사? 또는 종류

3-1)-(1) 소프트웨어 개발 생명주기(Software Develoment Life Cycle)

눈으로 확인할 수 없는 개발 과정을 눈에 보이도록

요구사항 정의 ,분석 등으로 단계를 세분화 하여 가시화를 시도

3-1)-(2) 세분화한 각 단계별 할일들을 구체화(활동, 도구, 기법, 산출물)

어떻게 하느냐에 따라서 각각의 방법론이 발전함

3-1)-(2)-1> 구조적 방법론(1960년대)

기존 방법론에 대한 언급은 아래 링크나 구글 형님과 대화하거나 괜찮은

도서를 구입하시는게 좋습니다.

http://blog.daum.net/techmail/6

3-1)-(2)-2> 정보공학 방법론

http://i-bada.blogspot.kr/2012/07/blog-post_4487.html

http://daddycat.blogspot.kr/2011/06/blog-post_8424.html

3-1)-(2)-3> 객체지향 방법론

http://mukang.blogspot.kr/2010/08/blog-post_6089.html

http://blog.daum.net/hankylee/5

3-1)-(2)-4> CBD방법론(기능, 프로세스 중심)

http://abuzz.tistory.com/2

이런 도서를 추천합니다

http://kangcom.com/sub/view.asp?sku=200308010007

3-1)-(2)-5> Enterprise 데이터 중심

엔터프라이즈 방법론은 좀 거대한 기업 시스템에 초첨을 맞춘 개념

3-1)-(2)-6> 객체 중심

객체 지향 이냐 객체 중심이냐 인데 같은 의미로 받아들여도 됩니다.

3-1)-(2)-7> component 중심

재사용성을 증가시키는 라이브러리 단위 개발

3-1)-(2)-8> White Box reUse / Black Box reUse

방법론이라기 애매하지만 보통 자사가 가지고 있는 라이브러리는 jar 형태로

제공하는게 보통이기 때문에 그에 해당 하는게 Black Box라 보면 될 듯.

3-1)-(3) 개방 방법론은 재사용성을 향상시키는 방향으로 발전함

2010년 이후 제안서 작성시 주로 등장하는 방법론은(방법론만 보았을때)

객체 지향 및 정보공학 방법론을 많이 사용함(한국)

3-2) 개발 방법론의 조건

3-2)-(1) 하나의 프로젝트를 일정 단계로 나눌 수 있음 3-2)-(2) (1)에서 정의한 각 단계별 산출물 리스트 보유 3-2)-(3) 각 산출물 리스트 에 사용할 산출물 양식 또는 문서를 포함 3-2)-(4) 해당 산출물 및 산출물 양식은 (1)에서 정의한 일정에서 요구하는 방법론 진행하는데에 있어 일치해야함 3-2)-(5) 한국에서 사용하는 개발 방법론 묶음? 또는 개발 방법론

3-2)-(5)-1> 관리기법1 - 한국 전산원에서 제공

- 구조적, 정보공학 방법론을 기초로 작성됨

- 개발 방법론, 관리 방법론에 대한 산출물들이 다 정의되어 있음

※ 마르미에 대한 설명 http://daddycat.blogspot.kr/2011/06/iii.html

3-2)-(5)-2> 마르미1 - 모름

- 구조적, 정보공학 방법론에 기초

3-2)-(5)-3> 마르미2

- 객체지향 방법론에 기초

3-2)-(5)-4> 마르미3 - 한국정보화 진흥원(2011.12)

- CDB를 기초

- 최초 작성시 ETRI에서 작성 이후 한국정보화진흥원으로 기술 이전

3-2)-(5)-4> 마르미4 - 한국전자통신연구원 http://www.etri.re.kr
- Embeded System 을 위한 개발 방법론

http://blog.daum.net/hihfly/12364189

4. 관리 방법론

4-1) 관리 방법론 종류

4-1)-(1) PMBOK

4-1)-(2) CMMi

카네기 멜론대학내 SI 단체에서 제시한

프로젝트 성숙도 모델

프로젝트 관리 방법론과 통합된 개념

일정 이상 수준의 프로젝트 관리 방법론이 적용되었다면

일정 품질 이상의 제품이 도출된다. 1~5단계로 평가되고

3단계부터 유효성을 지님

우리 나라 업체도 많이 함. 보통 4단계 3단계 많이 따는걸 들음

4-1)-(3) SP인증제

CMMi 비용 과다에 따라 한국에서 자체 수행하는 인증

1~3등급으로 관리중 2012년에는 많이 하지 않지만 하는

업체도 있다고 했는데 지금은 ...?

4-1)-(2) PRINCE2 방법론

유럽에서 많이 쓰이는 방법론,

유럽 진출시 필요, 한국에서는 잘 안쓴다고 함

4-2) 관리 방법론의 영역, 그리고 관리 영역의 수행체계 (혹은 PMBOK)

4-2)-(1) 프로젝트 관리 삼요소

예산, 일정, 품질

예산, 일정, 범위

개념은 붉은색, 실무에서는 파란색을 비중있게 보고

자격증에서는 두가지를 다 알고 있어야 함

4-2)-(2) 프로젝트 관리 영역

4. 통합관리

5. 범위관리

6. 일정관리

7. 원가관리

8. 품질관리

9. 인력관리

10. 의사소통관리

11. 위험관리

12. 조달관리

+ 이해관계자 관리

※각 관리명칭 앞의 숫자는 pmbok에서 정한 관리영역별 번호

4-2)-(3) 각 관리 영역별 산출물

(각 항목 서류 양식은 시험 준비하신다면 손닿는데 있습니다 )

4-2)-(3)-1> 통합 :

- 프로젝트 관리 계획서

- 사업 수행 계획서

- (추가) 변경 관리 대장, 혹은 내역서 (포함) 변경 요청서

4-2)-(3)-2> 범위 :

- WBS(Work Breakdown Structure)

- (추가) 요구사항 정의서

- (추가) 영향분석서

- (추가) 개발방법론

4-2)-(3)-3> 인력

- 인력투입 계획서

- 공정별 인력투입현황표

- (추가)인력변경 요청서

4-2)-(3)-4> 품질

- 품질관리 계획서

- 인스펙션 결과서

- 테스트 결과서

- (추가)인스펙션 계획서

- (추가)테스트 케이스

- (추가)시나리오

- (추가)개발 방법론

4-2)-(3)-5> 위험

- 위험관리 계획서

- 위험관리 등록부

- (추가) 주간, 월간 보고(이슈 현황이 포함된) 혹은 이슈 현황

4-2)-(3)-6> 일정

- 인력별 프로그램 개발현황

- (추가) WBS

- (추가) PMS

4-2)-(3)-7> 의사소통

- 주간, 월간, 수시보고

- (추가) 착수 및 완료 보고

4-2)-(3)-8> 원가관리

- 실행예산 계획서

- 집행내역

- 결과서

- (추가)PMS

4-2)-(3)-9> 조달관리

- 조달구매 계획서

- 납품내역

- 결과서

- (추가)PMS

4-2)-(3)-10> 이해관계자 관리

4-2)-(4) 통합관리

플잭 진행중 하나의 변경 사항에 대한 다른 변경사항을 통제,

조정하도록 조율하는 관리 영역

(2010년 초반부터 PMO 라는 조직을 큰 프로젝트에 넣도록

하고 있는데 이와 관련 있음 또는 PM이 하는일)

4-2)-(5) 범위관리

범위관리에서는 요구사항 관리를 반드시 관리해야 하며

이를 위해서 WEB, 요구사항 정의서 두가지를 꼭 상의없는

변경이 이루어지면 안된다.

PM 그리고 담당 개발자가 모르는 사이 정의서 내용이 수시로 바뀌게

되면 프로젝트에 치명적일수 있음

WBS작성은 범위 관리분야에서 주도하여 작성

여기에 요구사항 상세화, 작업범위 크기 가 작성되야 하며

해당 문서에 고객의 동의가 되어야 하며

이후 고객의 변경된 요구사항을 같이 정리 할수 있어야 함

(=변경점관리가 되야함)

차후 검수시 요구사항 상세화 내용으로 검증 진행할수 있는 수준

아무리 큰 플잭도 2주 이내 작성해야 하며 그 이하는 범위를 쪼개서

작업,

WBS 관련 내용은 주기적인 내용을 고객에게 보고하는 체계를

갖추는게 좋음

요구사항 정의서

유형 분류(기능 혹은 비기능 -> 비기능에는 품질, 보안 성능 등등)

중요도/ 우선순위(등급별로 체크)

난이도

요구사항 추적표 : 중간 변경 요청시 반영을 고려

요구사항, 요구사항 변경에 따른 개발 지침

- 형상관리는 케이스별로 이렇게 한다.

- 요구사항 변경에 대해 이렇게 대처 한다. 정도가 포함되어야 함

4-2)-(6) 일정관리

WBS, 프로그램 개발 일정표 두가지를 중심으로 작업 진행 체크

가중치 항목 혹은 중요도 : 사업관리 영역, 또는 구현부분에서

가중치 부여 정도를 결정, 정의하는 부분

작업 완료 기준서? 혹은 기준 제시서 등

구현 완료의 기준이란? 어디까지 일까?

- 작성 완료

- Git 또는 서버에 업로드 완료

- 개발자가 테스트 완료하고 업로드 한 시점

- 업로드 후 테스터 조직이 테스트를 시작할 수 있는 시점

- 테스트 완료 시점

- 테스트를 완료 후 X개 이하 오류 검출시 완료

- 해당 부분에 대한 테스트 후 버그를 완전이 제거하여 재

테스트 후 다시 업로드 한 시점

- 테스터 조직이 테스트 후 오류가 없는 시점

아직 구현이 완료되지 않았는데 90%, 80%의 공정이란

소프트웨어 개발에서는 갭차이가 발생할 수 있음(아주 크게)

WEB를 작성하기 위한 툴들 : ex)CPM(Critical Path Methodology) 등등

일정 관리 차트 (작성보다는 이용한다는 게 더 알맞다고 봄)

간트 차트 (바 형태로 표현)

마일스톤(간트 차트 + 특정 이벤트를 포함시킴(감리, 이벤트 점검 등)

Pert기범(chart) 예상 소요일수을 판단해 현재 진행 상태가

어느정도의 퍼포먼스를 내고 있는지 판단함

CPM 각 활동을 도시화하여 표현, 전체 프로젝트 일정을 확인

PERT/CPM (CPM과 동일 단 PERT 방법으로 산출해냄)

4-2)-(7) 인력관리

중요 담당자

품질, 표준(통합)담당자 (개발환경구성, 프레임웍 구성, API개발)

인프라 구축

시스템

사용자

개발자

프로젝트에 소요되는 인적 자원을 관리하는 것

이를 관리하기 위해서는 필요한 정보, 수정해야할 사항은

계획표 또는 현황표

변경관리 내역서(변경관리 대장과 같이 작성)

제안서(방법론, 그러나 플잭 들어와서는 거의 결정된다고 봐야함)

방법론을 바꾸고자 하는 경우 아래 절차대로 진행

사업수행 계획서 작성(계약시 결정사항에 대해 재검토)

-> 고객 협의 -> WEB 작성(산출물, 일정, 추진절차)

-> 계획서는 최종본으로 수정되고 공문 처리

4-2)-(8) 예산관리

원가 및 예산산정

원가 를 결정하는 요소들

4-2)-(8)-1> 소프트웨어 개발비(인력비)

- 본수 또는 MM(Man/Month) 또는 FP(Function Potin) 소프트웨어 규모산정

- FP 측정순서 : 자료 입출력 혹은 조회-> 내.외부 논리 및 연계 파일(DB table)

-> 데이터 및 트랜잭션 기능 측정 -> 미조정 기능점수 계산 및 조정 인자 결정

-> 조정 기능 점수 계산

4-2)-(8)-2> 하드웨어 비용

- 트랜잭션과 동시사용자, 서버, 메모리, 디스크 용량 산정

- 위 내용을 토대로 하드웨어 Spec 결정 및 비용산정

4-2)-(8)-3> 소프트웨어 구매비용

- 웹 레포팅 툴, 문서보안, WEB-WAS-DBMS 등 시스템 소프트웨어

- 소프트웨어는 설치대상, copy수, 대상 서버 스펙, 설치대상 Agent수로 비용산정 함

4-2)-(8)-4> 출장비

4-2)-(8)-5> 인쇄비

4-2)-(8)-6> 동영상 제작

4-2)-(8)-7> 장소 임대 및 기타 간접비용

4-2)-(9) 조달구매관리

필요한 산출물

원가 산정내역서(대상,기준,계산과정을 보여주는 내용)

원가 산정 계획표 및 현황

4-2)-(10) 위험관리

정의 : 프로젝트 진행에 긍정적, 부정적 영향을 미치는 이벤트, 사건

리스크 : 잠재된 위험

이슈 : 위험이 외부로 보여지는 상태

작성 문서

위험관리계획서(사업 초반에 작성)

- 위험관리 계획서는 아래 순서로 작성함

- 리스크 관리 계획 수립

- 리스크 식별

- 정성적 리스크 분석

- 정량적 리스크 분석(정량적 리스크는 이슈라고 정의하기도 함)

- 리스크 대응계획 수립

- 리스크 감시 및 통제

위험관리대장(각 단계별로 작성) 혹은 리스트 등록대장

작성문서는 계획단계부터 개발이 진행되는 상황별로 계속

작성하는게 기본임.

(계속 세분화, 식별, 수시 작성, 업데이트)

정량적 리스크 분석 방법

민감도 분석(Sensitivity Analysis) : 환경을 억제하고 1개 값 변화시

결과값의 변화폭을 확인(에러나 값이 예상 밖의 변화를 기대함)

몬테카를로 시뮬레이션(Monte Carlo Simulation)

비슷한 유형 프로젝트 경험치를 보고 해당 프로젝트의 성공

가능성을 판단하는 방법

위험분류체계(RBS: Risk Breakdown Structure)

위험 등급을 분류 : 발생 가능성, 발생시 영향도

위험요소 측정 대상을 정의

확인 주기

확인 방법

위험 분류체계는 정기 보고 이전에 체크되어 작성포함되어야 함

4-2)-(11) 품질관리

작성 문서

품질관리 계획 및 결과서 혹은 품질 보증 계획서

- 포함사항 : 품질지표, 품질측정 대상, 방법, 주기 는 필수

- 장려사항 : 전문인력 확보, 품질활동 결과분석 및 조치

공적표준(공신력 지닌 기관에서 지정한 표준 KS, TTA, ISO9126)등

사실표준(산업계 표준처럼 쓰는 표준 CMMi, GS(Good Software)

- 인스펙션 계획(계획 단계에서 시기, 대상, 범위를 정의) 또는 동료 검토서

품질 담당자의 중재하 진행 필요

※ 오버뷰 : 실행전 계획 구체화, 품질관리 확인 대상자에게 교육

※ 사전검토 : 인스펙션 수행, 결과확인 까지 진행

테스트 활동 계획 및 결과서

품질지표(ISO9126)

- 프로세스(이행율 및 조치율)

- 품질활동(방법, 주기, 대상) 정의

- V&V모델이 품질관리 기본이 됨

테스트 : 내용이 커서 별도로 묶음

큰 프로그램내 테스트 100% 통과가 가능할까?

로또 맞는 정도라고 보면 적당하지 않을까?

그래서 정의하길 핵심과제는 100% 충족

그 밖에는 데드라인을 정하고 그 이상의 품질을 목표로 함

테스트는

- 단위테스트(기능 테스트)

- 통합테스트(전체 시스템 구동 테스트)

- 시스템 테스트(전체 시스템을 구동 + 보안, 시스템성능, 부하 측정)

- 인수 테스트(사용자 요구에 맞는가?)

감리활동(중요한 품질활동중 하나)

한국의 경우 공기업은 일정 금액 이상시 필수 진행(2012년 이전 기준)

감리는 중간감리(설계단계 끝날시), 와 최종감리(구현완료, 오픈전)

검사는 산출물 대상으로 감리가 진행되며 감리 대상은

사업관리(품질), 응용시스템, DB, 인프라 중심으로 진행

품질 활동으로 영역이 커지고 있다고 생각됨

4-2)-(12) 의사소통관리 - 13번과 내용이 일부 중첩되어 뒤로 미룸

문건들

이해 관계자 식별

의사소통 계획수립

정보 배포서

기대사항 관리, 성과보고서

관리중점

의사결정자, 실 사용자의 명확한 구분이 필요

회의시 적절한 대상을 참석하여 정보 획득 필요함

개발중에도 실 사용자에 대한 접근도 필요함

의사소통 관리 계획서

회의록 개념이지만 다른 차원에서 접근(장기적인 측면)

4-2)-(13) 이해관계자 관리(2013 이후 포함된 개념)

4-2)-(14) 프로젝트 진척 현황 관리

기성고 관리 : 시간, 인원을 모두 금액(숫자)로 환원

EVM(Earned Value Management)

계획과 실제가 틀어지는 갭을 조정하기 위한 계획대비 실적관리

통제 기법

계획대비 일정 진척률 차이(SV), 진척률 차이(SPI)

변경관리(범위, 일정변경, 인력, 원가 품질 등등)

적용 순서는 아래와 같음

변경 대상 식별

->영향도 분석

->반영여부, 반영 수준 협의(회의록 또는 공문처리와 병행)

->변경요청 공식화(변경요청서)

->변경에 따른 계획 수정(WBS, 사업수행 계획서)

->변경 내용 공유, 배포(변경관리 내역서, 자기 정기보고)

위험요소 관리

위험요소 현황확인

->요소별 분석

->대응방안 확인

->조치 및 대응

품질확인하기(실제 플젝간 참여 시기)

요구사항 분석

->설계

->구현(계획서 작성 및 품질 확인 준비)

->테스트(결과서 작성과 병행)

4-2)-(15) 프로젝트 종료하기

산출물 정리

검수 요청서, 검수 기준서(필수)

과업내용 대비표, 감리조치결과포(감리 포함시 필수)

유지보수 계획서, 잔여업무 수행 및 조치계획

(사용자와 프로그램 인도조건에 해당 사항이 포함시)

(보통 결국엔 포함되는 경우가 많음)

하자보수 이행 증권

(하자보수 이행 계약이 포함시)

(보통 결국엔 포함되는 경우가 많음)

프로젝트 이후 개선 방향 도출하기