Enginyeria de programari

L'enginyeria de programari és la disciplina o àrea de la informàtica que ofereix mètodes i tècniques per desenvolupar i mantenir programari de qualitat. La creació del software és un procés intrínsecament creatiu i l'Enginyeria de programari mira de sistematitzar aquest proces amb la finalitat d'acotar el risc del fracas en la consecució de l'objectiu creatiu per mitjà de diverses tècniques que s'han demostrat adequades basant-se en l'experiència prèvia. Aquesta enginyeria tracta amb àrees molt diverses de la informàtica i de les ciències de la computació, tals com construcció de compiladors, sistemes operatius , utilitzant totes les fases del cicle de vida del desenvolupament de qualsevol tipus de sistemes d'informació i aplicables a infinitat d'àrees: negocis, investigació científica, medicina, logística, banca, control de trànsit vehicular, meteorologia, dret, Internet.

El terme enginyeria de programari va ser popularitzat durant 1968 NATO Software Engineering Conference (que va tenir lloc a Garmisch, Alemanya) pel seu president F.L. Bauer, i s'ha fet servir àmpliament des de llavors. La disciplina d'enginyeria de programari comprèn coneixement, eines, i mètodes per a la definició de requeriments de programari, i la realització de tasques de disseny de programari, programació de computadors, disseny d'interfícies d'usuari, proves de programari, i manteniment de programari.

L'enginyeria de programari també es recolza en coneixements de ciències de la computació, enginyeria de la computació, gestió, matemàtiques, gestió de projectes, gestió de la qualitat, ergonomia de programari, i enginyeria de sistemes.

El terme enginyeria de programari ha generat certa polèmica, ja que és discutible que el desenvolupament de programes informàtics és més art que ciència, i que tracten d'imposar disciplines de l'enginyeria sobre un tipus d'art és un exercici inútil com el que representa una bona pràctica en la creació de programari no està encara definida.

El IEEE Computer Society sSoftware Engineering Body of Knowledgedefineix "Enginnering programari" com l'aplicació d'un enfocament sistemàtic, disciplinat, enfocament quantificable al desenvolupament, operació i manteniment de la programari, i l'estudi d'aquests enfocaments, és a dir, l'aplicació d'Enginyeria del programari.

L'enginyeria de software aparèixer per primera vegada al 1968 de l'OTAN Conferència d'Enginyeria de Software i estava destinada a suscitar la reflexió sobre l'actual "crisi del programari" en el moment. Des de llavors, ha continuat com professió i el camp d'acció per a dissenyar, implementar i millorar el programari que és de més qualitat, més accessibles, fàcils de mantenir, i més ràpid construir. Atès que el camp és encara relativament jove en comparació amb els seus germans dels camps de l'enginyeria, hi ha molt debat entorn al que l'enginyeria de software realment és, i si s'ajusta a la definició clàssica de l'enginyeria. Ha crescut orgànicament a partir de les limitacions del programari de visualització com s'acaba de programació d'ordinadors.

De desenvolupament de programari un molt utilitzat i terme més genèric, no necessàriament incloure el paradigma de l'enginyeria. Tot i que és discutible l'impacte que ha tingut en el desenvolupament de programes efectius en els últims més de 40 anys, futur del camp sembla brillant d'acord amb Money Magazine i Salary.com que van qualificar de "enginyeria de programari" com el millor treball en els Estats Units en 2006.

Història

Quan el primer modern digital equips van aparèixer a la dècada de 1940, les instruccions per fer-los funcionar es va connectar a la màquina. Els professionals es van adonar ràpidament que aquest disseny no és flexible i se li va acudir la "arquitectura de programa emmagatzemat", o l'arquitectura Von Neumann. Així, la primera divisió entre "maquinari" i "programari", va començar amb abstracció s'utilitza per tractar la complexitat de la computació.

Els llenguatges de programació van començar a aparèixer a la dècada de 1950 i això és també un altre pas important en l'abstracció. Principals idiomes com el Fortran, ALGOL, i Cobol van ser alliberats a finals de 1950 per fer front a científics, algorísmica, i els problemes de negocis, respectivament. E.W. Dijkstra va escriure el seu treball seminal, "GO TO considerades perjudicials", el 1968 i David Parnas va introduir el concepte clau de la modularitat i ocultació d'informació el 1972 per ajudar els programadors bregar amb la complexitat cada vegada major de sistemes informàtics. Un sistema de programari per a la gestió del maquinari anomenada sistema operatiu també va ser introduït, en particular per Unix el 1969. El 1967, el Simula va introduir el llenguatge de programació orientada a objectes paradigma.

Aquests avenços en el programari es van trobar amb més avenços en el maquinari. A la dècada de 1970, el microordinadors es va introduir, per la qual cosa és econòmic per als aficionats per obtenir un ordinador i escriviu programari per a això. Això, al seu torn va conduir a la ara famosa ordinador personal PC] () i Microsoft Windows. El Desenvolupament de Software Cicle de Vida o SDLC també comencen a aparèixer com un consens per a la construcció centralitzada de programari en els anys 1980. Finals de 1970 i principis de 1980 va veure la introducció de diversos nous Simula inspirat en els llenguatges de programació orientada, incloent-hi C, Smalltalk, i Objective C.

Codi obert de programari van començar a aparèixer en els anys 90 en la forma de Linux i altre programari en presentar el "basar" o l'estil descentralitzat de la construcció de programari. Després de la Internet i World Wide Web va arribar a mitjans dels 90, el canvi de l'enginyeria de programari, una vegada més. Sistemes distribuïts va guanyar influència com una forma de disseny de sistemes, i la Java llenguatge de programació es va introduir amb el seu propi màquina virtual com un pas més en abstracció. Programadors col·laborat i va escriure la Manifest àgil, que va afavorir els processos més lleuger per crear més barat i més oportuna de programari.

La definició actual de l'enginyeria de programari encara està sent debatuda pels professionals d'avui en la seva lluita per trobar maneres de produir programari que és "més barat, més gran, més ràpid".

Implicacions socioeconòmiques

L'enginyeria de programari afecta l'economia i les societats de diverses maneres. Econòmicament Socialment A més, amb la indústria del llenguatge s'està trobant cada vegada més camps d'aplicació a escala global.

L'enginyeria de programari canvia la cultura del món a causa de l'estès ús de l'ordinador. El correu electrònic (E-mail), la WWW i la missatgeria instantània permeten a la gent interactuar de noves formes. El programari baixa el cost i millora la qualitat dels serveis de salut, els departaments de bombers, les dependències governamentals i altres serveis socials. Els projectes reeixits on s'han utilitzat mètodes d'enginyeria de programari inclouen GNU / Linux, el programa del transbordador espacial, els caixers automàtics i molts altres.

L'enginyeria de programari es pot considerar com l'enginyeria aplicada al programari, això és, per medis sistematitzats i amb eines preestablertes, l'aplicació d'aquests de la forma més eficient per a la obtenció de resultats òptims; objectius que sempre busca l'enginyeria. No és només la resolució de problemes, sinó que tenint en compte les diferents solucions, triar la més apropiada.

Metodologia

Un objectiu de dècades ha estat trobar processos i Metodologies, que siguin sistemàtiques, predictibles i repetibles, per tal de millorar la productivitat en el desenvolupament i la qualitat del producte software.

Etapes del procés

L'enginyeria de programari requereix dur a terme nombroses tasques, dins d'etapes com les següents:

Anàlisi de requisits

Extreure els requisits d'un producte de programari és la primera etapa per crear-lo. Mentre que els clients pensen que ells saben el que el programari ha de fer, es requereix d'habilitat i experiència en l'enginyeria de programari per reconèixer requisits incomplets, ambigus o contradictoris. El resultat de l'anàlisi de requisits amb el client es plasma en el document ERS,Especificació de Requisits del sistema, l'estructura pot venir definida per diversos estàndards, com ara CMM-I. Així mateix, es defineix un diagrama d'Entitat/Relació, en què es plasmen les principals entitats que participaran en el desenvolupament del programari.

La captura, anàlisi i especificació de requisits (fins i tot proves d'ells), és una part crucial; d'aquesta etapa depèn en gran mesura l'assoliment dels objectius finals. S'han ideat models i diversos processos de treball per a aquests fins. Tot i que encara no està formalitzada, ja es parla de l'anàlisi de requeriments.

La IEEE Std 830-1998 normalitza la creació de les Especificacions de Requeriments de Programari (Software Requirements Specification).

Especificació

L'Especificació de Requeriments descriu el comportament esperat en el programari un cop desenvolupat. Gran part de l'èxit d'un projecte de programari radicarà en la identificació de les necessitats del negoci (definides per l'alta direcció), així com la interacció amb els usuaris funcionals per a la recollida, classificació, identificació, priorització i especificació dels requeriments del programari .

Entre les tècniques utilitzades per a l'especificació de requeriments es troben:

• Casos d'Ús,
• Històries d'usuari,

Sent els primers més rigorosos i formals, els segones més àgils i informals.

Arquitectura

La integració d'infraestructura, desenvolupament d'aplicacions, bases de dades i eines gerencials, requereixen de capacitat i lideratge per poder ser conceptualizats i projectats en un futur , solucionant els problemes d'avui. El rol en el qual es deleguen totes aquestes activitats és el de l'Arquitecte. El Arquitecte del Software és la persona que afegeix valor els processos de negoci gràcies a la seva aportació important de solucions tecnològiques. L'Arquitectura de Sistemes en general, és una activitat de planificació ,ja sigui a nivell d'infraestructures de xarxa i hardware, o de Software. L'arquitectura de Software consisteix en el disseny de components d'una aplicació (entitats del negoci), generalment utilitzant patrons d'arquitectura. El disseny arquitectònic ha de permetre visualitzar la interacció entre les entitats del negoci i a més pot ser validat, per exemple per mitja dels diagrames de seqüència. Un disseny arquitectònic descriu en general com es construirà una aplicació de software. Per això es documenta utilitzant diagrames, per exemple:

• Diagrama de classes
• Diagrames de base de dades
• Diagrama de Diagrames de desplegament
• Diagrama de seqüència
• Diagrames de infraestructura química

Sent els dos primers els mínims necessaris per descriure l'arquitectura d'un projecte . Depenent de l'abast, complexitat i necessitats del projecte, els arquitectes trien quins diagrames elaborar. Entre les eines per dissenyar arquitectures de software es troben:

• Enterprise Architect
• Microsoft Visio for Enterprise Architects

Programació

Reduir un disseny a codi pot ser la part més òbvia del treball d'enginyeria de programari, però no necessàriament és la que demana més treball i ni la més complicada. La complexitat i la durada d'aquesta etapa està íntimament relacionada al o als llenguatges de programació utilitzats, així com al disseny prèviament realitzat.

Prova

Consisteix en comprovar que el programari realitzi correctament les tasques indicades en l'especificació del problema. Una tècnica de prova és provar per separat cada mòdul del programari, i després provar-lo de forma integral, per així arribar a l'objectiu. Es considera una bona pràctica que les proves siguin efectuades per algú diferent del desenvolupador que el va programar, idealment una àrea de proves, sense perjudicis el programador ha de fer les seves pròpies proves. En general hi ha dues grans formes d'organitzar una àrea de proves, la primera és que estigui formada per personal inexpert i que desconegui el tema de proves, d'aquesta manera s'avalua que la documentació lliurada sigui de qualitat, que els processos descrits són tan clars que qualsevol pot entendre'ls i el programari fa les coses tal com estan descrites. El segon enfocament és tenir una àrea de proves conformada per programadors amb experiència, persones que saben sense més indicacions en quines condicions pot fallar una aplicació i que poden posar atenció en detalls que personal inexpert no consideraria.

Documentació

Tot el que esta relacionat amb la documentació del propi desenvolupament del programari i de la gestió del projecte, passant per models (UML), diagrames, proves, manuals d'usuari, manuals tècnics, etc; tot amb el propòsit d'eventuals correccions, usabilitat, manteniment futur i ampliacions al sistema. Aquesta part és força important, ja que des de sempre es pensa el producte des de zero, i el client final no arribarà a entendre-ho tan bé com nosaltres. Per això cal documentar tot el material existent. Proves, manuals, instruccions específiques...tot en general, per tal que el client sempre sigui capaç de resoldre ell tot sol un possible problema de conceptes.

Manteniment

Mantenir i millorar el software per arreclar errors i aplicar nous requisits. Això pot dur a terme més temps que fins i tot el propi desenvolupament inicial del software. Al voltant d'un 60% de tota l'enginyeria del software té a veure amb el manteniment. Una petita part del treball consisteix en arreclar errors, o bugs. La major part consisteix en extendre el sistema per fer noves aplicacions. De forma similar, al voltant del 60% de tota l'enginyeria civi, arquitectura i treballs de construcció és donar manteniment.

Models de desenvolupament de programari

L'enginyeria de programari té diversos models, paradigmes o filosofies de desenvolupament en els quals es pot donar suport per a la realització de programari, dels quals podem destacar aquests per ser els més utilitzats i els més complets:

• Model cascada o Clàssic (model tradicional)
• Model espiral (model evolutiu)
• Desenvolupament per etapes
• Desenvolupament iteratiu i creixent o iterativa i incremental
• RAD (Rapid Application Development)
• Desenvolupament concurrent
• RUP (Model Racional)
• UML

L'enginyeria de programari té a veure amb diversos camps en diferents formes:

• Matemàtiques: Els programes tenen moltes propietats matemàtiques. Per exemple la correcció i la complexitat de molts algorismes són conceptes matemàtics que poden ser rigorosament provats. L'ús de matemàtiques a la EP és anomenat mètodes formals.

• Creació:Els programes són construïts en una seqüència de passos. El fet de definir pròpiament i dur a terme aquests passos, com en una línia d'acoblament, és necessari per millorar la productivitat dels desenvolupadors i la qualitat final dels programes. Aquest punt de vista inspira els diferents processos i metodologies que trobem a la EP.

• Gestió de Projectes :El programari comercial (i la majoria del no comercial) requereix gestió de projectes. Hi ha pressupostos i establiment de temps. Gent per liderar. Recursos (espai d'oficina, ordinadors) per adquirir. Tot això encaixa apropiadament amb la visió de la Gestió de Projectes.

• Art:Els programes contenen molts elements artístics. Les interfícies d'usuari, la codificació, etc. Fins i tot la decisió per un nom d'una variable o una classe.

Fases del lliurament del programari

El lliurament de programari es la distribució, ja sigui pública o privada, d'un producte nou o millorat en forma de programa per a ordinador. Cada cop que es canvia un programa o sistema, els enginyers informàtics i les empreses que realitzen el treball decideixen com canviaran o lliuraran aquests productes. Les actualitzacions de programari són un mètode de distribució de canvis, així com les descàrregues i els discos compactes.

El cicle de vida del programari es composa de diferents fases que descriuen l'estabilitat d'una part de programa i la quantitat de desenvolupament que es requereix abans de lliurar la versió final. Cada versió important d'un producte passa normalment per una fase en la que s'inclouen noves opcions, la fase alfa; una altra en la qual es comença a llevar errors, la fase beta; i finalment, una en la què s'ha eliminat tots els errors importants, la fase estable.Es possible que hi hagin fases intermèdies entre aquestes. És possible que aquestes fases s'anunciïn i es regulen formalment per part dels creadors del projecte, però de vegades, els termes s'usen informalment per descriure l'estat del producte. Moltes companyies usen noms clau de manera convencional per referir-se a versions anteriors al lliurament del producte, tot i que el nom real d'aquest i les seves característiques rarament romanen en secret.

Prealfa

De vegades, es prepara una versió coneguda com a «prealfa» abans de lliurar l'alfa o la beta. A diferencia d'aquestes dues versions, la prealfa no està completa. Quan s'usa aquest terme, es fa referència a totes les activitats realitzades durant el desenvolupament del projecte abans de fer la prova de programari. Aquestes activitats poden incloure l'anàlisi de requeriments, el disseny del programa, el desenvolupament d'aquest i la prova d'unitats. En el món del codi lliure, hi ha molts tipus de versions prealfa. Les versions de Milestone inclouen conjunts específics de funcionalitat, i es lliuren així com aquesta es veu completa. Les versions de Nightly builds es comproven automàticament al control de versions. Aquestes versions permeten als controladors comprovar immediatament les funcionalitats implementades més recents i trobar nous errors.

Alfa

La versió alfa d'un programa és la lliurada als controladors de programari, persones diferents als enginyers informàtics que s'encarreguen del projecte, però que normalment formen part de l'organització o la comunitat que desenvolupa el programa. Cada vegada hi ha més i més empreses al mercat que contracten a personal extern o altra gent per provar la versió alfa. Aquesta opció permet fer una prova més directa i extensa durant la fase alfa.

A la primera fase del control, els desenvolupadors solen provar el programa usant tècniques de caixa blanca. Aleshores, es realitza una validació addicional usant tècniques de caixa negra o grisa per un altre equip de control. Moure un projecte a una prova de caixa negra representa el lliurament de la versió alfa.

Beta

Una versió beta és la primera lliurada fora de l'organització o comunitat que desenvolupa el programa per tal d'avaluar-la o fer proves de caixa negra o grisa. El procés de proporcionar una versió beta als usuaris s'anomena lliurament de beta. El programari en nivell beta sol incloure totes les opcions, però pot incloure també errors i problemes de poca rellevància. El usuaris de les versions beta s'anomenen controladors de beta. Solen ser clients habituals o potencials de l'empresa que desenvolupa el programa. Reben el programari gratuïtament o per un preu reduït, però actuen com a controladors sense rebre cap pagament. Les versions beta proven les possibilitats de suport del producte, a qui va destinat (durant el reclutament dels controladors de beta), les possibilitats de manufactura i el canal de flux total.

El programari en versió beta és especialment útil per fer demostracions internes i avanços a clients particulars, però tanmateix, és inestable i no està llest per ser llançat. Alguns programadors es refereixen a aquesta etapa com a avanç, prototip, avanç tècnic o primer accés. Com a segona major fase en el cicle de vida d'un programa, després de la fase alfa, rep el nom de beta, segona lletra de l'alfabet grec.

Sovint, aquesta fase comença quan els programadors anuncien una parada de modificacions del producte, indicant així que no s'acceptaran més opcions per a aquesta versió del producte. Tan sols es notificaran problemes amb el programa, errors i opcions no implementades. Els programadors lliuren una beta tancada i una oberta. Les versions beta tancades es distribueixen a un grup selecte d'individus per fer una prova d'usuari, mentre que les obertes són per a un grup més ampli, normalment, el públic general. Els controladors informen de qualsevol error que troben i, de vegades, altres opcions secundaries que els agradaria veure a la versió final.

Un exemple de beta oberta al públic foren els Avanços per a la Comunitat Tecnològica del Windows Vista que Microsoft va proporcionar a controladors de beta al gener de 2005. El primer d'aquests avanços lliurats fou el ACT5219. Els següents ACT introduïren moltes de les opcions planejades, així com un bon nombre de canvis a la interfície de l'usuari, basats en gran part en les opinions dels controladors de beta. Windows Vista es declarà complet amb la ACT5308, lliurada el 22 de febrer de 2006, i la majoria del treball que quedà entre aquesta versió i la final es centrà en la estabilitat, l'aparença, la compatibilitat d'aplicacions i controladors de dispositius, i la documentació.

Quan es lliura una beta al públic general, els usuaris principals són entesos i gent familiaritzada amb les versions anteriors, i la usen com si fóra el producte final. Normalment, els desenvolupadors de programari lliure o beta de codi lliure els distribueixen al públic general, mentre que les versions dels propietaris passen a un grup reduït de controladors. En gran part dels casos, aquells que reben aquestes beta han de signar un acord de confidencialitat. Es considera que una beta està completa quan l'equip de producció ha trobat els requeriments funcionals del sistema i ja no inclourà noves característiques, tot i que encara poden existir errors al programa. Les empreses amb un processament formal de programari tendeixen a entrar a la fase beta amb un llistat dels errors que cal eliminar per sortir d'aquesta, i algunes empreses faciliten la llista als clients i als controladors.

Com que Internet permet una distribució de programari ràpida i barata, les empreses han començat a prendre un ús més flexible de la paraula "beta". Netscape Communications fou molt criticada per lliurar versions alfa del seu navegador de xarxa al públic assegurant que eren beta. Al febrer de 2005, ZDNet publicà un article sobre el fenomen recent de proporcionar una versió beta durant anys i usar-la com si fos definitiva. Va posar l'exemple de Gmail i Google News, que durant molt de temps foren beta i no els retiraven aquest estat tot i l'extens ús que es feia d'aquests serveis. Així però, Google News deixà de ser beta al gener de 2006. Aquesta tècnica també permet als desenvolupadors donar temps oferint ajuda completa i/o responsabilitat pels assumptes pendents. En el context de Web 2.0 es parlava fins i tot de versions beta perpètues per indicar que algun programa està destinat a seguir en versió beta.

Origen dels termes "alfa" i "beta"

El terme "test beta" aplicat al programari prové d'un primer test de maquinari d'IBM que es remunta a les màquines de tabulació i ordenació de targetes perforades. El maquinari passava primerament per la fase de test alfa per provar la seua funcionalitat preliminar i la viabilitat de producció a petita escala. Després es feia un test beta per verificar si realment realitzava correctament les funcions que havia de fer i per saber si es podria fabricar d'acord amb les exigències del mercat. Seguidament es feia un test c per comprovar la seguretat. Amb l'arribada dels ordinadors programables i el primer programari compartible, IBM utilitzà la mateixa terminologia per a les proves de programari. Els tests beta els realitzaven persones o grups diferents als desenvolupadors. Com que altres empreses començaren a desenvolupar programaris per al seu ús propi i també per a la seua distribució, aquesta terminologia va romandre i ara és part del nostre vocabulari habitual.

Possible llançament

El terme "possible llançament" es refereix a la versió amb potencial per a ser un producte final, preparat per a eixir llevat que apareguin errors fatals. En aquest estat, el producte incorpora totes les funcionalitats i no té cap error. En aquesta fase normalment el producte està codificat completament.

Microsoft Corporation utilitza a sovint el terme de "possible llançament". Durant els anys 90, Apple Inc. utilitzà el terme "golden master" per als seus possibles llançaments, i el "final golden master" era l'edició per al públic en general. Altres termes utilitzats eren gamma (de vegades també delta, i fins i tot més lletres gregues) per a versions que estaven prou completes però que encara es trobaven en fase de test, i el terme omega per al test final de versions que es creien lliures d'errors i que podien eixir al mercat en qualsevol moment (gamma, delta i omega són, respectivament, la tercera, quarta i última lletra de l'alfabet grec). Alguns usuaris anomenen despectivament "test gamma" als possibles llançaments i fins i tot als llançaments finals "punt zero", per tal de suggerir que el desenvolupador ha decidit utilitzar als consumidors per provar un programari que no està realment acabat per sortir al mercat. Sovint, els beta testers, si són seleccionats de forma privada, paguen per utilitzar aquests possibles llançaments com si foren el producte final.

Un llançament s'anomena "de codi complet" quan l'equip de desenvolupadors s'hi posa d'acord en no afegir més codi font al programari. Però encara poden haver-hi canvis de codi per solucionar errors, així com també canvis en la documentació i en els arxius, i al codi en cas de fer proves o utilitats. El nou codi s'afegiria en un llançament posterior.

Or o "llançament de disponibilitat general"

La versió d'or o de disponibilitat general és la versió final d'un producte particular. Normalment és quasi idèntica al possible candidat, solament amb errors d'última hora que han estat solucionats. Es considera que la versió d'or és molt estable i que està relativament lliure d'errors, i amb la qualitat suficient per a distribuir-se i utilitzar-se. En els llançaments de programari comercial, aquesta versió pot anar signada (cosa que permet verificar als usuaris que el codi no ha estat modificat des del seu llançament). L'expressió "un programari està en or" significa que el codi s'ha completat i que es produeix de forma massiva i prompte eixirà a la venda. Altres termes per expressar aquesta versió són or màster, màster daurat, "GM" (de les seues sigles en anglès), o versió or.

A mode d'anècdota, el terme "or" es refereix a l'ús del disc màster d'or que s'utilitzava normalment per enviar la versió final als fabricants, i que l'utilitzaven per a la producció en massa de còpies per a la venta al públic. En aquest context seria com el que es fa amb les produccions musicals. No obstant això, en alguns casos el disc màster està fabricat en or, tant per estètica com per la seua resistència a la corrosió.

RTM o RTW

Microsoft i altres utilitzen el terme "llançament de producció" (RTM en anglès) per referir-se a aquesta versió (per als productes comercials, com Windows XP, per exemple, Build 2600 és el llançament de producció del Windows XP). El "llançament web" (RTW en anglès) s'utilitza per productes de descàrrega gratuïta. Normalment, el llançament web es produeix al menys una o dues setmanes abans que el llançament de disponibilitat general (GA) ja que el llançament de producció ha de gravar-se a un disc, empaquetar-se, etc.

Còpia comercial

Una còpia comercial és el producte final, amb el disc imprès amb la versió actual, amb el disseny gràfic, etc. Aquest terme s'utilitza sobretot entre els controladors per diferenciar-lo dels discs d'or. Una còpia comercial no ha d'anar necessàriament tancada i empaquetada amb una caixa, només es refereix al disc en sí.

Estable o inestable

En la programació de codi obert, els números de versió o els termes estable o inestable normalment distingeixen l'estat del desenvolupament. El terme estable es refereix a la versió del programari que és substancialment idèntica a la versió que ha passat per suficients tests per assumir raonablement que no té problemes de funcionament, o almenys els problemes que tingui es coneixen i estan documentats. Per una altra banda, el terme inestable no significa necessàriament que tingui problemes, sinó més bé que s'han aplicat millores o canvis al programari que no han passat un test rigorós i que s'esperen canvis prompte. Als usuaris d'aquest tipus de programari se'ls adverteix en utilitzar la versió estable si cobreix les seves necessitats, i solament utilitzar la versió inestable si la nova funcionalitat els interessa tant que estan disposats a assumir el risc que alguna cosa no funcioni bé.

Al '''nucli del sistema operatiu''' de Linux, els nombres de versió estan formats per tres dígits, separats per un punt decimal. Abans de la versió 2.6.x, un segon nombre parell s'utilitzava per representar un llançament estable i un segon nombre imparell per representar un llançament inestable. A partir de la versió 2.6.x el segon número parell o imparell ja no té aquest significat. La pràctica d'utilitzar nombres parells i imparells per indicar l'estabilitat d'algun llançament ha estat utilitzada per molts altres projectes, tant de codi obert com de codi tancat.

Fi del producte

De vegades, les empreses de programari deixen de vendre o d'oferir els seus productes (és a dir, no ofereixen més actualitzacions). En aquest moment, es diu que el producte es troba en un estat de "legacy", "vintage" o "final de la vida". Per exemple, el 15 d'agost de 2007, Apple va anunciar que AppleWorks havia aplegat al "estatus de final de la vida". Vegeu també Final de la vida (d'un producte). En altres tipus de productes (més relacionats amb software de desenvolupament, com per exemple motors gràfics) quan arriba el seu "final de vida" passen a ser gratis i des del punt de vista de petits estudis o desenvolupadors de software això és molt profitós. Es podria dir que en aquest tipus de productes s'esgota el temps en que son útils i passen a ser 'software lliure'.

Professió

Els requisits legals per a la concessió de llicències o certificació d'enginyers de programari professionals varien al voltant del món. Molts estats dels enginyers de llicència de programari dels Estats Units ((edita | data = gener 2010)). Al Regne Unit, el British Computer Society llicències dels enginyers de programari i dels membres de la societat també pot convertir-se en Enginyers Públics (céng), mentre que en algunes zones del Canadà, com a Alberta, Ontàrio, i Quebec, els enginyers de programari pot contenir l'Enginyer Professional (P. Eng) la designació i / o el professional de Sistemes d'Informació (ISP) la designació, però, no hi ha cap requisit legal perquè aquestes qualificacions.

El IEEE Computer Society i la ACM, les dues principals organitzacions professionals de l'enginyeria de programari, publicar guies per a la professió de l'enginyeria de programari. L'IEEEGuía per al Cos d'Enginyeria del Software de coneixement - 2004 Versió, o SWEBOK, defineix l'àmbit i descriu el coneixement de la IEEE s'espera que un enginyer de programari de la pràctica de [[]] a tenir. L'IEEE també promulga una "." Enginyeria de Programari de Codi d'Ètica

Ocupació

El 2004, el U. S. Bureau of Labor Statistics comptats a 760.840 enginyer de programari s sostenint l'ocupació en la EUA, en el mateix període de temps hi va haver uns 1,4 milions de professionals empleats en els EUA en totes les disciplines d'enginyeria combinat. causa de la seva relativa novetat com un camp d'estudi, la formació acadèmica en enginyeria de programari sovint s'ensenya com a part d'un pla d'estudis d'informàtica, i com a resultat de la majoria dels enginyers de programari tenen títols de ciències de la computació.

La majoria d'enginyers de programari de treball com a empleats o contractistes. Els enginyers de programari treballen amb empreses, organismes governamentals (civils o militars), i organitzacions no lucratives. Alguns enginyers de programari treballen per a si mateixos com independent s. Algunes organitzacions compten amb especialistes per dur a terme cada una de les tasques de la procés de desenvolupament de programari. Altres organitzacions que requereixen els enginyers de programari per a fer moltes o totes elles. En els grans projectes, les persones poden especialitzar-se en una sola funció. En els projectes petits, les persones poden omplir diversos o tots els rols al mateix temps. Especialitzacions són: a la indústria ( Analistes, Arquitectes, desenvolupadors, emprovadors, el suport tècnic, administradors) i en l'acadèmia (educador s, investigador s).

Hi ha un debat considerable sobre les perspectives futures d'ocupació per als enginyers de programari i altres IT professionals. Per exemple, un mercat de futurs en línia anomenat el "Futur de la TI ITJOBS llocs de treball als Estats Units" intenta respondre si hi haurà més llocs de treball de TI, incloent enginyers de programari, l'any 2012 que hi havia a 2002.

Certificació

La certificació professional dels enginyers de programari és un tema polèmic, amb algunes organitzacions professionals que hi donen suport, i altres que afirmen que no és apropiat donada l'actual nivell de maduresa en la professió. Alguns ho veuen com una eina per millorar la pràctica professional; "L'únic propòsit dels enginyers de programari de llicència és per protegir el públic".

El ACM tenia un programa de certificació professional en la dècada de 1980, ((edita | data = March 2009)), que es va suspendre a causa de la manca d'interès. L'ACM ha examinat la possibilitat de la certificació professional dels enginyers de programari a finals de 1990, però finalment es va decidir que aquesta certificació no era l'adequada per a la pràctica professional de l'enginyeria industrial de programari. A 2006 l'IEEE havia certificat a més de 575 professionals de programari. Al Regne Unit, el British Computer Society desenvolupà una certificació professional reconeguda legalment llamadaChartered IT Professional (CITP) , a disposició dels membres complet (MBCS'). Al Canadà, la Societat Canadenca de Tractament de la Informació ha desenvolupat una certificació professional reconeguda legalment llamadaSistemas d'Informació Professional (ISP). El Software Engineering Institute ofereix certificació en temes específics com la seguretat, La millora de processos i arquitectura de programari.

La majoria de certificació en els programes de la tecnologia IT, la indústria estan orientades a tecnologies específiques, i són gestionats pels venedors d'aquestes tecnologies. Aquests programes de certificació s'adapten a les institucions que donen feina a persones que utilitzen aquestes tecnologies.

En alguns països, l'enginyer de programari és un títol d'enginyeria reals (Bachelor of Science o llicenciatura d'enginyeria), com un exemple en Educació a Israel enginyer de programari té el dret d'estar redactada en l' [Registre d'enginyeria http://www.tamas.gov.il/NR/exeres/DACD5881-70D5-463A-BDF2-AA363197FB2F.htm], i seria un delicte greu si una persona descriu a si mateix com un enginyer (la Llei d'enginyeria, defineix que una persona que declari a si mateix com un enginyer sense la deguda llicència o registre podria ser condemnat a fins 6 mesos a la presó).

Impacte de la globalització

Tot i que les estadístiques no mostren actualment una amenaça per a l'enginyeria de programari en si, una carrera relacionada, programació d'ordinadors sembla haver estat afectats. Sovint un s'espera que comenci a terme com a programador d'ordinadors abans de ser promogut a enginyer de programari. Així, la carrera d'enginyeria de programari poden ser difícils, especialment durant les recessions. És la quasi-aspectes de la gestió de l'enginyeria de programari que semblen ser el que li ha impedit sent impactada per la globalització.

Responsabilitat

La responsabilitat de l'enginyeria de programari és un concepte complexe, sobre tot perquè a l'estar els sistemes informàtics fortament caracteritzats per la seva complexitat, és difícil apreciar les seves conseqüències. En l'enginyeria de programari la responsabilitat sera compartida per un grup gran de persones, que abarca desde l'enginyer de requisits, fins a l'arquitecte de programari, i comptant amb el disenyador, o l'encarregat de realitzar les proves. Per sobre de tots ells destaca el director del projecte. El programari demana una clara distribució de la responsabilitat entre els diferents rols que es donen en el procés de producció. L'enginyer de programari té una responsabilitat moral i legal limitada a les conseqüències directes.

Disciplines relacionades amb l'enginyeria del programari

L'enginyeria de programari es podria dividir en:

• Anàlisi de requeriments
• Prototype
• Desenvolupament de programari
• Proves de programari
• Manteniment de programari
• Convenció sobre configuració
• Eines CASE

L'enginyeria de programari està relacionada amb les disciplines de ciències de la computació, gestió de projectes i enginyeria de sistemes.

Informàtica

L'enginyeria de programari es considerada un subcamp de la informàtica per molts acadèmics. Molts dels fonaments de l'enginyeria de programari provenen de la informàtica.

Gestió de projectes

La construcció d'un sistema de programari es considera generalment com un projecte i la gestió dels que pren prestats molts principis del camp de la gestió de projectes.

Enginyeria de sistemes

Els enginyers de sistemes s'han ocupat de la complexitat dels sistemes durant moltes dècades i el seu coneixement s'aplica a molts problemes d'enginyeria de programari.

Sub-disciplines

L'enginyeria de programari pot ser dividit en deu subdisciplines. Ells són:

• Requisits de programari: L'anàlisi de l'obtenció, especificació i validació de requisits de programari.
• Disseny de software: El disseny del programari es sol fer amb Computer-Aided Software Engineering (CASE) i l'ús de normes per al format, com el Llenguatge Unificat de Modelat ( UML ).
• Desenvolupament de programari: La construcció de programari a través de la utilització de llenguatges de programació.
• Proves de programari
• Manteniment de programari: Els sistemes de programari sovint tenen problemes i millores de la necessitat d'un llarg temps després de la primera efectuada. En aquest subcamp amb aquests problemes.
• Gestió de configuració de programari: Com que els sistemes de programari són molt complexos, la seva configuració (com ara el control de versions i control de codi font) han de ser gestionats en un mètode normalitzat i estructurat.
• Gestió d'enginyeria de progeamari: La gestió dels sistemes de programari s'inspira en gran mesura a partir de gestió de projectes, però hi ha matisos trobats en el programari que no es veu en les disciplines de gestió.
• Procés de desenvolupament de programari:El procés de construcció de programari és objecte d'acalorats debats entre els professionals amb els principals paradigmes que àgils de desenvolupament de programari o model en cascada.
• Les eines d'enginyeria de programari, vegeu Eines CASE
• La qualitat del programari

Educació

El coneixement de la programació és el principal requisit per a convertir-se en un enginyer de programari, però no és suficient. Molts enginyers de programari tenen títols en informàtica a causa de la manca de programes d'enginyeria de programari a l'educació superior. No obstant això, això ha començat a canviar amb la introducció de noves titulacions d'enginyeria de software, especialment en l'educació de postgrau. Un programa internacional per a les titulacions d'enginyeria de programari de pregrau va ser definit pel CCSE.

Steve McConnell opina que pel fet que la majoria de les universitats ensenyen ciències de la computació en lloc d'enginyeria de programari, hi ha una veritable escassetat d'enginyers de programari. El 2004, el IEEE Computer Society va produir el SWEBOK, que s'ha convertit en un estàndard ISO que descriu el cos de coneixement cobert per un enginyer de programari de ((edita | data = agost 2008)).

El Comissió Europea al Erasmus Mundus Programa ofereix una màster europeu graus, anomenada Màster Europeu en Enginyeria de Programari per als estudiants d'Europa i també fora d'Europa. Aquest és un programa conjunt (doble titulació) la participació de quatre universitats a Europa.

Organitzacions

• Software Engineering Institute (SEI)
• Association for Computing Machinery (ACM)
• British Computer Society (BCS)
• IEEE Computer Society
• RUSSOFT|RUSSOFT Association
• Society of Software Engineers

Vegeu també

• Patró de disseny (informàtica)
• Patró arquitectònic (informàtica)

Bibliografia

• Pressman, Roger S. Pressman. McGraw-Hill. Enginyeria del Programari: una perspectiva professional. 6a edició, 2005. ISBN 0072853182. 
• Sommerville, Ian Sommerville (acadèmic) [1982]. Pearson Education. Enginyeria de Software. 8, 2007. ISBN 0-321-31379-8. 
• Jalote, Pankaj Jalote [1991]. Springer. Un enfocament integrat d'Enginyeria de Software. 3, 2.005. ISBN 0-387-20881-X. 
• Ghezzi, Carlo; Mehdi Jazayeri, Dino Mandrioli. @ Pearson Education, Prentice-Hall. Fonaments d'Enginyeria del Software. 2 (Internacional), 2.003. 

Enllaços externs

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Enginyeria de programari

• Computing Curricula 2005: L'informe general de la Força de Tasca Conjunta de Computing Curricula ACM / AIS / IEEE-CS
• / ccse / Directrius de pla d'estudis per a programes de grau en Enginyeria de Programari de la Força de Tasca Conjunta de plans d'estudis d'Informàtica ACM / IEEE-CS
• [Directrius per http://www.acmtyc.org/WebReports/SEreport/ Associat grau de transferència de Currículum en Enginyeria de Programari] per l'ACM de Dos Anys de Colegio del Comitè d'Educació i la Força Especial Conjunta d'Enginyeria del Software Association for Computing Machinery IEEE Computer Societat
• Guia per al Cos d'Enginyeria del Software de Coneixement
• Computer Software Engineers - Definició i estadístiques dels EUA Oficina d'Estadístiques del Treball
• IEEE Software Engineering Online
• Guia de l'estudiant per a Projectes d'Enginyeria de Software - una guia en línia gratuït per als estudiants que prenen cursos del projecte ES