Уикипедия

Разработка на софтуер: Разлика между версии

Интерактивен преглед на историята
← По-стара редакцияПо-нова редакция →
Изтрито е съдържание Добавено е съдържание
ВизуаленУикитекст
Редакция без резюме
форматиране: 2x нов ред, 2x тире, 6lokavica, А|А, интервали, кавички (ползвайки Advisor.js)
Ред 1:
'''Разработката на софтуер''' (среща се и като '''разработка на приложения''', '''софтуерен дизайн''', '''проектиране на софтуер''', '''разработване на приложен софтуер''') е разработването на [[софтуер]]ен продукт съобразен с нуждите на дадена целева група или маркетинга на един софтуерен продукт. Терминът "разработка„разработка на софтуер"софтуер“ може да се използва, за да опише [[програмиране|компютърното програмиране]], което е процес на писане и поддържане на [[сорс код]], но в по-широк смисъл на понятието се включва всичко - – от концепцията на желания софтуер до крайната проява на софтуера, което в идеалния случай е планиран и структуриран процес. Следователно, разработката на софтуер може да включва [[изследвания]], нови разработки, прототипиране, модификация, повторно използване, ре-инженеринг, поддръжка, или всякакви други дейности, чийто краен резултат е софтуерният продукт.
 
[[Софтуер]] може да бъде разработен по множество от причини. Трите най-общи са да отговаря на конкретните нужди на клиент/фирма ([[:en:custom software|custom software]]), да отговаря на възприетите нужди на група от потенциални потребители (рекламен и [[:en:open source software|open source software]]) или за лична употреба (например някой учен може да напише програма за автоматизиране на сложни задачи). Вградената разработка на софтуер е разработката на вграден софтуер. Например, ако е използван софтуер за контрол на консуматорските продукти, се изисква процесът на разработка да бъде интегриран с разработката на контролиран физически продукт. Системният софтуер засяга апликации и самия процес на [[програмиране]], поради което често се разработва отделно.
Ред 24:
 
== Дейности на разработката на софтуер ==
 
=== Спецификация ===
Източниците на идеи за софтуерни продукти са много. Тези идеи могат да дойдат от [[:en:Market_research|пазарни проучвания]], включващи [[:en:Demographics|демография]] на потенциално нови клиенти, съществуващи клиенти, друг вътрешен персонал от разработчици или креативна трета страна. Идеите за софтуерни продукти са първо оценени от [[:en:Marketing|маркетингов]] личен състав за икономическа изпълнимост, за съчетаване със съществуващи канали на разпределение, за възможни ефекти върху съществуващи продуктови линии, за нужни допълнения и за съчетаване с интересите на компанията. Цената и определеното време се преценят във фазата на пазарно оценяване, . Рано в тази фаза, в зависимост от по-детайлната информация, предоставена от маркетинговия състав и софтуерните разработчици, се решава  дали проектът трябва да бъде осъществен.
Line 35 ⟶ 34:
След като основните изисквания са събрани от клиента, започва техния по-задълбочен анализ. Определя се обхвата на разработения продукт като се поставят конкретни задачи на проекта и се изработва съответната документация (scope document).
 
Някои функционалности могат да останат извън обхвата на проекта като в последствие могат да го оскъпят. Най-честа причина е неяснота по отношение на изискванията и приложението в самото начало на разработване. Ако друга компания извършва разработването и планирането, този документ може да се счита за правен документ и е част от договорните отношения. В случай на възникване на спорове и двусмислено тълкуване - – какво е обещано на клиента и какво е получено като продукт, документацията по разработване на проекта (scope document) може да се приложи за изясняване и разрешаване на спорни моменти.
 
=== Дизайн ===
Line 45 ⟶ 44:
[[:en:Software testing|Софтуерното тестване]] е интегрална и важна фаза в процеса на софтуерна разработка. Тази част от процеса осигурява разпознаването на дефектите възможно най-рано. В някои процеси, известни като тестово разработване, тестовете може да бъдат разработени преди писането на програмен код и да служат като показател за коректна имплементация.
 
[[:en:Software documentation|Документирането]] на вътрешния дизайн на софтуера, с цел бъдеща поддръжка и подобрение, се прави по време на разработката. Това може да включва същoсъщо и писането на [[:en:API|API]] (Application Programming Interface), външно или вътрешно. Софтуерният инженерен процес, избран от екипа на разработчицие, решава колко вътрешна документация е необходима. Плановите модели (като [[:en:Waterfall model|waterfall]]) обикновено съдържат повече документация от [[:en:Agile software development|пъргавите]] модели.
 
=== Внедряване и поддръжка ===
Line 55 ⟶ 54:
 
== Подтеми ==
 
=== View model ===
[[File:TEAF Matrix of Views and Perspectives.jpg|thumb|360px|The [[TEAF]] Matrix of Views and Perspectives.]]
Line 65 ⟶ 63:
 
=== Бизнес процеси и модели на данни ===
[[File:Process and data modeling.svg|thumb|360px|example of the interaction between business process and data models.<ref name="SS93"> Paul R. Smith & Richard Sarfaty (1993). [http://www.osti.gov/energycitations/servlets/purl/10160331-YhIRrY/ 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.</ref>]]
[[:en:business model|Бизнес моделът]] илюстрира функциите, асцориираниасоциирани с моделирането на бизнес процеса и организациите, отговорни за изпълнението им. С изобразяващи дейности и потоци от информация, е създадена фондация, която да визуализира, дефинира, разбере и валидира естеството на процеса.
 
[[:en:data model|Моделът на данните]] позволява детайлите на информацията да бъдат съхранени и се използва главно, когато крайният продукт е поколението на компютърен софтуерен код за апликация или подготовката на функционална спецификация, която да помогне или за правенето, или за продажбата на софтуера.
Line 76 ⟶ 74:
* Увеличаване на компютърната помощ в разработката на софтуер, както и по-добра поддръжка
* Инженерен подход към разработката на софтуер и неговата поддръжка.
 
Типични помощни инструменти съществуват за [[:en:configuration management|управление на конфигурацията]], [[:en:data modeling|моделиране на данни]], [[:en:model transformation|моделиране на трансформации]], [[:en:refactoring|рефакториране]], [[:en:source code generation|генерация на програмен код]].
 
Line 88 ⟶ 87:
 
=== Моделиращ език ===
[[:en:modeling language|Моделиращ език]] е всеки [[:en:artificial language|изкуствен език]], който може да бъде използван, за да изрази информация, знания или системи в една структура, които са дефинирани в последователна група от правила. Правилата се използват за интерпретация на значението на компонентите в една структура. Моделиращият език може да бъде графичен или текстов. Графичните използват [[:en:diagramming technique|диаграмни техники]] с наименованинаименувани символи, които репрезентиратпредставят концепции, линии, които ги свързват с техните взаимоотношения и други графични анотации, които репрезентират ограничения. Текстовите моделиращи езици обикновено използват стандартизирани ключови думи, придружени от параметри, които да формират компютърно-интерпретативни изрази.
 
Примери за графични моделиращи езици в сферата на софтуерното инженерство са:
* [[:en:Business Process Modeling Notation|Business Process Modeling Notation]] (BPMN, и [[XML|XML]] от BPMN) е пример за процесен моделиращ език
* [[:en:EXPRESS (data modeling language)|EXPRESS]] и EXPRESS-G (ISO 10303-11) е интернационален, стандартен моделиращ език за данни
* [[:en:Extended Enterprise Modeling Language|Extended Enterprise Modeling Language]] (EEML) е широко използван за бизнес процесно моделиране
Line 99 ⟶ 98:
* [[:en:LePUS3|LePUS3]] е [[:en:object-oriented|обектно-ориентиран]], визуален, дизайн-описателен език и [[:en:formal specification|бивш специфициращ]] език, който е съвместим най-вече с моделиране на широко обектно-ориентирани ([[:en:Java (programming language)|Java]], [[:en:C++|C++]], [[:en:C Sharp (programming language)|C#]]) програми и [[:en:design patterns|design patterns]].
* [[:en:Specification and Description Language|Specification and Description Language]] (SDL) е специфициращ език, съсредоточен в недвусмислената спецификация и описание на поведението на разпределени системи
* [[:en:Unified Modeling Language|Unified Modeling Language]] (UML) е [[:en:general-purpose modeling|general-purpose]] език, който е индустриален стандарт за специфициране на софтуерно-интензивни системи. UML 2.0 поддържа тринайсеттринадесет различни диаграмни техники и има широко разпространен инструмент за помощ
Не всички моделиращи езици са изпълними и за тези, които са, използването им не означава че програмисти не са нужни. Вместо това, изпълнимите моделиращи езици имат за цел да разширят продуктивностапродуктивността на умели програмисти, така че да адресират повече сложни проблеми като [[:en:parallel computing|паралелни изчисления]] и [[:en:distributed system|разпределителни системи]].
 
=== Програмни парадигми ===
[[:en:programming paradigm|Програмна парадигма]] е фундаментален стил на компютърно програмиране, който като цяло не е воден от методология за управление на проекта. Парадигмите се различават в концепциите и абстракциите, използвани за представяне на елементите в една програма (като обекти, функции, променливи, ограничения) и в изчислителните стъпки (като оценяване, продължения, поток от данни). Понякога утвърдените от парадигмата концепции, биват използвани кооперативно в архитектурния дизайн на високо ниво в една система, в други случаи обхватът на програмната парадигма е ограничен до вътрешната структура на конкретната програма или модул.
 
Един програмен език може да поддържа [[:en:multi-paradigm programming language|повече от една парадигми]]. Например програми писани на [[:en:C++|C++]] или [[:en:Object Pascal|Object Pascal]] може да са изцяло [[:en:procedural programming|процедурни]], изцяло обектно-ориентирани, или да съдъжатсъдържат елементи и от двете парадигми. Софтуерните дизайнери и програмисти решават как да бъдат използвани тези елементи. В [[:en:object-oriented programming|обектно-ориентираното програмиране]] програмистите могат да гледат на една програма, като колекция от взаимодестващивзаимодействащи си обекти, докато във [[:en:functional programming|функционалното програмиране]] програмата може да се разглежда като поредица от функции. Когато програмни компютри или системи с много процесори, [[:en:process-oriented programming|процесно-ориентираното програмиране]] позволява на програмистите да гледат на апликациите като комплект от конкурентни процеси, действащи върху логически свързани [[:en:data structures|структури от данни]].
 
Както различни групи софтуерно инженерство застъпват различни методологии, така и различните програмни езици застъпват различни парадигми. Някои езици са направени да поддържат само една парадигма ([[:en:Smalltalk|Smalltalk]] поддържа обектно-ориентирано програмиране, [[:en:Haskell (programming language)|Haskell]] поддържа функционално програмиране), докато други поддържат повече от една (например [[:en:Object Pascal|Object Pascal]], [[:en:C++|C++]], [[:en:C Sharp (programming language)|C#]], [[:en:Visual Basic|Visual Basic]], [[:en:Common Lisp|Common Lisp]], [[:en:Scheme (programming language)|Scheme]], [[:en:Python (programming language)|Python]], [[:en:Ruby (programming language)|Ruby]] and [[:en:Oz (programming language)|Oz]]).
Line 122 ⟶ 121:
 
=== Софтуерна платформа ===
[[:en:software framework|Софтуерната платформа]] е преизползваем дизайн или имплементация за софтуерна система или подсистема. Софтуерната система може да включва подпомагащи програми, [[:en:library (computer science)|библиотеки]] за програмен код, [[:en:scripting language|език за скриптиране]] или друг [[:en:software|софтуер]], който да помогне да се разработят и слепят различните компоненти на софтуерния проект. Платформите могат да намалят, консолидират или стандартизират логика, както и да изпълнят имплементации без показване на тяхната интелектуална собственост или чувствително-внедрените променливи. Различни части и компоненти от платформата могат да бъдат показани, посредством [[:en:application programming interface|API]]. Тези показани интерфейси се считат за публични (public) и представят общ протокол от информация и процедури. Те са обикновено показани чрез декларации, протколипротоколи и публични методи. Голяма част от действителната имплементация на платформата не може да бъде видяна от API. Тази част от платформата се нарича частна (private). Дори платформата да бъде с програмен код със свободен достъп или физически видима за разработчика/имплементатора, public и private разделения на идентификаторите се базират на това, какво се показва на консумиращия ресурс.
 
== Бележки ==
<references />
{{Превод от|en|Software development|683279988}}
 
[[Категория:Разработка на софтуер| ]]
Взето от „https://bg.wikipedia.org/wiki/Разработка_на_софтуер“.