본문 바로가기

백엔드 개발자 기록 일람/정보처리기사 준비 기록

(42)
UML(Unified Modeling Language) -2- 클래스 다이어그램 관계 표현 ▼ Class Diagram 시스템을 구성하는 객체간의 관계를 추상화한 모델을 논리적 구조로 표현한 것이다. 객체지향 개발에서는 공통으로 사용되며, 분석, 설계, 구현단계 전반에 지속해서 사용된다. 단방향 연관관계(일반화) : 한쪽은 알지만 반대쪽은 상대방의 존재를 모름 실체화 관계(실체화) : 첵임집합 인터페이스와 실제로 실현한 클레스들의 사이 의존관계 (의존): 연관 관계와 같지만 메소드를 사용할 때와 같이 매우 짧은 시간만 유지. 양방향 연관관계(연관) : 양쪽 클래스 객체들이 서로의 존재를 인식 일반화 관계(일반화) : 객체지향에서 상속관계를 표현하며, 한 클래스가 다른 클래스를 포함하는 상위개념일 떄 사용 집합관계(집합) : 클레스 사이 전체나 부분이 같은 관계 포합..
UML(Unified Modeling Language) -1- ▼개념 모델링 요구사항을 이해하기 쉽도록 실 세계의 상황을 단순화하여 개념적으로 표혀ㅑㄴ한 것을 모델이라고 하고, 이렇게 표현된 모델을 생성해 나가는 과정을 개념 모델링이라고 한다. 모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명하므로 소프트웨어 요구사항 분석의 핵심이라 할 수 있다. 개발 대상 도메인의 엔티티들과 그들의 관계및 종속성을 반영한다. 또한 요구사항 별로 관점이 다르므로 개념 모델도 다양하게 표현되어야 하는데, 대부분 UML을 사용한다. 종류 : Use Case Diagram, Data Flow Model, State Model, Goal-Based Modfel, User Interactions, Object Model, Data Model 엔터티(Entity) : 엔터티..
요구사항 개발 -2- 기능적 요구사항 · 시스템이 실제로 어떻게 움직이는지에 관점ㅇ믈 둔 요구사항 비기능적 요구사항 · 시스템 구축에 대한 성능, 보안, 품질, 안정성 등으로 실제 수행에 보조적이 요구사항. 요구사항 명세 · 시스템 정의, 시스템요구사항, 소프트웨어 요구사항을 작성한다. · 체계적으로 검토,평가, 승인 될ㅇ 수 있게 문서로 작성한다. · 기능 요구사항은 빠지는 부분없이 명확히 기술한다. · 설계과정의오류사항을 찾을 수 있게 해어야 한다. · 비기능 요구사항은 필요한 것만 명확히 기술한다. · 개발자가 효과적으로 설계하고, 사용자가 쉽게 이해할 수 있도록 작성한다. 요구사항 명세 속성 · 정확성: 요구사항은언제나 정확해야한다. · 명확성: 단 한가지로만 해설되어야 한다. · 완전성 : 모든 것이 표현 가능해야 ..
요구사항 개발 - 1 - 요구공학 · 소프트웨어 개발 시 사용자 요구가 정확히 반영된 시스템 개발을 위하여 사용자의 요구를 추출, 분석, 명세, 검증, 관리하는 구조화된 활동 집합니다. · 요구사항을 정의하고 문서로 만들고, 관리하는 프로세스를 의미한다. · 효과적인 의사소통을 통하여 공통이해를 설정하며, 불필요한 비용 절감, 요구사항 변경 추적이 가능해진다. · 분석 결과의 문서화를 통홰 향후 유지보수에 유용하게 사용할 수 있다. · 자료 흐름도, 자료사전 등이 효과적으로 이용될 수 있으며, 더 구체적인 명세를 위해 소단위 명세서가 활용될 수 있다. · 소프트웨어 개발시 이해관계자 사이의 원활한 의사소통 수단을 제공하며, 이로인해 요구사항 누락 방지, 상호이해오류 등의 제거로 경제성을 제공한다. · 요구사항 변경 이력 관리를 ..
현황 시스템 분석 현황 시스템 분석의 정의와 목적 · 현행 시스템이 어떤 하위 시스템으로 구성되어 있는지 파악하는 절차를 의미한다. · 현행 시스템의 제공 기능과 타 시스템과의 정보 교환 분석을 파악한다. · 현행 시스템 기술 요소와 소프트웨어, 하드웨어를 파악한다. · 개발 시스템의 개발 범위를 확인하고 이행 방향설을 설정하기위해 시행한다. 현행 시스템 파악 절차 · 1단계 : 시스템 구성 파악 - 시스템 기능 파악 - 시스템 인터페이스 현황 파악 · 2단계 : 아키택처 파악 - 소프트웨어 구성파악 · 3단계 : 시스템 하드웨어 현황 파악 - 네트워크 구성 파악 시스템 아키택처 · 시스템 내의 상위 시스템과 하위 시스템들이 어떠한 관계로 상호작용하는지 각각의 동작 원리와 구성을 표현한 것이다. · 단위 업무 시스템별로 ..
SCRUM SCRUM의 개념과 특징 요구사항 변경에 신속하게 대처할 수 있도록 반복적이고 점진적인 소규모 팀권 간 활발한 소통과 협동심이 필요한 팀 중심의 소프트웨어 개발 방법론이다. 신속하게 반복적으로 실제 작동하는 소프트웨어를 제공하고 기능 개선점에 우선순위를 부여, 개발 주기 동안 작용된 기능이나 개선점의 리스트 실제동작 가능한 결과를 제공한다. 개발자들의 팀의 구성은 팀원 스스로 팀을 구성해야하며, 개발작업에 관한 모든 것. 팀 구성과 구성원의 역활, 일정결과물 및 그 규칙을 스스로 정하고 해결해야한다. SCRUM 기본원리 기능협업을 기준으로 배치된 팀은 스프린트 단위로 소프트웨어를 개발한다. 스프린트는 고정된 30일의 반복이며, 스프린트시 행하는 작업은 고정된다. 정해진 시간은 철저히 지켜져야 하며, 요구..
애자일 개발 방법론과 XP 애자일(Agile) 개발 방법론 특정 방법론이 아닌 소프트웨어를 빠르고 낭비 없이 제작하기 위해 고객과의 협업에 초점을 둔 것으로 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항을 수용할 수 있다. 그렇기에 절차와 도구 보다 고객과의 소통 그리고 피드백을 중요시하며, 소트프웨어가 잘 실행되는 가에 가치를 두며, 배포시차를 최소화 할 수 있다. 애자일(Agile) 선언문 프로세스나 도구보다 개인과의 소통이 더 중요하다. 완벽한 문서보다 실행되는 소프트웨어가 중요하다. 계약 협상보다 고객과의 협업이 중요하다. 계획을 따르는 것보다 변경에 대한 응답이 더 중요하다. XP(eXtreme Programming) 1999년 Kent Beck이 제안하였으며, 개발 단계 중 요구사항이 시시각각 변동이 심한 경..
소프트웨어 설계 방법론 ★소프트웨어 생명주기(Software Life Cycle) 소프트웨어의 생명주기란 소프트웨어 제품의 개념 형성에서 시작하여 운용/ 유지보수에 이르기까지 변화의 모든 과정이다. 타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 - > 운용 -> 유지보수가 그 과정이다. ★폭포수 모형(WaterfallModel) 선형 순차적 모델이라고도 하며 Boehm이 제시한 고전적 생명주기 모형으로 소프트웨어 개발 과정의 각 단계가 순차적으로 진행되는 모형이다. 나성형 모델(Spiral Model) Boehm이 제시한 반복적인 작업을 수행하는 점증적 생명주기 모형이다. 점증적 모형, 집중적 모형이라고도 하며, 소프트웨어 개발중 발생할 수 있는 위험을 관리하며, 나선을 따라 돌고돌며 각 개..