Tema 2. Fases do desenvolvemeto do software

Fases do desenvolvemento do software

É demasiado frecuente que á hora de desenvolver un programa ou aplicación o programador comece a escribir liñas de código coma un poseso sen pararse a pensar que é o que quere facer, como o vai realizar e que problemas se vai atopar. Elaborar programas con este enfoque é máis unha tarefa artesanal que nos devolverán probablemente solucións inadecuadas. O habitual dende o punto de vista da enxeñaría do software é seguir unha metodoloxía con maior ou menor rigorosidade e precisión que sen dubida debe adaptarse as características e a natureza do proxecto. A grandes trazos e sen entrar en detalles que se sairían dos obxectivos deste curso, as fases que permiten chegar dende a formulación dun problema ata a obtención da aplicación informática que o resolve son os seguintes:

• Análise e especificación de requisitos.
• Deseño do programa.
• Codificación do programa.
• Proba do programa.
• Mantemento do programa.

Análise e especificación de requisitos

Esta fase é fundamental á hora de afrontar a resolución de calquera problema. Consiste en realizar unha descrición clara e completa que adoita a comezar con unha descrición textual xeral que vai sendo refinada e concreta ata culminar coa enumeración dun conxunto de requisitos. Durante esta fase pódense utilizar numerosas técnicas de análise baseadas en gran medida en diagramas de representación de datos, as relacións existentes entre eles, o fluxo dos mesmos e os algoritmos de procesamento que os manipulan. O grao de precisión e refinamento de todos eles establece o grao de abstracción do análise e depende de numerosos factores entre os que destacan as características do propio problema ( non se require o mesmo análise para desenvolver un programa que resolva ecuacións de segundo grao que un que controle a aterraxe dunha aeronave) e a experiencia dos programadores.

O análise e a especificación de requisitos proporciona un documento que non só permite afrontar a tarefa de deseño seguinte senón que ademais é un documento que permite que os promotores e usuarios da aplicación podan comprobar si o analista comprendeu a natureza do problema que se pretende resolver. Nesta fase, polo tanto, é moi importante que participen tanto os desenvolvedores coma os propios promotores e usuarios. Esta fase e crucial para o éxito do proxecto e en resumo é a que permite determinar que hai que facer.

Deseño

Unha ves que o análise permita especificar o que “temos que facer” e os requisitos que deben cumprirse é o momento de determinar como o vamos realizar. Hai que determinar o método que vamos seguir para resolver o problema, que partes ou bloques vai ter o programa, que linguaxe de programación se vai utilizar, etc.

Débense ter en conta as seguintes premisas:

• Por un lado procurar, na medida do posible, minimizar o custe, tamaño e tempo de execución daquilo que se estea a desenvolver. Non esquezamos que as empresas e os programadores intentar gañar cartos.
• Por outro lado, obter a máxima facilidade de uso, fiabilidade, flexibilidade e sinxeleza de mantemento.

Codificación

Consiste en expresar a solución do problema en linguaxe de programación. Hai que destacar que ata esta fase non se escribe nin unha soa liña de código. Ademais , se as fases previas son correctas e completas, o traballo de codificación soe ser bastante directo.

Proba

Nesta fase, unha vez codificado e compilado o programa, búscanselle as “cóxegas” ó programa. O principal é probar que o programa funciona correctamente segundo as especificacións do cliente. Por elo de novo volve a tomar importancia a fase de análise xa que as probas deben estar dirixidas polo que alí se recolleu. De feito, a fase de proba soe estar definida durante o propio análise e na codificación realízanse algunhas probas específicas que permiten obter un código máis fiable. A fase de probas a pesar de que para os programadores noveis no soe ser moi atractiva porque entenden que o produto xa está elaborado, resulta crucial para que o programa ou aplicación poda poñerse en produción (en uso real) coas mínimas garantías de seguridade. Durante esta fase débense avaliar tamén as situacións non previstas no uso normal pero que podan producirse durante o uso do mesmo.

Para que se faga unha idea do importante desta fase, nas empresas de certo tamaño as persoas que desenvolven o programa son distintas das que o proban. E en aplicacións con risco para a vida humana (hospitais, centrais nucleares, aeroportos, etc.) a fase de proba pode supoñer un 80% do tempo total de desenvolvemento.

Mantemento

Unha vez se probou suficientemente o programa entrégaselle ao cliente. Este úsao e o ideal é que nun principio quede satisfeito co resultado. Non obstante e a pesar de todos os esforzos, os análises concienciudos e as probas, poden aparecer erros que impliquen labores de mantemento correctivo. Por outro lado, co paso do tempo poden aparecer especificacións que non estaban contempladas no análise ben porque son novas ou por cambios en factores externos, dando lugar á necesidade de realizar operacións de mantemento adaptativo. Ademais pode ser prudente realizar modificacións en previsión de problemas que aínda non se produciran podan ser froito de problemas nun futuro dando lugar as operacións de mantemento predictivo.

Desenvolvemento en fervenza

Os ciclos de vida no desenvolvemento dunha aplicación poden seguir diferentes enfoques, aínda que nunha primeira toma de contacto co mundo da programación, o modelo máis utilizado é o denominado ciclo en fervenza, no que se realiza cada fase de forma secuencial pero con certo grao de solapamento ( inícianse etapas antes de rematar as anteriores) e con carácter cíclico (volvese a etapas anteriores). Aínda que no ciclo ideal, as fases deben suceder unha trala outra, o normal é que haxa a mencionada realimentación e solapamento. Sen ir máis lonxe, se atopamos erros na fase de probas teremos que regresar a fase de codificación, e si o erro e de deseño ou de análise, teremos que regresar as primeiras fases e reformular a nosa solución. Este ciclo de vida non é o único pero para o nivel deste curso é suficiente.

Durante o ciclo de vida dun desenvolvemento cada fase xera un conxunto de documentos que permiten afrontar as fases seguintes e que finalmente constitúe a documentación asociada ao proxecto que e crucial para afrontar todas as operacións de mantemento. A documentación debe incluír manuais para os diferentes tipos de usuarios (administradores, programadores e usuarios finais).

Concepto de Algoritmo

Defínese Algoritmo coma o conxunto de pasos necesarios para resolver un problema.

Pola súa natureza o algoritmo e previo ao programa, de feito pódese definir programa coma un algoritmo expresado nunha linguaxe de programación determinada. O algoritmo asociado a un problema non é único polo que convén analizar en detalle as diferentes opcións antes de tomar unha decisión. O algoritmo debe ser independente da linguaxe de programación na que se queira desenvolver e da máquina ou ordenador no que posteriormente se execute o programa, aínda que certamente a medida que se descende no nivel de abstracción e se concretan os detalles do algoritmo poden aparecer técnicas asociadas a linguaxe de programación coa que se ten previsto implementar a solución.

Exemplo de algoritmo

Deséxase resolver o seguinte problema: calcular o valor medio dunha serie de números positivos que se leen dende o teclado. Un valor cero ou negativo indicará o final da serie. O texto anterior constitúe o enunciado do problema que se desexa resolver e polo tanto e a especificación “en bruto” que debe ser refinada. A natureza de cada problema é diferente e polo tanto o programador non ten porque coñecer os detalles e os métodos asociados a cada problema. Isto fai preciso engadir información que explique con precisión o proceso ao que se someterán os datos de entrada para proporcionar os resultados de saída. Neste exemplo: o valor medio dun conxunto de números é o resultado de sumalos e dividir esa suma polo número de elementos. Polo tanto precisamos ir contando o número de valores que se suman e ir acumulando a suma. Con toda esta información proponse o seguinte algoritmo expresado en linguaxe “casi-verbal” coñecido coma pseudocódigo.

Algoritmo:

1. Inicio
2. Poñer o contador de números (C) e a suma (S) a cero
3. Ler un número
4. Si o número é positivos

1. Sumar o número a suma S

2. Incrementar en 1 o contador C

3. Ler o seguinte número

4. Ir ao paso 3

5. Calcular o valor medio (S/C)

6. Escribir o valor medio

7. Fin

Podemos observar que só pasaremos ao punto 4 (calcular o valor medio) cando ao executar o paso 3 o número non sexa positivo.

Observemos nesta táboa como se van modificando S e C a medida que imos lendo valores, utilizando para elo unha secuencia de números de entrada calquera (3,5,4,9,8,6,-2).

ENTRADA S C S/C
0 0
3 0+3=3 0+1=1
5 3+5=8 1+1=2
4 8+4=12 2+1=3
9 12+9=21 3+1=4
8 21+8=29 5+1=5
6 29+6=35 5+1=6
-2 35 6 35/6=5,83

Características dun algoritmo

Un algoritmo debe ser:

• Preciso (instrucións claras e concretas) e ordenado.
• Determinista (que o resultado sexa o mesmo ao executalo varias veces cos mesmos datos de entrada).
• Finito (que remate a súa execución baixo as condicións previstas).

Ademais, o deseño dun algoritmo:

• Debe ser descendente, de arriba cara abaixo (top-down), dividíndose o problema en subproblemas.
• Debe presentar un grao de refinamento sucesivo, e dicir, trátase de ir detallando a descrición en cada paso.
• A representación do algoritmo, de cara a súa especificación mediante unha ferramenta de programación, farase mediante diagramas e/ou pseudocódigo.

Intentemos explicar estas características con outro exemplo:

Supoñamos que o problema a resolver sexa calcular o volume dun cilindro.

E para que? No noso caso imos instalar uns paneis solares para quentar auga, e temos o tamaño do depósito, pero non o da auga que é capaz de conter.

Por sorte, revisando un vello libro de xeometría, atopamos que o volume dun cilindro é o resultado de multiplicar a súa base pola súa altura. E cal é a súa base? Houbo sorte, na mesma páxina atopamos que a base obtense multiplicando o radio ao cadrado pola constante PI. Problema resolto!.

A hora de trasladar este razoamento ao mundo da programación comezaríamos por dividir o problema en subproblemas, os cales poderían ser:

• Ler os datos
• Realizar os cálculos
• Escribir os resultados

Ben parece sinxelo. Temos claramente diferenciadas tres partes do programa.

Divide e vencerás!

Agora faise necesario ir detallando un pouco máis as partes anteriores. Isto é o que chamamos refinamento sucesivo. Unha posibles solución sería a seguinte:

• Ler datos estaría composto por outras subtarefas que serían:

- Ler Radio

- Ler Altura h

• Realizar cálculos descomporíase en:

- Calculala base = PI * r * r

- Calculalo volume = base * h

• Escribir resultado que daría simplemente:

- Escribir volume

Representación de Algoritmos

Estudamos que un algoritmo debe ser independente da linguaxe de programación que posteriormente se utilice (con algúns matices). Isto implica que o método que usemos para a representación dun algoritmo tamén debe ser independente da linguaxe de programación.

Tradicionalmente utilizáronse dúas formas para representar algoritmos, aínda que actualmente existen multitude de técnicas tan gráficas coma textuais que están deseñadas para representar diferentes aspectos dos algoritmos e dos datos asociados a unha aplicación. Non obstante nunha primeira aproximación ao mundo da programación as máis destacadas son as seguintes:

• Diagramas de fluxo
• Pseudocódigo

A primeira delas é unha forma de representación gráfica das estruturas de control que terá o noso programa e que estudaremos no tema Estruturas de control. A segunda consiste en crear unha linguaxe de programación xenérica que poda ser trasladada con facilidade a calquera outra linguaxe de programación.

Esta linguaxe polo seu enfoque é unha pseudo-linguaxe similar a que usamos en exemplos previos e que será a que usemos neste curso.

Diagramas de fluxo

Utiliza símbolos (caixas de distinta xeometría) unidos por frechas (liñas de fluxo) que indican a orde ou dirección do fluxo do programa.

Algúns dos símbolos que se utilizan son:

Programación Modular e Estruturada

Neste apartado estudaremos: os dous paradigmas da programación máis empregados, aínda que non son os únicos, que están baseados por un lado na descomposición dun determinado problema en módulos independentes (programación Modular), e a programación de cada módulo mediante métodos estruturados (Programación Estruturada).

O primeiro fundamentase no sabio consello de “divide e vencerás”, mentres que o segundo fundamentase en que calquera0 algoritmo pode ser elaborado empregando exclusivamente tres estruturas básicas de control. Imos analizar un pouco máis estes conceptos.

Programación Modular

Neste paradigma:

• O programa divídese en módulos independentes casa un dos cales executa unha determinada tarefa e resolve un problema concreto.
• Existirá un módulo denominado módulo principal que será o encargado de transferir o control a os demais módulos (denominados submódulos). A súa función principal e a de ser o fío condutor do programa.
• Ao ser os módulos independentes pódense desenvolver e probar ao mesmo tempo e con alta independencia. O obxectivo e concibir módulos independentes uns de outros e con alta cohesión (cada módulos serve para algo en concreto).
• As vantaxes serán unha maior claridade e lexibilidade, gran facilidade para modificar os programas e redución de custo de desenvolvemento.

Por outra parte, si hai partes ou cálculos do noso programa que se repiten, codificaranse coma módulo unha única vez e chamarase varias veces a ese módulo dende onde faga falla. Os módulos reciben datos de entrada denominados parámetros que so procesados internamente para devolver un conxunto de resultados. Obviamente tanto os parámetros coma os resultados non son sempre imprescindibles.

A programación Modular segue sendo un deseño descendente (top-down) que significa que primeiro débese especificar que é o que se quere facer globalmente e a continuación vaise dividindo esa tarefa principal en subtarefas, cada unha das cales da lugar a un ou varios módulos. Esta técnica require de un refinamento sucesivo ata chegar a un nivel de subtarefas abordables don facilidade.

Programación Estruturada

A programación Estruturada parte da premisa que afirma que calquera algoritmo pode ser organizado utilizando exclusivamente tres estruturas de control:

• Secuencial
• Selectiva
• Repetitiva

Utilizar as técnicas da programación estruturada implica unha diminución no tempo que se dedica á verificación, depuración e mantemento das aplicacións. Isto implica menor custo de desenvolvemento e maior calidade no produto.