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

Изтрито е съдържание Добавено е съдържание
м без част от :en препратките; форматиране: интервал, нов ред, тире-числа (ползвайки Advisor)
Редакция без резюме
Ред 44:
Имплементацията е процесът, в който софтуерните инженери пишат програмния код на проекта.
 
[[:en:Software testing|Софтуерното тестване]] е интегрална и важна фаза в процеса на софтуерна разработка. Тази част от процеса осигурява разпознаването на дефектите възможно най-рано. В някои процеси, известни като тестово разработване, тестовете може да бъдат разработени преди писането на програмен код и да служат като показател за коректна имплементация.
 
[[:en:Software documentation|Документирането]] на вътрешния дизайн на софтуера, с цел бъдеща поддръжка и подобрение, се прави по време на разработката. Това може да включва също и писането на [[:en:API|API]] (Application Programming Interface), външно или вътрешно. Софтуерният инженерен процес, избран от екипа на разработчицие, решава колко вътрешна документация е необходима. Плановите модели (като [[:en:Waterfall model|waterfall]]) обикновено съдържат повече документация от [[:en:Agile software development|пъргавите]] модели.
 
=== Внедряване и поддръжка ===
[[:en:Software deployment|Внедряването]] започва веднага, след като кодът е подобаващо тестван, потвърден за пускане и продаден или е пласиран по друг начин. Това може да включва инсталиране, персонализиране, тестване и евентуално разширен период за оценяване.
 
Обучаването за работа със софтуера е важно, тъй като той е ефикасен, само ако се използва коректно.
 
[[:en:Software maintenance|Поддръжката]] и подобряването на софтуера се справят с новооткрити грешки. Също някои изисквания може да заемат съществено време и усилия, например пропуснати изисквания може да доведат до промяна в дизайна на софтуера.
 
== Подтеми ==
=== View model ===
[[File:TEAF Matrix of Views and Perspectives.jpg|thumb|360px|The [[TEAF]] Matrix of Views and Perspectives.]]
[[:en:view model|View model]] е рамка, която осигурява различни [[:en:View model|viewpoints]](гледни точки) върху системата и нейната [[:en:environment (systems)|среда]], които да бъдат използвани в процеса на софтуерна разработка.
 
Целта на гледните точки и изгледите е да позволят на инженерите да разбират много сложни системи и да организират елементите на даден проблем, както и решението му. В проектирането на физически интензивни системи, гледните точки често отговарят на възможностите и отговорностите в инженерната организация.
 
Най-сложните системни спецификации са толкова обширни, че никой не е напълно способен да разбере всички аспекти на всички [[:en:specification|спецификации]]. Освен това всички имаме различни интереси в дадена система и различни причини за изследването на системните спецификации. Бизнес изпълнител би задавал по-различни въпроси относно направата на една система, отколкото човек, който е работил по имплементирането. Затова концепцията на платформата за гледните точки е да предостави различни виждания към спецификациите на една сложна система.
 
=== Бизнес процеси и модели на данни ===
[[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|Моделът на данните]] позволява детайлите на информацията да бъдат съхранени и се използва главно, когато крайният продукт е поколението на компютърен софтуерен код за апликация или подготовката на функционална спецификация, която да помогне или за правенето, или за продажбата на софтуера.
 
=== Computer-aided software engineering ===
[[:en:Computer-aided software engineering|Computer-aided software engineering]] (CASE) представлява комплект от инструменти и методи към софтуера, водещи до по-високо качество, липса на дефекти и по-добра поддръжка на софтуерните продукти. Терминът може да се свърже със софтуера, използван за автоматизация в разработката на софтуерни системи или компютърен код. Функциите на помощния софтуер включват анализ, дизайн и програмиране. Инструментите му автоматизират методите за дизайн, документация и създаване на структуриран компютърен код в желания програмен език.
 
Две ключови идеи в проектирането на помощен софтуер са:
Ред 77:
* Инженерен подход към разработката на софтуер и неговата поддръжка.
 
Типични помощни инструменти съществуват за [[:en:configuration management|управление на конфигурацията]], [[:en:data modeling|моделиране на данни]], [[:en:model transformation|моделиране на трансформации]], [[:en:refactoring|рефакториране]], [[:en:source code generation|генерация на програмен код]].
 
=== Интегрирана среда за разработка ===
[[File:Anjuta-2.0.0-2.png|thumb|360px|[[Anjuta]], a C and C++ IDE for the GNOME environment]]
[[Интегрираната среда за разработка]] е [[софтуерна апликация]], предоставяща разбираеми улеснения за [[:en:computer programmer|компютърния програмист]] при разработката на софтуер. Обикновено една среда за разработка съдържа:
* [[Редактор на програмния код]]
* [[Компилатор]] или [[интерпретатор]]
Ред 89:
 
=== Моделиращ език ===
[[:en:modeling language|Моделиращ език]] е всеки [[:en:artificial language|изкуствен език]], който може да бъде използван, за да изрази информация, знания или системи в една структура, които са дефинирани в последователна група от правила. Правилата се използват за интерпретация на значението на компонентите в една структура. Моделиращият език може да бъде графичен или текстов. Графичните използват [[диаграмни техники]] с наименувани символи, които представят концепции, линии, които ги свързват с техните взаимоотношения и други графични анотации, които репрезентират ограничения. Текстовите моделиращи езици обикновено използват стандартизирани ключови думи, придружени от параметри, които да формират компютърно-интерпретативни изрази.
 
Примери за графични моделиращи езици в сферата на софтуерното инженерство са:
Ред 98:
* [[Fundamental Modeling Concepts]] (FMC) е моделиращ език за софтуерно-интензивни системи
* [[IDEF]] е група от моделиращи езици, като най-значимите са [[IDEF0]] за функционално моделиране, [[IDEF1X]] за информационно моделиране и [[IDEF5]] за моделиране на онтологии
* [[LePUS3]] е [[обектно-ориентиран]], визуален, дизайн-описателен език и [[бивш специфициращ]] език, който е съвместим най-вече с моделиране на широко обектно-ориентирани ([[Java]], [[C++]], [[C#]]) програми и [[:en:design patterns|design patterns]].
* [[Specification and Description Language]] (SDL) е специфициращ език, съсредоточен в недвусмислената спецификация и описание на поведението на разпределени системи
* [[Unified Modeling Language]] (UML) е [[general-purpose]] език, който е индустриален стандарт за специфициране на софтуерно-интензивни системи. UML 2.0 поддържа тринадесет различни диаграмни техники и има широко разпространен инструмент за помощ
Не всички моделиращи езици са изпълними и за тези, които са, използването им не означава че програмисти не са нужни. Вместо това, изпълнимите моделиращи езици имат за цел да разширят продуктивността на умели програмисти, така че да адресират повече сложни проблеми като [[:en:parallel computing|паралелни изчисления]] и [[:en:distributed system|разпределителни системи]].
 
=== Програмни парадигми ===
[[Програмна парадигма]] е фундаментален стил на компютърно програмиране, който като цяло не е воден от методология за управление на проекта. Парадигмите се различават в концепциите и абстракциите, използвани за представяне на елементите в една програма (като обекти, функции, променливи, ограничения) и в изчислителните стъпки (като оценяване, продължения, поток от данни). Понякога утвърдените от парадигмата концепции, биват използвани кооперативно в архитектурния дизайн на високо ниво в една система, в други случаи обхватът на програмната парадигма е ограничен до вътрешната структура на конкретната програма или модул.
 
Един програмен език може да поддържа [[повече от една парадигми]]. Например програми писани на [[: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|структури от данни]].
 
Както различни групи софтуерно инженерство застъпват различни методологии, така и различните програмни езици застъпват различни парадигми. Някои езици са направени да поддържат само една парадигма ([[Smalltalk]] поддържа обектно-ориентирано програмиране, [[Haskell]] поддържа функционално програмиране), докато други поддържат повече от една (например [[Object Pascal]], [[C++]], [[C#]], [[Visual Basic]], [[Common Lisp]], [[Scheme]], [[Python]], [[Ruby]] и [[Oz]]).
Ред 113:
 
Примери за парадигми на високо ниво включват:
* [[:en:Aspect-oriented software development|Aspect-oriented software development]]
* [[:en:Domain-specific modeling|Domain-specific modeling]]
* [[:en:Model-driven engineering|Model-driven engineering]]
* [[:en:Object-oriented programming|Object-oriented programming]] methodologies
* [[:en:Search-based software engineering|Search-based software engineering]]
* [[:en:Service-oriented modeling|Service-oriented modeling]]
* [[:en:Structured programming|Structured programming]]
* [[:en:Top-down and bottom-up design|Top-down and bottom-up design]]
 
=== Софтуерна платформа ===
[[:en:software framework|Софтуерната платформа]] е преизползваем дизайн или имплементация за софтуерна система или подсистема. Софтуерната система може да включва подпомагащи програми, [[:en:library (computer science)|библиотеки]] за програмен код, [[:en:scripting language|език за скриптиране]] или друг [[:en:software|софтуер]], който да помогне да се разработят и слепят различните компоненти на софтуерния проект. Платформите могат да намалят, консолидират или стандартизират логика, както и да изпълнят имплементации без показване на тяхната интелектуална собственост или чувствително-внедрените променливи. Различни части и компоненти от платформата могат да бъдат показани, посредством [[:en:application programming interface|API]]. Тези показани интерфейси се считат за публични (public) и представят общ протокол от информация и процедури. Те са обикновено показани чрез декларации, протоколи и публични методи. Голяма част от действителната имплементация на платформата не може да бъде видяна от API. Тази част от платформата се нарича частна (private). Дори платформата да бъде с програмен код със свободен достъп или физически видима за разработчика/имплементатора, public и private разделения на идентификаторите се базират на това, какво се показва на консумиращия ресурс.
 
== Бележки ==