Análise e deseño detallado de aplicacións de informática e de xestión/Modelos de desenvolvemento de software

Análise e deseño detallado de aplicacións de informática e de xestión
← Volver a Visión xeral da enxeñaría do software	Modelos de desenvolvemento de software	Seguir con Conceptos sobre a xestión de proxectos →

A continuación estudaranse algúns modelos de desenvolvemento de sistemas.

Modelo en cascada

É o ciclo de vida clásico do deseño de aplicacións, e consta de seis fases en cascada, unha tras da outra. Estas seis fases son as que seguen: análise do sistema, análise dos requisitos do software, deseño, programación, proba e mantemento do sistema.

Definición do problema

Análise do sistema

É a análise de requisitos do sistema. Ao desenvolver software, este desenvolvemento non se pode levar a cabo de xeito illado. É necesario estudar os requisitos e as funcionalidades de cada un dos elementos do sistema no que vai funcionar o software desenvolvido.

Análise dos requisitos do software

Unha vez analizado o sistema, o analista, en colaboración co cliente, analizará os requisitos do software que se vai desenvolver, entre os que salientan as súas funcións, o rendemento e maila interface. Nesta fase hai que facer unha análise dos custos, os recursos e mailos riscos, así como definir tempos para as diferentes tarefas que se van desenvolver.

Desenvolvemento

Deseño

Na fase de deseño existen catro tarefas ben diferenciadas:

• definición das estruturas de datos,
• definición da arquitectura do software,
• definición dos algoritmos mediante os que se desenvolven os procedementos, e
• definición das interfaces.

O obxectivo do deseño é a descomposición do sistema en elementos máis pequenos (módulos), que á súa vez poidan descompoñerse noutros elementos máis sinxelos que poidan programarse con facilidade.

Programación

É o paso do deseño a unha linguaxe capaz de ser interpretada polo computador. A codificación e xeración de interfaces pode automatizarse empregando linguaxes de cuarta xeración e ferramentas CASE.

Posta a proba

A posta a proba permite comprobar a lóxica interna dos programas desenvolvidos. Próbase cada un deles comprobando que se obteñen as respostas esperadas aos datos introducidos.

Mantemento do sistema

Unha vez que o software están en funcionamento, faranse necesarias modificacións debido a erros durante a programación, a adaptación do sistema a novas circunstancias e as melloras que se queiras introducir para obter utilidades que non se especificaran durante o desenvolvemento do sistema.

Características do modelo en cascada

Algunhas características deste modelo de desenvolvemento son:

• Cada nova fase comeza ao rematar a fase anterior.
• Para pasar a unha nova fase é preciso conseguir todos os obxectivos da etapa previa.
• Axuda a previr que se superen as datas de entrega e mailos custos previstos.
• Ao rematar cada fase, o persoal técnico e mailos usuarios poden revisar o progreso do proxecto.

Críticas ao modelo en cascada

• Non reflicte o proceso “real” de desenvolvemento de software. Os procesos reais raramente seguen este proceso secuencial, dado que sempre hai iteracións que volven a fases anteriores e as modifican, afectando en consecuencia ás fases que lles seguen no proceso.
• Tárdase moito tempo en pasar por todo o ciclo, dado que ata que non se finalice unha fase non se pasa á seguinte.
• Non lle dá boa impresión ao usuario utilizar software con problemas, polo que mentres non estea completamente probado non se entregarán copias do mesmo, dado que non pode utilizarse para actividades reais.

Modelo de prototipos

O modelo de prototipos utilízase canto se coñecen os obxectivos xerais do sistema pero falta unha definición nos requisitos relativos á entrada de datos, o seu proceso e maila súa saída. O cliente ten que ter claro que o emprego do modelo de prototipos implica un aumento do tempo necesario no desenvolvemento do software, xa que non se entregarán os prototipos, senón o sistema desenvolvido a partires dos requisitos obtidos.

Unha vez desenvolvido o prototipo é necesaria a interacción entre o equipo de desenvolvemento e o cliente. A utilización do prototipo producirá os datos necesarios para refinar o deseño en vista dos requisitos achegados, modificándose sucesivamente o prototipo.

As fases do modelo de prototipos son similares ás do modelo en cascada: análise do sistema e de requisitos, deseño e construción do prototipo, achega de novos requisitos ao prototipo, novo deseño e reconstrución do mesmo, e así ata que se determine que o produto xa está rematado.

O modelo de prototipos permite establecer os requisitos necesarios para o desenvolvemento do software, pero, por mor do seu modo de construción, non é o produto definitivo que se debe entregar ao cliente. Unha vez se conseguiron os requisitos, utilizando o modelo en cascada ou outro modelo de desenvolvemento, xérase o software que o cliente espera.

Modelo expansivo

No modelo expansivo vaise creando o software engadindo compoñentes funcionais ao sistema. Axústase a ambientes de alta incerteza, por non ter a necesidade de posuír un conxunto exhaustivo de requisitos, especificacións, deseños e demais ao comezar o sistema, xa que cada refinamento amplía os requisitos e as especificacións derivadas da fase anterior.

Aínda que permite o cambio continuo de requisitos, aínda existe o problema de determinar se os requisitos propostos son válidos. Os erros nos requisitos detéctanse tarde e a súa corrección resulta tan custosa coma no modelo en cascada.

Modelo de ensamblaxe de compoñentes

O paradigma da orientación a obxectos fai fincapé na creación das clases que agrupan tanto os datos coma os algoritmos que se utilizan para manexar os datos. Se se deseñan e se implantan de maneira axeitada, as clases orientadas a obxectos poden aproveitarse dunhas aplicacións a outras, e dunhas arquitecturas a outras.

A actividade da enxeñaría comeza coa identificación de clases candidatas. os datos e mailos algoritmos correspondentes empaquétanse nunha clase. As clases ─tamén chamadas “compoñentes”─ creadas nos proxectos de enxeñaría do software anteriores almacénanse nunha biblioteca de clases. Unha vez identificadas as claves candidatas, a biblioteca de clases examínase para determinar se estas clases xa existen. En tal caso, extráense da biblioteca e vólvense utilizar. Se unha clase candidata non está xa presente na biblioteca, aplícanse os métodos orientados a obxectos. Componse así a primeira interacción da aplicación a construírse, mediante as clases extraidas da biblioteca e as novas clases construídas para cumprir as necesidades únicas da aplicación. O transcurso do proceso regresa á espiral e volverá introducir por último a iteración de ensamblaxe de compoñentes a través da actividade de enxeñaría.

Técnicas de cuarta xeración

Trátase dun conxunto de ferramentas que permiten a obtención de código fonte a partir de especificacións de alto nivel. As fases do deseño mediante técnicas de cuarta xeración son catro:

• Planificación de requisitos, na que o cliente describe as súas necesidades, obxectivos e restricións.
• A partir destas pode definirse unha estratexia de deseño para a creación da aplicación a desenvolver.
• Se non fixese falla por ser unha aplicación sinxela, unha vez definida a estratexia de deseño, prodúcese a utilización das ferramentas dispoñibles para a súa implantación nunha linguaxe de cuarta xeración que obteña as interfaces gráficas e mailo código fonte.
• Para rematar, defínese un conxunto de probas do sistema e crear toda a documentación anexa ao sistema que non fose creada de modo automático.

Entre as vantaxes do uso de técnicas de cuarta xeración está o incremento da produtividade derivado dunha maior velocidade de desenvolvemento. Un inconveniente é que as técnicas de cuarta xeración non producen o código máis eficiente en cada caso, nin reducen o tempo de desenvolvemento, só se modifica a duración de cada fase, aumenta o tempo adicado á análise e diminúe o da programación.

Análise e deseño detallado de aplicacións de informática e de xestión
← Volver a Visión xeral da enxeñaría do software	Modelos de desenvolvemento de software	Seguir con Conceptos sobre a xestión de proxectos →