Software engineering (SWE) is the application of engineering to the design, development, implementation, testing and maintenance of software in a systematic method. --> 소프트웨어의 개발, 운용, 유지보수 등의 생명 주기 전반을 체계적이고 서술적이며 정량적으로 다루는 학문
- 한마디로 정리하면 methodology(방법론)
- 어떻게가 중요한 학문
체계적으로 개발하고 효율을 가져가고 생산적으로 파워풀하게 개발하기 위해서
- Development (개발)
- The process of analysis, design, coding and testing software.
- Implementation (적용)
- The installation of a computer system or an information system.
- The use of software on a particular computer system.
개발자가 되는 것인가, 코더가 되는 것인가의 판별의 기준
개발 : 분석, 설계, 디자인 등 프로젝트 전반을 아우르는 것
적용 : 시스템에 돌어갈 수 있도록 코드를 생산하는 것 (제한적)
- Acceleration of DevOps adoption
- Continued wave of everything natively mobile
- Greater demand for increased privacy
- Cloud computing will be a thing of the past
- integration with Web and Mobile App
DevOps의 중요성 : 개발팀과 운영팀의 통합
네이티브 모바일 개발
보안의 강화
크라우딩 컴퓨팅 : 아마존 웹서비스, 구글 클라우드 등
웹과 모바일의 통합
- 웹앱 : 뒷단이 자바 등 네이티브한 웹환경에서 앱을 띄어놓는 것, 어떻게 구동되는지가 중요하다.
- 프로그래시브 웹앱 : 알리익스프레스
used to refer to a set of practices that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.
-
기존의 개발과 운영 분리로 인해 발생하는 문제들 문제 발생 -> 비방 -> 욕 -> 상처 -> 원인분석 -> 문제해결
-
좋은 소프트웨어를 위한 필수조건
- 기획팀과의 원활한 소통으로 요구사항을 충실히 반영
- 운영팀과의 원활한 소통으로 소비자 불만과 의견을 반영
운영과 개발을 통합하여 커뮤니케이션 리소스를 줄이고, 개발 실패 확률을 줄임과 동시에 보다 안정적인 서비스를 운영할 수 있음!!
- 크라우드 플랫폼을 통해 운영과 개발을 통합할 수 있다.
- 시스템 분석가의 요구에 맞게 컴퓨터 프로그래밍을 하거나 시스템 설계를 하는 사람
- Developer: can design
system(시스템을 만드는) - Programmer: can design
algorithm(알고리즘을 설계) - Coder: can produce
codefrompseudo code(알고리즘을 언어를 통해 구현)
- geek : 덕후스러움
- 특정한 하나에 대해 깊은 지식 보유
- 해결될때까지 집착할 수 있는
호기심
- **왜?**을 해결하기 위한 끈임없는 탐구
- **왜?**라는 질문을 끈임없이 해야한다.
컴퓨터 사고능력
- 정답이 정해지지 않은 문제에 대한 해답을 일반화하는 과정
-문제를 해결하는 많은 방법 중 어떻한 방법이 최적화된 방법일까
-알고리즘들을 계속 만들나가면서 기존의 솔루션과 비교하면서 끈임없이 실행하고 평가하는 것
- 문제 조직화(추상화) - Problem Formulation (abstraction)
- 솔루션 구현(자동화) - Solution Expression (automation)
- 솔루션 실행 및 평가(분석) - Solution Execution & Evaluation (analyses)
- 문제 분해(decomposition)
- 패턴인지 / 데이터 표현(pattern recognition / data representation)
- 일반화 / 추상화(generalization / abstraction)
- 알고리즘(algorithms)
- 문제 -> 일반화 / 추상화 -> 알고리즘
- 상황을 정의하는 문제의 일반화
- 추상화된 결과 도출 : 문제를 한문장으로 정리하여 문제를 파악하고
- 해결방법을 문장으로 정리하여 솔루션을 구성한다.
- 문제인지
배가 고프다
- 문제조직화
- 문제분해
뭘 먹긴 해야겠다집에서 해결함냉장고엔 뭐가있지? 밥은 해놨나? 라면이라도 먹을까? ...
나가서 해결함편의점? 식당? 패스트푸드? 레스토랑??
- 문제분해
- 패턴인지
아! 배가고프면 어디서 뭔가를 먹음으로써 Hunger가 False가 되는구나
- 일반화/추상화
- 추상화(간결하고 명확하게 단순화, 일반화, 개념화)
배가 고프면:{{어디}}에서{{어떻게}}해결함
- 알고리즘
- 추상화(간결하고 명확하게 단순화, 일반화, 개념화)
- 솔루션구현
- 솔루션실행 및 평가
솔루션대로 실행해서 나는 배고픔을 인지하고 해결하게 되었다.돈 보유량에 따라 다양한 선택지를 둬야겠다집에서 밥이 없으면 굶지말고 밥을 해야겠다.
평가를 통해 수정 보안
요구사항 분석
- 고객으로부터 개발에 필요한 정보를 얻어내는 과정
- 큰 그림을 그리기 위한 정보수집
무엇이 구현되어야 하는가에 대한 명세
시스템이 어떻게 동작해야 하는지 혹은 시스템의 특징이나 속성에 대한 설명
시스템 공학과 소프트웨어 공학 분야에서 수혜자 또는 사용자(고객 또는 실제사용자)와 같은 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 것과 같은 업무
- 이해관계자와의 상충을 해결
나(개발자)와 클라이언트(사장) 모두를 만족시키기 위한 연결고리
- 요구사항 유도(수집): 대화를 통해 요구사항을 결정하는 작업
- 요구사항 분석: 수집한 요구사항을 분석하여 모순되거나 불완전한 사항을 해결하는 것
- 요구사항 기록: 요구사항의 문서화 작업
- 사용자 요구사항 : 실제 사용자의 요구사항
"Why"
"왜" 프로젝트를 수행하는지
- 고객(클라이언트)이 제품을 개발함으로써 얻을 수 있는 이득
- Vision and Scope(비전과 범위)
"What"
사용자가 이 제품을 통해 할 수 있는 "무엇"
- Use cases, Scenarios, User stories, Event-response tables, ..
- 사용자 액션을 중심의 프로세스
- 클라이언트 중심의로 사용자의 흐름에 맞춰 작성한 프로세스
- 각 데스크가 어떤 프로세스로 진행되는지 정리
- 에자일에서 사용됨
- 마일스톤 : 각 단계의 목표와 어떻게 달성할 것인가를 명시
- 프로젝트 매니저, 기획자의 업무
"What"
- 개발자의 입장
개발자가 이 제품의 **"무엇"**을 개발할 것인지
- '~ 해야 한다' 로 끝나 반드시 수행해야 하거나 사용자가 할 수 있어야 하는 것들에 대해 작성
- 여러개의 서브 시스템으로 구성되는 제품에 대한 최상위 요구사항을 설명
- 컴퓨터: 모니터 + 키보드 + 마우스 + 본체 + 스피커
- 비즈니스 스트럭쳐의 요구나 제약사항을 명세
- "유저 로그인을 위해서는 페이스북 계정이 있어야 한다."
- "유저 프로필 페이지에 접근하기 위해서는 로그인되어 있어야 한다"
- 소프트웨어의 품질에 대해 명세
- "결제과정에서 100명의 사용자가 평균 1.5초의 지연시간 안에 요청을 처리해야 한다"
Functional Requirements에 명시하여 한 문서로 처리 가능하다.
- 시스템과 외부를 연결하는 인터페이스
- 다른 소프트웨어, 하드웨어, 통신 인터페이스, 프로토콜, ..
- 기술, 표준, 업무, 법, 제도 등의 제약조건 명세
- 개발자들의 선택사항에 제한을 두는 것
- 명세서는 말 그대로 명세일 뿐, 실제 개발 단계에서 마주칠 모든 것을 담을 수 없음
- 개발을 언어로 모두 표현할 수 없음
- 명세서가 완벽하다고 해서 상품도 완벽하리란 보장은 없음
- 때로는 명세를 작성하기 보단 프로토타이핑이 더 간단할 수 있음.
중요
- 유저 스토리를 통한 마일스톤 정리
- 소프트웨어 개발 생명주기 모델
- 개발하고 고치고 개발하고 고치고
설계없이 일단 개발, 만족할 때까지 수정
시작이 빠름
계획이 정확하지 않음, 개발 문서가 없고 진행상황 파악이 힘듦
- 소규모 프로젝트
- 마이크로 서비스 : 자기역할을 독립적으로 움직인다.(축구팀)
- 전체 웹서비스를 이렇게 진행하지 않는다. (부분적으로 사용한다.)
- 누더기가 될 가능성이 크기 때문에 추천하지 않는다.
순차적인 개발 모델, 가장 많이 사용됨
정형화된 접근 가능, 체계적인 문서화 가능
직전 단계가 완료되어야 진행 가능
- 대규모 프로젝트
- 각 단계가 완전히 끝날때까지 다음단계를 진행하지 않는다.
- 일반적으로 많이 사용되는 모델
- 답답하기 때문에 최근 환경에는 맞지 않다.
- 스타트업에선 적합하지 않다.
고객 요구사항을 적극적으로 반영하는 모델
빠른 개발과 고객 피드백을 빠르게 반영할 수 있음
대규모 프로젝트에 적용하기 힘듦
- 핵심기능을 빠르게 구현하여 의견을 수렴하고 적용해 나가는 방식
- 피드백 - 적용 - 피드백 - 적용 .... 완성 후 적용
- 프로토타입을 만드는 시간, 프로젝트에 적용되는 시간 등 대규모 프로젝트에는 사용하기 어렵다.
대규모 or 고비용 프로젝트
프로젝트의 위험요인을 제거해 나갈 수 있음
각 단계가 명확하지 않음
- 워터폴로 감당할 수 없는 큰 규모의 프로젝트
- 안정적인 운영 방식
- RAD(Rapid Application Development) Model
- Iterative Development Model
- V Model
- Component Based Development
in Agile
- 도입(분석위주), 상세(설계위주), 구축(구현위주), 이행(최종 릴리즈)의 반복
- 실무에 바로 적용할 수 있는 프로젝트
- 분석위주로 진행하고 설계 후 바로 구현까지 진행
- 다른 파트와 연관되지 않는 부분을 각자 개발 후 취합하는 형태
- 테스트를 중요하게 생각하지 않다. 문제가 생길 여지가 많다.
- 시니어 개발자가 많은 팀이 진행할 수 있는 프로젝트
- 스크럼 마스터가 주도적으로 프로세스를 주도하며, 고객과 개발자 사이의 소통을 중시함
- Product Owner와 Development Team, Customer로 롤을 구분하고 각자의 역할에 충실
- TDD 중시
- 더 많이 사용함
- 스크럼마스터
- 기획자는 디자인까지 진행하고 그 이후를 관리한다.
- 개발자의 일정관리 / 방향설정 / 대표 및 클라이언트에게 의견전달 / 프로세스 및 개발에 대한 정식 문서화작업
- 각자에 역활에 충실함
- 테스트 중심의 개발 방식
- 내가 만든 코드의 확신을 줄 수 있다.
- 객체지향적
- 재설계 시간 단축
- 디버깅 시간 단축
- 애자일과의 시너지(사용자 중심적)
- 테스트 문서 대체
- 추가 구현 용이
- 모듈단위 테스트
- 테스트코드 자체가 테스트문서가 될 수 있다.
초기 개발단계부터 마지막 출시까지 주기를 나타냄
- 어떤과정을 거쳐 배포가 되는지
- 테스트 이전까지 진행되는 요구사항 분석, 설계, 개발, 유닛 테스트를 포함
- 핵심 기능이 동작하기 시작한 상태
- 워터폴과정에서 베이픽케이션 까지의 단계
- 개발자가 테스트하는 단계
- 소프트웨어 테스트를 시작하는 첫 단계
- 회사 내부 테스터를 통해 진행하며, 피드백을 통해 소프트웨어를 개선함
- 내부에서의 테스트 : 외부인력을 통해 사용자의 피드백을 테스트한다.
- 당연하것도 물어보며 테스트하는 단계
- 외부에 직,간접으로 오픈하여 테스트를 진행
- 클로즈드 베타: 신청자 중 일부에 접근권한을 부여하고, 테스트를 진행함.
- 오픈 베타: 일반 유저에 모두 오픈하여 기능을 제공함.
- 일반사용자를 대상
- 오픈베타 : 마케팅 요소, 유저선점, 서버 과부하 테스트 등 버티는 용량과 예측불가능한 행동을 테스트 한다.
- 정식 제품이 될 가능성이 있는 베타버전. 심각한 문제가 없다면 이들 중 하나가 정식 버전이 됨.
- 소프트웨어를 유저에게 제공될 준비가 완료된 상태
- 과거의 개념 : cd 등 사용
- cd 공장에서 굽기 전 단계
- 소프트웨어를 유저가 이용 가능한 상태
- cd를 소비자가 사용하는 단계
- 개발방법론
- an iterative and incremental agile software development framework for managing product development
- 제품 개발 관리를 위한 반복적이고 점진적인 민첩한 소프트웨어 개발 프레임워크
- 가장 중요함 개념
- 함께 모여 문제와 해결책을 공유하는 것
- The product owner represents the stakeholders and is the voice of the customer, who is accountable for ensuring that the team delivers value to the business.
- The development team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each sprint (the sprint goal).
- facilitated by a scrum master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables.
- 프로젝트 오너 : 대표자
- 스크럼마스터 : 개발팀 매니저
- 개발팀 : 개발자
- 프로젝트 전체를 분할 : 테스크별 개발블록 설정
- 스크럼마스터가 각 개발자에게 효율적인 배분
- 시간단위로 개발블록을 설정한다.
- 에자일은 사람단위 블록으로 분할
- 간트차트 : 기능에 특화된 차트 (에자일에 사용되지 않는다.)
-
애자일 추정을 위해 사용하는 도구
-
모든 팀원이 한가지 과제에 대해 충분히 토론하고 작업시간을 추정하기 위함
-
deck 구성 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, 무한대, 커피
-
점수는 단위 작업시간(8시간)을 의미함
- 에자일은 사람이 먼저인 프로세스
- 스크럼마스터의 역량에 따라 진행 여부를 결정할 수 있다.
- 커피 : 휴식 (전체와 함께 해야하기를 원할 시 설득을 해야한다.)
- ? : 정보의 부족으로 일정을 체크할 수 없다.
- 무한대 : 한계를 벗어나는 행위를 의미
- 플레이방법
- 추정할 과제를 가장 잘 아는 사람이 해당 과제에 대해 설명합니다.
- 다른 사람은 추정에 필요한 정보를 얻기위해 질문과 토의를 합니다.
- 각자 생각하는 이 과제의 점수를 보이지 않게 내려놓습니다.
- 점수를 공유하고 가장 낮은 점수, 가장 높은 점수를 낸 팀원이 이 점수를 낸 이유에 대해 설명합니다.
- 모든 팀원이 같은 점수를 낼 때 까지 3~4의 반복
- 과제설명 : 필요한 정보를 모두 얻어야 한다.
- 점수가 몇점이든 중재를 할 수 있다.
- 은행 예금 계좌 및 체크카드 발급절차
- Fizzbuzz
- Profile Porfolio Page
- 시니어와 주니어가 한 팀을 이뤄 노하우를 전수하거나 같은 과제에 대해 충분한 논의를 함으로써 생산성 향상을 도모
- Navigator와 Driver가 한 팀을 이뤄 실시
- Navigator는 해당 과제에 대해 주도적으로 의견을 제시하고 Driver는 Navigator가 지시하는 대로 작업하되, 이해되지 않는 부분이 있다면 이의를 제기
- 약속한 시간이 지나면 Navigator와 Driver의 역할 변경
- 과제를 해결할 때 까지 반복
검토사항
- 요구사항
- 설계요구 충족여부
- 과도한코딩
- 같은 기능
- 함수의 입출력
- 빌딩블록(API, 라이브러리, 자료구조, ..)
- 변수 사용전 초기화