Intro Ingenieria Software

LINKS ADICIONALES

Escrito por scruz334 29-10-2007 en General. Comentarios (1)

LINKS

 

http://www.ati.es/novatica/2004/168/168-4.pdf

En este link encontraremos un lenguaje estándar para el modelado de software.

 

http://msdn2.microsoft.com/en-us/architecture/aa948857.aspx

Este link muestra una definición básica sobre SOA (Service Oriented Architecture), más algunos artículos publicados.

 

http://www-306.ibm.com/software/solutions/soa/

Aquí encontraremos una orientación de SOA pero tratado por IBM.

 

http://www.es-asp.net/tutoriales-asp-net/tutorial-215-217/utilizar-el-protocolo-soap-1-2.aspx

Aquí presento un link acerca de un tutorial de cómo utilizar el protocolo soap

http://scruz334.blogspot.es/admin/archivos/eek.gif 

Desarrollo de Software Basado en Componentes

Escrito por scruz334 28-10-2007 en General. Comentarios (5)

DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

 

Actualmente el desarrollo de software basado en componentes se ha transformado en el componente más seguro tanto para la construcción de grandiosos sistemas como para  aplicaciones de software.

 

Entonces analizaremos principalmente aquellas propiedades de calidad referentes a los componentes software y a las aplicaciones que con ellos se construyen.

 

El Desarrollo de Software Basado en Componentes (DSBC) trata de apoyar las bases para el diseño y desarrollo de aplicaciones distribuidas basadas en componentes software reutilizables. Esta norma cuenta en la actualidad con una utilidad, tanto desde el panorama académico como desde el industrial, en donde su demanda de temas es cada día mayor.

La finalidad primordial de (DSBC) es entender los diferentes modelos de desarrollo de software y la importancia de sus componentes y servicios. También evaluar las diferencias entre este modelo y los estudiados anteriormente en el transcurso de desarrollar este tipo de software.

Además deberíamos conocer los fundamentos sobre los que se sienta el modelo y todas las tendencias al momento de armar el software, es decir en su arquitectura.

 

¿Y por qué el empleo de este modelo de desarrollo en el mundo del software?

Se dice que la progresiva necesidad de efectuar sistemas complejos en poco de tiempo, y con menor esfuerzo tanto del desarrollador como de la parte económica, está beneficiando el avance de lo que se conoce como Desarrollo de Software Basado en Componentes (DSBC).

 

Este nuevo método se sustenta en componentes software ya desarrollado, que son combinados apropiadamente para satisfacer las exigencias del sistema.

 

Los primordiales esfuerzos de la gente desarrolladora de software en estos temas se han basado hasta ahora en los aspectos prácticos de los componentes, es decir, en la funcionalidad que brindan. Sin embargo, por lo general se han venido previniendo muchos de los aspectos de calidad que intervienen a la hora de seleccionar componentes y ensamblarlos para construir aplicaciones que satisfagan los requisitos del cliente.

 

Estos aspectos “extra-funcionales”, cada vez absorbe la curiosidad de los arquitectos e ingenieros del software. Por un lado, los requisitos extra-funcionales pueden afectar a varias partes del sistema, y por ello tendrán prioridad si entran en conflicto con los requisitos funcionales. Asimismo, el cuidadoso análisis de las propiedades de calidad puede mejorar el proceso de diferencia de los componentes candidatos que cumplan el núcleo de requisitos funcionales. Por ejemplo, si dos componentes efectúan la misma funcionalidad, sus atributos extra-funcionales pueden ser el criterio definitivo en el proceso de selección.

 

 

 

COTS

 

La segunda tarea para este modelo de desarrollo se centraliza en los procesos y herramientas para la evaluación y selección de componentes COTS. Aparte de tener en cuenta las obligaciones funcionales de la aplicación, es necesario meditar otros factores que también se mezclan a la hora de seleccionar componentes. El problema es que este tipo de requisitos, denominados “extra-funcionales” son difíciles de apreciar, aunque todos somos conscientes de la importancia que representan.

 

Estos  factores priman muchas veces incluso más que los funcionales, pues un diseñador hasta es capaz de adaptar la arquitectura de un sistema para poder incluir un componente que se desea que esté, o bien para evitar la presencia de un componente de un fabricante en el cual no se confía.

 

A pesar de estos problemas, los beneficios que proporciona el DSBC están ampliando su uso en ambientes industriales de desarrollo de software, sobre todo en cuanto a reducción de esfuerzos y costes de desarrollo y mantenimiento, y a la mejora de la calidad final de los productos y sistemas construidos. Esta extensión de su uso está favoreciendo la aparición de numerosas metodologías y herramientas de desarrollo para realizar un efectivo DSBC. Sin embargo, esta disciplina dista aún de ser una verdadera “ingeniería”, pues aún no se dispone ni de métricas adecuadas, ni de procesos precisos, ni de normativa internacional que la regule.

En este sentido, la definición de métricas de calidad para componentes y aplicaciones

Software, especialmente las desarrolladas en base a componentes COTS, aparece como una necesidad imperiosa.

EL MODELO EN ESPIRAL

Escrito por scruz334 23-10-2007 en General. Comentarios (12)

EL MODELO EN ESPIRAL

 

Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.

El modelo en espiral fue desarrollado por Boehm, quien lo describe así:

El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.

Se caracteriza principalmente por:

Ø      Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.

Ø      Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

El modelo espiral captura algunos principios básicos:

·         Decidir qué problema se quiere resolver antes de viajar a resolverlo.

·         Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.

·         Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.

·         No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y

·         Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles. 

Funcionamiento del modelo Espiral

 

http://scruz334.blogspot.es/img/espiral.jpg 

En cada vuelta tomamos en cuenta:

Ø      Los Objetivos: Que necesidad debe envolver el programa.

Ø      Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través de diferentes puntos como son:

  1. Características: experiencia del personal, exigencias a efectuar.
  2. Formas de gestión del programa.
  3. Riesgo tomado con cada alternativa.

Ø      Desarrollar y Verificar: Programar y probar el programa .

Ø      Se planificaran los siguientes pasos y se volverá a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones la radial y la angular:

  1. Angular=Avance del proyecto Software, dentro de un ciclo.
  2. Radial=Aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.

Este sistema es muy utilizado en proyectos largos como pueden ser la creación de un Sistema Operativo. Y que necesitan constantes cambios.

Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.

El modelo en espiral WINWIN

El modelo en espiral WINWIN de Boehm, define un conjunto de acciones de negociación al principio de casa paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:

  • Identificación del sistema o subsistemas clave de los directivos.
  • Determinación de las condiciones de victoria de los directivos.
  • Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.

 

LINKS

A Spiral Model of Software Development and Enhancement - Barry Boehm's original article

 

http://www.itba.edu.ar/capis/rtis/articulosdeloscuadernosetapaprevia/CORCOS-ESPIRAL.pdf - Similitudes y Diferencias entre el Modelo Espiral y el Prototipado

Modelo de construcción de prototipos

Escrito por scruz334 22-10-2007 en General. Comentarios (7)

MODELO DE PROTOTIPOS

Este modelo también denominado modelo de desarrollo evolutivo. Para comprender este modelo, comenzaremos con la definición de los objetivos globales para el software, después identificaremos los requerimientos que conocemos y los sitios del diseño en donde es necesaria más definición. Entonces planteamos con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido).

Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas del software.

El diseño rápido se basa en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

CONSTRUCCION DE PROTOTIPOS

A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. El responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humana – máquina, entonces en este caso cuando utilizamos la construcción de prototipos.

 

http://scruz334.blogspot.es/img/construcciondeprototipos.gif 

El paradigma de construcción de prototipos se inicia con la comunicación. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en la forma de un diseño rápido). El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el usuario final. El diseño rápido conduce a la construcción de un prototipo. Después, el prototipo lo evalúa el usuario y con la retroalimentación se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo se desarrollador entienda mejor lo que se debe hacer.

VENTAJAS:

Ø      No modifica el flujo del ciclo de vida.

Ø      Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.

Ø      Reduce costos y aumenta la probabilidad de éxito.

Ø      Exige disponer de las herramientas adecuadas.

Ø      No presenta calidad ni robustez.

Ø      Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería.

DESVENTAJAS

A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de prototipos se torna problemática por las siguientes razones:

Ø      El cliente ve funcionando lo que para el es la primera versión del prototipo que ha sido construido con “chicle y cable para embalaje”, y puede decepcionarse al indicarle que el sistema aun no ha sido construido.

Ø      El desarrollador puede caer en la tentación de aumentar el prototipo para construir el sistema final sin tener en cuenta los obligaciones de calidad y de mantenimiento que tiene con el cliente.

 

LINKS:

http://prototipos/Ingenieria%20de%20software%20-%20Monografias_com.htm

http://prototipos/Microsoft%20PowerPoint%20-%20Tema03.htm

 

MODELOS DE PROCESO PRESCRIPTIVO

Escrito por scruz334 16-10-2007 en General. Comentarios (10)

MODELOS DE PROCESO PRESCRIPTIVO

 

Introducción.- Se analizó un informe según Presuman que se basa en un triángulo multicapa, en el que se destaca: la calidad, los procesos, los métodos y técnicas, las herramientas.

El Proceso de Software se basa en las personas, en el producto, en el proyecto y finalmente en el proceso.

Debemos diferenciar entre el concepto de proyecto y proceso, el primero es una secuencia de acciones para llevar a cabo el desarrollo del software, mientras que el otro indica su proceso de desarrollo.

 

Proceso del Software.- Se observó una visión genérica acerca de dicho proceso, el cual consiste en:

DEFINICIÓN:          Ing. Sistema

                                  Planificación

                                  Análisis de Req.

 

 


DESARROLLO:      Diseño

                                  Generación de Código

                                  Pruebas

 

MANTENIMIENTO Y SOPORTES          

 

MODELO CASCADA

 

Llamado también Lineal secuencial. Proporciona una simple visión del desarrollo del Software. A los procesos los representa como fases separadas y secuenciales en tiempo.

Antes de codificar debemos diseñar el software, además probarlo antes de construirlo y ponerlo en operación.

 

FASES DEL MODELO CASCADA

 

 

Ingeniería y Análisis del Sistema

Análisis de los Requisitos

Diseño

Codificación

Prueba

Mantenimiento

 

·         Ingeniería y Análisis del Sistema:

Análisis y de diseño de todos los componentes del sistema computacional.

·         Análisis de Requisitos Software:

Se debe conocer que necesita el usuario para saber que necesidades debemos cubrir.

·         Diseño: En esta fase se realizan los algoritmos necesarios para que se cumplan los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación. Se dividen en:

  1. Diseño de Alto Nivel o Arquitectónico
  2. Diseño Detallado

·         Codificación: Es la fase de programación propiamente dicha.

    • Pruebas: Las componentes una vez programadas, se ensamblan para formar el sistema y se demuestra que trabaja correctamente antes de ser puesto en práctica por el usuario.

Existen varios tipos de Pruebas:

Ø      Pruebas de unidad

Ø      Pruebas de integración

Ø      Pruebas de sistema.

Ø      Pruebas de aceptación

  • Mantenimiento: El software necesitará cambios después de la entrega. Los tipos de mantenimiento son:

Ø      Mantenimiento Preventivo y Perfectivo

Ø      Mantenimiento Correctivo

Ø      Mantenimiento Evolutivo

 

VENTAJAS DEL MODELO CASCADA

1.      Modelo y planificación fácil y sencillos.

2.      Sus fases son conocidas por los desarrolladores.

3.      Los usuarios lo pueden comprender fácilmente.

DESVENTAJAS DEL MODELO CASCADA

1.      Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño.

2.      Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida.

 

Documentos del Modelo de Cascada

http://www.biblioteca.co.cr/pdf/unidad12-4.pdf

 

 

MODELO V

 

Se puede definir un software de mejor calidad ya que es un modelo mas evolucionado que Cascada.

Este Modelo más manejable, pero sigue teniendo con algunas carencias del Modelo Cascada.

Permite combinar los tipos de pruebas con actividades de verificación y validación sobre los documentos de requisitos y diseño que optimizan la capacidad de aceptar el producto resultante.

Ø      La verificación se fundamenta en demostrar si el producto se está construyendo correctamente.

Ø      La validación certifica que el producto cumple con las exigencias definidas por el cliente.