본문 바로가기

분류 전체보기

 (142)
4. 프로젝트 프로세스에 관하여(+근황) 대충 1년정도 시간을 잡고 하는 프로젝트인지라, 어디서부터 시작해야 할 지 감을 잡는게 쉽지 않은 것 같다. 현재 고민해본결과는 Khanban 기반 프로젝트 관리 시작 -> 시장분석 -> Use Case 정리 -> UML작성 -> Architecture 설계 -> TDD기반 개발 순으로 진행하는 것이다. 물론 각 단계단계마다 공부할 것도 많고 거쳐야 할 것도 많다(몇몇 부분은 공부를 끝낸것도 있고 진행중인것도 있음) 일단 첫번째 단계인 프로젝트 관리는 아마 가장 빨리 끝날 것이다. 시장분석단계가 매우 중요한데... 이것은 일단 공부를 위해 생각해놓은 책이 2개정도 있다. 1) Where to play, 2) Testing business idea. 사실 개인의 관심은 사업을 한다기 보다는 취미로 개발하는..
3. Requirement & UML & Architecture & 경과 1) 요구사항에 대한 생각 기존에 내가 사용하는 시스템이 아닌, 무에서 유를 창조하는 새로운 시스템의 개발같은 경우 정확한 요구사항이란게 존재한다기 보다는, 다소 애매모호한 정도로 어떤걸 하고싶다 정도로 요구사항이 표현되는 것 같는 생각이 들었다. 아마 개인이 개발을 시도한다면 비슷한 상황일 것 같다. 이것을 보다 명확하게 하기 위해서는, 시장조사와 기존에 존재하는 내가 생각하는 것과 비슷한 다른 시스템들을 분석함으로서 요구사항을 다소 명확하게 하는 것이 필요하다고 생각하였다. 이 과정은 도메인에 대한 추가적인 이해가 필요하므로 그에 대한 과정이 병행되어야 할 것 같다. 2) UML의 도입 OO에 대한 생각이 조금 더 명확해 진것 같다. OO는 안정적이고 변화에 대응할 수 있는 시스템을 위해서 필수적인 ..
2. Project Management & Development Plan 1) 개요 프로젝트 관리와 개발을 어떤 방식으로 진행할지 알아보다가, 개발은 TDD기반으로, 프로젝트 관리는 Kanban Board를 활용하여 관리하는것으로 계획하였음 2)TDD의 도입 개인프로젝트에서는 대개 요구사항이 명확하게 시작하는 경우보다는 두루뭉실하게 이런 프로그램을 만들고 싶다는 정도로만 끝나는 경우가 많다. 일반적인 Water Fall 모델을 적용할 경우 개발 한 사이클의 주기가 길어지고, 실제로 결과물을 확인하는 성취를 확인하기가 힘들어 동기부여가 하락하게된다. 또한, 문서화로인한 Overhead는 개인흥미 수준으로 프로젝트를 수행하는 개인이 프로젝트를 지루하게 느낄 수 있는 요인이 된다. 궁극적으로 프로젝트를 책임감있게 끝내지 못할 가능성이 높아진다. TDD를 통해 개발의 사이클을 줄이고..
1. 개인 프로젝트 시작 *Target Personal Software Engineering Study & Contemplating Future of Personal Program Development Framework *Main Project Name Automatic Market Analysis System for Personal Investor in Korea *Process Model 1) Specification 2) Development 3) Validation 4) Evolution *Detail Process 1) Requirement Engineering 2) Software Architecting 3) Software Design 4) Software Development 5) Test and Integrati..
5. System modeling System modeling이란 시스템에대한 추상화된 모델을 개발하는 프로세스를 말한다. 이러한 모델은 Mathmetical model(Formal model) 또는 Grapical Model(UML) 등으로 표현될 수 잇으며, 시스템을 보는 관점에 따라 다르게 표현되기도 한다. Requirement Engineering 단계에서 세부 요구사항을 도출하기 위해 모델이 개발된다. 1) 요구사항 단계에서 사용되는 이미 존재하는 시스템에 대한 모델 2) 요구사항 단계에서 사용되는 새로운 시스템에 대한 모델 시스템을 바라보는 관점에 따라 다른 모델을 개발할 수 있다. 1) External perspective : 시스템의 context 또는 environment에 대한 모델 2) Interaction presp..
4. Requirement engineering Requirement of system이란, 시스템이 제공해야하는 service와 그것의 operation의 제약사항을 의미한다. 이러한 요구사항을 찾고, 분석하고, 문서화하고 검토하는 프로세스를 Requirement engineering이라고 한다. 이러한 프로세스는 보통 Software Engineer의 첫번째 단계로 여겨진다. 여기서는 Agile방식이 아닌 클래식한 Plan-driven방식에서의 Requirement engineering을 다룬다. 이러한 요구사항은, Description level에 따라 두가지 유형으로 나눌 수 있고 각기다른 이해관계자를 위한 서술이다. 1) User requirement : diagram과 natural language 들로 구성된 추상화된 기술 2) Syste..
3. Agile software development Plan-driven 방식의 소프트웨어 개발 프로세스는 개발과정도중 요구사항의 변화나 요구사항의 문제에 대해서 빠르게 대처하지 못하는 문제점이 있다. 빠르게 변화하는 환경속에서, 빠르게 요구사항에 발맞추어 개발을 하기 위해 Agile 개발 프로세스가 도입되었다. Agile방식의 특징은 다음과 같다. 1) Interleaved specification, design, implementation, minimized fomal documentation 2) Development in series of increment 3) Extensive tool support for development process 3.1 Agile methods 대규모의 시스템이 아닌 빠르게 요구사항이 변화하는 중소규모의 시스템 개발..
2. Software processes 앞서 Introduction에서 보았듯이, software engineering은 software processes로 볼 수 있으며, 과정은 다음과 같다. 1) Specification -> Development -> Validation -> Evolution 2.1 Software process models software process model은 간단하게 모델화된 프로세스 표현이며, 다음과 같이 분류될 수 있다. 1) The waterfall model 2) Incremental development model 3) Integration and configuration 2.1.1 The waterfall model 하나의 phase에서 다음 phase로 단계적으로 cascading되는 특성 때문에,..

티스토리툴바