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
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:
Inicio
Poñer
o contador de números (C) e a suma (S) a cero
Ler
un número
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 Radio
-
Ler Altura h
-
Calculala base = PI * r * r
-
Calculalo volume = base * h
-
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.
