동호다찌

1. 소프트웨어 아키텍처의 설계 소프트웨어 아키텍처는 소프트웨어의 골격이 되는 기본 구조이자 소프트웨어 구성 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체 ex) 건축 설계와 비슷하다. 의뢰자의 요구사항에 맞추어 건물의 용도와 형태를 정하고, 땅을 어떻게 다질지, 골조는 어떻게 세울 것인지와 같이 대략적인 것을 정하는 과정 소프트웨어 개발 시 적용되는 원칙과 지침 이해관계자들의 의사소통 도구로 활용됨 좋은 품질을 유지하며 사용자의 비기능적 요구사항으로 나타난 제약을 반역하고,기능적 요구사항을 구현하는 방법을 찾는 해결 과정 기능적 요구사항 : 시스템이 갖춰야 할 필수적인 기능에 대한 요구 항목들 비기능적 요구사항 : 그 외의 품질이나 제약사항에 관한 것 애플리케이션의 분할 방법과 분할된 모듈에 ..

1. Use Case Diagram(유스케이스 다이어그램) 유스케이스 다이어그램은 개발될 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템이 개발된 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것이다. 외부 요소와 시스템 간의 상호작용 사용자의 요구사항을 분석하기 위한 도구 시스템의 범위를 파악 2.Class Diagram(클래스 다이어그램) 클래스 다이어그램은 구조 다이어그램으로 클래스 내부 구성요소 및 클래스 간의 관계를 도식화하여 시스템의 특정 모듈이나 일부 및 전체를 구조화 합니다. 개발 하기 전, 클래스 다이어그램을 그리게 되면 시스템 내 클래스 간의 의존성 파악과 팀원들 간 의사소통이 편리합니다. 3. Sequence Diagram(순서 다이어그램) 여러 대상 간..

1. UML(Unified Modeling Language) 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어이다. UML을 사용 시 6개의 구조 다이어그램, 7개의 행위 다이어그램 작성 가능 UML의 구성 요소 : 사물, 관계, 다이어그램 2. 사물 (Things) 사물은 모델을 구성하는 가장 중요한 기본요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상을 말한다. 사물에는 구조사물, 행동사물, 그룹사물, 주해사물이 있다. 3. 관계 (Relationships) 사물과 사물 사이의 연관성을 표현하는 것으로 연관관계, 집합관계, 포함관계, 일반화관계, 의존관계, 실체화관계 등이 있다. ..

1. 요구사항 분석을 위한 CASE (자동화 도구) 요구사항 분석을 위한 자동화 도구는 요구사항을 자동으로 분석하고, 명세서를 기술하도록 개발된 도구 표준화와 보고를 통한 문서화 품질 개선 데이터베이스가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정 교차 참조도와 보고서를 통한 결함, 생략, 불일치 등의 발견 용이성 변경이 주는 영향 추적의 용이성 명세에 대한 유지보수 비용의 축소 ✅ 종류 SADT (Structured Analysis and Design Technique) SREM (Software Requirements Engineering Methodology) PSL/PSA TAGS(Technology for Automated Generation of System) 2. HIPO HI..

1. 요구사항 분석의 개요 요구사항 분석은 소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동을 의미한다. 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정 요구를 정확하게 파악하여 목표를 정하고 어떤방식으로 해결할 지 결정 소프트웨어 설계 단계에서 필요한 자료가되므로 요구사항을 정확하고 일관성있게 분석하여 문서화 2. 구조적 분석 기법 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법 도형 중심의 분석용 도구와 분석 절차를 이용하여 문서화 하향식 방법을 사용하여 시스템 세분화 및 중복을 배제 요구사항을 논리적으로 표현하여 시스템을 일관성 있게 이해 분석 도구 DFD : Data Flow Diagram (자료 흐름도) DD : ..

1. 요구사항의 개념 및 특징 요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타낸다. 요구사항은 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다. 요구사항은 개발하려는 소프트웨 어의 전반적인 내용을 확인할 수 있게 하므로 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 준다. 요구사항이 제대로 정의되어야만 이를 토대로 이후 과정의 목표와 계획을 수립할 수 있다. 2. 요구사항의 유형 요구사항은 일반적으로 기술하는 내용에 따라 기능 요구사항(Functional requirements)과 비 기능 요구사항(Non-functional requirements)으로 구분한다. 기술 관점과 대상..

1. XP(eXtreme Programming) XP(eXtreme Programming)는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상하는 방법이다. XP는 짧고 반복적인 개발 주기 단순한 설계 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다. 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높인다. 릴리즈 테스트마다 고객을 직접 참여시킴으로써 요구한 기능이 제 대로 작동하는지 고객이 직접 확인할 수 있다. 비교적 소규모 인원의 개발 프로젝트에 효과적이다. XP의 5가지 핵심 가치 : 의사소통(Communication) , 단순성 (Simplicity), 용기(Courage),..

1. 스크럼의 개요 스크럼이란 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어이다. 스크럼은 팀원 스스로가 스크럼 팀을 구성(Self-Organization)해야 하며, 개발작업에 관한 모든 것을 스스로 해결(Cross-Functional)할 수 있어야한다. 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성된다. ✅ 제품 책임자 (PO; Product Owner) 이해관계자들 중 개발될 제품에 대한 이해도가 높고 요구사항을 책임지고 의사 결정할 사람으로 선정히는데 주로 개발 의뢰자나 사용자가 담당한다. 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체다. 요구사항이 담긴 백로그(Backlog) 를 작성하고 백로그에 대한 우선순위를 지정한다. 백로그란 제품 개발에 ..

1. 소프트웨어 개발 방법론의 개요 소프트웨어 개발 방법론은 소프트웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화 한 것이다. 목적은 소프트웨어 생산성과 품질 향상이다. 종류에는 구조적, 정보공학, 객체지향, 컴포넌트 기반, 애자일, 제품 계열 방법론이 있다. 2. 구조적 방법론 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Process)중심의 방법론 1960년대까지 가장 많이 적용되던 방식 쉬운 이해 및 검증이 가능한 프로그램 코드를 생성하는 것이 목적 복잡한 문제를 다루기 위해 분할과 정복 원리를 적용 구조, 흐름, 간결, 간단 이 구조적 개발방법의 특징이다. ..

1. 소프트웨어 생명주기(Software Life Cycle) 소프트웨어 생명 주기(수명 주기)는 개발과 유지보수 등에 필요한 작업들을 체계적으로 정리한 개발 방법론의 바탕으로서, 개발을 위한 정의, 운용, 유지보수 등의 과정을 단계별로 나눈것입니다. 소프트웨어 개발 단계와 각 단계별 활동, 결과에 대한 산출물로 표현합니다. 개발자는 문제의 유형, 개발 방법에 따라 특정한 생명 주기 모형을 선택하여 사용하거나, 개별적인 새로운 모형을 사용할 수 있습니다. 대표적인 생명 주기 모형 폭포수 모형 프로토 타입 모형 나선형 모형 애자일 모형 2. 폭포수 모형(Waterfall Model) 폭포수 모델의 특징은 이전 단계로 돌아갈 수 없습니다. 이러한 전제하에 각 단계에서 확실하게 진행하여 결과를 검토하고 승인하..