Visita Encydia-Wikilingue.com

Software

software - Wikilingue - Encydia

Coñécese como software[1] ao equipamiento lóxico ou soporte lóxico dunha computadora digital; comprende o conxunto dos compoñentes lóxicos necesarios que fan posible a realización de tarefas específicas, en contraposición aos compoñentes físicos do sistema, chamados hardware.

Tales compoñentes lóxicos inclúen, entre moitos outros, aplicacións informáticas —como o procesador de textos, que permite ao usuario realizar todas as tarefas concernentes á edición de textos— ou o software de sistema —tal como o sistema operativo, que, basicamente, permite ao resto dos programas funcionar adecuadamente, facilitando a interacción cos compoñentes físicos e o resto das aplicacións, proporcionando tamén unha interfaz para o usuario—.

Contido

Etimología

Software (pronunciación AFI:[soft'ɣware])[2] é unha palabra proveniente do inglés (literalmente: partes brandas ou suaves), que en español non posúe unha tradución adecuada ao contexto, polo cal utilízalla asiduamente sen traducir e así foi admitida pola Real Academia Española (RAE).[3] Aínda que non é estrictamente o mesmo, adoita substituírse por expresións tales como programas (informáticos) ou aplicacións (informáticas).[4]

Software é o que se denomina produto en Ingeniería de Software.[5]

Definición de software

Probablemente a definición máis formal de software sexa a seguinte:

É o conxunto dos programas de cómputo, procedementos, regras, documentación e datos asociados que forman parte das operacións dun sistema de computación.
Extraído do estándar 729 do IEEE[6]

Considerando esta definición, o concepto de software vai máis aló dos programas de cómputo nos seus distintos estados: código fonte, binario ou ejecutable; tamén a súa documentación, datos a procesar e información de usuario forman parte do software: é dicir, abarca todo o intangible, todo o "non físico" relacionado.

O término «software» foi usado por primeira vez neste sentido por John W. Tukey en 1957 . Nas ciencias da computación e a ingeniería de software, o software é toda a información procesada polos sistemas informáticos: programas e datos. O concepto de ler diferentes secuencias de instrucións desde a memoria dun dispositivo para controlar os cálculos foi introducido por Charles Babbage como parte da súa máquina diferencial. A teoría que forma a base da maior parte do software moderno foi proposta por vez primeira por Alan Turing no seu ensaio de 1936, "Os números computables", cunha aplicación ao problema de decisión.

Clasificación do software

Aínda que esta distinción é, en certo xeito, arbitraria, e ás veces confusa, aos fins prácticos pódese clasificar ao software en tres grandes tipos:

Proceso de creación do software

Defínese como Proceso ao conxunto ordenado de pasos a seguir para chegar á solución dun problema ou obtención dun produto, neste caso particular, para lograr a obtención dun produto software que resolva un problema.

O proceso de creación de software pode chegar a ser moi complexo, dependendo do seu porte, características e criticidad do mesmo. Por exemplo a creación dun sistema operativo é unha tarefa que require proxecto, xestión, numerosos recursos e todo un equipo disciplinado de traballo. No outro extremo, si trátase dun sinxelo programa (por exemplo, a resolución dunha ecuación de segunda orde), este pode ser realizado por un só programador (ata afeccionado) fácilmente. É así que normalmente divídense en tres categorías segundo o seu tamaño (liñas de código) ou costo: de Pequeno, Mediano e Gran porte. Existen varias metodoloxías para estimalo, unha das máis populares é o sistema COCOMO que prové métodos e un software (programa) que calcula e prové unha estimación de todos os costos de produción nun "proxecto software" (relación horas/home, costo monetario, cantidade de liñas fonte de acordo a linguaxe usada, etc.).

Considerando os de gran porte, é necesario realizar tantas e tan complexas tarefas, tanto técnicas, de gerenciamiento, forte xestión e análises diversas (entre outras) que toda unha ingeniería fai falta para o seu estudo e realización: é a Ingeniería de Software.

En tanto que nos de mediano porte, pequenos equipos de traballo (incluso un avezado analista-programador solitario) poden realizar a tarefa. Aínda que, sempre en casos de mediano e gran porte (e ás veces tamén nalgúns de pequeno porte, segundo o seu complejidad), débense seguir certas etapas que son necesarias para a construción do software. Tales etapas, aínda que deben existir, son flexibles na súa forma de aplicación, de acordo á metodoloxía ou Proceso de Desenvolvemento escolleito e utilizado polo equipo de desenvolvemento ou polo analista-programador solitario (si for o caso).

Os "procesos de desenvolvemento de software" posúen regras preestablecidas, e deben ser aplicados na creación do software de mediano e gran porte, xa que en caso contrario o máis seguro é que o proxecto ou non logre concluír ou termine sen cumprir os obxectivos previstos, e con variedade de fallos inaceptables (fracasan, en poucas palabras). Entre tales "procesos" hainos áxiles ou liviáns (exemplo XP), pesados e lentos (exemplo RUP) e variantes intermedias; e normalmente aplícanse de acordo ao tipo, porte e tipología do software a desenvolver, a criterio do líder (si haino) do equipo de desenvolvemento. Algúns deses procesos son Extreme Programming (XP), Rational Unified Process (RUP), Feature Driven Development (FDD), etc.

Calquera sexa o "proceso" utilizado e aplicado ao desenvolvemento do software (RUP, FDD, etc), e case independientemente del, sempre se debe aplicar un "Modelo de Ciclo de Vida".[7]

Estímase que, do total de proxectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas modificacións que o atrasan e un 26% son totalmente exitosos. [8]

Cando un proxecto fracasa, de cando en cando é debido a fallas técnicas, a principal causa de fallos e fracasos é a falta de aplicación dunha boa metodoloxía ou proceso de desenvolvemento. Entre outras, unha forte tendencia, desde fai poucas décadas, é mellorar as metodoloxías ou procesos de desenvolvemento, ou crear novas e concientizar aos profesionais na súa utilización adecuada. Normalmente os especialistas no estudo e desenvolvemento destas áreas (metodoloxías) e afines (tales como modelos e ata a xestión mesma dos proxectos) son os Enxeñeiros en Software, é a súa orientación. Os especialistas en calquera outra área de desenvolvemento informático (analista, programador, Lic. en Informática, Enxeñeiro en Informática, Enxeñeiro de Sistemas, etc.) normalmente aplican os seus coñecementos especializados pero utilizando modelos, paradigmas e procesos xa elaborados.

É común para o desenvolvemento de software de mediano porte que os equipos humanos involucrados apliquen as súas propias metodoloxías, normalmente un híbrido dos procesos anteriores e ás veces con criterios propios.

O proceso de desenvolvemento pode involucrar numerosas e variadas tarefas[7] , desde o administrativo, pasando polo técnico e ata a xestión e o gerenciamiento. Pero case rigurosamente sempre se cumpren certas etapas mínimas; as que se poden resumir como segue:

Nas anteriores etapas poden variar ligeramente os seus nomes, ou ser máis globais, ou contrariamente, ser máis refinadas; por exemplo indicar como unha única fase (aos fins documentales e interpretativos) de "Análises e Deseño"; ou indicar como "Implementación" o que está devandito como "Codificación"; pero en rigor, todas existen e inclúen, basicamente, as mesmas tarefas específicas.

No apartado 4 do presente artigo bríndanse maiores detalles de cada unha das listadas etapas.

Modelos de proceso ou ciclo de vida

Para cada unha das fases ou etapas listadas no ítem anterior, existen sub-etapas (ou tarefas). O modelo de proceso ou modelo de ciclo de vida utilizado para o desenvolvemento define a orde para as tarefas ou actividades involucradas[7] tamén definen a coordinación entre elas, enlace e realimentación entre as mencionadas etapas. Entre os máis coñecidos pódese mencionar: modelo en cascada ou secuencial, modelo espiral, modelo iterativo incremental. Dos antedichos hai á súa vez algunhas variantes ou alternativas, máis ou menos atractivas segundo sexa a aplicación requirida e os seus requisitos.[8]

Modelo cascada

Leste, aínda que é máis comúnmente coñecido como modelo en cascada é tamén chamado "modelo clásico", "modelo tradicional" ou "modelo lineal secuencial".

O modelo en cascada puro difícilmente utilícese tal cal, pois isto implicaría un previo e absoluto coñecemento dos requisitos, a non volatilidad dos mesmos (ou rixidez) e etapas subseguintes libres de erros; iso só podería ser aplicable a escasos e pequenos desenvolvementos de sistemas. Nestas circunstancias, o paso dunha etapa a outra das mencionadas sería sen retorno, por exemplo pasar do Deseño á Codificación implicaría un deseño exacto e sen erros nin probable modificación ou evolución: "codifique o deseñado que non haberán en absoluto variantes nin erros". Isto é utópico; xa que intrínsecamente o software é de carácter evolutivo, cambiante e difícilmente libre de erros, tanto durante o seu desenvolvemento como durante a súa vida operativa.[7]

Fig. 2 - Modelo cascada puro ou secuencial para o ciclo de vida do software.

Algún cambio durante a ejecución dunha calquera das etapas neste modelo secuencial implicaría reiniciar desde o principio todo o ciclo completo, o cal redundaría en altos costos de tempo e desenvolvemento. A figura 2 mostra un posible esquema do modelo en cuestión.[7]

Con todo, o modelo cascada nalgunhas das súas variantes é un dos actualmente máis utilizados[10] , pola súa eficacia e simplicidad, máis que nada en software de pequeno e algúns de mediano porte; pero nunca (ou moi de cando en cando) úsallo na súa forma pura, como se dixo anteriormente. En lugar diso, sempre se produce algunha realimentación entre etapas, que non é completamente predecible nin ríxida; isto dá oportunidade ao desenvolvemento de produtos software nos cales hai certas incertezas, cambios ou evolucións durante o ciclo de vida. Así por exemplo, unha vez capturados (elicitados) e especificados os requisitos (primeira etapa) pódese pasar ao deseño do sistema, pero durante esta última fase o máis probable é que se deban realizar axustes nos requisitos (aínda que sexan mínimos), xa sexa por fallas detectadas, ambigüedades ou ben por que os propios requisitos cambiaron ou evolucionado; co cal débese retornar á primeira ou previa etapa, facer os pertinentes reaxustes e logo continuar nuevamente co deseño; isto último coñécese como realimentación. O normal no modelo cascada será entón a aplicación do mesmo coas súas etapas realimentadas dalgunha forma, permitindo retroceder dunha á anterior (e ata poder saltar a varias anteriores) si é requirido.

Deste xeito obtense un "modelo cascada realimentado", que pode ser esquematizado como o ilustra a figura 3.

Arquivo:ModeloCascadaRealimentado.jpg
Fig. 3 - Modelo cascada realimentado para o ciclo de vida.

O devandito é, a grandes liñas, a forma e utilización deste modelo, un dos máis usados e populares.[7] O modelo Cascada Realimentado resulta moi atractivo, ata ideal, si o proxecto presenta alta rigidéz (poucos ou ningún cambio, non evolutivo), os requisitos son moi claros e están correctamente especificados.[10]

Hai máis variantes similares ao modelo: refino de etapas (máis etapas, menores e máis específicas) ou ata mostrar menos etapas das indicadas, aínda que en tal caso a faltante estará dentro dalgunha outra. A orde desas fases indicadas no ítem previo é o lóxico e adecuado, pero advírtase, como se dixo, que normalmente haberá realimentación cara atrás.

O modelo lineal ou en Cascada é o paradigma máis antigo e extensamente utilizado, con todo as críticas a el (ver desventajas) puxeron en dúbida a súa eficacia. Pese a todo ten un lugar moi importante na Ingeniería de software e continúa sendo o máis utilizado; e sempre é mellor que un enfoque ao azar.[10]

Desventajas do modelo cascada:[7]

Modelos evolutivos

O software evoluciona co tempo. Os requisitos do usuario e do produto adoitan cambiar conforme se desenvolve o mesmo. As datas de mercado e a competencia fan que non sexa posible esperar a poñer no mercado un produto absolutamente completo, polo que se debe introducir unha versión funcional limitada dalgunha forma para aliviar as presións competitivas.

Nesas ou outras situacións similares os desarrolladores necesitan modelos de progreso que estean deseñados para acomodarse a unha evolución temporal ou progresiva, onde os requisitos centrais son coñecidos de antemán, aínda que non estean ben definidos a nivel detalle.

No modelo Cascada e Cascada Realimentado non se ten en conta a natureza evolutiva do software, suscítase como estático con requisitos ben coñecidos e definidos desde o inicio.[7]

Os evolutivos son modelos iterativos, permiten desenvolver versións cada vez máis completas e complexas, ata chegar ao obxectivo final desexado; ata evolucionar máis aló, durante a fase de operación.

Os modelos “Iterativo Incremental” e “Espiral” (entre outros) son dous dos máis coñecidos e utilizados do tipo evolutivo.[10]

Modelo iterativo incremental

En términos xerais, podemos distinguir, na figura 4, os pasos xerais que segue o proceso de desenvolvemento dun produto software. No modelo de ciclo de vida seleccionado, identifícanse claramente devanditos pasos. A Descrición do Sistema é esencial para especificar e confeccionar os distintos incrementos ata chegar ao Produto global e final. As actividades concurrentes (Especificación, Desenvolvemento e Validación) sintetizan o desenvolvemento pormenorizado dos incrementos, que se fará posteriormente.

Arquivo:Modelo Gral Evolutivo Incremental.jpg
Fig. 4 - Diagrama genérico do desenvolvemento evolutivo incremental.

O diagrama 4 móstranos en forma moi esquemática, o funcionamento dun ciclo iterativo incremental, o cal permite a entrega de versións parciais a medida que se vai construíndo o produto final.[7] É dicir, a medida que cada incremento definido chega á súa etapa de operación e mantemento. Cada versión emitida incorpora aos anteriores incrementos as funcionalidades e requisitos que foron analizados como necesarios.

O incremental é un modelo de tipo evolutivo que está baseado en varios ciclos Cascada realimentados aplicados repetidamente, cunha filosofía iterativa.[10] Na figura 5 móstrase un refino do diagrama previo, baixo un esquema temporal, para obter finalmente o esquema do Modelo de ciclo de vida Iterativo Incremental, coas súas actividades genéricas asociadas. Aquí obsérvase claramente cada ciclo cascada que é aplicado para a obtención dun incremento; estes últimos vanse integrando para obter o produto final completo. Cada incremento é un ciclo Cascada Realimentado, aínda que, por simplicidad, na figura 5 móstrase como secuencial puro.

Arquivo:Modelo Iterativo Incremental.jpg
Fig. 5 - Modelo iterativo incremental para o ciclo de vida do software,.

Obsérvase que existen actividades de desenvolvemento (para cada incremento) que son realizadas en paralelo ou concurrentemente, así por exemplo, na figura, mentres se realiza o deseño detalle do primeiro incremento xa se está realizando en análise do segundo. A figura 5 é só esquemática, un incremento non necesariamente iniciarase durante a fase de deseño do anterior, pode ser posterior (ata antes), en calquera tempo da etapa previa. Cada incremento conclúe coa actividade de “Operación e Mantemento” (indicada "Operación" na figura), que é onde se produce a entrega do produto parcial ao cliente. O momento de inicio de cada incremento é dependente de varios factores: tipo de sistema; independencia ou dependencia entre incrementos (dous deles totalmente independentes poden ser fácilmente iniciados ao mesmo tempo si disponse de persoal suficiente); capacidade e cantidade de profesionais involucrados no desenvolvemento; etc.

Baixo este modelo entrégase software “por partes funcionales máis pequenas”, pero reutilizables, chamadas incrementos. En xeral cada incremento constrúese sobre aquel que xa foi entregado.[7]

Como se mostra na figura 5, aplícanse secuencias Cascada en forma escalonada, mentres progresa o tempo calendario. Cada secuencia lineal ou Cascada produce un incremento e a miúdo o primeiro incremento é un sistema básico, con moitas funcións suplementarias (coñecidas ou non) sen entregar.

O cliente utiliza inicialmente ese sistema básico intertanto, o resultado do seu uso e avaliación pode aportar ao plan para o desenvolvemento de o/os seguintes incrementos (ou versións). Ademais tamén aportan a ese plan outros factores, como o é a priorización (maior ou menor urxencia na necesidade de cada incremento) e a dependencia entre incrementos (ou independencia).

Logo de cada integración entrégase un produto con maior funcionalidad que o previo. O proceso repítese ata alcanzar o software final completo.

Sendo iterativo, co modelo incremental entrégase un produto parcial pero completamente operacional en cada incremento, e non unha parte que sexa usada para reaxustar os requerimientos (coma se ocorre no modelo de construción de prototipos).[10]

O enfoque incremental resulta moi útil con baixa dotación de persoal para o desenvolvemento; tamén si non hai dispoñible data límite do proxecto polo que se entregan versións incompletas pero que proporcionan ao usuario funcionalidad básica (e cada vez maior). Tamén é un modelo útil aos fins de avaliación.

Nota: Pode ser considerado e útil, en calquera momento ou incremento incorporar temporalmente o paradigma MCP como complemento, tendo así unha mixtura de modelos que melloran o esquema e desenvolvemento xeral.

Exemplo:

Un procesador de texto que sexa desenvolvido baixo o paradigma Incremental podería aportar, en principio, funcións básicas de edición de arquivos e produción de documentos (algo como un editor simple). Nun segundo incremento poderíaselle agregar edición máis sofisticada, e de xeración e mestura de documentos. Nun terceiro incremento podería considerarse o agregado de funcións de corrección ortográfica, esquemas de paginado e persoais; nun cuarto capacidades de debuxo propias e ecuaciones matemáticas. Así sucesivamente ata chegar ao procesador final requirido. Así, o produto vai crecendo, achegándose á súa meta final, pero desde a entrega do primeiro incremento xa é útil e funcional para o cliente, o cal observa unha resposta rápida en canto a entrega temprana; sen notar que a data límite do proxecto pode non estar acoutada nin tan definida, o que dá marxe de operación e alivia presións ao equipo de desenvolvemento.

Como se dixo, o Iterativo Incremental é un modelo do tipo evolutivo, é dicir onde se permiten e esperan probables cambios nos requisitos en tempo de desenvolvemento; admítese certa marxe para que o software poida evolucionar. Aplicable cando os requisitos son medianamente ben coñecidos pero non son completamente estáticos e definidos, cuestión esa que si é indispensable para poder utilizar un modelo Cascada.

O modelo é aconsejable para o desenvolvemento de software no cal obsérvese, na súa etapa inicial de análise, que posúe áreas bastante ben definidas a cubrir, con suficiente independencia como para ser desenvolvidas en etapas sucesivas. Tales áreas a cubrir adoitan ter distintos grados de prema polo cal as mesmas débense priorizar nunha análise previa, é dicir, definir cal será a primeira, a segunda, e así sucesivamente; isto coñécese como “definición dos incrementos” con base en priorización. Poden non existir prioridades funcionales por parte do cliente, pero o desarrollador debe fixalas de todos os xeitos e con algún criterio, xa que baseándose nelas desenvolveranse e entregarán os distintos incrementos.

O feito de que existan incrementos funcionales do software leva inmediatamente a pensar nun esquema de desenvolvemento modular, xa que logo este modelo facilita tal paradigma de deseño.

En resumo, un modelo incremental leva a pensar nun desenvolvemento modular, con entregas parciais do produto software denominados “incrementos” do sistema, que son escolleitos segundo prioridades predefinidas dalgún modo. O modelo permite unha implementación con refinamientos sucesivos (ampliación ou mellora). Con cada incremento agrégase nova funcionalidad ou se cobren novos requisitos ou ben se mellora a versión previamente implementada do produto software.

Este modelo brinda certa flexibilidad para que durante o desenvolvemento inclúanse cambios nos requisitos por parte do usuario, un cambio de requisitos proposto e aprobado pode analizarse e implementarse como un novo incremento ou, eventualmente, poderá constituír unha mellora/adecuación dun xa planeado. Aínda que si prodúcese un cambio de requisitos por parte do cliente que afecte incrementos previos xa terminados (detección/incorporación tardía) débese evaluar a factibilidad e realizar un acordo co cliente, xa que pode impactar fuertemente nos costos.

A selección deste modelo permite realizar entregas funcionales tempranas ao cliente (o cal é beneficioso tanto para el como para o grupo de desenvolvemento). Priorizar as entregas daqueles módulos ou incrementos en que xurda a necesidade operativa de facelo, por exemplo para cargas previas de información, indispensable para os incrementos seguintes.[10]

O modelo iterativo incremental non obriga a especificar con precisión e detalle absolutamente todo o que o sistema debe facer, (e como), antes de ser construído (como o caso do cascada, con requisitos conxelados). Só se fai no incremento en desenvolvemento. Isto torna máis manexable o proceso e reduce o impacto nos costos. Isto é así, porque en caso de alterar ou rehacer os requisitos, só afecta unha parte do sistema. Aínda que, lógicamente, esta situación agrávase si preséntase en estado avanzado, é dicir nos últimos incrementos. En definitiva, o modelo facilita a incorporación de novos requisitos durante o desenvolvemento.

Cun paradigma incremental redúcese o tempo de desenvolvemento inicial, xa que se implementa funcionalidad parcial. Tamén prové un impacto ventajoso fronte ao cliente, que é a entrega temprana de partes operativas do software.

O modelo proporciona todas as vantaxes do modelo en cascada realimentado, reducindo os seus desventajas só ao ámbito de cada incremento.

O modelo incremental non é recomendable para casos de sistemas de tempo real, de alto nivel de seguridade, de procesamiento distribuído, ou de alto índice de riscos.

Modelo espiral

O modelo espiral foi proposto inicialmente por Barry Boehm. É un modelo evolutivo que conxuga a natureza iterativa do modelo MCP cos aspectos controlados e sistemáticos do Modelo Cascada. Proporciona potencial para desenvolvemento rápido de versións incrementales. No modelo Espiral o software constrúese nunha serie de versións incrementales. Nas primeiras iteraciones a versión incremental podería ser un modelo en papel ou ben un prototipo. Nas últimas iteraciones prodúcense versións cada vez máis completas do sistema deseñado.[7] [10]

O modelo divídese nun número de Actividades de marco de traballo, chamadas "rexións de tarefas". En xeral existen entre tres e seis rexións de tarefas (hai variantes do modelo). Na figura 6 móstrase o esquema dun Modelo Espiral con 6 rexións. Neste caso explícase unha variante do modelo orixinal de Boehm, exposto no seu tratado de 1988; en 1998 expuxo un tratado máis recente.

Arquivo:Modelo Espiral Boehm.jpg
Fig. 6 - Modelo espiral para o ciclo de vida do software.

As rexións definidas no modelo da figura son:

As actividades enunciadas para o marco de traballo son xerais e aplícanse a calquera proxecto, grande, mediano ou pequeno, complexo ou non. As rexións que definen esas actividades comprenden un "conxunto de tarefas" do traballo: ese conxunto si se debe adaptar ás características do proxecto en particular a emprender. Nótese que o listado nos ítems de 1 a 6 son conxuntos de tarefas, algunhas das elas normalmente dependen do proxecto ou desenvolvemento en si.

Proxectos pequenos requiren baixa cantidade de tarefas e tamén de formalidad. En proxectos maiores ou críticos cada rexión de tarefas contén labores de máis alto nivel de formalidad. En calquera caso aplícanse actividades de protección (por exemplo, xestión de configuración do software, garantía de calidade, etc.).

Ao comezo do ciclo, ou proceso evolutivo, o equipo de ingeniería vira ao redor do espiral (metafóricamente falando) comezando polo centro (marcado con ๑ na figura 6) e no sentido indicado; o primeiro circuíto da espiral pode producir o desenvolvemento dunha especificación do produto; os pasos seguintes poderían xerar un prototipo e progresivamente versións máis sofisticadas do software.

Cada paso pola rexión de planificación provoca axustes no plan do proxecto; o custo e planificación se realimentan en función da avaliación do cliente. O xestor de proxectos debe axustar o número de iteraciones requiridas para completar o desenvolvemento.

O modelo espiral pode ir adaptándose e aplicarse ao longo de todo o Ciclo de vida do software (no modelo clásico, ou cascada, o proceso termina á entrega do software).

Unha visión alternativa do modelo pode observarse examinando o "eixe de punto de entrada de proxectos". Cada un dos circulitos (๏) fixados ao longo do eixe representan puntos de arranque dos distintos proxectos (relacionados); a saber:

Cando a espiral caracterízase desta forma, está operativa ata que o software retírase, eventualmente pode estar inactiva (o proceso), pero cando se produce un cambio o proceso arrinca nuevamente no punto de entrada apropiado (por exemplo, en "Mellora do Produto").

O modelo espiral dá un enfoque realista, que evoluciona igual que o software; adáptase moi ben para desenvolvementos a gran escala.

O Espiral utiliza o MCP para reducir riscos e permite aplicalo en calquera etapa da evolución. Mantén o enfoque clásico (cascada) pero incorpora un marco de traballo iterativo que reflicte mellor a realidade.

Este modelo require considerar riscos técnicos en todas as etapas do proxecto; aplicado adecuadamente debe reducilos antes de que sexan un verdadeiro problema.

O Modelo evolutivo como o Espiral é particularmente apto para o desenvolvemento de Sistemas Operativos (complexos); tamén en sistemas de altos riscos ou críticos (Ej. navegadores e controladores aeronáuticos) e en todos aqueles en que sexa necesaria unha forte xestión do proxecto e os seus riscos, técnicos ou de xestión.

Desventajas importantes:

Este modelo non se usou tanto, como o Cascada (Incremental) ou MCP, polo que non se ten ben medida a súa eficacia, é un paradigma relativamente novo e difícil de implementar e controlar.

Modelo espiral Win & Win

Unha variante interesante do Modelo Espiral previamente visto (Fig. 6) é o "Modelo espiral Win-Win"[8] (Barry Boehm). O Modelo Espiral previo (clásico) suxire a comunicación co cliente para fixar os requisitos, en que simplemente pregúntase ao cliente que necesita e el proporciona a información para continuar; pero isto é nun contexto ideal que de cando en cando ocorre. Normalmente cliente e desarrollador entran nunha negociación, negóciase custo fronte a funcionalidad, rendemento, calidade, etc.

"É así que a obtención de requisitos require unha negociación, que ten éxito cando ambas partes gañan".

As mellores negociacións fórzanse en obter "Vitoria & Vitoria" (Win & Win), é dicir que o cliente gañe obtendo o produto que o satisfaga, e o desarrollador tamén gañe conseguindo orzamento e data de entrega realista. Evidentemente, este modelo require fortes habilidades de negociación.

O modelo Win-Win define un conxunto de actividades de negociación ao principio de cada paso ao redor da espiral; defínense as seguintes actividades:

  1. Identificación do sistema ou subsistemas clave dos directivos(*) (saber que queren).
  2. Determinación de "condicións de vitoria" dos directivos (saber que necesitan e satisfaios)
  3. Negociación de condiciónelas "vitoria" dos directivos para obter condiciones "Vitoria & Vitoria" (negociar para que ambos gañen).

(*) Directivo: Cliente escolleito con interese directo no produto, que pode ser premiado pola organización si ten éxito ou criticado si non.

O modelo Win & Win fai énfasis na negociación inicial, tamén introduce 3 fitos no proceso chamados "puntos de fijación", que axudan a establecer a completitud dun ciclo da espiral, e proporcionan fitos de decisión antes de continuar o proxecto de desenvolvemento do software.

Etapas no desenvolvemento do software

Captura, análise e especificación de requisitos

Ao comezo dun desenvolvemento (non dun proxecto), esta é a primeira fase que se realiza, e, segundo o modelo de proceso adoptado, pode case terminar para pasar á próxima etapa (caso de Modelo Cascada Realimentado) ou pode facerse parcialmente para logo retomala (caso Modelo Iterativo Incremental ou outros de carácter evolutivo).

En simple palabras e basicamente, durante esta fase, adquírense, reúnen e especifican as características funcionales e non funcionales que deberá cumprir o futuro programa ou sistema a desenvolver.

As bondades das características, tanto do sistema ou programa a desenvolver, como da súa contorna, parámetros non funcionales e arquitectura dependen enormemente do ben lograda que estea esta etapa. Esta é, probablemente, a de maior importancia e unha das fases máis difíciles de lograr certeramente, pois non é automatizable, non é moi técnica e depende en gran medida da habilidade e experiencia do analista que a realice.

Involucra fuertemente ao usuario ou cliente do sistema, xa que logo ten matices moi subjetivos e é difícil de modelar con certeza ou aplicar unha técnica que sexa "a máis próxima á adecuada" (de feito non existe "a estrictamente adecuada"). Aínda que se idearon varias metodoloxías, ata software de apoio, para captura, elicitación e rexistro de requisitos, non existe unha forma infalible ou absolutamente confiable, e deben aplicarse conjuntamente bos criterios e moito sentido común por parte do ou os analistas encargados da tarefa; é fundamental tamén lograr unha fluída e adecuada comunicación e comprensión co usuario final ou cliente do sistema.

O artefacto máis importante resultado da culminación desta etapa é o que se coñece como especificación de requisitos software ou simplemente documento ERS.

Como se dixo, a habilidade do analista para interactuar co cliente é fundamental; o común é que o cliente teña un obxectivo xeral ou problema a resolver, non coñece en absoluto o área (informática), nin a súa jerga, nin sequera sabe con precisión que debería facer o produto software (que e cantas funcións) nin, moito menos, como debe operar. Noutros casos menos frecuentes, o cliente "pensa" que sabe precisamente o que o software ten que facer, e generalmente acerta moi parcialmente, pero o seu empecinamiento entorpece a tarefa de elicitación. O analista debe ter a capacidade para lidiar con este tipo de problemas, que inclúen relacións humanas; ten que saber poñerse ao nivel do usuario para permitir unha adecuada comunicación e comprensión.

Escasas son as situacións en que o cliente sabe con certeza e ata con completitud o que require do seu futuro sistema, leste é o caso máis sinxelo para o analista.

As tarefas relativas a captura, elicitación, modelado e rexistro de requerimientos, ademais de ser sumamente importante, pode chegar a ser dificultosa de lograr acertadamente e levar bastante tempo relativo ao proceso total do desenvolvemento; ao proceso e metodoloxías para levar a cabo este conxunto de actividades normalmente asúmellas parte propia da Ingeniería de Software, pero dada a antedicha complejidad, actualmente fálase dunha Ingeniería en Requisitos[11] , aínda que ela aínda non existe formalmente.

Hai grupos de estudo e investigación, en todo o mundo, que están exclusivamente abocados á idear modelos, técnicas e procesos para intentar lograr a correcta captura, análise e rexistro de requerimientos. Estes grupos son os que normalmente falan da Ingeniería en Requisitos; é dicir suscítase esta como un área ou disciplina pero non como unha carreira universitaria en si mesma.

Algúns requisitos non necesitan a presenza do cliente, para ser capturados ou analizados; en certos casos pódeos propoñer o mesmo analista ou, ata, adoptar unilateralmente decisións que considera adecuadas (tanto en requerimientos funcionales como non funcionales). Por citar exemplos probables: Algúns requisitos sobre a arquitectura do sistema, requisitos non funcionales tales como os relativos ao rendemento, nivel de soporte a erros operativos, plataformas de desenvolvemento, relacións internas ou ligas entre a información (entre registros ou táboas de datos) a almacenar en caso de bases ou bancos de datos, etc. Algúns funcionales tales como opcións secundarias ou de soporte necesarias para unha mellor ou máis sinxela operatividad; etc.

A obtención de especificaciones a partir do cliente (ou outros actores intervinientes) é un proceso humano moi interactivo e iterativo; normalmente a medida que se captura a información, analízalla e realimenta co cliente, refinándoa, puíndoa e corrixindo si é necesario; calquera sexa o método de ERS utilizado. O analista sempre debe chegar a coñecer a temática e o problema a resolver, dominalo, ata certo punto, ata o ámbito que o futuro sistema a desenvolver abárqueo. Por iso o analista debe ter alta capacidade para comprender problemas de moi diversas áreas ou disciplinas de traballo (que non son específicamente súas); así por exemplo, si o sistema a desenvolver será para gestionar información dunha aseguradora e as súas sucursais remotas, o analista débese compenetrar en como ela traballa e manexa a súa información, desde niveis moi baixos e ata chegando ata os gerenciales. Dada a gran diversidad de campos a cubrir, os analistas adoitan ser asistidos por especialistas, é dicir xente que coñece profundamente o área para a cal desenvolverase o software; evidentemente unha única persoa (o analista) non pode abarcar tan vasta cantidade de áreas do coñecemento. En empresas grandes de desenvolvemento de produtos software, é común ter analistas especializados en certas áreas de traballo.

Contrariamente, non é problema do cliente, é dicir el non ten por que saber nada de software, nin de deseños, nin outras cousas relacionadas; só se debe limitar a aportar obxectivos, datos e información (de man propia ou das súas registros, equipos, empregados, etc) ao analista, e guiado por el, para que, en primeira instancia, defina o "Universo de Discurso", e con posterior traballo logre confeccionar o adecuado documento ERS.

É ben coñecida a presión que sofren os desarrolladores de sistemas informáticos para comprender e rescatar as necesidades dos clientes/usuarios. Canto máis complexo é o contexto do problema máis difícil é logralo, ás veces fórzase aos desarrolladores a ter que converterse en case expertos dos dominios que analizan.

Cando isto non sucede é moi probable que se xere un conxunto de requisitos[12] erróneos ou incompletos e polo tanto un produto de software con alto grado de desaprobación por parte dos clientes/usuarios e un altísimo costo de reingeniería e mantemento. Todo aquilo que non se detecte, ou resulte mal entendido na etapa inicial provocará un forte impacto negativo nos requisitos, propagando esta corrente degradante ao longo de todo o proceso de desenvolvemento e incrementando o seu prexuízo canto máis tardía sexa a súa detección (Bell e Thayer 1976)(Davis 1993).

Procesos, modelado e formas de elicitación de requisitos

Sendo que a captura, elicitación e especificación de requisitos, é unha parte crucial no proceso de desenvolvemento de software, xa que desta etapa depende o logro dos obxectivos finais previstos, ideáronse modelos e diversas metodoloxías de traballo para estes fins. Tamén existen ferramentas software que apoian as tarefas relativas realizadas polo enxeñeiro en requisitos.

O estándar IEEE 830-1998 brinda unha normalización das "Prácticas Recomendadas para a Especificación de Requisitos Software".[13]

A medida que se obteñen os requisitos, normalmente vaillos analizando, o resultado desta análise, con ou sen o cliente, plásmase nun documento, coñecido como ERS ou Especificación de Requisitos Software, cuxa estrutura pode vir definida por varios estándares, tales como CMM-I.

Un primeiro paso para realizar o relevamiento de información é o coñecemento e definición acertada o que se coñece como "Universo de Discurso" do problema, que se define e entende por:

Universo de Discurso (UdeD): é o contexto xeral no cal o software deberá ser desenvolvido e deberá operar. O UdeD inclúe todas as fontes de información e todas as persoas relacionadas co software. Esas persoas son coñecidas tamén como actores dese universo. O UdeD é a realidade circunstanciada polo conxunto de obxectivos definidos por quen demandaron o software.

A partir da extracción e análise de información no seu ámbito obtéñense todas as especificaciones necesarias e tipos de requisitos para o futuro produto software.

O obxectivo da Ingeniería de Requisitos (IR) é sistematizar o proceso de definición de requisitos permitindo elicitar, modelar e analizar o problema, xerando un compromiso entre os Enxeñeiros de Requisitos e os clientes/usuarios, xa que ambos participan na xeración e definición dos requisitos do sistema. A IR aporta un conxunto de métodos, técnicas e ferramentas que asisten aos enxeñeiros de requisitos (analistas) para obter requerimientos o máis seguros, veraces, completos e oportunos posibles, permitindo basicamente:

Aínda que existen diversas formas, modelos e metodoloxías para elicitar, definir e documentar requerimientos, non se pode dicir que algunha delas sexa mellor ou peor que a outra, adoitan ter muchísimo en común, e todas cumpren o mesmo obxectivo. Con todo, o que si se pode dicir sen dúbidas é que é indispensable utilizar algunha delas para documentar as especificaciones do futuro produto software. Así por exemplo, hai un grupo de investigación arxentino que desde fai varios anos propuxo e estuda o uso do LEL (Léxico Estendido da Linguaxe) e Escenarios como metodoloxía, aquí[14] preséntase unha das tantas referencias e bibliografía sobre iso. Outra forma, máis ortodoxa, de capturar e documentar requisitos pódese obter en detalle, por exemplo, no traballo da Universidade de Sevilla sobre "Metodoloxía para a Análise de Requisitos de Sistemas Software".[15]


Na Fig. 7 móstrase un esquema, máis ou menos rigoroso, aínda que non detallado, dos pasos e tarefas a seguir para realizar captúraa, análises e especificación de requerimientos software. Tamén alí obsérvase que artefacto ou documento obtense en cada etapa do proceso. No diagrama non se explicita metodoloxía ou modelo a utilizar, sencillamente se pautan as tarefas que deben cumprirse, dalgún xeito.

Fig. 7 - Diagrama de tarefas para captura e análises de requisitos.

Unha posible lista, xeral e ordenada, de tarefas recomendadas para obter a definición do que se debe realizar, os produtos a obter e as técnicas a empregar durante a actividade de elicitación de requisitos, en fase de Especificación de Requisitos Software é:

  1. Obter información sobre o dominio do problema e o sistema actual (UdeD).
  2. Preparar e realizar as reunións para elicitación/negociación.
  3. Identificar/revisar os obxectivos do usuario.
  4. Identificar/revisar os obxectivos do sistema.
  5. Identificar/revisar os requisitos de información.
  6. Identificar/revisar os requisitos funcionales.
  7. Identificar/revisar os requisitos non funcionales.
  8. Priorizar obxectivos e requisitos.

Algúns principios básicos a ter en conta:

Clasificación e identificación de requerimientos

Pódense identificar dúas formas de requisitos:

É dicir, ambos son o mesmo, pero con distinto nivel de detalle.

Exemplo de requisito de usuario: O sistema debe facer préstamos Exemplo de requisito de sistema: Función préstamo: entrada código socio, código exemplar; saída: data devolución; etc.

Clasifícanse en tres os tipos de requisitos de sistema:

Os requisitos funcionales describen:

Os requisitos non funcionales son restricciones dos servizos ou funcións que ofrece o sistema (ej. cotas de tempo, proceso de desenvolvemento, rendemento, etc.)

Exemplo 1. A biblioteca Central debe ser capaz de atender simultáneamente a todas as bibliotecas da Universidade
Exemplo 2. O tempo de resposta a unha consulta remota non debe ser superior a 1/2 s
Á súa vez, hai tres tipos de requisitos non funcionales:

Os requisitos do dominio derívanse do dominio da aplicación e reflicten características de devandito dominio.

Poden ser funcionales ou non funcionales.

Ej. O sistema de biblioteca da Universidade debe ser capaz de exportar datos mediante a Linguaxe de Intercomunicación de Bibliotecas de España (LIBE). Ej. O sistema de biblioteca non poderá acceder a bibliotecas con material censurado.

Deseño do sistema

Codificación do software

Durante esta a etapa realízanse as tarefas que comúnmente coñécense como programación; que consiste, esencialmente, en levar a código fonte, na linguaxe de programación elixido, todo o deseñado na fase anterior. Esta tarefa realízaa o programador , seguindo por completo os lineamientos impostos no deseño e en consideración sempre aos requisitos funcionales e non funcionales (ERS) especificados na primeira etapa.

É común pensar que a etapa de programación ou codificación (algúns a chaman implementación) é a que insume a maior parte do traballo de desenvolvemento do software; con todo, isto pode ser relativo (e generalmente aplicable a sistemas de pequeno porte) xa que as etapas previas son cruciales, críticas e poden levar bastante máis tempo. Adóitase facer estimacións dun 30% do tempo total insumido na programación, pero esta cifra non é consistente xa que depende en gran medida das características do sistema, o seu criticidad e a linguaxe de programación elixido.[8] En tanto menor é o nivel da linguaxe maior será o tempo de programación requirido, así por exemplo tardaríase máis tempo en codificar un algoritmo en linguaxe ensamblador que o mesmo programado en linguaxe C.

Mentres se programa a aplicación, sistema, ou software en xeral, realízanse tamén tarefas de depuración, isto é o labor de ir liberando ao código dos erros factibles de ser achados nesta fase (de semántica, sintáctica e lóxica). Hai unha sorte de solapamiento coa fase seguinte, xa que para depurar a lóxica é necesario realizar probas unitarias, normalmente con datos de proba; claro é que non todos os erros serán atopados só na etapa de programación, haberán outros que se atoparán durante as etapas subseguintes. A aparición dalgún erro funcional (mala resposta aos requerimientos) eventualmente pode levar a retornar á fase de deseño antes de continuar a codificación.

Durante a fase de programación, o código pode adoptar varios estados, dependendo da forma de traballo e da linguaxe elixida, a saber:

Probas (unitarias e de integración)

Entre as diversas probas que se lle efectúan ao software pódense distinguir principalmente:

As probas normalmente efectúanse cos chamados datos de proba, que é un conxunto seleccionado de datos típicos aos que pode verse sometido o sistema, os módulos ou os bloques de código. Tamén se escollen: Datos que levan a condicións límites ao software a fin de probar a súa tolerancia e robustez; datos de utilidade para medicións de rendemento; datos que propocan condicións eventuales ou particulares pouco comúns e ás que o software normalmente non estará sometido pero poden ocorrer; etc. Os "datos de proba" non necesariamente son ficticios ou "creados", pero normalmente si o son os de pouca probabilidade de ocorrencia.

Generalmente, existe un fase probatoria final e completa do software, chamada Beta Test, durante a cal o sistema instalado en condicións normais de operación e traballo é probado exhaustivamente a fin de atopar erros, inestabilidades, respostas erróneas, etc. que pasen os previos controis. Estas son normalmente realizadas por persoal idóneo contratado ou afectado específicamente a iso. Os posibles erros atopados transmítense aos desarrolladores para o seu depuración. No caso de software de desenvolvemento "a pedido", o usuario final (cliente) é o que realiza o Beta Test, tendo para iso un período de proba pactado co desarrollador.

Instalación e paso a produción

A instalación do software é o proceso polo cal os programas desenvolvidos son transferidos apropiadamente ao computador destino, inicializados, e, eventualmente, configurados; todo iso co propósito de ser xa utilizados polo usuario final. Constitúe a etapa final no desenvolvemento propiamente devandito do software. Logo desta o produto entrará na fase de funcionamento e produción, para o que fose deseñado.

A instalación, dependendo do sistema desenvolvido, pode consistir nunha simple copia ao disco ríxido destino (casos raros actualmente); ou ben, máis comúnmente, cunha de complejidad intermedia na que os distintos arquivos compoñentes do software (ejecutables, bibliotecas, datos propios, etc.) son descomprimidos e copiados a lugares específicos preestablecidos do disco; ata se crean vínculos con outros produtos, ademais do propio sistema operativo. Este último caso, comúnmente é un proceso bastante automático que é creado e guiado con heramientas software específicas (empaquetado e distribución, instaladores).

En produtos de maior complejidad, a segunda alternativa é a utilizada, pero é realizada ou guiada por especialistas; pode ata requirirse a instalación en varios e distintos computadores (instalación distribuída).

Tamén, en software de mediana e alta complejidad normalmente é requirido un proceso de configuración e chequeo, polo cal asígnanse adecuados parámetros de funcionamento e se testea a operatividad funcional do produto.

En produtos de venda masiva as instalacións completas, si son relativamente simples, adoitan ser realizadas polos propios usuarios finais (tales como sistemas operativos, paquetes de oficina, utilitarios, etc.) con ferramentas propias de instalación guiada; incluso a configuración adoita ser automática. En produtos de deseño específico ou "a medida" a instalación queda restrinxida, normalmente, a persoas especialistas involucradas no desenvolvemento do software en cuestión.

Unha vez realizada exitosamente a instalación do software, o mesmo pasa á fase de produción (operatividad), durante a cal cumpre as funcións para as que foi desenvolvido, é dicir, é finalmente utilizado polo (ou os) usuario final, producindo os resultados esperados.

Mantemento

O mantemento de software é o proceso de control, mellora e optimización do software xa desenvolvido e instalado, que tamén inclúe depuración de erros e defectos que poidan haberse filtrado da fase de probas de control e beta test. Esta fase é a última (antes de iterar, segundo o modelo empregado) que se aplica ao ciclo de vida do desenvolvemento de software. A fase de mantemento é a que vén despois de que o software está operativo e en produción.

Dun bo deseño e documentación do desenvolvemento dependerá como será a fase de mantemento, tanto en costo temporal como monetario. Modificacións realizadas a un software que foi elaborado cunha documentación indebida ou pobre e mal deseño pode chegar a ser tanto ou máis custosa que desenvolver o software desde o inicio. Por iso, é de fundamental importancia respectar debidamente todas as tarefas das fases do desenvolvemento e manter adecuada e completa a documentación.

O período da fase de mantemento é normalmente o maior en todo o ciclo de vida.[8] Esta fase involucra tamén actualizaciones e evolucións do software; non necesariamente implica que o sistema tivo erros. Un ou máis cambios no software, por exemplo de adaptación ou evolutivos, pode levar ata a rever e adaptar desde parte das primeiras fases do desenvolvemento inicial, alterando todas as demais; dependendo de cuán profundos sexan os cambios. O modelo cascada común é particularmente custoso en mantemento, xa que a súa rixidez implica que calquera cambio provoca regreso a fase inicial e fortes alteracións nas demais fases do ciclo de vida.

Durante o período de mantemento, é común que xurdan novas revisiones e versións do produto; que o liberan máis depurado, con maior e mellor funcionalidad, mellor rendemento, etc. Varias son as facetas que poden ser alteradas para provocar cambios desexables, evolutivos, adaptacións ou ampliacións e melloras.

Basicamente téñense os seguintes tipos de cambios:

Véxase tamén

Modelos de ciclo de vida

Referencias

  1. ↑ Dicionario da lingua española 2005 (2010). wordreference.com (ed.): «software» (dicionario). Espasa-Calpe. Consultado o 1 de febreiro de 2010.
  2. ↑ http://www.respublicae.net/lingua/silabas/descompoñer.php Silabeador e Transcriptor Fonético e Fonológico
  3. ↑ Real Academia Española. «Significado da palabra Software». Dicionario da Lingua Española, XXIIº Edición. Consultado o 14 de marzo de 2008.
  4. ↑ Real Academia Española. «Uso da palabra Software». Dicionario panhispánico de dúbidas, 1.° Edición (outubro 2005). Consultado o 8 de febreiro de 2009.
  5. ↑ Pressman, Roger S. (2003). «O produto», Ingeniería do Software, un enfoque Práctico, Quinta edición edición., México: Mc Graw Hill.
  6. ↑ IEEE Std, IEEE Software Engineering Standard: Glossary of Software Engineering Terminology. IEEE Computer Society Press, 1993
  7. ↑ a b c d e f g h i j k «Ciclo de Vida do Software». Grupo Alarcos - Escola Superior de Informática de Cidade Real.
  8. ↑ a b c d e Pressman, Roger S. (2003). «O proceso», Ingeniería do Software, un enfoque Práctico, Quinta edición edición., Mexico: Mc Graw Hill.
  9. ↑ «Término "Elicitar"». 1ra. acepción - Wiktionary. Consultado o 15 Dic 2008.
  10. ↑ a b c d e f g h i «Ciclo de vida do Software e Modelos de desenvolvemento». Instituto de Formación Profesional - Libros Digitales.
  11. ↑ Software Requirements Engineering”, 2nd Edition, IEEE Computer Society. Os Alamitos, CA, 1997 (Compendio de papers e artigos en ingeniería de requisitos)
  12. ↑ «III Workshop de Engenharia de Requisitos». WER 2000, Rio de Janeiro, 2000..
  13. ↑ «Recommended Practice for Software Requirements Specification». IEEE-SA Standards Board.
  14. ↑ «LEL e Escenarios como metodoloxía en Ingeniería de Requisitos». Univ. de Morón, Bos Aires.
  15. ↑ «Metodoloxía para a análise de Requisitos de Sistemas Software». Univ. de Sevilla, 2001.

Bibliografía

Libros

Artigos e revistas

Enlaces externos

Wikcionario

Obtido de" http://ks312095.kimsufi.com../../../../articles/a/r/t/Encydia-Wikilingue%7EArt%C3%ADculos_solicitados_2358.html"
Your Ad Here