건희아범의 지속가능한 삽질

문) 요구공학
답)
  1. 요구사항 검증을 통한 SW위기의 해결 요구공학
    가. 요구공학(Requirement Engineering) 의 정의
      - 초기 개발 요구사항 및 이후 상세요구사항들이 설계와 구현 단계에서 제대로
        지켜지고 있는지 검증하는 기법
    나. 요구사항의 특성
      1) 정확성 : 명확화된 요구사항이 실제 구현시 필요한 것인지 알수 있게 정확해야함
      2) 명확성 : 여러가지가 아니라 단 한가지로 해석되어야 함, 프로토타이핑으로 해결가능
      3) 완전성 : 시스템 구현에 필요한 모든 것이 표현되어야 함
      4) 일관성 : 요구사항들 간의 충돌이 없어야 함
      5) 수정용이성 : 구조와 스타일에 일관성유지, 요구사항 변경 용이
      6) 추적성 : 요구사항들간 유기적 연결, 산출물이 각 단계와 mapping 되어야 함.
                  RTM(Requirements Traceability Matrix) - 순방향, 역방향 검색
  2. 요구공학 구성 및 절차
    가. 요구공학 구성
      - 도구 : 요구사항 요청, 영향분석, 변경수행, 배포 등의 자동화도구
      - 프로세스 : 요구사항 관리를 수행하기 위한 절차와 방법
      - 방법론 : 요구사항 추출,분석,정의,검증,관리의 각단계룰 정의한 정형화된 방법
    나. 요구공학 절차
      1) 추출 : 문제를 이해하고, 요구사항 추출
      2) 분석 : 추출된 요구사항을 분석하여 요구사항을 구조화하고, 각종 대안을 결정
      3) 정의 : 시스템이 무엇을 해야하는지를 기술, 분석된 요구사항을 명세화(명확성,
           완전성,검증가능성,일관성,수정용이성, 추적가능성,개발후 이용성)
      4) 검증 : 문제를 기술하고, 상이부분의 일치여부를 확인, (Review,Work-Through,Inspection)
      5) 관리 : 요구사항에 대한 최종결정 및 Baseline관리, 변경통제 및 확인기능
  3. 정형명세 기법과 비정형 명세기법 비교
    구분 |            정형명세      |        비정형명세
    -------------------------------------------------------
    기법 |      수학적기반/모델기반 |  상태/기능/객체중심
    종류 |      Larch,OBJ/Z,UDM,CSP |  FISM/Decision Table/SADT
    장점 | 시스템요구특성정확,명세간결,명세/구현의 일치성| 명세작성/이해용이, 의사전달방법 다양성
    단점 | 수학적이해, 이해관계자 부담| 불충분한 명세 가능, 모호성

------- 추가분--------
 **. 요구사항 분석의 문제점과 해결방안
    가. 요구사항 검증을 위한 V&V : 프로젝트 SDLC개발단계의 Verification(검증)과
        Test 단계의 Validation을 통한 검증 필요
    나. 요구사항 해결책에 대한 비문서화된 경험을 형식화한 Repository 관리, 업무 전문가
        양성계획 수립 및 프로젝트 참여로 제품품질 향상 기여."끝"

    *. 프레임워크 개요도 - 구성요소에 해당내용이 설명되어 1교시에서는 제외
        (추출/분석/정의/검증/관리 해당 구조도 첨부)

    *. 요구사항 분석이 어려운 이유
      1) 문제영역에 대한 명확한 이해부족 : 개발자의 도메인 이해부족으로 요구사항
         이 불명확하게 작성
      2) 참여자 사이의 이해문제 : 참여자들의 Role에 따라 서로다른 관점으로
         표현하고 분석함으로써, 같은 내용에 대해 충돌 또는 불명확성 발생
      3) 의사소통에 대한 문제 : 공동작업 중 충분한 의견교환이 없어 문제 발생
      4) 요구사항의변경 : 사용자의 변경요구, 습득된 지식 및 환경변화에 따른 변경

    * 요구사항 명세시 고려사항
      1) 기술적 내용과 제약조건은 언급하지 않는다. (외부 Entity 관점)
      2) 명세화 이전 자료에 기반두어 작성한다. - RFP, 제안서, 상위 요구사항
      3) 비기능적 요구사항도 모두 포함 작성
      4) 사용자별 중요도 및 난이도 고려하여 우선순위 정의.
         - 중요도 및 난이도는 어떤 기준으로 산정하는가?? 고민해볼것.
         - 중요도 난이도 구한 후에는 우선순위는 무엇으로 정하는가. - 중요도/난이도 차트?

    * 요구사항 명세서의 이해관계자별 목적
      1) 사용자측면 : 요구사항정의, 정의된 요구사항의 적용 및 추적성, 의사소통,
            프로젝트 품질, 납기기준 (특징:친숙한 용어사용베이스라인 제공, 연결)
      2) 개발자측면 : 사용자와의 의사소통 창구역할 수행(JRP), 프로젝트 목적에
            맞는 설계,개발 진행 (특징:정형화된 형식, 정량화,측정가능한 가치제공)
      3) PM측면 : 프로젝트 관리기준(일정, 비용, 품질), 프로젝트 범위에 대한 기준
           및 수용가능성 (특징:요구사항추적매트릭스-요구사항 관리)

  *. 요구사항 유형 분류를 위한 FURPS+ 모델
     가. FURPS : 기능성,편의성,신뢰성,성능, 지원성
     나. "+" : 구현성, 연계성, 운영성, 합법성. "끝".

쌍용차 해직노동자가 또 자살을 했단다.
벌써 14명째라던가..
또 자살이라는 의미는 우리가 트는 저녁 뉴스에는 거의 나오지 않는다는 얘기렸다.

우리의 MBN(MB님)은 G20세대가 나타났다며,
세계에 어깨를 나란히 하는 대한민국, 국격이 상승되었다는데,
이렇게 좋은나라에서 왜 이렇게 못살겠다고 죽는지 모르겠다.

무상급식관련해서도 말이 많다. 솔직히 무상급식은 아니다.
세상에 공짜가 어디에 있나? 다 우리가 내는 세금이다.
하지만 적어도 내가 내는 세금은 애들 먹이는 급식에 쓰여졌으면 좋겠다.
그 밥을 먹고, 그 아이들이 열심히 미래에 대한 꿈을 키웠으면 좋겠다.
(하지만, 한반도 대운하에 그 돈이 쓰여지길 원치는 않는다.
한반도 대운하에 미래에 대한 꿈이 있는 건 MBN 뿐인것 같으니까..)

회사에서 퇴직을 당해도 적어도 죽음을 생각하지는 않을 정도의 돈을 받는것,
어린이들이 학교에서 돈내지 않고 밥먹을 수 있는것,
아이가 많이 아프다고 해도, 치료비로 집 날리지 않고 이혼도 하지 않는 것.
이런거 하면 나라 망하는걸까..

내가 너무 많은 것을 기대하고 있나...
하긴 그래서 이렇게 지속가능한 삽질을 위해 열공중인지도 모른다.