라벨이 #소프트웨어공학인 게시물 표시

[소프트웨어공학] 디자인 패턴

이미지
[소프트웨어공학] 디자인 패턴 사용 목적에 따라 생성 패턴, 구조 패턴, 행위 패턴으로 분류 된다. 생성 패턴 객체의 생성 과정에 관여하는 것 ex) 추상 팩토리(abstract factory), 빌더(builder), 프로토타입(prototype), 싱글톤(singleton) 구조 패턴 클래스나 객체의 합성에 관한 패턴 ex) Adapter, Bridge, Composite, Decorator, Proxy 행위 패턴 클래스나 객체들이 상호작용하는 방법과 책임을 분산하는 방법을 정의 ex) chain of responsibility, command, iterator, mediator, memento, flyweight 팩토리 패턴 (factory pattern) 팩토리 메소드 패턴   객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정하게 만든다. 즉, 팩토리 메소드 패턴을 이용하면 클래스의 인스턴스를 만드는 일을 서브클래스에게 맡기는 것 추상 팩토리 패턴 인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고도 생성 어댑터 패턴 (adapter pattern) 전기 콘센트를 보면 이해하기 쉽다. 한국의 표준 플러그를 인본에 전원 소켓에 바로 끼워줄수 없어 동그랑 모양을 일자로 바꿔주는 어댑터를 끼워주어야 한다. 한 클래스의 인터페이스를 클라이언트에서 사용하고자하는 다른 인터페이스로 변환한다. 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있다. 호환되지 않는 인터페이스를 사용하는 클라이언트를 그대로 활용할 수 있다. 이렇게 함으로써 클라이언트와 구현된 인터페이스를 분리할 수 있으며, 향후 인터페이스가 바뀌더라도 그 변경 내역은 어댑터에 캡슐화 되기 때문에 클라이언트는 바뀔 필요가 없다. 기존 클래스를 재사용할...

[소프트웨어공학] UP(Unified Process)

[소프트웨어공학] UP(Unified Process) 도입(Inception) 비즈니스 케이스를 구축하며 시스템이 당면 문제를 알아낸다. 비즈니스 모델, 비전문서, 프로토타입을 생성한다. 상세(Elaboration) 시스템 요구사항의 대부분을 포착 이 단계에서 수행되는 일반적인 프로세스는 Use-case Diagram, Conceptual Diagram, Package Diagram 작성이 포함됩니다. 프로젝트를 계획하고, 시스템의 기능과 구조를 정의한다. 유스케이스 모델과 실행 가능한 기본 구조를 생서한다. 아키텍처 결정을 위한 설계 작업과 분석 작업의 비중이 크고, 시스템 구성에 관련된 위험 요소를 식별하고 완화하는데 중점을 두는 단계 구축(Construction) 기능이 반복 점진적인 방법으로 아키텍처에 자리 잡는다. 아키텍처에서 발생한 가정은 필요에 따라 테스트되고, 리팩토링된다. 각 반복을 통해 객관적으로 평가될 수 있는 실행 가능한 코드가 나온다. 이행(Transition) 테스트 후 사용자에게 인도된다. 출처 https://sonseungha.tistory.com/431

[소프트웨어공학] RAD모형(Rapid Application Development)

이미지
[소프트웨어공학] RAD모형(Rapid Application Development) 초고속 어플리케이션 개발 모형, RAD기법 모형 짧은 개발주기(60~90일) 동안 소프트웨어를 개발하기 위한 순차적 프로세스 모델로서 빠른 개발을 위해 CASE도구 사용 특징 2~3개월 정도의 짧은 기간으로 기술적 위험이 적고 빠른 개발이 요구될 때 적합 CASE 도구 및 재사용 가능한 Library 등을 활용하여 신속히 개발 프로토타입 사용 및 개발주기동안 내내 사용자의 적극적인 참여 필요 통합 단계가 필요한 대규모 시스템 개발에는 부적합 출처 https://bongbonge.tistory.com/entry/RAD%EB%AA%A8%ED%98%95Rapid-Application-Development

[소프트웨어공학] V모형

이미지
[소프트웨어공학] V모형 V 모형(V모델)은 폭포수 모형에 시스템 검증과 테스트 작업을 강조한 것이다. 코딩을 중심으로 각 단계가 V자 모양의 대칭을 이루고 있다. V자 모양 사이를 점선으로 연결한 의미는 각 테스트 단계에서 오류를 발견했을 때, 왼편의 요구분석, 설계, 코딩 단계로 되돌아 갈 수 있음을 의미한다. V 모형은 폭포수 모형에서는 감추어져 있는 반복과 재작업을 드러내 놓은 것이라 할 수 있다. 폭포수 모형은 문서와 결과물에 중점을 두는 반면, V 모형은 작업과 결과의 검증에 초점을 두고 있다. V 모형은 무엇보다도 높은 신뢰성이 필요한 응용 분야 , 예를 들어 의료 제어 시스템이나 원전 제어 시스템 개발 같은 곳에 적합하다. 출처 https://m.blog.naver.com/PostView.nhn?blogId=k97b1114&logNo=140165532912&proxyReferer=https%3A%2F%2Fwww.google.com%2F

[소프트웨어공학] 익스트림 프로그래밍 모델

이미지
[소프트웨어공학] 익스트림 프로그래밍 모델 애자일 개발 프로세스라고 불리는 개발 방법 중의 대표적인 하나로 손꼽힘 약칭인 'XP'로 잘 알려져 있음 (윈도우 XP 아니다) 다른 애자일 방법론과 구분되는 XP만의 특징에는 테스팅 이 있음 (Test-Driven Development) 반복적으로 프로토 타입을 고객에 전달함으로써 고객의 요구사항 변화에 민첩하게 대응한다. - 애자일 방법론의 기본 개념 특징 최근에 등장한 소규모 소프트웨어 개발에 유리함 1950년대 항공 방위 소프트웨어 시스템 개발 경험을 토대로 처음 개발되어 1970년대부터 널리 알려졌다. 애자일 방법론의 하나로 소프트웨어 개발 프로세스가 문서화하는데 지나치게 많은 시간과 노력이 소모되는 단점을 보완하기 위해 개발되었다. 의사소통, 단순함, 피드백, 용기, 존중의 5가지 가치에 기초하여 '고객에게 최고의 가치를 가장 빨리' 전달하도록 하는 방법론으로 켄트 벡이 고안하였다. 핵심가치 용기 : 문서로 변명하기 보단 진실되고 용기 있게 개발 존중 : 개발자의 역량을 존중하고 충분한 권한과 권리 부유 의사 소통 : 이해관계자 모두가 팀원이라는 생각으로 모든 사항 공유 피드백 : 의사소통에 따른 즉각적인 피드백 단순성 : 필요한 것은 하지만 더 이상은 하지 않음 출처 https://jhleed.tistory.com/2

[소프트웨어공학] UML(Unified Modeling Language)이란?

이미지
[소프트웨어공학] UML(Unified Modeling Language)이란? 요구 분석, 설계, 구현 등의 소프트웨어 개발 과정에서, 개발자간의 의사 소통을 원활하게 이루어지게 하기 위하여 표준화된 모델링 언어 이다. 모델링에 대한 표현이 정확하고 오류가 적은 논리적인 표기법 이다. 개발하려는 소프트웨어 규모에 상관없이 모두 적용 가능하다. 통합 모델링 언어로 객체 지향적 분석 설계 방법론의 표준 지정을 목표로 한다. 구조 다이어그램(Structure Diagram) 클래스 다이어그램(Class Diagram) 시스템의 정적인 구조를 나타냄 객체 다이어그램(Object Diagram) 데이터의 객체 구조를 보여주거나 시스템의 수행 중 특정 시점에서의 스냅샷(객체간의 연결 관계)을 보여주는 목적 패키지 다이어그램(Package Diagram) 컴포넌트 다이어그램(Component Diagram) 복합구조 다이어그램(Composite Structure Diagram) 배치 다이어그램(Deployment Diagram) 행위 다이어그램(Behavior Diagram) 유스케이스 다이어그램(Usecase Diagram) 시스템 분석 객체지향 방법론 상태 다이어그램(State Machine Diagram) 활동 다이어그램(Activity Diagram) 시스템의 동적 특징을 나타냄 시퀀스 다이어그램(Sequence Diagram) 시스템 설계 객체지향 방법론 객체 간의 메시지 통신을 분석하기 위한 모형 통신 다이어그램(Communication Diagram) 상호 작용 다이어그램(Interaction Overview Diagram) 타이밍 다이어그램(Timming Diagram) 출처 https://www.youtube.com/watch?v=nPREaEYax4Y

[소프트웨어공학] 검증검사(형상 검사 & 알파 검사 & 베타 검사)

[소프트웨어공학] 검증검사(형상 검사 & 알파 검사 & 베타 검사) 검증검사(Validation Test) 소프트웨어가 사용자의 요구사항을 충조가는가를 검사 1. 형상 검사(구성 검토, 검사) 구성 요소, 목록, 유지보수를 위한 모든 사항이 표현되었는가를 검사 2. 알파 검사 개발자의 장소 에서 사용자 가 개발자 앞에서 행하는 검사 기법 통제된 환경, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하며 기록 3. 베타 검사 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 기법 실 업무를 가지고 사용자가 직접 시험. 제어되지 않은 상태에서 행해짐. 발견된 오류와 사용상의 문제점을 주기적으로 개발자에게 보고 출처 https://m.blog.naver.com/PostView.nhn?blogId=agopwns&logNo=220998974776&proxyReferer=https%3A%2F%2Fwww.google.com%2F

[소프트웨어공학] 형상관리(CM : Configuration management)

[소프트웨어공학] 형상관리(CM : Configuration management) 소프트웨어의 개발의 변화하는 사항을 관리하는 활동 이다. 형상 관리 항목 정의 단계의 문서(분석서) 개발 단계의 문서와 프로그램(설계서 & 원시코드, 목적코드 등) 유지 보수 단계의 변경 사항(사용자 지침서) 비용은 절대 형상 관리 항목이 될 수 없다. 형상 관리 순서 식별(Identification) 형상 관리 대상 프로세스들을 분리 후 정의한다. 버전 관리(Version Control) 변경 전과 변경 후의 버전을 체계적으로 정리한다. 변경 관리(Change Control) 변경으로 인한 성능이나 품질, 신뢰도 등을 파악한다. 형상 감사(Configuration auditing) 변경을 평가하여 문제점을 지적하고 보완한다. 보고(Reporting) 문서화 출처 https://www.youtube.com/watch?v=ME1TIoIq0gI

[소프트웨어공학] CASE란?

이미지
[소프트웨어공학] CASE란? 소프트웨어공학을 지원하는 방법론/자동화도구 프로그램을 만들어서 팔려고하는데, 그 프로그램을 짜는 형태를 지원해주는 노하우나 프로그램 S/W개발 방법론 + 자동화 도구 ex) 세탁기를 그냥 놔두면 안되고 뭔가를 눌러야 내가 원하는것이 작동되는것처럼 운영되는 프로그램 Computer Aided Soft Engineering 소프트웨어를 개발하는 시점부터 요구 분석, 설계, 개발, 유지 보수에 이르기까지 소프트웨어의 생명 주기 전반을 지원하는 프로그램 또는 소프트웨어 개발을 지원하는 자동화 도구 혹은 방법론의 결합 특징 CASE의 툴(Tool)은 가격은 비싸지만 개발 비용은 절감된다. CASE를 도입하므로써 프로그램 개발 비용이 절감된다. CASE는 스스로 동작하는 것이 아니므로 분석가의 지원이 필요하다. 데이터가 있어서 자동으로 되는것이 아니라 명령어나 문법이 필요하다 ex) 엑셀처럼  수정이 용이하며 정확하다 ex) 주인공의 이름을 소똥에서 말똥으로 바꾼다. 개발을 신속하게 할 수 있어 개발 기간이 단축된다. ex) 원고를 이용하는것보다 워드 프로세서를 이용하면 빠르다. 생산성이 좋아진다. 재사용성이 높아진다. ex) 이력서를 하나하나 쓰는것보다는 컴퓨터에서 복사하면 편함 자동화된 검사를 통해 품질이 향상된다. CASE 툴(Tool)간의 호환성이 없다. ex) MS word에서 만든 문서를 아래 한글로 호환성 CASE 툴이 별로 없기 때문에 굳이 호환성 만들 필요가 없다. CASE의 분류 상위(Upper) CASE 요구 분석과 설계를 지원한다. 하위(Lower) CASE 코드 작성(구현), 검사(테스트)를 지원한다. 통합(Total) CASE 개발 주기 전 과정을 지원한다. CASE의 4가지 구성 요소 상위부 원하는 결과를 얻기 위한 명령 입력 부분 중위부 입력...

[소프트웨어공학] 일정계획방법론(PERT/CPM)

이미지
[소프트웨어공학] 일정계획방법론(PERT/CPM) PERT, CPM 둘 다 일정계획 방법론!!! 전체 규모를 측정한 다음에 -> 몇개월 걸릴 것이다! PERT Program-Evaluation and Review Technique 프로그램 평가 및 검토 기술이다. 소요 기간의 예측이 어려운 경우에 유리하다. 비용 측정은 고려 안한다!!!!!!!!!!! 작업별로 낙관치, 기대치, 비관치로 나누어 종료 시기를 결정한다. 노드에는 작업명, 간선에는 낙관치, 기대치, 비관치를 표시한다. 간트 차트를 이용하여 이정표를 작성한다. 간트 차트 내용에는 작업, 일정 계획(작업 일정), 이정표, 작업 기간 등이 포함된다. 네트워크를 그린 후 간트 차트를 마지막에 그린다. 예측치 공식을 이용하여 소요 기간을 정한다. 일정이 가장 늦은 경로인 임계 경로는 A -> D -> E -> F -> G 이다. CPM Critical Path Method 임계 경로 기법이라고도 한다. 소요 기간이 확실한 경우에 유리하다. 비용 측정은 고려 안한다!!!!!!!!!!! 노드는 작업명, 간선은 작업 사이의 전후 의존 관계를 표시한다. 원형 노드와 박스 노드로 구분된다. 원형 노드는 작업명, 박스 노드는 이정표를 표시하고, 예상 완료 시간을 표시한다. 한 이정표에서 다른 이정표에 도달하기 전에 작업을 완료해야 한다. 일정이 가장 늦은 경로인 임계 경로는 A -> D -> F -> H ->I이다. F작업은 E작업이 완료될 때까지 3일간의 여유 기간(Slack Time) 이 존재한다. 출처 https://www.youtube.com/watch?v=QXPkbu_Vjug https://www.youtube.com/watch?v=tDVouej-g2c

[소프트웨어공학] 유지보수

[소프트웨어공학] 유지보수 유지보수(Maintenance) 개발된 소프트웨어 품질을 항상 최상의 상태로 유지하기 위함. 개발단계 중 가장 많은 돈, 노력이 투입됨. 수정 보수 (Corrective) 잠재적인 오류를 찾아 수성, 오류 수정 및 진단 하자 보수 적응 보수 (Adaptive) 환경의 변화를 기존 소프트웨어에 반영하기 위한 활동 환경 적응 다른 시스템 요소가 향상되거나 변경될 때 대처하기 위한 유지보수 활동 완전화 보수 (Perfective) 본래 기능에 새로운 기능을 추가하거나 성능을 개선 유지보수 활동 중 가장 큰 업무 및 비용을 차지 예방 보수 (Prevention) 예비 조치 장래의 유지보수성. 오류발생에 대비하여 미리 예방 수단 강구 예방 유지보수를 소프트웨어 재공학 이라고 함. 출처 https://m.blog.naver.com/PostView.nhn?blogId=agopwns&logNo=220998978484&proxyReferer=https%3A%2F%2Fwww.google.com%2F

[소프트웨어공학] FTP(Formal Technical Review)의 지침사항

[소프트웨어공학] FTP(Formal Technical Review)의 지침사항 정형 기술 검토의 지침사항은 아래와 같다. 제품의 검토에만 집중하라 의제를 제한하여 진행하라 논쟁과 반박을 제한하라 문제의 영역을 명확히 표현하라 해결책과 개선책에 대해 논하지 마라 참가자의 수를 제한하라 체크 리스트를 개발하라 자원과 시간 일정을 할당하라 의미있는 훈련을 행하라 검토자들의 메모를 공유하라 검토 과정과 결과를 재 검토하라 출처 https://raisonde.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EA%B3%B5%ED%95%99-FTRFormal-Technical-Review%EC%9D%98-%EC%A7%80%EC%B9%A8%EC%82%AC%ED%95%AD

[소프트웨어공학] CPM(Critical Path Method) 네트워크

이미지
[소프트웨어공학] CPM(Critical Path Method) 네트워크 CPM 네트워크는 노드와 간선으로 구성된 네트워크이다. CPM 네트워크는 여러 가지 변형이 있다. 노드에는 작업을 표시하고, 간선은 작업 사이의 선후 의존 관계를 나타낸다. 위의 CPM 네트워크를 분석하면 S - A - M1 - C - M4 - I - M6 - K - M8 -L - X 작업으로 이루어진 경로가 임계 경로(critical path)가 된다. 즉, 이 경로에 있는 어떤 작업이라도 늦어지면 전체 프로젝트가 지연된다. 관리자는 다른 작어봅다 이런 작업들을 보다 관심에 두고 점검해야 한다. 또한 각 작업이 최대한 빠르게 끝날 수 있는 시간과 최대로 늦추어 끝낼 수 있는 시간을 각가 계산하게 된다. CPM 네트워크의 장점 관리자의 일정 계획에 도움을 준다. 프로젝트의 작업 사이의 관계를 나타낸다. 특히 최장 경로를 파악할 수 있게 한다. 할 수 있는 한 병행 작업을 할 수 있게 계획하고, 이를 위하여 자원 할당을 할 수 있게 한다. 다른 일정 계획안을 시뮬레이션 할 수 있다 프로젝트 일정을 점검하고 관리할 수 있게 한다. 출처 https://m.blog.naver.com/PostView.nhn?blogId=k97b1114&logNo=140165850486&proxyReferer=https%3A%2F%2Fwww.google.com%2F

[소프트웨어공학] NS(Nassi-Schneiderman) 차트

이미지
[소프트웨어공학] NS(Nassi-Schneiderman) 차트 NS(나씨 슈나이더만) 차트 모듈 명세서를 글로 쓸수도 있지만 N-S차트로 그림으로 그릴 수 있다. 플로우차트는 생각보다는 사용횟수가 많지 않다.  손으로 그리기가 까다롭기 때문이다. 이에 비해 NS차트는 더 쉽게 그릴 수 있어 생각을 더 쉽게 정리할 수 있다. 물론 NS차트만으로 모든것이 해결되는것은 아니다. 프로그램은 정해진 일을 정해진 방법으로 하도록 컴퓨터에 명령을 내리는 것이다. 컴퓨터는 정해진 일과 정해진 방법이 무엇인지 알수 없다. 왜냐하면 기계니까 따라서 우리는 두 가지 관점에서 프로그램을 만들어 갈 수 있다. 1. 무엇을 해야 하는지 생각해보기 컴퓨터에게 시킬일이 무엇이며 어떤 결과를 받아 보고 싶은지 정리 2. 어떻게 해야 하는지 생각해보기 사용자로부터 입력이 되는것과 입력없이 알 수 있는것들 가지고 어떤 처리를 어떤 순서로 진행해서 결과를 만들지 NS차트는 어떻게 원하는 결과를 얻을 수 있는지를 정리해 볼 수 있는 도구이다. NS차트 구성요소는 처리, 반복, 분기의 일반적인 프로그래밍 언어의 구성요소를 표현할 수 있다. 먼저 순차처리 네모 박스에 입력, 출력, 연산을 기록한다. 선택구조는 IF문이나 CASE문을 사용하여 처리 흐름을 기록한다. 반복구조는 While문이나 For문을 사용하여 조건에 따른 반복처리를 기술한다. 1에서 100까지 합을 구하는 ns차트 NS차트의 특징 논리의 기술에 중점을 둔 도형을 이용한 표현 방법이다. 그리기가 어렵다.(전문성이 있어야 잘 그린다) 순차, 선택, 반복으로 표현한다. 임의의 제어 이동이 어렵다. goto구조가 어렵다. 그래픽 설계 도구이다. 상자 도표라고도 한다 프로그램으로 구현이 쉽다. 조건이 복합되어 있는 곳의 처리를 명확히 식별하기에 적합하다. if문이 여러개일 때 가능 ...

[소프트웨어공학] 통합설계(하향식 통합 검사, 상향식 통합 검사)

[소프트웨어공학] 하향식 통합 검사, 상향식 통합 검사 하향식 통합 검사(Top Down Integration Test) 상위 모듈에서 하위 모듈 방향으로 통합하며 검사 주요 제어 모듈 기준으로 아래로 통합하며 이동 우선 통합법, 깊이 우선 통합법, 넓이 우선 통합법 등이 있음 절차 주요 제어 모듈을 드라이버 (검사 자료 입출력 제어 프로그램)로 사용. 주요 제어 모듈의 종속 모듈들을 스터브(임시 제공되는 가짜 모듈)로 대체 ex) A와 B가 결합된 C모듈이 있을 때 하향식 검사는 A와 B에서 옳은 값이 들어온다는 가정 하에 C가 잘 작동 하는 것인지 보는 것이므로, A와 B로부터 와야 할 값을 임의로 설정해 두는 것이다. 깊이 우선, 넓이 우선 방식에 따라 종속 스터브들이 실제 모듈로 교체. 모듈이 통합될 때마다 검사 실시. 새로운 오류가 생기지 않음을 보증하기 위해 회귀 검사 실시. 상향식 통합 검사(Bottom Up Integration Test) 하위 모듈에서 상위 모듈 방향으로 통합하며 검사 가장 하위 단계의 모듈부터 수행되므로 스터브가 필요 없음. 대신 하나의 주요 제어모듈과 관련된 종속 모듈의 그룹인 클러스터가 필요 절차 하위 모듈들을 클러스터(Cluster)로 결합 검사 사례 입출력 조정을 위해 드라이버(Driver) 작성. (제어 모듈이 없으므로) 클러스터 검사. 드라이버 제거 후, 클러스터는 프로그램 구조의 상위로 이동하여 결합. 출처 https://m.blog.naver.com/PostView.nhn?blogId=agopwns&logNo=220998971498&proxyReferer=https%3A%2F%2Fwww.google.com%2F

[소프트웨어공학] HIPO 모델

이미지
[소프트웨어공학] HIPO 모델 HIPO는 Hierarchical Input Process Output의 약자로, Input-Process-Output으로 이루어진모듈을 계층적으로 나타낸 도표이다. 시스템의 분석 및 설계나 문서화에 사용되는 기법으로 계층을 구성하는 각 모듈별 실행 과정인 입력, 처리, 출력 기능을 나타낸다. 수평 + 수직 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 도형 또는 도면 분석 및 설계 도구로 사용된다. 기본 시스템 모델은 입력, 처리, 출력으로 구성된다. 하향식(Top-Down) 개발에 적당하다 문서가 보기 좋게 체계화된다. 기능과 자료의 관계를 동시에 표현할 수 있다. 수정 및 유지 보수시에 좋다. 소규모 프로젝트에 적당한다. HIPO는 3가지 종류가 있다. 3가지를 따로 쓰는 것이 아니라 3가지로 이루어진 것이다. 가시적 도표(Visual Table of Content) 가시적 도표. 도식 목차라도고 불린다. 도식 목차 시스템의 전체적인 기능과 흐름을 보여주는 Tree형태 구조도 가시적 도표에는 입력, 처리, 출력이 나오지 않는다. 총체적 도표(Overview Diagram) 총체적 도표. 위 가시적 도표의 2.0 Update stock을 총체적 도표로 그린 것이다. 개요 도표 프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표  세부적 도표(Detail Diagram) 세부적 도표. 총체적 도표와 같은 프로세스를 그린 것이지만 더 복잡하고 상세하다 상세 도표 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표 총체적 도표와 같은 모양이지만 내용만 좀 더 복잡하게 들어간 형태이다. 꼭 이 3가지가 모여야 HIPO Model이 되는것은 아니다. 흔히 HIPO Chart라고 하는 건 가...

[소프트웨어공학] 소프트웨어 개발비용 산정 기법

[소프트웨어공학] 소프트웨어 개발비용 산정 기법 하향식 비용 산정 기법(top-down) 과거 유사 경험을 바탕으로 회의를 통해 산정하는 비과학적인 기법 전문가 감정 기법 조직내 경험이 있는 2명 이상의 전문가에게 비용산정 의뢰 신속하게 할 수 있지만, 편견이 있을 수 있다. 델파이 기법 한명의 조정자(중재자)와 여러명의 전문가의 의전을 종합하여 비용 산정 전문가 감정 기법의 단점을 보완한 것 상향식 비용 산정 기법(down-top) 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 전체 비용 산정 LOC(원시 코드 라인 수)기법  각 기능의 원시 코드의 라인수의 비관치(가장 많은 라인 수), 낙관치(가장 적은 라인 수), 기대치(평균 라인수)를 측정하여 예측지를 구해 비용을 산정하는 기법 예측치 = (낙관치 + 4*기대치 + 비관치)/6 노력(인월) = 개발기간 * 투입인원 = LOC / 1인당 월 평균 생상 코드 라인 수 개발 비용 = 노력 * 단위비용(1인당 월평균 인권비) 생산성 = LOC / 노력 개발 단계별 인원수(Effort per Task) 기법 생명 주기의 각 단계별로 노력(인월)을 산정 LOC보다 더 정확한 기법 LCO는 라인수만 있고, EPT는 가중치(일의 어려움)까지 측정 수학적 산정 기법(경험적 추정 모형, 실험적 추정 모형) 수학적 산정 기법 또한 상향식 비용 산정 기법이다. COCOMO(Constructive COst MOdel) 개발할 소프트웨어의 규모(LOC)를 예측한 후 소프트웨어의 종류에 따라 각 비용 산정 공식에 대입하여 비용 선정 소프트웨어 개발 유형 조직형(Organic Mode) 중,소 규모의 5만 라인 이하의 소프트웨어 사무처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합 반 분리형(Semi - Detached Mode) 조직형과 내장형의 중간형으로 30만 라인 이하의 소프트웨어 ...

[소프트웨어공학] 블랙 박스 테스트, 화이트 박스 테스트

[소프트웨어공학] 블랙 박스 테스트, 화이트 박스 테스트 블랙 박스 테스트(Back box test) 소프트웨어 검사 방법 중 하나로 어떤 소프트웨어를 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법 주로 올바른 입력과 올바르지 않은 입력을 일일이 다 동원하여 올바른 출력을 판별하는 방식으로 검사가 이루어지기 때문에 검사의 진행에 있어 대상이 되는 소프트웨어의 코드나 내부 구조 및 개발 노하우에 대한 정보는 기본적으로 필요로 하지 않습니다. 필요한 것은 특징, 요구 사항, 검사를 위해 공개된 설계도 등 대외적으로 공개된 사항들이며 '이 소프트웨어는 무슨 역할을 수행해야 되는가'와 같이 대상이 되는 소프트웨어의 특징이나 요구 사항 등에 초점을 맞춰 검사가 이루어진다. 검사 자체는 기능에 관한 것일 수 도 있고 기능외의 것에 관한 것 일수도있다. 블랙 박스 테스트는 유닛 검사, 인테그레이션 검사, 기능 검사, 시스템 검사, 적합성 검사 이렇게 소프트웨어 검사의 모든 레벨에 적용 가능합니다. 블랙박스 테스트의 기법 동등분할 기법 프로그램의 입력 도메인을 테스트 케이스가 산출 될 수 있는 데이터의 클래스로 분류하는 방법, 다양한 입력조건들을 갖춘 시험사례 유형들을 분할 : 상식적 경험에 의존(heuristic) 각 시험사례 유형마다 최소의 시험사례 작성 ex) 입력데이터가 값의 범위를 나타낼 때 : X값이 0~100사이여야 한다면 시험 사례를 (X<0, (x=0), X(x>50))으로 분할하여 유형을 적용 경계값분석기법 입력조건의 중간값에서 보다 경계값에서 에러가 발생될 확률이 높다는 점을 이용하여 이를 실행하는 테스트 케이스를 만드는 방법 ex) x값이 0~50사이여야 한다면 시험사례를 (x=0),(x=50),(x=-0.01),(x=50.1)로 정의 오류예측기법 각 시험기법들이 놓치기 쉬운 오류들을 감각 및 경험으로 찾아보는 것 ex) 입...

[소프트웨어공학] 럼바우의 분석 기법 모델링

[소프트웨어공학] 럼바우의 분석 기법 모델링 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법 순서는 객체 모델링, 동적 모델링, 기능 모델링 순으로 이루어짐 객체 모델링(Object Modeling) 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 클래스 다이어그램 으로 표현한 것 가장 중요하며 가장 선행되어야 하는 단계 동적 모델링(Dynamic Modeling) 상태도 를 이용하여 시간의 흐름에 따른 객체들 사이의 제어 흐름, 상호 작용, 동작 순서 등을 동적인 행위로 표현 한 것 기능 모델링(Functional Modeling) 자료 흐름도(DFD) 를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 것 입출력 결정 -> 자료흐름도 작성 -> 기능의 내용을 상세히 기술 -> 제약사항을 결정하고 최소화 출처 https://raisonde.tistory.com/entry/%EB%9F%BC%EB%B0%94%EC%9A%B0%EC%9D%98-%EB%B6%84%EC%84%9D-%EA%B8%B0%EB%B2%95-%EB%AA%A8%EB%8D%B8%EB%A7%81

[소프트웨어공학] 결합도 & 응집도

이미지
[소프트웨어공학] 결합도 & 응집도 모듈의 독립성을 판단하는 두 가지 지표이다. 결합도   모듈과 모듈간의 상호 의존 정도 응집도  모듈 내부의 기능적인 집중 정도 좋은 모듈화는 용도에 맞게 잘 구분된 기능을 가진 모듈들로 세분화 하는 것 즉, 개별 모듈은 독립적으로 자신에게 주어진 기능만을 수행하고 명확한 결과값을 내 놓아야 하고 다른 모듈에 의존성이 높아선 안된다. 즉, 결합도는 낮을수록 응집도는 높을 수록 이상적인 모듈화이다. 물론 결합도가 극단적으로 낮고 응집도가 극단적으로 높다고 다 좋은건 아니다. 결합도의 종류 자료 결합도 < 스탬프 결합도 < 제어 결합도 < 외부 결합도 < 공통 결합도 < 내용 결합도 자료 결합도(Data Coupling) Call by Value 모듈간의 인터페이스 전달되는 파라미터 나 인수 를 통해서만 모듈간의 상호 작용 깔끔한 Call by value 구조 결합도(Stamp Coupling) 하나의 구조를 여러개의 모듈이 같이 사용 모듈간의 인터페이스로 배열 이나 오브젝트 , 스트럭쳐 등이 전달되는 경우 제어 결합도(Control Coupling) 명령(ex 내림,오름 차순)에 따라 제어가 달라짐 단순히 처리를 해야 할 대상인 값만 전달되는게 아니라 어떻게 처리를 해야 한다는 제어 요소가 전달되는 경우 어떤 모듈이 다른 모듈의 내부 논리 조직을 제어하기 위한 목적으로 제어 신호를 이용하여 통신하는 경우이며, 하위 모듈에서 상위 모듈로 제어신호가 이동하여 상위 모듈에게 처리 명령을 부여 하는 권리전도현상 외부 결합도(External Coupling) 어떤 모듈에서 반환한 값을 다른 모듈에서 참조하는 경우 공통 결합도(Common Coupling) 파라미터가 아닌 모듈 밖에 선언되어 이는 전역 변수를 참조하고 전역변수를 갱신하는식으로 상호작용하...