Análisis y diseño de un Software

Texto completo

(1)Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Universidad Nacional de Trujillo. UNIVERSIDAD NACIONAL DE TRUJILLO FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. IC. A. S. ESCUELA ACADEMICO-PROFESIONAL DE INFORMATICA. INFORME DE TESINA PARA OPTAR EL TITULO DE: INGENIERO INFORMATICO. TITULO:. AUTOR: BR. LESLY DEL PILAR RODRIGUEZ PINILLOS. B. IB. LI. O. T. E. “ANÁLISIS Y DISEÑO DE SOFTWARE”. ASESOR: Ms. Ing CARLOS E. CASTILLO DIESTRA, Dr(c). TRUJILLO – PERU 2012 1 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(2) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Universidad Nacional de Trujillo. AGRADECIMIENTOS. Quiero empezar agradeciendo principalmente a Dios por su infinita bondad y amor, quien. S. me dio salud para ver mi esfuerzo compensado con el resultado obtenido.. IC. A. A mis familiares y amigos, a quienes deje de dedicarles tiempo desde que emprendí este. necesitaba.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. camino. Gracias por su paciencia y por darme su apoyo incondicional cuando más lo. También quiero agradecer a las personas que me encaminaron a lo largo de toda la investigación, especialmente a mi asesor el ing. Carlos Castillo Diestra, quien me proporcionó los lineamientos necesarios para alcanzar mi objetivo.. A todas y cada una de las personas que me brindaron su apoyo y que sin su cooperación este trabajo no hubiese sido posible. Muchas gracias.. B. IB. LI. O. T. E. Lesly Rodríguez Pinillos. 2 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(3) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. INDICE GENERAL RESUMEN .........................................................................................................................10 INTRODUCCION ...............................................................................................................11 CAPITULO I: PLANTEAMIENTO DEL ESTUDIO ...............................................................12 1.1 Especificación del campo de estudio............................................................................12 1.2Justificación del Trabajo ................................................................................................12 1.3Objetivos .......................................................................................................................13. A. S. CAPITULO II: INGENIERIA DE REQUERIMIENTOS .......................................................14. IC. 2.1Requerimientos funcionales y no funcionales................................................................16. S. 2.1.1 Requerimientos Funcionales ..................................................................................17. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. 2.1.2 Requerimientos No funcionales .............................................................................18 2.1.3 Requerimientos del dominio ...................................................................................21 2.2. Proceso de la Ingeniería de requerimientos ...........................................................21. 2.2.1 Estudio de Viabilidad ............................................................................................22 2.2.2 Obtención y Análisis de requerimientos ................................................................24 2.2.3 Especificación de Requerimientos ........................................................................28 2.2.4 Validación de Requerimientos ..............................................................................29 2.2.5 Documento de Requerimientos ............................................................................31 2.3. Técnicas y Herramientas utilizadas en la Ingeniería de requerimientos..................33. 2.3.1 Técnicas utilizadas en las actividades de IR .........................................................33 Entrevistas y Cuestionarios ......................................................................33. 2.3.1.2. Sistemas existentes .................................................................................34. 2.3.1.3. Lluvia de Ideas .........................................................................................34. Casos de Uso ..........................................................................................36. O. 2.3.1.5. Prototipos .................................................................................................35. T. 2.3.1.4. E. 2.3.1.1. LI. 2.3.2 Herramientas Automatizadas para la administración de Requerimientos .............36. IB. 2.3.2.1. Importancia de la Ingeniería de requerimientos ......................................................39. B. 2.4. RequisitePro ............................................................................................37. CAPITULO III: MODELADO DEL ANALISIS ......................................................................41 3.1. Análisis de Requisitos ............................................................................................41. 3.1.1 Objetivos del Modelo de Análisis ..........................................................................42 3.1.2 Reglas Prácticas de Análisis ................................................................................43 3.1.3 Análisis del Dominio .............................................................................................44 3.2. Enfoques de modelado del Análisis ........................................................................45. 3.3. Conceptos del Modelado de Datos.........................................................................46. 3.3.1 Objeto de Datos ...................................................................................................46 3 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(4) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 3.3.2 Atributos ...............................................................................................................47 3.3.3 Relaciones ...........................................................................................................47 3.3.4 Cardinalidad y modalidad .....................................................................................48 3.3.5 Diagramas entidad – Relación..............................................................................49 3.4. Análisis Orientado a Objetos ..................................................................................50. 3.5. Modelado basado en escenarios ............................................................................50. 3.5.1 Escritura de casos de Uso ....................................................................................50. S. 3.5.2 Desarrollo de un diagrama de Actividad ...............................................................55. A. 3.5.3 Diagramas de Carril..............................................................................................58 Modelado Orientado al Flujo ..................................................................................59. IC. 3.6. S. 3.6.1 Creación de un modelo de flujo de datos..............................................................59. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. 3.6.2 Creación de un modelo de control de flujo............................................................61 3.6.3 Especificación de control ......................................................................................62 3.6.4 Especificación de proceso ....................................................................................63 3.7. Modelo basado en Clases ......................................................................................64. 3.7.1 Identificación de clases de análisis .......................................................................64 3.7.1 Especificación de atributos ...................................................................................65 3.7.2 Definición de operaciones ....................................................................................65 3.7.3 Modelado de Clase – Responsabilidad – Colaborador (CRC) ..............................66 3.7.4 Asociaciones y dependencias ..............................................................................71 3.7.5 Paquetes de análisis ............................................................................................73 3.8. Modelado del Comportamiento ..............................................................................75. E. 3.8.1 Identificación de eventos en el caso de uso .........................................................75. T. 3.8.2 Representaciones de estado ................................................................................76 El diccionario de Datos...........................................................................................79. O. 3.9. Proceso y Calidad del Diseño ................................................................................83. 4.2. Principios del Diseño ..............................................................................................85. B. IB. 4.1. LI. CAPITULO IV: INGENIERÍA DEL DISEÑO ........................................................................82. Conceptos del Diseño ............................................................................................87. 4.3. 4.3.1 Abstracción ..........................................................................................................88 4.3.2 Arquitectura ..........................................................................................................89 4.3.3 Patrones ...............................................................................................................90 4.3.4 Modularidad .........................................................................................................90 4.3.5 Ocultación de Información ....................................................................................92 4.3.6 Independencia Funcional .....................................................................................93 4.3.7 Refinamiento ........................................................................................................94 4.3.8 Refabricación .......................................................................................................95 4 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(5) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 4.3.9 Clases de diseño ..................................................................................................95 4.4. El modelado de Diseño ..........................................................................................98. 4.4.1 Elementos del diseño de Datos ..........................................................................100 4.4.2 Elementos del diseño Arquitectónico ..................................................................101 4.4.3 Elementos del diseño de interfaz ........................................................................101 4.4.4 Elementos del diseño al nivel de componentes ..................................................103 4.4.5 Elementos de diseño al Nivel de Despliegue ......................................................104 Arquitecturas de Software ....................................................................................105. S. 4.5. A. 4.5.1 Calidad del Software ..........................................................................................106. IC. 4.5.2 Arquitectura de Software ....................................................................................107 Importancia de la arquitectura de software .............................................108. 4.5.2.2. Componentes, conectores y relaciones ..................................................110. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. 4.5.2.1. 4.5.3 Estilos y Patrones...............................................................................................112 4.5.3.1. Estilo Arquitectónico ...............................................................................113. 4.5.3.2. Patrón Arquitectónico .............................................................................116. 4.5.3.3. Patrón de Diseño ...................................................................................119. 4.5.4 Vistas Arquitectónicas ........................................................................................122 4.5.5 Notaciones .........................................................................................................127 4.5.6 Evaluación de Arquitecturas de software ............................................................130 4.5.7 Técnicas de evaluación de arquitecturas de software.........................................134 4.5.7.1. Evaluación basada en escenarios ..........................................................135. 4.5.7.1.1 Utility Tree...........................................................................................136. T. Evaluación basada en simulación ..........................................................141. O. 4.5.7.2. E. 4.5.7.1.2 Perfiles ................................................................................................137. LI. 4.5.7.3 4.5.7.4. Evaluación basada en modelos matemáticos.........................................142 Evaluación basada en experiencia .........................................................144. B. IB. 4.5.8 Métodos de evaluación de arquitecturas de software .........................................145 4.5.8.1. Software Architecture Analysis Method (SAAM) .....................................145. 4.5.8.2. Architecture Trade-off Analysis Method (ATAM).....................................147. 4.5.8.3. Active Reviews for Intermediate Designs (ARID)....................................149. 4.5.8.4. Modelo de Negociación WinWin.............................................................152. 4.5.8.5. Cost-Benefit Analysis Method (CBAM) ...................................................152. 4.5.8.6. Método Diseño y Uso de Arquitecturas de Software propuesto por Bosch. (2000). 154. 4.5.8.7. Método de comparación de arquitecturas basada en el modelo ISO/IEC. 9126 adaptado para arquitecturas de software ........................................................155 5 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(6) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. 4.5.8.8. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Comparación entre métodos de evaluación ...........................................155. 4.5.9 Herramientas de análisis, diseño y evaluación de arquitecturas de software. .....157 CAPITULO V: APLICANDO EL ANALISIS Y DISEÑO DE SOFTWARE ..........................161 5.1. Sistema para Gestión de Artículos Deportivos LSI 03 ..........................................161. 5.1.1Propósito, alcance y objetivos ..............................................................................161 5.1.2Necesidades y restricciones .................................................................................162 5.1.3Posicionamiento ...................................................................................................162 Oportunidad de negocio………………………………………………………162. 5.1.3.2. Sentencia que define el negocio ............................................................163. 5.1.3.3. Sentencia que define la posición del software ........................................163. IC. A. S. 5.1.3.1. S. 5.1.4 Beneficios del software.......................................................................................164. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. 5.1.5 Desarrollo del Software utilizando la metodología RUP ......................................164 5.1.5.1. Modelado del Negocio de la Empresa de Deportes Lsi 03 .....................164. 5.1.5.2. Requisitos ..............................................................................................169. 5.1.5.2.1 Casos de Uso con Rational Rose .......................................................169 5.1.5.2.2 Gestión de requisitos con Requisite Pro..............................................178 Análisis/Diseño ......................................................................................185. 5.1.5.3. 5.1.5.3.1 Modelo de Análisis/Diseño: Diagrama de Clases ................................185 5.1.5.3.2 Modelo de Datos: Modelo Relacional ..................................................186 5.1.5.4. Prototipos de interfaces de usuario ........................................................186. 5.1.5.4.1 Interfaces Comunes ............................................................................186. E. 5.1.5.4.2 Gestión de Almacén ............................................................................188. O. T. 5.1.5.4.3 Gestión de Ventas ..............................................................................193 Componentes/Despliegues ....................................................................194. LI. 5.1.5.5. IB. 5.1.5.5.1 Diagrama Global de Paquetes ............................................................195. B. 5.1.5.5.2 Diagrama de Componentes Comunes ................................................196 5.1.5.5.3 Diagrama de Componentes Almacén..................................................196 5.1.5.5.4 Diagrama de Componentes Ventas ....................................................197 5.1.5.5.5 Diagrama de Despliegue.....................................................................197. CAPITULO VI: CONCLUSIONES, APORTES Y SUGERENCIAS ....................................198 6.1 Conclusiones .............................................................................................................198 6.2 Aportes ......................................................................................................................198 6.3 Recomendaciones .....................................................................................................199 REFERENCIAS ...............................................................................................................200 6 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(7) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. INDICE DE FIGURAS Figura 1: Requerimientos del usuario y del sistema. ............................................................15 Figura 2: Lectores de los diferentes tipos de especificaciones. ............................................16 Figura 3: Usuarios de un documento de requerimientos.......................................................16 Figura 4: Tipos de requerimientos no funcionales. ...............................................................20 Figura 5: El proceso de Ingeniería de Requerimientos .........................................................22. A. S. Figura 6: El proceso de Obtención y análisis de Requerimientos .........................................27. IC. Figura 7: Modelo de análisis como un puente entre la descripción del sistema y el modelo de diseño. .................................................................................................................................42. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. Figura 8: La estructura del Modelo de Análisis. ...................................................................42 Figura 9: Entrada y Salida para el análisis del dominio.........................................................45 Figura 10:Elementos del Modelo de Análisis. .......................................................................46 Figura 11: Representación tabular de objetos de datos. ......................................................47 Figura 12: Modelo entidad – relación para el registro de Automóvil .....................................50 Figura 13: Caso de uso ........................................................................................................51 Figura 14: Diagrama de caso de uso ....................................................................................52 Figura 15: Especificación de caso de uso.............................................................................53 Figura 16: Caso de uso PagarImpuestoVentas ...................................................................57 Figura 17: Diagrama de actividad ........................................................................................57 Figura 18: Diagrama de carril para la función de Acceso a la cámara de vigilancia – despliegue de vistas de cámara. ..........................................................................................58. E. Figura 19: DFD al nivel de contexto para la función de seguridad de HogarSeguro .............60. T. Figura 20: DFD al nivel de nivel 1 para la función de seguridad de HogarSeguro ................61. O. Figura 21: DFD al nivel de nivel 2 que refina el proceso de monitores de sensores. ............61. LI. Figura 22: Diagrama de estado para la función de seguridad de HogarSeguro. ...................63. IB. Figura 23: Anatomía de una clase ........................................................................................66. B. Figura 24. Una carta índice del modelo CRC. .....................................................................67 Figura 25: Anatomía de una clase-Asociación......................................................................72 Figura 26: Anatomía de una clase-Multiplicidad ...................................................................72 Figura 27: Anatomía de una clase-Dependencia ..................................................................73 Figura 28a Paquetes UML ....................................................................................................74 Figura 28b Paquetes UML ....................................................................................................75 Figura 28c Paquetes UML ....................................................................................................75 Figura 29: Diagrama de estado. ..........................................................................................76. 7 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(8) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Figura 30: Diagrama de Secuencia (parcial) para la función de seguridad de HogarSeguro. .............................................................................................................................................77 Figura 31: Caso de uso ........................................................................................................78 Figura 32: Clase de análisis .................................................................................................79 Figura 33: Diagrama de secuencia .......................................................................................79 Figura 34: Conversión del modelo de análisis en un diseño de software. ............................83 Figura 35: Modularidad y costes de software. .....................................................................92. S. Figura 36: Anatomía de clase de diseño ..............................................................................98. A. Figura 37: Dimensiones del Modelo de Diseño. .................................................................100. IC. Figura 38: Representación en UML de la interfaz para el panel de control. ........................103. S. Figura 39 :Diagrama de componente en UML para manejoSensor. ...................................104. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Figura 40: Diagrama de despliegue en UML para HogarSeguro. .......................................105. B. IB. LI. O. T. E. Figura 41: Relación de abstracción entre estilos y patrones. ..............................................121. 8 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(9) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. INDICE DE TABLAS. Tabla1: Notación para el diccionario de datos. .....................................................................81 Tabla2: Estilos Arquitectónicos y Atributos de calidad. .......................................................114 Tabla3: Partes que conforman un estilo arquitectónico basado en atributos (ABAS). .........115 Tabla 4 (a): Patrones arquitectónicos y atributos de calidad. ..............................................118. S. Tabla 4 (b): Patrones arquitectónicos y atributos de calidad. ..............................................118. A. Tabla 5: Diferencias entre estilo arquitectónico y patrón arquitectónico. .............................119. IC. Tabla 6: Patrones de diseño y atributos de Calidad. ...........................................................120. S. Tabla 7: Comparación de vistas arquitectónicas en función de las perspectivas del sistema.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. ...........................................................................................................................................126 Tabla 8: Perfiles, categorías, pesos y métricas asociados a tributos de calidad según Bosch(2000). ......................................................................................................................140 Tabla 9: Instrumentos asociados a las distintas técnicas de evaluación de arquitecturas de software. ............................................................................................................................144 Tabla 10 :Pasos contemplados por el método de evaluación SAAM. .................................147 Tabla 11: Pasos del método de evaluación ATAM. ............................................................149 Tabla 12: Pasos del método de evaluación ARID. ..............................................................151 Tabla 13: Pasos contemplados en el marco de referencia para la evaluación de arquitecturas de software propuesto por In et al (2001). ..........................................................................153 Tabla 14: Etapas contempladas por el método de evaluación de arquitecturas propuesto por Bosch (2000). .....................................................................................................................154. E. Tabla 15: Actividades contempladas en el método de comparación de arquitecturas basado. O. T. en el modelo ISO/IEC 9126 adaptado para arquitecturas de software. ...............................155. B. IB. LI. Tabla 16: Comparación entre métodos de evaluación. .......................................................156. 9 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(10) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Universidad Nacional de Trujillo. RESUMEN. Frente a los problemas existentes en la industria del software como el desarrollo de un producto que: no funcione,. no tenga el rendimiento deseado, o que las piezas no. encajan perfectamente unas con otras; es que surge la necesidad de realizar un estudio. S. y describir el estado del análisis y diseño como etapas del proceso de desarrollo de. IC. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. cliente, asegurando de esta manera, la confianza en el software.. A. software, con la finalidad de lograr el cumplimiento de los aspectos requeridos por el. La etapa del análisis corresponde al proceso mediante el cual se intenta descubrir qué es lo que realmente se necesita y comprender adecuadamente los requerimientos del software. Mientras que, la etapa de diseño corresponde al diseño arquitectónico del software, es decir, se ha de decidir la estructura general que tendrá el mismo.. En el presente trabajo se da a conocer los conceptos, principios y modelos del análisis y diseño del software, así como cuál es el proceso que se debe llevar a cabo para su. B. IB. LI. O. T. E. desarrollo, facilitando así la tarea de los mismos.. 10 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(11) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Universidad Nacional de Trujillo. INTRODUCCION. El análisis y diseño de software es un enfoque sistemático, para la identificación de problemas, oportunidades y objetivos, analizando los flujos de información en las organizaciones y diseñando software para resolver un problema. Conforme prolifera la. S. información, es esencial un enfoque planeado y sistemático para la introducción,. A. modificación y mantenimiento del software.. IC. La etapa de análisis en el ciclo de vida del software corresponde al proceso mediante el. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. cual se intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los requerimientos del software.. En la etapa de diseño se estudian las posibles alternativas de implementación para el software que hemos de construir y se ha de decidir la estructura general que tendrá el mismo, es decir su diseño arquitectónico.. De acuerdo a ello, este trabajo constituye una guía de referencia en las etapas vistas. B. IB. LI. O. T. E. previamente dentro del área de ingeniería de software.. 11 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(12) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. CAPITULO I: PLANTEAMIENTO DEL ESTUDIO 1.1 Especificación del campo de estudio Actualmente, existen problemas en el ámbito o industria del software como lo son: el desarrollo de un producto que no funcione, que no tenga el rendimiento deseado, o que. desarrollo de. A. Esta problemática representa la cantidad de esfuerzo perdido en el. S. las piezas no encajan perfectamente unas con otras; trayendo con ello costes muy altos.. IC. software, produciendo costos de desarrollo y mantenimiento de productos fuera de. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. control.. Diversos autores han investigado y propuestos guías, principios, modelos, metodologías etc. para ayudar a enfrentar estos problemas de desarrollo de software. El problema que se pretende resolver en este trabajo es el uso de los distintos conceptos y modelos para el análisis y diseño de software, lo cual permitirá alcanzar que se ajuste al logro de todos los objetivos y obtener los resultados esperados para de esta manera evitar un mal uso de tiempo, y costos.. Nos resulta de mucha importancia resolver este problema, pues actualmente sabemos que el software representa un papel muy importante para el desarrollo de las. E. organizaciones, ya que es soporte para los procesos de negocio, productivos y. O. T. administrativos, y también es parte integral de las estrategias corporativas para la. IB. LI. generación de ventajas competitivas.. B. 1.2Justificación del Trabajo Frente a. la problemática planteada anteriormente. es que. surge la necesidad de. realizar un estudio de cómo desarrollar las etapas de análisis y diseño de software adecuadamente, con la finalidad de lograr el cumplimiento de los aspectos requeridos por el cliente, asegurando la confianza en el software.. 12 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(13) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Justificación Académica Dejar un aporte conceptual a los estudiantes de ciencias de la computación para profundizar en este tema que es clave en el desarrollo de software. 1.3Objetivos Objetivo General. S. . A. Hacer una descripción del estado del arte del análisis y diseño de software como. S. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. mantenimiento de software.. IC. etapas del proceso de desarrollo para una buena codificación, pruebas y. Objetivos específicos . Describir las etapas de análisis y diseño del software.. . Identificar la importancia del análisis y diseño como etapas del proceso de desarrollo de software.. Dar a conocer los elementos del modelo de análisis.. . Dar a conocer los elementos del modelo del diseño.. B. IB. LI. O. T. E. . 13 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(14) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. CAPITULO II: INGENIERIA DE REQUERIMIENTOS Los requerimientos para un sistema son la descripción de los servicios proporcionados por el sistema y sus restricciones operativas. Estos requerimientos reflejan las necesidades de los clientes de un sistema que ayude a resolver algún problema como el control de un dispositivo, hacer un pedido o encontrar información. El proceso de descubrir, analizar,. A. S. documentar y verificar estos servicios y restricciones se denomina ingeniería de. IC. requerimientos (RE). Este capítulo se centra en dichos requerimientos y cómo describirlos.. S. El término requerimiento no se utiliza de una forma constante en la industria de software.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. En algunos casos, un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste. En el otro extremo. Es una definición detallada y formal de una función del sistema. Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre estos diferentes niveles de descripción.. Aquí se distinguen utilizando la denominación requerimientos del usuario para designar los requerimientos abstractos de alto nivel, y requerimientos del sistema para designar la. E. descripción detallada de lo que el sistema debe hacer. Los requerimientos del usuario y del. T. sistema se pueden definir como se muestra a continuación:. LI. O. 1. Los requerimientos del usuario son declaraciones, en lenguaje natural y en diagramas,. IB. de los servicios que se espera que el sistema proporcione y de las restricciones bajo las. B. cuales debe funcionar.. 2. Los requerimientos del sistema establecen con detalle las funciones, servicios y restricciones operativas del sistema. El documento de requerimientos del sistema (algunas veces denominado especificación funcional) debe ser preciso. Debe definir exactamente qué es lo que se va a implementar. Puede ser parte del contrato entre el Usuario del sistema y los desarrolladores del software.. 14 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(15) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Universidad Nacional de Trujillo. Es necesario redactar los requerimientos en diversos niveles de detalle debido a que diferentes tipos de lectores los utilizan de distinta manera. Los lectores de los requerimientos de usuario normalmente no tratan de cómo se implementará el sistema y pueden ser usuarios que no están interesados en los recursos detallados del sistema. Los Lectores de los requerimientos del sistema necesitan saber con. S. más precisión qué hará el sistema debido a que están interesados en cómo ayudará esto a. IC. A. los procesos de negocio o debido a que están implicados en la implementación del sistema.. S. La Figura 1 ilustra la distinción entre los requerimientos del usuario y del sistema. Este. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. ejemplo de un sistema de biblioteca muestra la manera en que un requerimiento del usuario se expande en varios requerimientos del sistema. Puede verse en la Figura 1 que el requerimiento del usuario es más abstracto, y que los requerimientos del sistema añaden detalle, explicando los servicios y funciones que deben ser proporcionados por el sistema a desarrollar.. La Figura 2 muestra los tipos de lectores de los requerimientos de usuario y del sistema. Definición del requerimiento del usuario. 1. LIBSYS controlara todos los datos requeridos por las agencias que licencian los derechos de autor en el Reino Unido y en otra parte.. E. Especificación de los requerimientos del sistema. T. 1.1 Al hacer una petición de un documento del LIBSYS, el solicitante se presentará con un formulario que. O. registre los detalles del usuario y de la petición hecha.. LI. 1.2 El formulario de petición del LIBSYS será almacenado en el sistema durante cinco años desde la fecha. IB. de la petición.. B. 1.3 Todos los formularios de peticiones del LIBSYS se deben indexar por usuario, por el nombre del material solicitado y por el proveedor de la petición. 1.4 El LIBSYS mantendrá un fichero en el que se registrarán todas las peticiones que se han hecho al sistema. 1.5 Para el material donde se aplican los derechos de préstamo del autor, los detalles del préstamo serán enviados mensualmente a las agencias que licencian los derechos de autor que se han registrado con LIBSYS.. Figura 1: Requerimientos del usuario y del sistema. Fuente: Ian Sommerville. [SOM 05]. 15 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(16) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Universidad Nacional de Trujillo. S. Usuarios finales del sistema Ingenieros Clientes Arquitectos del sistema Desarrolladores del software. IC. Requerimientos del Sistema. A. Requerimientos del usuario. Administradores clientes Usuarios finales del sistema Ingenieros Clientes Administradores contratistas Arquitectos del sistema. B. IB. LI. O. T. E. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Fuente: Ian Sommerville. [SOM 05]. S. Figura 2: Lectores de los diferentes tipos de especificaciones.. Figura 3: Usuarios de un documento de requerimientos Fuente: Ian Sommerville. [SOM 05]. 2.1Requerimientos funcionales y no funcionales A menudo, los requerimientos de software se clasifican en funcionales y no funcionales, o como requerimientos del dominio: Requerimientos funcionales. Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos 16 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(17) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Universidad Nacional de Trujillo. funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer. Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad.. S. Normalmente apenas se aplican a características o servicios individuales del sistema.. IC. A. Requerimientos del dominio. Son requerimientos que provienen del dominio de aplicación. S. del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. funcionales o no funcionales.. 2.1.1 Requerimientos Funcionales. Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización. al. redactar. requerimientos.. Cuando. se. expresan. como. requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo, los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc.. T. E. Los requerimientos funcionales para un sistema software se pueden expresar de. O. diferentes formas. A continuación se presentan algunos ejemplos de estos. IB. LI. requerimientos funcionales para un sistema de biblioteca universitarios,. B. denominados LIBSYS, utilizado por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas.  El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.  El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el almacén de documentos.  A cada pedido se le deberá asignar un identificador único (ID_PEDIDO), que el usuario podrá copiar al área de almacenamiento permanente de la cuenta. 17. Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(18) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La completitud significa que todos los servicios solicitados por el usuario deben estar definidos. La consistencia significa que los requerimientos no deben tener definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es prácticamente imposible alcanzar los. A. S. requerimientos de consistencia y completitud.. S. IC. 2.1.2 Requerimientos No funcionales Los requerimientos no funcionales, como su nombre sugiere, son aquellos. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema.. Los requerimientos no funcionales rara vez se asocian con características particulares del sistema. Más bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. Por lo tanto, pueden especificar el. T. E. rendimiento del sistema, la protección, la disponibilidad, y otras propiedades. LI. O. emergentes. Esto significa que a menudo son más críticos que los requerimientos. IB. funcionales particulares.. B. Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una función del sistema que realmente no cumple sus necesidades. Sin embargo, el incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable. Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las funciones de control no funcionarán correctamente. 18. Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(19) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Los requerimientos no funcionales no sólo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema. Ejemplos de requerimientos de procesos son la especificación de los estándares de calidad que se deben utilizar en el proceso,. S. una especificación que el diseño debe producir con una herramienta CASE. IC. A. particular y una descripción del proceso a seguir.. S. Los requerimientos no funcionales surgen de las necesidades del usuario, debido. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas software o hardware, o a factores externos como regulaciones de seguridad o legislaciones sobre privacidad. La Figura 4 es una clasificación de los requerimientos no funcionales. Puede verse en este diagrama que los requerimientos no funcionales pueden venir de las características requeridas del software (requerimientos del producto), de la organización que desarrolla el software (requerimientos organizacionales) o de fuentes externas.. Los tipos de requerimientos no funcionales son:. B. IB. LI. O. T. E. 1. Requerimientos del producto. Estos requerimientos especifican el comportamiento del producto. Algunos ejemplos son los requerimientos de rendimiento en la rapidez de ejecución del sistema y cuánta memoria se requiere; los requerimientos de fiabilidad que fijan la tasa de fallos para que el sistema sea aceptable; los requerimientos de portabilidad, y los requerimientos de usabilidad. Ejemplo: la interfaz de usuario del LIBSYS se implementara como HTML simple sin marcos o appIets Java. 2. Requerimientos organizacionales. Estos requerimientos se derivan de políticas y procedimientos existentes en la organización del cliente y en la del desarrollador. Algunos ejemplos son los estándares en los procesos que deben utilizarse; los requerimientos de implementación. como los 19 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(20) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. lenguajes de programación o el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación. Ejemplo: El proceso de desarrollo del sistema y los documentos a entregar deberán ajustarse al proceso y a los productos a entregar definidos en XYZCo-5P-5TAN-95.. S. 3. Requerimientos externos. Este gran apartado incluye todos los. IC. A. requerimientos que se derivan de los factores externos al sistema y de su. S. proceso de desarrollo. Éstos pueden incluir los requerimientos de. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. interoperabilidad que definen la manera en que el sistema interactúa con sistemas de otras organizaciones; los requerimientos legislativos que deben seguirse para asegurar que el sistema funcione dentro de la ley, y los requerimientos éticos. Estos últimos son puestos en un sistema para asegurar que será aceptado por sus usuarios y por el público en general. Ejemplo: El sistema no deberá revelar al personal de la biblioteca que lo utilice ninguna información personal de los usuarios del sistema aparte de. B. IB. LI. O. T. E. su nombre y número de referencia de la biblioteca.. Figura 4: Tipos de requerimientos no funcionales. Fuente: Ian Sommerville. [SOM 05]. 20 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(21) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 2.1.3 Requerimientos del dominio Los requerimientos del dominio se derivan del dominio de aplicación del sistema más que de las necesidades específicas de los usuarios. Normalmente incluyen terminología especializada del dominio o referencias a conceptos del dominio. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer. S. cómo se deben ejecutar cálculos particulares.. IC. A. Debido a que éstos se especializan, a los ingenieros de software a menudo les. S. resulta difícil entender cómo se relacionan con los otros requerimientos del sistema.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen, puede ser imposible hacer que el sistema funcione de forma satisfactoria. El sistema LIBSYS incluye varios requerimientos del dominio: . Deberá existir una interfaz de usuario estándar para todas las bases de datos que estará basada en el estándar Z39.S0.. . Debido a las restricciones en los derechos de autor, algunos documentos deberán borrarse inmediatamente después de su llegada. Dependiendo de los requerimientos del usuario, estos documentos se imprimirán de forma local en el. T. E. servidor del sistema para ser distribuidos de forma manual al usuario o se. LI. O. enviarán a la impresora de la red.. IB. 2.2 Proceso de la Ingeniería de requerimientos. B. La meta del proceso de ingeniería de requerimientos es crear y mantener un documento de requerimientos del sistema. El proceso general corresponde cuatro subprocesos de alto nivel de la ingeniería de requerimientos. Éstos tratan de la evaluación de si el sistema es útil para el negocio (estudio de viabilidad); el descubrimiento de requerimientos (obtención y análisis); la transformación de estos requerimientos en formularios estándar (especificación), y la verificación de que los requerimientos realmente definen el sistema que quiere el cliente (validación).. 21 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(22) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Universidad Nacional de Trujillo. La Figura 5 ilustra la relación entre estas actividades. También muestra el documento que se elabora en cada etapa del proceso de ingeniería de requerimientos. Las actividades que se muestran en la Figura 5 se refieren al descubrimiento, documentación y verificación de requerimientos. Sin embargo, en casi todos los. S. sistemas los requerimientos cambian. Las personas involucradas desarrollan una. IC. A. mejor comprensión de lo que quieren que haga el software; la organización que. S. compra el sistema cambia; se hacen modificaciones a los sistemas hardware,. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. software y al entorno organizacional. El proceso de gestionar estos cambios en los requerimientos se denomina gestión de requerimientos.. Estudio de Viabilidad. Obtención y Análisis. de requerimientos. Especificación de Requerimientos. Informe de Viabilidad. Modelos. Validación de Requerimientos. Requerimientos Del Usuario del Sistema. LI. O. T. E. Del Sistema. B. IB. Documento de Requerimientos. Figura 5: El proceso de Ingeniería de Requerimientos Fuente: Ian Sommerville. [SOM 05]. 2.2.1. Estudio de Viabilidad Para todos los sistemas nuevos, el proceso de ingeniería de requerimientos debería empezar con un estudio de viabilidad. La entrada de éste es un conjunto de requerimientos de negocio preliminares, una descripción 22. Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(23) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. resumida del sistema y de cómo éste pretende contribuir a los procesos del negocio. Los resultados del estudio de viabilidad deberían ser un informe que recomiende si merece o no la pena seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema. Un estudio de viabilidad es un estudio corto y orientado a resolver varias. S. cuestiones:. IC. A. 1. ¿Contribuye el sistema a los objetivos generales de la organización?. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. de las restricciones de coste y tiempo?. S. 2. ¿Se puede implementar el sistema utilizando la tecnología actual y dentro. 3. ¿Puede integrarse el sistema con otros sistemas existentes en la organización?.. La cuestión de si el sistema contribuye a los objetivos del negocio es crítica. Si no contribuye a estos objetivos, entonces no tiene un valor real en el negocio. Aunque esto pueda parecer obvio, muchas organizaciones desarrollan sistemas que no contribuyen a sus objetivos porque no tienen una clara declaración de estos objetivos, porque no consiguen definir los requerimientos del negocio para el sistema o porque otros factores políticos u. T. E. organizacionales influyen en la creación del sistema.. O. Llevar a cabo un estudio de viabilidad comprende la evaluación y recopilación. B. IB. LI. de la información, y la redacción de informes. La fase de evaluación de la información identifica la información requerida para contestar las tres preguntas anteriores. Una vez que dicha información se ha identificado, se debería hablar con las fuentes de información para descubrir las respuestas a estas preguntas. Algunos ejemplos de preguntas posibles son: l. ¿Cómo se las arreglaría la organización si no se implementara este sistema? 2. ¿Cuáles son los problemas con los procesos actuales y cómo ayudaría un sistema nuevo a aliviarlos? 23. Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(24) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. 3. ¿Cuál es la contribución directa que hará el sistema a los objetivos y requerimientos del negocio? 4. ¿La información se puede obtener y transferir a otros sistemas de la organización? 5. ¿Requiere el sistema tecnología que no se ha utilizado previamente en la. S. IC. A. 6. ¿A qué debe ayudar el sistema y a qué no necesita ayudar?. S. organización?. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. En un estudio de viabilidad, se pueden consultar las fuentes de información, como los jefes de los departamentos donde se utilizará el sistema, los ingenieros de software que están familiarizados con el tipo de sistema propuesto, los expertos en tecnología y los usuarios finales del sistema. Normalmente, se debería intentar completar un estudio de viabilidad en dos o tres semanas.. Una vez que se tiene la información, se redacta el informe del estudio de viabilidad. Debería hacerse una recomendación sobre si debe continuar o no el desarrollo del sistema. En el informe, se pueden proponer cambios en el. T. E. alcance, el presupuesto y la confección de agendas del sistema y sugerir. Obtención y Análisis de requerimientos. B. IB. LI. 2.2.2. O. requerimientos adicionales de alto nivel para éste.. La siguiente etapa del proceso de ingeniería de requerimientos es la obtención y análisis de requerimientos. En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios finales del sistema para determinar: el dominio de la aplicación, qué servicios debe proporcionar el sistema, el rendimiento requerido del sistema, las restricciones hardware, etc. La obtención y análisis de requerimientos pueden afectar a varias personas de la organización.. 24 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(25) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. El término stakeholder se utiliza para referirse a cualquier persona o grupo que se verá afectado por el sistema, directa o indirectamente. Entre los stakeholders se encuentran los usuarios finales que interactúan con el sistema y todos aquellos en la organización que se pueden ver afectados por su instalación. Otros stakeholders del sistema pueden ser los ingenieros que. S. desarrollan o dan mantenimiento a otros sistemas relacionados, los gerentes. S. los trabajadores.. IC. A. del negocio, los expertos en el dominio del sistema y los representantes de. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. Obtener y comprender los requerimientos de los stakeholders es difícil por varias razones:. 1. Los stakeholders a menudo no conocen lo que desean obtener del sistema informático excepto en términos muy generales; puede resultarles difícil expresar lo que quieren que haga el sistema o pueden hacer demandas irreales debido a que no conocen el coste de sus peticiones. 2. Los stakeholders expresan los requerimientos con sus propios términos de forma natural y con un conocimiento implícito de su propio trabajo. Los ingenieros de requerimientos, sin experiencia en el dominio del cliente,. T. E. deben comprender estos requerimientos.. B. IB. LI. O. 3. Diferentes stakeholders tienen requerimientos distintos, que pueden expresar de varias formas. Los ingenieros de requerimientos tienen que considerar todas las fuentes potenciales de requerimientos y descubrir las concordancias y los conflictos. 4. Los factores políticos pueden influir en los requerimientos del sistema. Por ejemplo, los directivos pueden solicitar requerimientos específicos del sistema que incrementarán su influencia en la organización. 5. El entorno económico y de negocios en el que se lleva a cabo el análisis es dinámico. Inevitablemente, cambia durante el proceso de análisis. Por lo tanto, la importancia de ciertos requerimientos puede cambiar. Pueden 25. Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(26) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. emerger nuevos requerimientos de nuevos stakeholders que no habían sido consultados previamente. En la Figura 6 se muestra un modelo muy general del proceso de obtención y análisis. Cada organización tendrá su propia versión o instancia de este modelo. S. general, dependiendo de los factores locales como la habilidad del personal,. IC. A. el tipo de sistema a desarrollar y los estándares utilizados. De nuevo, se. S. puede pensar en estas actividades dentro de una espiral de forma que las. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. actividades se entrelazan a medida que el proceso avanza desde el anillo interior a los exteriores de la espiral. Las actividades del proceso son: 1.. Descubrimiento de requerimientos. Es el proceso de interactuar con los stakeholders del sistema para recopilar sus requerimientos. Los requerimientos del dominio de los stakeholders y la documentación también se descubren durante esta actividad.. 2.. Clasificación y organización de requerimientos. Esta actividad toma la recopilación no estructurada de requerimientos, grupos relacionados de. Ordenación por prioridades y negociación de requerimientos.. Inevitablemente, cuando existen muchos stakeholders involucrados, los. IB. O. 3.. LI. T. E. requerimientos y los organiza en grupos coherentes.. B. requerimientos entrarán en conflicto. Esta actividad se refiere a ordenar según las prioridades los requerimientos, y a encontrar y resolver los requerimientos en conflicto a través de la negociación. 4.. Documentación de requerimientos. Se documentan los requerimientos y se entra en la siguiente vuelta de la espiral. Se pueden producir documentos de requerimientos formales o informales.. 26 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(27) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. S. IC. A. S. Universidad Nacional de Trujillo. Figura 6: El proceso de Obtención y análisis de Requerimientos Fuente: Ian Sommerville. [SOM 05]. La Figura 6 muestra que la obtención y análisis de requerimientos es un proceso iterativo con retroalimentación continua de cada actividad a las otras actividades. El ciclo del proceso comienza con el descubrimiento de. E. requerimientos y termina con la documentación de requerimientos. La. O. T. comprensión de los requerimientos por parte del analista mejora con cada. LI. vuelta del ciclo.. B. IB. La clasificación y organización de requerimientos principalmente se refiere a la identificación de requerimientos coincidentes de diferentes stakeholders y a la agrupación de requerimientos relacionados. La forma más común de. agrupar requerimientos es utilizar un modelo de la arquitectura del sistema para identificar los subsistemas y asociar los requerimientos con cada subsistema. Esto pone de manifiesto que la ingeniería de requerimientos y el diseño arquitectónico no siempre se pueden separar.. 27 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(28) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Universidad Nacional de Trujillo. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Inevitablemente, los stakeholders tienen opiniones diferentes sobre la importancia y prioridad de los requerimientos, y algunas veces estas opiniones están reñidas. Durante el proceso, se deberían organizar frecuentes negociaciones con los stakeholders para que se pueda llegar a un acuerdo. Es imposible satisfacer completamente a todos los stakeholders.. S. pero si algún stakeholder piensa que sus opiniones no se han considerado. IC. A. adecuadamente, deliberadamente puede intentar socavar el proceso de. S. ingeniería de requerimientos.. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. En la etapa de la documentación de requerimientos, los requerimientos que se han obtenido se documentan de tal forma que se pueden utilizar para ayudar al descubrimiento de nuevos requerimientos. En esta etapa, se puede producir una versión inicial del documento de requerimientos del sistema, pero faltarán secciones y habrá requerimientos incompletos. Por otra parte, los requerimientos se pueden documentar como tablas en un documento o en tarjetas. Redactar requerimientos en tarjetas (el enfoque utilizado en la programación extrema) puede ser muy efectivo, ya que son fáciles de manejar, cambiar y organizar para los stakeholders.. T. E. 2.2.3 Especificación de Requerimientos. O. En esta tarea se documentan los requerimientos acordados con el. B. IB. LI. usuario/cliente, en un nivel apropiado de detalle. La especificación es el producto de trabajo final que genera la ingeniería de requisitos. Sirve como base para las actividades de Ingeniería de Software subsecuentes. Describe la función y el desempeño de un sistema basado en computadora y las restricciones que regirán su desarrollo. Se puede decir que la especificación es el “PASAR EN LIMPIO” el análisis realizado previamente aplicando técnicas y/o estándares de documentación,. 28 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.

(29) Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT. Facultad de Ciencias Físicas y Matemáticas – Ing. Informática. Universidad Nacional de Trujillo. como por ejemplo la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos.. 2.2.4 Validación de Requerimientos La validación de requerimientos trata de mostrar que éstos realmente definen el. problemas. con. los. requerimientos.. La. validación. A. encontrar. de. IC. implica. S. sistema que el cliente desea. Coincide parcialmente con el análisis ya que éste. S. requerimientos es importante debido a que los errores en el documento de. C Y A M D A E T C E IE M N Á C T I IC A A S S FÍ. requerimientos pueden conducir a importantes costes al repetir el trabajo cuando son descubiertos durante el desarrollo o después de que el sistema esté en uso. El coste de arreglar un problema en los requerimientos haciendo un cambio en el sistema es mucho mayor que reparar los errores de diseño o los de codificación. La razón de esto es que un cambio en los requerimientos normalmente significa que el diseño y la implementación del sistema también deben cambiar y que éste debe probarse nuevamente.. Durante el proceso de validación de requerimientos, se deben llevar a cabo verificaciones sobre requerimientos en el documento de requerimientos. Estas. T. E. verificaciones comprenden:. B. IB. LI. O. 1. Verificaciones de validez. Un usuario puede pensar que se necesita un sistema para llevar a cabo ciertas funciones. Sin embargo, el razonamiento y el análisis pueden identificar que se requieren funciones adicionales o diferentes. Los sistemas tienen diversos stakeholders con diferentes necesidades, y cualquier conjunto de requerimientos es inevitablemente un compromiso en el entorno del stakeholder. 2. Verificaciones de consistencia. Los requerimientos en el documento no deben. contradecirse.. Esto. es,. no. debe. haber. restricciones. o. descripciones contradictorias de la misma función del sistema.. 29 Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/.