일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 일본
- Sekai Entertainment
- 시스템관리
- 코라쿠엔
- 라면
- 리눅스
- 원탭바이
- Shimajirou
- 영단어
- 자동차
- TOY
- 동경 모터쇼
- 신쥬쿠
- 스테이크
- 칸칸
- 사이타마
- youtuber
- 米沢、팽이
- 여름
- 점심
- 돼지갈비
- paypay
- one tab buy
- fish
- しまじろう
- 돈까스
- 전철
- 명령어
- 시마지로
- 토익
- Today
- Total
IT Japan
요구정의와 요건정의의 차이를 생각한다. 본문
왜 시스템 개발이 실패하는 것일까 ...
사양 변경이 많아서 ...
말했다 말하지 않은 문제에서 피하고 싶은 ...
시스템 움직여 봐도 전혀 사용할 수없는 ...
사실. .
사업 운용을 운영 수준에 배포하지 않는 상태로,
시스템 개발을 해 버리는 곳에 원인이 있습니다.
입력 화면과 출력을 결정해도 ...
그것을 사용하여 어떻게 일상 업무를 해내지?
운영 수준까지 규명한 만들어 포함을하지 않고 전문가이기 때문에 전문이라서. . . 컴퓨터 전문가에 업무 운영 방식까지 던져 버리는 것이 문제입니다.
요구 정의 및 요구 사항 정의의 차이점
비즈니스
============
사업 운영 운영
사용자 인터페이스
============
요구 정의
· "~하고 싶다"고 이용자 측의 희망, 사업에 무엇이 필요한지 등을 기재 한 것
시스템
============
응용 프로그램
패키지
데이터베이스 / 통신 / ...
· IT 기술
============
데이터베이스 / 통신 / ...
OS
하드웨어
============
요건 정의
· [~가 필요]시스템 사양서, 시스템이 무엇을해야하는지 등을 기재 한 것
요구 정의 및 요구 사항 정의의 차이를 생각한다.
어떤 회사든지 컴퓨터 시스템을 도입하고 있습니다.
검증 된 패키지 소프트웨어의 도입라면 문제가 없지만, 자신의 시스템을 개발하면 실패가 발생합니다.
특히 경험이 적은 SE가 담당했거나 무리한 요구를 한 경우에 실패 할 가능성이 높아집니다.
그 원인은 무엇일까요?
그래서 중요한 것은 시스템화의 [요구]를 제대로 SE에 전달하는 것입니다.
SE는 최종 사용자의 요구를 제대로 캐치하지않으면... .
요구를 출발점으로하는 시스템 개발을 성공시킬 수 없습니다.
시스템 개발은 사용자의 요구를 제대로 잡고 기술자가 개발을 위해 필요한 요구 사항 정의를 작성하는 것이 중요합니다.
개발은 요구를 [어떤 문서에서는 어떻게 정리]일까요?
요구 정의 및 요구 사항 정의의 관련은 어디에 있을까요?
● 요구 정의
[~을하고 싶다] 이용자의 희망
비즈니스에서 무엇이 필요한지를 기술한 것
사업 운용을 운영 수준 생각 그대로 실현
컴퓨터 시스템에 대한 요구
● 요구 사항 정의
[~가 필요] 시스템 사양서
시스템이 무엇을해야 하는지를 기술한 것
시스템의 기능과 DB · 통신 등의 이용 방법
요구정의가 변경되면 요건정의의 변경이 필요합니다.
사업 방침이 변경되면 운영이 바뀝니다.
오퍼레이션이 바뀌는 것은 화면이나 장표 등의
인터페이스의 변경이 필요합니다.
따라서 시스템 개발을 할 때. . .
구체적인 작업 수준에서 작업의 「구조」를 잡아 않은 경우
[요구 정의]가 추상적이 됩니다.
업무의 운용 구조가 추상적인 상태그래로라면 .
담당 SE의 그 업무 경험과 능력, 특기 · 서툼으로 작성하는 [요건정의]가 달라집니다.
여기가 문제군요.
시스템 성공의 요건은 담당 SE의 경험과 능력에 맡겨. .
이것으로 좋은 것일까 요?
시스템 개발을 3 개의 세그먼트로 나누면 생각하기 쉽습니다.
비즈니스
시스템
· IT 기술
시스템 개발의 현장에서는이 세 가지 수준을 함께 논의하기 쉽습니다.
이것은 완전히 다른 능력입니다. 모두에 정통한 사람은 없습니다.
[요구 · 요구 사항]을 추적 할 수있는 구조가 필요
비즈니스의 운용 방침이 바뀌었다. .
시스템의 어디를 수정해야합니까?
시스템에 문제가 나왔다. .
· 그 문제는 비즈니스의 어디에 영향이 있을까?
비즈니스 환경은 변화하고 있습니다.
시스템의 개발 환경도 변화하고 있습니다.
지금 최선이라고 생각되는 시스템 개발을 할 수 있었다고해도,
그대로 계속 사용할 수 없습니다.
항상 개선해 나갈 필요가 있습니다.
그 때. . .
요구와 요건을 추적하는 구조가 없으면
프로그램 소스 목록을 쫓는 것입니다.
엄청난 노력이 소요됩니다.
그리고 성공률은 현저히 낮아집니다.
개발 문서에는 2 개 필요합니다.
사업 구조를 운영 수준에서 보여주는것
시스템 개발을 수행 SE가 이용하는 것
모두 갖추는 것이 앞으로의 개발에 필요합니다.
요구 정의
(이용자가 요구하는 시스템의 기능)
비즈니스의 [요구]
비지니스의 기본설계
비즈니스의 상세 설계
(비즈니스 오퍼레이션)
요건 정의
(개발되는 시스템의 기능 사양)
시스템 개발의 설계 사양
시스템의 기본설계서
시스템의 상세 설계서
소프트웨어
비즈니스의 요구에 따라 변화하기 쉬운 소프트웨어 요구 사항을 추적관리해나가는 환경을 구축
문장에서 양방향으로 추적 할 수있는 환경을 구축
정책 결정
개발 범위 및 절차
사례 연구 · 개발 사례의 의견 일치
시스템의 품질을 잘 해 나가는 데에도 도움이됩니다.
'IT > 인프라' 카테고리의 다른 글
Redmine과Git의 이행 (0) | 2017.05.26 |
---|---|
Vagrant에 lxc를 사용한다. (0) | 2017.05.25 |
러시아의 천재 해커에 의한 [신입 엔지니어 서버이벌 가이드] (0) | 2017.05.25 |
CentOS7에 LAMP환경을 만들자 (0) | 2017.05.25 |
데이터센터 서버 철거 (0) | 2017.02.24 |