https://www.youtube.com/watch?v=HwgFOJ00S5I
요구사항 확인 -1

소프트웨어 설계 부분에서는 위에 3개, 즉 고객 요구/ 요구 분석/ 설계 파트를 공부할 것이다.


이번 시간에 공부할 것은 요구사항 확인 파트이다.


1. 플랫폼 기능 분석
플랫폼은 현재 사용하고 있는 소프트웨어.
현재 시스템이 사용하고 있는 소프트웨어의 기능 분석....
새로운 향후 개발된 소프트웨어를 바꿨을 때 어떤 가치가 올라가는가, 우리 회사의 매출이 올라가는가 이런것을 분석하는것이 6번이 된다.




운영 체제, DBMS, 미들웨어, 오픈소스 이 순서대로 지금 현재 사용하고 있는 시스템을 살펴볼 것이다.


기출 문제들을 보면, 운영체제 관련 고려 사항으로 맞지 않는 것은?
이런 식으로 잘 출제된다.
- 신뢰도, 성능, 기술지원, 주변기기, 구축비용



물론, 운영 체제가 사용자를 도와서 시스템을 제대로 하드웨어나 소프트웨어 resource들을 다 관리해주고 편하게 사용할 수 있도록 해주긴 하지만 그거 외에도 더 서비스를 추가 확장하여 제공해주기를 바랄 때 사용하는 소프트웨어

기출을 보면 미들웨어의 종류에 대한 문제들이 다량 출제됨
종류에 대해서 암기해야 함. 6가지 정도는 암기해주
1. RPC - 리모컨 생각하면 된다. 원격으로 떨어져있는 프로시저를 호출하는 시스템
2. MOM - message를 생각, 분산 응용 프로그램 간에 메세지를 주고 받으면서 데이터를 전달하고 교환할 수 있게 해주는 미들웨어
3. ORB - 객체들이 서로의 요청을 제대로 잘 수행할 수 있도록 중간에서 브로커 역할을 해줌
4. DB 접속 미들웨어 - DataBase에 연결해주는 미들웨어
5. TP 모니터 - transaction processing을 모니터 해주는 것
6. 웹 애플리케이션 서버(WAS)


비용을 지불하지 않고도 누구나에게 공개되어있는 오픈 소스

오픈 소스이다보니 비용을 지불하고 가져온게 아니라서 이 기술의 지속 가능성을 꼭 확인해야 함


각 상황의 니즈를 확인해서 운영체제 등을 선택해야 함


앞에서 여러가지 개발기술 환경을 수집했으면 이 것을 토대로 현행 시스템 분석서를 작성해야 함
그 분석에 너무 초점을 맞춰서는 안된다. 향후 구축될 시스템의 목적에 맞추어 적절한 범위를 선정해야 함

<예시 문항>




요구사항 확인 - 2


소프트웨어를 개발하는 그 과정도 사람처럼 생명력이 있는게 아닐까?
이렇게 주기를 만들어서 모델화를 했던 많은 방법론들이 있는데, 그 중 가장 전통적으로 유명한 모델이 바로 폭포수 모델이다. 근데 위의 단계와 크게 다르지 않다. 비슷함
단지, 여기 다른 곳으로 돌아가는 화살표가 없어짐
폭포수이기 떄문에 아래에서 위로 못 올라가고 요구사항 분석부터 유지 보수까지 보통 1년이 걸린다.
한 단계를 꼼꼼하게 끝내놔야 그 다음 단계를 갈 수 있음
마음에 들지 않으면 다시 처음부터 시작해야 함 -> 비용 많이 든다.

요구 사항을 취합을 해서 원형으로 설계함
우리가 보고 판단할 수 있는 원형을 빨리 만들어서 요구 사항을 조절할 수 있음

고비용의 시스템 개발에서는 중간에 무엇인가가 잘못되면 중간에 수정하기가 힘들다.
위험을 분산하기 위해서 나선형의 모델을 구현한다.
계속 저 1 ~ 4번을 반복해나감
소프트웨어 개발 방법론
- 소프트웨어를 어떻게 개발할 것인가에 대한 전체적인 큰 흐름과 더불어 각 단계에서의 방법과 활동들을 포함
- 보다 상세하고 구체적인 프로세스들의 집합

**도형 중심의 분석용 도구(자료 흐름도, 자료 사전, 소단위명세)를 이용함

자료 흐름도는 말 그대로 자료가 어떻게 흘라가는 지를 그림으로 표현한 것
알아야할 그림은 4가지이다.

위의 그림은 예시이다.
저 작대기 2개가 있는 것을 자료 저장소로, 상품대장이 들어있음

자료 흐름도에 나오는 용어들을 명확하게 정의해서 사전화시킨 것
이 기호들은 시험에 자주 출제되니까 기억하길

예시로 쓰면 이렇게 된다.
계산서를 정의했다. =
{ } 은 반복의 의미. [ ] 선택의 의미 저 중의 하나를 선택하라

이 중에서 적당하고 편리한 것으로 선택해주면 된다.

구조적 언어는 위와같이 사용한다.
프로그램 언어도 아닌 것이 그래도 읽어보면 뭐라고 하는지 알 것 같은 그런 언어
의사결정표는 O/ X와 같이 명확하게 나타내는 표
이 결정 표를 그림으로 나타내면 의사결정도라고 한다.

왼쪽 공간은 빼기 기호, 즉 제외했다는 것
오른쪽 공간은 더하기 기호, 즉 추가했다는 것
저 3가지는 빼고 옆의 3가지 항목은 추가하자는 뜻
최근 기출로 많이 나옴

특히 저 XP가 시험에 자주 나옴
XP : 의사소통 개선과 즉각적 피드백을 내세우는 방법론
5가지 가치에 해당하지 않는 것은? 이런 문제가 나옴



특히 저 짝 프로그래밍이 무슨 뜻이냐면
드라이버와 파트너 , 이렇게 2명이서 짝을 이뤄서 5분씩 계속 릴레이로 코딩하게 함
그리고 고객의 참여! XP의 실천사항 중 하나인데,
고객을 개발하는 동안 상주하게 함

객체지향 방법론에서 중요하게 생각하는 것은 '재사용'이다.
비슷한 기능을 하는 것들을 또만들고 하는 것보다는 그냥 재사용을 하자
UML : 표기법만이라도 통일하자

붕어빵 틀의 모양에다가 원하는 형태의 재료를 넣어서 만들면 같은 모양이지만 다 다른 붕어빵이 만들어진다.
이 공통 속성과 행위를 묶어 추상화한 개념(클래스)가 붕어빵 틀이 되고,
원하는 재료를 넣어서 재료를 찍어서 실제로 먹을 수 있는 형태로 만들어진 붕어빵 그 자체는 객체라고 볼 수 있다.
같은 메서드("운다")인데 오리는 꽥꽥 울고 닭은 꼬꼬우는 것처럼 똑같은 메소드인데 다르게 반응하는 것을 다형성이라고 한다.

시험에 자주 나옴
SOLID는 객체지향프로그래밍 및 설계를 하는 데 5가지 기본 원칙을 정한 것이다.
S : single
O : open/closed
L : 리스코프 *바꿀 수 있다
I : 인터페이스 *를 분리한다
D : 의존 관련

객체지향 방법론을 얘기한 여러 학자들의 방법론을 나타내면 위 표와 같다.
럼바우만이라도 기억하길.
이 순서대로 모델링 과정을 거치는데, 이 순서를 기억하면 좋을 것 같음
: 객체 모델링(객체 다이어그램) -> 동적 모델링 (상태 다이어그램) -> 기능 모델링 (자료 흐름도)
각 모델링에 따른 다이어그램도 알아둬야 함









'AI HW study > 정보처리기사' 카테고리의 다른 글
1. 요구 사항 확인 (1) | 2024.07.14 |
---|---|
매 시험마다 꼭 나올 것으로 예상하는 부분 (0) | 2024.07.14 |
기출+개념암기+코딩 (0) | 2024.06.28 |
정보처리기사 필기 - 제 1과목 - 소프트웨어 설계 핵심 요약 -2 (0) | 2024.02.12 |
정보처리기사(2020. 6. 6.) (0) | 2024.02.04 |