iTrust2-Yonsei

Background

iTrust2 was founded as a class project for CSI3106 Software Engineering in the Computer Science Department of Yonsei University and is maintained primarily by Yeonghwan Jang. The goal of iTrust2 is to engage students with software engineering practices on a significant, relevant, and growing application that includes security and privacy requirements.

iTrust2 is an Electronics Health Records system (EHR) that provides patients with a means to maintain their health records and communicate with their health care providers (HCPs). HCPs can record information about office visits including basic health metrics, diagnoses, prescriptions, eye care, and pregnancy care. iTrust2 follows HIPAA statue for ensuring security and privacy of patient records.

Technical Info

iTrust2 is written with Java EE and JavaScript. It uses Spring to handle the backend and AngularJS on the frontend (currently AngularJS v1.6; work is underway to migrate to AngularJS v7) and runs with a MySQL/MariaDB database. Testing is performed using Spring for the API and a combination of Cucumber and Selenium on the frontend.

iTrust2 is a successor to the original iTrust also developed at NC State University. We mainly referred to NSCU CSC 326 SWE project

Each semester, the teaching staff releases a new version of iTrust2, taking a project from one team that followed particularly good practise and implemented a particularly good version, and cleans it up a bit.

Starting with v8, iTrust2 received a significant rewrite of the Java layers of the system. This was done to upgrade to Spring Boot 2.x (2.3.7.RELEASE as of the time of this writing) and use a more moduler, component-based architecture. This brought several benefits, such as transaction-based rollback in tests and separate test/production databases through Application Profiles. However, from a functional perspective, iTrust2-v8 marks a significant regression from iTrust2-v7, losing about half of the usecases. Efforts are underway to rewrite them.

iTrust2 Project

Members

GitHub ID	Name	Cell No.	Department
0xseo	Kim, Yeong Seo	Cell 1	Yonsei CS
2021147599	Park, Seungho	Cell 1	Yonsei CS
ddoddii	Uhm, Soeun	Cell 1	Yonsei IE
Nugu-ai	Kim, Jueun	Cell 2	Yonsei CS
yjy0503	Yoon, Jongyoon	Cell 2	Yonsei CS
yeong-hwan	Jang, Yeonghwan	Cell 2	Yonsei CS
minyong-yonsei	Kang, Minyong	Cell 3	Yonsei CS
three0-s	Lim, Yewon	Cell 3	Yonsei CS
2021147593	Noh, GyuMin	Cell 3	Yonsei CS

Leader Role

Iteration 1

• Team Leader: Park, Seungho
• QA Leader: Uhm, Soeun
• Plan Leader: Kim, Yeong Seo

Iteration 2

• Team Leader: Jang, Yeonghwan
• QA Leader: Yoon, Jongyoon
• Plan Leader: Kim, Jueun

Iteration 3

• Team Leader: Lim, Yewon
• QA Leader: Noh, GyuMin
• Plan Leader: Kang, Minyong

Project Rules

1. Communication is Key: Maintain open communication channels through Slack, emails, or regular standup meetings.
2. Task Assignment: Use project management tools (e.g., Trello, Asana) to assign tasks clearly and keep track of progress.
3. Code Review & Merge: All code must go through a review process before merging into the main branch.
4. Documentation: Keep documentation up-to-date to ensure smooth onboarding and knowledge transfer.
5. Coding Standards: Adhere to agreed-upon coding standards and naming conventions for consistency across the codebase.
6. Branch Protection: Protect important branches (main, develop) to prevent direct pushes and require code reviews for merging.
7. Testing Protocol: Ensure comprehensive test coverage for new features and bug fixes; automate where possible.
8. Meeting Etiquette: Start meetings on time, prepare an agenda, and ensure active participation from all team members.
9. Version Control: Use descriptive commit messages and avoid committing large, unrelated changes in a single commit.
10. Feedback Loop: Encourage a culture of feedback and improvement, both within the team and from stakeholders or end-users.

User Case Progress

User Case	Cell	Task Assignment	API Documentation	Backend API Completion	Frontend UI Completion	Integration & Testing
UC 21	Cell 1	✅	✅	✅	✅	✅
UC 22	Cell 1	✅	✅	✅	✅	✅
UC 16	Cell 2	✅	✅	✅	✅	✅
UC 19	Cell 2	✅	✅	✅	✅	✅
UC 15	Cell 3	✅	✅	✅	✅	✅
UC 23 (new)	Cell 3	✅	✅	✅	✅	✅

UC API Documentation

User Case	Cell	Document Link
UC 21	Cell 1	API Document
UC 22	Cell 1	API Document
UC 16	Cell 2	API Document
UC 19	Cell 2	API Document
UC 15	Cell 3	API Document
UC 23 (new)	Cell 3	API Document

Test Coverage

Achieved over 80% test coverage across all UCs implemented.

Regular Meeting

11 PM, Tue, 1hour.
Link: https://meet.google.com/ocp-naww-bnv

Meeting Date	Meeting Purpose	Participants	Document Link	담당 Cell
2023-10-17	Iter1 대비	Cell 1, 2, 3	Meeting Document	Cell 1
2023-10-24	Iter1 대비	Cell 1, 2, 3	Meeting Document	Cell 1
2023-11-07	Iter2 대비	Cell 1, 2, 3	Meeting Document	Cell 2
2023-11-14	Iter2 대비	Cell 1, 2, 3	Meeting Document	Cell 2
2023-11-28	Iter3 대비	Cell 1, 2, 3	Meeting Document	Cell 3
2023-12-05	Iter3 대비	Cell 1, 2, 3	Meeting Document	Cell 3

Meetings

Meeting Date	Meeting Purpose	Participants	Document Link
2023-10-28	UC 읽어보고 선정하기	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-10-30	Cell2 포지션 분배 및 개발 계획	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-11-04	Cell3 첫 미팅 및 구조 파악	Cell 3 (강민용, 임예원, 노규민)	Meeting Document
2023-11-04	포지션 재분배 및 Git 숙지	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-11-05	DB 칼럼 공부하기	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-11-08	UC15 필요한 기능에 대한 논의	Cell 3 (강민용, 임예원, 노규민)	Meeting Document
2023-11-09	UC19 API 명세 작성 및 개발 계획 브리핑	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-11-11	개발관련 오류 논의	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-11-13	UC19 FE BE간 개발 상황 공유	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-11-13	기능별 권한 확인하기	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-11-15	UC23 필요한 기능에 대한 논의	Cell 3 (강민용, 임예원, 노규민)	Meeting Document
2023-11-15	eclipse Build 이슈 해결	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-11-16	UC 21 구현	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-11-18	UC15, UC23 API 문서 작성	Cell 3 (강민용, 임예원, 노규민)	Meeting Document
2023-11-18	UC19 API 기능 설명 및 수정	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-11-18	FE, BE 형식 맞추기	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-11-20	UC15 개발 및 Test 작성 완료	Cell 3 (강민용, 임예원, 노규민)	Meeting Document
2023-11-20	UC19 이슈 해결 및 발표 준비	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-11-20	API 테스트 이슈 공유	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-11-22	UC22 개발 계획	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-11-24	UC16 역할 분담 및 개발 계획	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-11-24	FE 관련 화면 오류	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-11-28	UC23 개발 계획 수립 및 개발 시작	Cell 3 (강민용, 임예원, 노규민)	Meeting Document
2023-11-29	UC16 API 개발 이슈 공유 및 해결	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-12-01	UC23 개발 및 Test 작성 완료	Cell 3 (강민용, 임예원, 노규민)	Meeting Document
2023-12-01	BE, FE 관련 오류 해결	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-12-03	UC16 개발 상황 공유 및 이슈 해결	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-12-05	UC16 API 작동 문제 해결	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document
2023-12-07	테스트 코드 이슈	Cell 1 (김영서, 박승호, 엄소은)	Meeting Document
2023-12-08	UC16 테스트코드 문제 해결	Cell 2 (김주은, 윤종윤, 장영환)	Meeting Document

Git Flow

We follow a simplified Git flow process:

Branching Strategy

• main: Production-ready code
• develop: Integration branch for ongoing development
• Feature branches: Begin with feature/ prefix (e.g., feature/team1-UC21-FE)

Workflow

1. Start with develop: Create feature branches from the develop branch.
2. Work on Features: Develop new features or fix issues in feature branches.
3. Pull Requests: Submit pull requests to merge feature branches into develop.
4. Code Review: Team members review code, suggest changes if necessary.
5. Merge to develop: After approval, merge into the develop branch.
6. Release: Periodically merge develop into main for stable releases.

How We Co-operation

Git flow

• Git flow description

Commit Convention

• Commit Convention reference

# --- COMMIT END ---  
#   <Type> : Title 
#   feat        : 기능 (새로운 기능)  
#   fix         : 버그 (버그 수정)  
#   refactor    : 리팩토링  
#   design      : CSS 등 사용자 UI 디자인 변경  
#   comment     : 필요한 주석 추가 및 변경  
#   style       : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)  
#   docs        : 문서 수정 (문서 추가, 수정, 삭제, README)  
#   test        : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)  
#   chore       : 기타 변경사항 (빌드 스크립트 수정, assets, 패키지 매니저 등)  
#   rename      : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우  
#   remove      : 파일을 삭제하는 작업만 수행한 경우  
# ------------------  
#   <Body> : descripton(optional)
# ------------------  
#   <Footer> : issue control(optioanl)
#   Fixes        : 이슈 수정중 (아직 해결되지 않은 경우)  
#   Resolves     : 이슈 해결했을 때 사용  
#   Ref          : 참고할 이슈가 있을 때 사용  
#   Related to   : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)  
#   ex) Fixes: #47 Related to: #32, #21