일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- Шуғ дар Корея
- 빅데이터
- Data Lake
- Мобиль замима
- Кор барои хориҷиён
- 계정삭제 요청
- korea
- စကားစမြည်ပြောခြင်း
- Кори нопурра дар Корея
- Hello World
- အယ်လ်ဘာ
- 비바버튼
- BigData
- အလုပ်
- Werwingtoepassing
- 스프링부트
- ကိုရီးယား
- Чои кор барои хоричиён
- မြန်မာ
- Коркабулкунӣ барои хориҷиён
- Kotlin
- Job
- java
- Кор дар Корея
- Ҷойҳо дар Корея
- Spring boot
- Чати тарҷумаи худкор
- နိုင်ငံခြားသား
- အလုပ်အကိုင်
- Mobiele toepassing
- Today
- Total
목록IT/소프트웨어 공학 (8)
VivaButton
아키텍트의 종류와 역할아키텍쳐를 설계하는 사람은 아키텍트(Architect)라고한다. 이 아키텍트는 아키텍쳐 설계 프로세스에서 정의한 각 아키텍쳐에 대해서 아키텍쳐를 설계하는 역할들이 정의된다. 계층 구조를 제외하면 아키텍쳐는 5가지로 분리된다..(http://bcho.tistory.com/667 참조) Business Architecture, Application Architecture, Solution Architecture, Data Architecture로 분리되며, 아키텍트 역시 이 5개 분야에 걸쳐서 총 5개의 역할로 정의된다. * Architecture Business Architecture System Architecture Application Architecture Technical A..
PoC({Proof of Concept) 프로세스는 검증할 주요 내용에 대한 목표설정, 프로토타이핑 또는 커스터마이징, 배포의 순서를 통해 개념을 증명을 증명한다. 1. 대상선정 : 검증할 중 내용에 대한 목표 및 기간 설정2. 요구사항 결정 : 인프라 영향도 체크 및 배포 전략 준비3. 설계 : 기업환경에 맞는 솔수션 분석 및 계획4. 구현 : 분석 설계된 내용 커스터마이징5. 배포 : 향후 발생할 수 있는 환경을 테스트하고 이를 통한 잠재적 문제점을 해결6. 테스트 : 고객의 요건에 적합한지 여부 확인 및 실제 프로젝트를 위한 프로세스 진행7. 본 프로젝트 진행
Trello란?애자일과 칸반(간판) 스타일의 작업관리를 할 수 있는 툴이다. 화이트 보드의 시스템을 디지털로 가져왔다고 보면 이해가 편하다.그냥 화이트보드처럼 포스트잇을 통한 관리용도로도 쓸 수 있지만, 이것저것 첨부도 할 수 있고, 댓글도 달 수 있는 등 상당히 리치하게도 쓸 수 있다. Trello의 구조 : 하이드보드에서 따온 3가지 구조로 되어있다.포스트잇과 같은 역할의 Card/ 그 포스트잇들을 한줄로 붙이는 List/화이트보드 개념의 Board Card : 트렐로에서 사용하는 가장 작은 단위. 카드는 간단하게는 포스트잇처럼 복잡하게는 빽빽하게 채운 다이어리 페이지 느낌으로 사용 할수도 있다. 이미지를 삽입할 수도 있고 긴 글도 작성 할 수 있고, 마크다운을 지원하므로, 굵게나 가늘게 등도 표현이..
1. 정의불완전한 요구사항 분석에 대한 해결책으로 간단한 시제품을 만들어 사용자의 요구를 수용해서 시스템을 보완해 나가는 방법 2. 진행단계 3. 장/단점1. 폭포수 모델보다 사용자 요구를 철저히 분석하게 되므로 실패율이 적다.2. 시스템의 기능이 사용자에게 보여짐으로 이해당사자간의 오해와 기능에 대한 정의가 명확해져 고품질의 시스템을 명세화 하는데 기초가 된다.3. 완제품에 대한 오해를 불러일으켜 너무 많은 변화를 유도할 수 있다.4. 시스템의 극한상황에 대한 평가가 어려워 시스템간의 교류 및 평가가 힘들다.
1. 개요Scrum 은 프로젝트 관리를 위한 상호, 점진적 개발방법론으로 애자일 소프트웨어 공학 중 하나이다. 소프트웨어 개발을 위하여 고안된 것이지만 일반적인 제품개발이나 유지보수 등에 활용이 가능하다 2. Scrum 구성의 원칙1) 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여2) 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공3) 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공4) 일일 15분 정도의 회의5) 항상 팀 단위로 사고6) 원활한 의사소통 3. 스크럼 팀 구성원이 추구하는 가지(Ground Rule)1)확약 : 약속한 것을 확실히 실현하는 것.2)전념 : 확약한 것의 실현에 전념하는 것3)정직 : 어떤 것이 자신에게 불리해도 숨기지 않는 ..
데일리 스크럼이란?스크럼 방법론에서 쓰이는 용어로, 날마다하는 짧은 회의를 뜻한다.* 매일 현재 상태를 업데이트하고 조율하는 것을 의미한다.* 다른 애자일 방법론인 XP에서는 스탠드업 미팅이라고 하는것도 있다. 스탠드업 미팅에서는 회의를 서서하는 것이 필수적이다. 데일리 스크럼의 일반적인 규칙과 필요성데일리 스크럼의 일반적인 규칙* 정해진 시간은 없다.(꼭 아침에만 해야 되는것은 아니다.) 단, 최대 15분 이내에 마친다.* 꼭 서서하지 않아도 된다.* 팀원들이 모두 돌아가면서 아래의 질문에 대답한다.* 질문 : - 지난 데일리 스크럼부터 지금까지 내가 완수한 것이 무엇인가?- 다음 데일리 스크럼까지 내가 하기로 한 것이 무엇인가- 현재 장애가 되고 있는것(이슈가 되는것)이 무엇인가? 데일리 스크럼의 필..
애자일의 등장 배경초기 소프트웨어의 개발 방법은 계획 중심의 프로세스(SW 개발의 역사)* 초기에 SW를 주로 개발했던 분야는 '군사'쪽의 대형 프로젝트이다.* 즉, 계획 중심의 프로세스로 SW 개발이 진행됬다.- 이 계획 중심의 프로세스는 '건축(도시 계획)' 에서의 방법을 본딴 것이다.* 당시에는 이런 프로세스를 하는 것이 적합해보이는 프로젝트가 대부분이었다. 하지만, 지금은 달라졌다. 높아진 SW 개발의 불확실성* 90년대를 지나면서 SW분야가 젋어지고 SW의 사용자(end user)들이 '일반 대중을'로 바뀌기 시작했다.* 또한 비지니스 싸이클이 짧아지면서 사람들의 욕구와 트렌드도 빨리 바뀌게 되었다.- 비지니스 싸이클 : 제품이 나오고 , 사용하고, 또 다른 제품으로 넘어가서 사용하고, 또 새로..
소프트웨어 디자인 패턴(software design pattern)이란? 소프트웨어 공학에서 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계 코드로 바로 전환될수 있는 완성된 디자인은 아니며, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿이다. 디자인 패턴은 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 관행이다.