Computer Science/Software Engineering23 [Software Engineering] Software Architecture Software Architecture소프트웨어의 골격이 되는 기본 구조이자, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체이다. 아키텍처 설계는 그러한 서브 시스템을 식별하고 서브 시스템 제어 및 통신을 위한 구조적 프레임워크를 확립하는 초기 설계 프로세스이다. - 소프트웨어 아키텍쳐가 중요한 이유1. 초기 디자인 결정: 소프트웨어 아키텍처는 시스템의 남은 개발, 배포 및 유지보수와 관련하여 시스템을 지배하는 가장 초기의 설계 과정을 나타낸다.2. 이해관계자와의 소통: 소프트웨어 아키텍처는 시스템 이해관계자가 상호 이해, 협상, 합의 및 소통의 기초로 사용할 수 있는 시스템의 공통된 추상화를 나타낸다.3. 시스템의 이전 가능한 추상화: 유사한 품질 속성 및 function.. 2025. 1. 31. [Software Engineering] UML(Unified Modeling Language) : Behavioral Diagram Use Case DiagramUse case 모델은 시스템의 요구사항을 capture하기 위해 사용되는 모델이다. Use case는 시스템이 무엇을 하도록 의도되었는지 사용자 및 기타 이해 관계자에게 전달하는 수단이다. - Actors- Use Cases- Uses Connector- Generalizationis-a 관계이다. - Include RelationshipWithdraw가 Card Identification이라는 use case를 포함하고 있어, Withdraw가 실행되면, Card Identification도 실행된다. - Extend RelationshipGet Approval은 Modify Order 실행 시, 경우에 따라 실행될 수도 있고 안될 수도 있다는 의미이다.State Mach.. 2025. 1. 29. [Software Engineering] UML(Unified Modeling Language) : Structural Diagram UML- 분산 및 동시 시스템을 위한 시각적 모델링 언어이며 실제 세계의 아이디어를 그래픽으로 표현한다.- 모델이란 불필요한 세부 사항을 걸러내어 복잡한 문제나 구조의 본질을 표현하는 추상화이다. 이를 통하여 문제를 더 쉽게 이해할 수 있도록 한다. Three Means for Modeling- Notation: 모델에서 사용되는 기호/언어- Process: 기호/언어가 사용되는 방식- Tool: 기호/언어를 사용하게 해주는 도구 UML Diagram Classification- Structure Diagrams: 모델링 되는 시스템에 '무엇이 반드시 있어야' 하는지 강조- Behavior Diagrams: 모델링 되는 시스템에 '무엇이 반드시 일어나야' 하는지 강조- Interaction Diagram.. 2025. 1. 27. [Software Engineering] System Models System ModelModel은 Requirement engineering 프로세스에서 시스템의 상세 요구사항을 이끌어내기 위해서 사용(Analysis model)되고, Design 프로세스에서는 시스템을 구현할 엔지니어들에게 시스템을 설명하기 위해서 사용(Design model)되며, 구현 후에는 시스템의 구조와 동작을 문서화하기 위해서 사용된다. 기존 시스템이나 개발될 시스템 둘 다 모델을 개발할 수 있다. System Modelling PerspectiveExternal perspective: 외부에서 바라보는 소프트웨어의 모델Structual perspective: 내부에서 바라보는 소프트웨어의 구조적 모델Behavioural perspective: 내부에서 바라보는 소프트웨어의 동적 모델 Co.. 2025. 1. 21. [Software Engineering] Requirement Engineering Requirements EngineeringSystem requirements 문서를 생성하고 유지보수 하기 위한 과정으로 세 개의 sub-processes로 진행된다.- Elicitation: 도출- Validation: 검증- Management: 관리Requirements Elicitation애플리케이션 도메인, 시스템이 무엇을 서비스 해야하는지, 시스템의 성능, 하드웨어의 제약사항 등을 찾아내는 과정이다.- 이를 수행하기 위해 다양한 이해 관계자와 소통해야 한다.- 이해 관계자/의뢰인은 개발자와 domain knowledge가 다르다는 것을 유념해야한다.- 목적, 컴퓨터 솔류선을 요구하는 문제에 대한 기초적인 이해, 프로젝트의 맥락과 환경, 고객이 바라는 시스템의 영향력, 고객이 가진 동기와 기대.. 2025. 1. 12. [Software Engineering] Software Requirements What are requirements?- 시스템에 의해 제공되는 서비스와 운영 제약 사항을 기술한 것- Requirements engineering이란 그런 서비스와 제약사항을 찾아내고, 분석하고, 문서화하는 것이다. Classifications of Requirements- Functional Requirements: 시스템이 제공해야 하는 서비스와 특정 입력에 대해 시스템이 반응하는 방식, 그리고 특정 상황에 시스템이 동작해야 하는 방식을 기술한 것. - Non-functional Requirements: 시스템이 제공하는 서비스나 기능에 대한 제약사항. 비기능적 요구사항은 시간적 제약, 개발 프로세스에 대한 제약과 표준에 의해 지켜야 하는 제약 등을 포함. 개별적인 시스템 특징이나 서비스보다는 전.. 2025. 1. 9. [Software Engineering] Feasibility Study Feasibility Study프로젝트를 시작하기 앞서 프로젝트의 타당성을 조사하는 것. The Decision Maker's ViewpointBenefits: 이익이 무엇인가? 정량화 가능한가?Costs: 스태프, 시간, 장비 비용이 얼마나 드는가? Risks: 위험요소는 무엇이고 최소화될 수 있는가?Client: 누굴 위한 프로젝트인가?Scope: 어느 범위까지 맡아야하는가?Technical Feasibility: 기술적으로 실현 가능한가?Alternatives: 이 프로젝트가 아니더라도 대체품이 존재하는가? Why are Feasibility Studies Diffcult- 이익을 정량화 하기 어렵다.- 접근 방식은 일반적으로 잘 정의되지 않으며, 필요한 자원과 일정은 대략적이다.- 조직 변화가 필.. 2025. 1. 6. [Software Engineering] Software Processes Basic Process Steps1. Feasibility study2. Requirements engineering3. Design4. Implementation5. Verification and validation6. Operation, maintenance, and evolution Feasibility Study프로젝트를 시작할 지 결정하기 위한 타당성 조사 단계.1. 이윤이 발생하는가?2. 담당할 범위는 어디까지인가?3. 기술적으로 타당한가?4. 비용이 얼마나 들어가는가? Requirements Analysis and Definition프로젝트가 제공하는 서비스, 제약사항, 목표를 설정.1. 요구사항 도출/분석2. 요구사항 구체/명세화3. 요구사항 검증(고객이 원하는 것을 잘 명세하였는지) D.. 2025. 1. 3. 이전 1 2 다음
