소프트웨어 공학 1주차 - 김범수 교수님

1. 소프트웨어 개발 패러다임의 전환

• 과거의 주먹구구식 개발:
  1970~80년대에는 간단한 프로그램을 빠르게 개발하는 방식이 주를 이루었으나, 하드웨어 제약과 낮은 복잡도 덕에 큰 문제가 없었음.
• 소프트웨어 위기와 변화의 필요성:
  1990년대부터 급증하는 소프트웨어 수요와 복잡도, 문서화 및 유지보수의 어려움 등으로 “소프트웨어 위기”가 대두됨.
• SW공학의 등장:
  체계적인 요구사항 분석, 설계, 구현, 테스트, 유지보수 및 품질 보증, 그리고 프로젝트 관리 등을 통해 고품질 소프트웨어를 저비용, 정해진 일정에 맞춰 개발할 수 있도록 가이드라인을 제시.

2. 개발자 vs. 엔지니어의 차이

• 개발자(프로그래머):
  주로 코딩에 집중하며 기능 구현에 치중하는 역할.
• 엔지니어:
  소프트웨어 개발 전 과정을 이해하고 프로젝트 관리, 문서화, 팀 및 리스크 관리 등 보다 폭넓은 역할 수행.
• 커리어 전환:
  초반에는 코딩 중심의 역할을 수행하더라도, 경력이 쌓이면 프로젝트 리딩 및 관리 역할로 자연스럽게 전환됨.

3. 단계적 프로세스 모델과 체계적 접근

• 요구사항 분석 → 명세화 → 설계 → 구현 → 테스트 → 유지보수:
  각 단계마다 산출물을 만들어내며, 이를 통해 체계적이고 예측 가능한 개발 프로세스를 구성함.
• 객체 지향 및 디자인 패턴:
  모듈 간의 결합도를 낮추고 응집도를 높여 유지보수와 재사용성을 개선하는 설계 원칙을 학습.
• 프로세스 모델 예시:
  예를 들어, 유튜브와 같은 동영상 공유 플랫폼 개발 과정을 통해 요구사항 정리, 디자인 문서 작성, 테스트 케이스 수립 등을 미리 준비하는 방식이 소개됨.

4. 품질 보증 및 프로젝트 관리

• 품질 보증 프로세스:
  각 단계별 산출물(요구사항 명세서, 설계서, 소스 코드 등)을 평가하여 품질을 확보하는 절차를 마련.
• 프로젝트 관리 모델:
  인력 배치, 리스크 관리, 일정 관리 등 PM(프로젝트 매니저)의 역할이 강조됨.
• 실무 적용:
  기업에서는 단순 코딩을 넘어 고객 요구 사항에 맞춰 체계적으로 프로젝트를 수행할 수 있는 능력을 요구함.

5. SI(시스템 통합)와 B2C 기업의 현장 이해

• SI 기업의 특징:
  • 프로젝트 기반: 고객의 RFP(제안 요청서)에 따라 사업 제안서를 제출하고, 사업 수행 계획서를 통해 실제 개발에 들어감.
  • 현장 변화: 팀 구성, 근무 장소, 근무 시간이 자주 바뀌며, 고객과의 소통 및 협업이 필수적임.
  • 리스크 관리: 예기치 않은 상황(예: 야간 긴급 호출, 서버 장애 등)에 대비해야 함.
• B2C 기업:
  • 내부 개발: 자체 제품(예: 네이버, 카카오 등)을 개발하며 안정적인 업무 환경과 명확한 커리어 패스 제공.
  • 인재상: 단순한 개발 경험을 넘어서, 문제 해결 능력과 기술 한계를 인지하고 이를 극복할 전략적 역량을 중시.

6. 제안 요청서(RFP)와 사업 제안서 이해

• RFP의 역할:
  발주처가 프로젝트에 대해 요구사항, 기간, 예산 등을 명시한 문서로, 이를 기반으로 IT 기업이 제안서를 작성하여 경쟁을 벌임.
• 사업 제안서 작성:
  기업은 실제 수행 계획과 비용, 기술력을 어필하는 문서를 제출하며, 이 과정에서 실무 경험과 전략적 사고가 필요함.
• 실제 사례 학습:
  교수님은 조달청 나라장터의 RFP 예시를 통해 실제 제안서 작성 및 평가 프로세스를 설명하며, 이를 통해 창업이나 취업 시 실무 대응 능력을 강조함.

7. 전략적 포트폴리오 준비의 중요성

• 문제 해결 능력 강조:
  단순히 앱 개발 경험을 나열하는 것보다, 기술의 한계를 정확히 인지하고 이를 극복하기 위한 구체적 접근법과 해결 사례를 보여주는 것이 중요함.
• 포트폴리오 구성:
  • 다양한 프로젝트 참여: 팀 프로젝트, PBL, 개인 프로젝트 등 여러 경험을 통한 문제 해결 사례 포함.
  • 실무 중심의 전략: SI, B2C 등 자신이 목표하는 기업의 인재상에 맞추어 포트폴리오를 구성할 필요가 있음.

 

수업 스크립트 :

시작하기 전에 추석 먼저 한번 불러볼까요?

아침 9시 수업이라 다들 표정이 멋지네요. 출석 문자 한번 들어보고 시작하도록 하겠습니다

-이름 생략-


저희가 저번 주에 원래 오리엔테이션을 했어야 되는데 빨간 날이라 못했죠.
그래서 이번 시간에 보강 대신에 1주 차와 2주 차 강의를 연달아서 할까 합니다.
뭐 하는 것보다 그게 낫죠. 간단하게 오늘은 가볍게 들을 만한 내용으로 준비했으니까 이렇게 부담 가지실 필요는 없고요.
제 소개 먼저 하자면 저는 김범수라는 사람이고요.
파이 학습 및 IoT AI 운영 등 네트워크 분야에서 연구를 진행을 하고 있고요.
연구실 홈페이지는 이러니까 저 관심 있으신 한번 구경하는 것도 괜찮을 것 같습니다.
그리고 학점 부여 원칙인데 강의 자료는 다 다운로드 받아 보셨죠?
이미 보셨을 것 같긴 한데 상대평가 원칙 적용 당연하죠.
하지만 두 개의 분만 통합 평가라는 것이 좀 이해 안 될 수가 있습니다.
수강 신청을 하실 때 보셨겠지만 이 소프트웨어 공학이라는 항목이 1분 반 2분 반이 있습니다.
그래서 각각 수강생들이 401명 되는데요.

그래서 각 중반마다 상대 평가를 적용해서 평가를 할 수도 있지만 두 개의 분반을 통합해서 평가를 하면 좀 더 공정하게 학점을 부여할 수 있을 것 같아서 제가 이렇게 하기로 계획을 했습니다.
어떤가요? 원래 같으면 41명 간의 상대평가를 통해서 a 학점 몇 퍼센트 b 학점 몇 퍼센트 c 학점 몇 퍼센트 제가 다 주고 싶다고 줄 수 있는 구조가 아니고 누군가는 c를 받아야만 하는 그런 구조가 되는데 두 개의 운반을 통합 평가하면은 모수가 82명으로 증가하게 되겠죠.
그러면 내가 a 분반에서는 원래 같으면 b 학점을 받아야겠지만 통합 선플라드는 a 학점을 받을 수도 있습니다.
반대로 나는 b 학점을 받을 수가 있었는데 통합 평가를 하다 보니까 상대적으로 더 고쳐서 더 순위가 내려가서 c 학점을 받을 수 있다는 거죠.
하지만 부자보다는 전자인 경우가 좀 더 많더라고요.

그래서 두 개 분반을 통합 평가하는 것이 여러분들한테 좀 더 열심히 한 분들한테 좀 더 유리할 것 같다고 판단이 들어서 두 개의 등반 통합 평가를 하기로 결정을 했습니다.
여기에 대해서 이의 사항 있나요? 다른 의견 있으면 이메일로 연락 주시면 제가 이번 주 동안 고민을 한번 해보고 다음 주에 알려드리도록 하겠습니다.
별일 없으면 이대로 진행해도 괜찮겠죠? 열심히 하시면 됩니다.
아무런 문제가 없습니다. 고평가 방식은 중간고사가 30% 이게 자꾸 다 걸리네요.
기말고사가 40% 출석이 10% 과제가 20%입니다.
중간고사와 기말고사를 30과 40으로 차등 조정한 이유가 있는데요.

왜 10% 차이를 뒀을까요? 중간 30 기말 40 중간이 좀 더 퍼센트가 낮은 이유가 뭘까요?
보통은 중간고사 때 시험을 망치면 기말고사 때까지 그 동기 부여까지 안 가더라고요.
중간에 좀 못 치더라도 좀 더 열심히 해서 이 말을 잘 치면 성적이 그런 의미에서 10%를 조금 차등을 두었습니다.
출석은 10%고요. 과세가 20%인데 팀 과제일까요?
개인 과제일까요?

사실 어느 정도 조사를 사람 뽑으신 거 아닌가요? 이 교수는 팀 과제를 한다 개인 과제를 한다 팀 과제 하고 싶으신 분 있나요?
혹시 같이 이렇게 3명씩 딱 하면 딱 좋을 것 같은데 개인 과제를 했으면 좋겠다.
손 한번 들어보시죠. 팀 과제를 했으면 좋겠다. 전화 한번 들어보시죠.
개인 과제로 하겠습니다. 팀 과제 제가 한번 해봤는데 여기 겪어보신 분도 있을 거예요.
근데 너무 괴로워하셔가지고 여러분들이 굳이 여러분들을 괴롭힐 이유는 없잖아요.
그쵸? 과제도 크게 부담스러운 과제는 내지 않을 거고요.
최대한 시험에만 여러분들 집중할 수 있도록 그리고 강의 내용을 좀 더 숙지할 수 있는 방향으로 과제를 내려고 합니다.
괜찮죠? 그리고 이제 본격적으로 저번 주에 못했던 오리엔테이션을 한번 진행을 해 보고자 하는데 이 강의가 뭔지 한번 설명을 드리고자 합니다.
소프트웨어 개발은 개발이지 소프트웨어 공학이라는 말은 여러분들이 접해보지 못한 개념이죠.

이 소프트웨어 공학을 이해하려면 이 프로그래머와 엔지니어의 차이를 이해하면서 시작을 하는 게 좋을 것 같다.
개발자 프로그래머라고 하죠. 개발자는 뭐고 엔지니어는 뭘까요?
그 차이점을 아시는 분 따로 대답은 잘 안 하실 것 같긴 하지만 먼저 말씀드리면 프로그램을 개발자 다 그런 건 아니지만 단순히 코딩에 머무는 사람이라고 볼 수가 있어요.
엄청 고급 개발자는 여기에 해당되지 않겠지만 일반적으로 엔지니어의 개념이 없는 사람들은 다 초급 개발자 프로그래머라고 할 수가 있겠죠.
반대로 엔지니어는 소프트웨어 개발 모든 작업의 과정을 다 이해하고 프로젝트를 이끌어 나갈 수 있는 그런 프로젝트 매니저 역할을 충실히 수행할 수 있는 사람을 엔지니어라고 합니다.
여러분들이 보통 it 컴퓨터 공학을 전공을 하게 된다면 개발자로 시작을 하게 되겠죠.
그리고 여러 가지 학부 프로젝트를 거치고 취업을 하게 된다면 여기서 또 함께 회사마다 다른 프로젝트를 수행을 하게 되겠죠.

다양한 개발 프로젝트를 수행을 하고 거기서 얻은 경험을 바탕으로 더 나은 회사로 이직을 하면서 자연스럽게 여러분들이 엔지니어로 거듭난다고 볼 수가 있겠어.
엔지니어란 간단하게 말해서 프로젝트 관리, 인력 관리 그리고 문서 작업 등등을 다 할 수 있는 사람인데 보통은 엔지니어에 가까워진다면 나이가 점점 늘어간다는 것이고 30 중후반만 되더라도 여러분들은 개발을 할 가능성은 거의 없습니다.

거의 없어요. 개발을 40 50대까지 할 것 같죠.
하지만 그런 가능성은 거의 없고 여러분들이 팀장급이 되면 프로젝트를 이끌어 나가야 될 그런 관리자의 역할을 하게 되지 개발로서의 뭔가 나의 역량을 계속해서 키워나가기는 구조적으로 어렵다고 볼 수가 있습니다.
뒤에 나올 거긴 하지만 여러 가지 서비스 기업이겠죠.
네카라 쿠에 가시면 순수 개발자로서의 뭔가 커리어를 계속해서 쌓을 수는 있겠지만 일반적인 it 기업에 가게 된다면 여러분들은 실어드 엔지니어의 역량을 갖게 될 것이고 개발 능력은 점점 퇴화하게 된다라는 것이 기본이 되겠습니다.
그러면 이 소프트웨어 공학이라는 과목은 이 엔지니어가 되기 위해서 필요한 여러 가지 요소 기술들을 소개하는 강의라고 볼 수 있겠습니다.
그래서 중간고사 이전까지는 다소 테크니컬한 측면을 다루지는 않아요.
문서화를 어떻게 하고 프로젝트를 어떻게 이끌어 나갈지 그런 관점에서 강의를 진행하기 때문에 굉장히 재미가 없을 겁니다.

하지만 중간고사 이역은 프로그램 프로젝트 설계 및 구현 관점에서 약간은 테크니컬한 부분이 들어갑니다.
그래서 기말고사 준비는 좀 재미있을 수 있겠지만 중간고사 때까지는 조금 재미가 없으셔 보겠다.
미리 밑밥을 조금 깔아보고요. 어쨌든 여러분들이 일반적인 it 기업에 들어간다 치면 데다 코딩을 하는 것이 아니라 설계라는 것을 보통합니다.
설계도가 있어야 개발을 할 수가 있겠죠. 설계 이전에 또 명세화라는 걸 합니다.
이 명세화라는 것을 문서 작업이라고 볼 수가 있어요.
대표적인 문서로는 뭐가 있을까요? 프로그램을 내가 개발하고 싶은 프로그램을 개발한 용어는 없습니다.
보통 it 회사에서는 발주처가 있고요. 고객이 되겠죠.
고객이 원하는 프로그램을 개발해 주고 돈을 지급받는 구조를 따르기 때문에 고객이 원하는 프로그램의 요구 사항이 있을 겁니다.
그 요구 사항을 명세화하는 것이 요구 사항 명세서라는 것이고요.

그것을 기반으로 디자인 명세까지 하고 등등의 문서 작업을 거쳐서 설계에 들어간다는 것이죠.
설계도가 나와야 코딩이 들어가게 되고요. 코딩을 완료하면 끝나는 것이 아니라 테스트를 해 봅니다.
원하는 대로 개발이 잘 됐는지 테스트를 해보고 문제가 없다 그러면 고객한테 프로그램을 건네주게 되고요.
거기서 끝나는 것이 아니라 유지 보수를 해줍니다.
사용하다가 터지는 버그들 그리고 기능적인 추가 사항들이 있다고 하면 유지 보수 작업을 통해서 계속해서 서비스를 제공해 주게 되는 것이죠.
여기서 끝나는 것이 아니라 또 추가적인 요구 사항이 나오면 또 요구 사항 업데이트를 하고 명세화를 해서 또다시 설계를 하고 코딩을 하고 이것이 소프트웨어 개발에 큰 주기라고 볼 수가 있겠습니다.
여러분들은 지금 내가 원하는 프로그램만 개발하고 있죠.
내가 스스로 프로그램을 기획을 해서 개발을 하게 되는데 실제로 취업을 하게 된다면 그럴 가능성은 없죠.

고객이 갑이다 갑을 견디면서 여러분들이 개발을 해야 된다 라는 것이 되겠습니다.
그래서 이러한 개발 주기가 지금은 자리 잡혔지만 예전에는 이런 곳이 없었어요.
주먹구구식 개발이라고 했습니다. 그냥 내 딴 비주얼 스튜디오를 켜서 메인 하나 만들고 프로그램을 개발해도 큰 문제가 없던 시절이었습니다.
1970년대에는 하드웨어 PC 장비가 그렇게 좋진 않았겠죠.
그에 맞춰서 프로그램도 크게 복잡도가 없었습니다.
라인 수가 기껏 해봐야 1만 라인 넘어가지 않았죠.
그래서 그냥 그때그때 맞춰서 개발을 해도 큰 문제가 없었습니다.
하지만 PC 사용이 점점 증가하고 그에 맞춰서 소프트웨어도 점점 복잡해지고 사용자들의 요구 사항도 점점 늘어나게 됐습니다.
그렇게 하니까 네 가지의 어려움이 등장을 하게 된 거죠.
1990년대 그래서 일단 문서화에 어려움이 있습니다.
체계적으로 문서를 어떤 식으로 만들지에 대한 가이드라인이 없었죠.

요구사항 명세서는 어떤 식으로 만들지, 설계도는 어떤 식으로 명세를 할지 기준이 없었기 때문에 회사마다 다 다른 규정이 있었어요.
그렇게 되면 어렵겠죠. 남의 문서 보는 것도 어렵고 어떤 식으로 문서를 작성해야 될지도 모르기 때문에 너무 더럽게 문서 작업이 진행됐다고 볼 수가 있겠습니다.
첫 번째 문서화의 어려움이 있었고요. 두 번째는 재사용에 어려움이 있습니다.
재사용이 어렵다는 게 뭘까요? 남이 짜놓은 코드 그대로 가져와 가지고 내가 그대로 사용할 가능성이 있을까요?
잘 짜진 라이브러리 헤더 파일을 가져올 수가 있지만 그런 경우가 아니고 보통 a 프로젝트에서 만든 모듈을 b 프로젝트에서 가져와서 그대로 이식해서 사용할 수 있는 가능성은 거의 없다고 보시면 되겠습니다.
특히나 주먹구구식으로 개발했던 1900년도 후반 대에는 프로그램 코드의 재사용성이 거의 없다고 세 번째로는 예측의 어려움인데요.
이거 뭘까요?

프로그램 개발할 때 예측이 점점 어려워진다라는 것이 지금은 당장 필요한 프로그램인데 1년 뒤에는 이 프로그램이 더 이상 의미가 없을 수가 있다.
더 이상 판매가 안 될 수도 있다. 예측이 어렵죠. 네 번째로 유지 보수의 어려움 남이 짜놓은 코드 해석하고 그걸 다시 디팩토링해서 개발하는 게 정말 어렵겠죠.
프로그램의 복잡도가 올라갈수록 유지 보수가 점점 어려워진다고 볼 수가 있겠습니다.
어쨌든 개발 작업에 이 네 가지 어려움 프로그램의 복잡도가 올라가면서 점점 더 어려워진다는 것이죠.
소프트웨어 보안이 없었던 190 연도 후반 대에는 개발이 점점 어려워지고 그것을 우리는 소프트웨어 위기라고 불렀습니다.
소프트웨어 수요가 급격히 증가하고 있는 반면에 개발 수준은 계속해서 낮은 수준으로 머물러 있다는 것이죠.
그래서 점점 더 고객의 요구 사항이 증가했고요. 그에 맞춰서 프로그램의 복잡도도 증가를 하게 되고 난이도도 점점 증가하게 되겠죠.

프로그램의 규모가 커지기 때문에 하지만 맨날 같은 인력으로 같은 주먹구구식 방법으로 같은 도구를 사용을 해서 개발을 하다 보니까 개발이 안 된다는 거야.
이게 소프트웨어 위주가 되었어요. 그래서 나온 것이 소프트웨어 공학 이론이다.
그래서 소프트웨어 공학의 접근법은 즉흥적인 소프트웨어 개발의 문제를 극복하고자 나온 겁니다.
과거에는 지금 여러분들이 웬만하면 이런 방식을 따르고 있겠죠.
보통 과제가 나오거나 내가 개발하고 싶은 프로그램 주제가 있어 그러면 일단 내 다 비주얼 스튜디오 키고나 리플리스 키죠 vs 코드 키죠.
메일 하나 만듭니다. 그리고 짜고 실행해 보고 만족할 때까지 수정을 해 봅니다.
그리고 개선을 위한 아이디어를 짜내보고 다음 날 아침에 이렇게 한번 해보자 하고 다시 물어봐서 만족할 때까지 수정을 하죠.
이것이 즉흥적인 소프트웨어 개발이라고 합니다.
다들 그러진 않겠지만 이런 구조를 따랐던 적이 있었죠.

하지만 이렇게 한다면 네 가지 위기 사항이 같이 만나는 것이 되겠죠.
그래서 소프트웨어 공학은 이 소프트웨어 개발의 위기를 극복하기 위해서 소프트웨어 개발의 운영 유지 보수 소면에 대한 체계적인 가이드라인을 제공해 주는 상품이라고 보시면 되겠습니다.
그래서 개발에 사용되는 방법이 일회성이 아니라 재사용에 초점을 맞춘 그런 공항이라고 보시면 되겠습니다.
구체적으로 사용자 요구는 어떤 식으로 분석을 할지 가이드라인을 제시를 해 주고요.
그리고 요구 사항 분석을 통해서 요구 사항 명세서를 어떻게 사용, 어떤 목차를 가지고 작성을 할지에 대한 가이드라인도 제시를 해 줍니다.
거기서 끝나는 것이 아니라 요구 사항을 기반으로 설계는 또 어떻게 하면 좋을지 가이드라인을 제시해 주고요.
설계도를 기반으로 구현은 또 어떤 식으로 하면 좋을지 그것조차도 알려주고 있습니다.

그리고 개발이 끝나면 테스팅은 또 어떤 식으로 하면 좋을지, 품질은 어떤 식으로 보증을 하면 좋을지, 프로젝트 매니저라고 하면 프로젝트를 어떤 식으로 이끌어 나가면 좋을지, 인력 관리는 어떻게 할지, 리스크 관리는 어떻게 할지 이런 모든 것을 다 가이드라인을 만들어 놓고 제공을 해 주는 학문이 소프트웨어 공학이라고 보시면 되겠죠.
그래서 중간고사 이전까지는 설계 이전까지의 단계를 한번 다뤄보고자 합니다.
중간고사 이후부터는 설계를 어떤 식으로 하면 좋을지 나눠보게 될 텐데 객체 지향 방법론을 기반으로 다뤄보고자 합니다.
대충 어떤 강인지 느낌이 오시죠? 소프트웨어 공학의 목표는 세 가지가 있습니다.
어찌 됐건 간에 이 모든 작업을 하는 이유는 고품질의 소프트웨어를 최소의 비용으로 저비용으로 계획된 일정 데드라인에 맞춰서 개발을 하게끔 가이드라인을 제시해 주는 것이 소프트웨어 공학이다.

어쨌든 it 회사 입장에서는 최소의 비용으로 데드라인에 맞춰서 고객이 원하는 고품질 소프트웨어를 개발을 하는 것이 목표가 되기 때문에 이 소프트웨어 공학이 반드시 적용이 된다라고 보시면 되겠죠.
그래서 이 오리엔테이션이 끝나기 전에 소프트웨어 공학의 대표적인 소재 세 가지에 대해서 간략하게 리뷰를 하고 넘어가도록 하겠습니다.
크게 소프트웨어 공학은 세 가지로 나눌 수가 있는데요.
토픽이 첫 번째로 단계적 프로세스가 있습니다. 이 단계적 프로세스는 앞서 말씀드린 대로 주먹 공구식 개발에서 벗어나기 위해서 나온 프로세스 모델이라고 보시면 되겠는데요.
코딩에 집중하지 않고 맵다 코딩을 하는 것이 아니라 사용자의 요구사항 분석부터 그를 기반으로 프로그램 설계 구현, 테스팅 유지보수까지 단계를 나눠서 체계적으로 개발하도록 만든 프로세스 모델이 단계적 프로세스라고 볼 수가 있겠습니다.
대표적으로 포커스 모델, 에자일 모델 등등이 있는데요.
차차 이 단계적 프로세스에 대해서 다뤄보고자 합니다.

이걸 여러분이 숙지하시면 입사를 하시면 회사에 입사를 하시고 이 프로세스를 따르게 될 겁니다.
그러면 이때 배웠던 내용이 당시에는 잘 이해가 되지 않더라도 기억을 한번 되어보고 이때 이런 것을 배웠었지 정도만 떠올려도 성공이라고 봅니다.
두 번째로는 품질 보증 방법이 있는데요. 이 단계적 프로세스마다 산출물이 있습니다.
첫 번째로 요구사항 분석이 끝나면 요구 사항 명세서가 나오겠죠.
설계 단계가 끝나면 설계사로 나올 겁니다. 코딩이 끝나면 소스 코드가 나오겠죠.
이런 단계별의 산출물들을 어떤 식으로 평가를 하고 잘 됐는지 잘 도출되었는지 품질을 평가하는 프로세스도 있습니다.
이것이 품질 보증 프로세스 모델이라고 하는데요.
본 강의에서는 이걸 다루지 않을 겁니다. 이거는 뭐 산출물이 있어야 우리가 평가를 할 수 있겠죠 이런 것이 있다고만 여러분들이 기억을 하시면 되겠고요.
마지막으로 소프트웨어 공학에서는 프로젝트 관리 모델도 제공해 준다고 했었죠.

PM 입장에서 주어진 시간 동안 고품질의 프로그램을 저비용으로 개발할 수 있도록 인력을

자원 프로젝트에서의 자원은 인력이죠. 개발자들을 어떤 식으로 잘 배치를 해서 개발 도중에 마주할 수 있는 리스크를 미리 식별하고 미리 대응을 하게 되는 거죠.
그리고 프로젝트가 잘 계획대로 수행되고 있는지 모니터링 하는 여러 가지 방법들을 소프트웨어 공학에서 제공을 해 주고 있습니다.
여러분들 팀장 역할을 수행을 하고 있을 수도 있죠.
지금 다양한 PBL 수업이라든지 팀 프로젝트를 수행을 할 때 팀장 역할을 수행하는 학생도 지금 분명히 있을 거라고 봅니다.
팀장 입장에서 이런 기법들을 잘 배워놓으면 당장 써먹을 수도 있겠죠.
어쨌든 중간고사 이전까지 이 프로젝트 관리 방법과 단계적 프로세스 모델을 따라가면서 여러분들에게 차차 소프트웨어 공학을 알려드리고자 합니다.
이 소프트웨어 공학은 컴퓨터 공학 및 과학뿐만 아니라 다양한 도메인들이 합쳐진 학문이라고 보시면 되겠습니다.

지금 여러분들은 컴퓨터 및 공학 및 과학만 집중을 하고 있다면 소프트웨어 공학을 배우게 된다면 프로젝트 관리 방법도 알아야 될 것이고 시스템 공학, 품질 관리, 응용 도매, 경제학, 수학 이런 등등의 학문들이 다 합쳐진 과목을 배우신다고 보시면 되겠습니다.
이고 소프트웨어 공학에 지금은 여러분들이 컴퓨터 과학 이론과 컴퓨터 비능 테크니컬한 부분에 대해서 학습을 하고 있지만 취업을 하게 된다면 고객 이죠.
고객이 없으면 우리는 필요가 필요가 없는 건 아니죠.
개발자들이 일을 잃어버릴 수가 있겠죠. 항상 고객이 있어야만 합니다.
고객이 말하는 문제 요구 사항이 되겠죠. 이 요구 사항들을 잘 개발할 수 있도록 서구 공항에서 제시를 합니다.
끝나기 전에 이 단계적 프로세스가 있다고 했었죠.
이 소프트웨어 개발을 위한 단계적 프로세스의 예시를 한번 들어보고 오리엔테이션 끝나고 2주 차 만기로 넘어가도록 하겠습니다.

대표적으로 이 유튜브 동영상 공유 플랫폼을 여러분들이 개발한다고 가정을 해 봅시다.
좀 더 구체적으로 여러분들이 어떤 회사 a에 몸 담아 있고 그 회사에서 유튜브를 따라잡을 수 있는 동영상 공유 플랫폼을 한번 개발해 보자라고 나온 상황입니다.
그러면 요구 사항을 정리를 해야 되는데요. 일단 구체적으로 고객은 없습니다.
고객이 없는 상황에서 요구 사항을 일단 이제 회의를 통해서 뽑아낸다는 상황이죠.
일단 요구 사항을 정리를 해야 되는데 어떤 기능을 넣을지, 영상 길이 제한 플랫폼 이름 모바일 웹으로 개발할지 사용자 메신저 기능을 어떻게 넣을지 등등 기능적 요구 사항과 품질 요구 사항들을 잘 도출을 해서 요구 사항을 정리를 하게 됩니다.
그리 요구 사항 정리가 끝나면 개발에 들어간 것이 아니라 일단 디자인도 중요하죠.
프론트를 어떤 식으로 짧지 또 회의를 해봅니다.

그래서 왼쪽 상단 유튜브 버튼을 누르면 초기 페이지로 돌아가도록 설계를 할 것이다 등등 그리고 이미지 버튼을 누르면 검색창 버튼을 누르면 어떤 식으로 기능이 수행될지 그런 디자인 문서도 먼저 정리를 한 다음에 그리고 여기서는 테스트 케이스까지 함께 정리를 해 왔습니다.
개발이 잘 됐는지 확인하기 위해서 검색 버튼을 눌렀을 때 어떤 화면이 떠야 되는지 안 뜨면 에러 잘 뜨면 성공 이런 식으로 테스트 케이스까지 미리 정의를 해놓게 되죠.
그리고 나서 개발에 들어가는 것이 아니라 또 회의를 합니다.
개발 환경은 어떤 식으로 짧지, 프론트는 어떻게 할지, 백엔드는 어떻게 할지, 공유 작업 환경은 뭘로 할지 이런 식으로 다 회의를 거쳐서 개발에 들어가냐 아닙니다.
요구사항 명세서라는 걸 만듭니다. 그리고 디자인 요구서 이런 명세화를 다 한 다음에 개발에 들어갑니까?
안 갑니다. 또 설계를 해야 되죠.

이 명세화된 문서를 기반으로 설계를 해야 되는데 대표적으로 이 설계에 사용되는 방식이 방법론이 객체 지향 방법론이라고 보시면 되겠습니다.
중간고사 이후로 이제 객체 지향 방법론에 대해서 잘 다뤄보게 될 텐데 기존 프로그램을 여러분들이 개발할 때 메인 문 하나로 개발을 할 수도 있지만 기능이 좀 더 조금만 더 들어가게 된다면 새로운 파일로 쪼개서 헤더 파일을 만들고 메인에서 지금 헤더 파일을 불러들여서 조립을 해서 프로그램을 만들고 계시죠.
이것이 모듈화 프로그래밍 방식이라고 합니다. 여러분들이 은연 중에 했던 방식을 명명하자면 모듈화 프로그래밍 방식인데요.
기능별로 n개의 모듈 즉 헤더 파일로 쪼개서 메인 문에서 그것을 불러들여서 조립해서 만든 방식을 모듈화라고 한다면 이 모듈 간의 결합도를 낮추고 응집도를 올려야 된다는 것이 이 모듈화 프로그램의 기본 방식이 되겠습니다.

그럼 설계를 할 때 어떻게 하면은 응집도를 높이고 모듈 간의 결합도를 낮출지 잘 가이드라인을 제시해 놓은 것이 디자인 패턴이라고 합니다.
여러분들은 이 디자인 패턴을 잘 알아야만 설계를 잘할 수가 있다고 보시면 되겠죠.
창의력은 아무것도 없는 상태에서 나오지 않습니다.
여러분들이 이 디자인 패턴을 잘 숙지해야만 설계를 할 때 아 이 패턴을 적용해서 설계를 하면은 효율적이겠구나라는 생각이 들 겁니다.
그래서 최대한 여러분들한테 이 디자인 패턴을 소개하고 설계 능력을 키울 수 있도록 도와드리고자 합니다.
어쨌든 이렇게 체 지향 방식을 이용해서 디자인 패턴을 적용해서 설계까지 끝나게 된다면 비로소 개발에 들어가게 되는데요.
개발은 실제 개발 시간이 100시간이라 하면 20시간도 되지 않을 겁니다.
다 명세화와 설계 시간에 시간이 다 들어간다고 보시면 돼요.
그렇습니다. 그리고 개발이 끝나면 테스트를 하죠.

UN 테스트 통합 테스트 등등이 있는데 어쨌든 뭐 테스트 방식은 이 시간에 다루진 않을 겁니다.
그래서 블랙 박스 테스트, 화이트 박스 테스트 등등이 있는데 이런 것들은 이런 것이 있다고만 여러분들이 생각을 하시면 되겠고요.
테스트까지 끝나면 출시를 하게 되겠죠. 이것이 소프트웨어 공학을 적용한 프로그램 개발 한 사이클이라고 보시면 되겠습니다.
여기서 요구 사항이 바뀌면 다시 명세화를 해서 설계해서 구현을 하게 되겠죠.
이것이 소프트웨어 공학이다. 이것이 오리엔테이션 잠깐 쉬었다가 이제 2주차 강의로 넘어가게 될 텐데 질문 있나요?
평가 방식이라든지 소프트웨어 공학 팀 과제 하고 싶다 등등 다양한 의견도 괜찮습니다.
의견 한번 받고 짧게 한 10분만 쉬었다가 이 숫자 강의에 들어가도록 하겠습니다.

없나요? 없으면 지금이 32분인데 40분까지만 쉬었다가 이제 2주차 강의로 들어가도록 하겠습니다.

 

(일부 녹음 빠짐)

그렇기 때문에 여기를 목표로 한다면 취업의 기회가 늘어나는 것이고 그에 맞춰서 취업의 확률도 올라가겠죠.
그리고 팀원뿐만 아니라 사업 발스처와 지속적인 의사소통이 불가피합니다.
밤 10시에 전화 옵니다. 서버 터졌다고 새벽 2시에 개발자한테 올 수도 있어요.
여러분들이 프로젝트 매니저라고 하면 이 과정에서 다양한 사람들과 의사소통이 불가피하다.
지금 여러분들 팀 과제 한번 해야 될 되지 않겠어요?
미리 사람들과 소통하는 방법 아무것도 모르는 사람이야.
일면식도 없는 사람이랑 싸움을 하려면 지금 여러분들이 이 스트레스에 익숙해져야 되는데 여기서 하지 않겠습니다 걱정하지 마시고 다양한 환경에서 다양한 프로젝트 경험을 할 수가 있습니다.
제가 아까 말했죠. 개발 프로젝트 이외에도 유지보수 솔루션 개발 등의 다양한 팀의 회사에 존재합니다.
개발팀만 있는 것이 아니라 다양한 그런 서드 디파트먼트가 있기 때문에 업무에 대한 선택 폭이 넓습니다.

처음에는 SI 업체가 좀 브로드하게 고용을 합니다.
채용을 합니다. 거기서 뽑아놓고 필요한 부분에 배치를 하죠.
여러분들이 개발 업무 하는 줄 알았는데 유지보수팀에 갈 수도 있고요.
다양한 내가 원하지 않는 그런 부서에 배치될 가능성도 매우 높습니다.
회사는 여러분들 그냥 부품 하나라고 생각하기 때문에 여러분들 다 개발하고 싶어 한다고 그쪽에 넣어주지 않아요.
그래서 이걸 좀 좋게 포장하자면 업무에 대한 선택 폭이 넓다 라고 보시면 되겠습니다.
하지만 재수가 없으면 내가 하고 싶지 않은 업무에도 배치될 수가 있다.
장점과 같은 단점은 다 얘기했지만 명확한 단점도 있습니다.
아까 말했다시피 갑을 관계가 명확하죠. 갑을병정까지 내려갈 수가 있습니다.
그리고 출근 환경이 매우 주기적으로 바뀔 수가 있습니다.
파견을 매우 많이 나가요.

어떤 업체 a가 프로젝트를 발주하였고 it 기업 b가 그 프로젝트를 수주했다고 치면 이 회사 b에서 소속 개발자들을 그쪽으로 파견시켜서 개발시킬 수가 있습니다.
회사 b가 판교에 있다고 치더라도 발주처가 발주처 a가 저기 강원 경기도 용인 쪽에 있다고 치면 용인 쪽으로 여러분들이 출퇴근을 해야 돼요.
최소 1 2년 그거 끝나고 다시 돌아오는 것이 아니라 또 다른 프로젝트에 참여하게 된다면 그쪽이 아니야 전라도 전라도로 가는 거 매우 출근 환경이 자주 바뀌는 단점이 있습니다.
소기업이 아닌 이상 일하는 팀마다 계속적으로 달라집니다.
대기업일수록 그런 부서의 규모가 크고 그만큼 이직도 빈번하게 발생을 합니다.
그러면 이 3개월에 한 번씩 팀원이 옆자리가 바뀔 수가 있어요.

계속해서 또 친해져야 되고 계속해서 수식소통을 해야 되는 그리고 팀원으로서 정해진 기간 동안 맡은 역할을 데드라인에 맞춰서 이행을 해야 되겠죠.
내가 쳐내지 못하면 전체 프로젝트가 딜레이 되는 리스크가 있습니다.
그래서 책임감과 중압감이 낮춰 가겠죠. 이런 것이 SI 직무의 특징이다.
요 화면 많이 보셨죠? SI 프로그래머의 7번 실제 PD 수첩에 나온 건데요.
이 SI 프로그래머가 약간 일용직 노동자에 비유될 수가 있습니다.
프리랜서라고 치면 이 노가다를 군대 전역하고 노가다를 한번 띄워보신 적 있죠?
인력 사무서가 보통 4시 5시에 엽니다. 그리고 일감을 받으려면 4시 5시에 새벽부터 나가요.
이 SI 프리랜서 개발자도 이 인력 사무소에 있는 거죠.
기름통 앞에 불 딱 피워놓고 딱 들면 승합차가 딱 한 대 와가지고 문을 엽니다.
자바 할 수 있는 사람 2명 타세요 하면 그게 딱 타는 거예요.
과거 얘기이긴 하지만 지금도 그 처우가 크게 달라지지 않았습니다.

여러분들이 그 3대 SI 대기업에 가신다면 이럴 가능성은 없겠지만 프리랜서급의 개발자로 여러분들이 커리어를 이어나가게 된다면 이제 이런 상황에 여러분들이 마주할 수가 있다는 것이죠.
정신 똑바로 차리고 열심히 공부하시면 돼. 그래서 SI 대표 기업 세 가지를 먼저 말씀을 드렸지만 각 대기업마다 it 계열사들이 많습니다.
대표적으로 현대 하면은 오토에버, 포스코 하면은 ICT 요즘이 바뀌었죠.
포스코 뭔지는 잘 기억 안 나는데 신세계 IC i&c 롯데 정보통신 등등 대기업마다 it 계열사들이 있는데 이들은 보통 같은 계열사들의 일감을 받아서 개발을 하기 때문에 나갈 일이 거의 없습니다.
LG만 하더라도 다양한 계열사들이 있죠. 그 계열사에서 홈페이지 하나만 구축해 달라고 해도 일감이 쏟아지는 거예요.
그렇기 때문에 이런 대기업에 가시면 여러분들이 월급이 밀릴 일은 없다라는 것이 되겠고요.
이거는 채용 공고를 제가 좀 써놨는데 3학년 때부터 미리 고통스럽겠지만 현실을 아셔야 됩니다.

미리 채용 공고를 보시고 자신이 원하는 회사에 들어가기 위해서 전략적으로 포트폴리오를 준비해야 된다는 취지 하에 빠져 주세요.
이거는 작년이죠. 작년 하반기 9월 작년 9월 CNS 하반기 신입사원 공채 공고문이 되겠습니다.
여기 다운로드 받으셔서 보셔도 되고요. 같이 봐도 되는데 이 SI 인식이 너무 안 좋다 보니까 요즘에 사람들이 머리를 짠 게 SI 말을 안 씁니다.
디스라는 말을 써요. 디스 뭔 약자일까요?

디지털 익스피어리언스 개발자고요. 사용자 경험 사용자들의 경험을 어떻게 잘 만들어줄 수 있는 그런 엔지니어를 뽑겠다 SI죠.
사용자들이 원하는 프로그램 개발해 주는 거 SI 이런 식으로 DX 엔지니어라는 말로 채용을 하게 되는데 설명이 더 명확하게 나와 있죠.
다양한 산업의 프로젝트 경험과 it 신기술로 고객 맞춤형 서비스를 제공한다 SI 죠.
고객 비즈니스의 가치를 더하는 일을 합니다. 유지 보수해 주는 거죠.
이것이 SI 업체의 공고문이다라고 보시면 되겠고요.
이렇게 진행을 하고 여기 보이죠. 현지 근무 2년 필수라는 조건이 있습니다.
파견 많이 나간다고 했죠. 현지 업무가 2년씩 될 수도 있습니다.

그리고 그다음에 여기 보시면 여러분들이 이제 졸업이 다가오게 되면 이런 SI 기업부터 공고문이 뜨기 때문에 필연적으로 여러분들이 이런 기업부터 자기소개서 이력서를 넣게 될 겁니다.
미리 어떤 분야를 우대하고 채용을 하는지 알아야만 전략적으로 지금 주어진 2년 동안 잘 준비할 수가 있겠죠.
어쨌든 지금은 SI라는 말은 잘 안 쓰고 뭐 디스 DT 디지털 트랜스포메이션 이런 식으로 포장을 해서 SI를 얘기하고 있다라고 기억을 하시면 되겠고요.
그럼 대한민국의 SI 기업밖에 없냐 아니죠. 여러분들이 잘 아는 B2C 기업이라고 하는데요.
회사 자체적인 솔루션을 개발을 하는 회사를 B2C 업체라고 합니다.
대표적으로 네이버가 있죠. 네이버 클라우드 개발해가지고 어떤 플랫폼 개발해가지고 네이버 페이 개발해가지고 사용자들한테 일정한 멤버십 구독료 받아서 이윤을 창출하죠.

반대로 SI 기업은 고객으로부터 프로그램 수주를 받아서 돈을 버는 구조 자체적으로 기술 개발을 하기 때문에 좀 더 개발자로서의 처우가 좋고 자아 실현이 가능한 장점이 있습니다.
대표적인 B2C 기업이 네이버 카카오 요즘에 네카쿠배라당토 이런 식으로 얘기하죠.
이거 이외에도 게임 업체가 있는데 대표적으로 3n이 있습니다.
그래서 크게 세 가지 업체를 구분해 봤는데요. 지금부터 여러분들이 직무 탐색을 잘 하셔서 그 기업이 원하는 인재상에 가깝게 포트폴리오를 전략적으로 준비를 하셔야 됩니다.
그렇지 않으면 그 1년 이번에 지금 3학년이죠. 1년 딱 준비를 내가 하고 싶은 그냥 PBL 하고 프로젝트 팀 모여가지고 이런 거 한번 개발해 보자.
개발하면 기업이 원하는 그런 포트폴리오를 만들 수가 없어요.
그들이 원하는 부분이 뭘까요? SI든 B2C든 3n이든 이 업체들이 신규 채용을 할 때 공통적으로 보는 역량이 있습니다.

뭘까요? 그냥 애플리케이션 개발 경험 이런 건 다들 가지고 있기 때문에 더 이상 베네핏 받을 수 있지 않아요.
그럼 여러분들이 어떻게 전략적으로 여러분들의 포트폴리오를 완성해야 될까요?
항상 제가 얘기하는 말이 있는데 문제 해결 능력을 쌓아야 된다.
회사에서 만약에 면접을 봤을 때 기술 a에 대해서 물어본다면 면접자는 기술 a에 대해 답변을 하겠죠.
이러이러한 기술입니다. 끝나는 것이 아니라 기술 a에 대한 한계를 여러분들이 정확하게 인지를 하고 있고 그 한계를 해결하기 위해서 문제를 해결하기 위해서 이런 기술을 적용하면 좋을 것 같다 해서 해결을 해 봤다 이런 식으로 대화를 이끌어 나갈 수 있는 인재를 기업에서는 공통적으로 원합니다.
그러면 단순히 개발 프로젝트만 쌓아서는 경험만 쌓아서는 이런 역량을 갖출 수가 없겠죠.
그런 문제 해결 능력을 갖추기 위해서 여러분들이 포트폴리오를 전략적으로 한번 준비해 보시기 바랍니다.

구체적인 방법은 제가 할 수는 없고요. 이것을 아는 것과 모르는 것에는 큰 차이가 있기 때문에 그렇습니다.
그리고 9시에 이제 기분도 안 좋으신데 이렇게 너무 안 좋은 소리만 해서 죄송하고요.
일단 아셔야 되니까 진실은 항상 고통스러운 법입니다.
회사의 프로젝트의 워크플로우를 간략하게 설명드리고 10분 내로 마치도록 하겠습니다.
일단은 제안 요청서라는 것이 나옵니다. RFP라고 하는데요.
여러분들이 이 RFP를 반드시 아셔야만 합니다. RFP가 뭔가 했을 때 모른다 그러면 좀 곤란합니다.
졸업했을 때 이 퀘스트 폴 프로포절(quest for proposal)의 약자가 되겠는데요.
SI는 발주처가 있고 발주처로부터 대가를 받아서 프로그램을 개발해 주는 업체라고 했었죠.
그렇기 때문에 발주처가 이런 프로그램을 개발해 주세요라고 공고를 올리는데 그것을 제안 요청서 RFP라고 합니다.

이것은 보통 나라 장터 혹은 자체 회사 홈페이지에 올리게 되는데 회사가 규모가 크지 않으면 보통 나라 장터라는 곳에 이 제안 요청서를 발주처가 올리게 됩니다.
그러면 대한민국의 대기업 SI 회사뿐만 아니라 수백 개의 중소 중견 기업들도 있겠죠.
이걸 모니터링하고 있다가 다 사업 제안서를 제출합니다.
이걸 수주하려고 사업 제안서라는 것을 제출하는데요.
이 사업 제안서에서는 우리가 단가 얼마를 들여서 언제까지 개발을 할 수가 있다.
우리는 어떤 기술이 있고 어떤 인력이 있고 어떤 인력들이 있다 등등 어필을 하는 그런 문서라고 보시면 되겠죠.
이력서라고 보시면 돼요. 얘네로 따지면 그러면 제안 요청서를 올린 발주처는 사업 제안서를 제출한 여러 가지 기업이 있다 치면 몇 팀을 뽑아서 서면 평가를 거쳐서 발표 평가를 올립니다.
여기서 발표 평가를 마치고 한 팀만 기업 하나만 선택을 해서 계약서를 씁니다.

이때 대상 업체 선정 공고가 된 이후에 한 10일 정도 또 추가적인 시간을 주게 되는데 이때 사업 수행 계획서라는 것을 제출하라고 합니다.
이것은 사업 제안서에는 엄청나게 많은 거짓말들이 들어가 있어요.
뻥튀기 하는 거죠. 본인 회사들의 영역을 발주처도 압니다.
그렇기 때문에 거짓말을 다 걷어내고 진짜로 얼마를 들여서 언제까지 어떻게 개발을 할 것이다라는 것을 사업 수행 계획서를 통해서 한다고 합니다.
그럼 사업 수행 계획서를 제출하게 되면은 프로젝트가 진행이 되게 되는 것이죠.
이때 사업 수행 계획서 작성부터 프로젝트 진행까지가 소프트웨어 공학이 적용되는 법이라고 보시면 되겠습니다.
이거를 몰라도 되는 것이 아니라 프로젝트 기업이 어떻게 프로젝트를 수주하고 돈이 어떻게 모여들고 여러분들의 인건비가 어떻게 나가는지 이해를 하셔야만 좀 더 전략적으로 취업에 도전을 할 수가 있다.
그래서 제가 넣은 것이고요.

아무튼 소프트웨어 공학은 사업 수행 계획서의 작성 방법부터 실제 요구 사항, 공적 설립 구현 테스팅 프로젝트 진행을 어떤 식으로 할지 다루는 학문이다.
이 밑에 부분을 소프트웨어 공학의 범위라고 보시면 되겠고요.
사업 수행 계획서에는 다양한 계획 들어갑니다. 폭포수 모델을 기반으로 단계별 산출물로는 SRS SD 등등을 사용해서 할 것이다.
소프트 공학 모르면 이 용어들에 여러분들이 익숙하지 않겠죠.
다 배워볼 거고요. 어쨌든 단기적 프로세스 모델을 어떤 걸 쓸지 중간 산출물을 어떤 식으로 도출할지, 품질 관리는 어 할지 위험 관리 어떻게 할지 인력 관리는 어떻게 할지 그것들을 다 사업 수행 계획서에 적게 됩니다.
그것들을 여러분들이 알게 될 거고요. 그래서 짧게 5분 정도 제안 요청서 RFP를 한번 분석을 해보고자 합니다.
일단 웹페이지 한번 켜시고 컴퓨터 네이버에 조달청 나라장터라는 것을 한번 검색해 주세요

그러면 제안 요청서를 검색을 할 수가 있습니다.

알라 장표를 쓰시면 이게 조달청이 입니다.

사업 공고 입찰 공고라는 앱이 있는데요. 그쪽에서 이 RFP들을 볼 수가 있습니다.
여기서는 잘 보이지 않는데

이런 식 늘려가지고 일단 이 홈페이지 들어가면 이 여러 가지 제안 요청서들이 검색되게 됩니다.
첨부해 드린 두 가지 파일 있죠. LMS 인덱스 축 제한 요청서 첨부 3 제한 요청서 이걸 제가 예시로 한번 들고 와봤는데요.
들으신 경우 이걸 보셔도 됩니다. 이런 식으로 대한전문건설협회 홈페이지 구축이라는 RFP를 여기서 볼 수가 있죠.
여기 보시면 추진 배경 사업 기간 계약일로부터 7개월 1년도 안 됩니다.
7개월이라는 시간 동안 개발을 해달라고 하고요.
그래서 굵직굵직한 것만 보면 그래서 7개월 요구 사항이 있습니다.
요구 사항들이 있고요. 기능적 요구 사항도 있을 뿐만 아니라 품질 요구 사항도 있습니다.
어떤 버튼을 눌렀을 때 응답 시간은 1초 이내여야 한다 이런 등등 품질 요구 사항도 함께 이렇게 rq에 기술이 되어 있고요.
또 요구 사항들이 있습니다. 쭉 쭉 쭉 내려보시면

이렇게 제안서를 쓸 때 이제 그런 게 있습니다. 50페이지 25장 이내로 제안서를 제출해라 이런 식도 있고 제안서 목차도 이런 식으로 써라라고 안내를 해 주고 있습니다.

e예산은 2억 4천 7개월에 2억 4천 여러분들이 만약에 어떤 it 회사 기업 대표입니다.
7개월 2억 4천 도전할 겁니다. 도전하실 겁니까?
사업 제안서 한번 써볼 만해요. 72 2억 4천 직원들 월급이 끊기게 될 상황이면 도전해야죠.
특히나 여러분들이 창업을 하게 될 경우에 it 기업을 차린다고 할 경우에 직원들 월급 줘야죠.
직원들 채용해야죠 이런 거 rp를 계속해서 분석을 해서 제안서를 쓰게 될 겁니다.
그래야만 직원들 월급을 줄수 있는 거죠. 그래서 여러분들이 창업을 하실 경우에는 이 RFP를 반드시 이해하시고 사업 제안서를 쓸 줄 알아야 된다라는 것이 핵심이 되겠습니다.
시간 날 때 한번 보시고요. 그래서 SI 기업들은 이 제안서 요청서를 기반으로 프로젝트를 수주하고 직원들에게 월급을 준다라는 것이 되겠습니다.
사업 제안서를 쓰는 방법도 제가 좀 가져와 봤는데 이거 패스할까요?
이거는 시간 나시면 한번 읽어보시고요. 그런 분들이 만약에 사업 제안서를 써야 될 상황이다.

어떤 스타트업을 찾았다 직원들 월급 줘야 된다 그러면 이 나라 장터를 계속해서 들락날락하실 텐데 RP를 열심히 분석을 하시고 이 자료에 있는 사업 제안서 작성 전략들을 잘 숙지하신 뒤에 사업을 수주하시도록 하시면 되겠습니다.
여러분 시간 나시면 읽어보시고 끝났습니다. 정리하자면 이번 시간에서 알려드린 거는 SI 직무가 무엇이고 소프트웨어 공학이 무엇인지 알아봤죠.
소프트웨어 공학은 SR 직무의 워크플로우를 정확하게 따라가고 있고 SI 직무 수행에 필요한 다양한 가이드라인을 제시해 주는 학문이다.
여러분들이 소프트웨어 공학을 잘 숙지하시면 대신히 SI 기업 취업에 반드시 큰 도움이 되겠죠.
그리고 만약에 SI 직무가 나한테 안 맞는 것 같다.
B2C 기업에 내가 취업을 하고 싶다 그러면 B2C 기업에서 원하는 인재상을 미리미리 파악을 하시고 전략적으로 포트폴리오를 지금부터 준비를 하셔야 돼요.
성실성을 보여주기 위해서는 본인만의 블로그 피트업을 준비를 하셔야 되고요.

문제 해결 능력을 보여주고 싶다면 단순히 어떤 앱 개발 프로그램 개발 공모전 참석뿐만 아니라 근본적인 기술 개발을 보여줄 기술 개발 능력을 보여줄 수 있는 프로젝트에 참여를 하셔야 되겠죠.
이런 것들을 다방면으로 보여주기 위한 포트폴리오를 반드시 지금부터 전략적으로 준비를 하시면 되겠고요.
그리고 SI 업체도 제가 나쁘게 얘기했지만 내용 좋습니다.
그리고 평생 직장 없죠 여기서 시작을 해서 이직을 하셔도 괜찮아요.
하지만 어중간하게 시작하시면 올라가는 데 시간이 너무나 오래 걸려요.
그렇기 때문에 지금 주어진 시간 동안 잘 준비하셔서 취업에 성공하시기 바랍니다.
어쨌든 우리는 여기까지 하고요. 일단 오늘 수업은 여기까지 하겠습니다.
질문 있어요. 질문받고 끝내겠습니다. 다음 시간부터는 이 단계적 프로세스 모델부터 차근차근 따라가 보게 될 텐데요.
요구사항 분석은 또 어떻게 하는지, 설계는 어떻게 하는지 구현 어떻게 하는지 이런 식으로 계속해서 수업을 진행해 보고자 합니다.

질문 사과만 받고 마치겠습니다. 질문 없나요? 질문 없나요?
질문 없나요? 질문 없으면 마치겠습니다. 고생했습니다.

[2주차] SI 와 소프트웨어공학.ppt

0.67MB

[1주차] Introduction.ppt

2.92MB