금융IT

은행의 기본 업무 : 수신 / 여신 / 이체 / 결제 등이자계산 로직 / 회계분개 규칙 / 계약신규 프로세스 / 상품조건 / 고객정보 관리 / 정산개발자 레벨은 S/E에서 결정 : 알고리즘 / 디자인 패턴 / 리팩토링 / 트러블 슈팅 / 테스팅 / 프레임워크 / 방법론

클라이언트의 요구사항 분석 후 '데이터' 요건 형상화 필요.. table 설계 과정이건 이렇게 저건 저렇게 해주세요 (X) / 잘 돌아가게 해주세요 (O)전체적인 구조를 이해하고, 일관된 개념 하에 이루어지는 모델링 작업 필요적절한 모델링이 이루어지지 않으면 실제적 변

막상 실습해보니 굉장히 난해하다. 어떤 것부터 고려해야 할 지 순서를 정하고, 절차에 맞춰서 한 단계씩 진행해야 할 것 같다.한번에 idea가 떠올라서 구조를 짜면 오히려 error 가능성..

💰 0. 전 실습 간 수정사항

왜 우리 회사의 솔루션 / 상품을 이용해야 하는지 논리적으로 설명해야함.제목 20%가 인식 80%를 결정한다.다양한 RFP와 제안서를 보면서 안목을 키워야 할 것 같다.. 현재 많이 부족한 수준.

설계안을 도출하기 위한 모든 것요구사항에 대한 여러 가지 해석 존재반드시 구체적으로 서술되어야 함.요구사항 정의 - 외부 설계 - 개발 스프린트 - 결합 테스트 - 통합 테스트 - 인수 테스트 / 교육 - 컷오버 - 안정화Transaction : request - re

모델링 절차와 유사하게, 주제영역 식별 - 엔티티 식별 - PK 식별 - Attribute 부여 등의 절차를 생각하면 쉽다.'나' 라는 주체를 중심으로 내부 어플리케이션 / 외부 에이전트를 식별한 후 순서에 따라 위에서 아래로 서술컨텍스트 다이어그램을 쪼개면 업무 프로

길게 가자.. 인문학 / 역사 등 관심을 가지고 책을 읽어보자.모르는 게 있으면 여쭈어 보자.스트레스는 당연히 발생하는 것 / 안고 간다고 생각하자.어플리케이션 또는 시스템의 동작과 성능, 안정성이 요구사항을 만족하는지 확인하는 과정요구사항과 다른 것은 결함(defec

원천징수 / 비과세 / 질권

💰 원금균등 💰 원리금균등 💰 만기일시