'소프트웨어공학'에 해당되는 글 29건

  1. 2009/12/17 초록별사랑 유지보수를 위한 설계
  2. 2009/12/05 초록별사랑 성공적인 소프트웨어 개발을 위해 반드시 알아야할 57가지 법칙
  3. 2009/09/19 초록별사랑 애자일 방법론이 추구하는 가치 4가지
  4. 2009/09/19 초록별사랑 짝 프로그래밍의 시너지
  5. 2009/09/19 초록별사랑 그래디 부치가 설명한 RUP의 가장 중요한 6가지 본질
  6. 2009/07/08 초록별사랑 프로젝트 비용산정 기법
  7. 2009/07/07 초록별사랑 WBS (Work Breakdown Structure)
  8. 2009/07/07 초록별사랑 프로젝트 계획서
  9. 2009/07/07 초록별사랑 IEEE-Std-830명세 표준
  10. 2009/07/07 초록별사랑 CMMI 1.2의 22개 프로세스 영역

유지보수를 위한 설계

소프트웨어공학 2009/12/17 13:39 초록별사랑
소프트웨어 컨플릭트2.0에 보면 전산학과 교수님에게 보내는 내용으로 유지보수를 위한 설계의 내용이 나온다.
소프트웨어를 개발하면 항상 생각하면서 바빠서 또는 귀찮아서 지키지 못하는 경우들이 더러 있다.
이후로는 반드시 지켜서 생산적인 유지보수가 가능하도록 하여야 겠다.

유지보수를 위한 설계
  1. 단일지점제어설계
    • 모듈화
    • 자료 추상화
    • 객체 지향
    • 테이블과 파일 위주 설계
  1. 방어적 설계
    • 예외처리
    • 자가점검
    • 여유있는 엔지니어링
    • 결함 허용



최근 소프트웨어 공학에 관련된 책들을 읽는데 주먹구구식으로 프로젝트를 해왔던 방식에 문제가 많음을 느끼고있지만 무턱대고 적용하기 보다는 좀더 스터디한후에 우리회사의 실정에 맞도록 적용해야 할듯하다..
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/12/17 13:39 2009/12/17 13:39
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/456

  1. 비전을 고유하라.
  2. 팀이 게임에 몰입하게 하라.
  3. 여러개의 릴리스 기술 계획을 만든다.
  4. 무책임한 비난을 하지 않는다.
  5. 정찰을 한다.
  6. 비율에 신경쓴다.
  7. 기능팀(Feature Team)을 사용한다.
  8. 프로젝트 관리자를 사용한다.
  9. 권위 자체가 되어야지, 권위적인 인물이 되어서는 안된다.
  10. 혼자라고? 경쟁자 없는 시장은 없다.
  11. 막상막하? 기능 대결에서 벗어난다.
  12. 뒤쳐저 있는가? 새로운 기능으로 더 자주 출시하라.
  13. 앞서고 있는가? 절대로 뒤는 돌아보지 말아라.
  14. 숨쉬고 살자
  15. 고객을 흥분시킨다.
  16. 최적점(Sweet point)를 찾는다.
  17. 영업이 아니라 관계구축이 중요하다.
  18. 신속하게 사이클을 순환한다.
  19. 위대함을 추구한다.
  20. 주제를 확실하게 얘기한다.
  21. 종속성을 최소화 한다.
  22. 신의 뜻을 거슬리지 말라
  23. 무의미한 플랫폼 지원을 줄인다.
  24. 디자인 시점에서 시간을 디자인한다.
  25. 지시를 받아들이지 않는다.
  26. 이제 놀러가자.
  27. 의사처럼 행동하라
  28. 기능, 리소스, 시간이알는 삼각형을 기억할것
  29. 모르는 것은 그대로 인정한다.
  30. 어둡게 만들지 않는다.
  31. 다른 사람의 상황을 안다.
  32. 빌드를 한다면 결국에는 출시할 것이다.
  33. 알려진 상태를 유지한다.
  34. ZD(Zero defect)마일스톤을 사용한다.
  35. 모든 사람이 ZD마일스톤에 도달하기 전에는 아무도 도달한 것이 아니다.
  36. 모든 마일스톤은 비난없는 사후검토를 받아들야한다.
  37. 마일스톤의 정의와 정신을 고수한다.
  38. 규범을 만든다.
  39. 마일스톤을 지나치게 세분화하지 않는다.
  40. 모든 작은 마일스톤은 자신만의 의미를 갖는다.
  41. 자연스러운 마일스톤을 모색한다.
  42. 뒤쳐지되, 낙오되지는 말라
  43. 나쁜 날짜끼리 바꾸지 않는다.
  44. 일정지연 후에는, 어떻게 해서라도 다음 마일스톤을 지킨다.
  45. 일정 지연을 잘 활용한다.
  46. 숲을 본다.
  47. 세상은 변한다. 여러분도 변해야 한다.
  48. 최소한 하나 정도의 신성모독 행위를 한다.
  49. 베타에서 변경해서는 안된다.
  50. 베타는 나선식 개발을 위한것
  51. 냉정하게 구원순위를 정한다.
  52. 묽은 젤리는한번에 흔들지 않는다.
  53. 멋진 이야기를 가지고 경쟁한다.
  54. 멋진 이미지는 만든다.
  55. 완벽한 보스가 되도록 한다.
  56. 보스는 여러분의 가장 중요한 고객이다.
  57. 상납세를 지불하고 알파몫을 찾는다.
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/12/05 19:04 2009/12/05 19:04
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/448

  1. 프로세스와 툴보다 개인과 상호반응을 추구한다.
  2. 문서보다 실제로 동작하는 소프트웨어를 전달한다.
  3. 계약 협상보다 고객과의 협업 추구한다.
  4. 고정된 계획을 따르기 보다는 변화에 민감하게 반응한다.
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/09/19 12:10 2009/09/19 12:10
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/438

짝 프로그래밍의 시너지

소프트웨어공학 2009/09/19 12:03 초록별사랑
  1. 짝 입력
  2. 짝 협의
  3. 짝 용기
  4. 짝 리뷰
  5. 짝 디버깅
  6. 짝 배움
  7. 짝 믿음
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/09/19 12:03 2009/09/19 12:03
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/437

  1. 반복적(iterative)이며 점진적(incremental)으로 개발하라.
  2. 비주얼하게 모델링하라
  3. 요구사항을 관리하라
  4. 변화를 관리하라
  5. 끊임없이 품질을 보증하라
  6. 컴포넌트 기반의 아키텍처를 사용하라


부치가 이야기한 두번째로 중요한 원리들
  1. 단지 필요한 것만 개발하라
  2. 가치 있는 결과물에 집중하라. 그것을 달성하는 방법에 치우치지 마라
  3. 문서 작업을 최소화하라
  4. 유연하라
  5. 실수로부터 배워라
  6. 정기적으로 위험이 있는지를 재고하라
  7. 프로젝트의 진도를 확인할 수 있는 객관적이고 추정 가능한 기준을 세워라
  8. 인간의 노력이 집중되고 지루하고 에러가 발생할 여지가 많은 부분은 자동화 하라
  9. 작고 힘이 있는 팀을 사용하라
  10. 계획을 세워라
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/09/19 11:47 2009/09/19 11:47
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/436

프로젝트 비용산정 기법

소프트웨어공학 2009/07/08 20:37 초록별사랑
  1. 델파이 기법
  2. LOC(Line of Code)
  3. COCOMO(Constructive Cost Model)
  4. 기능점수(Function Point)
기능식별
  • 내부논리파일(ILF : Internal Logical Files)
  • 외부연계파일(EIF : External Interface Files)
  • 외부입력(EI : External Input)
  • 외부출력(EO : External Output)
  • 외부조회(EQ : External in Query)
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/07/08 20:37 2009/07/08 20:37
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/419

WBS (Work Breakdown Structure)

소프트웨어공학 2009/07/07 22:09 초록별사랑
소프트웨어 프로젝트
프로젝트 착수
프로젝트 팀 구성
인원산정, 역할 할당
프로젝트 제안
도메인/유사서비스 분석
프로젝트 범위 결정
생명주기 및 일정 활동 계획
상위수준 WBS작성
프로젝트 제안서 작성
프로젝트 제아서 작성 검토
협의 및 계약
요구사항 분석
UseCase분석
UserCase 다이어그램 작성
UserCase Spec작성
객체분석
Sequence다이어그램 작성
프로토타입 작성
ERD작성
요구사항 명세서 작성
요구사항 명세서 검토
프로젝트 계획
상세수준 WBS작성
세부 일정 계획 수립
위험 계획 수립
프로젝트 관리 계획 수립
프로젝트 계획서 검토
테스트 계획서 작성
테스트 케이스 작성
프로젝트 계획서
설계
기본설계
시스템 구조와 데이터 규명
사용자 인터페이스 정의
기본 설계 사양서 작성
기본 설계 사양서 검토
상세설계
아키텍처 정의서
DB설계서
ERD작성(논리/물리)
클래스 다이어그램 작성
상세 설계 사양서 작성
상세 설계 사양서 검토
구현
소스코드 작성
단위 테스트
통합 테스트
시스템 테스트
테스트
테스트 시나리오 작성
테스트 케이스 설계
테스트 기법 산정
테스트 수정
테스트 결과 보고서 작성
테스트 결과 보고서 검토
프로젝트 완료
프로젝트 완료보고서 작성
프로젝트 완료보고서 검토
프로젝트 최종 발표
산출물 제출
종료회의(사후 검토)

크리에이티브 커먼즈 라이센스
Creative Commons License
2009/07/07 22:09 2009/07/07 22:09
트랙백은 하나, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/418

프로젝트 계획서

소프트웨어공학 2009/07/07 22:03 초록별사랑
1. 개요
 1.1 프로젝트 개요
 1.2 프로젝트 산출물
 1.3 계획서의 변경기록
 1.4 참고문헌
 1.5 정의와 약어
2. 프로젝트 조직
 2.1 프로세스 모델
 2.2 조직 구조
 2.3 조직의 범위와 인터페이스
 2.4 프로젝트 책임
3. 관리적 프로세스
 3.1 관리적 목적과 우선순위
 3.2 가정과 제한
 3.3 위험 관리
 3.4 통제 메커니즘
 3.5 인력

크리에이티브 커먼즈 라이센스
Creative Commons License
2009/07/07 22:03 2009/07/07 22:03
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/417

IEEE-Std-830명세 표준

소프트웨어공학 2009/07/07 22:00 초록별사랑
1. 소개
 1.1 SRS의 목차
 1.2 산출물의 범위
 1.3 정의, 두문자어, 약어
 1.4 참조문서
 1.5 SRS개요
2. 일반적인 기술 사항
 2.1 제품의 관점
 2.2 제품의 기능
 2.3 사용자 특성
 2.4 제약 사항
 2.5 가정 및 의존성
3. 상세한 요구사항
 3.1 기능적 요구사항
  3.1.1 기능적 요구사항
   3.1.1.1 개요
   3.1.1.2 입력물
   3.1.1.3 프로세싱
   3.1.1.4 산출물
   3.1.1.5 수행 요구사항
   3.1.1.6 디자인 제약 사항
   3.1.1.7 속성
   3.1.1.8 기타 요구사항
 3.2 외부적인 인터페이스 요구사항
  3.2.1 사용자 인터페이스
  3.2.2 하드웨어 인터페이스
  3.2.3 소프트웨어 인터페이스
  3.2.4 커뮤니케이션 인터페이스
부록
인덱스
크리에이티브 커먼즈 라이센스
Creative Commons License
2009/07/07 22:00 2009/07/07 22:00
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/416

 성숙도 수준
초점
프로세스 영역

 5  최적화 지속적인 프로세스 개선
 조직 혁신 및 적용관리
원인 분석 및 해결
OID
CAR
 4  정량적 관리
정량적인 프로세스 관리
 조직 프로세스 성과 관리
정량적 프로젝트 관리
OPP
QPM
 3  정의 조직 차원의 프로세스 구축
요구사항 개발
기술 솔루션
제품 통합
검증
확인
조직 프로세스 중점관리
조직 프로세스 정의+제품 및 프로세스 통합 개발
위험 관리
의사결정 분석 및 해결
RD
TS
PI
VER
VAL
OPF
OPD+IPPD
OT
IPM+IPPD
RSKM
DAR
 2  관리 프로젝트 관리
 요구사항 관리
프로젝트 계획 수립
프로젝트 모니터링 및 통제
공급업체 계약 관리
측정 및 분석
프로세스 및 제품 품질보증
형상관리
REQM
PP
PMC
SAM
MA
PPQA
CM
 1  초기      


크리에이티브 커먼즈 라이센스
Creative Commons License
2009/07/07 21:56 2009/07/07 21:56
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://haroc.haroc.net/tc/rss/response/415