개발/소프트웨어공학 (27) 썸네일형 리스트형 소프트웨어 개발 방법론 소프트웨어 개발 방법론의 구성 작업절차: 소프트웨어를 진행할 때 이루어지는 작업의 순서 작업방법: 각 단계별 작업마다 수행해야 할 일(누가, 언제, 무엇을) 산출물: 단계별로 나오는 산출물(설계서, 명세서) 관리: 개발 진행을 어떻게 제어하고 감독할 것인지 기법: 단계별 작업 시 사용하는 기술, 기법(DFD, ERD, Use Case) 도구: 사용하는 기법 별 지원 도구(PowerPoint, Excel, ERWin) 소프트웨어 생명주기 관리 모델에서는 포르젝트가 어떤 순서로 진행될지 그리고 중간에 어떤 산출물을 점검할 지에 대해 주로 관심을 가졌다면, 소프트웨어 개발 방법론은 소프트웨어를 어떻게 만들지에 대해 관심을 가진다. 따라서 개발 방법론에서는 단계별 산출물 뿐만 아니라 산출물은 누가 어떤 순서로 .. SOLID - 단일 책임 원칙(Single Responsibility Principle) 객체는 단 하나의 책임만을 가져야 한다. 책임이란 객체가 할수 있는 것, 해야 하는 것을 말한다. 예를들어 학생 클래스가 수강 과목을 추가하거나 조회하고 데이터베이스에 객체 정보를 저장하거나 데이터베이스에서 객체 정보를 읽는 작업도 처리하고 성적표와 출석부를 출력하는 일도 한다고 가정했을 때 이런 경우 학생 클래스의 코드는 다음과 같다. public class Student { public void getCourses() {...} public void addCourses(Course c) {...} public void save() {...} public Student load() {...} public void printOnReportCard() {...} public void printOnAtten.. SOLID - 의존성 역전 원칙(Dependency Inversion Principle) 객체 사이에 서로 도움을 주고 받으면 의존 관계가 발생한다. 의존 역전 원칙 DIP는 이러한 관계를 맺을 때의 가이드라인에 해당한다. DIP는 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것 보다는 변화하기 어려운 것 거의 변화가 없는 것에 의존하라는 원칙이다. 변하기 쉬운 것과 변하기 어려운 것은 정책, 전략과 같은 어떤 큰 흐름이나 개념 같은 추상적인 것은 변하기 어려운 것에 해당하고 구체적인 방식, 사물 등과 같은 것은 변하기 쉬운 것으로 구분하면 좋다. 객체지향의 관점에서는 변하기 어려운 추상적인 것들을 표현하는 수단으로 추상 클래스와 인터페이스가 있다. DIP를 만족하려면 어떤 클래스가 도움을 받을 때 구체적인 클래스보다는 인터페이스나 추상 클래스와 의존 관계를 맺도록 설계해야 한.. 소프트웨어 개발 방법론 - 애자일 애자일 소프트웨어 개발(Agile software development)은 프로젝트의 생명주기동안 반복적인 개발을 통해 빠른 개발 사이클을 가지는 개발 방법론이다. 애자일 방법론은 소프트웨어 개발 방법에 있어 계획과 무계획 사이에서 타협점을 찾고자 하는 방법론이다. 애자일 모델이 전통적인 개발 모형과 다른 점은 문서를 통한 개발이 아니라 실질적인 코딩을 통한 방법론이라는 점이다. 애자일 개발 방법론은 특정 개발 방법론에 국한되지 않고 애자일한 개발을 가능하게 해주는 방법론을 통칭하는 말이다. 지속적으로 고객의 요구사항을 반영할 수 있으며 빠른 피드백과 개발을 중시한다. 애자일 방법론의 사전적 정의는 2001년 애자일 소프트웨어 개발 선언에 의해 공식적으로 명명되었다. 애자일 소프트웨어 개발 선언 공정과 .. 소프트웨어 개발 방법론 - 워터폴 현재 가장 많이 사용되고 있는 개발 모델인 “폭포수 모델(waterfall model)”에 대해 작성한다. 요구분석 > 설계 > 디자인 > 개발 > 검증 폭포수 모델은 순차적인 소프트웨어 개발 프로세스로 각 단계를 완료하고 다음 단계로 이어서 진행하는 개발 프로세스를 말한다. 또한, 소프트웨어 개발에 구조화된 접근 방식을 제공하고 각각의 구분된 단계를 순차적으로 진행하여 마일스톤을 잡거나 프로젝트 관리를 할때 용이하다. 하지만 각 단계를 완료하고 다음 단계로 진행해야 하기 때문에 개발 사이클이 길어지고 고객의 요구사항을 반영하기 어렵다는 이슈가 있다. 따라서 폭포수 모델을 조직의 니즈에 맞게 수정하여 많이 사용한다. 컴퓨터 아키텍쳐, 소프트웨어 아키텍쳐 컴퓨터 아키텍쳐는 컴퓨터 구조로서 컴퓨터 공학의 개념의 살계이며 컴퓨터 시스템의 근간이 되는 운영 구조이다. 컴퓨터의 설계적으로 이식되는 것들과 요구 사항들(특히 속도와 상호 연결)이 무엇인지 기능적으로 설명되어 있는 청사진이다. 주로 중앙처리장치가 메모리 주소에 내부적으로 수행하고 접근하는 방법이 집중적으로 설명된다. 소프트웨어 아키텍쳐는 소프트웨어 구조로서 소프트웨어의 구성요소들 사이에서 유기적인 관계를 표현하고 소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙을 말한다. 소프트웨어 개발 환경 - local, dev, integration, qa, stage, production 일반적으로 사용되는 소프트웨어 개발 환경에 대해 작성한다. 프로젝트 진행에 있어 모든 환경을 갖출 필요는 없으며 프로젝트 환경에 따라서 각 환경을 합치거나 생략해도 된다. 로컬 (Local) 각 개발 PC 에 개발 및 테스트 환경 및 서버를 셋업한 환경을 말한다. 로컬 서버 환경에서의 개발에서 주의할 부분은 모든 개발자가 같은 개발 환경을 사용해야 한다는 것이다. 서로 다른 개발 환경에서 작업한 코드를 머지할 때 로컬 환경에서 잘 작동했던 코드가 작동하지 않는 경우가 많다. 전체 개발 환경을 zip 파일 형태로 묶어서 사용하거나 Docker 등의 컨테이너 기술을 사용한다. 개발 (Dev) 개발자들이 작업한 코드를 머지하여 테스트를 진행할 수 있는 환경이다. 소스코드를 형상관리 시스템에 커밋하면 코드는 개.. 컴포넌트(Component) 컴포넌트는 소프트웨어 시스템에서 독립적인 업무 또는 독립적인 기능을 수행하는 모듈로서 이후 시스템을 유지보수 하는데 있어 교체 가능한 부품이다. 소프트웨어 컴포넌트는 하드웨어의 그래픽카드와 같은 개념으로 독립적인 기능을 수행하는 소프트웨어 모듈이라고 말할 수 있으며 소프트웨어 컴포넌트는 컴포넌트란 말로 대체되어 사용되고 있다. 컴포넌트는 정의나 형태가 관점에 따라 다양하게 존재하지만 재사용 부품으로서의 컴포넌트가 되기 위해서는 아래의 내용을 만족해야 한다. 1. 소스코드가 아닌 실행코드 기반으로 재사용할 수 있도록 이미 구현이 완료되어 있어야 한다. 2. 컴포넌트는 용도, 유형, 기술표준과 인터페이스 등에 대한 정보들에 대해서 명세화가 되어 있어야 한다. 3. 교체가능한 컴포넌트를 개발하기 위해서는 표준.. 이전 1 2 3 4 다음
