[Challenge / day-7] 소프트웨어 개발주기

study/Challenge

[Challenge / day-7] 소프트웨어 개발주기

creatorAron 2023. 2. 26. 17:52

오늘의 공부범위 : 강의 9-10강 내용(Part1. ch2. 5강 - 끝)

소프트웨어 개발주기

왜 알아야 할까?

소프트웨어 개발 주기는 소프트웨어 개발에서 가장 근본적인 프로세스이자 프레임 워크입니다. 소프트웨어 개발 주기를 이해하면, 프로젝트의 각 단계를 체계적으로 관리하고, 소프트웨어 개발과 유지 보수의 업무를 보다 효율적으로 수행할 수 있습니다.

실무에서도 소프트웨어 개발 주기를 기반으로 프로젝트를 진행합니다. 이를 통해 팀원들은 프로젝트의 진행 상황을 파악하고, 업무를 효율적으로 수행할 수 있습니다.

또한, 사이드 프로젝트도 이 개발 주기를 기반으로 진행해야 체계적으로 진행하고, 더 좋은 품질의 제품을 개발할 수 있습니다. 개발 주기를 이해하면, 각 단계에서 무엇을 해야 하는지 명확히 알 수 있으며, 이는 제품의 품질 향상에 큰 영향을 미칩니다.

SDLC (Software Development Life Cycle)

소프트웨어 개발주기는 구글 검색을 통해 찾아봐도 거의 동일하다. 강의자료와 비슷한 이미지를 찾아서 첨부하였다.

1. 기획

요구사항을 수집하고 프로젝트를 기획하는 단계입니다. 여러 채널을 통해 데이터를 수집하는 과정은 매우 중요하며 기초적인 단계입니다. 사용자 설문, 마케팅 요구사항 등 다양한 채널을 활용하여 요구사항을 수집하는 방법이 있습니다.
이후 QA(Quality Assurance)를 위한 요구사항과 프로젝트가 가질 수 있는 리스크를 판단합니다. 미리 예측하여 대처할 수 있는 문제들을 파악하고 대처해나가는 것이 중요합니다.

2. 분석

제품의 요구사항을 정의하는 단계입니다.
SRS (Software Requirement Specification)에 기록합니다. SRS란 디자인/구현해야 할 소프트웨어의 모든 요구사항을 기록해 둔 명세서입니다. IEEE에서 제공하는 SRS 템플릿을 활용할 수 있습니다. https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc

3. 디자인

시스템을 디자인하고 설계하는 단계입니다.
이 단계에서는 시스템의 구조와 인터페이스를 설계합니다. 안정적인 시스템을 만들기 위해서는 신중하게 설계해야 합니다.

4. 구현

디자인을 기반으로 개발자가 코드로 기능을 구현하는 단계입니다.
이 단계에서는 디자인한 시스템을 실제로 개발하며, 디자인 단계에서 정한 요구사항을 충족시키도록 코드를 작성합니다.

5. 테스팅 및 배포

구현 내용이 요구사항을 충족하는지 검증하는 단계입니다.
프로젝트/비지니스 성격에 따라 베타 오픈, 특정 시간에 오픈하거나, 프로젝트의 성격에 맞는 적절한 배포 방식을 선택합니다.

6. 유지 보수

제품을 마켓에 배포하고 서비스를 모니터링 하면서 유지보수 하는 단계입니다.
제품 출시 후에도 문제점이 발생할 수 있으므로 유지보수를 통해 제품의 안정성과 신뢰성을 유지합니다.

소프트웨어 개발 방법론

여러가지 방법론이 있지만 대표적인 두 가지 방법에 대해서 알아보도록 하자.

Waterfall

전통적인 개발 모델로 프로젝트 기간 동안 SDLC의 주기를 한 사이클만 돈다. 즉, 모든 단계를 완벽하게 준비하고 진행해서 모든 기능의 배포를 한 번에 한다는 것. 이 방법론은 대규모, 장기간의 프로젝트에서 많이 사용된다.

이 방법론은 매우 체계적이고 계획을 잘 세워서 개발을 진행할 수 있다는 장점이 있습니다. 하지만, 요구사항 변경에 대응하기가 어렵고, 위험 관리도 어렵습니다.

Agile

등장 배경

소프트웨어의 요구사항은 개발 도중 자주 변경됩니다. 예측하기 어렵기 때문에, 계획과 형식에 지나치게 의존할 경우 전체적인 개발의 흐름이 느려집니다.

아무 계획이 없이 개발하는 것과 지나치게 많은 계획을 세우고 개발하는 방법들 사이에서 타협점을 찾고자 고안됐습니다. 이 방법론은 빠르게 변화하는 시장에서 적응적으로 개발하기에 이상적입니다.

이 방법론은 기본적으로 프로젝트를 작은 단위로 나눠서 진행하고, 이론보다는 실제적인 결과물에 초점을 맞춥니다. 이로 인해 개발자와 고객 간의 소통이 원활하게 이루어집니다.

특징

일정한 주기를 가지고 프로토타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 소프트웨어를 개발해 나가는 실용적인 스타일. 이 방법론은 빠른 개발을 할 수 있고, 고객의 요구사항을 빠르게 반영할 수 있다는 장점이 있습니다. 또한, 작은 단위로 개발하다 보니 위험도 낮습니다. 하지만, 이 방법론을 사용할 때에는 개발자와 고객 간의 소통이 중요한 역할을 합니다.

Agile을 적용한 방법 중에서도 여러가지 방법이 있으며 크게 두가지를 알아봤다.

Agile Development

Agile 개발 방법론은 소프트웨어 개발 생명주기를 단계별로 진행하는 대신, 반복적으로 개발하며, 사용자의 요구사항을 반영해 나가는 방법을 사용합니다.
Extreme Programming (XP)은 1~2주 단위로 개발-데모를 프로젝트가 끝날 때까지 반복합니다. 이 방법론은 설계, 구현, 프로토타이핑을 전체 개발 기간에 걸쳐 조금씩 자주 실시하도록 하는 개발 방법입니다.
Scrum은 주기적인 데모 대신 Sprint 목표를 달성하는 것에 촛점을 둔 프로세스로, 2~4주 단위의 스프린트를 운영합니다. Grooming 미팅에서 Backlog에 쌓인 task들에 대해 팀원들끼리 논의를 해서, 해당 task의 size estimation과 우선 순위를 정합니다. Planning 미팅에서는 Product Backlog에서 Sprint 기간 동안 할 수 있는 일을 팀원들끼리 결정하고 할당합니다. Daily Scrum은 매일 팀원들 끼리 모여 전 날 어떤 일을 했는지, 오늘 어떤 일을 할 것인지, blocker가 있는지에 대해 간단하게 공유합니다. 회고 미팅에서는 스프린트가 끝난 후 팀원들 끼리 모여 스프린트에서 잘 된 것들, 개선되면 좋을 것들을 논의해서 다음 스프린트에 반영할 수 있도록, 협업을 더 잘 하기 위한 시간을 가집니다.
위 방법론들은 각각의 장점과 특징을 가지고 있기 때문에, 프로젝트의 성격에 맞게 선택하여 사용할 수 있습니다.

사이드 프로젝트에 적용할 것들..!!

여러가지 방법론을 배웠지만 무엇을 적용할지 선별해서 적합한 방법론을 적용하는 것이 성공적인 사이드 프로젝트 진행에 매우 중요할 것이다.

일단 이번 강의에서 소프트웨어 개발주기 한 사이클을 쭉 따라가면서 필요한 기술을 배우고, 과제(숙제 - homework 같은 느낌이다)를 수행하면서 사이드 프로젝트를 할 수 있는 힘을 기를 것이다.

지난번에 틀을 완성해놓은 노션 페이지에서 한 파트를 예로 들자면,

기획과정 중 아이디어를 정리하는 문서를 만들었는데 그 안을 이렇게 채워나가면서 기획 - 디자인 - 개발까지 전부해보고 배포 - 유지보수까지 배울 것이다.

배포나 유지보수까지 체계적으로 배울 기회는 많지 않아서 이번 기회에 집중해서 배우고 실제 사이드 프로젝트도 팀원들을 모아서 해보면서 실전경험까지 채우면 개발자로서 많은 성장을 할 수 있을 것 같아 기대된다..!!🙂🙂🙂