Requisitos de Software. Departamento de Lenguajes y Sistemas Informáticos II

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

Download "Requisitos de Software. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es"

Transcripción

1 Requisitos de Software Departamento de Lenguajes y Sistemas Informáticos II

2 Introducción Ingeniería de Requisitos Definición: La Ingeniería de requisitos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software, tomando en cuenta los diversos requisitos de los clientes (y usuarios), que pueden entrar en conflicto entre ellos. Básicamente cubre todo el proceso de descubrir, analizar, documentar los servicios que debe suministrar un software y las restricciones operativas a las que se deberá enfrentar.

3 Introducción Requisitos Definición: Descripción de los servicios que tendrá que proporcionar el sistema y de sus restricciones operativas. Reflejan además las necesidades de los clientes y usuarios de un sistema para que ayude a resolver algún problema concreto (como el control de un dispositivo, localizar una determinada información o realizar una determinada función administrativa como escribir un documento).

4 Introducción Se puede observar que la definición citada anteriormente puede llegar a ser muy ambigua y de hecho en la industria del software encontramos esta ambigüedad en el uso del término requisitos. El problema radica en que la descripción de lo que un sistema debe hacer cambia radicalmente dependiendo del destinatario de dicha descripción. Obviamente el nivel de detalle de descripción no puede ser el mismo para un equipo que ha de iniciar el desarrollo de un sistema que para el equipo directivo que decide contratar el desarrollo de un sistema. El sistema es el mismo y ambos colectivos saben lo que el sistema debe hacer pero el detalle necesario en la descripción es radicalmente distinto.

5 Requisitos de usuario y de sistema De este modo, podremos comenzar a diferenciar los requisitos en función del grado de detalle en la descripción de los mismos: Requisitos de usuario/cliente: Declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe operar. Requisitos de sistema/software: descripción detallada de las funciones, servicios y restricciones del sistema. El documento de requisitos del sistema/software (a veces llamado especificación funcional) debe ser preciso. Debe definir exactamente QUÉ es lo que se va a implementar. A menudo la relación contractual entre el cliente y los desarrolladores suele estar sujeto a este documento.

6 Requisitos de usuario y de sistema Ejemplo: Requisito de usuario 1. El teléfono móvil permitirá al usuario introducir contactos en la agenda del teléfono Requisitos del sistema 1.1. El usuario tendrá que tener encendido el teléfono y haber accedido mediante su pin Accederá al menú principal y seleccionará Contactos Pulsará Opciones y seleccionará Crear Contacto 1.4. Introducirá todos los datos del contacto a crear y pulsará Aceptar 1.5. El sistema almacenará los datos del nuevo contacto en Contactos. Como se puede observar un único requisito de usuario se transforma en 5 requisitos de sistema. El de usuario es más abstracto mientras que los de sistema requieren definir en mayor detalle todas las funciones implicadas.

7 Requisitos de usuario y de sistema Como se ha comentado es necesario redactar los requisitos en diferentes niveles de detalle debido a que existen distintos tipos de lectores. A continuación se muestra un clasificación de los lectores tipo de cada nivel de detalle. Requisito de usuario Administradores Clientes Usuarios finales del sistema Ingenieros Clientes Administradores Contratistas Arquitectos del sistema Requisitos del sistema Usuarios finales del sistema Ingenieros Clientes Arquitectos del sistema Desarrolladores del software

8 Clasificación de Requisitos Podemos igualmente encajar a los requisitos atendiendo a la siguiente clasificación: Requisitos funcionales: Definen lo que el sistema debe hacer. Declaraciones de los servicios que debe proporcionar el sistema: cómo se debe comportar en situaciones particulares, qué respuestas debe dar a determinadas entradas. En algunos casos, estos requisitos pueden declarar explícitamente lo que el sistema NO debe hacer. Requisitos no funcionales: Requisitos que no se refieren directamente a las funciones específicas del sistema sino a las propiedades emergentes de éste como la fiabilidad, rendimiento, tiempo de respuesta, capacidad de almacenamiento, etc. Además también no tienen por qué referirse, exclusivamente, al sistema a desarrollar, sino a técnicas a seguir como estándares de calidad, uso de una herramienta CASE concreta o la descripción del modelo de proceso de desarrollo a seguir. Requisitos de dominio: Provienen del dominio de aplicación del sistema y reflejan las características y restricciones de dicho dominio.

9 Clasificación de Requisitos Ejemplo: Requisitos funcionales: El teléfono móvil permitirá crear nuevos contactos y almacenarlos en la agenda (Contactos). Requisitos no funcionales: La pantalla del teléfono móvil será táctil. Requisitos de dominio El teléfono móvil deberá operar en un rango de frecuencias comprendidas entra los 800 y MHz.

10 Requisitos no Funcionales Requisitos no Funcionales La siguiente trasparencia muestra una clasificación detallada de los requisitos no funcionales. Estos requisitos pueden venir de las características requeridas por el software (producto), de la organización que desarrolla el software (organizacionales) y de otras fuentes externas: Requerimientos del producto: especifican el comportamiento del producto. Ejemplos: Rendimientos de rendimiento en el tiempo de carga de una página Web o el uso máximo de la memoria. Fiabilidad en los resultados ofrecidos por el sistema. Portabilidad: por ejemplo multinavegador (Internet Explorer v.x y Firefox v.x) Requerimientos Organizacionales: provienen de las políticas y procedimientos existentes en las organizaciones (tanto cliente como desarrollador)especifican el comportamiento del producto. Ejemplos: Lenguajes de programación, procesos a utilizar, documentación exigida basados en determinados estándares, etc. Requerimientos Externos: todos los requisitos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Ejemplo: Requisitos de interoperabilidad (definen los protocolos para interactuar con otros sistemas), legislación competente (ej. Ley Orgánica de Protección de Datos de Carácter Personal)

11 Requisitos no Funcionales A continuación se muestra una clasificación de los requisitos no funcionales. Estos requisitos pueden venir de las características requeridas por el software (producto), de la organización que desarrolla el software (organizacionales) y de otras fuentes externas. REQUISITOS NO FUNCIONALES Requisitos de producto Requisitos externos Requisitos de fiabilidad Requisitos organizacionales Requisitos interoperabilidad Requisitos éticos Requisitos legislativos Requisitos de usabilidad Requisitos De entrega Requisitos implementación Requisitos estándares Requisitos De privacidad Requisitos De seguridad Requisitos de portabilidad Requisitos de eficiencia Requisitos de rendimiento Requisitos de espacio

12 Requisitos no Funcionales Ejemplo en el dominio de un sistema de expedición de billetes de tren. Requisito del producto : RNF.10. La interfaz de usuario se implementará en HTML. Requisito organizacional RNF.20. La documentación a entregar seguirá el estándar IEEE. Requisito externo El sistema no deberá revelar al personal de ventas, la información personal de teléfono y dirección postal de los clientes ni viajeros.

13 Requisitos del Dominio Requisitos de Dominio. Definición: Requisitos que provienen del dominio de especificación del sistema y que reflejan las características y restricciones de ese dominio (no tienen por qué derivarse de las especificaciones del usuario). Pueden ser funcionales o no funcionales: restringir algún requisito existente, o establecer cómo se deben ejecutar cálculos particulares. El dominio tiene su propio vocabulario/lenguaje. Es importante comprenderlo para comprender a los usuarios y clientes. Antes de entrar de lleno a especificar, con los usuarios y clientes, hay que trabajar para conocer el dominio del sistema. Estos requisitos plantean un problema especial a los ingenieros del software porque han de comprender un dominio que en ocasiones se escapa de nuestro conocimiento habitual. El grado de dificultad lo marca el dominio, no requiere el mismo esfuerzo adaptarse a un dominio para desarrollar el sistema de expedición de billetes de tren que un Broker-Online.

14 Requisitos del Dominio Ejemplo (Requisitos de Dominio) En el desarrollo de un producto software (VERTA) para la gestión de billetes dentro de un entorno ferroviario, parte del vocabulario que se puede llegar a utilizar es éste: Tarifa Descuento de calendario Descuento general Origen / Destino Retraso Cliente Viajero

15 Requisitos del Dominio Glosario (Ejemplo de Requisitos de Dominio) Tarifa: Precio que queda determinado por el origen/destino y la fecha/hora en la que el cliente va a viajar. Descuento de calendario: Descuento que se aplica en determinados días sobre el precio de la tarifa. Descuento general: Descuento que se aplica al precio de la tarifa en función de determinados criterios (tercera edad, grupos de clientes que viajan al mismo sitio, familia numerosa, etc.) Origen / Destino: Origen / Destino del tren en un viaje. No se refiere a las estaciones por las que pasa sino del punto de partida del tren y del destino final del mismo. Retraso: Se considera retraso a superar en más de 10 minutos la hora prevista de llegada. Se desembolsará el importe del billete al viajero, si existe retraso. Cliente: Persona que compra un billete de tren a su nombre. Viajero: Persona que compró un billete de tren a su nombre y que viaja en el tren. Algunos clientes pierden el tren, por lo tanto estos no son viajeros. La importancia de este concepto es fundamental en términos económicos ya que el desembolso por retraso sólo se aplicará a los viajeros y no a los clientes.

16 Requisitos de Usuario Requisitos de Usuario Deben describir los requisitos funcionales y no funcionales de tal forma que sean comprensibles para los usuarios, sin conocimiento técnico detallado. Se deben centrar en especificar el comportamiento externo del sistema, alejándose todo lo posible de las consideraciones de diseño del sistema, aspectos ajenos a la problemática de los usuarios. Pensemos en la diferencia existente en la especificación de un coche para un ingeniero mecánico y para un usuario que está decidiendo su compra. Ambos visualizan el mismo vehículo pero desde dos perspectivas diferentes. Obviamente la enorme cantidad de información técnica asociada al motor -necesaria para el ingeniero- se resume para el usuario en una línea: 175 CV de potencia. No se debe utilizar una jerga técnica. Deben redactarse en un lenguaje sencillo, utilizando tablas y formularios sencillos y diagramas intuitivos.

17 Requisitos de Usuario Aun teniendo claro lo expuesto en la trasparencia anterior, suelen surgir problemas cuando se plasman requisitos de usuario en un documento de texto: Falta de claridad: Es difícil utilizar un lenguaje sencillo de forma precisa y no ambigua sin hacer el documento poco conciso y difícil de leer. Confusión de requisitos: No se distinguen claramente los requisitos funcionales de los no funcionales, las metas del sistema y la información para el diseño. Conjunción de requisitos: A veces se expresan diferentes requisitos de forma conjunta en un único requisito. Veamos un ejemplo!

18 Requisitos de Usuario Problemas que suelen surgir Ejemplos: Falta de claridad: VERTA proporcionará un sistema de contabilidad que mantendrá registro de todos los pagos hechos por los clientes. Los administradores del sistema pueden configurarlo de forma que los clientes habituales puedan recibir precios rebajados a través de los descuentos generales. Conjunción de requisitos: Se están expresando diferentes requisitos juntos. Por un lado se habla de que el sistema mantendrá un registro de los pagos. Por otro lado se indica que se aplicarán descuentos a los clientes habituales.

19 Requisitos de Usuario Recomendaciones para minimizar malentendidos: Formato estándar para todos los requisitos. Esto permite homogeneizar la captura de los requisitos aunque sea realizada por diferentes personas. También suele ser recomendable indicar la persona que solicitó el requisito. Utilizar el lenguaje de forma consistente para distinguir entre los requisitos obligatorios de los deseables. Los obligatorios se redactan en futuro simple y los deseables en condicional. Resaltar el texto para distinguir las cuestiones claves del requisito (negrita, cursiva, colores). Evitar en la medida uso de jerga informática. Es habitual encontrar a personal técnico que abusa de la terminología técnica como medio para hacer visible la diferencia de conocimientos entre ellos y los usuarios. Es ridículo, obviamente dicha diferencia es evidente y un buen profesional de ser capaz de traducir simultáneamente de un idioma a otro. El hecho de no dejar claramente especificado un requisito porque el usuario no lo entendió correctamente se debe a que el ingeniero de requisitos no realizó bien su trabajo.

20 Requisitos de Sistema Requisitos del Sistema. Son versiones extendidas de los requisitos de usuario para los ingenieros de software. Agregan detalle y deben especificar cómo el sistema debe proporcionar los requisitos para satisfacer los requisitos de usuario. Debe ser una especificación completa y consistente del sistema en su conjunto. Ha de tenerse en cuenta que este conjunto de requisitos establece la relación contractual entre cliente y proveedor. Debe definir claramente el sistema a desarrollar de forma que ambas partes puedan asegurarse los compromisos alcanzados. Evitar el uso exclusivo del lenguaje natural porque puede ser confuso y dar lugar a malentendidos que se detectan en las últimas fases del ciclo de desarrollo.

21 Requisitos de Sistema Requisitos del Sistema Cómo expresarlos? Como se ha comentado, los requisitos de usuarios se redactan en lenguaje natural, lo que facilita la comprensión de los mismos por parte de todos los potenciales lectores. Sin embargo, en el caso de los requisitos de sistemas es diferente. Estos requisitos necesitan de un mayor nivel de detalle y las especificaciones en lenguaje natural puede ser excesivamente confusas y difíciles de entender propensas a malas interpretaciones. Para evitar estos problemas, se pueden utilizar diferentes notaciones que mejoren el entendimiento de los requisitos de sistemas, permitiendo llegar a un nivel de detalle mayor y facilitando la comprensión de los mismos por parte de los lectores no técnicos. En la siguiente transparencia se muestra este conjunto de notaciones.

22 Requisitos de Sistema Notaciones Notaciones para la especificación de requisitos Lenguaje natural estructurado Definición de formularios y plantillas estándares para expresar la especificación de requisitos (la siguiente trasparencia muestra un ejemplo de plantilla). Notaciones gráficas Uso de lenguaje gráfico complementado con anotaciones de texto. Casos de uso, diagramas de secuencia, diagramas de estados, (UML) Especificaciones matemáticas Notaciones que se basan en conceptos matemáticos como el de las máquinas de estados finito o los conjuntos. La mayoría de los clientes no comprenden estas especificaciones y son reacios a aceptarlas como un contrato del desarrollo del sistema.

23 Agregar contacto en el móvil/srs/ Función Descripción Entradas Salidas Precondición Postcondición Efectos colaterales Requisitos de Sistema Agregar un contacto nuevo. Agregará un contacto nuevo a la lista de contactos del móvil. Se deberá verificar que no se duplique ni el nombre ni el número de teléfono Datos del contacto de forma manual. Numero de teléfono desde llamada o sms. Contacto nuevo almacenado. El móvil debe estar encendido y desbloqueado y se debe haber accedido mediante el menú a dicha opción. Ninguna. Ninguno. Notaciones Ejemplo de Plantillas: Lenguaje Natural Estructurado

24 Requisitos de Sistema Notaciones Ejemplo de Diagrama de Estados en UML: Semáforo X-Y en cada estado identifica el color del visor del automóvil y del peatón respectivamente. Visor del automóvil: R (rojo), A (ámbar), V (verde). Visor del peatón: R (rojo), Vi (verde intermitente), V (verde). R-V Do/ Contar (t1) t1 cumplido R-Vi Do/ Contar (t2) t2 cumplido R-R Do/ Contar (t3) t6 cumplido t3 cumplido A-R Do/ Contar (t6) t5 cumplido A-R Do/ Contar (t5) t4 cumplido V-R Do/ Contar (t4) Veremos con mayor detalle este tipo de diagramas, pero aun sin conocerlo en profundidad se puede observar que es intuitivo y refleja fácilmente lo que pretendemos capturar: el funcionamiento de un semáforo.

25 Especificación de la interfaz Especificación de la Interfaz Actualmente es muy difícil encontrar sistemas que se desarrollen aislados, sin necesidad de comunicarse con otros sistemas ya existentes o con otros en fase igualmente de desarrollo. De esta forma se hace imprescindible la definición clara de las interfaces de comunicación entre estos sistemas. Estas interfaces se deben definir al inicio del proceso de desarrollo y debería incluirse en el documento de requisitos. Tipos: Interfaces de procedimiento: los sistemas o subsistemas ya existentes ofrecen una variedad de servicios a los que se accede invocando a los procedimientos de la interfaz. Estas interfaces a veces se denominan APIs (Interfaz de Programación de Aplicaciones). Estructuras de datos: se refiere a las estructuras de datos que pasan de un sistema a otro. Casi todos los sistemas a desarrollar trabajarán con Bases de Datos, que en algunos casos ya existen y que trabajan con otros sistemas en explotación. Será necesario definir estas nuevas estructuras para el sistema nuevo a desarrollar.

26 El Documento de Requisitos de Software El Documento de Especificación de Requisitos Software ERS es la declaración oficial de qué deben implementar los desarrolladores del sistema. Debe incluir los requisitos de usuario y los de sistema. Los lectores de dicho documento abarca tanto a los altos cargos de la organización cliente (es decir, la que paga por el nuevo sistema) como a los ingenieros responsables de desarrollar el software. Debe ser un documento equilibrado para comunicar los requisitos a los clientes, detallar los requisitos para desarrolladores e ingenieros de pruebas del software, y contener la información relativa a la evolución del software. Debe incluir la información sobre cambios previstos. Esto ayudará a los diseñadores a evitar decisiones de diseño restrictivas y a los ingenieros encargados del mantenimiento del sistema, quienes tendrán que adaptar el sistema a nuevos requisitos.

27 El Documento de Requisitos de Software Tipología de lectores destinatarios del documento ERS Clientes Especifican los requisitos y los leen para verificar que se cumplen sus necesidades. Especificarán cambios si es necesario. Administradores Planifican una oferta por el sistema y el proceso de desarrollo. Ingenieros de sistemas/software Utilizan el SRS para saber QUÉ sistema debe desarrollarse Ingenieros de pruebas Utilizan el SRS para desarrollar las pruebas de validación para el sistema/software. Ingenieros de mantenimiento Utilizan el SRS para comprender el sistema nuevo y las relaciones entre sus partes (subsistemas).

28 El Documento de Requisitos de Software Usuarios del documento ERS La diversidad de posibles usuarios significa que el documento de requisitos tiene que presentar un equilibrio entre la comunicación de los requisitos a los clientes y la definición de los requisitos en el detalle necesario por los desarrolladores. En cualquier caso, en nivel de detalle del documento ERS dependerá del tipo de sistema que se desarrolle y del proceso de desarrollo que se esté empleando. Pueden existir varios escenarios (entre ellos remarcamos dos): Desarrollo subcontratado a una empresa de desarrollo: las especificaciones de los sistemas han de ser claras y muy detalladas Desarrollo dentro de la empresa utilizando un proceso de desarrollo iterativo: el documento puede ser mucho menos detallado y posponer la resolución de ambigüedades en los sucesivas iteraciones del proceso de desarrollo.

29 Ejemplo de ERS: IEEE El Documento de Requisitos de Software Varias organizaciones grandes han definido sus propios estándares para los documentos de requisitos. Entre ellos, el más conocido es el IEEE/ANSI La siguiente trasparencia muestra la estructura propuesta por el IEEE para los ERS. Aunque el estándar no es ideal, contiene un gran número de consejos sobre cómo redactar los requisitos y cómo evitar los problemas descritos en este tema. Es demasiado general como para poder convertirse en un estándar de una organización, pero puede servir de marco de trabajo para adaptarlo a las necesidades particulares de cada organización. La información a incluir en el documento ERS dependerá del tipo de software a desarrollar y se verá fuertemente influenciado por el proceso de desarrollo a utilizado.

30 El Documento de Requisitos de Software Introducción Propósito Alcance del producto Definición, acrónimos y abreviaturas Referencias Descripción del resto del documento. Descripción general Perspectiva del producto Funciones del producto Características del usuario Restricciones generales Suposiciones y dependencias Requisitos específicos IEEE/ANSI Es la parte más sustancial del documento. Incluye los requisitos funcionales, no funcionales y de interfaz. Dada la amplia variabilidad en la práctica organizacional, no es apropiado definir una estructura estándar para esta sección. Apéndices Índice

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

Identificación de requerimientos

Identificación de requerimientos Licenciatura en Informática Administración de requerimientos Identificación de requerimientos Licenciatura en Informática Sirva este material como apoyo a los apuntes de la asignatura Administración de

Más detalles

Especificación de Requisitos según el estándar de IEEE 830

Especificación de Requisitos según el estándar de IEEE 830 Especificación de Requisitos según el estándar de IEEE 830 IEEE Std. 830-1998 22 de Octubre de 2008 Resumen Este documento presenta, en castellano, el formato de Especificación de Requisitos Software (ERS)

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

Especificación de requerimientos

Especificación de requerimientos Especificación de requerimientos 1. Requerimientos funcionales y no funcionales 2. Especificación de requerimientos en lenguaje natural 3. Herramientas de especificación Modelado de datos Diagramas entidad/relación

Más detalles

Introducción En este apartado se va a proporcionar una apreciación global del SRS.

Introducción En este apartado se va a proporcionar una apreciación global del SRS. INTRODUCCIÓN Se pretende desarrollar una aplicación web para la gestión de un restaurante que ofrece espectáculos en fechas determinadas con el fin de poner en práctica los principios de planificación

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3

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

Catálogo General de Requisitos

Catálogo General de Requisitos I.T. INFORMÁTICA DE GESTIÓN 05BM: Fundamentos de Ingeniería del Software 05BP: Diseño de Bases de Datos Catálogo General de Requisitos Copyleft 2009 Departamento de Informática y Sistemas. Licencia Copyright

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

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

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera Departamento de Lenguajes y Sistemas Informáticos INDICE 1. Introducción. 2. Documentación del Proyecto de Fin de

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

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

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

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

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

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

YoExportoAceite.com Buenas prácticas para el Diseño Web Jornada Empresarial Exporta tu aceite con tan sólo un clic

YoExportoAceite.com Buenas prácticas para el Diseño Web Jornada Empresarial Exporta tu aceite con tan sólo un clic YoExportoAceite.com Buenas prácticas para el Diseño Web Jornada Empresarial Exporta tu aceite con tan sólo un clic Lina García Cabrera Departamento Informática Qué se pretende con esta charla 1. Importancia

Más detalles

El modelo de casos de uso. Ingeniería de la Programación

El modelo de casos de uso. Ingeniería de la Programación El modelo de casos de uso Ingeniería de la Programación Prácticas cas 1 Contenidos Introducción RF y RNF Introducción al modelo de RF de UML. Actores y Casos de Uso Modelo de casos de uso Diagrama de contexto

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

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

CAPÍTULO 4 NORMA IEEE 1058.1 PARA LA PLANIFICACIÓN DE PROYECTOS SOFTWARE ESTE DOCUMENTO ES PARTE DEL SIGUIENTE TRABAJO:

CAPÍTULO 4 NORMA IEEE 1058.1 PARA LA PLANIFICACIÓN DE PROYECTOS SOFTWARE ESTE DOCUMENTO ES PARTE DEL SIGUIENTE TRABAJO: ESTE DOCUMENTO ES PARTE DEL SIGUIENTE TRABAJO: La norma IEEE 1058.1: Plan para la Gestión de Proyectos Software realizado por el alumno Ismael Caballero Muñoz-Reja para la asignatura Planificación y Gestión

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

Servidores Donantonio

Servidores Donantonio Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3

Más detalles

El Software. Es lo que se conoce como el ciclo de vida del software.

El Software. Es lo que se conoce como el ciclo de vida del software. El Software Hace referencia a los programas y toda la información asociada y materiales necesarios para soportar su instalación, operación, reparación, y mejora. Para construir un nuevo elemento software

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

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

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales The Anatomy of the Grid Enabling Scalable Virtual Organization Autores : Ian Foster, Carl Kesselman y Steven Tuecke. 2001 GRIDS y Organizaciones Virtuales Permite compartir recursos en forma coordinada

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 Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Especificaciones de casos de uso Universidad Técnica del

Más detalles

Planificación y Control de Proyectos de Software mediante MS Project

Planificación y Control de Proyectos de Software mediante MS Project Práctica 2 Planificación y Control de Proyectos de Software mediante MS Project E n esta práctica vamos a introducirnos en la Planificación y Control de Proyectos de Software mediante herramientas informáticas

Más detalles

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título 3. OBJETIVOS 3.1. Objetivos Objetivos generales del título De acuerdo con lo establecido en el Libro Blanco y el acuerdo del plenario de la Conferencia de Directores y Decanos de Informática (Zaragoza,

Más detalles

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0)

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0) Proyecto: Actualización del Sistema de Información de Muebles Documento: Especificación de s del Sistema de Registro y Control de Muebles ULA (ULA_SRCBM, versión 1.0) Elaborado por: William J. Montilva

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

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Modelado con Casos de Uso (CU)

Modelado con Casos de Uso (CU) Universidad de Congreso Modelado con Casos de Uso (CU) Análisis de Sistemas 2do año Qué es el modelado de Casos de uso? Una forma de capturar el comportamiento deseado del sistema a desarrollar Una manera

Más detalles

Objetivo Las personas que realicen el curso aprenderán a:

Objetivo Las personas que realicen el curso aprenderán a: Objetivo Las personas que realicen el curso aprenderán a: Describir el proceso de desarrollo de software orientado a objetos, lo que incluye las metodologías y los flujos de trabajo de la programación

Más detalles

Historial de Revisiones

Historial de Revisiones Página: 1 Especificación de Requerimientos de Software Plataforma Libre Orientada a Servicios para la Gestión de Trámites a través de Gobierno Electrónico (Actualización FASE I) Historial de Revisiones

Más detalles

SISTEMA DE ESPECIICACION DE REQUERIMIENTOS

SISTEMA DE ESPECIICACION DE REQUERIMIENTOS SISTEMA DE ESPECIICACION DE REQUERIMIENTOS Presentado por: Jefferson Peña Cristian Álvarez Cristian Alzate 10 CONTENIDO 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. AMBITO DEL SISTEMA 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Especificación de requisitos de software

Especificación de requisitos de software Especificación de requisitos de software Apellido : skiker Nombre : Oussama Dni : F466569 Especificación de requisitos de software Contenido CONTENIDO...3 CONTENIDO...3 CONTENIDO...3 1 INTRODUCCIÓN...5

Más detalles

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV 746 Miércoles 5 octubre 2005 Suplemento del BOE núm. 238 CE2.1 Identificar los distintos sistemas de archivo utilizables en un dispositivo de almacenamiento dado para optimizar los procesos de registro

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Ciclo de vida y Requerimientos de software. Laboratorio de Programación

Ciclo de vida y Requerimientos de software. Laboratorio de Programación Ciclo de vida y Requerimientos de software Laboratorio de Programación b d ó Parte 1 Un modelo es una estructura guía, abstracciones, marcos del proceso que pueden se extendidos y adaptados d para crear

Más detalles

Qué es Google Calendar? Qué se puede hacer en Google Calendar?

Qué es Google Calendar? Qué se puede hacer en Google Calendar? Qué es Google Calendar? Google Calendar es una herramienta web 2.0 que permite tener una agenda virtual a la que se puede acceder desde cualquier lugar, en forma gratuita. La característica más interesante

Más detalles

Manual de Lineamientos para sitios web secundarios

Manual de Lineamientos para sitios web secundarios Manual de Lineamientos para sitios web secundarios y de las Facultades Elaborado Febrero 2012 Universidad de Caldas 2012 1. Introducción El comité web trabajó con el consultorio de diseño, jefe de prensa,

Más detalles

Especificación de requisitos de software Proyecto: SIS-WEB (Sistema de Información de Seminarios WEB) Revisión 1.0

Especificación de requisitos de software Proyecto: SIS-WEB (Sistema de Información de Seminarios WEB) Revisión 1.0 Especificación de requisitos de software Proyecto: (Sistema de Información de Seminarios WEB) Revisión 1.0 Tania Isadora Mora Dorance Moreno Luis Yovany Romo Septiembre 2007 Realizado Por: Tania I. Mora

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información 1 1. Definición y objetivos análisis.(del gr. ἀνάλυσις). 1. m. Distinción y separación de las partesdeun todo hasta llegar a conocer sus principios o elementos. 2. m.

Más detalles

IBM InfoSphere Foundation Tools permite ofrecer información de confianza

IBM InfoSphere Foundation Tools permite ofrecer información de confianza ZP06-0517, con fecha 15 de diciembre del 2009 IBM InfoSphere Foundation Tools permite ofrecer información de confianza Índice 1 Visión general 2 Fecha de comercialización prevista 2 Requisitos previos

Más detalles

- Capacidad para dirigir las actividades objeto de los proyectos del ámbito de la informática de acuerdo con los conocimientos adquiridos.

- Capacidad para dirigir las actividades objeto de los proyectos del ámbito de la informática de acuerdo con los conocimientos adquiridos. Competencias generales - Capacidad para concebir, redactar, organizar, planificar, desarrollar y firmar proyectos en el ámbito de la ingeniería en informática que tengan por objeto, de acuerdo con los

Más detalles

En verde están algunas propuestas que entendemos que faltan y que ayudarían a mejorar las fichas sustancialmente.

En verde están algunas propuestas que entendemos que faltan y que ayudarían a mejorar las fichas sustancialmente. NOTAS ACLARATORIAS: Esta ficha de grado es la resultante de las dos reuniones celebradas (9 enero 2009 y 23 de febrero de 2009) por la subcomisión creada desde el MICIIN para debatir las fichas de Grado

Más detalles

www.krontime.com [1] Receta [1] Instrucciones de montaje [2] Instrucciones industriales

www.krontime.com [1] Receta [1] Instrucciones de montaje [2] Instrucciones industriales INNOVATION FOR DIGITAL MANUFACTURING WHITE PAPER WORK INSTRUCTIONS UNA INTRODUCCIÓN AL CONCEPTO QUÉ SON LAS WORK INSTRUCTIONS? ESTA PUBLICACIÓN INFORMATIVA ESTÁ REALIZADA DESDE UNA ÓPTICA GENERAL SOBRE

Más detalles

Tema 4d: Proceso Unificado: Captura de Requisitos

Tema 4d: Proceso Unificado: Captura de Requisitos Tema 4d: Proceso Unificado: Captura de Requisitos Marcos López Sanz Índice Visión general Diagramas UML Proceso de captura de requisitos Enumerar requisitos candidatos Comprender el contexto del sistema

Más detalles

14. Ingeniería de software. Ing. Alejandro Adorjan

14. Ingeniería de software. Ing. Alejandro Adorjan 14. Ing. Alejandro Adorjan : un enfoque en ingeniería de requerimientos Introducción La ingeniería de software es una disciplina que estudia la aplicación de la teoría, el conocimiento y la práctica de

Más detalles

Sistema de Movilidad de Ventas - CLOUD -

Sistema de Movilidad de Ventas - CLOUD - Planificación de un proyecto de construcción de software. Sistema de Movilidad de Ventas - CLOUD - Informe de definición 1 1 RAZÓN Y OPORTUNIDAD DEL PROYECTO.... 3 1.1 LA EMPRESA... 3 1.3 EL NACIMIENTO

Más detalles

MATERIA: Proyecto de Desarrollo de Aplicaciones Multiplataforma

MATERIA: Proyecto de Desarrollo de Aplicaciones Multiplataforma DEPARTAMENTO: Informática MATERIA: Proyecto de Desarrollo de Aplicaciones Multiplataforma NIVEL: 2º Desarrollo de Aplicaciones Multiplataforma 1. Objetivos. Competencias Profesionales, Personales y Sociales

Más detalles

2 EL DOCUMENTO DE ESPECIFICACIONES

2 EL DOCUMENTO DE ESPECIFICACIONES Ingeniería Informática Tecnología de la Programación TEMA 1 Documentación de programas. 1 LA DOCUMENTACIÓN DE PROGRAMAS En la ejecución de un proyecto informático o un programa software se deben de seguir

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

SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: DOCUMENTO DE VISIÓN SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA

SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: DOCUMENTO DE VISIÓN SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA PARA INARGOS LTDA. DOCUMENTO DE VISIÓN VERSIÓN 1.3 BOGOTÁ, COLOMBIA, ENERO 2012

Más detalles

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL Página 1 de 23 CUALIFICACIÓN PROFESIONAL Familia Profesional Nivel 3 Código IFC363_3 Versión 5 Situación RD 1701/2007 Actualización ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS

Más detalles

B.1.4. Características del registro computadorizado de pacientes

B.1.4. Características del registro computadorizado de pacientes B.1.4. Características del registro computadorizado de pacientes Ya se ha considerado que la complejidad, la magnitud y el alcance de los datos y los registros de pacientes son sobrecogedores, en particular

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

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

SUPLEMENTO EUROPASS AL TÍTULO

SUPLEMENTO EUROPASS AL TÍTULO SUPLEMENTO EUROPASS AL TÍTULO DENOMINACIÓN DEL TÍTULO Técnico Superior en Desarrollo de Aplicaciones Multiplataforma --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Más detalles

UNIDAD 3 EL PROCESO DE EDUCCIÓN

UNIDAD 3 EL PROCESO DE EDUCCIÓN UNIDAD 3 EL PROCESO DE EDUCCIÓN 3. EL PROCESO DE EDUCCIÓN... 1 3.1.DEFINICIONES... 1 3.2.EL PROCESO DE EDUCCIÓN... 2 3.3.PARTICIPANTES... 5 3.4.PROBLEMAS DE LA EDUCCIÓN... 7 3.1. Definiciones En los últimos

Más detalles

Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento

Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento Vegega, C., Pytel, P., Ramón, H., Rodríguez, D., Pollo-Cattaneo, F.,

Más detalles

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo 1 CAPITULO 2 ANÁLISIS DEL SISTEMA 1. Introducción Como se definió en el plan del presente proyecto, este será desarrollado bajo la metodología orientada a objetos. El objetivo del análisis será marcar

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S3 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

CENTRO INTEGRAL DE GESTIÓN DEL TRANSPORTE COLECTIVO DEL CONSORCIO REGIONAL DE TRANSPORTES DE MADRID

CENTRO INTEGRAL DE GESTIÓN DEL TRANSPORTE COLECTIVO DEL CONSORCIO REGIONAL DE TRANSPORTES DE MADRID CENTRO INTEGRAL DE GESTIÓN DEL TRANSPORTE COLECTIVO DEL CONSORCIO REGIONAL DE TRANSPORTES DE MADRID Autores de la comunicación J. Dionisio González Ingeniero de Caminos, Canales y Puertos. Responsable

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 3. Requisitos. Univ. Cantabria Fac. de Ciencias Francisco Ruiz

INGENIERÍA DEL SOFTWARE I Tema 3. Requisitos. Univ. Cantabria Fac. de Ciencias Francisco Ruiz INGENIERÍA DEL SOFTWARE I Tema 3 Univ. Cantabria Fac. de Ciencias Francisco Ruiz Objetivos Conocer la naturaleza de los requisitos software. Conocer el proceso de desarrollo de requisitos y sus principales

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 4. Requisitos. Univ. Cantabria Fac. de Ciencias Carlos Blanco, Francisco Ruiz

INGENIERÍA DEL SOFTWARE I Tema 4. Requisitos. Univ. Cantabria Fac. de Ciencias Carlos Blanco, Francisco Ruiz INGENIERÍA DEL SOFTWARE I Tema 4 Requisitos Univ. Cantabria Fac. de Ciencias Carlos Blanco, Francisco Ruiz Objetivos Conocer la naturaleza de los requisitos software. Conocer el proceso de desarrollo de

Más detalles

Su empresa siempre en contacto

Su empresa siempre en contacto Su empresa siempre en contacto Entorno Digital, S.A. (2009). 1/9 Qué es? Solución Web para ofrecer un servicio de valor añadido a sus clientes o empleados. Damos un paso más a la imagen corporativa de

Más detalles

SINAUTO. (Captura Requirimientos) GRUPO 03

SINAUTO. (Captura Requirimientos) GRUPO 03 SINAUTO (Captura Requirimientos) GRUPO 03 Iker Jauregi ikerjauregivicente@hotmail.com Iñigo Arregui bateman2012@gmail.com Javier Arce arcjav@hotmail.com Jorge García. jgfand@gmail.com Patxi Campos.patxi948@wanadoo.es

Más detalles

EXPERTIS Y LA GESTION DE FABRICACION

EXPERTIS Y LA GESTION DE FABRICACION EXPERTIS Y LA GESTION DE FABRICACION Ingeniería Informática DesingSoft, S.L. - 1 - Introducción: Expertis dispone de un conjunto de módulos y aplicaciones orientadas a empresas del sector de Fabricación

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

Administración de proyectos. Organizar, planificar y programar los proyectos de software

Administración de proyectos. Organizar, planificar y programar los proyectos de software Administración de proyectos Organizar, planificar y programar los proyectos de software Administración de proyectos Trata de las actividades que hay que realizar para asegurar que el software se entregará

Más detalles

FAMILIA PROFESIONAL: Informática y Comunicación CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIMEDIA DAM 350 HORAS

FAMILIA PROFESIONAL: Informática y Comunicación CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIMEDIA DAM 350 HORAS FAMILIA PROFESIONAL: Informática y Comunicación CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIMEDIA DAM 350 HORAS Resultados de aprendizaje y criterios de evaluación 1. Identificar la estructura y organización

Más detalles

Ejemplo: agencia de viajes por internet

Ejemplo: agencia de viajes por internet Introducción Modelado de casos de uso Propósito y definición Casos de uso y extracción de requisitos Carácter hipotético de los casos de uso El modelo de casos de uso Notación. Actores y casos de uso.

Más detalles

K2BIM Plan de SQA Versión 1.1

K2BIM Plan de SQA Versión 1.1 K2BIM Plan de SQA Versión 1.1 Historia de revisiones Fecha VersiónDescripción Autor 18/08/2009 1.0 Creación del documento. Diego Píriz 23/08/2009 1.1 Pequeñas correciones. Alan Descoins 1 Contenido 1.

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

Novedades en la versión 3.1

Novedades en la versión 3.1 Novedades en la versión 3.1 1 Introducción... 3 Novedades en la versión 3.1... 3 Planificador de lecciones...3 it s learning mobile...5 Inicio de sesión...5 Interfaz de usuario...6 eportfolio...6 Blog...8

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

Herramientas automáticas y semiautomáticas que apoyan a la aplicación de los métodos.

Herramientas automáticas y semiautomáticas que apoyan a la aplicación de los métodos. Unidad I Introducción a la ingeniería del software y sistemas de información Las economías de todos las paises son cada vez más y más dependientes del Software Importancia del Software 10 Cada vez más

Más detalles

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba Pruebas Pruebas en el PUD Las pruebas del software Diseño de casos de prueba Tipos de prueba Estrategias de prueba 1 2 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos

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

Xperta es una aplicación que no requiere instalar nada en su ordenador, sólo necesita un navegador web y una conexión a Internet.

Xperta es una aplicación que no requiere instalar nada en su ordenador, sólo necesita un navegador web y una conexión a Internet. Xperta es una herramienta ideada como ayuda a los servicios técnicos de cualquier empresa para realizar una gestión de s más clara, rápida y eficiente. Xperta es una aplicación que no requiere instalar

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

Grado en Ingeniería Informática

Grado en Ingeniería Informática Grado en Ingeniería Informática Competencias Generales y trasversales De acuerdo con la resolución del Consejo de Universidades de fecha 3 de marzo de 2009, para obtener este título de grado en ingeniería

Más detalles

Documento de Arquitectura de Software IEEE-1471-2000

Documento de Arquitectura de Software IEEE-1471-2000 Documento de Arquitectura de Software Control del documento IEEE-1471-2000 Proyecto Sistema Restaurant Título Arquitectura del Sistema [v1.0 al 02 de Julio de 2009] Generado por Magister en Informática

Más detalles

Q-flow 3.1: Introducción a Q-flow

Q-flow 3.1: Introducción a Q-flow Q-flow 3.1: Introducción a Q-flow Código del manual: Qf310001ESP Versión: 1.1 Se aplica a: Q-flow 3.1 Última revisión: 13/12/2010 i Q f 3 1 0 0 0 1 E S P v 1. 1 Q - f l o w 3.1 Introducción a Q-flow Urudata

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

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