본문 바로가기

소프트웨어공학23

[SW 설계 원칙] SOLID 원칙과 그 진정한 의미 ㅁSOLID 원칙: 객체지향 설계의 핵심 원칙 소프트웨어 개발에서 유지보수성과 확장성을 높이기 위해서는 올바른 설계 원칙을 따르는 것이 중요하다. SOLID 원칙은 이러한 객체지향 설계를 효과적으로 수행할 수 있도록 돕는 다섯 가지 핵심 원칙을 의미한다. 이 원칙들은 로버트 C. 마틴(Robert C. Martin)에 의해 정립되었으며, 특히 객체지향 프로그래밍(OOP)에서 널리 사용된다. 1. SRP(Single Responsibility Principle, 단일 책임 원칙)"클래스는 단 하나의 책임만 가져야 한다."단일 책임 원칙은 하나의 클래스가 하나의 역할만 수행하도록 설계해야 한다는 원칙이다. 즉, 하나의 클래스는 변경이 필요한 이유가 단 하나뿐이어야 한다. 이를 통해 코드의 응집도를 높이고, .. 2025. 3. 17.
[SW 설계 원칙] 의존성 주입(DI, Dependency Injection) 쉽게 이해하기(w/Python) https://claremont.tistory.com/entry/SW-%EC%84%A4%EA%B3%84-%EC%9B%90%EC%B9%99-SOLID-%EC%9B%90%EC%B9%99%EA%B3%BC-%EA%B7%B8-%EC%A7%84%EC%A0%95%ED%95%9C-%EC%9D%98%EB%AF%B8 [SW 설계 원칙] SOLID 원칙과 그 진정한 의미ㅁSOLID 원칙: 객체지향 설계의 핵심 원칙 소프트웨어 개발에서 유지보수성과 확장성을 높이기 위해서는 올바른 설계 원칙을 따르는 것이 중요하다. SOLID 원칙은 이러한 객체지향 설계를 효과적claremont.tistory.com   괜히 쫄 거 없다!정말 간단한 개념이다예제를 통해 의존성 주입이 무엇인지 알아볼 거고, 언어는 제일 가독성이 좋은 파이썬을 .. 2025. 3. 13.
[디자인 패턴] 데코레이터 패턴과 클로저 기능(python, java 관점) ㅁ데코레이터 패턴(Decorator Pattern): 객체에 새로운 기능을 동적으로 추가하는 구조적 디자인 패턴"기존 코드를 수정하지 않고"도 기능을 확장할 수 있어 유지보수성과 확장성이 뛰어나다! [데코레이터 패턴의 특징]기존 코드 변경 없이 기능 추가 가능상속(Inheritance)과 차별화된 방식상속 - 기존 클래스를 확장하여 기능을 추가하는 방식데코레이터 패턴 - 기존 객체를 감싸(wrapping) 추가적인 기능을 부여하는 방식유연한 구조(여러 개의 데코레이터를 조합하여 다양한 기능을 적용할 수 있다) e.g. 안드로이드에서의 활용안드로이드 개발에서 다양한 컴포넌트들은 데코레이터 패턴을 활용하여 구현되어 있다. 대표적인 예로 Drawable을 감싸는 LayerDrawable이나, View의 기능을.. 2025. 3. 7.
[소프트웨어공학] 전통적인 SW 테스트 방법론 소프트웨어 개발 과정에서 테스트(Testing)는 필수적인 단계이다. 특히 시스템의 안정성과 성능을 보장하고, 예상치 못한 오류를 방지하기 위해 다양한 테스트 기법이 사용된다. 이번 글에서는 소프트웨어 개발에서 활용되는 주요 테스트 방식을 살펴보고, 각각의 목적과 특징을 정리한다.1. 단위 테스트(Unit Test)단위 테스트는 각 구성 요소(함수, 모듈, 클래스 등)를 개별적으로 검증하는 테스트이다. 소프트웨어 개발의 초기에 수행되며, 코드의 기능이 의도한 대로 동작하는지 확인하는 것이 목적이다.✅ 주요 특징개별 함수나 메서드 단위로 수행됨독립적인 환경에서 실행되며, 외부 시스템(DB, API 등)과의 연결을 최소화함테스트 자동화 도구(JUnit, PyTest, Mocha 등)를 사용하여 검증 가능✅ .. 2025. 2. 19.
[SW 개발 모델] 스크럼(Scrum): 효과적인 애자일 개발 방법론 https://claremont.tistory.com/entry/SW-%EA%B0%9C%EB%B0%9C-%EB%AA%A8%EB%8D%B8-%EC%95%A0%EC%9E%90%EC%9D%BCAgile-%EB%B0%A9%EB%B2%95%EB%A1%A0 [SW 개발 모델] 애자일(Agile) 방법론https://claremont.tistory.com/entry/SW-%EA%B0%9C%EB%B0%9C-%EB%AA%A8%EB%8D%B8-%EC%9B%8C%ED%84%B0%ED%8F%B4Waterfall-%EB%AA%A8%EB%8D%B8 [SW 개발 모델] 워터폴(Waterfall) 모델ㅁ워터폴(Waterfall) 모델: 전통적으로 사용되는 방법론 중claremont.tistory.com  ㅁ스크럼(Scrum): 소프.. 2025. 2. 18.
[SW 개발 모델] 칸반(Kanban): 애자일 프로젝트 관리를 위한 효과적인 방법론 https://claremont.tistory.com/entry/SW-%EA%B0%9C%EB%B0%9C-%EB%AA%A8%EB%8D%B8-%EC%95%A0%EC%9E%90%EC%9D%BCAgile-%EB%B0%A9%EB%B2%95%EB%A1%A0 [SW 개발 모델] 애자일(Agile) 방법론https://claremont.tistory.com/entry/SW-%EA%B0%9C%EB%B0%9C-%EB%AA%A8%EB%8D%B8-%EC%9B%8C%ED%84%B0%ED%8F%B4Waterfall-%EB%AA%A8%EB%8D%B8 [SW 개발 모델] 워터폴(Waterfall) 모델ㅁ워터폴(Waterfall) 모델: 전통적으로 사용되는 방법론 중claremont.tistory.com  칸반 보드는 WIP(Work.. 2025. 2. 18.
[SW 개발 모델] MoSCoW 원칙: 효과적인 요구사항 우선순위 결정 방법 소프트웨어 개발과 프로젝트 관리는 제한된 리소스 내에서 최적의 결과를 도출하는 것이 중요하다. 하지만 프로젝트를 진행하다 보면 다양한 요구사항이 쏟아지고, 이들을 모두 처리하는 것은 현실적으로 어렵다. 이러한 문제를 해결하기 위해 등장한 것이 "MoSCoW 원칙"이다. 이 원칙은 프로젝트에서 요구사항을 우선순위별로 분류하여 필수적인 요소와 부차적인 요소를 명확히 구분할 수 있도록 돕는다.  ㅁMoSCoW 원칙: 프로젝트 관리와 요구사항 정의에서 널리 사용되는 우선순위 결정 기법이 원칙의 핵심은 요구사항을 네 가지 범주로 분류하는 것이다(MoSCoW라는 명칭은 다음 네 가지 요소의 앞글자를 조합한 것이다)Must-Have (반드시 포함해야 할 기능)Should-Have (필요하지만 반드시 필수는 아님)Co.. 2025. 2. 18.
[SW 개발 모델] 애자일에서의 WBS와 스프린트 및 백로그의 융합 https://claremont.tistory.com/entry/SW-%EA%B0%9C%EB%B0%9C-%EB%AA%A8%EB%8D%B8-PMBOK%EC%99%80-WBS-%EA%B0%9C%EB%85%90 [SW 개발 모델] PMBOK와 WBS 개념ㅁPMBOK(Project Management Body of Knowledge, 프로젝트 관리 지식 체계): 프로젝트 관리에 필요한 지식과 프로세스를 체계적으로 정리한 가이드 미국 프로젝트 관리 협회(PMI, Project Management Institute)에서claremont.tistory.comhttps://claremont.tistory.com/entry/SW-%EA%B0%9C%EB%B0%9C-%EB%AA%A8%EB%8D%B8-%EC%95%A0%EC%.. 2025. 2. 18.
[SW 개발 모델] 스프린트, 백로그, 테일러링 개념 ㅇ스프린트(Sprint): 일정한 기간(보통 1~4주) 동안 수행하는 개발 주기 애자일 프레임워크 중 하나인 "스크럼(Scrum)" 에서 중요한 개념으로, 개발팀이 정해진 기간 내에 완료할 수 있는 작업을 선정하고 집중적으로 개발을 진행하는 방식이다 [스프린트 특징]짧고 반복적인 개발 주기: 일정한 기간(예: 2주) 동안 제품을 개발하고, 그 후 리뷰와 피드백을 반영하여 다음 스프린트를 진행한다고정된 기간: 스프린트는 타임박스(time-boxed)되어 있으며, 중간에 변경되지 않는다우선순위 기반 개발: 가장 중요한 기능부터 개발하여 빠르게 사용자에게 제공할 수 있다지속적인 개선: 각 스프린트가 끝난 후 회고(Retrospective)를 진행하여 프로세스를 개선한다 ㅇ백로그(Backlog): 완료해야 할 .. 2025. 2. 18.