그냥 한번 작성

UML

• 시스템 개발 과정에서 개발자와 고객 or 개발자 간 의사소통 도와주는 객체지향 모델링 언어
• 6개 구조 다이어그램 -> 시스템 구조 표현
• 7개 행위 다이어그램 -> 시스템 동작 표현

사물 (Things)

관계 (Relationships)

연관 관계 (Association)

• 2개 이상 사물 서로 연결
• 서로에게 영향 시 화살표 생략

집합 관계 (Aggregation)

• 하나의 사물이 다른 사물에 포함되어 있는 관계
• 서로 독립적

포함 관계 (compostion)

• 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
• 서로 독립적이지 않다. (생명주기 함께 함)

일반화 관계 (Generalization)

• 다른 사물에 비해 더 일반적인지, 구체적인지
• 상속관계라고 생각하면 쉬움
• 일반적 -> 상위(부모)
• 구체적 -> 하위(자식)

의존 관계 (dependency)

• 서로 연관 있으나 필요에 의해 짧은 시간 동안만 유지

실체화 관계 (Realization)

• 사물이 할 수 있거나 해야 하는 기능 서로 그룹화 가능한 관계

※ 관계 간단 정리

다이어그램 (Diagram)

• 시스템을 가시화 한 뷰(view) -> 의사소통 도움

구조적 다이어그램

• 정적 모델링에서 주로 사용

행위 다이어그램

• 동적 모델링에서 주로 사용

요구사항

• SW가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명
• 정상적으로 운영되는데 필요한 제약조건 등
• 개발 참여하는 이해관계자들 간의 의사소통 도움

요구사항 유형

○ 기능 요구사항

• ex) 기능에 관한 요구사항 (회원ID, PW를 입력하여 로그인 할 수 있다.)
• 시스템이 무엇을 하는지, 어떤 기능을 하는지 (동작)
• 시스템이 반드시 수행해야하는 기능
• 시스템을 통해 사용자가 제공받기를 원하는 기능

○ 비기능 요구사항

• ex) 대부분 품질이나 제약사항 관련 (시스템 1년 내내, 하루 24시간 운용)
• 시스템 장비 구성 요구사항
• 성능 요구사항
• 인터페이스 요구사항
• 데이터 요구사항
• 테스트 요구사항
• 보안 요구사항
• 품질 요구사항
• 제약사항 요구사항
• 프로젝트 관리 요구사항
• 프로젝트 지원 요구사항

○ 사용자 요구사항

• 사용자 관점에서 시스템이 제공해야 할 요구사항

○ 시스템 요구사항

• 개발자 관점에서 시스템 전체가 사용자 및 다른 시스템에 제공해야 할 요구사항
• 전문적이고 기술적인 용어로 표현
• 소프트웨어 요구사항

요구사항 개발 프로세스

요구사항 도출 (Requirement Elicitation)

• 개발 관련된 사람들이 서로 의견 교환
• 요구사항 어디 있는지, 어떻게 수집할 것인지 식별 및 이해
• 개발자↔고객 사이의 관계 생성
• 이해관계자 식별 (다양한 이해관계자 간의 효율적인 의사소통 중요)
• SW 개발 생병 주기 동안 지속적 반복
• ex) 브레인 스토밍, 프로토 타이핑, 유스케이스, 인터뷰, 설문 등

요구사항 분석 (Requirement Analysis)

• 요구사항 중 명확하지 않거나 모호한 부분 발견 및 걸러냄
• 요구사항의 타당성 조사 -> 비용과 일정 제약 설정
• 도출된 요구사항 토대로 SW 범위 파악

요구사항 명세 (Requirement Specification)

• 요구사항 체계적으로 분석 후 문서화
• 기능 요구사항 -> 완전 명확하게 기술
• 비기능 요구사항 -> 필요한 것만 명확하게 기술
• 사용자 이해쉽게, 개발자 효과적 설계하도록 작성

요구사항 확인 (Requirement Validation)

• 개발 자원을 요구사항에 할당하기 전
• 요구사항 명세서가 정확하게 작성되었는지 검토
• 요구사항 명세서 내용 이해쉬운지, 일관성, 회사기준 등 검증
• 요구사항 정의 문서들에 대해 형상 관리 수행

※ 도출 -> 분석 -> 명세 -> 검증

구글 문서 음성입력

최근 코로나19 때문에 유치원생부터 시작해서 대학생까지 모두 개학 연기로 인해 집에 있다.

대학생의 경우 집에서 온라인 강의를 듣고 과제물을 통해 출석인정이 되는 방식으로 진행이 되는데,

이 같은 과정에서 문제가 발생한다는 것을 최근에 스브스뉴스를 통해 접하게 되었다.

입모양만 보고 온라인 강의를 하는 청각장애인 학생분들을 위해 어떻게 하면 좋을까 고민도 해보았다.

마음 같아서는 자막과 수화(수어)가 같이 나오는 프로그램을 개발하고 싶다.

지금 당장은 개발하지 못하지만 나중에 내가 할 수 있는 것이 더 많아지면 개발하고 싶다.

하지만 그 전에 구글 문서 음성입력이라는 좋은 것이 있기 때문에 지금은 이것을 활용해보자.

마이크가 없거나 마이크를 내장하지 않은 컴퓨터를 사용하는 분들도 사용할 수 있으며,

교수님께서 무슨 말씀을 하는지 모르겠다는 분들도 유용할 것이다.

1. 보통 컴퓨터 화면 오른쪽 하단에 보면 스피커 모양의 아이콘이 있을 것이다. 이것을 마우스 우클릭 한다.

2. 소리를 클릭한다.

3. 녹음 탭 -> 마우스 우클릭 -> 사용할 수 없는 장치 표시 클릭

4. 스테레오 믹스 -> 사용 (나머지는 사용 안 함) -> 확인

5. 구글 아이디와 크롬 준비

https://www.google.co.kr/chrome/index.html

6. 구글 로그인 -> 구글문서 

https://docs.google.com/document/?usp=mkt_docs

7. 새 문서 시작

8. 도구 -> 음성 입력 클릭 (Ctrl+Shift+s)

9. 언어 설정 -> 마이크 클릭 -> 녹음

※ 영상을 먼저 켜고 클릭해야하고, 발음이 안 좋거나, 주변 잡음이 많이 있으면 자동으로 멈출 수 있습니다.

XP (eXtreme Programming)기법

• 고객의 참여와 개발 과정의 반복을 극대화 -> 개발 생산성 향상
• 짧고 반복적인 개발 주기
• 단순한 설계
• 적극적인 고객참여
• 릴리즈 기간 짧게 반복 -> 요구사항 반영의 가시성 향상
• 비교적 소규모 인원 개발 프로젝트 적합
• 자동화된 테스팅 도구 사용 권장

※ XP의 5가지 핵심가치

1. 의사소통
2. 단순성
3. 용기
4. 존중
5. 피드백

→ 피.존.의.용.단

XP 개발 프로세스

사용자 스토리 (User Story)

• 고객 요구사항 -> 간단한 시나리오 표현
• 기능 단위 구성
• 필요 시 간단한 테스트 사항 기재

릴리즈 계획 수립 (Release Planning)

• 릴리즈 : 몇 개 스토리 적용되어 부분적 기능 완료된 제품 제공
• 부분 or 전체 개발 완료 시점 일정 수립

스파이크 (Spike)

• 요구사항 신뢰성↑, 기술문제 위험 감소↓ 위한 간단한 프로그램
• 처리할 문제 외 모두 무시

이터레이션 (Iteration)

• 릴리즈 세분화 한 단위
• 1~3주 정도 기간 진해애
• 새로운 스토리 작성 및 포함 가능 (다음 이터레이션에도 포함 가능)

인수 테스트 (Acceptance Test)

• 계획된 릴리즈 단위의 부분 완료 제품 구현 시 수행
• 데트트 사항에 대해 고객이 직접 수행
• 오류사항 발견 시 다음 이터레이션에 포함
• 테스트 후 새 요구사항 작성 및 요구사항 우선순위 변경 가능

소규모 릴리즈 (Small Release)

• 기능별 고객 반응 확인 -> 유연 대응
• 계획된 릴리즈 기간 동안 모두 완료 시 최종 테스트 후 릴리즈

스크럼 (Scrum) 기법

• 팀 중심의 개발 효율성 향상
• 팀원 스스로 스크럼 팀 구성
• 개발 작업에 모든 것을 스스로 해결해야함

1. 제품 책임자 (PO: Product Owner)

• 개발될 제품 이해도 높음
• 요구사항 책임 및 의사결정자 선정 (개발의뢰자 or 사용자)
• 이해관계자 의견 종합 -> 제품 요구사항 작성
• 요구사항 포함한 백로그 작성 및 백로그 우선순위 지정
• 제품 테스트 수행하며 주기적 요구사항 우선순위 갱신

※ 팀원은 백로그에 스토리 추가 O

※ 팀원은 백로그에 우선순위 지정 X

2. 스크럼 마스터 (SM: Scrum Master)

• 팀이 잘 수행하도록 객관적 시각 조언 - 가이드 역할 (팀원 통제X)
• 일일 스크럼 회의 주관
• 진행사항 점검, 개발과정 중 발생된 장애요소 공론화하여 처리

3. 개발팀 (DT: Development Team)

• 제품 책임자와 스크럼 마스터 제외 모든 팀원 (개발자, 디자이너, 테스터 등 참여자)
• 보통 인원 7~8명 적당

스크럼 개발 프로세스

○ 제품 백로그 (Product Backlog)

• 제품 개발에 필요한 모든 요구사항에 우선순위 부여한 목록
• 개발 과정 중 새로운 요구사항으로 지속적 업데이트
• 사용자 스토리 기반 릴리즈 계획수립

계획 회의 -> 스프린트 -> 일일 회의 -> 검토 회의 -> 회고

○ 스프린트 계획 회의 (Sprint Planning Meeting)

• 이번 스프린트에서 수행할 작업 대상으로 단기 일정 수립
• 처리할 요구사항 -> 태스크 작업단위로 분할 후 개발자별 수행 -> 스프린트 백로그 작성

※ 스프린트 백로그 : 개발자별로 수행할 작업 목록

○ 스프린트 (Sprint)

• 실제 개발 작업 진행
• 보통 2~4주 기간 내 진행
• 작업 시간 추정 후 개발 담당자 할당 (직접 선별하는게 좋음)
• To Do, In Progress, Done 3가지 상태

○ 일일 스크럼 회의 (Daily Scrum Meeting)

• 모든 팀원 약속시간에 매일 약 15분 정도 진행상황 점검 (보통 서서 진행)
• 남은 작업 시간은 소멸 차트 (Burn-down Chart)에 표시

※ 스크럼 마스터는 장애요소 해결 도와줌

○ 스프린트 검토 회의 (Sprint Review)

• 사용자 포함 참석자 앞에서 테스팅 수행
• 스프린트 한 주당 1시간 내 진행

※ 제품 책임자는 피드백 정리 후 제품 백로그에 업데이트

○ 스프린트 회고 (Sprint Retrospective)

• 스프린트 주기 되돌아보며 개선할 점, 규칙준수 확인 및 기록
• 해당 스프린트 끝난 시점 or 일정 주기로 수행

소프트웨어 생명주기

• 소프트웨어 개발 방법론의 바탕이 된다.
• 소프트웨어 생명주기 모형이라 하며, 소프트웨어 프로세스 모형 or 소프트웨어 공학 패러다임이라 한다.
• 개발자는 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택 사용 가능, 개별적인 모형 사용가능

1. 폭포수 모형 (Waterfall Model)

• 이전 단계로 돌아갈 수 없다.
• 선형 순차적 모형 (각 단계를 확실하고 철저하게 검토하여 승인 과정을 거친 후 다음 단계 진행)
• 고전적 생명 주기 모형 (소프트웨어 공학에서 가장 오래됨)
• 매뉴얼 작성해야함
• 결과물이 명확하게 산출되야함 (다음 단계 진행위해)
• 2개 이상 과정이 병행하여 수행X

※ 타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현 -> 검사 -> 유지보수

2. 프로토타입 모형 (Prototype Model)

• 견본품을 만들어 최종 결과물 예측
• 사용자와 시스템 사이의 인터페이스 중점 개발
• 추후 구현 단계에서 사용될 골격 코드
• 폭포수 모형 단점 보완

※ 요구수집 -> 빠른 설계 -> 프로토타입 구축 -> 고객평가 -> 프로토타입 조정 -> 구현

3. 나선형 모형 (Spiral Model)

• 보헴 제안
• 폭포수 + 프로토타입 + 위험분석 기능
• 점진적으로 최종 소프트웨어 개발
• 개발 중 위험 관리 및 최소화 목적
• 누락 및 추가 요구사항 첨가 가능
• 정밀하고 유지보수 과정 필요X

4. 애자일 모형 (Agile Model)

• 고객 요구사항에 대해 유연하게 대응가능
• 일정한 주기 반복 개발과정
• 각 개발주기에서 요구사항에 우선순위 부여
• 소규모 프로젝트, 고도 숙달 개발자, 급변 요구사항에 적합
• ex) 스크럼, XP, 칸반, Lean, 크리스탈, ASD 등등

※ 애자일의 4가지 특징

1. 프로세스, 도구 < 개인과 상호작용
2. 방대한 문서 < 실행되는 SW
3. 계약협상 < 고객과 협업
4. 계획 < 변화 반응

아래 링크 클릭

https://www.oracle.com/downloads/

스크롤 내리다가 Developer Tools의 SQL Developer 클릭

각자 컴퓨터 사양에 맞는 것을 다운로드

(교육 진행 중에 다운하지않고 이전 대학강의 시간에 따로 다른 버전을 다운로드하여 그것을 사용하였음)

.

.

.

다운로드가 완료 시 다운된 경로로 들어가 sqldeveloper.exe 실행하고 보류

이전 글에 Docker와 Docker image가 설치되었다면 다시한번 oraxe11g 도커 이미지가 있는지 확인

docker images

실행 중인 것이 있는지 확인

docker ps -a

oraxe11g 실행하고 잘 실행되는지 다시 확인

docker start oraxe11g

1 -> 2 -> 3 -> 4 순서대로 확인

4에서 ex) 123.456.789.100:1521 와 같은 형태로 되있는지 확인하고 :1521이전까지 기억

그러고 나서

왼쪽 상단에 초록색 + 버튼 클릭

접속 이름 : oraxe11g-system

사용자 이름 : system

비밀번호 : oracle (개인이 기억할 것으로 설정)

비밀번호 저장 체크

호스트 이름 : ※ 위에 도커에서 기억한 ip 입력

입력하고 바로 저장하지 말고 테스트 클릭 후 상태에 성공이라고 뜨면 저장

테스트 시 상태가 빨간글씨로 오류나면 도커쪽하고 연결이 안됬거나 이미 있는 오라클 계정

.

.

저장되었으면 생성된 oraxe11g-system 계정 더블 클릭

sql문 실행하여 연습용 계정 잠금해제 -> 커밋

alert user hr account unlock;
alert user hr identified by hr;

다시한번

접속 이름 : oraxe11g-hr

사용자 이름 : hr

비밀번호 : hr (개인이 기억할 것으로 설정)

비밀번호 저장 체크

호스트 이름 : ※ 위에 도커에서 기억한 ip 입력

연습할 계정 생성

.

.

.

연습용 계정 생성하고 unlock했던가... 기억이 안남

생성된 3개의 아이콘 중 Kitematic(Alpha) 클릭

이렇게 잘 설치 되다가 빨간색으로 바뀔텐데 그냥 가만히 두면 알아서 됨

시간이 지나도 안된다하면 기억이 안나는데 맨 오른쪽 버튼인가 클릭한거로 기억남

.

.

.

로그인 창이 나오면 가입해도 상관없지만 오른쪽 하단에 Skip now 클릭 후

왼쪽 하단에 Docker CLI 클릭

.

.

docker pull mrsono0/devremotecontainers:oraxe11g

docker images

docker run --name oraxe11g -itd -p 1521:1521 -e ORACLE_ALLOW_RENAME=true mrsono0/devremotecontainers:oraxe11g

docker ps -a

docker stop oraxe11g

docker start oraxe11g