Métodos del proceso de software

Introducción

Con el pasar del tiempo los proyectos que buscan desarrollar software implementan diferentes procesos que les permiten tener un orden lógico en el proceso a seguir para la elaboración del producto de software, por lo que con el pasar del tiempo se requieren diferentes procesos para cada proyecto que surja, ya sea para software complejos o sencillos requieren un diferente ritmo de trabajo y organización de las actividades para el equipo de trabajo.

Desarrollo

Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto de software que pueda reunir los requisitos del cliente. Algo que debemos tener claro es que los procesos de software son complejos además de que dependen totalmente de las decisiones y el juicio del equipo de trabajo que busca satisfacer las necesidades del cliente. 

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos:

1. Especificación de software. Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.
2. Diseño e implantación. Se diseña y construye el software de acuerdo a la especificación.
3. Validación. El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.
4. Evolución. El software debe evolucionar, para adaptarse a las necesidades del cliente.

Modelo de proceso de software

Un modelo de proceso de software se define como una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.

Algunos de los modelos de proceso de software existentes son:

• Modelo en cascada
• Desarrollo evolutivo
• Basado en componentes

Modelo de cascada

Considera las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución. Los representa como fases separadas del proceso, tales como especificación de requerimientos, el diseño de software, la implantación, las pruebas, etc.

Las principales etapas de este modelo se transforman en actividades de desarrollo:

1. Análisis y definición de requerimientos. Os servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se definen en detalle y sirven como una especificación del sistema.
2. Diseño del sistema de software. El proceso de diseño de sistema divide los requerimientos en sistemas en hardware y software. Establece la arquitectura completa del sistema. El diseño del software identifica y describe las abstracciones fundamentales del sistema de software y sus relaciones.
3. Implantación y prueba de unidades. En esta etapa el diseño del software se lleva a cabo como un conjunto o unidades de programa. La prueba de unidades implica verificar que cada una cumpla su especificación.
4. Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como sistema completo para asegurar que se cumplan los requerimientos del software. Después de las pruebas, el sistema del software se entrega al cliente
5. Funcionamiento y mantenimiento. Por lo general, ésta es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento. El mantenimiento implica corregir errores no cubiertos en las etapas anteriores del ciclo de vida, mejorar la implantación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren nuevos requerimientos.

Desarrollo evolutivo

La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en versiones hasta que se desarrolle el sistema final adecuado. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Existen dos tipos de desarrollo evolutivo:

• Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.
• Prototipos desechables., donde su objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos del sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Basado en componentes

En la mayoría de proyectos de software se reutiliza software. Esto sucede cuando las personas que trabajan en el proyecto conocen diseños o códigos similares al requerido. En los últimos años ha surgido un enfoque de desarrollo de software denominado ingeniería de software basado en componentes que se basa en la reutilización. Algunas veces estos componentes son sistemas por si mismos que pueden proporcionar funcionalidad específica. Las etapas son las siguientes:

1. Especificación de requerimientos. Similar al modelo de cascada.
2. Análisis de componentes. A partir de la especificación de buscan los componentes para implementar esta especificación. Por lo general no existe una concordancia exacta y los componentes que se utilizan sólo proporcionan parte de la funcionalidad.
3. Modificación de requerimientos. Los requerimientos se analizan utilizando información acerca de los componentes que se han descubierto.. Entonces estos componentes se modifican para reflejar los componentes disponibles. Si las modificaciones no son posibles, la actividad de análisis de componentes se puede llevar a cabo nuevamente para buscar soluciones alternativas.
4. Diseño del sistema con reutilización. En esta fase se diseña o se reutiliza un marco de trabajo para el sistema. Los diseñadores tienen en cuenta los componentes que se reutilizan y organizan el marco de trabajo para que los satisfaga. Si los componentes reutilizables no están disponibles, se puede tener que diseñar nuevo software.
5. Desarrollo e integración. Para crear el sistema, el software que no se puede adquirir externamente se desarrolla, y los componentes y los sistemas adquiridos se integran.
6. Validación del sistema. Similar al modelo de cascada

Conclusion

Como hemos visto, los diferentes clientes que podemos encontrar tendrán diferentes necesidades que cubrir, por lo que el utilizar un único modelo de desarrollo de software para todos los proyectos resulta ser insuficiente para cubrir las necesidades del cliente, por lo que siempre debemos elegir el que se acople mejor a las necesidades tanto del cliente como del equipo de trabajo para la realización del software.

Bibliografía

• Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.
• http://ele-mariamoliner.dyndns.org/~fperal/proy/ingenieriaSW.pdf
• http://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdf

Pruebas de integración y de Sistema

Pruebas de Integración.

La prueba de integración es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté de acuerdo con el que dicta el diseño. La integración puede ser descendente si se integran los módulos desde el control o programa principal, o bien, ascendente, si la verificación del diseño empieza desde los módulos más bajos y de allí al principal. La selección de una estrategia de integración depende de las características depende de las características del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias.

Diseñadas para probar la interacción entre los distintos componentes de un sistema.

Tipos de errores:

·         Errores de programación entre componentes.

·         Errores de interoperabilidad.

Estrategias de pruebas:

·         Pruebas no incrementales (“Big Band Approach”):

Se integran todos los componentes y entices se prueba el Sistema como un todo. No es una técnica recomendada pues dificulta el aislamiento de errores.

·         Pruebas incrementales:

El programa es construido y probado en pequeños incrementos. Facilita el aislamiento de errores y las pruebas sistemáticas.

o    Integración descendente (Top-down).

§  En profundidad (Depth-first).

§  En anchura (Breadth-first).

o    Integración ascendente (Bottom-up).

Integración descendente.

·         Permite verificar los puntos de control o decisión al principio del proceso de prueba.

·         La integración en profundidad permite probar funcionalidades completas lo cual aumenta la confianza.

·         Puede requerir el uso de muchos stubs.

La integración se realiza partiendo del programa principal y moviéndolos hacia abajo por la jerarquía de control.

Integración descendente en profundidad.

La integración se realiza por ramas. Cada rama suele implementar una funcionalidad específica.

Integración descendente en anchura.

La integración se realiza por niveles moviéndose en horizontal por la estructura de control.

Integración ascendente.

·         Se elimina la necesidad de usar stubs.

·         Es necesario el uso de controladores de prueba (“drivers”) a fin de coordinar la entrada y salida de casos de prueba.

La integración se realiza partiendo de módulos atómicos situados en los nodos finales de la jerarquía de control. No suele necesitar el uso de stubs.

Pruebas de Sistema.

Diseñadas para probar el sistema en su totalidad como si de una caja negra se tratase.

Un clásico problema de la prueba del sistema es la delegación de culpabilidad. Esto ocurre cuando se descubre un error t cada uno de los creadores de cada elemento del sistema echa la culpa del problema a otros, para evitar esto se debe prever y tomar medidas correctivas tomando en cuenta lo siguiente:

• Diseñar caminos de manejo de errores que prueben toda la información procedente de otros elementos del sistema.
• Lleva a cabo una serie de pruebas que simulan la presencia de datos en mal estado o de otros posibles errores en la interfaz del software.
• Registrar los resultados de las pruebas como “evidencias” en el caso de señalamientos informales.
• Participar en la planificación y diseño de las pruebas del sistema para asegurarse de que el software es probado en forma adecuada.

La prueba del sistema se basa en otras técnicas de pruebas, aunque la finalidad de cada prueba es distinta, sirven para verificar que se hayan integrado correctamente cada uno de los elementos del sistema:

1. Prueba de Recuperación: es una prueba que se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperación se lleve a cabo, ya sea automáticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperación.
2. Prueba de Seguridad: intenta verificar la aplicación de los mecanismos de protección incorporados en el sistema. Durante la prueba el encargado desempeña el papel de intruso tratando de violar la seguridad del sistema, intentando obtener las claves de acceso por cualquier medio externo; debe bloquear el sistema negando así el servicio a otras personas además de producir errores a propósito en el sistema o debe curiosear los datos públicos intentando encontrar una clave de acceso al sistema.
3. Prueba de Resistencia: está diseñada para enfrentar a los problemas en situaciones anormales, es decir ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volúmenes anormales. El encargado de la prueba debe intentar tirar el sistema. Para lograr esto se puede tomar en consideración lo siguiente:

•  Diseñar pruebas especiales que generen 10 o más interrupciones por segundo.
• Incrementar la frecuencia de datos de entrada en un orden de magnitud con el fin de comprobar cómo responden las funciones de entrada.
• Ejecutar casos de prueba que requieran al máximo de memoria o de espacio en disco.
• Diseñar casos de prueba que produzcan excesivas búsquedas de datos almacenados en el disco.

https://www.lsi.us.es/docencia/get.php?id=6731

http://www.academica.mx/blogs/las-pruebas-integraci%C3%B3n-software

Diagrama de Nodos

Diagrama

Posibles Rutas

p1
p2-p7
p2-p7-p9
p3-p7
p3-p7-p9
p4-p5-p8-p9
p4-p5-p8...
p4-p6-p8-p9
p4-p6-p8...

Pruebas de Caja Negra & Blanca

Pruebas de Caja Negra: Realiza pruebas que comprueben que todas las funciones son operativas. (Externo). Demuestran que las funciones del software son operativas, que la entrada es aceptada y la salida es correcta, y la integridad de la información se mantiene. (Interfaz).

Intentan encontrar errores de Funciones incorrectas o ausentes, Errores en Interfaz, en Estructuras de Datos o Accesos a Bases de Datos, Rendimiento, Inicialización y Terminación.

Prueba de Partición Equivalente

Divide el dominio de entrada de un programa en clases de datos, y de estas se derivan los casos de prueba. Cada clase de equivalencia representa un conjunto de estados válidos o inválidos para las condiciones de entrada.

Prueba de Análisis de Valores Límites

Conduce a que para determinadas clases de equivalencia se genere más de un caso de prueba.

Pruebas de Caja Blanca: Realiza pruebas que comprueben que las operaciones internas son correctas y sean de acuerdo a las especificaciones. (Interno). En estas pruebas se comprueban que los detalles del programa sean correctos, es decir que los procedimientos sean los que corresponden.

·         Se ejecutan por lo menos una vez en cada camino de cada módulo.

·         Se utilizan todas las estructuras de datos internas.

Prueba del Camino Básico

Propuesto por McCabe, con este se obtiene una medida de la complejidad de un diseño procedimental, diseña casos de prueba que garanticen que todos los caminos se ejecuten por lo menos una vez.

Prueba de Bucles

Técnica de prueba de caja blanca que se enfoca en la validez de las construcciones de los bucles.

Hay cuatro tipos de bucles:

-Simples

-Concatenados

-Anidados

-No Estructurados

Referencias:

http://indalog.ual.es/mtorres/LP/Prueba.pdf

http://www.lsi.us.es/docencia/get.php?id=401

Tarea 2

CALIDAD

Se refiere a que un producto, servicio, etcétera, cumpla con las características que menciona y satisfaga y se sustenta en su habilidad las necesidades del cliente, existe calidad cuando las necesidades son cubiertas. También podemos mencionar que la calidad es un sinónimo de mejora continua.

ISO 9126

Establece un estándar internacional para la evaluación de la calidad de productos de software. Tiene seis características básicas:

·         Funcionalidad

·         Confiabilidad

·         Usabilidad

·         Eficiencia

·         Mantenibilidad

·         Portabilidad

BIBLIOGRAFÍA

http://www.gestiopolis.com/recursos/experto/catsexp/pagans/ger/No9/Que%20es%20calidad.htm

http://recursosbiblioteca.utp.edu.co/tesisd/textoyanexos/0053L864e_anexo.pdf

Tarea 1

INTRODUCCIÓN

Cuando se desarrolla un sistema es necesario realizar una serie de pruebas con el fin de que el sistema o software cumpla con el objetivo que tiene, además debe satisfacer las necesidades del cliente así como aspectos que requiere un sistema de calidad.

PRUEBA

Ensayos que se realizan para observar cual será el resultado de algo. También puede ser considerada como una evaluación, examen o experimento ya que evalúa diversos aspectos o características con el cual se puede saber si se cumplió el objetivo principal.

INGENIERÍA DE PRUEBAS

La ingeniería de Pruebas facilita la realización de éstas al seguir una serie de pasos para realizar las pruebas necesarias que el producto o software necesite, con la intención de que el producto cumpla con estándares y con el objetivo de éste.

CICLO DE VIDA DEL DESARROLLO DE SOFTWARE

Es el conjunto de fases por el que pasa un sistema, desde su inicio hasta que este se retira o se reemplaza. También se le conoce como paradigma. Se compone de fases sucesivas compuestas por tareas que se planifican. Las fases se pueden ejecutar más de una vez a lo largo de un proyecto.

Existen 6 modelos de ciclos de vida de desarrollo del software:

-Modelo en cascada

-Modelo en v

-Modelo iterativo

-Modelo de desarrollo incremental

-Modelo en espiral

-Modelo de prototipos

TIPOS DE PRUEBAS

·         Test de facilidad

·         Test de volumen

·         Test de Stress

·         Test de usabilidad

·         Test de seguridad

·         Test de performance

·         Test de configuración

·         Test de instabilidad

·         Test de fiabilidad

·         Test de recuperación

·         Test de documentación

·         Test de mantenibilidad

CONCLUSIÓN

Para realizar un software que pueda ser de calidad es indispensable realizar y seguir los procedimientos necesarios para poder demostrar que fue hecho para el mejor uso del usuario.

BIBLIOGRAFÍA

http://es.thefreedictionary.com/prueba

http://adimen.si.ehu.es/~rigau/teaching/EHU/ISHAS/Curs2008-2009/Apunts/IS.14.pdf

http://www.moravia.com/es/services/engineering-testing/

http://materias.fi.uba.ar/7548/PruebasSoftware.pdf

http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-ii/materiales/tema1-pruebasSistemasSoftware.pdf

Tarea 5 Modelo Relacional

El modelo relacional nos permite modelar las relaciones con ayuda del álgebra relacional, después de hacer los diagramas Entidad-Relación, los transformaremos al modelo relacional.

1.

Coches(Número de accidentes registrados)

2.

Cliente(DNI, Nombre, Apellidos, Dirección, Teléfono)

Coche(Matrícula, Modelo, Marca, Color)

Nuevo(Num. de unidades)

Usado(Km. recorridos)

Mecánico(DNI, Nombre, Apellidos, Fecha de contratación)

Compra(Matrícula, DNI)

Repara(DNI, Matrícula)

3.

Jugador(Estadísticas)

Partido(Núm. de partido, Resultado)

4.

Cliente(No. de Cliente, Direcciones de envio, Saldo, Descuento, Límite de crédito)

Pedido(No. de cliente. Direcciones de envio,No. de artículo)

Cabecera(Fecha del pedido)

Cuerpo(Cantidad)

Artículo(No. de Articulo,  Existencia, Fab. distribuidoras, Existencias en fab.)

Fábrica(No. de fábrica, Tel. de contacto,Artículos que provee)

Realiza(No. de cliente,No. de artículo)

Solicita(No. de cliente,No. de artículo)

Fabrica(No. de artículo, No. de Fábrica)

5.

Producto(ID, Nombre, Stock, Precio)

Categoría(ID,Nombre, Descripción)

Proveedor(RUT, Nombre, Dirección, Teléfono, Página web)

Cliente(RUT,Teléfono, Dirección, Nombre)

Venta(ID, Fecha, Cliente, Descuento, Monto final)

Organiza(ID,ID)

Provee(ID, RUT)

Compra(ID, RUT)

Tiene(ID, ID)