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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

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

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

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

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

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA METODOLOGÍA DE VERIFICACIÓN Y VALIDACIÓN DE ADQUISICIÓN EN LA ETAPA DE ANÁLISIS DE SISTEMAS DE INFORMACIÓN DESARROLLADOS A LA

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

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

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

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

Actividad ASI 1: Definición del Sistema

Actividad ASI 1: Definición del Sistema Actividad ASI 1: Definición del Sistema Descripción del sistema, delimitando su alcance Establecimiento de interfaces con otros sistemas Identificación de usuarios representativos ASI 1.1 Determinación

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

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

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

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA DESARROLLO DE UN SISTEMA DE CONSTRUCCIÓN DE WEBS 2.0 E INTEGRACIÓN CON UN SISTEMA DE VENTA DE DOMINIOS Tesis para optar por el

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

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

UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL INDUSTRIAL

UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL INDUSTRIAL UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL INDUSTRIAL DISEÑO E IMPLEMENTACIÓN DE UN SUB-SISTEMA DE GESTIÓN DE INFORMACIÓN PARA EL ÁREA DE OPERACIONES DE LA EMPRESA COPEFRUT

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

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

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

ÍNDICE INTRODUCCIÓN 3 EJEMPLOS DE PREGUNTAS DE RESOLUCION DE PROBLEMAS 4

ÍNDICE INTRODUCCIÓN 3 EJEMPLOS DE PREGUNTAS DE RESOLUCION DE PROBLEMAS 4 ÍNDICE Pág. INTRODUCCIÓN 3 EJEMPLOS DE PREGUNTAS DE RESOLUCION DE PROBLEMAS 4 Climatizador 5 Billetes 8 Tráfico 12 Robot de limpieza 15 Reproductor MP3 18 Fiesta de cumpleaños 22 2 INTRODUCCIÓN En el presente

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

GUÍA DE BUENAS PRÁCTICAS PARA COMPLETAR LAS PLANTILLAS DE REQUERIMIENTOS PARA PROYECTOS DE EXPLOTACION DE INFORMACIÓN

GUÍA DE BUENAS PRÁCTICAS PARA COMPLETAR LAS PLANTILLAS DE REQUERIMIENTOS PARA PROYECTOS DE EXPLOTACION DE INFORMACIÓN Reporte Técnico GEMIS-TD-20-0-RT-202-0 GUÍA DE BUENAS PRÁCTICAS PARA COMPLETAR LAS PLANTILLAS DE REQUERIMIENTOS PARA PROYECTOS DE EXPLOTACION DE INFORMACIÓN Ariel Deroche & María Florencia Pollo-Cattaneo

Más detalles

1. INTRODUCCIÓN 1.1 PROPÓSITO DEL DOCUMENTO

1. INTRODUCCIÓN 1.1 PROPÓSITO DEL DOCUMENTO 1. INTRODUCCIÓN El presente documento describe la especificación de requerimientos de software para el proyecto titulado: Sistema de Análisis Crediticio del Programa de Crédito Automotriz en Arrendamiento

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

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

COUNTSTAR: ADMINISTRACIÓN Y GESTIÓN DE EMPRESA

COUNTSTAR: ADMINISTRACIÓN Y GESTIÓN DE EMPRESA Trabajo fin de carrera INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Facultad de Matemáticas Universidad de Barcelona COUNTSTAR: ADMINISTRACIÓN Y GESTIÓN DE EMPRESA Óscar Llorente Lucía Director/a: Dra.

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

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

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

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

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

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

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego TFC Ingeniería de Software Alumno: Halyna Klachko Consultor: Juan José Cuadrado Gallego Índice 1. Identificación del proyecto..5 1.1 Introducción...5 1.2 Objetivos del proyecto..5 1.3 Descripción general..5

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

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

- 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

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

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

DISEÑO DE UN SISTEMA INFORMÁTICO PARA LA

DISEÑO DE UN SISTEMA INFORMÁTICO PARA LA DISEÑO DE UN SISTEMA INFORMÁTICO PARA LA ADMINISTRACIÓN DE COMPRAS DE ALMACÉN INITE, S.C. no es responsable del contenido, de la veracidad de los datos, opiniones y acontecimientos vertidos en el presente

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

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

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

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

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

Correo electrónico. Correo electrónico

Correo electrónico. Correo electrónico Correo electrónico El correo electrónico o «e-mail» es la herramienta más antigua y a la vez más útil de Internet. Permite enviar y recibir mensajes a cualquiera de los/as usuarios/as de Internet en el

Más detalles

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3 Historia de revisiones Fecha Versión Descripción Autor 17/08/2005 1.0 Se hace la

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

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

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

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

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

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

Ingeniería Software software. Análisis de requisitos y especificación de una aplicación

Ingeniería Software software. Análisis de requisitos y especificación de una aplicación Ingeniería Software software 4º Físicas 4º de Físicas Análisis de requisitos y especificación de una aplicación José M. Drake Computadores y Tiempo Real Santander, 1 Ingeniería de Programación (4º Físicas)

Más detalles

Fundamentos del diseño de software

Fundamentos del diseño de software Fundamentos del diseño de software El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería. Definición de diseño según Taylor Proceso de aplicar distintas técnicas

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción El WWW es la mayor fuente de imágenes que día a día se va incrementando. Según una encuesta realizada por el Centro de Bibliotecas de Cómputo en Línea (OCLC) en Enero de 2005,

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

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: DETERMINACIÓN DE REQUERIMIENTOS ENTREVISTAS, CUESTIONARIOS, OBSERVACIONES JOINT APPICATION DESIGN (JAD) PROTOTIPOS, CASE, GROUPWARE Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza

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

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

ESET Remote Administrator 6. Version 6.0 Product Details

ESET Remote Administrator 6. Version 6.0 Product Details ESET Remote Administrator 6 Version 6.0 Product Details A pesar de que ESET Remote Administrator 6.0 es el sucesor de ESET Remote Administrator V5.x, representa un gran adelanto, ya que constituye una

Más detalles

Trabajo de Investigación

Trabajo de Investigación Escuela Técnica Superior de Ingeniería Informática Departamento: Ingeniería de Software y Sistemas Informáticos Trabajo de Investigación Arquitecturas Software: Gestión de los atributos de calidad de un

Más detalles

Listado de comprobación para informes de Evaluación de Tecnologías Sanitarias. Introducción

Listado de comprobación para informes de Evaluación de Tecnologías Sanitarias. Introducción Listado de comprobación para informes de Evaluación de Tecnologías Sanitarias Introducción Objetivo INAHTA ha diseñado este listado de comprobación con el propósito de facilitar la obtención de información

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

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

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A. Cátedra : Sistemas de Información Administrativa S.I.A. Escuela de Contadores Auditores Tema: Ingeniería del Software SLC -ERS Relator: Sr. Eduardo Leyton G Ingeniería de Software (IS) Es una disciplina

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