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

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

При разработката на програмния продукт програмираното му е съобразено с нуждите на дадена целева потребителска група, която се интересува от създаването или подобряването на такъв софтуерен продукт и съответства на маркетинга му. Но софтуерът може да бъде разработван и по множество причини, като най-общо трите са да отговаря на конкретните нужди на потребителите, на дадена фирма или клиент (на английски: custom software или bespoke software), да отговаря на възприетите нужди на група от потенциални потребители (често софтуер с отворен код или рекламен) или дори за лична употреба (например напредналият програмист или изследовател-учен може да напише програма за автоматизиране на сложни задачи). Понякога се налага разработката и на вграден софтуер (асемблиране), например когато се изисква процесът на разработка да бъде интегриран с разработката на контролиран физически продукт. Системният софтуер засяга приложните програми и самия процес на програмиране, поради което често се разработва отделно.

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

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

Методологии

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

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

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

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

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

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

Дизайн

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

Планиране

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

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

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

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

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

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

Писане на програмен код

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

Създаване на потребителски интерфейс

Това може да включва също и писането на API (Application Programming Interface), външно или вътрешно.

Тестване и софтуерна документация

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

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

Плановите модели (като waterfall) обикновено съдържат повече документация от гъвкавите модели.

Потребителска документация

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

Имплементация

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

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

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

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

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

Подтеми

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

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

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

View model

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

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

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

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 и Oz).

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

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

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

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

Виж още

Бележки

↑ Paul R. Smith & Richard Sarfaty (1993). Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools. Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group.

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

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.

Литература

Иан Соммервилл, Инженерия программного обеспечения ( Software Engineering ) 6-е изд, стр. 642, Москва, 2002

[SS93-1] Paul R. Smith & Richard Sarfaty (1993). Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools. Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group.

[1]