향후 소프트웨어 발전 방향

소프트웨어 공학은 어떻게 발전할 것인가?

앞으로 몇 년 안에 다음과 같은 추세가 나타날 것이라고 생각합니다. ● 요구사항 엔지니어링은 전문적인 역할, 점점 더 복잡해지는 비즈니스 혁신, 전 세계적으로 분산된 팀 및 인터넷 수준의 전달 속도 등 점차적으로 뜨거운 주제가 되었습니다. 요구사항 획득의 정확성과 효율성에 대한 더 높은 요구사항을 제시했습니다. 요구사항 엔지니어링의 연구 및 구현이 가까운 미래에 뜨거운 주제가 될 것이며 유스케이스 기술이 보다 광범위하고 정확하게 적용될 것이며 관련이 있을 것으로 예상합니다. 도구 연구 및 개발도 핫스팟이 될 것입니다(예: IBM RationalRequirements Composer, Ravenflow 등). 유스 케이스의 장점은 본질적으로 블랙박스라는 것입니다. 자연어를 사용하여 사용자와 대상 시스템 간의 상호 작용을 추상화하고 유스 케이스를 실제로 이해할 수 있도록 분석, 설계 및 구현 세부 사항이 혼합되는 것을 방지합니다. 특정 기술을 이해하지 못하는 비즈니스 및 테스터가 이해합니다. 동시에 요구 사항 분석가는 사용 사례 분석(즉, 분석 클래스를 사용하여 이상적인 방식으로 사용 사례를 구현하려고 시도)을 통해 요구 사항 시스템을 분석 모델로 쉽게 구체화할 수 있습니다. 이 프로세스에서 요구 사항 분석가는 요구 사항을 오염시키는 분석 모델에 대해 걱정하지 않고 사용 사례를 기반으로 요구 사항 시스템을 더욱 개선할 수 있으므로 요구 사항과 분석의 분리 및 효과적인 상호 작용을 달성할 수 있습니다. ● DSSA 및 MDD, 오래된 나무의 새로운 꽃(도메인 기반 아키텍처(DSSA) 및 모델 기반 개발(MDD)): 소프트웨어 애플리케이션의 인기가 높아짐에 따라 소프트웨어는 수동 프로세스 자동화를 넘어 비즈니스 혁신의 주요 동인입니다. 따라서 특정 분야에서 가장 발전된 요구 사항과 구현 아키텍처를 포착하는 DSSA의 도입은 업계 고객에게 인기 있는 지점 중 하나가 되었습니다. 또한 DSSA의 도입으로 MDD 임계값이 크게 낮아졌으며 DSSA 기반의 MDD 지원 도구 개발이 가능해졌습니다. 이는 개발 효율성을 크게 향상시키고 소프트웨어 품질을 보장할 수 있습니다. 예를 들어 Telelogic의 Rhapsody는 성공적인 실시간 임베디드 시스템 아키텍처입니다. MDD 도구 기반). ● Iterative/Agile, 점차 표준이 됨: 소프트웨어 제공 주기가 가속화됨에 따라 반복 개발은 대부분의 소프트웨어 개발 팀에게 필수가 되었습니다. 그러나 반복은 전체 팀의 요구 사항, 아키텍처, 협업 및 테스트 기능에 대한 더 높은 요구 사항을 제시했습니다. 이제 많은 개발 팀이 반복 개발 방법을 도입하려고 시도하고 있지만 그 범위는 넓습니다. 애자일은 실제로 반복 개발보다 더 큽니다. 애자일의 세 가지 요소는 반복 개발, 개방형 협업, 적응성입니다. 솔직한 협력은 실제로 애자일의 본질입니다. Ivar가 말했듯이 애자일은 실제로 사회 공학에 관한 것입니다. Agile의 주요 기여는 개발자의 작업 열정을 자극하는 방법에 대해 더 많이 생각한다는 것입니다. 이는 수십 년 동안 소프트웨어 엔지니어링이 개발되는 동안 상대적으로 무시되었던 영역입니다. ● 지속적인 통합, 즉시 사용 가능: 지속적인 통합은 반복 개발의 품질을 보장하는 주요 방법입니다. 지속적인 통합을 통해 자동화된 방법을 사용하여 가능한 한 빨리 자동으로 코드 품질을 보장할 수 있습니다. 반복과 민첩성의 인기로 인해 지속적인 통합 관련 도구는 시장에서 새로운 핫스팟이 되었습니다(예: 지속적인 통합 프레임워크 IBM Rational BuildForge, 오픈 소스 소프트웨어 CruiseControl, 코드 정적 분석 도구 Klocwork Insight, IBM Rational Software Analyser, 등.). 지속적인 통합은 복잡한 시스템 엔지니어링입니다. 조직은 먼저 기존 구성 관리/변경 관리 도구를 빌드 환경과 긴밀하게 통합하고 자동화된 빌드 프로세스를 완료한 다음 기업/프로젝트/제품의 현재 상태를 기반으로 방법을 정의해야 합니다. 소프트웨어 품질(코드 정적 분석, 단위 테스트 또는 연기 테스트)을 자동으로 감지하고 자동으로 생성되어야 하는 관리 보고서를 정의합니다. ● 실무 기반 프로세스 프레임워크의 대세: 개발 역할의 전문화와 유통의 세계화로 인해 소프트웨어 개발 프로세스가 더욱 표준화되어야 하고, Agile에서는 프로세스가 프로젝트의 실제 요구 사항과 밀접하게 일치해야 하므로 기존의 통합된 프로세스는 이러한 요구를 충족할 수 없습니다. 차세대 프로세스는 실무 중심이 될 것이며 프로젝트는 필요한 다양한 실무를 조합하여 프로젝트 요구 사항에 가까운 프로세스를 얻을 수 있습니다. IJI(Ivar Jacobson International)의 EssWork 프레임워크와 IBM Rational의 RMC는 모두 차세대 실무 기반 프로세스 프레임워크입니다. 프로세스 전문가의 오랜 경험을 바탕으로 전체 개발 프로세스를 매우 신중하게 구성 요소화하고 개별적으로 가져와 함께 조립할 수 있는 개발 프로세스에서 사례를 추상화함으로써 단계별 개선 공식 프로세스 개선이 가능해집니다.

소프트웨어 조직의 경우 상대적으로 성숙한 소프트웨어 개발 프로세스가 확립되었지만 이 프로세스가 모든 프로젝트의 실제 요구에 적합하지 않다고 생각되면 이제 고려할 수 있는 것은 실용적인 방법을 사용하여 기존 프로세스를 재구성하는 것입니다. 이를 통해 프로젝트 팀은 실제 프로젝트에 적합한 프로세스를 구성할 수 있으며, 또한 조직은 조직에 적용할 수 있는 인기 있는 업계 관행을 IJI 전문가가 최고의 경험을 통해 학습할 수 있습니다. 업계의 8가지 사례, 구성 관리를 추출했습니다.

어제: 개발 팀의 규모가 줄어들면서 구성 관리의 복잡성이 크게 줄어들고 점점 더 많은 사용자가 구성 관리를 사용하는 것으로 나타났습니다. 오픈 소스 구성 관리 도구(예: Subeverison, JIRA, 호스팅 프로젝트 등)는 전체 수명 주기 관리 플랫폼(애플리케이션 수명 주기 관리)의 형태로 더 많이 등장하여 단일 구성 관리 기능과 강조점을 약화시킵니다. 전체 프로세스의 통합(예: Microsoft VisualStudio Team System 및 IBM Rational Team Concert 등)에 대해 설명합니다. 구성 관리의 복잡성이 줄어들었음에도 불구하고 여전히 개발 프로젝트 관리를 위한 가장 중요한 지원 플랫폼 중 하나입니다. 현재 초점은 구성 관리 지식에 대한 프로젝트 관리자의 교육을 강화하여 구성 관리 기능(예: 병렬 개발, 기준선 롤백 등)이 프로젝트 개발 프로세스에 어떻게 도움이 될 수 있는지 이해하고 이를 통해 구성 관리 도구를 만드는 것입니다. /environment 값을 최대한 활용할 수 있습니다.