반응형 소프트웨어공학9 테스트 소프트웨어 테스트의 정의 소프트웨어에 내에 존재하지만 드러나지 않고, 숨어 있는 오류를 발견할 목적으로, 개발 과정에서 생성되는 문서나 프로그램에 있는 오류를 여러 기술을 이용해 검출하는 작업이다. 오류를 찾아내 정상적으로 실행될 수 있도록 하는 정도이지, 소프트웨어에 오류가 없음을 확인시켜주지는 못한다. 테스트는 오류를 찾고 올바르게 수정하여 프로그램을 작동시킬 수는 있지만, 그 프로그램이 완전하고 정확하다고 증명할 수는 없다. 소프트웨어 테스트의 목표 작은 의미 원시 코드 속에 남아 있는 오류를 발견하는 것 결함이 생기지 않도록 예방하는 것 큰 의미 개발된 소프트웨어가 고객의 요구를 만족시키는지 확인시켜주는 것 개발자와 고객에게 사용하기에 충분한소프트웨어임을 보여주는 것 결과적으로 테스트의 목표는 개.. 소프트웨어공학 2022. 6. 3. 프로젝트 관리 프로젝트의 이해 프로젝트의 정의 미국 프로젝트 관리 협회 PMI는 프로젝트를 다음과 같이 정의한다. 프로젝트 : 유일한 제품이나 서비스를 만들기 위해 일정한 기간을 정해 놓고 수행하는 작업 프로젝트의 특징 한시성 유일성 참여자의 일시성 한정된 자원 프로젝트 매니저 PM이라고 줄여서 말하며 프로젝트 시작 시점부터 기획을 하고 설계를 한다. 프로젝트에 참여하는 팀원들의 장점과 능력을 잘 파악해 적재적소에 배치해야 한다. 고객과의 많은 대화를 통해 의견을 조율해야 한다. 프로젝트가 시작되면 진행 상황을 늘 체크해야 하고 진척 관리도 해야 한다. 프로젝트 수행 중 크고 작은 문제가 발생하면 해결책을 고민해야 하고, 책임감을 갖고 해결해야 한다. 인력 관리를 통해 참여자들이 도중 하차하는 일이 없도록 하고, 충분.. 소프트웨어공학 2022. 6. 3. 표준 코딩 규칙 표준 코딩 규칙을 따를 때 장점 가독성이 높아진다. 간결하고 명확한 코딩이 가능하다. 개발 시간을 단축시킨다. 명칭에 관한 규칙 명칭은 31자 이내로 정한다. 변수명과 함수명은 다르게 사용한다. 명칭의 규칙을 따른다. 매크로명 : _및 대문자 사용 상수명 : _및 대문자 사용 변수명 : 소문자로 시작 함수명 : 소문자로 시작, 첫 번째 단어는 동사로 작성 포인터명 : 참조하는 변수명의 첫 글자는 대문자 사용, 포인터 변수명은 앞에 p를 붙인다. 소스 형식에 관한 규칙 소스 파일 하나는 200줄 이내로 작성한다. 한 줄의 길이는 80자 이내로 작성한다. 함수의 내용은 70줄 이내로 작성한다. 하나의 문장을 2줄로 작성하는 경우 다음 규칙을 따른다. 80자가 넘어 쉼표가 오면 다음 문자는 새 줄로 시작한다... 소프트웨어공학 2022. 6. 3. 아키텍처 설계와 클래스 설계 아키텍처 설계 아키텍처란 건물의 뼈대뿐 아니라 특성을 결정짓는 기본 구조를 일컫는 말 아키텍처는 모든 기술 분야에 적용할 수 있고 종류도 다양하다. 아키텍처의 필요성 복합성의 문제 대형 프로젝트는 전체 시스템의 구조를 생각하며 균형과 조화를 이루도록 설계 대형 프로젝트가 복합성의 문제를 해결하는 법은 아래와 같다. 개발할 소프트웨어의 전체적 구조를 가장 먼저 생각한다. 소프트웨어의 구조를 이루는 각 구성 요소를 찾는다. 각 구성 요소 간의 명확한 관계를 설정한다. 일정한 규칙을 따른다. 아키텍처의 필요성 복잡하고 규모가 큰 소프트웨어를 개발하려면 전체적인 구조가 유기적으로 잘 구성되어야 한다. 잘 정의된 구조의 품질 좋은 소프트웨어를 만드려면 소프트웨어 아키텍처가 필요하다. 아키텍처 설계로 소프트웨어가 .. 소프트웨어공학 2022. 4. 15. 설계 요구분석과 설계의 차이 구분 요구분석 설계 산출물 요구분석명세서 설계서 관점 무엇 what 어떻게 how 특성 개념적, 추상적 사용환경을 반용해 구체적 비고 미고려 대상 : OS, DBMS, 프레임워크 고려 대상 : 비기능 요구사항, 제약사항 플랫폼(OS, 미들웨어, 프레임워크) 좋은 설계가 되기 위한 조건 설계서는 요구분석 명세서의 내용을 모두 포함 유지보수가 용이하도록 추적이 가능해야 한다. 변화에 쉽게 적응할 수 있어야 한다. 시스템 변경으로 인한 영향이 최소화되도록 국지적이어야 한다. 설계서는 읽기 쉽고 이해하기 쉽게 작성되어야 한다. 설계의 원리 분할과 정복 분할 : 큰 소프트웨어 하나를 개발할 때 여러 개의 서브시스템으로 세분화해 나누는 작업 정복 : 어느 정도 수준까지 분할했다면 말단에 있는.. 소프트웨어공학 2022. 4. 10. 요구분석 요구사항 소프트웨어 개발에서의 정의는 '사용자와 개발자가 합의한 범위 내에서 사용자가 필요로 하는 기능' 시스템이 제공하는 기능 요구와 품질과 같은 비기능 요구로 나뉜다. 요구사항이 정확히 무엇인지 파악하는 작업은 요구분석 단계에서 이루어진다. 요구분석 정의는 시스템이나 소프트웨어의 요구사항을 정의하기 위해 사용자 요구사항을 조사하고 확인하는 과정 목적은 사용자에게서 필요한 요구사항을 추출해 목표하는 시스템의 모델을 만들고 요구분석명세서를 작성하기 위함이다. 요구분석명세서는 요구 분석 단게에서 생성되는 최종 산출물로 시스템의 기능이 무엇인지에만 초첨을 두고 정리한다. 요구분석 단계 후 설계 단계에서는 설계서가 만들어지는데 이 문서는 어떻게 구현할지 기술한다. 요구분석의 어려움 사용자와 분석가의 의사소통 .. 소프트웨어공학 2022. 4. 6. 계획 계획 계획을 제대로 세우지 않고 수행하는 소프트웨어 개발은 일정 지연, 비용 초과, 품질 저하라는 결과를 낳게 된다. 소프트웨어 개발의 성패는 비용, 기간, 인력과 같은 자원을 토대로 초기에 얼마나 계획을 잘 세우느냐에 달려있다. 문제정의 문제를 정의하려면 개발하고자 하는 영역의 배경 지식이 필요하다. 유사한 프로젝트를 개발한 경험이 있는 분석가가 참여하는 것이 도움이 된다. 문제를 파악하기 위해 현재 운영중인 시스템을 사용해보고, 실무 면담자와 면담해 자료를 수집한 후 면밀히 분석해보는 것이 필요하다. 타당성 분석 경제적 타당성 경영자 입장에서 의사결정을 하는 데 매우 중요한 요소다. 시장 분석을 통해 시장성을 확인 경제적 타당성 분석으로 투자 효율성과 시장성을 검증한 후 개발 여부를 판단한다. 기술적.. 소프트웨어공학 2022. 4. 6. UML 이번 시간은 UML에 대해서 정리해보겠습니다. UML이란? Unified Modeling Language의 약어다. 소프트웨어의 전체를 판단할 수 있도록 12개의 다이어그램을 제시한다. UML의 역할은 시스템이 상호작용하는 측면, 시스템 전체 구조 측면, 컴포넌트 간의 관계 등을 시각적으로 볼 수 있게 나타낸 도면이다. UML의 12개 다이어그램은 아래와 같다. 12개 다이어그램에서도 유스케이스, 클래스, 순차. 통신, 활동, 상태, 컴포넌트, 배치 다이어그램에 대해 살펴보겠다. 유스케이스 다이어그램 객체지향 방법에서는 UML의 유스케이스 다이어그램으로 사용자 요구 사항을 표현한다. 유스케이스 다이어그램은 시스템이 제공하는 기능을 나타내는 유스케이스와 이 기능을 사용하는 사용자인 액터, 그리고 이 둘의 .. 소프트웨어공학 2022. 4. 4. 소프트웨어 공학과 개발 프로세스 이번 학기에 배우는 소프트웨어 공학 과목(줄여서 소웨공)에 대한 공부 내용을 늦게나마 정리해보려고 합니다 중간고사 전까지 전부 정리하기... 나 자신 파이팅!!!! 소프트웨어의 정의 프로그램 : 프로그래밍한 원시 코드를 의미 소프트웨어 : 프로그램(코드)을 비롯해 개발 과정에서 생성되는 모든 산출물(자료 구조, DB 구조, 테스트 결과 등)과 각 단계에서 만들어지는 문서와 사용자 매뉴얼 등 소프트웨어의 특징 제조가 아닌 개발 소모가 아닌 품질 저하 대형 빌딩 짓기와 대규모 소프트웨어 개발은 비슷하다. 개발 과정이 복잡하다 - > 개발의 복잡함을 줄이기 위한 방법과 기술 필요 참여 인력이 많다 -> 개발에 참여하는 팀을 구성하고 관리하는 효율적인 방법이 필요 개발 기간이 길다 -> 프로젝트를 효율적으로 관.. 소프트웨어공학 2022. 4. 1. 이전 1 다음 반응형
