Desarrollo y comercialización de productos de software [El proceso unificado]

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Desarrollo y comercialización de productos de software [El proceso unificado]"

Transcripción

1 Desarrollo y comercialización de productos de software [El proceso unificado] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-P Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 1 / 72

2 Análisis del negocio para el desarrollo de software Análisis del negocio para el desarrollo de software I El análisis del negocio consiste en comprender cuáles son las necesidades del cliente/negocio, con la finalidad de articular claramente los objetivos del software a desarrollar. Un analista de negocio (business analyst) es el responsable de identificar las necesidades del negocio de sus clientes interesándose en ayudarlos determinar las soluciones a sus problemas. Es el puente entre el cliente y el depto. de desarrollo. Debe estar próximo al usuario final y entender sus necesidades, al mismo tiempo que debe conocer cómo están construidas las aplicaciones. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 2 / 72

3 Análisis del negocio para el desarrollo de software Análisis del negocio para el desarrollo de software II Responsabilidades de un analista de negocios Desarrollo y administración de los requerimientos del sistema. Análisis de requerimientos organizacionales y operacionales. Validación de requerimientos para la ingeniería de procesos. Análisis y recomendación de soluciones y de mejora continua. Validación y documentación de problemas. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 3 / 72

4 Análisis del negocio para el desarrollo de software Análisis del negocio para el desarrollo de software III El analista durante la fase de desarrollo Primero debe recoger las necesidades de los usuarios (los requerimientos o requisitos) y aglutinarlos en un documento que será entregado al departamento de desarrollo. Participará en el ciclo de vida del desarrollo, sobre todo en la construcción del diseño del sistema donde se especifican los elementos con los que debe cumplir el software. Se encargará de la validación. Durante la fase de construcción, resolverá las dudas de los técnicos para garantizar que las aplicaciones sean construidas de acuerdo a las necesidades del usuario. Participará en la fase de pruebas y aceptación del producto. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 4 / 72

5 Análisis del negocio para el desarrollo de software Cómo realizar el análisis del negocio? Cómo realizar el análisis del negocio? I Los analistas deben de ser capaces de utilizar técnicas para la captura de requisitos en diferentes situaciones. Realizando un correcto análisis de negocio se podrá guiar el desarrollo hacia el sistema correcto. Un flujo de trabajo sugerido para documentar todo el análisis del negocio es el siguiente: 1 Enumerar los requisitos candidatos. 2 Comprender el contexto del sistema. 3 Capturar requisitos funcionales. 4 Capturar requisitos no funcionales. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 5 / 72

6 Análisis del negocio para el desarrollo de software Cómo realizar el análisis del negocio? Cómo realizar el análisis del negocio? II Enumerar los requisitos candidatos Durante el desarrollo del sistema, los clientes, usuarios, analistas y desarrolladores proponen ideas que pudieran convertirse en verdaderos requisitos. Lo ideal es realizar una lista de características que permita llevar un control sobre el estados de las propuestas. Cada característica debe poseer los siguientes puntos: 1 Estado (propuesto, aprobado, validado). 2 Costo de implementación (recursos hardware, software y humanos). 3 Prioridad (crítico, importante, secundario). Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 6 / 72

7 Análisis del negocio para el desarrollo de software Cómo realizar el análisis del negocio? Cómo realizar el análisis del negocio? III Comprender el contexto del sistema Generalmente están involucrados los analistas y el arquitecto del software. Se puede realizar mediante modelos de dominio y de negocio. El modelo de dominio permite identificar algunas de las clases durante el desarrollo del sistema. El modelo de negocio describe los procesos y ayuda en la identificación de los casos de uso. El arquitecto y el jefe de proyecto deciden la forma de proceder (utilizan uno, ambos o ninguno). Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 7 / 72

8 Análisis del negocio para el desarrollo de software Cómo realizar el análisis del negocio? Cómo realizar el análisis del negocio? IV Capturar requisitos funcionales Es el diseño de los casos de uso. Se debe tener en claro el contexto del sistema. Se sugiere entrevistar a los usuarios. Se deben analizar y discutir propuestas para un mismo caso de uso. Para las interfaces de usuario lo mejor es construir visualizaciones o prototipos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 8 / 72

9 Análisis del negocio para el desarrollo de software Cómo realizar el análisis del negocio? Cómo realizar el análisis del negocio? V Capturar requisitos no funcionales Entender cuáles son las propiedades que debe tener el sistema. Entender las restricciones del entorno. Entender cuál debe ser el rendimiento del sistema en términos de velocidad, tiempo de respuesta, uso de memoria, entre otros. Algunos requerimientos no funcionales pueden ser genéricos y otros mas específicos, lo que los relaciona con muchos o un sólo caso específico. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 9 / 72

10 Análisis del negocio para el desarrollo de software Cómo realizar el análisis del negocio? Cómo realizar el análisis del negocio? VI Qué es un modelo de dominio? Un modelo de dominio captura los tipos más importantes de objetos/clases en el contexto del sistema. Los principales objetos del dominio a considerar son: Objetos del negocio. Representan las cosas que se manipulan en el negocio, como pedidos, cuentas, contratos, entre otros. Objetos del mundo real. Son los objetos físicos que se deben tomar en cuenta. Sucesos pasados o presentes. Como la partida y arribo de un avión, de un embarque de productos, etcétera. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 10 / 72

11 Análisis del negocio para el desarrollo de software Cómo realizar el análisis del negocio? Cómo realizar el análisis del negocio? VII Desarrollo de un modelo de dominio El modelo de dominio solo contribuye a la comprensión de del problema, el cómo se resolverá en el diseño e implementación del sistema. Lo ideal es utilizar UML u otros lenguaje de modelado para documentar los resultados. Los dominios pequeños pueden requerir menos de 10 clases, los de tamaño moderado entre 10 y 50, y los grandes más de 50. Es importante desarrollar un glosario de términos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 11 / 72

12 Análisis del negocio para el desarrollo de software Cómo realizar el análisis del negocio? Cómo realizar el análisis del negocio? VIII Qué es un modelo de negocio? Un modelo de negocio describe los procesos del negocio de una empresa en términos de casos de uso y actores del negocio. El objetivo es esquematizar como el sistema proporcionará un valor a sus usuarios. Un modelo de objetos del negocio describe cómo es llevado a cabo el proceso por parte de un conjunto de actores que utilizan un conjunto de entidades y unidades de trabajo. Una entidad del negocio es algo físico que es inspeccionado, manipulado, producido o utilizado en un caso de uso del negocio. Una unidad de trabajo del negocio representa una actividad que puede ser reconocida por un actor. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 12 / 72

13 Análisis del negocio para el desarrollo de software Cómo realizar el análisis del negocio? Cómo realizar el análisis del negocio? IX Desarrollo de un modelo de negocio Crear el modelo de casos de uso (diagrama de casos de uso) con los actores y casos involucrados. Desarrollar el modelo de objetos, entidades y unidades de trabajo del negocio. En realidad el modelo de dominio es una variante simplificada del modelo de negocio, la diferencia es que el modelo de dominio busca ser más concreto y compacto y el de negocio mucho más general y detallado. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 13 / 72

14 El Proceso Unificado I El Proceso Unificado o Proceso Unificado Racional -Rational Unified Process RUP- fue creado por Philippe Kruchten en El Proceso Unificado es un proceso de desarrollo de software. Su antecesor es fue el Rational Objectory Process de Este es un modelo híbrido que considera la buena práctica en especificación y diseño y esta de acuerdo con la entrega de prototipos y entrega incremental. Una de las ventajas que provee es que es una forma de desarrollo genérica que puede adecuarse a diferentes variedades des sistemas de software. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 14 / 72

15 El Proceso Unificado II Se basa en el uso de componentes software interconectados a través de interfaces. Se ayuda de UML para la generación de los esquemas del sistema. El Proceso Unificado se consiste de una serie de ciclos que en conjunto forman la vida del sistema. Cada ciclo se lleva a cabo en cuatro fases: 1 Inicio. 2 Elaboración. 3 Construcción. 4 Transición. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 15 / 72

16 El Proceso Unificado III Cada fase se compone de iteraciones. Cada ciclo da como resultado una nueva versión (completa) del sistema. Durante cada ciclo se deben considerar flujos de trabajo que consideren lo siguiente: 1 Un modelo de casos de uso (requerimientos). 2 Un modelo de análisis. 3 Un modelo de diseño. 4 Un modelo de implementación. 5 Un modelo de prueba. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 16 / 72

17 El Proceso Unificado IV Requerimientos Se modelan los procesos del negocio utilizando los casos de uso de la empresa y su relación con los usuarios. Debe existir una planificación que cumpla con las restricciones de costo y tiempo. Se deben cubrir las necesidades y expectativas del cliente. Análisis Se identifican los actores del sistema y se desarrollan los propios casos de uso. Descubrir el conjunto de objetos que proporcionan el comportamiento requerido por algunas funcionalidades del sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 17 / 72

18 El Proceso Unificado V Diseño Se crea y documenta el diseño del sistema mediante modelos arquitectónicos, de componentes, de objetos y de secuencias. Lo ideal es tener un sistema en forma de subsistemas, clases e interfaces. Los casos de uso deben ser mapeados a diagramas de colaboraciones. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 18 / 72

19 El Proceso Unificado VI Implementación Se proporciona al equipo de desarrollo las herramientas adecuadas para el producto a desarrollar. Se implementan y estructuran los componentes del sistema. La generación automática de código puede acelerar esta actividad. Se realiza el ensamblaje de los componentes, librerías, datos y la compilación para crear el ejecutable del sistema. Pruebas Son un proceso iterativo que va de la mano con la implementación. Se libera el producto hacia los usuarios. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 19 / 72

20 El Proceso Unificado VII Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 20 / 72

21 I Inicio Consiste en modelar el problema del cliente/empresa. Se deben identificar todas las entidades externas (personas y sistemas) que interactuarán con el sistema. Se deben identificar los requisitos necesarios para resolver el problema. Se valora la aportación del sistema al cliente/empresa. Se establece el alcance del proyecto y su costo. Se proponen arquitecturas para el sistema Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 21 / 72

22 II Elaboración Se desarrolla la comprensión del problema. Puede que se encuentren más requisitos y se redefina el alcance. Se establece un marco conceptual arquitectónico del sistema. Se establecen los casos de uso UML, el diseño arquitectónico y la planificación del proyecto. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 22 / 72

23 III Construcción Consiste en el diseño, programación y pruebas del sistema. La arquitectura debe crecer hasta convertirse en un software estable. El producto debe contener los casos de uso aprobados. No necesariamente el software está libre de defectos. Debe evaluarse si la versión actual cubre las necesidades de los cliente como para liberárselas. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 23 / 72

24 IV Transición Consiste en liberar la versión (beta) a los usuarios para que la usen en el entorno real. Los desarrolladores corrigen los problemas e incorporan las sugerencias/mejoras proporcionadas por los usuarios que probaron el sistema. Lo ideal es dividir los defectos según su impacto y agregarlos en la misma versión o como parte de una nueva. Es una fase costosa y problemática. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 24 / 72

25 Fase de inicio I El Proceso Unificado De modo general, esta fase consiste en arrancar el proyecto. Se realizará el análisis del negocio tal que se logre justificar la puesta en marcha del proyecto. Se comprenderán los procesos o actividades que serán cubiertas por el nuevo software. Se delimitará el alcance del proyecto. Se realizará una primera aproximación de la arquitectura que será el soporte del sistema. Se debe prever el impacto del sistema en términos económicos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 25 / 72

26 Fase de inicio II El Proceso Unificado Compensarán las ganancias procedentes del uso o la venta del software, su costo de desarrollo? Llegará el producto al cliente o al mercado a tiempo de obtener tales ganancias? Gran parte de la justificación del proyecto puede entenderse mejor si se considera para quién va dirigido el sistema. El mercado en general. Otros departamentos de la misma empresa. Para un cliente en particular. La planificación de la fase de inicio consiste de cuatro pasos esenciales: Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 26 / 72

27 Fase de inicio III El Proceso Unificado 1 Recabar toda la información posible antes de que comience el proyecto. 2 Organizar la información de forma útil. 3 Reunir a los especialistas que sepan analizar la información. 4 Descubrir los objetivos que hacen falta para terminar con éxito esta fase. Es importante considerar los siguientes criterios de evaluación: 1 Decidir el entorno del sistema. 2 Resolver ambigüedades en los requerimientos. 3 Determinar una arquitectura candidata. 4 Mitigar los riesgos críticos. 5 Juzgar el valor aportado al negocio. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 27 / 72

28 Fase de inicio IV Decidir el entorno del sistema Está claro lo que va a formar parte del sistema? Se han identificado todos los actores? Se podría generar un sistema funcional con los elementos del entorno existente? Queda claro el papel de los actores y su interacción con el sistema? Resolver ambigüedades en los requerimientos Se han identificado los requerimientos funcionales? Se han identificado los requerimientos no funcionales? Determinar una arquitectura candidata La arquitectura propuesta satisface las necesidades de los usuarios? Es una arquitectura factible? Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 28 / 72

29 Fase de inicio V Mitigar los riesgos críticos Un riesgo crítico es aquel que en caso de no eliminarse pone en riesgo al proyecto. Se han identificado los riesgos críticos? Existe algún plan para eliminar los riesgos? Juzgar el valor aportado al negocio El sistema aporta un valor agregado al negocio? Vale la pena desarrollar un nuevo sistema? Qué valor podría aportar otro software ya existente? Tomando en cuenta los criterios de evaluación, es necesario ejecutar los flujos de trabajo fundamentales. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 29 / 72

30 Fase de inicio VI El Proceso Unificado Esta fase es mas complicada cuando el producto a desarrollar es totalmente nuevo e innovador. Cada iteración puede visualizarse como un pequeño ciclo de vida en cascada. En esta fase los flujos de trabajo más importantes son: 1 La recopilación de los requisitos. 2 El análisis. 3 El diseño. 4 La implementación. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 30 / 72

31 Fase de inicio VII Recopilación de los requisitos Enumerar los requisitos candidatos. Comprender el contexto del sistema. Representar los requisitos funcionales como casos de uso. Recopilar los requisitos no funcionales. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 31 / 72

32 Fase de inicio VIII Análisis De la arquitectura. El arquitecto debe construir una primera versión del modelo de análisis que ayudará a visualizar las partes del sistema. El primer modelo de análisis puede ser la base de las siguientes versiones o sólo una guía. De casos de uso. Se deben identificar los casos de uso que comparten recursos. El modelo de análisis permita visualizar tales recursos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 32 / 72

33 Fase de inicio IX Diseño De la arquitectura. Realizar un modelo de diseño que contemple los casos de uso como colaboraciones entre subsistemas o clases. Se deben definir las interfaces. Se elige el software de sistema y los marcos de trabajo. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 33 / 72

34 Fase de inicio X Implementación Dilema Arquitectura Prototipo Prototipo Arquitectura Lo ideal es al menos desarrollar una arquitectura candidata. El prototipo puede ser uno desechable. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 34 / 72

35 Fase de elaboración I El Proceso Unificado Al inicio de esta fase se tiene un modelo de casos de uso casi completo y una descripción de la arquitectura candidata. También pueden existir las primeras aproximaciones de un modelo de análisis y el de diseño. Se deben recopilar los requisitos que aún queden pendientes y formularse como casos de uso. Establecer una arquitectura sólida del sistema. Seguir controlando y considerando los riesgos críticos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 35 / 72

36 Fase de elaboración II Al finalizar esta fase, lo ideal es contar con aproximadamente el 80 % de los casos de uso bien definidos. En esta fase se realiza un mejor análisis del negocio. Se desarrollan los fundamentos sólidos para avanzar a la fase de construcción. La planificación de esta fase contempla tres puntos importantes: 1 Formación del equipo de trabajo. 2 Modificación del entorno de desarrollo. 3 Establecimiento de los criterios de evaluación. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 36 / 72

37 Fase de elaboración III Formación del equipo de trabajo Si hay necesidades especiales, integrar al equipo al personal capacitado para esas funciones. Las personas que se incorporen a partir de esta fase, se verán involucradas cuando menos hasta la siguiente fase. Modificación del entorno de desarrollo Conforme se descubren los nuevos requisitos el entorno de desarrollo puede sufrir cambios. La arquitectura debe ser independiente del entorno de desarrollo. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 37 / 72

38 Fase de elaboración IV Establecimiento de los criterios de evaluación Ampliar los requisitos. Están identificados todos los requisitos, actores y casos de uso que permitan el correcto diseño de la arquitectura básica? Se encuentran bien detallados los requisitos y los casos de uso? Definir la arquitectura básica. La arquitectura satisface las necesidades de todos los usuarios? La arquitectura permitirá posibles adecuaciones? Juzgar la validez del análisis del negocio. Está el proyecto bien definido como para proponer un precio y la calidad del nuevo producto? Se recuperará la inversión del desarrollo del producto? Es posible redactar un contrato a un precio fijo? Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 38 / 72

39 Fase de elaboración V Si el proyecto es grande, puede llevar bastante tiempo reunir al equipo de trabajo. Mientras se conforma el equipo de trabajo lo ideal es proponer y ensayar soluciones. El desarrollo de cada nueva arquitectura propuesta es en realidad una iteración incremental de esta fase. Aquí se aplican los cinco flujo de trabajo. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 39 / 72

40 Fase de elaboración VI Recopilación de los requisitos Encontrar casos de uso y actores. Desarrollar prototipos de las interfaces de usuario. Determinar la prioridad de los casos de uso. Detallar los casos de uso. Estructurar el modelo de casos de uso. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 40 / 72

41 Fase de elaboración VII Análisis I De la arquitectura. Generar el modelo básico de la arquitectura. Se desarrollan los siguientes diagramas estructurales: 1 Diagrama de clases. 2 Diagrama de paquetes. 3 Diagrama de componentes. De casos de uso. Se refinan los casos de uso de mayor prioridad. También se refinan los casos de uso que den soporte a los casos de uso prioritarios. Cada caso de uso se queda especificado en función de las clases que lo soportan. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 41 / 72

42 Fase de elaboración VIII Análisis II De clases. Se refinan las clases derivadas de los análisis anteriores. Deben quedar detallados los métodos y atributos esenciales de cada clase. De paquetes. El arquitecto determinará el agrupamiento de las clases como paquetes de servicio. De componentes. Se desarrollan los componentes en base a los paquetes planteados. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 42 / 72

43 Fase de elaboración IX Diseño I De la arquitectura. Identificar el tipo de arquitectura a desarrollar. Ej en capas. Identificar los subsistemas y sus interfaces. Identificar las clases de diseño de la arquitectura. Identificar los nodos y las configuraciones de red (sólo si aplica). De casos de uso. Plantear los casos de uso (sólo los analizados) en términos de subsistemas. Se especifican las operaciones utilizadas para la comunicación. Se empieza a echar un vistazo acerca de que subsistemas, marcos de trabajo o componentes es posible reutilizar. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 43 / 72

44 Fase de elaboración X Diseño II De clases. No necesariamente quedarán completas las clases. Las operaciones deben encontrarse en clases consistentes. De subsistemas. Se diseñan los subsistemas derivados del diseño de la arquitectura. Puede ser necesario actualizar la arquitectura del modelo del diseño. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 44 / 72

45 Fase de elaboración XI Implementación Generalmente se implementan menos de la mitad de los casos de uso. De las clases. De los subsistemas. De la arquitectura. Integrar el sistema. Lo ideal sería obtener un sistema ejecutable. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 45 / 72

46 Fase de elaboración XII Pruebas El objetivo es asegurar que el sistema funcione a todos los niveles. Lo ideal es probar por capas. Las pruebas permiten visualizar la escalabilidad del sistema. Se consideran cuatro pasos para realizar este proceso: 1 Planificar las pruebas. 2 Diseñar las pruebas. 3 Realizar las pruebas de integración. 4 Planificar las pruebas del sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 46 / 72

47 Fase de construcción I El objetivo de esta fase es crear un producto de software que sea operable. Se deberán detallar los casos de uso faltantes. Se implementarán el 90 % de los caos de uso. Con ayuda de la representación de la arquitectura como subsistemas e interfaces se logrará una mejor distribución del trabajo. El jefe de proyecto asignará un subsistema a cada desarrollador, quien es comúnmente llamado ingeniero de componentes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 47 / 72

48 Fase de construcción II Otros de los involucrados en esta fase son: Analista de sistemas. El ingeniero de pruebas. El responsable de la integración del sistema. El encargado de las pruebas de integración. El encargado de las pruebas del sistema. La labor del arquitecto de software es menor en esta parte. También se comienza a preparar cierto material de evaluación, como: Material para los usuarios. Manual de usuario, texto de ayuda, notas de las versiones. Material para cursos. Materiales didácticos para el soporte de los cursos como diapositivas, notas, ejemplos y tutoriales. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 48 / 72

49 Fase de construcción III Recopilación de los requisitos faltantes El objetivo es tener identificados y detallados el 100 % de los requisitos al final de esta fase. Encontrar actores y caso de uso faltantes. Se desarrollan los prototipos para la interfaz de usuario. Si la interfaz de usuario es muy complicada, esta evolucionará conforme el usuario proporcione sus observaciones. Una vez creados los nuevos casos de uso se reorganizan sus prioridades y se desarrollan nuevamente según su orden. Se detallan todos los casos de uso. No se recomiendan cambios grandes en el modelo de casos de uso pues pueden impactar negativamente en la arquitectura. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 49 / 72

50 Fase de construcción IV Análisis I De la arquitectura. Dado que el modelo de análisis será más detallado, la arquitectura puede requerir ciertos cambios menores. Se afinan los siguientes diagramas estructurales: 1 Diagrama de clases. 2 Diagrama de paquetes. De casos de uso. Conforme se analiza la totalidad de los casos de uso, el modelo de análisis se vuelve más realista. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 50 / 72

51 Fase de construcción V Análisis II De clases. Se analizan las clases faltantes y las que hayan aparecido debido a los nuevos casos de uso. De paquetes. Se refinan los paquetes involucrados. La nuevas clases son clasificadas donde les corresponda. De componentes. El trabajo es menor, pocas veces se requiere crear componentes adicionales en este punto. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 51 / 72

52 Fase de construcción VI Diseño I Se consideran los siguientes elementos de diseño. Modelo de diseño. Se describe el detalle, a través de modelos de objetos, de la realización de los casos de uso faltantes. Elaboración de clases de diseño. Se deben especificar las clases en el lenguaje de programación. También para las operaciones, parámetros, atributos y tipos. De diagramas de clases. Se diseñan los nuevos diagramas de clases conectados al resto de los casos de uso. Se especificarán las clases participantes, subsistemas y sus relaciones. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 52 / 72

53 Fase de construcción VII Diseño II De diagramas de interacción. Se lleva a cabo gracias a los diagramas de secuencia. Los diagramas de secuencia permiten entender la interacción que habrá con el sistema. Cuando un subsistema recibe un mensaje, es en realidad un objeto de una clase del subsistema el que recibe tal mensaje. Lo mismo para cuando un subsistema envía un mensaje. De Interfaces. Puede ser que la mayoría se encuentren definidas, pero hay que especificarlas todas. Del modelo de despliegue. Se describe la distribución física del sistema en términos de nodos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 53 / 72

54 Fase de construcción VIII Implementación De la arquitectura. La arquitectura ya debe contar con bases sólidas. Sólo se realiza trabajo de actualización. De las clases y de los subsistemas. Los ingenieros de componentes llevan a cabo esta labor. De pruebas de unidad. También son realizadas por los ingenieros de componentes. Si es necesario se corregirá el diseño y la implementación. De la integración del sistema. Se crea un plan de integración de construcciones. El plan debe detallar los casos de uso o escenarios se implementan en dicha construcción. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 54 / 72

55 Fase de construcción IX Pruebas I Planificación de las pruebas. Se seleccionan los objetivos que verifiquen el funcionamiento de las construcciones realizadas. Diseño de pruebas. Se preparan los casos y procedimientos que verifiquen los requisitos. Se preparan las pruebas individuales y en conjunto de los componentes. Pruebas de integración. El encargado de integración determinará si son necesarias pruebas adicionales. También se deben registrar las fallas detectadas. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 55 / 72

56 Fase de construcción X Pruebas II Pruebas del sistema. En ocasiones hay un encargado de las pruebas del sistema. El encargado de las pruebas del sistema debe comprobar la operativa de todo el sistema. Evaluación de pruebas. Los resultados obtenidos de las pruebas deben ser comparados contra los objetivos inicialmente planteados. Cuando la prueba no cumple los objetivos, los casos y procedimientos deben ser rediseñados. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 56 / 72

57 Fase de construcción XI Prueba de desarrollo Es un proceso realizado por los programadores. Cada componente se prueba de forma independiente. Existen herramientas que automatizan este proceso o bien pueden ser creadas las propias. JUnit in Action, Petar Tahchiev, Felipe Leme, Vincent Massol and Gary Gregory, 2nd Ed Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 57 / 72

58 Fase de construcción XII Prueba de desarrollo JUnit es un marco de trabajo diseñado para automatizar la generación de casos de prueba. JUint es una instancia de la arquitectura xunit, que fue creada para realizar pruebas de unidad. Pruebas del sistema El objetivo es descubrir errores de las interacciones entre los componentes. También se busca verificar que el sistema cumple con los requerimientos funcionales. Puede consistir de varias etapas. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 58 / 72

59 Fase de transición I El Proceso Unificado El principal objetivo de esta fase es que al final el sistema cumpla con los requisitos establecidos y todos los usuarios estén satisfechos con el software. Realizar las correcciones necesarias a la versión beta del sistema. Cuando se trata de un producto que saldrá al mercado general, las versiones beta suelen distribuirse a los posibles compradores de ciertas organizaciones. Cuando es para un cliente en específico simplemente se instala el producto en algunas de sus computadoras. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 59 / 72

60 Fase de transición II El Proceso Unificado Las objetivos específicos de esta fase son: Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 60 / 72

61 Fase de transición III El Proceso Unificado Esta fase es difícil de planificar pues la cantidad de trabajo dependerá de la retroalimentación del cliente. Lo ideal es tener a cierto personal atento a las recomendaciones o fallas reportadas por los usuarios del sistema. El perfil del personal para esta fase está orientado al servicio. Incluso las mejoras mas pequeñas pueden requerir de expertos que las detecten. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 61 / 72

62 Fase de transición IV Establecimiento de los criterios de evaluación Verificación de los requisitos. Los usuarios han probado las funciones clave del sistema? Pruebas de aceptación. El producto ha superado las pruebas de aceptación realizadas por los usuarios? Material para los usuarios y los cursos. Tiene el material de usuario una calidad aceptable? Está listo el material para impartir los cursos referentes al sistema? Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 62 / 72

63 Fase de transición V Análisis El análisis esta enfocado en modificar las clases, y quizás los componentes, en los que se hayan encontrado fallas. Una menor parte del tiempo será dedicada al análisis de los casos de uso que hayan quedado pendientes en la fase de construcción. Diseño Puede ser necesario rediseñar algunas clases. Generalmente sólo se rediseñan aquellas clases que llagasen a fallar constantemente y a afectar a uno o más componentes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 63 / 72

64 Fase de transición VI Implementación Se corrigen los errores encontrados por los usuarios. Se agregan las mejoras sugeridas. Se implementan las clases rediseñadas. Pruebas Se realizan las pruebas de integración que estén pendientes. Se realizan las pruebas de sistema pendientes. Hay mayor flujo de trabajo en la parte de pruebas de aceptación. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 64 / 72

65 Fase de transición VII Pruebas de aceptación El sistema se pone a prueba con datos reales. Los datos reales suelen revelar problemas no detectados con los datos ficticios. Permiten observar el rendimiento global del sistema. Cuándo acaba el proyecto? Cuando los usuarios están satisfechos. Cuándo los usuarios están satisfechos? Depende del contrato establecido. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 65 / 72

66 Buenas prácticas del Proceso Unificado Buenas prácticas del Proceso Unificado I Desarrollo de software de manera interactiva Realizar el desarrollo en base a las prioridades del cliente. Gestión de requerimientos Documentar explícitamente los requerimientos y realizar los cambios necesarios sobre estos. Evaluar el impacto de cambios en el sistema antes de aceptarlos. Usar arquitecturas basadas en componentes Estructurar la arquitectura del sistema en base a componentes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 66 / 72

67 Buenas prácticas del Proceso Unificado Buenas prácticas del Proceso Unificado II Software modelado visualmente Utilizar modelos UML para refresentar procesos en la fases y actividades de ingeniería del Proceso Unificado. Verificar la calidad del software Asegurar que el software cumple con los estándares de calidad establecidos en la empresa. Controlar los cambios al software Gestionar los cambios mediante un controlador de versiones. Además se deben documentar los procedimientos y todo lo necesario para la configuración del sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 67 / 72

68 Comercialización de software Comercialización de software I La comercialización de software es parte de un proceso mas grande llamado industria del software y consiste en la venta de un producto de software. La industria del software se encarga de la investigación, desarrollo, distribución y comercialización de software. Los gastos iniciales de desarrollo, marketing e infraestructura de soporte técnico para las versiones iniciales son altos. Las nuevas versiones basadas en las anteriores suelen requerir menos gastos de desarrollo. En la industria es común las compras hostiles o agresivas. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 68 / 72

69 Comercialización de software Comercialización de software II Para la parte de distribución, algunas empresas de desarrollo de software se ayudan de empresas distribuidoras de software. Una distribuidora de software es una empresa intermediaria entre las empresas de desarrollo de software y los posibles compradores. La distribuidora es quien decide el modo de distribución. En ocasiones las distribuidoras realizan la investigación pertinente con la finalidad de ofrecer nuevos productos. También se suelen encargar de vender las licencias de software bajo limitaciones temporales y geográficas, y retribuirle regalías a la desarrolladora. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 69 / 72

70 Comercialización de software Comercialización de software III Principales funciones de la distribuidoras de software Contactar a otras empresas que hagan llegar el software a los posibles clientes. Dar a conocer el producto de software mediante anuncios y eventos. Diseñar y producir el empaque en el caso de distribución física. Regresando al tema de comercialización, existen dos formas de comercializar software: Para un mercado general. Para un cliente en específico. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 70 / 72

71 Comercialización de software Comercialización de software IV Para un mercado general El mercado es diversificado. Existen diferentes variantes del sistema considerando: el país, el idioma, la moneda y algunas otras unidades de medida. Generalmente son instalados por el usuario o por el administrador de sistemas de la empresa. El producto viene con una aplicación que guía a los usuarios en la instalación. Generalmente se brinda asistencia telefónica de ser necesario. El proceso de instalación no debe variar mucho de un sistema operativo a otro. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 71 / 72

72 Comercialización de software Comercialización de software V Para un cliente en específico El mercado es conocido. Existen diferentes variantes del sistema considerando las necesidades del cliente. Pueden ser instalados por los usuarios, pero también por el equipo de distribución de la empresa de software. El producto también debe venir con una aplicación que de soporte en el proceso de instalación. La asistencia suele ser personalizada. El proceso de instalación no debe variar mucho de un sistema operativo a otro. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo y comercialización de PS 72 / 72

Fundamentos de Ingeniería de Software [Modelos]

Fundamentos de Ingeniería de Software [Modelos] Fundamentos de Ingeniería de Software [Modelos] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-I Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

El proceso unificado en pocas palabras

El proceso unificado en pocas palabras El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,

Más detalles

6 Anexos: 6.1 Definición de Rup:

6 Anexos: 6.1 Definición de Rup: 6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Metodologías de Desarrollo de Sistemas de Información

Metodologías de Desarrollo de Sistemas de Información Metodologías de Desarrollo de Sistemas de Información Metodología para el Desarrollo de SI Las metodologías son sistemas completos de técnicas que incluyen procedimientos paso a paso, productos resultante,

Más detalles

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Metodología Evolutiva Incremental Mediante Prototipo y Técnicas Orientada a Objeto (MEI/P-OO)

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

Patrones de software y refactorización de código

Patrones de software y refactorización de código Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.

Más detalles

Primer avance de proyecto de software para la gestión de inscripciones en cursos

Primer avance de proyecto de software para la gestión de inscripciones en cursos Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Principios y criterios para la evaluación del ciclo de vida de desarrollo de sistemas Se pueden enunciar algunos principios para desarrollar

Más detalles

Modelos de Proceso Tradicionales

Modelos de Proceso Tradicionales Modelos de Proceso Tradicionales Capitulo 2,QJHQLHUtDGHO6RIWZDUH (VSHFLDOL]DFLyQHQ*HUHQFLDGH6LVWHPDVGH,QIRUPDFLyQ 8QLYHUVLGDG6DQWLDJRGH&DOL Profesor: MSc. MIGUEL ANGEL NIÑO ZAMBRANO Programación: Tiempo

Más detalles

Criterios de clasificación

Criterios de clasificación Criterios de clasificación Usualmente clasificamos para agrupar elementos con características comunes, simplificando la realidad y analizando un conjunto de elementos desde distintos puntos de vista. Sobre

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008)

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008) Unidades temáticas de Ingeniería del Software Fases del proceso de desarrollo 4ª edición (2008) Facultad de Informática organización del desarrollo El ciclo de vida del software abarca el proceso de desarrollo,

Más detalles

PRU. Fundamento Institucional. Objetivos. Alcance

PRU. Fundamento Institucional. Objetivos. Alcance PRU INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de PRUEBAS para el desarrollo de software, en el cual se debe apoyar para la ejecución de sus actividades;

Más detalles

Introducción a la Ingeniería de Software - Examen 20/07/2012

Introducción a la Ingeniería de Software - Examen 20/07/2012 Cada pregunta múltiple opción contestada correctamente tiene un valor de 2,5 puntos. Esta parte consta de 20 preguntas, haciendo un total de 50 puntos. Los ejercicios de desarrollo tienen un valor total

Más detalles

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS Rubby Casallas, Andrés Yie Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Agenda Contexto Ciclos de vida: Modelo

Más detalles

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS Existen diversos métodos para desarrollar un sistema de información o un microsistema, pero en esencia todos parten de los mismos principios

Más detalles

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0 Centro Ideoinformática Universidad de las Ciencias Informáticas Carretera a San Antonio Km 2 ½. Torrens. Boyeros. Ciudad de La Habana. Cuba Teléfono: + 53 (7)

Más detalles

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos ZP09-0207, con fecha 2 de junio de 2009 IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos Índice 1 Resumen de características

Más detalles

CICLO DE VIDA DEL SOFTWARE

CICLO DE VIDA DEL SOFTWARE CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en

Más detalles

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Versión 3.0 Fecha: 02/01/2003 Historial de Revisiones Fecha Versión Descripción Autor 22/07/2002 0.9 Versión preliminar como propuesta

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]:

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]: RESUMEN DE COBIT 4.1 COBIT es un marco de trabajo y un conjunto de herramientas de Gobierno de Tecnología de Información (TI) que permite a la Gerencia cerrar la brecha entre los requerimientos de control,

Más detalles

Unidad 9. Implementación. M.C. Martín Olguín

Unidad 9. Implementación. M.C. Martín Olguín Unidad 9 Implementación M.C. Martín Olguín Implementación Es la traducción directa del diseño en un lenguaje de programación. Es decir, en la implementación se construyen los componentes: Archivos de código

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008

Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008 Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008 ISO 9001 CUATRO CAPÍTULOS BÁSICOS RESPONSABILIDADES DE LA DIRECCIÓN P D GESTIÓN DE RECURSOS REALIZACIÓN DEL PRODUCTO A C MEDICIÓN

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

Más detalles

http://www.informatizate.net

http://www.informatizate.net http://www.informatizate.net Metodologías De Desarrollo De Software María A. Mendoza Sanchez Ing. Informático - UNT Microsoft Certified Professional - MCP Analísta y Desarrolladora - TeamSoft Perú S.A.C.

Más detalles

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO Ejercicio Guiado de Análisis y Diseño Orientado a Objetos Ejemplo: CAJERO AUTOMÁTICO El siguiente ejercicio muestra las diferentes actividades que se realizan dentro del desarrollo de un producto software

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS METODOLOGIAS AGILES PROCESO UNIFICADO AGIL (AUP) MATERIA : INGENIERIA SOFTWARE DOCENTE : LIC. ERVIN FLORES ESTUDIANTE : JORGE LUIS CORDERO

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

Más detalles

PROCEDIMIENTO GENERAL RAZÓN SOCIAL DE LA EMPRESA. Diseño y desarrollo. Código PG-17 Edición 0. Índice

PROCEDIMIENTO GENERAL RAZÓN SOCIAL DE LA EMPRESA. Diseño y desarrollo. Código PG-17 Edición 0. Índice Índice 1. TABLA RESUMEN... 2 2. OBJETO... 2 3. ALCANCE... 2 4. RESPONSABILIDADES... 3 5. ENTRADAS... 3 6. SALIDAS... 3 7. PROCESOS RELACIONADOS... 3 8. DIAGRAMA DE FLUJO... 4 9. DESARROLLO... 5 9.1. IDENTIFICACIÓN

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Sergio Valero Orea, svalero@utim.edu.mx, UTIM, Izúcar de Matamoros, Puebla. Resumen El desarrollo de sistemas

Más detalles

Mantenimiento de Sistemas de Información

Mantenimiento de Sistemas de Información de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD MSI 1: REGISTRO DE LA PETICIÓN...4 Tarea MSI 1.1: Registro de la Petición... 4 Tarea MSI 1.2: Asignación de la Petición... 5 ACTIVIDAD

Más detalles

JUSTIFICACIÓN DEL DESARROLLO DE UN SE

JUSTIFICACIÓN DEL DESARROLLO DE UN SE JUSTIFICACIÓN DEL DESARROLLO DE UN SE El beneficio económico que representa la solución del problema es alto La experiencia humana puede desaparecer La experiencia humana no se encuentra comúnmente disponible

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Capítulo 11. Conclusiones y trabajo futuro

Capítulo 11. Conclusiones y trabajo futuro Capítulo 11. Conclusiones y trabajo futuro En esta tesis ha realizado un entorno de desarrollo Web que proporciona herramientas para la mejora de la calidad del código de los desarrolladores. Para conseguir

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes. Definiciones

Más detalles

Sistemas de gestión de la calidad Requisitos

Sistemas de gestión de la calidad Requisitos Sistemas de gestión de la calidad Requisitos 1 Objeto y campo de aplicación 1.1 Generalidades Esta Norma Internacional especifica los requisitos para un sistema de gestión de la calidad, cuando una organización

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Información General del Documento Versión Actual del Documento 0.0.0.7 Descripción

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

Escogiendo un sistema host

Escogiendo un sistema host 2002 Emerson Process Management. Todos los derechos reservados. Vea este y otros cursos en línea en www.plantwebuniversity.com. Fieldbus 402 Escogiendo un sistema host Generalidades Experiencia del proveedor

Más detalles

Proceso Unificado de Rational

Proceso Unificado de Rational RUP: El Proceso Unificado de Rational XP: Programacion Extrema EAP: Computación Científica Ciencia de la Computación V Prof. Oscar Brnito Pacheco Proceso Unificado de Rational Orígenes Modelo original

Más detalles

cumple y hay evidencias objetivas

cumple y hay evidencias objetivas Lista de Verificación ISO :2008 LISTA DE VERIFICACIÓN ISO :2008 Sistemas de Gestión de la Calidad Pliego Objeto y campo de aplicación Esta lista de verificación tiene como objetivo conocer con mayor detalle

Más detalles

ASI. Análisis del Sistema de Información

ASI. Análisis del Sistema de Información ASI Análisis del Sistema de Información 1 ASI Análisis del Sistema de Información Introducción Objetivo Obtención de una especificación detallada del Sistema Información a través de: Catálogo de Requisitos

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Ciclo de vida del Software

Ciclo de vida del Software Tema 2: Ciclo de vida del Software Marcos López Sanz Índice Qué es el ciclo de vida del Software? La norma 12207-2008 Modelos de desarrollo Qué es el Ciclo de Vida del SW? Es una sucesión de etapas por

Más detalles

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M No. REQUISITOS EXISTE ESTADO OBSERVACIONES 4. SISTEMA DE GESTION DE LA CALIDAD 4.1 Requisitos Generales La organización debe establecer, documentar, implementar y mantener un S.G.C y mejorar continuamente

Más detalles

EJ-DSI. Ejemplo - Diseño del Sistema de Información

EJ-DSI. Ejemplo - Diseño del Sistema de Información EJ-DSI Ejemplo - Diseño del Sistema de Información 1 Estructura DSI 1 Definición de la Arquitectura del Sistema DSI 2 Diseño de la arquitectura de soporte DSI 3 Diseño de Casos de Uso Reales DSI 4 Diseño

Más detalles

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA Resumen AUTORIA CARLOS CABALLERO GONZÁLEZ TEMATICA INFORMÁTICA ETAPA ESO-BACHILLERATO-CFGM(ESI,ASI,DSI) Se describe la revolución que supuso la incursión

Más detalles

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE UNIVERSIDAD DEL CAUCA FACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

Más detalles

El Proceso Unificado Rational para el Desarrollo de Software.

El Proceso Unificado Rational para el Desarrollo de Software. Instituto de Electrónica y Computación El Proceso Unificado Rational para el Desarrollo de Software. Carlos Alberto Fernández y Fernández Huajuapan de León, Oaxaca 26 de octubre de 2000 Objetivo Proporcionar

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

IMPLEMENTACION DE SISTEMAS DE INFORMACION CONTABLE

IMPLEMENTACION DE SISTEMAS DE INFORMACION CONTABLE IMPLEMENTACION DE SISTEMAS DE INFORMACION CONTABLE OBJETIVO: Obtener los conocimientos necesarios para realizar implementación de sistemas contables CICLO DE VIDA DE UN SISTEMA DE INFORMACION MANTENIMIENTO

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

DIRECCIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO

DIRECCIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO DIRECCIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO n Objetivo

Más detalles

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos

Más detalles

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles

El Desarrollo de Software desde un enfoque de procesos

El Desarrollo de Software desde un enfoque de procesos El Desarrollo de Software desde un enfoque de procesos Planteamiento del Problema Desarrollo de Software Software Proceso: conjunto de actividades interrelacionadas que permiten

Más detalles

RESUMEN. IV P á g i n a

RESUMEN. IV P á g i n a RESUMEN El Sistema Web para el Control de la Caja de Ahorros de SENECA, fue desarrollado siguiendo las fases establecidas por la Metodología RUP (Proceso Unificado de Rational). Las fases de esta metodología

Más detalles