[Software Engineering] 3주차 (2)

Software Process

 

Software process is a structured set of activities required to develop a software system.

소프트웨어 프로세스는 소프트웨어 시스템을 개발하는데에 필요한 활동들의 구조화된 집합입니다.

 

Many different software processes but all involve:

많은 소프트웨어 프로세스들이 다르지만 모두 아래의 것들은 포함합니다:

• Specification: defining what the system should do
• Design and implementation: defining the organization of the system and implemention the system
• Validation: checking that it does what the customer wants
• Evolution: changing the system in response to changing customer needs

 

Software process model is an abstract representation of a process.

소프트웨어 프로세스 모델은 SW 프로세스의 추상화된 표현입니다. 프로세스 모델을 이용해 구체적인 SW 프로세스를 만들어나가면 됩니다.

 

Software Process Model

 

Software (Development) Process models = SDLC(* SW Development Life-Cycle) models(* 생명 주기 모델)

• Defining a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high-quality software, systematically.

소프트웨어 프로세스 모델은 고성능의 소프트웨어에 필요한 활동이나 작업, 분기점들을 정의합니다.

 

• Defining Who is doing What, When to do it, How to reach a certain goal.

소프트웨어 프로세스 모델은 누가 무엇을 하고, 언제 그것을 하고, 어떻게 특정한 목표에 도달할 것인지를 정의합니다.

 

다음은 소프트웨어 프로세스 모델의 변천입니다:

 

현재는 Waterfall Model과 Iterative Model로 크게 두 개로 분류하고, 각각의 모델은 적용되는 분야에 따라 유리할 수도 불리할 수도 있습니다.

 

The Waterfall Model

 

A classic software development life-cycle model proposed in 1960s:

1960년대에 제안된 클래식한 소프트웨어 프로세스 모델은 아래의 특징을 갖습니다:

 

• Suggests a systematic and sequential approach to software development.

Waterfall Model은 체계적이고 순서가 있는 소프트웨어 개발방식을 제안합니다.

 

• Has distinct/separated phases. In principle, a phase must be complete before moving onto the next phase

Waterfall Model은 구별되고 분리된 단계를 갖습니다. 원칙적으로는 현재 단계를 끝내기 전까지는 다음 단계로 넘어갈 수 없습니다.

 

• Inflexible partioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

Waterfall Model은 각각의 단계에서의 유연성이 떨어집니다. 이는 고객의 요구사항 변경에 반응하기 어렵게 만듭니다.

phases of waterfall model

 

The waterfall model is useful in situation where:

waterfall 모델은 아래와 같은 상황에서 유리합니다:

 

• Requirements are fixed early.
• Work can/should proceed to completion in a linear manner.
• Large systems engineering projects where a system is developed at several sites

요구사항이 일찍이 고정되고, 작업이 선형적인 방식으로 진행할 수 있거나 해야만 하고, 시스템이 각각의 장소, 팀에서 진행되는 경우에 유리합니다.

 

The Incremental and Evolutionary Model

 

Incremental and Evolutionary model

 

이 두 프로세스 모델은 여러 개의 개발이 동시에, 병렬적으로 이루어진다는 공통점을 갖습니다.

 

• Each increment is developed independent with each other, and integrated later(* Incremental Development)

Incremental Model에서는 우선 fixed된 SRS(* System Requirement Spectification)이 있습니다. 만약 그 SRS가 여러 components들로 분리 할 수 있다면, 각각의 requirements에 대한 개발을 진행합니다. 이때 서로 기능적으로 피드백을 주고 받을 수 있습니다.

 

• The last version is the final one to deliver(* Evolutionary Development)

Evolutionary Model은 Incremental Model과 달리 하나의 고정된 SRS가 있는것이 아닌, 개발을 계획할 때마다 SRS를 만듭니다. 그리고 나서 끝까지 진행합니다. 이때의 개발은 병렬적으로 이루어지고, 앞서 진행된 결과에 따라 추후 진행되는 개발에 영향을 미칩니다. 즉, 수정사항이 발생하면 그 수정사항들을 받아서 다시(* 다른 팀이 혹은 같은 팀이) waterfall을 진행합니다. 결국 가장 마지막에 waterfall이 진행되서 나온 결과물이 최종 결과물이 됩니다.

 

이 두 모델을 합친것이 The Incremental and Evolutionary Model입니다.

각각의 Requirements에 대해 병렬적으로 진행되며 통합은 마지막에 합니다. 그리고 수정사항이 생기면 이를 받아 다른 팀에서 다시 waterfall을 진행합니다. 가장 마지막에 나온 결과물을 통합해서 나온 시스템이 최종 시스템이 됩니다.

 

이 모델은 다음과 같은 특징들을 갖고 있습니다:

• The process is not visible: Many increments are developed concurrently. and Documentations are not easy.

프로세스를 볼 수 없습니다. 많은 waterfall들이 동시에 진행되고, 문서화도 동시에 진행되기 때문에 최종 프로세스를 보기 쉽지 않습니다.

 

• System structure tends to degrade as new increments are added: Regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.

새로운 increments들을 추가할수록, 시스템의 구조는 나빠집니다. 주기적인 변경이나 소프트웨어 변화가 심해지면 시스템의 구조에 영향을 주고, increments들을 통합하는데에 매우 어려워지고 비용이 비싸집니다.

 

The Spiral Model

 

the spiral model

 

waterfall모델의 variation입니다. 기본 waterfall모델에 risk analysis를 추가한 모델입니다.

이때 주의할 점은 위 그림이 하나의 waterfall단계를 나타낸다는 것입니다. 즉 한 바퀴 돌때마다 새로운 버전을 release하는 것이 아닌 여러 바퀴를 돌아 최종적으로 하나의 프로그램을 release하는 것입니다.

https://www.geeksforgeeks.org/software-engineering-spiral-model/

What is Spiral Model in Software Engineering? - GeeksforGeeks

 

CBD(* Component-Based Development)

 

이는 소프트웨어의 재사용에 기반을 둡니다.

• Systems ar integrated from existing components or application systems by using COTS(* Commercial-off-the shelf) systems/components

시스템들은 이미 존재하는 컴포넌트나 활용되고 있는 시스템들을 통합해서 만듭니다. 이는 COTS를 활용할 수도 있습니다.

 

• Reused elements should be configured to adapt their behaviour and functionality.

재사용되는 요소들은 기능적으로나 수행적으로 시스템에 적응되도록 구성되어야 합니다.

 

Reuse is now conceptually the standard approach for building many types of business systems.

재사용은 개념적으로 현재 많은 종류의 시스템을 만드는데에 표준 접근방식이 되었습니다.

 

재사용 가능한 컴포넌트들의 종류는 다음과 같습니다:

• Stand-alone application systems(* COTS): are configured for use in a particular environment.

독립/자립 가능한 시스템(* COTS)는 특정한 환경에서 사용하도록 구성되어있는 컴포넌트입니다.(* 돈주고 사는것)

 

• Collections of objects: are developed as a package to be integrated with component frameworks such as .NET or J2EE.

.NET이나 .J2EE와 같은 컴포넌트 프레임워크로 통합된 객체들의 집합입니다.

 

• Web services: are developed according to service standards and which are available for remote invocation.

웹 서비스를 통해 얻는 컴포넌트입니다. 이는 서비스 지향 표준에 의해 만들어지는 웹 서비스들을 통해 API를 얻을 수 있습니다.

 

CBD

 

CBD는 waterfall로 볼 수도 있고, Iterative로 볼 수도 있지만, 위 그림은 waterfall model을 기준으로 설명한 그림입니다.

 

Software discovery and Software evaluation: COTS등을 통해 component를 받아왔을 때, 이 component가 우리의 requirement랑 일치하지 않을 수 있습니다. 이를 검사하고 우리의 requirement와 맞는 component를 찾는 단계입니다.

 

Adapt components and Develop new componets: COTS의 경우 돈을 주고 사오면, binary code로 받아올 수 있습니다. 이는 debugging하기 힘들고 COTS들이 쌓였을 때 시스템이 COTS에 대한 통제력을 잃을 수도 있습니다; COTS내부를 이해하지 못하는데 쌓기만 하니까. 그렇기 때문에 가져온 components를 어떻게든 변형 시켜서 우리에 맞게 적응시키거나 그냥 아에 새롭게 컴포넌트를 개발하거나를 선택해야 합니다.

 

component의 선택에서 고려해야할 점이 있습니다. COTS는 code가 공개되지 않지만 quality는 보장합니다. 하지만 open source는 code가 공개되지만 quality를 보장할 수 없기 때문에 이를 잘 선택해야합니다.

 

장점:

• Reduced costs and risks as less software is developed from scratch
• Faster delivery and development of systems are possible

적은 비용과 위험으로 소프트웨어를 만들 수 있고, 빠르게 배포할 수 있습니다.

 

단점:

• Requirements compromises are inevitable, so system may not meet real needs of user.
• Loss of control over evolution of reused system elements

요구 사항의 변경은 필수불가결하기 때문에 해당 시스템이 실제 고객의 요구와 맞지 않을 수 있습니다. 또한 재사용된 요소들의 변경등은 통제력을 잃을 수 있습니다.

 

The Iterative Model - Agile

 

Agile

 

Agile development is an umbrella term for a group of methodologies weighting rapid prototyping and rapid development experiences. it is also lightweighing in terms of documentation and process specification.

Agile은 빠른 프로토타입 생성과 빠른 개발에 중점을 두는 방법론들의 상위 용어입니다. 이는 또한 문서화와 명세화에 중점을 두지 않습니다. Agile의 예로 XP(* eXtreme Programming, Agile보다 더 빠름), TFD(* Test First Development), TDD(* Test Driven Development)가 있습니다.

 

Agile은 Iterative(* 반복적, 여러번의 사이클을 돈다.)하고 Incremental(* 증가적, 한 번에 최종적인 하나의 프로그램을 만들지 않는다.)합니다.

 

Agile의 특징은 아래와 같습니다:

• Individual over processes and tools

개발 과정에서의 프로세스 모델이나 도구들 대신 개인이 알아서 모델이나 도구들을 잘 사용하면 됩니다.

 

• Working software over documentation

문서화하는 대신 코드가 문서입니다. Requirement Specification을 하지 않습니다. code가 바로 spec입니다. 그러기 위해서는 clean code가 필수적입니다.

 

• Customer collaboration over contract negotiation

계약대신 고객과의 적극적인 소통입니다. 빠른 개발을 목표로하는 Agile은 requirement의 수정이 있다면 개발의 속도에 맞게, 빠르게 수정해야 하기 때문에 같은 공간에서의 적극적인 고객과의 소통이 중요합니다.

 

• Responding to change over following a plan

사전에 계획된 것을 따르기 보다는 변화에 반응하는 것입니다.

 

+ 빠른 개발을 위해서는 디버깅이나 테스팅이 자동화되어야 합니다. 따라서 CTIP이나 CICD환경이 구축되어야합니다. 또한 여러번 반복하기 때문에 refactoring을 위한 clean code또한 필수적입니다. 이 또한 CTIP이나 CICD가 필요한 이유입니다.

https://m.blog.naver.com/seek316/221733285012

[IT정보] 코드 리팩토링(Code Refactoring) 개념

 

+ SRS(* Software Requirement Specification)가 없으므로 Maintenance개념이 없습니다.