Академический Документы
Профессиональный Документы
Культура Документы
S O FT WA R E Y E L D E S A R R O L LO
I N F O R M T I C O
A P U N T E S D E I NG E N I E R A D E S O FT WA R E
TABLA DE CONTENIDO
INTRODUCCIN..........................................................6
RESUMEN EJECUTIVO.............................................................................7
AGREDECIMIENTOS................................................................................7
MODELO
MODELO
MODELO
MODELO
MODELO
MODELO
MODELO
MODELO
MODELO
MODELO
LINEAL SECUENCIAL............................................................................14
DE CONSTRUCCIN DE PROTOTIPOS..................................................15
ITERATIVO INCREMENTAL....................................................................16
ESPIRAL............................................................................................... 17
DE DESARROLLO RPIDO DE APLICACIONES (RAD).............................18
DE ESPIRAL WIN-WIN..........................................................................19
DE DESARROLLO CONCURRENTE........................................................20
DE DESARROLLO BASADO EN COMPONENTES....................................21
DE MTODOS FORMALES....................................................................22
DEL MARCO DE TRABAJO PARA SOLUCIONES MICROSOFT (MSF).........22
REFLEXIONES.......................................................................................30
INGENIERA DE REQUERIMIENTOS.......................................................41
STAKEHOLDERS...................................................................................................... 41
EL PROCESO ITERATIVO DE LA OBTENCIN DE REQUERIMIENTOS.........................42
TCNICAS DE IDENTIFICACIN Y ANLISIS DE REQUERIMIENTOS...........................43
ENTREVISTAS CON STAKEHOLDERS..............................................................................43
TCNICAS PARA FACILITAR LA ESPECIFICACIN DE UNA APLICACIN (TFEA)........................44
DESPLIEGUE DE LA FUNCIN DE CALIDAD (DFC)...........................................................45
CASOS DE USO....................................................................................................... 47
TCNICAS DE FORMALIZACIN Y MODELAMIENTO DE REQUERIMIENTOS..............47
ESPECIFICACIONES EN LENGUAJE NATURAL....................................................................48
ESPECIFICACIONES EN LENGUAJE ESTRUCTURADO...........................................................48
ESPECIFICACIONES CON MODELOS GRFICOS................................................................50
REFLEXIONES.......................................................................................53
REFLEXIONES.......................................................................................84
ESTILOS DE PROGRAMACIN..................................................................................95
FACTORES DE CALIDAD.......................................................................................... 96
REFLEXIONES.....................................................................................102
LA DETECCIN DE ERRORES..............................................................111
DISEO DE LOS CASOS DE PRUEBA.....................................................................112
PRUEBA DE CAJA NEGRA......................................................................................... 113
PRUEBA DEL CAMINO BSICO..................................................................................114
PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURAS Y APLICACIONES......................114
ESTRATEGIAS DE PRUEBA....................................................................................115
PRUEBA DE UNIDAD............................................................................................... 116
PRUEBA DE INTEGRACIN........................................................................................116
PRUEBA DE VALIDACIN......................................................................................... 117
PRUEBA DE SISTEMA.............................................................................................. 117
LA GARANTA DE CALIDAD.................................................................118
ESTNDARES DE CALIDAD....................................................................................119
TIPOS DE ESTNDARES DE CALIDAD....................................................................120
ESTNDARES DE PROCESO......................................................................................120
ESTNDARES DE PRODUCTO....................................................................................121
EL CONTROL DE LA CALIDAD.............................................................122
ENFOQUES DEL CONTROL DE CALIDAD................................................................122
LAS REVISIONES DEL SOFTWARE.........................................................................122
REVISIONES INFORMALES........................................................................................123
REVISIONES FORMALES........................................................................................... 124
LAS MTRICAS DEL SOFTWARE............................................................................126
FACTORES DE CALIDAD........................................................................................... 127
MTRICAS
PARA LOS
FACTORES
DE
CALIDAD...............................................................129
REFLEXIONES.....................................................................................134
ANEXOS.................................................................141
METODOLOGAS GILES DE PROGRAMACIN....................................142
EL MANIFIESTO GIL............................................................................................. 142
XP (EXTREME PROGRAMMING).............................................................................143
OTRAS METODOLOGAS GILES...........................................................................145
ESTNDARES DE CODIFICACIN........................................................147
ESTNDAR DE CODIFICACIN PARA JAVA..............................................................147
ESTNDAR DE CODIFICACIN PARA PHP..............................................................149
ESTNDAR DE CODIFICACIN PARA .NET.............................................................150
ESTNDARES DE PROCESO................................................................154
CMMI.................................................................................................................... 154
REAS DE PROCESO.............................................................................................. 155
EVALUACIN......................................................................................................... 156
ISO 9000.............................................................................................................. 157
MARCO CONCEPTUAL DE LAS NORMAS ISO 9000.......................................................158
NORMA ISO 9001................................................................................................ 158
PROCESO DE CERTIFICACIN....................................................................................160
SPICE (ISO/IEC 15504).......................................................................................... 160
CARACTERSTICAS.................................................................................................. 161
DIMENSIONES SPICE............................................................................................. 161
BIBLIOGRAFA.....................................................................................163
TABLA DE ILUSTRACIONES.................................................................164
INTRODUCCIN
RESUMEN EJECUTIVO
Este documento contiene una compilacin de clases y apuntes del curso de
Ingeniera de Software dictado por el profesor Andrs Muoz O. durante 2 aos
a alumnos de sexto semestre de la carrera de Ingeniera en Computacin en
Informtica del Instituto Profesional La Araucana.
Los contenidos principales se dividen en 6 unidades:
AGREDECIMIENTOS
Agradezco profundamente a mis alumnos del instituto de los aos 2008
y 2009, quienes recibieron este apunte clase a clase, y por supuesto
fueron informando todo tipo de errores e inconsistencias que
encontraban.
Adems, agradecer el apoyo y confianza de los profesores Ral Rojas y
Nelson Carvallo, quienes me dieron la oportunidad de lograr desarrollar
este ramo. Tambin al profesor Daniel Muoz G., quien tambin dict el
curso y me entreg parte de la informacin que aqu se encuentra
descrita.
QU ES LA INGENIERA DE SOFTWARE?
Aunque muchos autores han desarrollado definiciones personales de la
ingeniera del software, una definicin propuesta por Fritz Bauer en una
conferencia de gran influencia sobre estos temas va a servir como base de
estudio:
LA INGENIERA DEL SOFTWARE ES EL ESTABLECIMIENTO
Y USO DE PRINCIPIOS ROBUSTOS DE LA INGENIERA, A
FIN DE OBTENER ECONMICAMENTE SOFTWARE QUE
SEA FIABLE Y QUE FUNCIONE EFICIENTEMENTE SOBRE
MQUINAS REALES.
Casi todos tendran la tentacin de seguir esta definicin. No dice mucho sobre
los aspectos tcnicos de la calidad del software: no se enfrenta directamente
con la necesidad de la satisfaccin del cliente o de la entrega oportuna del
producto, omite la mencin de la importancia de mediciones y mtricas y
tampoco expresa la importancia de un proceso avanzado.
Y, sin embargo, la definicin de Bauer nos proporciona una lnea base. Cules
son los principios robustos de la ingeniera aplicables al desarrollo de
software? Cmo construimos el software econmicamente para que sea
fiable? Qu se necesita para crear programas de computador que funcionen
eficientemente, no en una mquina sino en mquinas reales? Estas son
cuestiones que siguen siendo el reto para los ingenieros del software.
El IEEE ha desarrollado una definicin ms completa:
LA INGENIERA DEL SOFTWARE ES LA APLICACIN DE UN
ENFOQUE
SISTEMTICO,
DISCIPLINADO
Y
CUANTIFICABLE HACIA EL DESARROLLO, OPERACIN Y
MANTENIMIENTO DEL SOFTWARE.
11
Los artefactos que se producen dentro del proceso se definen al principio y van
a depender de la metodologa que se utilice, del marco legal, de las normativas
internas de las compaas involucradas, de las negociaciones iniciales, etc.
Algunos de estos artefactos se consideran especialmente dado que dentro de
la definicin inicial se establece que se har entrega de ellos y se define
cundo, cmo y/o a quin se har esta entrega. Por este motivo se los
denomina entregables.
El software es, claramente, el principal de estos entregables.
EL SOFTWARE
En 1970, menos del uno por ciento de las personas podra haber descrito
inteligentemente lo que significa software. Hoy, la mayora de los
profesionales y muchas personas, en general, piensan que comprenden el
software. Pero lo entienden realmente?
CARACTERSTICAS DEL SOFTWARE
Para poder comprender lo que es el software (y consecuentemente, la
ingeniera del software), es importante examinar las caractersticas del
software que lo diferencian de otras cosas que los hombres pueden construir.
Cuando se construye un hardware, el proceso creativo humano (anlisis,
diseo, construccin, prueba) se traduce en una forma fsica. Si construimos un
nuevo computador, nuestro boceto inicial, diagramas formales de diseo y
prototipo de prueba evolucionan hacia un producto fsico.
El software es un elemento del sistema que es lgico, en lugar de fsico. Por
tanto, el software tiene unas caractersticas considerablemente distintas a las
del hardware.
Aunque existen similitudes entre el desarrollo del software y la construccin del
hardware, ambas actividades son fundamentalmente diferentes. Ambas
actividades dependen de las personas, pero la relacin entre las personas
dedicadas y el trabajo dedicado es completamente diferente para el software
Los costes del software se encuentran en la ingeniera. Esto significa que los
proyectos de software no se pueden gestionar como si fueran proyectos de
construccin.
Un aspecto claro en la diferencia entre la construccin de hardware y el
desarrollo del software est en el mantenimiento. Cuando el hardware se
estropea, se sustituye alguna pieza por otra nueva. En cambio, no hay piezas
de repuesto para el software: cada fallo en el software implica un problema en
el diseo en la forma en que este fue llevado a su forma final, por lo tanto, el
mantenimiento del software tiene una complejidad mucho mayor a la del
mantenimiento del hardware.
Otra clara diferencia est relacionada con el hecho de que la construccin en la
industria est ms automatizada y consiste normalmente en ensamblar
12
16
EL MODELO ESPIRAL
El modelo en espiral, propuesto originalmente por Boehm, es un modelo de
proceso de software evolutivo que conjuga la naturaleza iterativa de
construccin de prototipos con los aspectos controlados y sistemticos del
modelo lineal secuencial. Proporciona el potencial para el desarrollo rpido de
versiones incrementales del software. En el modelo espiral, el software se
desarrolla en una serie de versiones incrementales. Durante las primeras
iteraciones, la versin incremental podra ser un modelo en papel o un
prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms
completas del sistema diseado.
El modelo en espiral se divide en un nmero de actividades de marco de
trabajo, tambin llamadas regiones de tareas. Generalmente, existen entre tres
y seis regiones de tareas. Un modelo de seis regiones puede contener:
19
para
construir
una
ms
Cada una de las regiones est compuesta por un conjunto de tareas del
trabajo, llamado conjunto de tareas, que se adaptan a las caractersticas del
proyecto que va a emprenderse. Para proyectos pequeos, el nmero de tareas
de trabajo y su formalidad es bajo. Para proyectos mayores y ms crticos cada
regin de tareas contiene tareas de trabajo que se definen para lograr un nivel
ms alto de formalidad. En todos los casos, se aplican las actividades de
proteccin (por ejemplo: gestin de configuracin del software y garanta de
calidad del software) mencionadas ms adelante en este apunte.
Cuando empieza este proceso evolutivo, el equipo de ingeniera del software
gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando
por el centro. El primer circuito de la espiral puede producir el desarrollo de una
especificacin de productos; los pasos siguientes en la espiral se podran
utilizar para desarrollar un prototipo y progresivamente versiones ms
sofisticadas del software. Cada paso por la regin de planificacin produce
ajustes en el plan del proyecto. El coste y la planificacin se ajustan con la
realimentacin ante la evaluacin del cliente. Adems, el gestor del proyecto
ajusta el nmero planificado de iteraciones requeridas para completar el
software.
A diferencia del modelo de proceso clsico que termina cuando se entrega el
software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida
del software de computadora.
El modelo en espiral demanda una consideracin directa de los riesgos tcnicos
en todas las etapas del proyecto, y, si se aplica adecuadamente, debe reducir
los riesgos antes de que se conviertan en problemticos.
20
Generacin
de
Aplicaciones:
Se
construye
el
software
(preferentemente con lenguajes de cuarta generacin y reutilizacin de
componentes de software.
Bajo desarrollo
Cambios en espera
22
Bajo modificacin
Bajo revisin
En lnea base
Realizado
23
24
3
Mayor
informacin
http://en.wikipedia.org/wiki/Microsoft_Solutions_Framework
25
en
NECESIDADES
PROBLEMA 4
EXPLCITAS
IMPLCITAS
DE
UN
TIPOS DE ESTNDARES
27
Redaccin de la propuesta
Para hacer tangible estas labores, los gestores deben describir algunos
documentos estndares a todo proyecto:
Plan
de
Mantenimiento:
Describe
los
requerimientos
de
mantenimiento del sistema, los costes del mantenimiento y el esfuerzo
predecido.
ESPECIFICACIN DE REQUERIMIENTOS
La ingeniera de requerimientos es el proceso a travs del cual se capturan las
necesidades del usuario y se convierten en requerimientos formales, a travs
de una especificacin. Este proceso tiene 4 grandes pasos:
Requerimientos
Especficos:
en
donde
se
describen
los
requerimientos funcionales, no funcionales y de interfaz, en detalle.
Dependiendo del detalle, se utilizan distintas tcnicas de especificacin
como diagramas, lenguajes estructurados o incluso algebraicos y
pseudocdigo.
modelan
Prefacio,
Usuario,
Sistema,
DESARROLLO
La implementacin de los sistemas constituye la etapa ms dura dentro del
ciclo de vida, ya que es donde se transforma el diseo en un producto final. Por
esta razn, tambin se transforma en un problema cuando se trata de
intervenir.
La documentacin durante el desarrollo es clave para orientar y permitir el
mantenimiento de los sistemas, ya que tienen como misin definir los
elementos bsicos en un lenguaje comprensible por los futuros expertos que lo
deben intervenir. A esto se le llama Documentacin del Cdigo o de
Programas.
Existen varias tcnicas de documentacin del cdigo:
31
Comentarios en los Programas: Tienen por objetivo describir inline, utilizando textos entre las lneas de cdigo, algunas ideas que
permitan orientar para qu sirve cada parte del programa en detalle. En
este tipo de documentacin tambin se estila incluir definicin ms
funcional como encabezados de los programas, permitiendo entender el
funcionamiento de cada una de las partes del programa de acuerdo al
uso que se le va a dar.
Todos estos planes es recomendable plasmar su resultado en documentos adhoc de pruebas con sus resultados, de modo que se mantenga control de las
incidencias y cmo se van corrigiendo los problemas detectados a lo largo del
proyecto.
OTROS MBITOS
Dentro del ciclo de vida del software, tambin existen otros mbitos donde es
importante documentar con estndares el trabajo. A continuacin una mirada a
algunos:
Gran parte de esta informacin ser revisada a lo largo del curso, pero
enunciar su importancia no est de ms, ya que permite dimensionar la
necesidad de la documentacin en las distintas etapas del ciclo de vida.
REFLEXIONES
Ahora veamos algunas preguntas clave respecto a esta unidad.
Qu es la Ingeniera de Software?
Es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable
hacia el desarrollo, operacin y mantenimiento de un software. Esta
definicin tiene 2 partes claves: una tiene que ver con el proceso
sistemtico y disciplinado, una clave muy importante, adems de ser
cuantificable, es decir, que puede ser medido; y por otro lado tambin
est la clave de que este enfoque va apuntado tanto al desarrollo como
a la operacin y mantenimiento del software, es decir, a su ciclo de vida.
33
Software de
comerciales.
Gestin:
centrado
en
el
apoyo
las
reas
34
Qu hay que hacer despus con el prototipo, luego que es validado por
el cliente?
La teora nos dice que debe ser descartado para comenzar con el diseo
desde cero. Por lo tanto, para mantener esta lgica, el proyecto debe ser
planificado considerando desde el principio que el prototipo es
desechable.
36
Qu es CMMI?
El Capability Maturity Model Integration es un modelo que permite
certificar diferentes procesos (produccin, adquisicin y de servicios)
para que sean eficaces.
Existen 3 tipos:
o
o
o
Nivel
Nivel
Nivel
Nivel
Nivel
Nivel
0:
1:
2:
3:
4:
5:
Incompleto
Ejecutado
Gestionado
Definido
Cuantitativamente Gestionado
Optimizado
Qu es SCAMPI?
Es un modelo para evaluar los procesos segn CMMI, para determinar
que tan bien los procesos se comparan con las mejores prcticas CMMI,
informar a los clientes y cumplir con los requerimientos contractuales.
Responsabilidad de direccin.
38
o
o
o
Gestin de recursos.
Realizacin del producto.
Medicin, anlisis y mejora.
Nivel 0: Incompleto
Nivel 1: Realizado (equivalente a Ejecutado de CMMI)
Nivel 2: Gestionado
Nivel 3: Establecido (equivalente a Definido de CMMI)
Nivel 4: Predecible (equivalente a Cuantitativ. Gestionado de
CMMI)
Nivel 5: En Optimizacin (equivalente a Optimizado de CMMI)
Qu es la estandarizacin?
39
Especificacin de requerimientos
Documento de diseo
Plan de pruebas
Carta Gantt
Especificacin de Programas
40
41
NECESIDADES O REQUISITOS/REQUERIMIENTOS?
Existe una amplia discusin lingstica respecto a los trminos requerimiento
y necesidad, ya que tienen interpretaciones muy similares, an cuando su
enfoque puede ser totalmente diferente ya que uno existe como una
consecuencia de otro.
Cuando hablamos de una necesidad queremos decir que existe una carencia o
la exigencia de algo (producto, servicio, funcin, etc). Por ejemplo, cuando se le
pide a un artista pintar un cuadro, esto nace de una necesidad (porque yo
quiero tener un cuadro en mi sala) pero no es un requerimiento, porque es algo
que yo (como cliente) deseo tener, es una carencia o algo que mi entorno
exige (una pared vaca, por ejemplo). De esta manera, el artista podra pintar
lo que a l le plazca, an cuando no sea lo que nosotros esperamos.
Sin embargo, cuando hablamos de un requerimiento, lo que queremos decir al
artista es algo ms preciso: yo deseo un cuadro de 50 centmetros de alto y
80 centmetros de ancho, en donde est representada una casa de campo en
un ambiente otoal, en donde se vean los animales de la granja y un da claro,
esto se asemeja ms a un requerimiento, ya que estamos dando la informacin
necesaria para que nuestro interlocutor pueda realizar la labor o resuelva
nuestra necesidad (el tener un cuadro en mi sala).
Si esto lo llevamos a un mundo ms industrial, de una manera formal podemos
decir que:
UN REQUERIMIENTO ES UNA NECESIDAD DOCUMENTADA
SOBRE EL CONTENIDO, FORMA O FUNCIONALIDAD DE
UN PRODUCTO O SERVICIO.
Los requerimientos para un sistema son la descripcin de los servicios que ste
debe proporcionar y sus restricciones operativas. El proceso de descubrir,
analizar, documentar y verificar estos servicios y restricciones se denomina
ingeniera de requerimientos.
El trmino requerimiento no se utiliza de forma constante en la industria del
software. En algunos casos, un requerimiento es simplemente una declaracin
abstracta de alto nivel de un servicio que debe proporcionar el sistema o una
restriccin de ste. En el otro extremo, es una definicin detallada y formal de
una funcin del sistema.
Si una compaa desea establecer un contrato para un proyecto de desarrollo
de software grande, debe definir sus necesidades de una forma
suficientemente abstracta para establecer a partir de ella una solucin. Los
requerimientos deben redactarse de tal forma que varios contratistas puedan
licitar el contrato, ofreciendo, quizs, formas diferentes de cumplir las
necesidades de los clientes en la organizacin. Una vez que el contrato se
42
asigna, el contratista debe redactar una definicin del sistema para el cliente
ms detalladamente, de forma que este comprenda y pueda validar lo que el
software har. Ambos documentos se pueden denominar documento de
requerimientos.
Algunos de los problemas que surgen durante el proceso de ingeniera de
requerimientos son resultado de no hacer una clara separacin entre estos
diferentes niveles de descripcin.
TIPOS DE REQUERIMIENTOS
En la disciplina de ingeniera de software, los requerimientos se distinguen
utilizando la denominacin de requerimientos del usuario para designar los
requerimientos abstractos de alto nivel y de requerimientos del sistema
para designar la descripcin detallada de lo que el sistema debe hacer.
43
44
INGENIERA DE REQUERIMIENTOS
El desafo de la ingeniera del sistema (y de los ingenieros del software) es
importante: Cmo podemos asegurar que hemos especificado un sistema que
recoge las necesidades del cliente y satisface sus expectativas? No hay una
respuesta segura a esta difcil pregunta, pero un slido proceso de ingeniera
de requisitos es la mejor solucin de que disponemos actualmente.
La ingeniera de requisitos o de requerimientos facilita el mecanismo
apropiado para comprender lo que quiere el cliente, analizando necesidades,
confirmando su viabilidad, negociando una solucin razonable, especificando la
solucin sin ambigedad, validando la especificacin y gestionando los
requisitos para que se transformen en un sistema operacional. El proceso de
ingeniera de requisitos puede ser descrito en 6 pasos distintos.
45
STAKEHOLDERS
La obtencin y anlisis de requerimientos pueden afectar a varias personas de
la organizacin. El trmino stakeholder se utiliza para referirse a cualquier
persona o grupo que se ver afectado por el sistema, directa o indirectamente.
Entre los stakeholders se encuentran los usuarios finales que interactan con el
sistema y todos aqullos en la organizacin que se pueden ver afectados por
su instalacin. Otros stakeholders del sistema pueden ser los ingenieros que
desarrollan o dan mantenimiento a otros sistemas relacionados, los gerentes
del negocio, los expertos en el dominio del sistema y los representantes de los
trabajadores.
Obtener y comprender los requerimientos de los stakeholders es difcil por
varias razones:
Documentacin
de
requerimientos:
se
documentan
los
requerimientos y se entra en la siguiente vuelta de la espiral. Se pueden
producir documentos de requerimientos formales o informales.
47
Es necesario acordar una agenda que sea tan formal como para cubrir
todos los puntos importante e informal como para motivar al flujo
natural de ideas.
49
50
A pesar que la tcnica como tal es aplicable a cualquier nivel del proceso de
desarrollo, es importante destacar que en todos los pasos el funcionamiento es
el mismo: a travs de matrices de informacin.
La analoga ms simple y ms utilizada de DFC es una casa:
Lo primero que se definen son cules son los requerimientos del cliente para el
producto o servicio (pared izquierda). Luego se debe definir algunos issues de
planeacin que tienen que ver con los requerimientos descritos (pared
derecha). Otra informacin relevante tiene que ver con las especificaciones
tcnicas de los requerimientos (techo interior). Adems, se define en el centro
lo que tiene que ver con los requerimientos convertidos en trminos del
desarrollo (interior). La parte inferior define la jerarquizacin de los requisitos
de acuerdo a su criticidad (cimiento). Por ltimo, se definen en la parte superior
cules son las proyecciones del proyecto (techo exterior).
Finalmente, el resultado de utilizar un enfoque DFC puede obtener una matriz
de correlacin como la siguiente:
51
De esta manera, podemos ver que la tcnica utilizar una herramienta bastante
ms formal al momento de definir las diferentes dimensiones de los
requerimientos. Es por eso que es un interesante enfoque cuando se habla de
operar en procesos de calidad.
CASOS DE USO
Normalmente las personas encuentran ms fcil dar ejemplos de la vida real
que descripciones abstractas. Pueden comprender y criticar un escenario de
cmo ellos podran interactuar con un sistema de software. Los ingenieros de
requerimientos pueden utilizar la informacin obtenida de esta discusin para
formular los requerimientos reales del sistema.
Los escenarios pueden ser especialmente tiles para agregar detalle a un
esbozo de la descripcin de requerimientos. Son descripciones de ejemplos de
las sesiones de interaccin. Cada escenario abarca una o ms posibles
interacciones. Se han desarrollado varias formas de escenarios, cada una de
las cuales proporciona diferentes tipos de informacin en diferentes niveles de
detalle sobre el sistema. Utilizar escenarios para describir requerimientos es
una parte fundamental de los mtodos giles, como la programacin extrema.
Los casos de uso son una tcnica que se basa en escenarios para la obtencin
de requerimientos que se introdujo por primera vez en el mtodo Objectory.
Actualmente se han convertido en una caracterstica fundamental de la
notacin de UML, que se utiliza para describir modelos de sistema orientados a
objetos. En su forma ms simple, el caso de uso identifica el tipo de interaccin
y los actores involucrados.
52
53
55
nn
Cursos Alternos:
nn
Otros Datos:
Observaciones:
ILUSTRACIN 10. PLANTILLA PARA LA ESPECIFICACIN DE CASOS DE USO
56
Modelo de Contexto: Sirve para definir los lmites del sistema. En este
caso, se puede presentar un diagrama sencillo en donde se muestra al
sistema en el centro y las interacciones con otros sistemas o fuentes de
informacin externas, las cuales no sern intervenidas.
58
REFLEXIONES
Ahora veamos algunas preguntas clave respecto a esta unidad.
59
los
requerimientos
funcionales,
no
Identificacin
Anlisis y negociacin
Especificacin
Modelado del sistema
Validacin
Gestin
Qu es un stakeholder?
El stakeholder es toda persona que tiene o se ve afectado por el sistema,
ya sea desde el punto de vista de la operacin (usuarios finales),
expertos del negocio (gerentes) o del equipo de desarrollo y mantencin.
60
A qu se refiere TFEA?
TFEA se refiere a un conjunto de tcnicas de descubrimiento y anlisis
de requerimientos, cuyo comienzo puede ser a partir de una entrevista,
pero se conjuga con un trabajo en equipo entre los desarrolladores y
representantes de clientes. En ese trabajo se define en conjunto cules
deben ser los requerimientos, se clasifican, se priorizan y se documentan
de manera de especificar en forma ms clara la informacin para el
desarrollo.
62
63
QU ES EL DISEO?
El diseo del software, al igual que los enfoques de diseo de ingeniera en
otras disciplinas, va cambiando continuamente a medida que se desarrollan
mtodos nuevos, anlisis mejores y se ampla el conocimiento.
Las metodologas de diseo del software carecen de la profundidad, flexibilidad
y naturaleza cuantitativa que se asocian normalmente a las disciplinas de
diseo de ingeniera ms clsicas. Sin embargo, s existen mtodos para el
diseo del software; tambin se dispone de calidad de diseo y se pueden
aplicar notaciones de diseo.
El objetivo del diseo es producir un modelo o representacin de una entidad
que ser construida a posteriori.
Para ello, veamos algunos conceptos que ayudarn al ingeniero del software a
responder las siguientes preguntas:
ABSTRACCIN
La nocin psicolgica de abstraccin permite concentrarse en un problema a
algn nivel de generalizacin sin tener en consideracin los datos irrelevantes
de bajo nivel; la utilizacin de la abstraccin tambin permite trabajar con
conceptos y trminos que son familiares en el entorno del problema sin tener
que transformarlos en una estructura no familiar.
Cada paso del proceso del software es un refinamiento en el nivel de
abstraccin de la solucin del software. En el nivel ms alto de abstraccin, la
solucin se pone como una medida extensa empleando el lenguaje del entorno
del problema. En niveles inferiores de abstraccin, se toma una orientacin
ms procedimental.
A medida que nos adentramos en el proceso de diseo, se reduce el nivel de
abstraccin para crear abstracciones procedimentales y de datos.
de
REFINAMIENTO
El refinamiento paso a paso es una estrategia de diseo descendente
propuesta originalmente por Niklaus Wirth.
En cada paso (del refinamiento), se descompone una o varias instrucciones del
programa dado en instrucciones ms detalladas. Esta descomposicin sucesiva
o refinamiento de especificaciones termina cuando todas las instrucciones se
expresan en funcin de cualquier computadora subyacente o de cualquier
lenguaje de programacin. De la misma manera que se refinan las tareas, los
datos tambin se tienen que refinar, descomponer o estructurar, y es natural
refinar el programa y las especificaciones de los datos en paralelo.
Todos los pasos del refinamiento implican decisiones de diseo. Es importante
que el programador conozca los criterios subyacentes (para decisiones de
diseo) y la existencia de soluciones alternativas.
Finalmente, el refinamiento es un proceso de elaboracin, en donde se
comienza con un alto nivel de abstraccin (conceptualmente descrita) para
luego dar la capacidad al diseador de ir detallando ms y ms cada funcin.
MODULARIDAD
La arquitectura de computadora expresa la modularidad; es decir, el software
se divide en componentes nombrados y abordados por separado, llamados
frecuentemente mdulos, que se integran para satisfacer los requisitos del
problema.
Esta disciplina de modularizar frente a un problema particular viene del
concepto de divide y vencers, que es un argumento basado en
observaciones humanas sobre la resolucin de problemas (dividiendo el
problema se puede llegar a otros problemas ms pequeos o conocidos).
Es posible concluir que si subdividimos el software indefinidamente, el esfuerzo
que se requiere para desarrollarlo sera mnimo. Desgraciadamente,
intervienen otras fuerzas, que hacen que esta conclusin sea (tristemente)
falsa: a medida que aumenta el nmero de mdulos, tambin crece el esfuerzo
(coste) asociado con la integracin de ellos.
Para encontrar un punto exacto hasta cundo modular, se definen algunos
criterios. Uno de ellos, propuesto por Meyer, define cinco criterios que nos
65
ARQUITECTURA DE SOFTWARE
La arquitectura del software alude a la estructura global del software y a las
formas en que la estructura proporciona la integridad conceptual de un
sistema. En su forma ms simple, la arquitectura es la estructura jerrquica de
los componentes del programa (mdulos), la manera en que los componentes
interactan y la estructura de datos que van a utilizar los componentes. Sin
embargo, en un sentido ms amplio, los componentes se pueden generalizar
para representar los elementos principales del sistema y sus interacciones.
Un objetivo del diseo del software es derivar una representacin
arquitectnica de un sistema. Esta representacin sirve como marco de trabajo
desde donde se llevan a cabo actividades de diseo ms detalladas. Un
conjunto de patrones arquitectnicos permiten que el ingeniero del software
reutilice los conceptos a nivel de diseo.
Shaw y Garlan describen un conjunto de propiedades
especificarse como parte de un diseo arquitectnico:
que
debern
66
OCULTACIN DE INFORMACIN
El principio de ocultacin de informacin sugiere que los mdulos se
caracterizan por las decisiones de diseo que (cada uno) oculta al otro.
En otras palabras, los mdulos debern especificarse y disearse de manera
que la informacin (procedimiento y datos) que est dentro de un mdulo sea
inaccesible a otros mdulos que no necesiten esa informacin.
Ocultacin significa que se puede conseguir una modularidad efectiva
definiendo un conjunto de mdulos independientes que se comunican entre s
intercambiando slo la informacin necesaria para lograr la funcin del
software. La abstraccin ayuda a definir las entidades (o informacin).
COHESIN
La cohesin es una extensin natural del concepto de ocultacin de
informacin. Un mdulo cohesivo lleva a cabo una sola tarea dentro de un
67
ACOPLAMIENTO
El acoplamiento es una medida de interconexin entre mdulos dentro de una
estructura de software. El acoplamiento depende de la complejidad de
interconexin entre los mdulos, el punto donde se realiza una entrada o
referencia a un mdulo, y los datos que pasan a travs de la interfaz.
En el diseo del software, intentamos conseguir el acoplamiento ms bajo
posible. Una conectividad sencilla entre los mdulos da como resultado un
software ms fcil de entender y menos propenso a tener un efecto ola
(propagacin de errores).
Pressman define algunos niveles de acoplamiento:
68
Los principios bsicos de diseo hacen posible que el ingeniero del software
navegue por el proceso de diseo. Davis sugiere un conjunto de principios para
el diseo del software, los cuales han sido adaptados y ampliados en la lista
siguiente:
69
El diseo deber ser una gua legible y comprensible para aquellos que
generan cdigo y para aquellos que comprueban y consecuentemente,
dan soporte al software.
de
datos,
FACTORES DE CALIDAD
Para un buen diseo (o diseo de calidad), se definen 2 tipos de factores:
Los factores de calidad externos son esas propiedades del software que
pueden ser observadas fcilmente por los usuarios (por ejemplo,
velocidad, fiabilidad, grado de correccin, usabilidad).
MODELOS DE DISEO
El diseo del software se encuentra en el ncleo tcnico de la ingeniera del
software y se aplica independientemente del modelo de diseo de software que
71
se utilice. Una vez que se analizan y especifican los requisitos del software, el
diseo del software es la primera de las tres actividades tcnicas -diseo,
generacin de cdigo y pruebas- que se requieren para construir y verificar el
software. Cada actividad transforma la informacin de manera que d lugar por
ltimo a un software de computadora validado.
La informacin recopilada en el modelo de anlisis sirve, en general, para crear
4 modelos de diseo de software:
A continuacin veremos algunos aspectos bsicos con los cuales debe trabajar
el arquitecto antes de llegar a obtener un diseo completo.
DECISIONES DE DISEO
Al momento de elegir la arquitectura del sistema, se deben considerar
aspectos relevantes. Por ejemplo, Bass seala que las ventajas de disear una
arquitectura de software son:
Por otro lado, otros aspectos que afectan la arquitectura definida, segn Bosch,
y que tambin los menciona Bass en sus ventajas, tienen que ven con el
rendimiento, solidez, grado de distribucin y mantenibilidad del sistema
(requerimientos no funcionales), los cuales se definen de la siguiente forma
cuando son crticos:
73
Es posible que estos factores sean opuestos entre s. Por ejemplo, los
subsistemas de grano grueso mejoran el rendimiento, pero no son facilitadores
de la mantenibilidad.
Por lo general, descomponer el sistema no es una tarea fcil, ya que los
requerimientos de sistema con un factor fundamental, y stos deberan
corresponderse con los subsistemas. Sin embargo existen arquitecturas que
son estndares con las cuales se puede empezar, de manera de que,
dependiendo de los requerimientos, stas se puedan ajustar al problema
presentado.
En resumen, el arquitecto debe tener como base algunas preguntas claves al
disear la arquitectura:
1) Existe una arquitectura de aplicacin genrica que pueda actuar como
una plantilla para el sistema que se est diseando?
2) Cmo se distribuir el sistema entre varios procesadores?
3) Qu estilo o estilos arquitectnicos son apropiados para el sistema?
4) Cul ser la aproximacin fundamental utilizada para estructurar el
sistema?
5) Cmo se descompondran en mdulos las unidades estructurales del
sistema?
6) Qu estrategia se usar para controlar el funcionamiento de las
unidades del sistema?
7) Cmo se evaluar el diseo arquitectnico?
8) Cmo debera documentarse la arquitectura del sistema?
Como vern, estas cuestiones son simples guas que llevan a un buen
resultado: un modelo arquitectnico de calidad y adecuado al problema
presentado. De esta manera, y volviendo a lo anteriormente expuesto, se
puede elaborar la arquitectura con 2 visiones.
La primera es desde arquitecturas genricas. El arquitecto ya conoce el modelo
que desea aplicar y valida de manera tal que los requerimientos del problema
sean validables en dicha arquitectura. Por supuesto que es posible adaptar
dicha arquitectura cuando no son exactas, pero la base siempre es un modelo
genrico.
La segunda es que el arquitecto vaya construyendo su propia arquitectura. An
cuando existan algunos patrones arquitectnicos, siempre el profesional puede
encontrar algunos factores que le sirvan de ellos, pero para su propio modelo.
De esta forma, esta arquitectura es una a medida del problema presentado.
74
control
de
acceso
EL MODELO CLIENTE-SERVIDOR
En este caso, los clientes pueden conocer tanto la identidad de los servidores
como los servicios ofrecidos por ellos, sin embargo, los servidores no requieren
conocer a los clientes.
Dentro de las ventajas de este modelo se destaca la distribucin de los
servicios, lo que permite una fcil incorporacin de nuevos servicios utilizando
la misma arquitectura.
EL MODELO DE CAPAS
Este modelo organiza el sistema en una serie de capaz que ofrecen un conjunto
de servicios, en su propio lenguaje lgico. Cada una de las capas posee un
objetivo funcional claro para el sistema, de manera que los servicios ofrecidos
se encuentran de acuerdo a la naturaleza de s misma.
77
La cantidad de capaz que se puedan definir depende del estilo que se adapte.
Por ejemplo, el modelo MVC (Model View Controller) est definido solo en 3
capaz, las cuales se organizan de la siguiente forma:
78
Los cambios de interfaz pueden afectar a todos los usuarios del objeto
cambiado.
79
Es intuitiva, ya
transformaciones.
que
muchas
personas
piensan
en
forma
de
Debe existir un formato comn para transferir los datos, de modo que
sean reconocibles por las transformaciones.
MODELOS DE CONTROL
Dependiendo del modelo de organizacin seleccionado y la modularizacin
realizada para el sistema integral, es importante tener en cuenta que para que
los subsistemas funcionen como sistemas independientes requieren que
alguien los orqueste, de manera que sus servicios se entreguen en el
momento y el lugar correcto.
De esta manera, el arquitecto debe disear la arquitectura del sistema
complementndola con un modelo de control para sus subsistemas.
Se proponen 2 estilos de control genricos:
MODELO DE CONTROL CENTRALIZADO
Modelo del Gestor: Una componente del sistema se disea para definir el
inicio, parada y coordinacin del resto de los procesos del sistema.
81
82
83
85
86
deben
ser
adecuados
a la cultura
local
87
89
90
Si vemos estos principios notaremos que solo estn planteando una forma de
organizar las componentes (desde el punto de vista del empaquetamiento y su
uso dentro de ellas). Sin embargo, existen tambin algunas reglas sencillas 7
que se pueden aplicar (como una receta) para realizar el diseo basado en
clases:
1. Identifique todas las clases de diseo que correspondan al dominio del
problema.
2. Identifique todas las clases de diseo que correspondan al dominio de la
infraestructura (GUI, sistemas operativos, administracin de datos etc.).
3. Elabore todas las clases que no provienen de clases reusadas
a. Especifique detalles de los mensajes entre clases que colaboran
b. Identifique las interfaces de cada componente
c. Elabore atributos y defina tipos de datos y estructuras de datos
requeridas para implementarlas
d. Describa el flujo de procesamiento de cada componente en detalle
7 P. Gomez-Gil, INAOE. 2008
91
(deployment)
para
dar
detalles
92
REFLEXIONES
93
94
95
Rendimiento
Proteccin
Seguridad
Disponibilidad
Mantenibilidad
Cules son los diferentes niveles de anlisis en los que se tiene que
basar el diseo de datos?
Se basa en 3 niveles de anlisis al realizar el diseo:
al
Cules son las caractersticas que debe tener un almacn de datos para
ser considerado como tal?
Las caractersticas son 4:
98
Cules son los tipos de interaccin que el sistema debe proveer para el
usuario?
Los tipos de interaccin son:
o
99
100
Notacin
tabular,
que
permite
evaluar
condiciones
y
seleccionadas operaciones que cumplen con dichas condiciones
desde un punto de vista de las acciones que se deben cumplir
para ellas.
101
102
QU ES LA CODIFICACIN?
La construccin del software es la fase en donde se concretan los diseos
realizados y se codifica gran parte del sistema final que se est definiendo. Es
por eso que es importante realizarlo y documentarlo de manera de realizarlo
dentro de un proceso de calidad, obteniendo programas de calidad.
CODIFICACIN O PROGRAMACIN
La programacin es un proceso por el cual se escribe (en un lenguaje de
programacin), se prueba, se depura y se mantiene el cdigo fuente de un
programa informtico. Dentro de la informtica, los programas son los
elementos que forman el software, que es el conjunto de las instrucciones que
ejecuta el hardware de una computadora para realizar una tarea determinada.
Por lo tanto, la programacin es una de las principales reas dentro de la
informtica.
LENGUAJES DE PROGRAMACIN
Para que la computadora entienda nuestras instrucciones debemos usar un
lenguaje especfico de ellas conocido como lenguaje mquina. Este lenguaje es
muy fcil de entender para una mquina, pero excesivamente complicado para
una persona. De hecho solamente consiste en cadenas interminables de
nmeros 1 y 0.
Para hacer el trabajo un poco ms fcil los primeros operadores de
computadoras decidieron reemplazar los 1 y 0 por palabras o letras
provenientes del ingls; ste se conoce como lenguaje ensamblador. Por
ejemplo, para sumar se usa la letra A de la palabra inglesa add (sumar). En
realidad escribir en lenguaje ensamblador es basicamente igual que hacerlo en
lenguaje mquina, pero las letras y palabras son ms fciles de recordar y
entender que los nmeros.
Pero a medida que la complejidad de las tareas que realizaban las
computadoras aumentaba, se hizo necesario disponer de un mtodo ms
adecuado para programarlas. Entonces, se crearon los lenguajes de alto nivel.
Mientrs que una tarea tan sencilla como sumar dos nmeros puede necesitar
varias instrucciones en lenguaje ensamblador, en un lenguaje de alto nivel
bastar con solo una.
Una vez que se termin de escribir un programa en ensamblador o en un
lenguaje de alto nivel es necesario compilarlo, es decir, transformarlo en
lenguaje mquina.
ALGORITMOS
103
ESTILOS DE PROGRAMACIN
La programacin se define a travs de un conjunto de paradigmas diferentes
de programacin. Si lo vemos desde un punto de vista etimolgico, un
paradigma de programacin representa un enfoque particular o filosofa para la
construccin del software. No es mejor uno que otro sino que cada uno tiene
ventajas y desventajas. Tambin hay situaciones donde un paradigma resulta
ms apropiado que otro:
FACTORES DE CALIDAD
La programacin debe perseguir la obtencin de programas de calidad. Para
ello se establece una serie de factores que determinan la calidad de un
programa. Algunos de los factores de calidad ms importantes son los
siguientes:
105
ESTNDARES DE CODIFICACIN
Los estndares de codificacin se refieren a un conjunto de reglas y
lineamientos que se usan al escribir los cdigos fuentes de un software. El uso
de un estndar particular ayuda a los programadores a leer y entender el
cdigo evitando los errores de la mejor manera.
Por ejemplo, el siguiente es un cdigo que realiza una cierta interaccin entre
un usuario y el computador (muy bsico para ser exacto):
public class labasss { static public void main (String[] xxx) throws Exception {
System.out.print("Ingrese un nmero entre 1 y 10 > ");
int ang = (int) Integer.parseInt(new java.io.BufferedReader(new
java.io.InputStreamReader(System.in)).readLine());
System.out.println("Te gano con el " + (++ang)); } }
Este programa se llama Jalisco y hace evidente su origen del dicho mexicano
Jalisco nunca pierde y cuando pierde arrebata, pero en ese caso solo ocurre
lo primero. El juego consiste en solicitar al usuario un nmero, y el programa
siempre va a sumarle uno al resultado para ganar.
Es fcil ver que el concepto es muy sencillo, pero el programa no lo es, ya que
la forma en la que escrita no parece ser legible por un programador ajeno al
que realiz este cdigo. Cules han sido los factores que lo hicieron complejo?
Fcilmente detectamos algunos:
Apariencia del Cdigo: Los estndares apuntan a que el cdigo debe ser
de fcil entendimiento humano. De esta forma se pueden utilizar
algunas tcnicas bsicas como indentacin, alineamiento vertical,
espaciado y tabuladores.
Lista
de
Informes:
Indicar
el
nombre
librera/DBD/Descripcin de los archivos.
Datos de Prueba: Se incluir una copia de los datos usados para prueba.
Datos de Control: Se incluir una copia de los datos usados para prueba.
copia
de
la
110
Pero esto no es solo una casualidad, ya que en particular Java tiene una
herramienta llamada JavaDoc con la cual se obtiene tambin la
especificacin funcional de los programas, pero esto es solo una caracterstica
del lenguaje. No todos los lenguajes pueden jactarse de generar ambas
documentaciones en forma directa.
111
REFLEXIONES
112
113
114
UNIDAD V: LA CALIDAD EN
INGENIERA DE SOFTWARE
El objetivo de esta unidad es estudiar los principios de la calidad
de software, los planes de aseguramiento de calidad, las tcnicas
de deteccin y estimacin de factores de la calidad y la misin que
tiene dentro del proceso de ingeniera de software.
115
reducen de una entrego a otra. Tambin nos gustara reducir las diferencias en
velocidad y precisin de nuestras respuestas de soporte a los problemas de los
clientes.
La lista se podra ampliar ms y ms.
Para responder a estas cuestiones, debemos primero entender algunos
conceptos respectos a la calidad de software:
CALIDAD
El American Heritage Dictionary, define la calidad como una caracterstica o
atributo de algo. Como un atributo de un elemento, la calidad se refiere a las
caractersticas mensurables. Sin embargo, el software en su gran extensin,
como entidad intelectual, es ms difcil de caracterizar que los objetos fsicos.
No obstante, s existen las medidas de caractersticas de un programa. Entre
estas propiedades se incluyen complejidad ciclomtica, cohesin, nmero de
puntos de funcin, lneas de cdigo y muchas otras. Cuando se examina un
elemento segn sus caractersticas mensurables, se pueden encontrar dos
tipos de calidad:
las
CONTROL DE CALIDAD
El control de calidad es una serie de inspecciones, revisiones y pruebas
utilizadas a lo largo del proceso del software para asegurar que cada producto
cumple con los requisitos que le han sido asignados. El control de calidad
incluye un bucle de realimentacin (feedback) del proceso que cre el
producto. La combinacin de medicin y realimentacin permite afinar el
proceso cuando los productos de trabajo creados fallan al cumplir sus
especificaciones. Este enfoque ve el control de calidad como parte del proceso
de fabricacin.
Las actividades de control de calidad pueden ser manuales, completamente
automticas o una combinacin de herramientas automticas e interaccin
humana. Un concepto clave del control de calidad es que se hayan definido
todos los productos y las especificaciones mensurables en las que se puedan
comparar los resultados de cada proceso. El bucle de retroalimentacin es
esencial para reducir los defectos producidos.
GARANTA DE CALIDAD
117
COSTOS DE CALIDAD
Comprende los costos acarreados en la bsqueda de la calidad o en las
actividades relacionadas en la obtencin de la calidad. Se realizan estudios
sobre el costo de calidad para proporcionar una lnea base del costo actual de
calidad, para identificar oportunidades de reducir este costo, y para
proporcionar una base normalizada de comparacin.
Los costos de calidad se pueden dividir en costos asociados con la prevencin,
la evaluacin y los fallos:
Planificacin de la calidad,
Equipo de pruebas,
Formacin.
Entre los costos de evaluacin se incluyen actividades para tener una visin
ms profunda de la condicin del producto la primera vez a travs de cada
proceso.
Los costos de fallos son los costos que desapareceran si no surgieran defectos
antes del envo de un producto a los clientes. Estos costos se pueden subdividir
en costos de fallos internos y costos de fallos externos. Los internos se
producen cuando se detecta un error en el producto antes de su envo. Entre
estos se incluyen: re-trabajo (revisin), reparacin, anlisis de las modalidades
de fallos. Los costos de fallos externos son los que se asocian a los defectos
encontrados una vez enviado el producto al cliente. Algunos de estos costos de
fallos externos son: resolucin de quejas, devolucin y sustitucin de
productos, soporte de lnea de ayuda, trabajo de garanta.
FIABILIDAD
118
DISPONIBILIDAD
Adems de una medida de la fiabilidad debemos obtener una medida de la
disponibilidad. La disponibilidad del software es la probabilidad de que un
programa funcione de acuerdo con los requisitos en un momento dado, y se
define como:
SEGURIDAD
La seguridad del software es una actividad de garanta de calidad del software
que se centra en la identificacin y evaluacin de los riesgos potenciales que
pueden producir un impacto negativo en el software y hacer que falle el
sistema completo. Si se pueden identificar pronto los riesgos en el proceso de
ingeniera del software podrn especificarse las caractersticas del diseo del
software que permitan eliminar o controlar los riesgos potenciales.
119
120
LA DETECCIN DE ERRORES
Durante las fases anteriores de definicin y de desarrollo, el ingeniero intenta
construir el software partiendo de un concepto abstracto y llegando a una
implementacin tangible. A continuacin, llegan las pruebas. El ingeniero crea
una serie de casos de prueba que intentan demoler el software construido.
De hecho, las pruebas son uno de los pasos de la ingeniera del software que
se puede ver (por lo menos, psicolgicamente) como destructivo en lugar de
constructivo.
En un excelente libro sobre las pruebas del software, Glen Myers establece
varias normas que pueden servir acertadamente como objetivos de las
pruebas:
Es fcil ver que los casos de pruebas para esta sencilla caracterstica de varios
tipos de sistema se transforma en un conjunto de pruebas que debemos
realizar no menor. En este caso podemos contar no menos de 10 casos
sencillos de pruebas, sin preocuparnos de la cantidad de datos que tenemos
que ir variando, lo que significa que durante las pruebas se debe realizar un
trabajo que parece exhaustivo.
Davis sugiere un conjunto de principios de prueba que se han adaptado para
usarlos:
A todas las pruebas se les debera poder hacer un seguimiento hasta los
requisitos del cliente.
Para ser ms eficaces, las pruebas deberan ser realizadas por un equipo
independiente.
124
Este tipo de pruebas no tienen una forma especfica de ser aplicadas, ya que
pueden ser usadas para realizar pruebas tcnicas unitarias, de integracin e
incluso para las pruebas funcionales. Sin embargo su uso es altamente
recomendado como base para descubrir errores, ya que la especificacin de
diseo considera el uso de artefactos que definen a travs de un enfoque de
caja negra, por lo que buscar los casos de pruebas tcnicas se transforma en
un trabajo de revisin de los modelos de diseo.
PRUEBA DEL CAMINO BSICO
La prueba del camino bsico es un tipo de prueba de caja blanca propuesta
inicialmente por Tom McCabe.
El mtodo del camino bsico permite al diseador de casos de prueba obtener
una medida de la complejidad lgica de un diseo procedimental y usar esa
medida como gua para la definicin de un conjunto bsico de caminos de
ejecucin.
Los casos de prueba obtenidos del conjunto bsico garantizan que durante la
prueba se ejecuta por lo menos una vez cada sentencia del programa.
PRUEBA
DE
APLICACIONES
ENTORNOS
ESPECIALIZADOS,
ARQUITECTURAS
Los mtodos de prueba de caja blanca y de caja negra tratados son aplicables
a todos los entornos, arquitecturas y aplicaciones. Sin embargo a veces se
necesitan algunas directrices y enfoques nicos para las pruebas. A
continuacin se mencionan directrices de prueba para entornos, arquitecturas
y aplicaciones especializadas que pueden encontrarse los ingenieros del
software.
125
Prueba de sistema de tiempo real: no slo tiene que considerar los casos
de prueba de caja blanca y de caja negra, sino tambin el tratamiento
de sucesos (por ejemplo, procesamiento de interrupciones), la
temporizacin de los datos y el paralelismo de las tareas (procesos) que
manejan los datos.
ESTRATEGIAS DE PRUEBA
Las pruebas son un conjunto de actividades que se pueden planificar por
adelantado y llevar a cabo sistemticamente. Por esta razn, se debe definir en
el proceso de la ingeniera del software una plantilla para las pruebas del
software: un conjunto de pasos en los que podamos situar los mtodos
especficos de diseo de casos de prueba.
Todas las estrategias de pruebas proporcionan al ingeniero del software una
plantilla para la prueba y todas tienen las siguientes caractersticas generales:
PRUEBA DE SISTEMA
El software es incorporado a otros elementos del sistema (por ejemplo, nuevo
hardware, informacin) y realizan una serie de pruebas de integracin del
sistema y de validacin. Estas pruebas caen fuera del mbito del proceso de
ingeniera del software y no las realiza nicamente el desarrollador del
software. Sin embargo, los pasos dados durante el diseo del software y
durante la prueba pueden mejorar enormemente la probabilidad de xito en la
integracin del software en el sistema.
En este caso existen pruebas puntuales que deben realizarse:
128
LA GARANTA DE CALIDAD
La calidad del software ha mejorado significativamente en los quince ltimos
aos. Una de las razones ha sido que las compaas han adoptado nuevas
tcnicas y tecnologas como el uso del desarrollo orientado a objetos y el
soporte asociado de herramientas CASE. No obstante, tambin ha habido una
mayor consciencia de la importancia de la gestin de la calidad y de la
adopcin de tcnicas de gestin de la calidad para desarrollo en la industria del
software.
Sin embargo, la calidad del software es un concepto complejo que no es
directamente comparable con la calidad de la manufactura de productos. En la
manufacturacin, la nocin de calidad viene dada por la similitud entre el
producto desarrollado y su especificacin. En un mundo ideal, esta definicin
debera aplicarse a todos los productos, pero, para sistemas de software,
existen estos problemas:
129
ESTNDARES DE CALIDAD
Antes de definir los estndares de la calidad, es primordial saber a qu le
llamaremos estndar. Recordando la definicin tradicional que vimos en la
introduccin al curso, decimo que:
UN ESTNDAR ES UNA ESPECIFICACIN QUE REGULA LA
REALIZACIN DE CIERTOS PROCESOS O LA FABRICACIN
DE
COMPONENTES
PARA
GARANTIZAR
SU
INTEROPERABILIDAD.
130
132
EL CONTROL DE LA CALIDAD
Es fcil ver que la garanta de calidad trata de anteceder el proceso de
desarrollo para prepararlo para obtener un producto de calidad. Pero la
pregunta ahora es cmo aseguramos entonces que el producto que estamos
obteniendo no est divergiendo de la meta planteada por la garanta de
calidad?
La respuesta tiene que ver con el control de la calidad. Este concepto viene a
complementar lo planificado y se preocupa de velar por el cumplimiento de
todas las definiciones de calidad que se hayan adoptado desde un principio.
134
De esta manera, las revisiones no son ms que una forma de controlar para
que el trabajo que fue planificado con consideraciones de calidad, se mantenga
en ese camino durante el mayor tiempo posible (o a lo menos lo ms cerca que
sea posible).
En general podemos encontrar 2 tipos de revisiones:
135
La RTF es realmente una clase de revisin sistematizada que slo tendr xito
si es bien planificada, controlada y atendida. Es importante destacar que estas
revisiones no necesariamente son realizadas por el equipo de trabajo, sino que
tambin pueden ser realizadas por auditores externos que conozcan los
estndares de calidad definidos para l.
Se pueden realizar una RTF en una reunin o en alguna entrevista. Tambin se
puede apoyar con la revisin de los productos de la etapa que se est
inspeccionando.
A pesar de ello, es importante destacar que en las RTF se siguen algunos
principios bsicos, los que deben respetarse en su cabalidad:
136
Tomar notas escritas. A veces es buena idea que el registrador tome las
notas en una pizarra, de forma que las declaraciones o la asignacin de
prioridades pueda ser comprobada por el resto de los revisores, a
medida que se va registrando la informacin.
Disponer recursos y una agenda para las RTF. Para que las revisiones
sean efectivas, se deben planificar como una tarea del proceso de
ingeniera del software. Adems se debe trazar un plan de actuacin
para las modificaciones inevitables que aparecen como resultado de una
RTF.
LA REUNIN DE REVISIN
Independientemente del formato que se elija para la RTF, cualquier reunin de
revisin debe acogerse a las siguientes restricciones:
139
140
Estos factores pueden usarse para establecer mtricas de la calidad para todas
las actividades del proceso del software.
FACTORES DE CALIDAD ISO 9126
El estndar ISO 9126 ha sido desarrollado en un intento de identificar los
atributos clave de calidad para el software. El estndar identifica seis atributos
clave de calidad:
Al igual que los anteriores, los factores ISO 9126 no necesariamente son
utilizados para medidas directas. En cualquier caso, facilitan una valiosa base
para medidas indirectas y una excelente lista para determinar la calidad de un
sistema.
MTRICAS PARA LOS FACTORES DE CALIDAD
Como ya dijimos, la medicin asigna nmeros o smbolos a atributos de
entidades en el mundo real. Para conseguirlo se necesita un modelo de
medicin que comprenda un conjunto consistente de reglas. A continuacin
veremos algunas de esas reglas que se pueden aplicar a los diferentes modelos
de la ingeniera de software.
MTRICAS DEL MODELO DE ANLISIS
El trabajo tcnico en la ingeniera del software empieza con la creacin del
modelo de anlisis. En esta fase se obtienen los requisitos y se establece el
fundamento para el diseo. Por tanto, son deseables las mtricas tcnicas que
proporcionan una visin interna a la calidad del modelo de anlisis.
Estas son las mtricas que se pueden usar en este modelo:
Las mtricas de diseo para el software, como otras mtricas del software, no
son perfectas. Contina el debate sobre la eficacia y cmo deberan aplicarse.
MTRICAS DEL CDIGO FUENTE
La ciencia del software asigna leyes cuantitativas al desarrollo del software de
computadora, usando un conjunto de medidas primitivas que pueden
obtenerse una vez que se ha generado o estimado el cdigo despus de
completar el diseo.
Estas medidas son:
143
Con estas medidas y las teoras de Halstead se puede obtener la longitud del
cdigo.
Tericamente, debe existir un volumen mnimo para un algoritmo. De esta
forma define una relacin de volumen como la relacin de volumen de la forma
ms compacta de un programa con respecto al volumen real del programa.
MTRICAS PARA PRUEBAS
La mayora de las mtricas propuestas se concentran en el proceso de prueba,
no en las caractersticas tcnicas de las pruebas mismas.
En general, los responsables de las pruebas deben fiarse de las mtricas de
anlisis, diseo y cdigo para que les guen en el diseo y ejecucin de los
casos de prueba.
De esta manera:
145
146
REFLEXIONES
Qu es la fiabilidad?
Se refiere a la confianza que entrega el software en su uso y se calcula
como una el tiempo ocurrido entre la aparicin de un defecto y la
recuperacin de ste.
Qu es la disponibilidad?
Es una probabilidad de que el sistema falle de acuerdo a la fiabilidad y el
tiempo permitido para el mantenimiendo o recuperacin de errores
durante la operacin del sistema.
147
Cules son los principios que nos permiten definir casos de prueba
adecuados?
Los principios son:
Cules son los enfoques que podemos aplicar para el diseo de las
pruebas?
148
Cules son los principios necesarios para disear una prueba de caja
negra?
Se debe considerar:
Qu efectos produce.
149
Qu es la garanta de calidad?
Es una serie de actividades que permiten asegurar la calidad del
producto del proceso de desarrollo y mantencin del software.
Cules son los tipos de estndares de calidad que se pueden usar para
la garanta de calidad?
Son solo dos tipos:
o
Qu es el control de calidad?
El control de calidad es un conjunto de medidas que permiten al equipo
de trabajo vigilar la calidad definida a travs de los estndares para
prevenir desviaciones de un producto de calidad.
Cules son las caractersticas que deben seguir las RTF para ser
exitosas?
Los principios a seguir para la realizacin de los RTF son:
o
151
153
ANEXOS
154
EL MANIFIESTO GIL
Segn el Manifiesto se valora:
155
un plan. La
los largo del
equipo, etc.)
lo tanto, la
Los valores anteriores inspiran los doce principios del manifiesto que son
caractersticas que diferencian un proceso gil de uno tradicional. Los dos
primeros principios son generales y resumen gran parte del espritu gil. El
resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en
cuanto metas a seguir y organizacin del mismo. Los principios son:
I.
II.
III.
IV.
V.
VI.
VII.
VIII.
IX.
X.
La simplicidad es esencial.
156
XI.
XII.
XP (EXTREME PROGRAMMING)
XP es una metodologa gil centrada en potenciar las relaciones
interpersonales como clave para el xito en desarrollo de software,
promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentacin continua entre el cliente y el equipo de desarrollo,
comunicacin fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy
cambiantes, y donde existe un alto riesgo tcnico.
A continuacin presentaremos las caractersticas esenciales de XP:
157
El programador
implementacin.
estima
el
esfuerzo
necesario
para
su
158
159
ESTNDARES DE CODIFICACIN
Complementando lo visto en el captulo relativo a la codificacin, se presentan
algunos estndares utilizados por programadores de diferentes estilos de
lenguaje (Java, PHP y .NET).
11
Estndar
de
SUN
Microsystems:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
160
de
un
bloque
que
mejoren
el
161
Existen ms reglas en el estndar, pero estas son las bsicas con las que ya se
puede trabajar.
Para las estructuras de control (if, for, while, switch, etc), se debe dejar
un espacio entre la instruccin y el parntesis con la condicin.
En el nombrado de objetos:
o
Mantenga el tiempo de vida de las variables tan corto como sea posible,
esto es muy importante por ejemplo cuando se utiliza un recurso finito
como una conexin a una Base de Datos.
Mantenga el alcance de las variables tan corto como sea posible, esto
sirve para evitar confusiones, mejorar la mantenibilidad y adems
minimiza la dependencia, es decir si por algn motivo se comete el error
de borrar una variable es ms fcil de encontrar el error si esta tiene un
alcance ms pequeo.
Sea especifico cuando declare objetos que puedan generar colisin, por
ejemplo si tiene dos mtodos con el mismo nombre en diferentes
namespaces escrbalos con el nombre completo incluyendo el del
paquete.
En el nombrado de namespaces:
164
166
167
ESTNDARES DE PROCESO
A continuacin, las descripciones de los estndares de proceso citados en la
unidad V.
CMMI
Capability Maturity Model Integration
(CMMI) es un modelo para la mejora de
procesos
que
proporciona
a
las
organizaciones los elementos esenciales
para procesos eficaces.
Las mejores prcticas CMMI se publican
en los documentos llamados modelos.
En la actualidad hay dos reas de inters
cubiertas por los modelos de CMMI:
Desarrollo y Adquisicin.
CMMI es el sucesor de CMM. CMM Fue
desarrollado desde 1987 hasta 1997. En 2002, se lanzo CMMI Versin 1.1,
luego en Agosto de 2006 sigui la versin 1.2. El objetivo del proyecto CMMI es
ILUSTRACIN 27. ESTRUCTURA CMMI
mejorar la usabilidad de modelos de
madurez integrando varios modelos
diferentes en un solo marco (framework). Fue creado por miembros de la
industria, el gobierno y el SEI. Entre los principales patrocinadores se incluyen
la Oficina del Secretario de Defensa (OSD) y la National Defense Industrial
Association.
Hay tres constelaciones de la versin 1.2 disponible:
CMMI-DEV
168
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
Validacin (VAL)
22)
Verificacin (VER)
170
ISO 9000
La familia de normas ISO 9000 son normas de "calidad" y "gestin continua de
calidad", establecidas por la Organizacin Internacional para la Estandarizacin
171
Aumento de la productividad
La familia de normas apareci por primera vez en 1987 teniendo como base
una norma estndar britnica (BS), y se extendi principalmente a partir de su
versin de 1994, estando actualmente en su versin 2000.
MARCO CONCEPTUAL DE LAS NORMAS ISO 9000
El marco conceptual de cumplimiento debe verificarse para que la organizacin
obtenga la certificacin de su Sistema de gestin de la calidad.
Una empresa es el ente socioeconmico vinculado con la produccin de bienes
y servicios.
Una organizacin que cumple con la ISO 9001:2000 slo cumple con los
requisitos bsicos en cuanto a normas de "calidad". Si quiere ir ms all y
lograr la excelencia, debera cumplir requisitos adicionales. La ISO 9004:2000
establece estos requisitos adicionales.
Esta norma es entonces una gua para la ficticia mejora destinada a aquellas
organizaciones que quieren ir ms all de los requisitos bsicos de calidad de
la ISO 9001:2000. La ISO 9004:2000 no es una norma certificable, y su
cumplimiento no puede ser exigido por una entidad certificadora.
Tiene una principal diferencia en la gestin del sistema de calidad de la versin
2000 comparada con la versin anterior del ao 1994, esta diferencia es la
introduccin del concepto de gestin por procesos interrelacionados. En vez
de normar y asegurar la calidad bajo una conceptualizacin esttica, como
ocurra en la versin de 1994, en la nueva versin se propone complementarla
con una visin integral y dinmica de mejora continua, orientada a que el
cliente se pueda sentir obligadamente satisfecho.
NORMA ISO 9001
172
173
175
Est alineado con el estndar ISO/IEC 12207 que define los procesos del
ciclo de vida del desarrollo, mantenimiento y operacin de los sistemas
de software.
DIMENSIONES SPICE
Este modelo tiene una arquitectura basada en dos dimensiones: de proceso y
de capacidad de proceso.
Desde la dimensin de proceso agrupa a los procesos en tres grupos que
contienen cinco categoras de acuerdo al tipo de actividad:
Procesos primarios
o
ENG: Ingeniera
Procesos de soporte
o
SUP: Soporte
Procesos organizacionales
o
MAN: Gestin
ORG: Organizacin
Nivel 0: Incompleto
Nivel 1: Realizado
Nivel 2: Gestionado
Nivel 3: Establecido
Nivel 4: Predecible
Nivel 5: En optimizacin
176
177
BIBLIOGRAFA
El material principal utilizado para estos apuntes es:
Ingenieria de Software
Ian Sommerville
Editorial Prentice Hall
178
Tabla de Ilustracione
180