소프트웨어 공학

📌소프웨어란? Code : 프로그램의 한 부분 Program : 실행가능한 컴퓨터 명령어임을 표시 Software : program + document(요구사항 분석, 디자인, 계획 등 문서) 📖소프트웨어 특징 Complexity : 복잡성 Conformity :

코딩 - 버그 픽스의 단순 반복개발 과정을 특정한 task로 나누고, 순서를 정의하여 진행하는 것우리가 배우는 것은 Development processDevelopment process : 개발에 직접 관여하는 활동들을 정리하고 나열한 것정해진 절차를 따라 진행하면 최

the waterfall model : 전통적, one shotrapid prototyping model : 유저에게 피드백 계속 받기the evolutionary model : 유저에게 피드백 계속 받기the spiral model : 위험 분석 위주the V mod

📌Agile 구체적 진행 방법 📖scrum 애자일의 팀 관리 방법, 또는 팀 그자체 매일 팀원끼리 개발상황 공유 일정 주기(그림은 30일)로 결과물을 고객에게 피드백 받기 sprint : 개발 주기 product backlog : 요구사항, 구현해야할 기능 목록,

정해진 일정내에 완성제한 비용내에서 완성요구한 품질를 만족잘 기능하는 팀을 계속 유지해나가는 것스케줄 정하기비용 관리팀원 관리리스크 관리프로젝트 범위제약 사항 및 조건(어느 환경에서 돌아가야한다 등)SOW, 작업명세서시스템 구성(SW, HW)팀 구성비용 계획일정프로젝트

경험 기반 예상비용 모델 알고리즘 : 고려 요소로 project size, work period비용 모델 알고리즘 중 하나소프트웨어 개발에대한 거래에서 가격을 객관적으로 정할 수 있는 근거Efforts = A SIZE^B MA : 소프트웨어 타입에 따라 정해지는 상

해야 할 일들을 트리 모양으로 만듬대분류에서 depth가 깊어질수록 소분류(구체적으로)작업끼리의 의존성과 작업 시간을 나타낸 것C작업을 하기위해서 A작업이 필요하고, A작업에 8시간이 걸림노드 : 태스크엣지 : 의존관계중요 경로(critical path) : 프로젝트

project manager(PM) : 프로젝트 일정 관리, 리스크 관리 등project leader(PL) : 아키텍처, 설계 등software engineer : 실제 개발자tester(QA team) : 테스트 계획 수립, 테스터build/release team

리스크를 예측해보고 해당 리스크를 어떻게 대응할 건지 계획소프트웨어 개발은 불확실성이 매우 높다 -> 대비가 필요리스크를 파악하자, 어떤 리스크가 있을지 나열해보자estimate짧은 개발 일정저조한 오류 수정률규모 측정 오류organizational예산 축소담당하던 부

소프트웨어 시스템이 제공해야하는 기능들(what)해당 시스템의 제약 사항들프로젝트 실패의 중요 원인은 적당하지 않은 요구사항 때문요구사항 자체가 복잡고객 스스로 무엇을 원하는지 명확하지 않다이해당사자들(고객, 개발자)은 자신들만의 용어로 요구사항을 표현한다, 본인 분야

누구로부터 요구사항을 얻어야하는가 고객 해당 분야 전문가 실 사용자 비슷한 다른 소프트웨어 및 제품 요구사항 추출의 어려움 이해 당사자들 본인들이 무엇을 원하는지 잘 모른다 구현가능한지 잘 알지 못함 무엇을 원하는지 잘 전달하지 못함 분석가 : 유

요구사항들을 완전한가?, 상충하지 않나? 등을 분석요구사항들을 분석하고 정제하여 정해진 모델, 양식으로 만드는 것DFDUML : use case modeling각 상호작용에서 유저의 관점에서 바라보는 요구사항을 기술하는 것UC : 시스템에서 제공하는 기능시스템 : 모든

만들고자 하는 소프트웨어 시스템을 단순화한 것분석 단계에서는 고객들이 원하는 시스템의 기능들에 대하여 설명한 것설계 단계에서는 실제 내부 구조에 대하여 설명한 것어떤 기능의 요구사항을 위한 인풋과 아웃풋을 정의인풋으로부터 아웃풋을 만들기 위한 요소들을 정의 Data f

실행하면서 변하지않는 정적인 기능을 서술시 사용하는 다이어그램association : X 클래스의 멤버 변수로 Y 클래스 타입이 존재 => X has a Yinheritance : X 클래스는 Y 클래스의 자식이다 => X is a Ydependecy : X 클래스가

class diagram : 시스템을 구성하는 클래스로 표현object diagram : 시스템을 구성하는 객체로 표현package diagram : 모델을 구성하는 패키지들로 구성component diagram : 시스템을 구성하는 컴포넌트로 표현composite d

소프트웨어 시스템의 청사진 : 구조, 동작, 상호작용, 비기능적 속성 등또다른 정의로는 설계시 나오는 다양한 의사결정들의 집합계층 아키텍처 예시컴포넌트 : 독립적으로 수행가능한 모듈 또는 클래스 or 아키텍처의 한 부품(부분)아래 예시에서는 4가지 기본 컴포넌트들을 기

패키지를 사용하여 표현uml 패키지 내부에 MyAppFrame 클래스가 존재javax::swing 패키지 내부에 JFrame, JMenu 클래스가 존재MyAppFrame 클래스에서 JFrame, JMenu 클래스를 사용다음과 같이 패키지안의 서브패키지를 두면서 계층적으

계층적인 아키텍처각 계층은 그 위 계층에 서버스를 제공한다이미 있는 시스템 위에 새로운 기능을 쌓을 때 사용여러 팀이 각 기능 계층을 하나씩 맡아 개발할 때 사용보안성을 강화해야할 때(보안해야할 계층을 아래에 두어서 보안강화)인터페이스를 동일하게 유지하면 하나의 계층을

큰 흐름, 단계부터 정하면서 세부적으로 설계하는 것먼저 큰 3단계로 구분하고각 단계를 세분화중요한 것은 드러나도록, 세부적이거나 중요하지 않은 것은 숨긴다procedural interface를 보여준다(큰 흐름)prodecural의 내부 알고리즘은 숨긴다data에대해

단일 책임 원리각 모든 모듈 or 클래스들은 하나의 기능 or 역할을 가져야 한다하나의 모듈에 여러 기능이 있는 경우하나의 기능이 여러 모듈에 걸쳐 있는 경우참고) transaction : DB에서 자주사용하는 용어로 어떤 로직이 수행되다가 제대로 마치지 못하였으면 처

코딩을 하면서 나타나는 문제들을 ~한 패턴으로 코딩하면 해결하더라이러한 문제해결 패턴들을 모아둔 것객체 생성시 어떻게 클래스의 구성할 것 인가?(불필요한 의존성 등)에대한 패턴객체와 해당 객체의 클래스 사이의 의존성을 낮추는 패턴객체를 생성하는데 구체적인 클래스의 이름

\- : private\+ : public\`\_ : static자기 자신 참조Computer가 없어져도 다른 객체들은 존재Computer가 없어지면 다른 객체들도 같이 사라짐

📌리팩토링이란 어떤 코드의 동작이 바뀌지 않도록 다시 작성하는 것 다시 작성하면서 중복코드를 삭제하거나, 복잡한 로직을 단순화 하는 등의 개선을 거침 📖리팩토링 목록 collapse hierarchy 두개의 클래스 혹은 모듈의 의존성이 굉장히 높으면 하나로 merge한다 consolidate conditional express 같은 결과를 return...

테스트장점 : 버그를 찾으면 확실하게 버그라고 단정지을 수 있다(no false positive)단점 : 완전하지 않음, 못 찾는 경우 존재버그를 존재하는 것을 증명할 수 있지만 버그가 없다고 증명할 수 없다가능한 모든 인풋, 경우의 수를 고려하는 것장점 : 완전함(모

소프트웨어의 명세에 기반하여 테스트(코드를 직접 보지 않음)명세서의 기능들을 동작하도록 테스트하는 것이 목적명세에 없는 세부적인 오류는 찾기 힘듬도메인에 집중할 수 있다코드가 필요 없다, test case 디자인을 미리 할 수 있다명세에서의 논리적 오류를 찾을 수 있다