분류 전체보기
-
UML Use Case Diagram - Scenario Based Analysis에 속하는 Diagram 이다. - Actor : 시스템과 소통하는 내부에 있는 모든 요소 Negotiating Requirements(요구사항 협상) - 협상 결과가 stakeholder 모두에게 ‘win-win’한 결과가 나와야 한다. Stakeholder는 만족스러운 결과물을 얻고, developers는 deadline에 맞춰 생산하는 것이 ‘win-win’ 이다. 이런 결과를 만드는 건 Handshaking 이 거의 유일하다. - Developers가 요구사항을 분석하고 솔루션을 제시한다. 이 때 묘사하는 것은 효과와, Developer가 솔루션을 구상하며 가진 생각이다. - Customer는 솔루션을 분석하고, 놓..
소프트웨어 공학 이론 정리 -7장- <요구사항 분석 2부>UML Use Case Diagram - Scenario Based Analysis에 속하는 Diagram 이다. - Actor : 시스템과 소통하는 내부에 있는 모든 요소 Negotiating Requirements(요구사항 협상) - 협상 결과가 stakeholder 모두에게 ‘win-win’한 결과가 나와야 한다. Stakeholder는 만족스러운 결과물을 얻고, developers는 deadline에 맞춰 생산하는 것이 ‘win-win’ 이다. 이런 결과를 만드는 건 Handshaking 이 거의 유일하다. - Developers가 요구사항을 분석하고 솔루션을 제시한다. 이 때 묘사하는 것은 효과와, Developer가 솔루션을 구상하며 가진 생각이다. - Customer는 솔루션을 분석하고, 놓..
2020.12.09 -
Establishing the Groundwork 작업을 수행하기 전 확립해야 할 사전 작업에 대한 논의 - Stakeholder를 확인한다. [유저, 스폰서, 개발자] - 각 Stakeholder가 다양한 관점을 갖는다는 것을 인지할 수 있어야 한다. - Stakeholder간 협업을 할 수 있어야 한다. - 첫 번째 질의 프로젝트의 요구사항을 제시하는 사람과 그 뒤에서 영향을 주고 있는 사람은 누구인가? 솔루션의 사용자는 누군가? 성공적으로 솔루션을 만들었을 때, 어떤 금전적인 이익이 생기는가? [각 stakeholder 별로 원하는 이익이 다를 수 있다.] 솔루션[소프트웨어]를 만들 때, 필요한 도메인 기술이나 추가적인 역량이 필요하진 않은가? Collaborative Requirements Gat..
소프트웨어 공학 이론 정리 -6장- <요구사항 분석>Establishing the Groundwork 작업을 수행하기 전 확립해야 할 사전 작업에 대한 논의 - Stakeholder를 확인한다. [유저, 스폰서, 개발자] - 각 Stakeholder가 다양한 관점을 갖는다는 것을 인지할 수 있어야 한다. - Stakeholder간 협업을 할 수 있어야 한다. - 첫 번째 질의 프로젝트의 요구사항을 제시하는 사람과 그 뒤에서 영향을 주고 있는 사람은 누구인가? 솔루션의 사용자는 누군가? 성공적으로 솔루션을 만들었을 때, 어떤 금전적인 이익이 생기는가? [각 stakeholder 별로 원하는 이익이 다를 수 있다.] 솔루션[소프트웨어]를 만들 때, 필요한 도메인 기술이나 추가적인 역량이 필요하진 않은가? Collaborative Requirements Gat..
2020.12.09 -
Agility Principles - Customer의 만족은 Customer가 요구하는 가치를 제공하는 소프트웨어를 최대한 빠르게 전달시킬 수 있을 때 충족된다. - 요구사항은 반드시 바뀌며, 바뀌는 요구사항을 잘 받아들일 수 있어야 한다. - 소프트웨어의 증진은 매주[Not Monthly] Stakeholder에게 내용을 전달해 피드백을 확인받으며 가치를 입증 받아야 한다. - Stakeholder는 서로 face-to-face 하여 communication을 하게 되며, 이들 모두 같이 agile team에 소속된다. - 팀으로 이뤄지는 process는 기술적인 전문성과, 좋은 디자인, 단순화라는 가치를 얻게 해준다. - Customer의 요구에 맞는 소프트웨어를 제작하는 것이 가장 중요한 목적이다..
소프트웨어 공학 이론 정리 -5장- <Perescriptive Process 마무리와 요구사항 분석의 시작>Agility Principles - Customer의 만족은 Customer가 요구하는 가치를 제공하는 소프트웨어를 최대한 빠르게 전달시킬 수 있을 때 충족된다. - 요구사항은 반드시 바뀌며, 바뀌는 요구사항을 잘 받아들일 수 있어야 한다. - 소프트웨어의 증진은 매주[Not Monthly] Stakeholder에게 내용을 전달해 피드백을 확인받으며 가치를 입증 받아야 한다. - Stakeholder는 서로 face-to-face 하여 communication을 하게 되며, 이들 모두 같이 agile team에 소속된다. - 팀으로 이뤄지는 process는 기술적인 전문성과, 좋은 디자인, 단순화라는 가치를 얻게 해준다. - Customer의 요구에 맞는 소프트웨어를 제작하는 것이 가장 중요한 목적이다..
2020.12.09 -
Prescriptive Process Models : 예부터 많이 사용된 단계별로 쪼개어 진행하는 소프트웨어 엔지니어링 모델 : 2가지 메인 질문 - 구조나 순서에 집중해 구성하는 모델, 소프트웨어를 기획에 변화가 많이 생길 때 적합한가? - 기존 프로세스 모델을 부정하고 새로운 구조모델을 사용한다면, 소프트웨어를 개발하는 사람들 간의 조화와 결집을 이룰 수 있는가? Waterfall Process Model - 장점 프로세스에 대한 이해가 쉽고 계획하기 쉽다. 복잡하지 않은 작은 프로젝트에 유용하다. 분석과 테스트가 직관적으로 이해하기 쉽다. - 단점 변화에 적합하지 않다. 테스팅 과정이 프로세스 내 너무 늦게 존재한다. Customer의 평가가 마지막이 되어서야 확인 가능하다. Prototyping ..
소프트웨어 공학 이론 정리 -4장- <Prescriptive Process Models>Prescriptive Process Models : 예부터 많이 사용된 단계별로 쪼개어 진행하는 소프트웨어 엔지니어링 모델 : 2가지 메인 질문 - 구조나 순서에 집중해 구성하는 모델, 소프트웨어를 기획에 변화가 많이 생길 때 적합한가? - 기존 프로세스 모델을 부정하고 새로운 구조모델을 사용한다면, 소프트웨어를 개발하는 사람들 간의 조화와 결집을 이룰 수 있는가? Waterfall Process Model - 장점 프로세스에 대한 이해가 쉽고 계획하기 쉽다. 복잡하지 않은 작은 프로젝트에 유용하다. 분석과 테스트가 직관적으로 이해하기 쉽다. - 단점 변화에 적합하지 않다. 테스팅 과정이 프로세스 내 너무 늦게 존재한다. Customer의 평가가 마지막이 되어서야 확인 가능하다. Prototyping ..
2020.12.09 -
Essence of Software Engineering practice - Polya Suggests Understand the problem Plan a Solution Carry out the plan Examine result for accuracy Understand the Problem - 4가지 확인 요소 문제를 갖고 있는 사람이 누구인가? 즉, 이 문제에 대해 이해관계가 얽힌 사람이 누군가? 알려지지 않은게 무엇인가? 문제를 해결하기 위해 알아야만 하는 데이터와 함수, 기능이 무엇이 있는가? 큰 문제를 작은 문제로 나눌 수 있는가? (Compartmentalize) 문제를 풀기 위해 이해하기 쉽도록 문제를 작은 문제 단위로 해결할 수 있는가? 문제에 대해 시각화 할 수 있는가? 분석 모델을..
소프트웨어 공학 이론 정리 -3강- <소프트웨어 엔지니어링 2부>Essence of Software Engineering practice - Polya Suggests Understand the problem Plan a Solution Carry out the plan Examine result for accuracy Understand the Problem - 4가지 확인 요소 문제를 갖고 있는 사람이 누구인가? 즉, 이 문제에 대해 이해관계가 얽힌 사람이 누군가? 알려지지 않은게 무엇인가? 문제를 해결하기 위해 알아야만 하는 데이터와 함수, 기능이 무엇이 있는가? 큰 문제를 작은 문제로 나눌 수 있는가? (Compartmentalize) 문제를 풀기 위해 이해하기 쉽도록 문제를 작은 문제 단위로 해결할 수 있는가? 문제에 대해 시각화 할 수 있는가? 분석 모델을..
2020.12.08 -
레이어 (McGraw-Hill Education) - Tools – 소프트웨어 개발에 도움되는 도구 - Methods – 제작론에 이어 구체적인 방법을 제시 - Process – 제작론을 결정 - A Quality Focus Process Framework Activities - Communication - Planning => Product : Proposal Proposal : 목적과 기간, 타겟, 이익 등… 상업적 토의가 이뤄짐 - Modeling=설계 => Product : Design 설계서 Analysis of Requirement (요구사항 분석) : User, Developer, Sponsor 세 부류 모두의 요구사항을 분석한다. => 성능과 고객의 만족도, 스폰서의 소요비용을 모두 비교 ..
소프트웨어 공학 이론 정리 -2장- <소프트웨어 엔지니어링>레이어 (McGraw-Hill Education) - Tools – 소프트웨어 개발에 도움되는 도구 - Methods – 제작론에 이어 구체적인 방법을 제시 - Process – 제작론을 결정 - A Quality Focus Process Framework Activities - Communication - Planning => Product : Proposal Proposal : 목적과 기간, 타겟, 이익 등… 상업적 토의가 이뤄짐 - Modeling=설계 => Product : Design 설계서 Analysis of Requirement (요구사항 분석) : User, Developer, Sponsor 세 부류 모두의 요구사항을 분석한다. => 성능과 고객의 만족도, 스폰서의 소요비용을 모두 비교 ..
2020.12.08