https://www.youtube.com/watch?v=JhKOsZuMDWs&list=PL6i7rGeEmTvqEjTJF3PJR4a1N9KTPpfw0
소프트웨어 공학 = 소프트웨어를 만들기 위한 전체적인 학문
소프트웨어 = 어플리케이션
스마트폰 안에 있는 프로그램들
윈도우 또는 맥에서 사용되는 다양항 소프트웨어들
상품성 - 판매가 안 되면 필요가 없다
복잡성 - 복잡하다, 단계가 많다
변경 가능성 - 변경이 가능하다 (업데이트)
복제성 - 많이 복제해서 쉽게 사용할 수 있고 유통할 수 있다.
시스템 = 하나의 조직 (컴퓨터 시스템)
입력, 처리, 출력, 제어, 피드백
제어 (처리를 하는데 제어)
입력 -> 처리 -> 출력
피드백 (결과에 대한 피드백)
소프트웨어 위기
소프트 웨어 비용을 초과하는 개발의 증가
디자이너, 설계자, 프로젝트 매니저, 데이터베이스 관리자 등 여러 사람들이 들어간다
개발 기간의 지연
인력이 많이 필요한데 부족하다
인건비의 상승
신뢰성의 부족
유지보수의 어려움 등 엄청난 비용이 든다
유지보수 비용
윈도우 만드는 것은 얼마 안 든다 그러나 3달에 한번씩 주기적으로 보안 업데이트 -> 비용
소프트웨어 공학의 기본 원칙
현대적인 프로그래밍 기술 적용
신뢰성 (100개 중 2개가 틀렸다)
사용의 편의성
유지 보수성
지속적인 검증
소프트웨어 재공학
많은 돈이 든다
기존에 만들었던 것 다시 쓴다
개발 시간
비용 감소
품질 향상
생산성 향상
신뢰성 향상
구축 방법 지식 공유
-> 프로젝트 실패 위험이 감소
소프트웨어의 유지 보수성 향상이 최우선 목표
복잡한 시스템을 다루는 방법을 구현하고 다른 뷰를 생성하고
잃어버린 정보의 복구를 제거
재사용을 수월하게 해서 소프트웨어 수명을 연장하기 위해서다
분석(잘 쓸 수 있겠냐) -> 구성(구조를 변경) -> 역공학(거꾸로 분석해내는 것) -> 이식(실제로 적용)
역공학
소프트웨어를 분석하는 기법
다시 만들어서 쓰기 위함
문서화를 통해서 쓸만한 곳에 쓸 수 있느냐에 해당하는 것
CASE - 소프트웨어 엔지니어링을 도와주는 자동화 도구
개발 신속 정확
품질 향상
소프트웨어 생명주기 전체 단계를 연결
자동화 시켜주고 통합
소프트웨어 시스템의 문서화와 명세화를 위한 그래픽 기능을 제공
개발 단계의표준화를 기할 수 있고 자료 흐름도 작성 기능 제공
모델들 사이의 모순 검사 기능을 제공
다양한 소프트웨어 개발 모형을 지언
원천기술은 구조적 기법과 프로토타입 기법, 정보 저장소 기술
소프트웨어를 개발하는데 도움을 주는 것
기간 단축
비용 절약
생산성 향상
소프트웨어로 제공
소프트웨어를 맨처음에 설계하고 구현하고 나중에 유지보수 하는 전체적인 내용들을 총괄 관리하게 된다.
문서화 도구
상위: 상단 설계에서 초기에 일어나는 요구 분석 설계 지원
하위: 실제 구현 (코딩 지원)
통합: 소프트웨어 개발 주기 전체 과정 지원
요구사항 분석을 위한 도구
SADT - 소프트웨어 툴, CASE 프로그램 중 하나, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해서 널리 사용되어 온 구조적 설계 도구다. 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구다.
CASE를 도와주는 프로그램 이름
블록 다이어그램을 지원
소프트웨어 개발 방법론
- 소프트웨어 생명 주기: 사람이 태어나서 생명주기, 소트프웨어도 폐기 될 때 까지 전체 사이클이 있다.
타당성 검토 (1억 들여서 개발할 건데 1억어치 줄거니) -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수
- 폭포수 모형: 폭포는 거꾸로 올라가지 못해 (순서대로 쭉 해나가는 것), 소규모 소프트웨어에 아주 적합, 중간에 요구사항이 변경되거나 이벤트가 발생했을 경우에 그 내용을 적용할 수 없다
- 나선형 모형(Spiral Model): Boehm, 요렇게도 해보고 저렇게도 해보고 조금씩 진화시키는 거다. 반복적으로 작업, 중간에 위험 분석,
계획 수립 그리고 위험 분석 (중간에 변동사항, 이벤트) -> 고객님께 평가 (이게 맞니) -> 요구사항을 다시 파악 -> 두번째 위험 분석 그리고 2차 프로토 타입(시제품, 임의로 하나 만들어봄) 그리고 개발 및 검증
하향식 설계: 상위에 있는 메인 유저 function (주 사용자 함수)를 먼저 만들고 나머지 곁가지를 만들어 나가는 것
상향식 설계: 아주 단순한 아이들을 모아가지고 기둥을 세우는 형태 (기초적인 기능들을 가지고 통합해서 만들어내는 것)
프로토타입: 실제 개발될 시스템의 견본(시제품)을 미리 만든다. 고객과의 커뮤니케이션이 좋아진다. 이 사람이 무엇을 원하는지 만들어갈 수 있는 하나의 도구. 완제품을 만드는 경우도 있다. 큰 프로젝트는 프로토타입을 만들고 폐기하고를 반복. 소규모 프로젝트에서는 시제품을 보완해서 완제품을 만든다.
- HIPO: 계층적 입력 처리 출력, 폭포수형하고 같은 것이다.
입력 처리 출력으로 구성되는 시스템 분석 및 설계와 문서화 과정이다.
가시적 도표, 총체 다이어그램, 세부 다이어그램 세가지로 구성
하향식 소프트웨어 개발을 위한 문서화 도구이다.
여기서 가시적 도표를 쓸 수 있다.
보기 쉽고 이해하기 쉬우며 유지보수가 쉽다.
- V-모델
폭포수 모형에서 시스템 검증과 테스트 작업을 강조한 모델
요구사항 분석 ~ 테스트 계획 및 설계(정적) : HIPO
전체는 V모델
정적: 코드를 분석
동적: 실제 실행
실제 요구사항과 우리가 만들어낸 것이 같은가를 검증하게 된다.
실제 각각 단위에서 얘가 실제로 테스트 한 것이 원하는대로 작동하는지를 보는 것을 확인이라고 한다.
그림 외우기
HIPO에 테스트 추가
화살이 날라가는 형태: Agile
소프트웨어를 개발하는데 정확하게 목표 (고객이 원하는 것) 만 적용
목표하는데로 만들어지느냐를 확인
종류가 시험에 많이 출제 된다.
익스트림, 스크럼, 린 ,DSDM, FDD
고객과 소통해서 제대로 만들어주자
익스트림: 격하게 움직이는 것, 아주 빠르게 양질의 소프트웨어를 만드는 것
핵심가치: 소통, 단순성, 피드백, 용기, 존중
익스트림 프로그래밍 절차
Spike (요구사항을 확인하기 위한 하나의 작은 프로그램)
User Stories (사용자가 어떤 것을 원하는지에 대한 것)
Release Planning (소프트웨어를 만들고 배포하는 과정 거기에서의 계획)
Splike (거기에서 요구사항이 계속 적용)
Iteration (최신버전까지의 요구사항을 계속해서 반복)
실제 적용이 되면 Small Realse (소규모로 적용해보는 것)
사용자가 실제 테스트에 참여를 해서 실제 내가 원하는 것인지를 알아보는 것이 반복된다.
테스트를 통해서 우리가 원하는 것이 만들어지는지를 테스트
작은 단위별로 실제 프로그램이 실제 실행할 수 있는 단위로 만들어내는 것을 의미 한다.
짝 프로그래밍: 한 사람은 개발하고 한 사람은 테스트
Planning Game: 게임처럼
Test Driven Development: 테스트 기반 테스트
Whole Team: 사용자가 팀에 속해야 한다
Continuous Integratoin: 지속적 통합, 하나를 무언가 만들어내면 걔네를 통합해서 실제로 배포할 수 있는 상태로 유지를 해야 한다.
Design Impovement: 기능 변경 없이 중복/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성을 수행
Small Realese: 작은 주기로 우리가 릴리즈를 한다. 우리가 고객에게 알려주고 변경사항을 확인한다.
Coding Standards: 표준 코딩 기법
Collective Code Ownership: 시스템에 소스코드는 팀의 모든 프로그래머가 누구든지 같이 볼 수 있다. 우리가 다 주인이다.
Simple Design: 최대한 간결하게 설계를 한다.
System Metaphor: 최종적으로 개발되어야 할 시스템의 구조를 기술한다.
Sustainable Pace: 일주일에 40시간 이상 작업 금지, 2주 연속 오버타임을 금지한다.
사람
문제
프로세스 (어떻게 처리할 것인가)
효과적으로 프로젝트를 관리하기 위한 요소
SCRUM: 요구사항을 빠르게 적용해서 빠르게 소프트웨어를 정확하게 개발하는 방식
제품 책임자: 개발 목표에 이해도가 높은 개발 의뢰자, 사용자가 담당, 기업의 경우 개발 담당자
스크럼 마스터: 개발팀의 마스터, 업무를 배분, 강요하지 않아, 장애 요소를 찾아서 제공, 훌륭한 감독 및 일정 정도를 알려주고 문제점이 있으면 해결해줌
스크럼 팀: 제품 책임자, 스크럼 마스터를 제외한 모든 팀원, 디자이너, 실제 코더, 5~9명 정도로 구성, 작업 단위로 분류해서 요구사항을 사용 스토리로 도출하고 일정 속도를 추정한 다음 제품 책임자에게 제시해서 이때 까지 끝날 것 같습니다 얘기를 하고 스프린트 결과물을 제품 책임자에게 시연을 한다. 매일 스크럼 회의에 참석해서 진행 상황을 점검을 하게 된다.
아침에 일어나는 스크럼 미팅. 3-40분 내에 모든 의사소통을 끝낸다.
SCRUM은 SPRINT라고 하는 과정이 계속해서 반복하는 형태
24시간에 한번씩 진행 상황과 완료된 것들을 확인
- 소멸차트: 작업해야 될 내용들을 목록으로 작성해 놓고 매일 매일 내가 한 일들을 소멸해나가는 형태로 진행을 해간다.
스프린트는 2~4주 정도가 진행이 된다.
현행 시스템 분석: 내가 소프트웨어를 개발을 할 거야 큰 그림을 그린다.
이 회사가 어떻게 굴러가는지를 확인
현행 시스템
어떤 일을 하는지, 어떤 컴퓨터가 설치되어 있는지, 어떤 인터넷을 사용하는지 쭉 보는 것을 의미
- 개발 범위 확인
- 이행 방향성 설정
현행 시스템 파악 절차
1단계: 시스템 구성 파악 (조직, 업무 흐름 파악, 부서의 기능 파악, 각각의 정보가 어떻게 주고 받는지 파악) "현재 시스템이 어떻게 운영되고 있는지"
2단계: 아키텍처 파악(설계도, 조직도), 그 안에서 설치되서 운영되고 있는 소프트웨어 구성을 파악 "설계도를 본다"
3단계: 실제 사용하고 있는 컴퓨터가 윈도우인지 매킨토시인지 그리고 각각 네트워크가 wifi로 되어있는지 근거리 통신망으로 되어있는지를 파악해주어야 한다. "하드웨어적 내용 & 네트워크적 내용을 본다"
시스템 아키텍처: 설계도
시스템 (조직) 에서의 각각의 구성과 서로 어떻게 움직이는지를 다 짜 놓은 것을 시스템 아키텍처라고 한다.
이 회사가 하는 일이 무엇인지 전체 프로세스를 알고 있어야 한다.
핵심적인 것을 파악한다.
시스템 전체의 구조나 행위 그리고 행위 원리를 나타내고 시스템이 어떻게 작동하는지를 설명하는 틀이다.
서로 상호 관계가 있다.
시스템 조직 내의 각각의 업무를 구분 파악
어떤 명칭, 어떤 기능들을 하는 것인지를 파악
문서화 -> 서로 공유 -> 소프트웨어를 개발 (목적 및 방법)
기간 업무: 중심 핵심 기능
지원 업무: 중심 핵심 기능을 지원하는 부서 분류해서 각각의 내용을 분석해서 문서화한다.
시스템 기능 파악: 각각의 시스템이 하는 기능별로 분류
인터페이스 현황 파악: 각각의 시스템이 서로 두 시스템 간의 연결을 해주어야 한다. 이를 인터페이스 현황 파악
실제 이 업무가 어떻게 진행되는지를 볼 수 있다.
EAI: 기업에 있는 모든 어플리케이션을 통합하는 형태를 우리가 이야기를 한다.
기업내에 다양한 소프트웨어가 있다. 이를 통합하고 조정하는 것을 목표로 만들어낸 도구다. 소프트웨어다.
FEP: 전위 처리기
앞쪽에서 처리. 입력 데이터를 프로세서가 처리하기 전에 미리 처리해서 프로세서가 처리하는 시간을 줄여주는 프로그램
소프트웨어 구성 파악: 내부에 있는 업무 시스템의 업무 처리용 소프트웨어의 품명, 용도, 라이선스 적용 방식, 라이선스 수를 명시
이름, 용도, 라이선스(돈주고 샀나, 언제까지 쓰는건지, 업데이트는 되는지)를 의미
시스템 구축시 많은 예산 비중을 차지하기 때문에 라이선스 적용 방식과 고유 라이선스 수량 파악이 중요하다.
예를 들어 서버를 하나 운영한다고 하면 서버에 사용되는 운영체제들은 단위가 1000단위가 넘어간다. 억단위가 넘어가기도 한다.
정확하게 파악한다.
하드웨어 구성파악: 하드웨어는 결국은 이 회사에 설치되어 있는 컴퓨터의 사양 또 서버가 이중화 되어 있는지를 보게 된다.
플랫폼: 기차 타는 칸, 기반 시설, 응용 소프트웨어와 하드웨어 시스템 소프트웨어 즉 내가 소프트웨어를 만들기 위한 기반을 의미
내가 건물을 짓는다고 하면 바닥을 의미한다.
소프트웨어 개발을 위한 바탕
플랫폼의 종류
IOS, JAVA, MacOS
현행 사용자가 요구사항을 통해서 시스템 성능 상의 문제를 리뷰하기 위해 플랫폼 성능을 파악을 해주어야 한다.
그리고 사용자가 느끼는 속도도 파악하고 개선 방안을 제시를 해주어야 한다.
응답 시간(얼마나 빠르게 반응하느냐), 가용성(이 시스템을 얼마나 쓸 수 있느냐), 사용률 (몇 프로나 쓸 수 있니)
플랫폼 성능 특성 분석 방법
- 기능 테스트: 현재 시스템의 각각의 기능을 부화를 주어서 테스트
- 사용자 인터뷰: 관리자가 있다. 현행 시스템 사용하는 사람들의 플랫폼을 분석할 수 있도록 인터뷰를 통한다
- 문서 점검: 이 회사는 어떤 플랫폼을 쓰고 있는지를 확인을 해서 비슷한 플랫폼의 기능 자료를 분석
현행 시스템의 운영체제 분석
- Android
- iOS
- UNIX
- LINUX
OS 종류와 버전, 패치 일자, 백업 주기 분석
고려사항: 가용성, 성능, 기술 지원, 주변기기, 구축 비용(TCO)
메모리 누수: 내가 지금 사용하는 메모리에 운영체제가 차지하고 있는 비율, 소프트웨어가 정상 종료되지 않고 남아있는 형태 즉 내가 어떤 프로그램을 종료했는데 이 운영체제는 걔네를 킬해주지 못해 이를 메모리 누수라고 이야기를 한다.
오픈소스: 공짜, 많다, 모든 소스가 공개
GNU: UNIX가 아니다. 리누스 토발즈가 3만줄의 LINUX를 개발 그리고 git을 만들어서 올리게 된다. 아얘 소스코드 부터 모두가 공개가 되어 있다. 나만의 운영체제를 만들 수 있다.
GNU GPLv1: 소스 코드를 공개하지 않으면서 바이너리만 배포하는 것을 금지, 소스코드 공개하라는 약관에 해당
BSD: 아무나 개작할 수 있고 수정한 것을 제한 없이 배포할 수 있다. 수정본의 재배포는 강제하지 않고 공개하지 않아도 되는 상용 소프트웨어에서도 사용할 수 있다.
Apache 2.0: Apache 재단에서 소프트웨어를 적용하기 위한 하나의 라이선스, HADOOP (다수의 저렴한 컴퓨터를 모아서 빅데이터를 처리하는 기술),
현행 시스템의 DBMS 분석
DBMS - 데이터베이스 관리 시스템
종속성과 중복성 문제를 해결하게 된다.
종속성: 어떤 하나의 필드가 다른 필드를 강제해서 끌고 다니는 것
중복성: 데이터가 똑같은게 두가지가 들어가 있다.
응용 프로그램과 데이터의 중재자로서 모든 응용 프로그램들이 데이터베이스를 공유할 수 있도록 중간 역할을 한다.
일종의 미들웨어
어떤 프로그램이 데이터를 관리할 때 DBMS를 통해서 관리하게 된다.
종류로는 Oracle, IBM DB2, Microsoft SQL Server, MySQL, SQ Lite, Mongo DB, Redis
DBMS 마다 접근하는 명령어가 차이가 날 수 있기 때문에 분석해준다.
가용성, 성능, 기술지원, 상호 호환성, 구축비용
요구사항을 어떻게 개발하는가?
개발에 상관 없으신 분들이 요구사항을 작성
이것을 끌어내는 것이 요구사항 개발
자료 흐름도, 자료 사전 등이 효과적으로 이용될 수 있다.
소단위 명세서로 구축
작은 단위별로 원하는 것을 세분화해서 요구사항을 파악하면 된다.
이해 관계자 사이의 원활한 의사소통 수단을 제공한다.
요구사항을 누락하는 것.
상호 이해의 오류
경제성을 제공 (요구사항을 추가하려면 비용이 많이 든다, 다시 부시고 다시 만들어야 한다)
요구사항 베이스라인(BaseLine, 기준선)
이해관계자 간의 협의에 의해서 기준선에 맞게 소프트웨어를 개발한다.
요구공학(개발) 프로세스
요구사항을 분석해서 검증하는 진행 순서
개발 대상에 대한 요구사항을 체계적으로 도출해주어야 한다.
도출된 요구사항을 분석해서 분석 결과에 명세서에 정리한다.
정리된 명세서를 마지막에 확인 검증하는 일련의 단계
경제성, 기술성, 적법성, 대안성 등 타당성 조사가 선행되어야 한다.
도출 -> 분석 -> 명세 -> 확인
소프트웨어가 해결해야 할 문제가 있을 것이다.
얘를 이해해야 하겠다
그리고 현재 상태를 파악해야 되겠지
문제를 정의한 후에 해당 결과의 목표를 명확하게 만들어내는 과정을 요구사항 도출이라고 이야기를 하겠다.
이해관계자: 소프트웨어 개발에 해당하는 팀에 모두 다
요구사항을 요청하는 고객도 포함
요구사항 도출 기법 (시험 기출)
고객의 발표, 문서 조사, 설문, 업무 절차 및 양식 조사, 브레인스토밍, 워크숍, 인터뷰, 관찰 및 모델의 프로토타입, Use Case, 벤치마킹, BPR(업무 재설계), RFP(제안요청서)
요구사항 분석
사용자 요구사항이 실제 무엇인지에 관한지를 걸러내는 것이 분석
요구분석을 위한 기법
사용자 의견 청취, 사용자 인터뷰, 현재 사용 중인 각종 문서 분석과 중재, 관찰 및 모델 작성 기술, 설문 조사를 통한 의견을 수렴한다.
요구분석 수행 단계
- 문제 인식
- 전개
- 평가와 종합
- 검토
- 문서
요구사항 분류
- 기술 내용에 따른 분류: 기능 요구사항(작동하는 것들), 비기능 요구사항(서포트 하는 것들)
- 기술 관점 및 대상에 따른 분류: 시스템 요구사항, 사용자 요구사항
요구사항 분류 기준
기능 요구사항, 비기능 요구사항으로 구분하고 우선순위 여부를 확인한다.
정형 명세 (정해져있다, 수학적 기반 모델링)
비정형 명세 (상태/기능/객체 중심 명세 기법, 자연어 기반)
요구사항 명세 속성 (시험기출)
정확성, 명확성, 완전성, 일관성, 수정 용이성, 추적성
요구사항 분석 단계를 거쳐 문서로 만들어진 내용을 확인하고 검증하는 단계이다.
일반적으로 요구사항 관리 도구를 이용하여 이해관계자들이 문서를 검토해야 하고 요구사항 정의 문서들에 대해 형상(Configuration)을 관리해야 한다.
회사의 표준에 적합하고 이해할 수 있는지 일관성이 있는지 완전하지 검증한다.
요구사항 관리 도구의 필요성(시험 기출)
요구사항 변경으로 인한 비용 편익 분석, 요구사항 변경의 추적, 요구사항 변경에 따른 영향 평가
형상관리
소프트웨어 개발 과정중에 나오는 모든 것들, 문서, 데이터, 자료 이런 것을 다 각각 다 형상단위라고 이야기를 한다.
요구사항 할당
각각 할당 어느 위치에 하는지
추가 요구사항을 발견할 수도 있다.
정형 분석
구문과 형식에 정의된 의미를 지닌 언어로 요구사항을 표현할 때 쓴다
정확하고 명확하게 표현하고 오해를 최소화할 수 있다.
요구사항 분석의 마지막 단계
프로토타이핑, 모델 검증, 요구사항 검토, 인수 테스트
시제품은 실제 보여줄 수 있기 때문에 요구사항을 도출하는데 아주 유용하다
회사는 미리 가지고 있다
이거를 보고 원하시는데로 조금 변경을 해서 보여드릴게요 이것이 바로 프로토타이핑이다
고객이 자료를 보면서 메뉴 위치를 바꾸세요 라든지 정확하게 파악할 수 있다.
요구사항 분석 단계 -> 프로토타입 설계 단계 -> 프로토타입 개발 단계 -> 고객의 평가 단계 -> 프로토타입 정제 단계 -> 완제품 생산 단계
모델 검증
분석 단계에서 개발된 모델의 품질을 검증한다.
모델: 각각 내가 개발하려고 하는 대상
- 정적 분석: 객체 모델에서 객체들 사이에 존재하는 Communication Path(의사소통 경로)를 검증하기 위해 사용한다. 명세의 일관성과 정확성을 확인 분석하는 도구이다. (문서화 처리, 코드 확인)
- 동적 분석: 직접 실행을 통하여 모델을 검증하는 방식이다. (실제 작동하는지 잘 되는지 안 되는지 본다)
인수 테스트
실제로 고객에게 전달을 하고 얘가 진짜 맞는지 안 맞는지를 확인을 한다.
계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타 검사, 사용자 인수 테스트, 운영 인수 테스트
연관관계: 소유
의존관계: 필요할 때만
UML 일반화 관계: 상속
UML 집합 관계
빈 마름모로 표시
점선은 or로 표시한다
인터페이스와 실제 구현한 일반 클래스 간의 관계를 의미
날다(인터페이스) <-> 파리, 미사일, 나방(실체화)
Use Case Diagram: 각각의 액터들이 어떤 행동을 하는지 도식화 한 것
시스템 경계: 각각의 시스템이 제공해야 하는 사례의 범위
액터: 서비스를 이용하는 외부 객체
유스 케이스: 시스템이 제공해야 하는 개별적인 서비스 기능
접속 관계: 일어나는 범위
사용 관계: 여러 개의 유스케이스를 공통이 사용되는 기능 모델링
확장 관계: 확장 기능 유스 케이스를 수행하는 경우
하나의 목적지를 보고 간다
소프트웨어도 이런 설계도를 보고 이용한다, 개발한다
소프트웨어 아키텍처가 구성이 되어야 할 때
충분히 우리가 원하는 것을 줄 수 있느냐
품질 요구사항이 있고 이것을 정의한 것이 ISO./IEC 9126 모델을 이용해서 등급을 정하고 평가할 수 있는 기준을 정한다.
외부지표: 대상을 기준으로 지표를 만듬
내부지표: 코딩, 설계 표준 품질을 평가한다
그림 출제
UI: 사용자 인터페이스, 사용자가 어떻게 시스템에 접근을 할 것인지
'정보처리기사 (필기) - 이기적 영진 닷컴' 카테고리의 다른 글
| [이기적 영진 닷컴] 정보처리기사 필기 핵심이론1과목-2(소프트웨어 설계) (0) | 2025.02.06 |
|---|