소프트웨어 개발의 모든 것에 대한 종합 가이드

게시 됨: 2020-08-13

공장 생산 현장과 소프트웨어 개발자 사무실은 얼마나 유사합니까?

컴퓨터에 코드를 입력하는 프로그래머로 가득 찬 방을 상상해 보십시오. 출력을 공장 조립 라인에서 조립된 위젯처럼 취급하면 어떻게 될까요? 생산을 극대화하는 것들이 여기에서도 작동합니까? 아니면 개발 프로세스가 다른 엔지니어링 분야와 비슷합니까?

프로젝트 관리자는 소프트웨어 개발이 시작된 이후로 이 문제를 해결하기 위해 노력해 왔습니다. 이러한 질문에서 소프트웨어 개발 수명 주기의 정의가 등장했습니다.

소프트웨어 개발이란 무엇입니까?

소프트웨어를 처음부터 만드는 과정입니다. 코드 작성이 핵심 활동이지만 그 이상입니다.

개발 프로세스에는 코드를 작성하기 전에 아이디어와 디자인이 포함됩니다. 계획은 간과하기 쉽습니다. 코드를 작성하는 방식으로 개발하는 것처럼 느껴지지 않습니다. 그러나 중요한 질문에 답하는 것이 먼저 완성품을 강화합니다. 프로젝트가 추구할 가치가 있습니까? 그렇다면 가장 좋은 방법은 무엇입니까? 어떤 기능이 필요하고 어떤 기능이 있으면 좋을까요? 답은 프로젝트의 성공 가능성을 높여줍니다.

단계는 일정하지만 응용 프로그램은 다양합니다. 소프트웨어 개발이 새로운 분야인 이유. 공학 분야는 수백 년의 역사와 함께 성숙합니다. 소프트웨어 개발은 1940년대 후반으로 거슬러 올라갑니다. 아직 새로운 학문입니다. 애자일 방법은 이제 겨우 20년이 되었습니다. 그러나 이것은 소프트웨어 생성 이론에서 일어나는 가장 영향력 있는 일 중 하나입니다. 그럼에도 불구하고 6개의 소프트웨어 개발 수명 주기 단계는 모든 시스템에 공통적입니다.

소프트웨어 개발 수명 주기(SDLC)의 6단계

개발 팀은 전체 프로젝트 또는 하나의 기능에서 소프트웨어 개발 수명 주기를 사용할 수 있습니다. SDLC 사용의 진화는 각 단계의 길이를 단축하여 위험을 줄이는 것이었습니다. 잠시 후 다양한 방법론을 살펴보겠습니다. 먼저 단계 자체를 살펴보겠습니다.

또한 단계 수 또는 이름과 관련하여 변형이 표시된다는 점에 유의할 필요가 있습니다. 개발 및 테스트와 같이 단계가 병합되는 경우가 있습니다. 다른 경우에는 계획이 계획이 되고 분석이 되는 것처럼 한 단계가 두 개로 나누어지는 것을 볼 수 있습니다. 우리의 경우 이 6가지가 단계를 명확하게 정의하므로 계속 사용하겠습니다.

1. 기획

계획 단계는 가장 중요한 단계입니다. 이해 관계자는 프로젝트 자체의 타당성을 포함하여 모든 것을 고려해야 합니다. 여기에서 전체 프로젝트를 종료해도 됩니다. 건전한 조직은 이해 관계자가 필요한 경우 그렇게 할 수 있도록 권한을 부여합니다. 프로그래머는 엔터프라이즈 환경에서 이 단계에서 덜 관여하게 됩니다. 제품 소유자, 비즈니스 분석가 및 기타 이해 관계자는 이 단계에서 자신의 요구 사항을 표명합니다.

2. 디자인

3. 개발

디자인 단계에는 사용자 경험(UX) 디자인도 포함됩니다. 응용 프로그램에 사용자 대면 구성 요소가 있는 경우 UX 디자인은 필수입니다. 여기에는 실제 사람들이 제품 모형과 상호 작용하는 것을 관찰하여 사용자 조사가 포함됩니다. 이것이 개발 단계가 아닌 설계 단계에서 발생하는 이유는 타이밍입니다. 사용자 세션에는 시간이 걸립니다. 종종 비즈니스 이해 관계자와 더 많은 앞뒤 논의가 수집된 데이터에서도 발생합니다.

4. 테스트

다음으로 개발 팀은 코드를 테스트합니다. 코드 작성자와 테스터는 다른 사람이어야 합니다. 더 나은 것은 비개발자 품질 보증 테스터입니다. 개발자는 행복한 경로 시나리오만 생각하는 경향이 있습니다. 전담 QA 테스팅 전문가는 소프트웨어를 손상시킬 수 있는 방법에 대해 더 잘 생각하는 경향이 있습니다. 이런 식으로 배포하기 전에 버그를 찾을 가능성이 더 큽니다. 그 결과 릴리스 시 보다 안정적인 소프트웨어가 제공됩니다.

자동화된 테스트와 수동 테스트

단위 테스트와 통합 테스트는 종종 자동화됩니다. 종종 DevOps 플랫폼은 마스터 분기에 병합하기 전에 새 코드에서 이러한 테스트를 실행합니다.

수동 테스트는 더 이상 쓸모가 없습니다. 자동화된 테스트는 동일한 작업을 계속 반복합니다. 그러나 수동 테스트를 수행하는 사람은 테스트 중에 실수로 버그를 찾을 수 있습니다. 강점은 수동 테스트의 가변성입니다.

단위 테스트

단위 테스트는 메서드만 확인하고 그 이상은 확인하지 않습니다. 테스트 중인 함수는 경계입니다. 개발자는 단위 테스트를 작성하고 일부 SDLC 프레임워크에서는 이를 요구합니다. 익스트림 프로그래밍은 그것들을 필요로 합니다. 또한 테스트 주도 개발을 규정합니다. 이것은 먼저 단위 테스트를 작성하는 방법입니다. 그런 다음 실제 프로그램 코드를 작성합니다.

통합 테스트

통합 테스트는 코드베이스의 섹션 또는 기능을 확인합니다. 일반적으로 DevOps 플랫폼에 의해 자동화되고 실행됩니다. 그들이 검증하는 것은 단일 방법 이상입니다. API 호출이 데이터베이스에서 새 레코드를 지속했는지 확인하는 것이 한 예입니다. API 메소드를 검증하는 단위 테스트와도 이것을 대조하십시오. 단위 테스트는 데이터베이스에 대한 호출이 발생해야 하는지 확인할 수만 있습니다. 통합 테스트는 데이터가 예상대로 애플리케이션을 통해 흘렀음을 증명할 수 있습니다.

시스템 테스트

테스트의 최종 형태는 전체 시스템 테스트입니다. 요약하자면, 단위 테스트는 기능만 검증합니다. 통합 테스트는 기능을 확인합니다. 그러나 시스템 테스트는 전체 애플리케이션을 단일 단위로 취급합니다. 연기 테스트는 시스템 테스트의 가벼운 형태입니다. 여기에서 테스터는 자연 사용자처럼 시스템과 상호 작용하고 예상대로 작동하는지 확인합니다. 보다 엄격한 전체 종단 간 시스템 테스트와 대조됩니다. 전체 시스템 테스트는 시스템의 모든 부분을 단일 엔터티로 확인합니다. 또한 통합 테스트 모음이 전체 시스템 테스트 역할을 할 수 있습니다.

5. 배포

배포 단계에서는 테스트된 코드를 프로덕션으로 푸시합니다. 배포를 자동화하면 더 안정적입니다. 또한 프로덕션 배포를 연습하면 원활한 배포의 가능성도 높아집니다. 개발 팀은 스테이징 환경이라는 테스트 환경에서 연습합니다. 생산품과 동일해야 합니다. 두 환경이 비슷할수록 실습 배포의 가치가 높아집니다.

6. 유지보수

SDLC의 이 시점까지 모든 것은 총 소유 비용의 약 4분의 1에 불과합니다. 소프트웨어의 초기 개발 비용 은 기업이 지출할 비용의 25%입니다. 유지 관리 단계에서는 총 소유 비용의 약 75%가 비즈니스에 소요됩니다. 급증하는 유지 관리 비용에 대한 방어는 초기 단계에 더 많은 주의를 기울이는 것입니다. 이것은 더 나은 기술 설계, 개발 및 더 철저한 테스트를 의미합니다. 대안은 기술 부채입니다. 실제 부채처럼 시간이 지날수록 더 비싸집니다.

5가지 주요 소프트웨어 개발 방법론

SDLC의 단계는 변경되지 않지만 구현 및 실행 순서는 다릅니다. 조직에서 소프트웨어 개발 프로세스를 수행하는 가장 일반적인 방법을 살펴보겠습니다.

1. 애자일

애자일을 독특하게 만드는 것은 사람에 대한 초점입니다. 애자일 방법론은 업계의 관심을 다시 집중시켰습니다. 이전에는 제품, 소프트웨어에 중점을 두었습니다. Agile은 이에 도전하고 프로세스를 수행하는 개인에게 집중했습니다. 또한 Agile Manifesto 이전에는 XP(Extreme Programming)와 Scrum이 연결되지 않았습니다. 그러나 그 후 그들의 실무자들은 애자일 깃발 아래 하나로 뭉쳤습니다.

애자일은 프레임워크 자체가 아닙니다. 프레임워크를 위한 프레임워크입니다. 핵심은 사람과 빠른 반복에 초점을 맞추는 것입니다. 이름 그대로 애자일입니다. 잘 하면 결과를 얻을 수 있는 유연성이 있습니다. 프로세스는 사람을 희생시키면서 수행되지 않으며 대신 가치를 창출합니다.

Agile의 또 다른 핵심 테넌트는 반복적인 접근 방식입니다. 아이디어는 더 짧은 시간에 작업 블록을 수행하는 것입니다. 그렇게 하면 비즈니스가 시장의 변화에 더 빨리 적응할 수 있습니다. 개발 방향을 빠르게 변경할 수 있는 능력이 이를 민첩하게 만듭니다. 동시에 개발 팀은 각 반복에서 수행한 작업에서 배우고 개선할 수 있습니다. 애자일 팀은 각 반복 후에 회고 회의에서 이를 수행합니다.

2. 익스트림 프로그래밍

익스트림 프로그래밍(종종 XP로 축약됨)은 1990년대 초에 시작되었습니다. Martin Fowler는 Agile Manifesto의 최초 서명자 중 한 명이었습니다. 그는 Agile이 XP 프레임워크로 인해 인기를 얻었다고 생각합니다. 또한 그는 이것이 Agile 소프트웨어 개발을 시작하는 가장 좋은 방법이라고 주장합니다.

XP는 접근 방식에서 이름을 얻었습니다. 일반적인 좋은 소프트웨어 관행을 필요로 합니다. 그것이 "극단적"인 이유입니다. XP는 단위 테스트, 페어 프로그래밍, 더 자주 릴리스와 같은 것을 요구합니다.

XP를 고유한 방법으로 만드는 것은 다음과 같습니다.

짧은 반복 주기(일반적으로 1~2주)
현재 반복에서 작업 항목 교체에 대한 개방성(스크럼에서 허용하지 않는 것)
자동화된 테스트 및 페어 프로그래밍 강조

3. 린

Lean은 기술적으로 Agile이 아니었지만 실제로는 비슷한 느낌을 받았습니다. 이제 대부분의 사람들이 Agile의 일부로 받아들입니다. 그 초점은 전통적인 Agile과 다릅니다. 애자일 선언문에 따르면 "프로세스와 도구에 대한 개인과 상호 작용" Lean은 제조사보다 소프트웨어에 더 중점을 둡니다.

그 뿌리는 Toyota의 린(Lean) 제조 원칙입니다. 다음은 그것을 정의하는 7가지 부분입니다. 제조 린(Lean)에 익숙하다면 비슷하게 들릴 것입니다. 그들은:

낭비 제거
학습 확대
최대한 늦게 결정
최대한 빨리 전달
팀의 역량 강화
무결성 구축
전체 최적화

4. 스크럼

스크럼은 가장 인기 있는 애자일 방법입니다. 14차 애자일 현황 보고서에 따르면 소프트웨어 회사의 58%가 스크럼을 사용합니다. 스컴 하이브리드를 포함하면 비율이 84%로 점프합니다. 가장 인기있는 이유는 무엇입니까?

정답은 스크럼이 더 적은 시간에 더 많은 작업을 수행하는 것입니다. 그것은 기업에 호소합니다. Scrum의 각 반복은 "스프린트"입니다. 이름은 속도에 대한 아이디어를 강화합니다. 일반적으로 스프린트는 2~3주입니다. 스크럼 팀이 스프린트를 계획한 후에는 누구도 이를 변경해서는 안 됩니다. 새로운 작업은 다음 스프린트가 시작될 때까지 기다려야 합니다. 이를 위해서는 비즈니스 이해 관계자의 징계가 필요합니다. 실제로 이 스크럼 규칙은 자주 위반됩니다. 이것이 팀이 스크럼 하이브리드를 자주 수행한다고 보고하는 이유입니다.

스크럼의 또 다른 특징은 스크럼 마스터입니다. 스프린트를 목표로 유지하도록 지명된 팀원 중 한 명입니다. 종종 스크럼 마스터는 개발 팀의 개발자입니다.

스크럼의 가장 일반적인 변형은 스크럼과 칸반의 매시업인 ScrumBan입니다. Kanban은 Lean과 같은 일본 Toyota 제조 프로세스에 뿌리를 두고 있습니다. 제시간에 작업하는 시스템입니다.

작업의 각 항목은 자체적으로 반복되는 것과 같습니다. 개발자는 한 번에 한 가지 작업만 수행합니다. 규칙은 개발자당 하나의 "진행 중인" 항목입니다. 이 엄격한 진행 중인 작업 제한은 모든 병목 지점에 빛을 비춥니다. 개발자는 Kanban 보드를 통해 진행 중인 작업 항목을 추적합니다. 참고로 이름은 여기에서 따왔습니다. 일본어로 Kanban은 "간판"을 의미합니다.

5. 폭포

폭포수 방식은 모든 소프트웨어 개발 방식 중 가장 초기입니다. Agile보다 적어도 수십 년은 앞서 있습니다. 이 방법도 이름보다 오래되었습니다.

회사가 항상 일을 하는 것은 자연스러운 방식입니다. 선형 프로세스이며 처음부터 시작합니다. 첫째, 이해 관계자는 요구 사항을 컴파일합니다. 그들은 한두 가지 기능을 위해 이것을 하지 않습니다. 아니요, 비즈니스 이해 관계자는 전체 프로젝트의 범위를 한 번에 파악합니다. 그 후, 작업이 시작됩니다. 개발자는 완료될 때까지 반복하지 않고 모든 작업을 수행합니다.

폭포수 방식은 개념적으로 가장 이해하기 쉽습니다. 사람들은 한 번에 한 가지 일을 합니다. 즉, 비즈니스 성공에 가장 위험합니다. 목표를 벗어난 것이 있으면 이해 관계자는 프로젝트가 완료될 때까지 이를 수정할 수 없습니다. 그 이유는 프로젝트가 완료될 때까지 눈치채지 못하기 때문입니다.

소프트웨어의 3가지 핵심 하위 유형

완성된 소프트웨어는 세 가지 유형 중 하나입니다. 이러한 유형은 시스템, 프로그래밍 및 응용 프로그램 소프트웨어입니다. 설명을 위해 여기 케이크를 굽는 비유가 있습니다. 믹서 또는 주걱은 프로그래밍 소프트웨어입니다. 이 비유에서 더 많은 케이크 또는 더 많은 소프트웨어 응용 프로그램을 만들 수 있습니다. 케이크를 조립할 때 맨 아래 레이어는 시스템 소프트웨어입니다. 기초입니다. 그것 없이는 레이어 케이크를 가질 수 없습니다. 그러면 최상위 계층은 응용 프로그램 소프트웨어가 됩니다. 그것은 대부분의 평범한 관찰자에게 보이는 것입니다.

시스템 소프트웨어

컴퓨터의 운영 체제는 시스템 소프트웨어입니다. 그것은 그것의 유용성에 결정적입니다. 운영 체제가 없는 컴퓨터를 상상해 보십시오. 기계어를 통해서만 상호 작용할 수 있습니다. 그것은 순수한 이진법입니다. 단지 1과 0입니다. 규모에 관계없이 작업하는 것이 불가능하다는 것을 알게 될 것입니다. 시스템 소프트웨어는 컴퓨터의 유용성을 열어줍니다.

Windows, macOS 및 Linux는 시스템 소프트웨어의 가장 인기 있는 예입니다. 장치 드라이버는 시스템 소프트웨어이기도 합니다. 운영 체제의 기본 기능을 확장합니다. 운영 체제가 없는 스마트 장치는 펌웨어를 사용하여 기능을 활성화합니다. 시스템 소프트웨어이기도 합니다.

프로그래밍 소프트웨어

프로그래밍 소프트웨어는 응용 소프트웨어의 하위 집합입니다. 개발자가 새 프로그램을 만드는 데 사용하는 모든 프로그램은 분류됩니다. 간단한 텍스트 편집기에서 복잡한 통합 개발 환경(IDE)에 이르기까지 다양합니다. 대부분의 개발자는 더 복잡한 프로그래밍 소프트웨어 도구를 선호합니다. Microsoft의 Visual Studio와 같은 프로그램은 개발 속도를 높이는 데 도움이 됩니다.

응용 소프트웨어

응용 소프트웨어는 가장 일반적인 유형입니다. 컴퓨터로 작업을 수행할 수 있게 해주는 소프트웨어입니다. 컴퓨터를 유용하게 만듭니다. 인기 있는 예는 Microsoft Word 및 Excel과 같은 프로그램입니다.

클라우드 소프트웨어도 이 범주에 속합니다. Google Docs, Dropbox, 심지어 Instagram도 애플리케이션 소프트웨어입니다. 애플리케이션 소프트웨어인지 아닌지 혼란스럽다면 여기 간단한 테스트가 있습니다. 프로그램을 실행하려면 다른 것이 필요합니까? Windows나 Android는 그렇지 않습니다. 시스템 소프트웨어입니다. PowerPoint 또는 Call of Duty와 같은 게임도 작동하려면 다른 항목을 실행해야 합니다. 즉, 응용 프로그램 소프트웨어입니다. 장치 드라이버와 운영 체제가 없으면 실행할 수 없습니다.

결론

소프트웨어 개발 방법은 아직 성숙 단계에 있습니다. 그러나 사용된 방법에 관계없이 단계는 동일하게 유지됩니다. 애자일 팀은 더 빠르게 반복할 수 있고 Waterfall 실무자는 천천히 하나에서 다음 팀으로 이동합니다. 그러나 더 나은 소프트웨어를 만들기 위해서는 각 단계의 프로세스를 강화해야 합니다. 그들은 서로를 기반으로 합니다. 소프트웨어 개발 수명 주기는 단계 중 하나가 없는 것이 아닙니다. 부분이 전체를 만듭니다.

한 발짝이라도 나가면 어떻게 되는지 생각해 보세요. 무엇을 만들고 있는지 계획하지 않고? 디자인이 없으면 개발 프로세스가 무의미해질 것입니다. 개발 단계를 생략하는 것은 불가능합니다. 테스트가 부족하면 제품이 예상대로 작동하지 않습니다. 배포가 없으면 아무도 제품을 사용할 수 없습니다. 유지 관리되지 않는 응용 프로그램은 사용하지 않게 됩니다. 각 단계는 소프트웨어 제품의 성공에 매우 중요합니다.