"자로 재기는 두번 하고 자르기는 한 번 하라"
라는 말이 있다. 어떤 행위를 하기전 실수하지 않도록 여러번 재보라는 것이다.
소프트웨어를 구현하기에 앞서 우리는 선행 조건을 수행해야 한다.
특정한 목적을 가지는 소프트웨어를 구현하기 위해서는
선행조건의 중요성을 알고, 소프트웨어의 종류에 따른 성격을 결정하고
발생하는 문제에 대해 알며, 고객이 원하는 요구사항을 구체적으로 알아야 한다.
그리고 선행조건은 생각보다 많은 시간소요를 필요로 한다.
선행조건의 중요성 : 소프트웨어를 구현하기 전 단계에서 모든 문제점을 잡아내야 한다.
마지막에 소프트웨어를 테스트하는 과정이 있기는 하지만 처음 목적과는 다른 엉뚱한 제품을 만들어냈거나 잘못된 방법으로 개발하는 것과 같은 문제점은 잡아낼 수 없다. 그렇기 때문에 구현 전에 모두잡아냄으로써 소요되는 비용을 줄이고 고객이 원하는 제대로된 프로그램을 만들 수 있는 것이다.
선행 조건이 현대적인 소프트웨어 프로젝트에 적용되는가? : 선행 조건의 가장 중요한 목표는 위험 절감이다. 가능한 한 초기에 위험요소를 제거해야 하며, 프로젝트마다 위험 절감을 위한 구체적인 접근 방법은 달라져야 한다.
불완전한 준비의 원인 : 자신의 작업을 수행할 정도의 지식을 가지고 있지 않다는것이 일반적인 원인이다. 이런 기술들은 프로젝트를 계획하고 강력한 비즈니스 케이스를 만들기 위해서 또한, 포괄적이고 정확한 요구사항을 개발하고 훌륭한 아키텍처를 만들기 위해서도 필요하다.
요구사항 개발에 한창 열올릴때, 상사가 지금 당장 코딩을 요구한다면,
당신은 네가지의 결정을 내릴 수 있다.
첫째, 이렇게 비효율적인 순서로 작업을 할 수 없다고 단호하게 거절하는 것이다.
물론, 상사와의 관계가 남다르다거나 그렇게 말해도 될 정도로 은행 잔고가 두둑하다면 말이다.
(이 멘트에서 웃어버렸다ㅋ;;; 돈이 많아야 하는건가 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ)
둘째, 코드를 작성하고 있는 것처럼 보이는 것이다.
이전에 만든 코드를 책상 한켠에 둔 다음, 하고 있던 요구사항과 아키텍처를 개발한다.
(이것은 공감해서였다. 학생인 나에게 실제로 교수들이나 선배들은 코딩을 요구한다. 난 아직 계획도 덜짰는데.. ;;)
셋째, 상사가 프로젝트에 대해 이해하도록 알려주는것이다.
견식 있는 관리자가 늘어날 수 있다는 점에서 훌륭한 접근방법이다.
마지막으로, 다른 직장을 구하는 것이다.
-_- 흐음. 우리 나라에서는 달리 선택권이 없는 듯하다.
첫째 방법으로 말하면 넷째 방법으로 돌아올 듯 싶다 ㅋㅋㅋㅋ
구현전에 선행조건을 수행하기 위한 필수적인 논의
-논리적 설득
-비유적 설득
-자료적 근거
-상사의 준비 테스트
라는 말이 있다. 어떤 행위를 하기전 실수하지 않도록 여러번 재보라는 것이다.
소프트웨어를 구현하기에 앞서 우리는 선행 조건을 수행해야 한다.
특정한 목적을 가지는 소프트웨어를 구현하기 위해서는
선행조건의 중요성을 알고, 소프트웨어의 종류에 따른 성격을 결정하고
발생하는 문제에 대해 알며, 고객이 원하는 요구사항을 구체적으로 알아야 한다.
그리고 선행조건은 생각보다 많은 시간소요를 필요로 한다.
선행조건의 중요성 : 소프트웨어를 구현하기 전 단계에서 모든 문제점을 잡아내야 한다.
마지막에 소프트웨어를 테스트하는 과정이 있기는 하지만 처음 목적과는 다른 엉뚱한 제품을 만들어냈거나 잘못된 방법으로 개발하는 것과 같은 문제점은 잡아낼 수 없다. 그렇기 때문에 구현 전에 모두잡아냄으로써 소요되는 비용을 줄이고 고객이 원하는 제대로된 프로그램을 만들 수 있는 것이다.
선행 조건이 현대적인 소프트웨어 프로젝트에 적용되는가? : 선행 조건의 가장 중요한 목표는 위험 절감이다. 가능한 한 초기에 위험요소를 제거해야 하며, 프로젝트마다 위험 절감을 위한 구체적인 접근 방법은 달라져야 한다.
불완전한 준비의 원인 : 자신의 작업을 수행할 정도의 지식을 가지고 있지 않다는것이 일반적인 원인이다. 이런 기술들은 프로젝트를 계획하고 강력한 비즈니스 케이스를 만들기 위해서 또한, 포괄적이고 정확한 요구사항을 개발하고 훌륭한 아키텍처를 만들기 위해서도 필요하다.
요구사항 개발에 한창 열올릴때, 상사가 지금 당장 코딩을 요구한다면,
당신은 네가지의 결정을 내릴 수 있다.
첫째, 이렇게 비효율적인 순서로 작업을 할 수 없다고 단호하게 거절하는 것이다.
물론, 상사와의 관계가 남다르다거나 그렇게 말해도 될 정도로 은행 잔고가 두둑하다면 말이다.
(이 멘트에서 웃어버렸다ㅋ;;; 돈이 많아야 하는건가 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ)
둘째, 코드를 작성하고 있는 것처럼 보이는 것이다.
이전에 만든 코드를 책상 한켠에 둔 다음, 하고 있던 요구사항과 아키텍처를 개발한다.
(이것은 공감해서였다. 학생인 나에게 실제로 교수들이나 선배들은 코딩을 요구한다. 난 아직 계획도 덜짰는데.. ;;)
셋째, 상사가 프로젝트에 대해 이해하도록 알려주는것이다.
견식 있는 관리자가 늘어날 수 있다는 점에서 훌륭한 접근방법이다.
마지막으로, 다른 직장을 구하는 것이다.
-_- 흐음. 우리 나라에서는 달리 선택권이 없는 듯하다.
첫째 방법으로 말하면 넷째 방법으로 돌아올 듯 싶다 ㅋㅋㅋㅋ
구현전에 선행조건을 수행하기 위한 필수적인 논의
-논리적 설득
-비유적 설득
-자료적 근거
-상사의 준비 테스트
