Académique Documents
Professionnel Documents
Culture Documents
INGENIERIA DE SOFTWARE II
Trayecto III. Trimestre I
Queremos capacitarlos para participar en los grandes proyectos, tanto tcnicos como de gestin, de desarrollo de software que el pas demanda. Queremos DESPERTAR SU INTERES en el desarrollo de software como un mecanismo eficiente para la administracin de nuestro recurso ms valioso: La informacin. Queremos que sean AGENTES DE CAMBIO para potenciar el crecimiento del desarrollo de software en nuestro pas.
QU ES IMPORTANTE?
Es importante la participacin en clase Es importante la puntualidad Es importante mantener nuestros celulares apagados o en modo de vibracin, en clase. -no contestarlos en el saln-
Clases terico-prcticas o consultas del Proyecto Prctico los Lunes de 7:00 a.m. a 9:10 a.m. y los Mircoles de 7:00 a.m. a 8:25 a.m.
Proyecto Prctico
Talleres prcticos relacionados con la materia con el objetivo de:
Tres Evaluaciones parciales terico prcticos. (50%) Un Taller prctico UML (10%).
Humphrey Watts S. (2001). Introduccin al Proceso Software Personal. Addison Wesley. Meyer
JACOBSON Ivar. BOOCH Grady RUMBAUCH James (1999) The United Software Development Process. Rational Software Corporation. Addition Wesley. Larman Craig. (2003) UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. PEARSON Prentice Hall. Segunda Edicin.
Pressman, Roger S. (2005). Ingeniera del Software: Un enfoque prctico; Sexta edicin. McGraw-Hill, Madrid.
Reifer, Donald J. (1993). SOFTWARE MANAGEMENT. IEEE Computer Society Press. Los Alamitos, CA Sommerville, Ian (2006). Ingeniera de Software; Sexta edicin. Pearson Educacin, Mxico. Wang, Yingxu & King, Graham (2000). Software Engineering Processes. Principles and Applications. CRC Press LLC, N. W. Florida.
Wilson, Scott F. Analyzing Requirements and Defining Solution Architectures. Redmond: Microsoft Press, 1999.
Choque Ayala de Joaquin , Americo . Ingeniero de Sistemas www.unpmsm.org Joaquin Deza de Choque, Victoria Rosa. Analista de Sistemas www.unpmsm.org Apuntes de Clases
UN CASO HIPOTTICO
El sistema debe usarse en los 740 puntos ubicados en diferentes partes de la geografa nacional. Los 740 puntos de acceso en todo el pas, van a tener conectividad? Si, todos van a tener banda ancha. Qu tipo de arquitectura estn esperando? Nosotros hemos pensado en un sistema WEB Pero van a tener conectividad, las 24 horas? Bueno sabemos que en algunas partes es difcil y deben pensar en eso. Puede ser una parte WEB y una no WEB. !Por supuesto!. Una parte Cliente/Servidor y una WEB. S, me parece bien, porque en realidad no hace falta que funcione todo si no hay conexin; as que la parte cliente/servidor podra ser ms pequea que la parte WEB. Perdn, porqu quieren un sistema WEB?
REFLEXIONES
La funcionalidad es slo una parte de lo que el sistema puede hacer. Para definir la arquitectura debemos CONOCER los requerimientos o atributos de calidad, que nos hablan de las caractersticas especficas que el sistema tendr. Ejemplo: Flexibilidad, transportabilidad, usabilidad, etc. Los atributos de calidad muchas veces se afectan entre s. Por ejemplo portabilidad vs. performance o flexibilidad vs. performance.
Por lo general estn pobremente especificados, o no especificados (un requerimiento que no es medible no es implementable). En general no se analizan sus dependencias. La importancia de los atributos varia con el dominio para el cual se construye el software. El ingeniero de software, generalmente no identifica las restricciones asociadas a los atributos de calidad que identifica.
La arquitectura de un sistema es un medio para alcanzar los atributos de calidad deseados, no el fin.
El atributo de mayor importancia suele ser la flexibilidad: Facilidad de cambios.
Valorar la importancia de construir software de calidad Caracterizar los requerimientos de software. Identificar los problemas asociados a los requerimientos de software Diferenciar entre el espacio del problema y el espacio de solucin.
Reconocer la importancia del Modelado de Negocios y de la Ingeniera de Requerimientos en el proceso de desarrollo de software de calidad.
QU ES CALIDAD?
Propiedad o conjunto de propiedades inherentes a una cosa, que permite apreciarla como igual, mejor o peor que las restantes de su especie.
Diccionario de la Real Academia Espaola
Totalidad de las caractersticas de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades expresadas o implcitas.
NORMA UNE 66-001-92 Traduccin de ISO 8402 [AENOR, 1992]
ORGENES DE LA CALIDAD
Calidad Programada
Calidad Realizada
Calidad Necesaria
CALIDAD DE SOFTWARE
Los requisitos [requerimientos] especificados. Las necesidades o expectativas del cliente o usuario.
(IEEE Std. 610.1990) [IEEE, 1993] (Cursivas nuestras)
Concordancia del software producido con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente.
[Pressman, 1998]
DESCRIPCIN Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades especficas. Las funciones son aquellas que satisfacen lo indicado o implica necesidades.
Idoneidad
Exactitud Interoperabilidad Seguridad Cumplimiento de normas. Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestacin bajo condiciones establecidas durante un perodo de tiempo establecido.
FIABILIDAD
Madurez Recuperabilidad Tolerancia a fallos Un conjuntos de atributos relacionados con el esfuerzo necesitado para el uso, y en la valoracin individual de tal uso, por un establecido o implicado conjunto de usuarios.
USABILIDAD
* Un atributo es una entidad la cual puede ser verificada o medida en el producto software.
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"
DESCRIPCIN Conjunto de atributos relacionados con la relacin entre el nivel de desempeo del software y la cantidad de recursos necesitados bajo condiciones establecidas.
Comportamiento en el tiempo Comportamiento de recursos Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software.
MANTENIBILIDAD
Estabilidad Facilidad de anlisis Facilidad de cambio Facilidad de pruebas Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra.
PORTABILIDAD
Capacidad de instalacin
Capacidad de reemplazamiento
Adaptabilidad
Se estima que, del total de proyectos software grandes emprendidos, un 28% fracasan, un 46% caena en severas metodologas o procesos Nosotros nos comprometemos mejorar las modificaciones que lo retrasan y un 26% son nuevas y concientizarnos en su utilizacin de desarrollo, o crear totalmente exitosos. Cuando un proyecto fracasa, rara vez es debido a fallas tcnicas, la principal causa de fallos adecuada. es la falta de aplicacin de una buena metodologa o proceso y fracasos de desarrollo.
Serie de instrucciones abstractas de alto nivel de un servicio o de un sistema, limitado a detallar en una especificacin.
(Abbott, 1986 )
Los requerimientos EXPRESAN lo que una aplicacin Propiedad que debe hacer paracumplir o las necesidadessistema o sistema debe exhibir, satisfacer satisfacer un desarrollado o clientes o usuarios. No un problema particular de sus adaptado para resolver intentab expresar cmo lograr estas funciones Aspecto de un sistema o una descripcin de aquello que el sistema es capaz de hacer a fin de cumplir su propsito
(Pfleeger, 1998) (Sawyer y Kotonya, 2001)
CONTEXTO DE SISTEMA
El trmino sistema se refiere a: Un sistema de software
- Software de sistema -- Ejemplo: Sistemas operativos, compilador, interpretes, DBMS, entre otros.
-
- Software de desarrollo
-
- Aplicacin de software
-
Un sistema de hardware-software
-
Un sistema de negocios
Se refiere al dominio de aplicacin donde un sistema de software o H/S opera. Ejemplos: -- El sistema contable de una empresa
-
- El vehculo donde opera el GPS. -- El proceso industrial controlado por un controlador automtico
-
Sistema de Software
CASO DE ESTUDIO
Un sistema de comercio electrnico para monedas antiguas.
RAFMA, C.A. es una empresa especializada en la compra y venta de monedas antiguas de todo el mundo, con ms de 10 aos en el mercado. Durante su existencia, RAFMA ha conformado una de las ms completas colecciones de monedas antiguas a nivel mundial. Para operar RAFMA enva catlogos impresos de su coleccin a clientes selectos en todo el mundo, por los cuales deben cancelar $10. Los pedidos se hacan por correo electrnico y las monedas eran despachadas por correo courier a los clientes. Como estrategia para fortalecer el negocio RAFMA decidi cambiar su modelo de negocios por uno basado en comercio electrnico, para lo cual se contrat el desarrollo de la aplicacin web: oldcurrency.com
CASO DE ESTUDIO
Un sistema de comercio electrnico para monedas antiguas (oldcurrency.com).
Oldcurrency.com es una aplicacin que permite la comercializacin de monedas antiguas de y desde cualquier parte del mundo.
Algunos requerimientos
Explcitos: Los requerimientos establecidos explcitamente se reflejan en el documento de Especificacin de Requerimientos del Sistema (ERS)
Requerimientos funcionales: Funciones a realizar por el software. Requerimientos no funcionales: Requerimientos depermiten Los estndares y las normas de desarrollo seguridad, rendimiento, interfaz,que se consiga una alta calidad tcnica. las opciones de solucionar el etc. Describen restricciones que limitan problema. Restricciones cuantitativas o precisin. Pseudorequerimientos: Impuestos por el cliente que restringen la implementacin del sistema
Implcitos: Los requerimientos implcitos no aparecen en la ERS, pero si no se cumplen con ellos la calidad del software queda en entredicho.
Requerimiento
Funcional
No Funcional
De Negocios
Del Usuario
Del Sistema
De Comportamiento
Restriccin
Atributo de Calidad
De Interfaz
Regla de Negocio
Requerimientos de Usuarios
Expresan que objetivos, metas o necesidades la empresa espera alcanzar con el uso del sistema.
Ejemplos:
La empresa RAFMA, C.A. quiere abrir su mercado a cualquier usuario interesado en la adquisicin de monedas antiguas. La aplicacin oldcurrency.com deber contribuir a abrir el mercado e incrementar el volumen de ventas anuales de monedas antiguas.
Requerimientos de Comportamiento
Son de alto nivel para productos que tienen componentes H/S. Se expresan desde la perspectiva del sistema H/S que contiene la aplicacin. Asumen que la el software es parte de un sistema mayor. Ejemplos:
La aplicacin oldcurrency.com deber enviar un mensaje electrnico cada vez que RAFMA, C.A. disponga de una moneda antigua de su inters.
Ejemplos:
El sistema oldcurrency.com, deber permitirle al cliente efectuar el pago de su pedido en lnea, usando cualquier tarjeta de crdito.
El sistema deber permitirle al usuario visualizar la moneda o monedas seleccionadas por el usuario de los contenidos en el catlogo de monedas.
Restricciones
Atributos de Calidad
Expresan las limitaciones que se le imponen al desarrollo del sistema. Describen aspectos tales como:
Plataforma de desarrollo y operacin. Uso de estndares, prcticas, mtodos de desarrollo. Tiempo mximo de desarrollo. Costo mximo de desarrollo.
Ejemplos:
oldcurrency.com, deber tener una confiabilidad mayor a 95%. oldcurrency.com deber ser fcil de usar..
Ejemplos:
oldcurrency.com deber ser una aplicacin web que debe ser desarrollado con las siguientes herramientas: Plataforma LAMP: Linux, Apache, MySql y PHP. Tiempo mximo de desarrollo 6 meses. Costo mximo de desarrollo 50.000 Bs.
Reglas de Negocio
De Interfaz
Expresan todas las regulaciones que la aplicacin deber acatar, entre otras:
Regulaciones gubernamentales decretos, providencias, etc.) (Leyes,
Expresan las caractersticas de la interaccin del usuario con el sistema. Se dividen en:
Requerimientos de interfaz grfica (GUI). Describen las propiedades generales de la interfaz grfica que permitir la interaccin entre el usuario y el sistema. Requerimientos de interfaces con otros sistemas. Describen con qu o cmo la aplicacin interactuar con otras aplicaciones de software o sistemas de hardware.
Regulaciones de la empresa (Polticas, normas, procedimientos, estrategias, etc.) Regulaciones propias de la aplicacin (Estndares, metodologa que debe seguirse, algoritmos o clases que deben usarse).
Ejemplos:
oldcurrency.com deber desarrollarse usando la metodologa RUP. Un cliente puede descargar gratuitamente las actualizaciones de un catlogo adquirido por el, durante los dos primeros meses a partir de la publicacin de la actualizacin.
Ejemplos:
oldcurrency.com deber usando una interfaz web. ser implementada
Requerimientos Funcionales
Requerimientos No Funcionales
Establecen:
Los objetivos de negocio respecto al sistema. Los servicios que el sistema debe proporcionarle al sistema.
la del
Determinan la funcionalidad del sistema. Determinan lo que el sistema deber hacer, es decir:
Su comportamiento. Su interaccin con los usuarios y su dominio de aplicacin (negocio) Sus respuestas a eventos.
Completos. Todo lo que el software tiene que hacer est recogido en el conjunto de
requerimientos, es decir, deben describir toda la funcionalidad que el sistema deber implementar.
No ambiguos. Cada requerimiento debe tener una sola interpretacin. debiendo poder
expresarse de una manera sencilla, clara y sin ambiguedades usando: - Lenguaje natural (espaol). - Lenguajes grficos (UML) - Lenguajes formales (Notacin Z).
Correctos. Cada requerimiento establecido debe representar algo requerido por el usuario
para el sistema que se construye y ser validado por este.
Trminos conflictivos: Si dos trminos se usan en contextos diferentes para la misma cosa.
Caractersticas en conflicto: Si en dos partes de la ERS se pide que el producto muestre comportamientos contradictorios.
Inconsistencia temporal: Si dos partes de la ERS piden que el producto obedezca restricciones de tiempo contradictorias.
EJEMPLOS DE REQUERIMIENTOS
1. Hasta 15 objetos se dibujarn dentro de la misma ventana. Si excede el nmero se utilizar una ventana diferente. 2. El sistema tendr una interfaz de usuario sencilla de utilizar. 3. Los usuarios deben escribir su contrasea en un tiempo menor de 15 segundos desde que escribieron su nombre de usuario. 4. El tiempo de respuesta para todos los comandos ser menor de 0.1 segundos. El tiempo de respuesta para el comando DELETE ser menor de 5 segundos. 5. El sistema tendr un tiempo de respuesta aceptable.
1. El software normalmente est integrado por muchos componentes. En la mayor parte de los casos, es difcil para el ingeniero de software entender todos estos componentes al mismo tiempo. 2. El costo de cambiar los requerimientos crece a medida que avanza el proyecto. Reparar un requisito omitido o mal especificado se ha establecido, en forma proporcional, como sigue:.
$3 durante la codificacin.
$5 durante la prueba de unidades. $20 durante la validacin. $100 despus que el sistema ha entrado en produccin.
1. Los mtodos tradicionales de desarrollo de software importancia del problema y su anlisis, debido a que: - Se centran en la solucin y sus requisitos.
subestiman
la
ESPACIO DE PROBLEMA
INGENIERIA DE REQUERIMIENTOS
MN
IR
El Modelado de Negocios (MN) es un proceso a travs del cual se representa el dominio de una aplicacin. Es el mecanismo por el cual un negocio trata de generar ingresos y/o beneficios. Es un resumen de cmo una organizacin planifica servir a sus clientes. En aplicaciones empresariales el MN representa diferentes aspectos del dominio de la aplicacin. - El dominio es denominado SISTEMA DE NEGOCIOS. El MN identifica y representa aspectos del sistema de negocios, tales como: - Objetivos de la organizacin. - Procesos de Negocio y sus actividades. - Reglas de Negocio.
El Problema
Sub-modelos
Objetivos
Procesos de Negocio
Objetos de Negocio
Actores
Reglas de Negocio
Eventos
Requerimientos Funcionales
Requerimientos No Funcionales
La Solucin
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"
En la fase de Ingeniera de Requerimientos, el Modelo de Negocios es usado para: - Entender el proceso de negocio actual y establecer sus problemas de informacin. - Descubrir las necesidades que los usuarios tienen. - Se analiza cada proceso para determinar que informacin requiere. - Facilitar la definicin y especificacin de requerimientos funcionales. - Los diagramas de actividades permiten identificar aquellas acciones que se desean automatizar. - Caracterizar el nuevo proceso de negocios y su flujo de trabajo.
La IR se encarga de establecer:
- Principios - Modelos - Mtodos
- Mejores prcticas
- Tcnicas y - Herramientas automatizadas que contribuyan a mejorar la definicin y especificacin de los requerimientos.
- Transformar la definicin de necesidades en una descripcin completa y precisa de requerimientos denominada: Especificacin de Requerimientos de Software (ERS). - Lograr un entendimiento comn, entre usuarios y desarrolladores, de los
requerimientos que debe satisfacer el sistema.
tiene
tres
elementos
El Producto: Qu se hace?
Documento de Definicin de Requerimientos (DDR) Describe los requerimientos de alto nivel desde la perspectiva de los clientes y/o usuarios. Est orientado usuarios. a los clientes y/o
Documento de Especificacin de Requerimientos (DDR) Describe detalladamente los requerimientos contenidos en el DDR.
Existen varios estndares y modelos (plantillas o patrones) que ayudan a elaborar el DR. El estndar IEEE 830-1993 - Propuesto por el Institute of Electrical and Electronics Engineers
(IEEE)
II.
Descripcin general
1. Perspectivas del producto - Interfaces del sistema - Interfaces del usuario - Interfaces de H/S - Interfaces de comunicacin
3. Requisitos de desempeo
4. Restricciones de diseo 5. Atributos de calidad del sistema 6. Otros requisitos
- Restricciones de memoria
- Operaciones - Requisitos de adaptacin del sitio.
Descripcin: Calcular el promedio diario, mensual y anual ingresos por concepto de venta de monedas antguas de cada una de las casa sucursales de RAFMA en los cinco continentes. Justificacin del requisito Es necesario elaborar los reportes de ingresos diarios, mensuales y anuales de venta de monedas antguas de cada sucursal. Fuente (que interesado lo propone) Unidad en la que se origina: Pedro Prez Departamento de Ventas Criterios de Validacin Los valores obtenidos se compararan con los obtenidos en aos pasados para determinar si hay inconsistencias. Grado de satisfaccin del usuario: Grado de insatisfaccin del interesado: 3 5 Dependencias (qu requisitos dependen de este): Conflictos (qu requisitos son incompatibles con este) 35, 56 Documentos de Soporte: Historico de cambios: Manual de Ventas 15/07/2010 Proyecto: oldcurrency.com Analista: Rafael Matos
Plantilla Volere
ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (5) El Proceso La Ingeniera de Requerimientos consta de cinco grandes procesos:
Capturan, organizan, filtran y documentan los requisitos Obtencin de Requisitos Anlisis de Requisitos Especificacin de Requisitos
Procesos Tcnicos
Validacin de Requisitos
Procesos de Gestin
Gestin de Requisitos Controlan y apoyan a los procesos tcnicos