• 독서

    [Object Oriented S/E] Chapter 4 - Software Requirements Elicitation

    [Object Oriented S/E] Chapter 4 - Software Requirements Elicitation

    # 범위 80page ~ 103page # 내용 ## 4.1 WHAT IS REQUIREMENTS ELICITATION? 실제 세계의 프로젝트에서는 예산이나 시간의 제한이 존재한다. 그렇기 때문에 요구사항의 subset만이 충족되어 진다. 소프트웨어 요구사항은 시스템이 제공해야 하는 기능이다. 성공적인 소프트웨어 프로젝트는 예산을 넘기지 않고 계획된대로 시스템을 완성시키는 것이다. 이해관계자들의 성향(경영가, 개발자, 기술자 ...)에 따라서 우선순위로 두는 것이 달라지기 때문에 요구사항의 우선순위를 두는것이 어렵다. 제약조건은 소프트웨어 솔루션 공간에 대한 제약이다. 제약은 설계와 구현대안들을 감소시킨다. 극단적인 예로, 제약조건이 없다면 선택범위가 매우 광범위 하지만 제약족건이 존재하면 솔루션 공간이..

    [Object Oriented S/E] Chapter 3 - System Engineering(2)

    [Object Oriented S/E] Chapter 3 - System Engineering(2)

    # 범위 58page ~ 65page # 내용 ## 3.3 SYSTEM REQUIREMENTS DEFINITION System requirements은 비지니스 니즈를 파악하며, 초기 단계에 설정되고 개념을 확장해나간다. 비즈니스 니즈를 파악하는 것은 정보수집활동을 하는 것이다. 정보 수집 방법에는 고객발표, 현재 사업 운영에대한 연구, 유저 설문, 사용자 인터뷰, 문헌조사가 있다. 시스템 요구사항은 어떠한 예산, 납품 기일, 정치적 제약, 비용 효율성과 같은 여러 이유로 요구사항이 충족되지 못할 수 있다. ## 3.4 SYSTEM ARCHITECTURAL DESIGN 시스템 아키텍처를 디자인 하는 것은 모든 공학의 능통한 전문가를 고용해서 하는 것이 좋지만, 이런 사람들은 고용하기 어렵다(너부 비싸다)..

    [Object Oriented S/E] Chapter 3 - System Engineering(1)

    [Object Oriented S/E] Chapter 3 - System Engineering(1)

    # 범위 53page ~ 58page # 내용 ## 3.0 SYSTEM ENGINEERING System engineering은 하드웨어, 소프트웨어, 인적요인들과 관련된 시스템을 개발하기 위한 종합적인 접근법이다. 임베디드 시스템(embedded system)은 하드웨어,소프트웨어 인적요인들로 구성되고, 이것들은 각각이 상호작용하면서 시스템의 목적(mission)을 완료시킨다. 이러한 종합적인 요인들을 고려해야하기 때문에 System engineering(시스템 공학)적인 접근법이 필요하다 software-only system에서도 여러 비지니스 프로세스와 데이터베이스와 같은 요인들, 여러 기능들이 있기 때문에 System engineering(시스템 공학)적인 접근법이 필요하다. ## 3.1 WHAT..

    [Object Oriented S/E] Chapter 2 - Software Process and Methodology(1)

    [Object Oriented S/E] Chapter 2 - Software Process and Methodology(1)

    # 범위 16page ~ 30page 2.1 CHALLENGES OF SYSTEM DEVELOPMENT (시스템 개발의 과제) 2.2 SOFTWARE PROCESS 2.3 MERITS AND PROBLEMS OF THE WATERFALL PROCESS ( 폭포수 과정의 장단점) 2.4 SOFTWARE DEVELOPMENT IS A WICKED PROBLEM 2.5 SOFTWARE PROCESS MODELS # 내용 ## 2.1 CHALLENGES OF SYSTEM DEVELOPMENT 실험실 또는 학부에서 소프트웨어를 개발한것과 현실세계(현업)에서 개발하는 것은 상당히 큰 차이를 갖고 있다. 그렇기 때문에 왜 소프트웨어 프로세스와 방법론이 필요한지 알 수 있다. 현실에서는, 1년에서 몇년까지의 긴 개발 ..

    [Object Oriented S/E] Chapter 1 - Introduction

    [Object Oriented S/E] Chapter 1 - Introduction

    # 시작하기 전 4학년 1학기에 듣는 소프트웨어공학이라는 과목에서 교재로 사용하는 책이다. 일단 번역본을 구해보려 했는데 번역본이 없다. 영어 해석해가면서 읽는게 꽤 오래 걸리기 때문에, 나중에 돌려보기도 힘들거 같아서 한번볼때 정리를 잘해놔야 겠다 # 범위 0 ~ 15page Chapter 1 Introduction # 내용 소프트웨어의 개발 라이프 사이클을 소개한다. 이 사이클에는 제품개발, SQA(Software Quality Assurance), 소프트웨어 프로젝트 관리(비용 일정 등등), 시장 출시의 사이클을 가진다. water-fall(폭포수) 방식의 개발방법은 각각의 단계가 완료되고 나서 그 다음단계로 넘어가게 되는 과정이다. 상당히 계획적인 개발방법이라고 할 수 있다. 소프트웨어 디자인(S..

    [객체지향의 사실과 오해#1] 소프트웨어의 세계에서 객체를 바라보는 새로운 시각

    [객체지향의 사실과 오해#1] 소프트웨어의 세계에서 객체를 바라보는 새로운 시각

    # 읽은 목차 01 협력하는 객체들의 공동체 02 이상한 나라의 객체 # 시작하며 객체지향에 흥미를 가지게 되면서, 객체지향을 꽤 공부해봤지만 정작 내가 배웠던 원리 원칙들이 실제 개발에서는 전혀 보이지 않았다. 내가 객체지향을 잘 못 이해하고 있는 것일까? 아니면 개발단계에서 적용되는 객체지향적인 사고는 어떤 것일까 궁금해서 읽기 시작했다. 실제세계의 객체와 소프트웨어 세계에서의 객체의 개념은 사뭇 달라보인다. "02 이상한 나라의 객체"챕터까지 읽은 지금 내용들을 잊지 않기 위해서 조금 정리해보려고 한다. # 01 협력하는 객체들의 공동체 객체지향의 목표는 실세계를 모방하는 것이 아니다. 오히려 새로운 세계를 창조하는 것이다. 시작하며에서 적었던거와 같이, 책에서는 실제 애플리케이션 개발단계에서 객체..