Разработка на софтуер

Разработката на софтуер (среща се и като разработка на приложения, софтуерен дизайн, проектиране на софтуер, разработване на приложен софтуер) е разработването на софтуерен продукт съобразен с нуждите на дадена целева група или маркетинга на един софтуерен продукт. Терминът „разработка на софтуер“ може да се използва, за да опише компютърното програмиране, което е процес на писане и поддържане на сорс код, но в по-широк смисъл на понятието се включва всичко – от концепцията на желания софтуер до крайната проява на софтуера, което в идеалния случай е планиран и структуриран процес. Следователно, разработката на софтуер може да включва изследвания, нови разработки, прототипиране, модификация, повторно използване, ре-инженеринг, поддръжка, или всякакви други дейности, чийто краен резултат е софтуерният продукт.

Софтуер може да бъде разработен по множество от причини. Трите най-общи са да отговаря на конкретните нужди на клиент/фирма (Шаблон:Lang-en), да отговаря на възприетите нужди на група от потенциални потребители (рекламен и софтуер с отворен код) или за лична употреба (например някой учен може да напише програма за автоматизиране на сложни задачи). Понякога се налага разработката на вграден софтуер, например когато се изисква процесът на разработка да бъде интегриран с разработката на контролиран физически продукт. Системният софтуер засяга приложните програми и самия процес на програмиране, поради което често се разработва отделно.

Нуждата от по-добро качество на процеса на софтуерна разработка води до началото на софтуерното инженерство, което се стреми да приложи систематичния подход, илюстриран в инженерната парадигма, към разработката на софтуер.

Съществуват много подходи към управлението на софтуерни проекти, известни като циклични модели в живота на софтуерната разработка, методологии, процеси или модели. „Моделът на водопада“ Шаблон:Lang-en е традиционният подход, а т.нар. гъвкава методология Шаблон:Lang-en разработка на софтуер е по-модерен подход.

Методологии

Софтуерната методология при разработката на софтуер (известна още като процес на разработка на софтуер, модел или цикъл от живота) е рамка, която се използва за структуриране, планиране и контролиране процеса на разработка на информационни системи. През годините са еволюирали много разновидности на такива платформи, всяка със своите отличителни предимства и недостатъци. Има няколко различни подхода в разработката на софтуер: някои използват по-структуриран, инженерен подход за разработка на бизнес решения, докато други възприемат по-частични подходи, като софтуерът се развива на части. Една системна методология на разработка на софтуер не винаги е подходяща за всички проекти. Всяка от възможните методологии е най-подходяща за определен тип проекти, в зависимост от различните технически, организационни, проектни и екипни спецификации.

Повечето методологии споделят някои от следните комбинации в разработката на софтуер:

• Анализиране на проблема
• Проучване на пазара
• Събиране на изискванията за предложеното бизнес решение
• Изработване на план или дизайн на софтуерно решение
• Писане на програмен код (имплементация)
• Тестване на софтуера
• Внедряване
• Поддръжка и оправяне на бъгове

Тези етапи често се свързват с цикъла на живот на софтуерната разработка. Различните подходи в разработката на софтуер ги използват в различна последователност или посвещават повече или по-малко време на някои от тях. Детайлите в документацията на всеки етап също може да варират. Посочените етапи могат да се свържат с подхода на „водопада“ или може да бъдат повтаряни в различни цикли (малко „по-екстремен“ подход). По-екстремният подход обикновено включва по-малко отделено време за планиране и документиране, но повече време в писане на програмен код и разработка на автоматизирани тестове. По-екстремните подходи предлагат също непрекъснато тестване по време на живота на разработка, както и работещ (или без бъгове) продукт през цялото време. По-структурираните подходи на „водопада“ се стремят да оценяват рисковете и да разработят детайлен план преди писането на програмен код, за да се избегнат значителни промени в дизайна и програмния код на по-късен етап.

Кой е най-добрият подход често зависи от типа на проблема. Ако проблемът е добре разбран и може да бъде планирано решение за дълъг период от време напред, то подходите на „водопада“ често са най-удачни. От друга страна, ако проблемът е уникален (или е такъв поне за екипа от разработчици) и структурата на софтуерното решение не може да бъде лесно визуализирана, то тогава „по-екстремните“, частични подходи биха свършили по-добра работа.

Дейности по разработката на софтуер

Спецификация

Източниците на идеи за софтуерни продукти са много. Тези идеи могат да дойдат от пазарно проучване, включващо демографията на потенциално нови клиенти, съществуващи клиенти, друг вътрешен персонал от разработчици или креативна трета страна. Идеите за софтуерни продукти се оцеяват от маркетингов специалист по отношение на икономическа изпълнимост, както и за съчетаване със съществуващи канали на разпределение, за възможни ефекти върху съществуващи продуктови линии, за необходими допълнения и за съчетаване с интересите на компанията. Цената и определеното време се преценяват във фазата на пазарно оценяване. Също в тази фаза се решава дали проектът трябва да бъде осъществен, в зависимост от по-детайлната информация, предоставена от маркетинговия състав и софтуерните разработчици.

Тъй като разработката на софтуер може да включва компромиси или пък да надмине исканията на клиента, софтуерната разработка на един проект може да изостава в нетехнически въпроси, като човешки ресурси, управление на риска, интелектуална собственост, бюджетиране и други. Тези процеси може също да причинят бизнес разработката да се застъпи за софтуерната разработка.

Планиране

Планирането е обект на всяка дейност, когато искаме да открием нещата, от които проектът има нужда. Важна задача в създаването на софтуерна програма е извличането на изискванията и техния анализ. Клиентите обикновено имат обща представа за това, какво искат като краен резултат, но не знаят какво трябва да прави софтуерът. В този етап умели и опитни софтуерни инженери разпознават непълните, двусмислени и понякога противоречиви изисквания.

След като основните изисквания са събрани от клиента, започва техния по-задълбочен анализ. Определя се обхвата на разработения продукт като се поставят конкретни задачи на проекта и се изработва съответната документация (scope document).

Някои функционалности могат да останат извън обхвата на проекта като в последствие могат да го оскъпят. Най-честа причина е неяснота по отношение на изискванията и приложението в самото начало на разработване. Ако друга компания извършва разработването и планирането, този документ може да се счита за правен документ и е част от договорните отношения. В случай на възникване на спорове и двусмислено тълкуване – какво е обещано на клиента и какво е получено като продукт, документацията по разработване на проекта (scope document) може да се приложи за изясняване и разрешаване на спорни моменти.

Дизайн

Когато изискванията се установят, дизайнът на софтуера може също да бъде установен в документ на софтуерен дизайн (Шаблон:Lang-en). Това включва предварителен или дизайн на високо ниво на главните модули с обща картина (например блок-схема) на това как се съчетават частите. Езикът, операционната система и хардуерните компоненти трябва да са ясни до този момент. След като е създаден детайлен дизайн или дизайн на ниско ниво, може да се пристъпи към доказателство за концепцията или да се потвърдят изискванията с прототип.

Имплементация, тестване и документация

Имплементацията е процесът, в който софтуерните инженери пишат програмния код на проекта.

Софтуерното тестване е интегрална и важна фаза в процеса на софтуерна разработка. Тази част от процеса осигурява разпознаването на дефектите възможно най-рано. В някои процеси, известни като тестово разработване, тестовете може да бъдат разработени преди писането на програмен код и да служат като показател за коректна имплементация.

Документирането на вътрешния дизайн на софтуера, с цел бъдеща поддръжка и подобрение, се прави по време на разработката. Това може да включва също и писането на API (Application Programming Interface), външно или вътрешно. Софтуерният инженерен процес, избран от екипа на разработчицие, решава колко вътрешна документация е необходима. Плановите модели (като waterfall) обикновено съдържат повече документация от пъргавите модели.

Внедряване и поддръжка

Внедряването започва веднага, след като кодът е подобаващо тестван, потвърден за пускане и продаден или е пласиран по друг начин. Това може да включва инсталиране, персонализиране, тестване и евентуално разширен период за оценяване.

Обучаването за работа със софтуера е важно, тъй като той е ефикасен, само ако се използва коректно.

Поддръжката и подобряването на софтуера се справят с новооткрити грешки. Също някои  изисквания може да заемат съществено време и усилия, например пропуснати изисквания може да доведат до промяна в дизайна на софтуера.

Подтеми

View model

The TEAF Matrix of Views and Perspectives.

View model е рамка, която осигурява различни viewpoints(гледни точки) върху системата и нейната среда, които да бъдат използвани в процеса на софтуерна разработка.

Целта на гледните точки и изгледите е да позволят на инженерите да разбират много сложни системи и да организират елементите на даден проблем, както и решението му. В проектирането на физически интензивни системи, гледните точки често отговарят на възможностите и отговорностите в инженерната организация.

Най-сложните системни спецификации са толкова обширни, че никой не е напълно способен да разбере всички аспекти на всички спецификации. Освен това всички имаме различни интереси в дадена система и различни причини за изследването на системните спецификации. Бизнес изпълнител би задавал по-различни въпроси относно направата на една система, отколкото човек, който е работил по имплементирането. Затова концепцията на платформата за гледните точки е да предостави различни виждания към спецификациите на една сложна система.

Бизнес процеси и модели на данни

example of the interaction between business process and data models.

Бизнес моделът илюстрира функциите, асоциирани с моделирането на бизнес процеса и организациите, отговорни за изпълнението им. С изобразяващи дейности и потоци от информация, е създадена фондация, която да визуализира, дефинира, разбере и валидира естеството на процеса.

Моделът на данните позволява детайлите на информацията да бъдат съхранени и се използва главно, когато крайният продукт е поколението на компютърен софтуерен код за апликация или подготовката на функционална спецификация, която да помогне или за правенето, или за продажбата на софтуера.

Computer-aided software engineering

Computer-aided software engineering (CASE) представлява комплект от инструменти и методи към софтуера, водещи до по-високо качество, липса на дефекти и по-добра поддръжка на софтуерните продукти. Терминът може да се свърже със софтуера, използван за автоматизация в разработката на софтуерни системи или компютърен код. Функциите на помощния софтуер включват анализ, дизайн и програмиране. Инструментите му автоматизират методите за дизайн, документация и създаване на структуриран компютърен код в желания програмен език.

Две ключови идеи в проектирането на помощен софтуер са:

• Увеличаване на компютърната помощ в разработката на софтуер, както и по-добра поддръжка
• Инженерен подход към разработката на софтуер и неговата поддръжка.

Типични помощни инструменти съществуват за управление на конфигурацията, моделиране на данни, моделиране на трансформации, рефакториране, генерация на програмен код.

Интегрирана среда за разработка

Anjuta, a C and C++ IDE for the GNOME environment

Интегрираната среда за разработка е софтуерна апликация, предоставяща разбираеми улеснения за компютърния програмист при разработката на софтуер. Обикновено една среда за разработка съдържа:

• Редактор на програмния код
• Компилатор или интерпретатор
• Инструменти за автоматизация на изпълнението
• Дебъгер (в повечето случаи)

Средите за разработка са създадени за максимална програмна продуктивност, като предлагат компоненти със сходни потребителски интерфейси. Типично за една среда е, че е посветена на един програмен език, така че да предоставя комплект от приставки, които най-добре съвпадат с програмните парадигми на езика.

Моделиращ език

Моделиращ език е всеки изкуствен език, който може да бъде използван, за да изрази информация, знания или системи в една структура, които са дефинирани в последователна група от правила. Правилата се използват за интерпретация на значението на компонентите в една структура. Моделиращият език може да бъде графичен или текстов. Графичните използват диаграмни техники с наименувани символи, които представят концепции, линии, които ги свързват с техните взаимоотношения и други графични анотации, които репрезентират ограничения. Текстовите моделиращи езици обикновено използват стандартизирани ключови думи, придружени от параметри, които да формират компютърно-интерпретативни изрази.

Примери за графични моделиращи езици в сферата на софтуерното инженерство са:

• Business Process Modeling Notation (BPMN, и XML от BPMN) е пример за процесен моделиращ език
• EXPRESS и EXPRESS-G (ISO 10303-11) е интернационален, стандартен моделиращ език за данни
• Extended Enterprise Modeling Language (EEML) е широко използван за бизнес процесно моделиране
• Flowchart е схемова репрезентация на алгоритъм или процес на стъпки
• Fundamental Modeling Concepts (FMC) е моделиращ език за софтуерно-интензивни системи
• IDEF е група от моделиращи езици, като най-значимите са IDEF0 за функционално моделиране, IDEF1X за информационно моделиране и IDEF5 за моделиране на онтологии
• LePUS3 е обектно-ориентиран, визуален, дизайн-описателен език и бивш специфициращ език, който е съвместим най-вече с моделиране на широко обектно-ориентирани (Java, C++, C#) програми и design patterns.
• Specification and Description Language (SDL) е специфициращ език, съсредоточен в недвусмислената спецификация и описание на поведението на разпределени системи
• Unified Modeling Language (UML) е general-purpose език, който е индустриален стандарт за специфициране на софтуерно-интензивни системи. UML 2.0 поддържа тринадесет различни диаграмни техники и има широко разпространен инструмент за помощ

Не всички моделиращи езици са изпълними и за тези, които са, използването им не означава че програмисти не са нужни. Вместо това, изпълнимите моделиращи езици имат за цел да разширят продуктивността на умели програмисти, така че да адресират повече сложни проблеми като паралелни изчисления и разпределителни системи.

Програмни парадигми

Програмна парадигма е фундаментален стил на компютърно програмиране, който като цяло не е воден от методология за управление на проекта. Парадигмите се различават в концепциите и абстракциите, използвани за представяне на елементите в една програма (като обекти, функции, променливи, ограничения) и в изчислителните стъпки (като оценяване, продължения, поток от данни). Понякога утвърдените от парадигмата концепции, биват използвани кооперативно в архитектурния дизайн на високо ниво в една система, в други случаи обхватът на програмната парадигма е ограничен до вътрешната структура на конкретната програма или модул.

Един програмен език може да поддържа повече от една парадигми. Например програми писани на C++ или Object Pascal може да са изцяло процедурни, изцяло обектно-ориентирани, или да съдържат елементи и от двете парадигми. Софтуерните дизайнери и програмисти решават как да бъдат използвани тези елементи. В обектно-ориентираното програмиране програмистите могат да гледат на една програма, като колекция от взаимодействащи си обекти, докато във функционалното програмиране програмата може да се разглежда като поредица от функции. Когато програмни компютри или системи с много процесори, процесно-ориентираното програмиране позволява на програмистите да гледат на апликациите като комплект от конкурентни процеси, действащи върху логически свързани структури от данни.

Както различни групи софтуерно инженерство застъпват различни методологии, така и различните програмни езици застъпват различни парадигми. Някои езици са направени да поддържат само една парадигма (Smalltalk поддържа обектно-ориентирано програмиране, Haskell поддържа функционално програмиране), докато други поддържат повече от една (например Object Pascal, C++, C#, Visual Basic, Common Lisp, Scheme, Python, Ruby and Oz).

Много парадигми са добре познати както с методите, които забраняват, така и с тези, които позволяват. Например чистото функционално програмиране забранява използването на side-effects, а структурното програмиране забранява използването на goto изявления.

Примери за парадигми на високо ниво включват:

• Aspect-oriented software development
• Domain-specific modeling
• Model-driven engineering
• Object-oriented programming methodologies
• Search-based software engineering
• Service-oriented modeling
• Structured programming
• Top-down and bottom-up design

Софтуерна платформа

Софтуерната платформа е преизползваем дизайн или имплементация за софтуерна система или подсистема. Софтуерната система може да включва подпомагащи програми, библиотеки за програмен код, език за скриптиране или друг софтуер, който да помогне да се разработят и слепят различните компоненти на софтуерния проект. Платформите могат да намалят, консолидират или стандартизират логика, както и да изпълнят имплементации без показване на тяхната интелектуална собственост или чувствително-внедрените променливи. Различни части и компоненти от платформата могат да бъдат показани, посредством API. Тези показани интерфейси се считат за публични (public) и представят общ протокол от информация и процедури. Те са обикновено показани чрез декларации, протоколи и публични методи. Голяма част от действителната имплементация на платформата не може да бъде видяна от API. Тази част от платформата се нарича частна (private). Дори платформата да бъде с програмен код със свободен достъп или физически видима за разработчика/имплементатора, public и private разделения на идентификаторите се базират на това, какво се показва на консумиращия ресурс.

Бележки

Тази страница частично или изцяло представлява превод на страницата Software development в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​ ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​