중간 발표 준비
SMART 원칙 기반 구성
1️⃣ Specific : 프로젝트 개요나 해결하고자하는 문제를 구체적으로 정의 ✅
2️⃣ Measurable : 정량적 목표 지표 또는 성능 기준 정의 ✅
3️⃣ Achievable : 현재 팀의 기술 수준-시간 데이터로 달성 가능한 목표인지 선언 ✅
4️⃣ Relevant : 목표의 중요성, 문제 해결과 어떤 연관이 있는가 → MVP 기능과 연결 ✅
5️⃣ Time-bound : 언제까지 무엇을 완성할 것인지 구체적 범위 제시 ✅
프로젝트 주제 및 선정 배경
- 주제 선정 배경 = pain point
- 기존 유사 서비스가 지닌 한계
- 서비스명, 주제 공개
서비스 기획
- 서비스 타겟
- 서비스 목표
- MVP
프로젝트 내용
- 개발 환경 및 기술 스택
- 멀티모듈 방식
- 메시지 기반 통신
- ERD (Sync 테이블)
- 문서 위변조 검증 로직
- 인프라 아키텍처
- CI/CD
- 핵심 기능 및 UI 소개
기대 효과 및 마무리
- 기대 효과 및 확장성
- 프로젝트 일정 → 스프린트 별 계획
5회차 멘토링
최종 전까지 대비 및 보완이 필요한 부분 정리
정부 연계, 공공데이터, 오픈API 찾아봐야 한다. 없으면 만든다?
- 진짜 자격이 있는 사람인지 확인하기 위해 사회복지사 어느 기관 등록되어 있는지 검증 필요 → 공공데이터를 활용해야 할까?
- 현재는 장애인활동 지원사 교육 이수증 검증 → 이게 위변조 된지 아닌지만 검증 + 수여해준 기관에 대한 검증
- https://developer.codef.io/products/public/each/mw/certificate-disability
- 실제 장애인 정보를 가지고 있을 순 없으니까 DB에 데이터 살짝 담아놓고 이 api처럼 입력값 받으면 존재하는 장애인 정보인지 임의로 체크해주는 api 만들기 (회원 서비스쪽에) - 이런걸 고려를 했다는게 중요다양한 장애 유형 커버
- 시각장애인
- 스크린 리더 테스트 필요
- 진짜 내 도우미를 판단할 수 있는 방안 (시각 정보 없이)
- 시각장애인이 버튼 누르면 상대 기기에서 음성 출력 → api 사용
- 아무때나 누르게 하면 안될듯 (ex. 맥도리아 앱 쿠폰 사용 방식)
- 청각장애인
- 진짜 내 도우미인지 판단할 수 있는 방안 (소리 없이) → 하면 좋다. 일단 보류
- 지체장애인 (손, 팔 장애)
- 음성 인식으로 처음부터 끝까지 해볼 수 있으면 좋겠다. -> 일단 보류
- 추후 확장 방안으로 제시해도 좋을 듯
- 그 외 장애 유형 (지적 장애인)
- 기관 연계해서 오픈 API 조회 해서 어떤 기관이 어떤 날짜, 시점에 도우미를 얼마나 갖고 있는지 보여주고 예약할 수 있는 기능 -> 보류
- 사용자 테스트 중요당도의 역할에 대한 재고
- 숨고나 네이버 지식인처럼 ⇒ 업적 시스템
- 뱃지
- ex. 시각장애인 도움 5회 이상 → 시각 장애인 전문가
- 시간을 잘 지켜요 등
-> 기존 별점식 리뷰에서 키워드 선택식 리뷰로 변경
- 프로필 페이지에서 활동 내역에 관한 시각화에 좀 더 유의미한 정보를 담으면 좋겠다 → 활동 개수 말고도 도움 유형, 도와준 장애인의 장애 종류 등등까지 그 도우미가 가진 특성이나 경험을 더 제대로 확인할 수 있도록애니메이션 효과
- 배민 라이더 위치 표기하는 것처럼 꽃잎, 꿀벌 위치 실시간 위치 표기시연 영상
- 어떤 기능에 대해 시연할지 시나리오 구성 필요
- 우리 팀원 중 한명이 안대 쓰고 시연하는 영상 첨부 or 시각장애인 유튜버? 섭외