소프트웨어 개발

Software development
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

소프트웨어 개발은 애플리케이션, 프레임워크 또는 기타 소프트웨어 컴포넌트의 작성과 유지보수에 관련된 개념, 지정, 설계, 프로그래밍, 문서화, 테스트 및 버그 수정을 수행하는 프로세스입니다.소프트웨어 개발에는 소스코드의 작성과 유지보수가 포함되지만, 보다 넓은 의미에서는 일반적으로 계획적이고 [1]구조화된 프로세스에서 원하는 소프트웨어의 개념에서 소프트웨어의 최종 표현에 이르기까지 모든 프로세스가 포함됩니다.또한 소프트웨어 개발에는 연구, 신규 개발, 프로토타이핑, 수정, 재사용, 재설계, 유지보수 또는 소프트웨어 [2]제품의 결과로 이어지는 기타 활동이 포함됩니다.

방법론

하나의 시스템 개발 방법론이 모든 프로젝트에서 사용하기에 반드시 적합한 것은 아닙니다.이용 가능한 각 방법론은 다양한 기술적,[3] 조직적, 프로젝트 및 팀의 고려사항에 따라 특정 종류의 프로젝트에 가장 적합합니다.

소프트웨어 개발 활동

요구의 특정

소프트웨어 제품의 아이디어 출처는 풍부하다.이러한 아이디어는 잠재적인 신규 고객, 기존 고객, 제품을 거부한 판매 잠재 고객, 기타 내부 소프트웨어 개발 직원 또는 창의적인 서드파티의 인구 통계 등 시장 조사를 통해 도출될 수 있습니다.소프트웨어 제품에 대한 아이디어는 일반적으로 먼저 마케팅 담당자가 경제적 타당성, 기존 채널 배포, 기존 제품 라인에 대한 영향, 필수 기능 및 회사의 마케팅 목표에 부합하는지 여부를 평가합니다.마케팅 평가 단계에서는 비용과 시간의 전제조건이 평가됩니다.마케팅·개발 스탭에 의해 생성된 보다 상세한 정보에 근거해, 프로젝트를 한층 [4]더 추진할 필요가 있는지에 대해서는, 제1단계 초기에 결정되고 있다.

Alan M. Davis는 "Great Software Development"라는 책에서 "Requirements" 장, "The Missing Piece of Software Development"라는 하위 장에 기술되어 있습니다.

공대생들은 공학을 배우고 금융이나 마케팅에 거의 노출되지 않습니다.마케팅학과 학생들은 마케팅을 배우고 금융이나 공학에 거의 노출되지 않습니다.우리들 대부분은 한 분야에서만 전문가가 된다.설상가상으로, 우리 중 직장 내에서 학제적인 사람들을 만나는 사람은 거의 없기 때문에 모방할 역할이 거의 없습니다.그러나 소프트웨어 제품 계획은 개발 성공을 위해 필수적이며 여러 분야에 [5]대한 지식이 절대적으로 필요합니다.

계획 프로세스

계획은 모든 활동의 목표이며, 이 프로젝트에 속하는 것을 발견하기 위한 것입니다.소프트웨어 프로그램을 만들 때 중요한 작업은 요구사항 또는 요구사항 [6]분석을 추출하는 것입니다.고객은 일반적으로 최종 결과로 무엇을 원하는지 추상적으로 알고 있지만 소프트웨어가 무엇을 해야 하는지 알지 못합니다.숙련된 숙련된 소프트웨어 엔지니어는 이 시점에서 불완전하거나 모호하거나 모순되는 요건을 인식하고 있습니다.라이브 코드를 자주 시연하면 요구 사항이 잘못될 위험을 줄일 수 있습니다.

「요건의 완전성과 일관성을 확보하기 위해서 요건 국면에 많은 노력을 기울이지만, 그러한 경우는 거의 없습니다.새로운 요건이나 변화하는 요건의 영향을 최소한으로 억제할 때는 소프트웨어 설계 국면을 가장 영향력 있는 국면으로 합니다.요건의 변동성은 미래에 영향을 미치거나 이미 개발 중인 [7]노력에 영향을 미치기 때문에 어렵습니다."

소프트웨어 개발 대웹 개발

컴퓨터 프로그래밍에서 소프트웨어 개발과 웹 개발은 모두 동일한 엔지니어 또는 프로그래머와 코딩 과정을 말합니다.[8]

주의: 소프트웨어 프로그램(특히 모바일 앱)은 웹에서 작동할 수 있습니다.

소프트웨어 개발은 컴퓨터 시스템에서 사용되는 프로그램(또는 소프트웨어)에 초점을 맞추고 있습니다.소프트웨어 개발자는 소프트웨어 및 소프트웨어 컴포넌트의 개념, 작성, 프로그래밍, 일부 문서화, 테스트, 개선 및 유지보수를 책임집니다.[8]

소프트웨어 개발자(및 모바일 소프트웨어 엔지니어)는 독립 실행형 데스크톱 컴퓨터, 모바일 장치 및 해당 플랫폼용 프로그램 및 모바일 애플리케이션을 만듭니다.[8]

소프트웨어 개발자는 개발의 베스트 프랙티스뿐만 아니라 프로그래밍의 이면에 있는 이론도 이해할 필요가 있습니다.[8]

웹 개발자는 코딩 및 쓰기 마크업을 사용하여 대화형 [8]웹 페이지를 만듭니다.

웹 개발은 클라이언트 측과 서버 측 두 가지로 나눌 수 있습니다.클라이언트 측 프로그래밍은 사용자가 웹 페이지에서 직접 액세스할 수 있는 모든 요소를 담당합니다.클라이언트 측 시스템은 사용자가 웹 페이지에 원하는 작업을 지시할 수 있도록 하며 서버 측 시스템은 이러한 요청을 이행할 책임이 있습니다.[8]

서브토픽

모델 표시

TEAF의 뷰와 관점 매트릭스.

뷰 모델은 소프트웨어 개발 프로세스에서 사용되는 시스템 및 해당 환경에 대한 관점을 제공하는 프레임워크입니다.뷰의 기본 의미를 그래픽으로 표현한 것입니다.

관점과 관점의 목적은 인간 엔지니어가 매우 복잡한 시스템을 이해하고 전문 분야를 중심으로 문제의 요소를 구성할 수 있도록 하는 것이다.물리 집약적인 시스템의 엔지니어링에서 관점은 엔지니어링 [9]조직 내의 능력과 책임에 상당하는 경우가 많습니다.

비즈니스 프로세스 및 데이터 모델링

정보의 현재 상태를 그래픽으로 표현하면 사용자와 시스템 개발자에게 모두 정보를 제공할 수 있는 매우 효과적인 수단이 됩니다.

비즈니스 프로세스와 데이터 [10]모델 간의 상호 작용 예제입니다.
  • 비즈니스 모델은 모델링되는 비즈니스 프로세스와 관련된 기능과 이러한 기능을 수행하는 조직을 보여줍니다.활동 및 정보 흐름을 묘사함으로써 프로세스의 특성을 시각화, 정의, 이해 및 검증할 수 있는 기반이 구축됩니다.
  • 데이터 모델은 저장해야 할 정보의 상세를 제공하며, 최종제품이 어플리케이션용 컴퓨터 소프트웨어 코드 생성 또는 컴퓨터 소프트웨어의 제조 또는 구매 결정을 지원하기 위한 기능 사양의 작성일 때 주로 사용된다.비즈니스 프로세스와 데이터 [10]모델 간의 상호 작용 예는 오른쪽 그림을 참조하십시오.

통상, 비즈니스 분석이라고 하는, 면접을 실시한 후에 모델을 작성합니다.인터뷰는 프로세스를 설명하는 필수 정보를 추출하기 위해 설계된 일련의 질문을 하는 퍼실리테이터로 구성됩니다.인터뷰 진행자는 정보를 제공하는 사람이 참여자라는 것을 강조하기 위해 진행자라고 불립니다.진행자는 관심 있는 프로세스에 대해 어느 정도 알고 있어야 하지만, 이는 프로세스 전문가에게 질문을 하는 구조화된 방법론을 갖는 것만큼 중요하지 않습니다.일반적으로 퍼실리테이터 팀이 시설 전체에서 정보를 수집하고 모든 인터뷰 진행자의 정보 결과가 완료되면 [10]일치해야 하기 때문에 방법론은 중요하다.

이 모델은 프로세스의 현재 상태를 정의하는 것으로 개발됩니다.이 경우 최종 제품을 "있는 그대로" 스냅샷 모델이라고 부르거나 프로세스가 무엇을 포함해야 하는지에 대한 아이디어를 모아 "될 수 있는 것" 모델을 생성합니다.프로세스 및 데이터 모델의 생성을 사용하여 기존 프로세스 및 정보 시스템이 건전한지, 사소한 수정이나 개선만 필요한지, 수정 조치로서 재엔지니어링이 필요한지 여부를 판단할 수 있습니다.비즈니스 모델의 작성은 정보 프로세스를 보거나 자동화하는 방법 이상의 것입니다.분석을 사용하여 비즈니스 또는 조직의 [10]운영 방식을 근본적으로 재구성할 수 있습니다.

컴퓨터 지원 소프트웨어 엔지니어링

CASE(Computer-Aided Software Engineering)는 소프트웨어 개발에서 일련의 소프트웨어 도구와 방법을 과학적으로 응용하여 고품질, 결함 없는 유지보수가 가능한 소프트웨어 제품을 [11]만드는 것을 말합니다.또한 소프트웨어 개발 프로세스에서 [12]사용할 수 있는 자동화된 도구와 함께 정보 시스템을 개발하는 방법을 말합니다."컴퓨터 지원 소프트웨어 엔지니어링"(CASE)이라는 용어는 시스템 소프트웨어의 자동 개발에 사용되는 소프트웨어, 즉 컴퓨터 코드를 나타낼 수 있습니다.CASE 기능에는 분석, 설계 및 프로그래밍이 포함됩니다.CASE 도구는 원하는 프로그래밍 [13]언어로 구조화된 컴퓨터 코드를 설계, 문서화 및 생성하는 방법을 자동화합니다.

컴퓨터 지원 소프트웨어 시스템 엔지니어링(CASE)의 두 가지 주요 아이디어는 다음과 같습니다.[14]

  • 소프트웨어 개발 및 소프트웨어 유지보수 프로세스에서의 컴퓨터 지원 촉진
  • 소프트웨어 개발과 유지보수에 대한 엔지니어링 접근법.

일반적인 CASE 도구는 구성 관리, 데이터 모델링, 모델 변환, 리팩터링, 소스 코드 생성에 사용됩니다.

GNOME 환경용 C 및 C++ IDE인 Anjuta

모델링 언어

모델링 언어는 일관된 규칙 집합에 의해 정의된 구조에서 정보, 지식 또는 시스템을 표현하기 위해 사용할 수 있는 모든 인공 언어입니다.규칙은 구조에서 구성요소의 의미를 해석하는 데 사용됩니다.모델링 언어는 그래픽 또는 [15]텍스트 형식일 수 있습니다.

프로그래밍 패러다임

프로그래밍 패러다임은 컴퓨터 프로그래밍의 기본 스타일로, 일반적으로 프로젝트 관리 방법론(폭포나 민첩성 등)에 의해 지시되지 않습니다.패러다임은 프로그램의 요소(예: 객체, 함수, 변수, 제약)를 나타내는 데 사용되는 개념과 추상화 및 계산(예: 할당, 평가, 연속성, 데이터 흐름)을 구성하는 단계에서 다릅니다.때로는 패러다임에 의해 주장되는 개념들이 높은 수준의 시스템 아키텍처 설계에서 협력적으로 이용되기도 하고, 다른 경우에는 프로그래밍 패러다임의 범위가 특정 프로그램이나 모듈의 내부 구조로 제한되기도 한다.예: Grady Boch의 객체 지향 디자인(OOD)은 객체 지향 분석 및 디자인(OOAD)이라고도 합니다.Boch 모형에는 클래스, 객체, 상태 전환, 상호작용, 모듈 및 [16]공정의 6가지 다이어그램이 포함되어 있습니다.

「 」를 참조해 주세요.

역할과 업계

레퍼런스

  1. ^ "Application Development (AppDev) Defined and Explained". Bestpricecomputers.co.uk. 13 August 2007. Retrieved 5 August 2012.
  2. ^ DRM Associates (2002). "New Product Development Glossary". Retrieved 29 October 2006.
  3. ^ 웹 지원 E-비즈니스 시스템 개발 방법론: 커스터마이즈 프레임워크 Linda V. Knight(미국 DePaul University, DePaul University), Teresa A.Steinbach(미국 DePaul University) 및 Vince Kelen(미국 블루 울프)
  4. ^ Joseph M. Morris(2001).소프트웨어 산업회계 페이지 1.10
  5. ^ 앨런 M. 데이비스위대한 소프트웨어 토론(2004년 10월 8일), 125-128 Wiley-IEEE Computer Society 프레스
  6. ^ Ralph, P. 및 Wand, Y.A 디자인 컨셉의 정식 정의를 위한 제안 2018년 1월 27일 Wayback Machine에 보관.Lytinen, K., Loucopoulos, P., Mylopoulos, J. 및 Robinson, (에드), 디자인 요건 엔지니어링: 10년 전망: Springer-Verlag, 2009 페이지 103-136.
  7. ^ Otero, Carlos. "Software Design Challenges". IT Performance Improvement. Taylor & Francis LLC. Retrieved 19 October 2017.
  8. ^ Edward J. Barkmeyer ea (2003)시스템 통합 자동화에 관한 개념 NIST 2003.
  9. ^ a b c d Paul R. Smith & Richard Sarfaty(1993)CASE(Computer Aided Software Engineering) 툴을 사용한 구성 관리의 전략적 계획 작성.1993년 국가 DOE/청부업자 및 시설 CAD/CAE 사용자 그룹용 문서.
  10. ^ 쿤, D.L(1989)"컴퓨터 지원 소프트웨어 엔지니어링 도구를 선택하고 효과적으로 사용"연례 Westinghouse 컴퓨터 심포지엄; 1989년 11월 6-7일; Pittsburgh, Pa(미국); DOE Project.
  11. ^ P. 루코풀로스와 V. 카라코스타스(1995).시스템 요건 엔지니어링맥그로 힐.
  12. ^ 사례 2012-02-18 Wayback Machine 정의 In: Telecom Glossary 2000 Archived 2005-11-22 Wayback Machine. 2008년 10월 26일 취득.
  13. ^ K. 로빈슨(1992)소프트웨어 엔지니어링을 케이스에 넣습니다.뉴욕 : John Wiley and Sons Inc.
  14. ^ 샤오허(2007년)."그래픽 모델링 언어 표기 메타모델"인: 컴퓨터 소프트웨어 및 응용 프로그램 컨퍼런스, 2007. COMPSAC 2007 – 제1권 제31회 국제연보, 제1권 제1호, 2007년 7월 24~27일, 페이지 219-224.
  15. ^ Merx, Georges G.; Norman, Ronald J. (2006). Unified Software Engineering with Java. Prentice-Hall, Inc. p. 201. ISBN 0130473766.

추가 정보

  • Kit, Edward (1992). Software Testing in The Real World. Addison-Wesley Professional. ISBN 0201877562.
  • McCarthy, Jim (1995). Dynamics of Software Development. Microsoft Press. ISBN 1556158238.
  • Conde, Dan (2002). Software Product Management: Managing Software Development from Idea to Product to Marketing to Sales. Aspatore Books. ISBN 1587622025.
  • Davis, A. M. (2005). Just enough requirements management: Where software development meets marketing. Dorset House Publishing Company, Incorporated. ISBN 0932633641.
  • Hasted, Edward (2005). Software That Sells: A Practical Guide to Developing and Marketing Your Software Project. Wiley Publishing. ISBN 0764597833.
  • Hohmann, Luke (2003). Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley Professional. ISBN 0201775948.
  • John W. Horch (2005)."물체 조작 방법에 대한 두 가지 방향"입력: IEEE 소프트웨어. vol. 12, no. 2, 페이지 117–118, 1995년 3월.
  • Rittinghouse, John (2003). Managing Software Deliverables: A Software Development Management Methodology. Digital Press. ISBN 155558313X.
  • Wiegers, Karl E. (2005). More About Software Requirements: Thorny Issues and Practical Advice. Microsoft Press. ISBN 0735622671.
  • Wysocki, Robert K. (2006). Effective Software Project Management. Wiley. ISBN 0764596365.

외부 링크

Wikimedia Commons 소프트웨어 개발 관련 미디어