꿈을 꾸다~!!

« 2024/04 »
일	월	화	수	목	금	토
	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

▣ S/W tip - 해당되는 글 35건

▣ 1 Man/Month (맨/먼스) - S/W tip - 2017. 6. 23. 17:27

소프트웨어개발 사업의 대가를 계산하는 방식의 하나로 한 사람이 한 달 동안 할 수 있는 양을 계산해 사업비를 책정한다. 즉 사업에 투입한 인력 수를 기준으로 사업비를 책정하는 방식인 셈이다.
인력을 기준으로 사업비를 책정하기 때문에 발주자나 관리자 입장에서는 편리하다. 하지만 투입 인력의 수준에 관계없이 인력의 수에만 초점을 맞추다 보니 소프트웨어의 질을 확보하기가 쉽지 않다는 단점이 있다.

[네이버 지식백과] 맨먼스 [man/month] (한경 경제용어사전, 한국경제신문/한경닷컴 )

저작자표시

▣ 개발자 커리큘럼 및 개발 책 추천 - S/W tip - 2016. 1. 29. 14:07

아래는 전 회사에서 공유되었던 개발자 커리큘럼인데 참고하시기 바랍니다.(아래의 교육 과정이 정답은 아니지만, 개발자라면 알아야 하는 필수 목록이라고 생각하시면 될 것 같습니다.)

아래는 전에 보내드렸던 참고 도서이므로 각 과정에 맞춰 보시면 됩니다.

모두 개발관련 서적인데, 워낙 유명한 책들이라서 보시면 도움이 되실 겁니다^^

(아래의 책은 모두 제가 소장하고 있어서 빌려드릴 수는 있지만, 꼭 필요한 책은 회사차원에서 구입하는 것도 괜찮을 것 같습니다.)

[UML 실전에서는 이것만 쓴다.]

UML에 대해 설명하는 책이지만, ~~UML에 너무 의존하지 말라는 메시지를 담고 있으며~~, UML과 객체지향 개발의 원칙, 분석-설계-구현-테스트 까지 설명하고 있어 상당히 많은 도움이 되는 책입니다.

객체지향 SW 설계의 원칙(너무나 유명해서….)

1. 개방-폐쇄 원칙
2. 단일 책임 원칙
3. 인터페이스 분리의 원칙
4. 리스코프 치환 원칙
5. 의존 관계 역전의 원칙

[헤드 퍼스트 디자인 패턴/ GOF의 디자인 패턴]

고전적이면서 정말 유명한 책입니다. JAVA언어로 되어 있지만(이런 류의 책들은 C#은 찾아보기 힘들며, JAVA라고 해도 문법은 비슷하고, 개념만 이해하면 됩니다.), 디자인 패턴을 적용하는 이유와 패턴을 적용한 후의 효과에 대하여 비교적 쉽게 기술되어 있고, OOP를 충분히 만끽? 하실 수 있을 것입니다.

[아는 만큼 보이는 데이터베이스 설계와 구축]

데이터 베이스 모델링, 설계, 정규화/반정규화 방법, 튜닝 등 프로젝트에서 실무적인 내용을 바탕으로 작성되어 있어 상당히 유용한 책입니다.

[Effective C#]

C#이라는(유일한 C#책) 언어를 좀 더 효과적으로 사용할 수 있도록 지침/노하우 50가지를 정리한 책인데, 초급자가 생각하기에도 당연하면서도 기초적인 내용도 다루고 있습니다.(그렇지만 많은 개발자들이(저를 포함하여) 지키고 있지 않은 것들)

[Refactoring]코드 품질을 개선하는 객체지향 사고법

역시나 너무나 유명한 책입니다. 코드 품질을 개선하는 객체지향 사고법을 정리한 책인데,(최근의 개발방법론도 포함) 필수적으로 읽어야 할 책이 아닌가 합니다.

왜?
- 소프트웨어의 디자인 개선.
- 소프트웨어에 대한 이해력 향상.
- 버그 탐색.
- 빠른 프로그램 작성.
언제?
- 삼진규칙 : 세번째 중복 코드 발견 시.
- 기능 추가 시.
- 버그 수정 시.
- 코드 리뷰 시.

저작자표시

▣ Stored procedure 템플릿 등록하는 법 - S/W tip - 2013. 7. 24. 13:45

VS2010 에 Stored Procedure 템플릿 등록하는 법입니다.

아래의 지정한 각 폴더에 첨부한 파일을 압축해제해서 복사합니다.

폴더명은 각자 자기 로그인 아이디로 바꿔야 합니다.

Templates1.zip ->

c:\Users\administrator\AppData\Roaming\Microsoft\VisualStudio\10.0\ItemTemplatesCache\

Templates2.zip ->

c:\Users\administrator\Documents\Visual Studio 2010\My Exported Templates\

Templates2.zip ->

c:\Users\administrator\Documents\Visual Studio 2010\Templates\ItemTemplates\

복사한 후에 VS2010을 다시 시작합니다.

사용법 설명 : Webplus.HyundaiMipo.MDS.DB.MDS_AS 프로젝트에 SP를 추가하고자 하면

1. Webplus.HyundaiMipo.MDS.DB.MDS_AS의 User Procedure에서 마우스 오른쪽 버튼 클릭

2. 추가 -> 저장 프로시져 -> 설치된 템플릿 클릭

3. 오른쪽 창에서 UP_MDS_AS 선택

4. 아래쪽에서 파일명을 SP명명 규칙대로 파일명을 입력

5. [추가] 클릭

6. 화면에 나타난 소스의 맨위에 "use MDS_AS"가 있는지 확인

7. If exists문 마지막 where name="부분에 4에서 지정한 파일명이 제대로 있는지 확인

8. Drop Procedure문 확인

9. create procedure문 확인

템플릿 설명 : sql문 맨 위에 있는 "USE"문에 따라

UP_MDS_AS : MDS_AS 데이터 베이스에 SP가 생성됨
UP_MDS_COMMON : MDS_COMMON 데이터 베이스에 SP가 생성됨
UP_MDS_EXCHANGE : MDS_EXCHANGE 데이터 베이스에 SP가 생성됨
UP_PlusMail : PlusMail 데이터 베이스에 SP가 생성됨

USE [MDS_AS]
GO

if exists (select * from sys.procedures where [name] = N'$safeitemname$')
BEGIN
drop procedure [dbo].[$safeitemname$]
END
go

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

/*********************************************************************************
SP 명 :
SP 기능 :
작 성 일 :
작 성 자 :
실행예제 : EXEC [dbo].[$safeitemname$]
수 정 일 수정자 수정한 라인 번호 및 수정 사항

*********************************************************************************/
CREATE PROCEDURE [dbo].[$safeitemname$]
@param1 int, --
@param2 int --
AS
BEGIN
SET NOCOUNT ON

END

▣ 추천 사이트 - S/W tip - 2013. 7. 24. 13:18

http://www.w3schools.com/default.asp

▣ AS-IS / TO-BE 분석 - S/W tip - 2012. 9. 3. 15:23

출처 : http://dasoon.egloos.com/2371229

AS-IS 분석

AS-IS 분석이란 현재의 업무 프로세스를 분석하는 것을 말한다. 이는 크게 3가지로 나누어지는데 첫 번째가 AS-IS 프로세스 목록 작성이고, 두 번째가 AS-IS 프로세스 체계도 작성 그리고 세 번째가 AS-IS 프로세스 정의서를 작성하는 일련의 작업이 수반이 되어진다. 첫 번째의 AS-IS 프로세스 목록작성이란 업무를 대분류, 중분류, 세분류, 프로세스 설명 등을 엑셀 등을 이용하여 목록을 작성하는 것이고, 두 번째의 AS-IS 프로세스 체계도 작성이란 업무가 어떤 체계의 구조를 가지고 있는지에 대하여 계층구조 형태로 업무를 분류하는 작업믈 말하여, 세 번째의 AS-IS 프로세스 정의서란 업무의 흐름에 대하여 Flow Chart 형태로 업무를 정의하는 작업이다.

AS-IS 분석은 앞에서 얘기한 부서의 Needs 분석 자료를 가지로 AS-IS와 Needs간의 Gap 분석을 통하여 구현하고자하는 ERP의 이슈들을 도출하는 자료가 된다. 또한 나중에 TO-BE 분석 자료를 가지고 AS-IS와 TO-BE간의 Gap 분석을 통하여 구현하고자 하는 전체적인 ERP 틀이 잡혀지기 때문에, 시간도 많이 들어가는 반면 아주 중요한 분석 자료가 된다. 이 AS-IS 분석은 컨설턴트들이 어떤 조언이나 방향을 얘기해 줄 수 있는 부분이 아니며, 단지 어떤 형태의 틀로 위의 3가지를 작성해야 하는지에 대해서만 알려준다.

실질적으로 AS-IS 분석은 PI들이 많은 노력과 시간을 보내는 부분 중에 하나다. 그리고 컨설턴트들이 프로젝트를 추진하는 업체를 판단하는 자료가 되기 때문에, 어떤 부분에 대해서는 PI들이 컨설턴트들에게 조언을 해주어 우리 회사의 프로젝트가 성공적으로 구축될 수 있도록 유도해야하는 부분도 있다. 그리고 AS-IS 분석을 잘 해 놓으면 나중에 구현하고자하는 분석인 TO-BE 분석을 하는데 큰 어려움 없이 TO-BE 분석을 할 수 있다. 그러므로 시간이 많이 든다고 하여도 프로젝트를 추진하는 업체의 PI들이 공을 많이 들여 만들어야 하는 것이다. 의료원의 PI들은 7월말에 SAP 모듈별 교육 일정이 잡혀져 있어서 늦은 시간까지 AS-IS 분석을 해야만 했다.

나의 경우는 AS-IS 분석을 하면서 과연 CO(관리회계) 모듈을 통해서 의료원에서 요구하는 예산부분을 구현할 수 있는지 궁금했다. 의료원의 특수성인 대학회계 부분과 병원회계 부분에 대하여 나의 느낌은 병원회계는 몰라도 대학회계 부분은 CO 모듈을 통해서 예산부분을 구현할 수 없다고 생각이 되었다. 이는 대학회계의 경우는 예산통제가 절대적으로 필요한 부분이라 CO에서 구현하는데 무리가 있다는 판단이었다.

그래서 CO 모듈 컨설턴트에게 대학회계의 예산관리는 FM(Fund Management) 모듈을 사용하겠다는 의사를 밝혔다. 그리고 컨설턴트도 대학예산의 특수성이 있기 때문에 CO 모듈보다는 FM 모듈이 적합할 것이라는 의견을 주었다. 또한 병원회계에 대해서도 SAP에서 CO 교육을 받아본 후 예산관리를 CO 모듈을 사용할지 FM 모듈을 사용할지 결정하겠다는 의사를 밝혔다. 그리고 컨설턴트 회사인 L사의 ERP 팀장으로부터도 예산관리를 하는데 있어 CO 모듈을 사용하던, 아니면 FM 모듈을 사용하던 문제가 되지 않는다는 답변을 얻었다. CO 모듈을 사용하여 예산관리를 하고자 하는 경우 USER EXIT를 통하여 예산통제가 가능하고, FM 모듈을 사용하면 FM 모듈자체가 예산관리 모듈이기 때문에 문제가 되지 않는다는 답변이었다.

내가 왜 예산관리에 대하여 CO 모듈을 사용할지 FM 모듈을 사용할지에 대하여 칸설턴트에게 한 얘기를 서술하는가는 나중에 이것이 컨설턴트와 L사의 ERP 팀장과의 마찰의 원인이 되고, 추후 얘기를 서술할 것이기 때문이다.

TO-BE 분석

TO-BE 분석이란 AS-IS 분석과 비슷한데, AS-IS분석이 현재의 업무 프로세스를 분석하는 것을 의미하다면, TO-BE 분석이란 미래에 구현하고자하는 업무 프로세스를 정의하는 분석이다. TO-BE 분석도 크게 3가지로 나누어지는데 첫 번째가 TO-BE 프로세스 목록 작성이고, 두 번째가 TO-BE 프로세스 체계도 작성 그리고 세 번째가 TO-BE 프로세스 정의서를 작성하는 일련의 작업이다. 첫 번째의 TO-BE 프로세스 목록작성이란 SAP의 ERP에서 업무를 1레벨, 2레벨 등으로 레벨별로 구분하여 세부업무에 대한 레벨은 하위 레벨로 정하여 최하위 레벨과 SAP의 T-CODE(트랜잭션코드)를 매칭하는 작업을 하는 것이고, 두 번째의 TO-BE 프로세스 체계도 작성이란 SAP 기준으로 업무가 어떤 체계의 구조를 가지고 있는지에 대하여 계층구조 형태로 업무를 분류하는 작업을 말하여, 세 번째의 TO-BE 프로세스 정의서란 SAP 기준으로 업무의 흐름에 대하여 Flow Chart 형태로 업무를 정의하는 작업이다.

TO-BE 분석에서 중요한 것은 각 모듈별로 TO-BE 프로세스를 작성을 하였으면 통합 프로세스에 대하여 설계해야 한다는 것이다. 의료원 프로젝트팀에서는 통합 프로세스 설계에 대한 논의가 많이 있었다. 특히 대학회계 EPR를 추진할 때 참여하였던 PI 중심으로 전체 의료원 업무에 대한 통합 프로세스를 작성해야 한다는 주장이 많았다. 이는 대학회계에서 발생되었던 문제가 의료원 전체 EPR를 구현하면서 다시 발생되지 않도록 하자는 배경과 함께, 전체적 밑그림을 알아야 PI들이 TO-BE 프로세스를 올바로 정의하여 ERP를 좀더 완벽하게 구현할 수 있으리라 믿었기 때문이다. 하지만 우리 의료원은 통합 TO-BE 프로세스에 대한 논의가 있었지만 이는 단지 몇몇의 얘기로 끝나고 말았다. 내가 시간이 흘러 지금까지 안타까워하는 것이 바로 이부분이다. 그 때 통합 프로세스에 대하여 모든 모듈 PI들이 모여서 정의했었다면 멋있는 작품이 탄생하지 않았을까 하는 안타까움이 남는 부분이다.

ERP 프로젝트를 구현하고자 하는 분들에게 여기서 한마디 조언을 해 드리고 싶다. 내용은 무슨 일이 있더라도 각 모듈별로 TO-BE 프로세스 분석이 끝났으면 꼭 통합 프로세스에 대한 정의를 각 모듈 PI들이 모두 모인 가운데 밤을 새워서라도 꼭 설계하라는 것이다. 내가 속해 있는 의료원에서도 못했는데 왜 참견 하냐는 말을 한다면 할 말이 없다. 하지만 이것은 아주 중요한 것이다. 프로젝트를 어떻게 구현하는가에 대한 가장 초보적 단계이자 타 모듈에 대한 입장을 청취할 수 있는 기회이면서, 그리고 데이터가 어떻게 내 모듈로 들어와서 어디로 가고 나중에 어떻게 되는지를 알 수 있기 때문이다. 이런 데이터의 흐름을 파악한 상태에서 TO-BE를 설계한다면 자연스럽게 BPR이 되는 것이고, 프로젝트를 구현하는데 있어서 타 모듈 PI가 왜 저런 주장을 하는지 이해를 할 수가 있다. 그럼으로 자연스럽게 커뮤니케이션에도 자기주장보다는 서로의 업무 개선을 위해 조언을 할 수 있는 밑바탕이 된다.

내가 예산관련 부분에 대하여 TO-BE 프로세스에 대하여 분석하고 정의한 것은 SAP CO 교육을 마치고 또한 CO 컨설턴트 자격을 취득한 이후에 하게 되었다. 이 때 나는 CO(관리회계) 모듈을 이용하여 예산관리를 하는 것보다 FM(예산관리) 모듈을 이용하는 대학회계와 병원회계를 모두 구현하는 것이 의료원에서 요구하는 방법에 적합하다는 결론을 내렸다. 이는 FM 모듈에서는 각각의 상태(STATUS)에 대한 예산집행 관리가 가능하지만 CO에서는 최종 FI(재무회계)에서 처리한 데이터만 받기 때문에 프로세스 차원에서의 예산관리가 힘들다는 결론을 내렸다. 그리고 이는 아마도 내가 대학회계에서 FM 모듈을 사용하였던 경험이 있었기 때문에 모듈간 비교를 통한 장단점을 비교하여 FM모듈을 예산관리 모듈로 선택할 수 있었다고 생각되어진다.

앞에 서술한 AS-IS 분석에서 설명했듯이 여기서 나는 L사의 팀장 및 컨설턴트와 마찰을 빚게 된다. 내가 예산관리를 CO 모듈을 사용하지 않고, FM 모듈을 이용하여 구현하겠다고 얘기하면서 TO-BE 설계를 하자, FM 모듈을 사용하겠다고 의료원측에서 처음부터 얘기를 하지 않았기 때문에 FM 모듈에 대하여 L사는 지원해 줄 수 없다는 선언을 나에게 하였다. 나는 황당하기도 하고 예전에 나에게 했던 얘기와 완전히 틀리기도하여 마음이 많이 상한 상태에서 L사의 팀장과 설전을 벌려야한 했다. 결국 의료원측의 ERP 팀장과 L사의 컨설턴트의 의견을 조율한 결과 CO 모듈에서는 의료원에서 요구하는 방향으로 예산관리를 할 수 없으므로 FM 모듈을 이용하는 것이 좋을 것 같다는 결론이나 L사의 팀장이 추후 FM 모듈에 대한 컨설턴트 지원을 약속하여 나는 TO-BE 설계를 완성할 수 있었다.

출처 : http://blog.empas.com/kimppa0/12023139

출처:AS-IS / TO-BE 분석 (ERP Project)

꿈을 꾸다~!!

교착 상태 처리

개념

티스토리툴바