• Author / Uploaded
• CARLOS ANDRES RAMIREZ LOPEZ

Citation preview

3.1Actividades de Reflexión inicial. Tomando como punto de partida las actividades realizadas en su proyecto formativo y la necesidad de poder conocer de una forma precisa que se requiere a nivel de recursos físicos y lógicos para el éxito del desarrollo del SI de su proyecto, lo invito a investigar y/o indagar lo siguiente: • ¿Qué tipos de propuestas de trabajo conoce para presentar los requerimientos de una empresa? RTA/ existen informes o documentos con estructura técnica en los cuales se estipulan previamente a través de una recolección de información los requerimientos necesarios para la satisfacción o solución de la problemática de información que contiene el desarrollo a implementar.

• ¿Describa las formas de representar soluciones a problemas planteados? RTA/ Se pueden representar a través de: un informe de requerimientos en los cuales se estipulan las soluciones específicas a las problemáticas presentadas. Un diagrama donde se especifique cada problema y la posible solución. Un cuadro comparativo donde se especifique las ventajas y desventajas del proceso actual con el nuevo cambio que se quiere implementar.

• ¿Describa metodologías, herramientas que permitan representar soluciones a problemas planteados? Las herramientas y técnicas cualitativas y no cuantitativas son las siguientes: 1. Recolección de datos. Es una recolección de datos para reunir y clasificar las informaciones según determinadas categorías de un evento o problema que se desee estudiar. 2. Lluvia/Tormenta de ideas (Brainstorming). Técnica que consiste en dar oportunidad, a todos los miembros de un grupo reunido, de opinar o sugerir sobre un determinado asunto que se estudiar. 3. Diagrama de Pareto. Gráfico cuyas barras verticales están ordenadas de mayor a menor importancia, estas barras representan datos específicos correspondientes a un problema determinado, la barra más alta está del lado izquierdo y la más pequeña, según va disminuyendo de tamaño, se encuentra hacia la derecha. 4. Diagrama de Ishikawa. (Causa Efecto)

Técnica de análisis de causa y efectos para la solución de problemas, relaciona un efecto con las posibles causas que lo provocan. 5. Diagrama de flujo. Esquematiza todo el proceso de solución de un problema de manera secuencial. 6. Matriz de relación. Consiste en un Gráfico de filas y columnas que permite priorizar alternativas de solución, en función de la ponderación de criterios que afectan a dichas alternativas. 7. Diagrama de comportamiento Herramienta que permite graficar los puntos del comportamiento de una variable, de acuerdo a como se van obteniendo. 8. Diagrama de Gantt. Gráfico que establece el orden y el lapso en que deben ejecutarse las acciones que constituyen un proyecto. 9. Entrevistas. Técnica que permite reunir información directamente con el involucrado en el proceso. 10. Listas chequeables. Método, lista u hoja de información para lograr que nada se nos olvide ni se omita, en la cual la información consignada es de fácil análisis y verificación.

• ¿Mencione al menos cuatro diferencias entre los requisitos funcionales, y los no funcionales?

Funcionales

son declaraciones de los servicios que proveerá el sistema

declaran explícitamente lo que el sistema no debe hacer.

No funcionales Estos refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, entre otros

Deber ser completa y ser consistente expresa una capacidad de acción del mismo

es una característica ya sea del sistema, del proyecto o del servicio de soporte Son las reglas del negocio.

• ¿Menciones cuáles son las características deseables de una buena especificación de Requerimientos? Rta/ El requerimiento debe cumplir con ciertos criterios y características 1. Correcta 2. No ambigua 3. Completa 4.Consistente 5. Calificada de acuerdo a la importancia y/o estabilidad 6.Verificable 7.Modificable 8.Rastreable

1. Correcta Esta cumple este criterio si y solo sí, cada requisito especificado es un requisito que el software debe cumplir. 2. No ambigua No es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación. 3. Completa Debe incluir los siguientes elementos: a) Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas. En particular cualquier requisito externo impuesto por una especificación del sistema debe ser reconocido y tratado. b) Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Notar que es importante especificar las respuestas tanto para valores de entrada válidos como inválidos. c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la especificación de requerimientos, así como la definición de todos los términos y unidades de medida.

4. Consistente Es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningunos subconjuntos de requisitos ahí descritos se contradicen o entran en conflicto. 5. Jerarquizada de acuerdo a la importancia y/o estabilidad Una SRS está calificada de acuerdo a la importancia y/o estabilidad si cada requisito tiene un identificador que indique la importancia o estabilidad del requisito. 6. Verificable

es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple el requisito. En general cualquier requisito ambiguo no es verificable. 7. Modificable es modificable, sí y solo sí, su estructura y estilo son tales que, cualquier cambio a los requisitos pueden ser hechos fácil, completa y consistentemente sin perder la estructura y el estilo. La modificabilidad generalmente requiere que una especificación de requerimientos tenga:   

Tenga una organización coherente y fácil de usar con una tabla de contenido, un índice y referencias cruzadas explícitas. No sea redundante (esto es, el mismo requisito no debe aparecer en más de una parte en las especificaciones de requerimientos). Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros requisitos.

8. Rastreable

Es rastreable si el origen de cada uno de sus requisitos es claro y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentación. Se recomiendan los siguientes dos tipos de rastreabilidad:  

Rastreabilidad hacia atrás (esto es, a estados previos del desarrollo). El requisito tiene referencias explícitas a sus fuentes en documentos anteriores. Rastreabilidad hacia enfrente (esto es, a todos los documentos derivados del SRS). Depende de que cada requisito tenga un nombre único o número de referencia. Es particularmente importante cuando el software entra en operación y mantenimiento. Cuando el código y los documentos de diseño son modificados, es esencial contar con a capacidad para conocer el conjunto completo de requisitos que pueden ser afectados por esas modificaciones.

3.2 Actividades de contextualización e identificación de conocimientos necesarios para el aprendizaje. Realice una investigación sobre los siguientes conceptos:



Requerimientos, Informe de Requerimientos Rta/ ¿Qué es Requerimiento? Puede definirse como un atributo necesario dentro de un sistema, que puede representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales. Es simplemente una declaración abstracta de alto de nivel de un servicio que debe proporcionar el sistema o una restricción de este.  Requerimientos del usuario Son las declaraciones, en lenguaje natural y en diagramas de los servicios que se esperan que el sistema proporcione y de las restricciones bajo las cuales debe funcionar  Requerimientos del sistema Establece con detalle las funciones, servicios y restricciones operativas del sistema, el documento de requerimientos del sistema debe ser preciso y debe definir exactamente qué es lo que se va a implementar. Para ser mejor comprendidos estos requerimientos se pueden clasificar en  Requerimientos funcionales Son declaración de los servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares, también puede declarar lo que el sistema no debe hacer.  Requerimientos no funcionales Son restricciones de los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Se aplican a características o servicios individuales del tema.  Requerimientos de dominio Estos reflejan las características y restricciones del dominio de aplicación del sistema. Para la construcción y definición de los requerimientos se debe tener en cuenta:

Verificación de Requisitos Para la verificación de requisitos se deben añadir criterios de aceptación por cada requisito, una tarea de la calidad es asegurarse de que cada requisito cumple con los criterios asignados, este criterio es una medida del requisito que lo hace entendible y con capacidad de ser probado. Una vez ya identificado los requerimientos, documentados y verificados se procede a realizar la revisión de los mismos con base a la información recolectada con los usuarios del sistema, en esta revisión participa los analistas del equipo de trabajo y los usuarios necesarios para esta revisión de debe chequear que:  Los requisitos estén en su totalidad  Están resultas las diferencias entre los requisitos solicitados y definitivos  Los requisitos son claros y cumplibles por parte de la organización  Se tiene documentado todo lo solicitado.  Se tiene registro de los cambios.  Se tienen los diferentes roles del sistema. Preparar plan de revisión: En la preparación del plan de reunión de debe planear quienes deben asistir que se va a hablar y cuánto tiempo se va a gastar. Documentos de requisitos a revisar: Identificar cuáles son los documentos de especificación de requisitos que se va a revisar. Preparar reunión: Se debe confirmar el lugar en el cual realizará la reunión y se deben prepara los materiales necesarios para la reunión (lápices, hojas, elementos visuales… etc). Realizar reunión: Se revisa el entendimiento de la especificación por parte de los interesados y se valida que lo especificado si cumple con la necesidad del cliente y con lo solicitado. Identificar de defectos de la especificación: Si revisa si se encuentran defectos con respecto a lo solicitado o si hace falta alguna especificación requerida. Realización de correcciones a los documentos: Si en la etapa anterior se encuentran defectos en la especificación el analista del sistema debe realizan las debidas correcciones al documento. Informar modificaciones a los interesados: Una vez los defectos en la especificación han sido subsanados, se debe enviar un breve resumen informando las tareas realizadas para la corrección de los documentos especificados junto con los documentos corregidos a los participantes en la reunión para dar su aprobación.

Cierre de los requerimientos: Por último, se da por cerrado y entendido el requerimiento se firma la aprobación por parte de los interesados y se procede a enviarse un correo con la aprobación del requerimiento. Informe de requerimientos CONTENIDO DEL DOCUMENTO DE REQUERIMIENTOS Introducción Alcance En esta sección se delimita el alcance del documento de requerimientos. Propósito Esta sección se refiere al compromiso propuesto, a las metas fijadas en el contrato y no al documento de requerimientos. Documentos aplicables En esta sección se listan referencias, normas y demás documentos que sean apropiados para la tarea propuesta. Información técnica y requerimientos 

Cuáles son las características deseables de una buena especificación de Requerimientos.



Dominio del Sistema, Requisito Funcional, requisito No Funcional y Reglas del negocio Procesos, identificando y aclarando los tipos de procesos, así como sus características, metodologías.



Información fundamental Esta sección es usada típicamente para describir alguna solución existente al problema y proveer información adicional que sea relevante. En algunos casos esta información puede ser muy extensa y podría estar contenida en volúmenes separados o estar citada como referencia.

Definición del sistema Es una descripción del sistema deseado desde el punto de vista de entradas, funciones y salidas. El propósito de esta sección es informar sobre el ambiente en el cual debe funcionar el sistema. Los siguientes ítems son típicos de la clase de información que debe incluirse normalmente en esta sección.

   

Diagrama jerárquico o de bloques que describa la estructura del sistema. Diagrama de flujo de datos para el sistema. Descripción de la base de datos, si existe, que el sistema debe mantener. Definición y descripción de todas las variables controladas

Requerimientos técnicos Contiene la información técnica que será usada para determinar una solución aceptable, de acuerdo con las necesidades que dieron origen al contrato. Define claramente las tareas que se van a ejecutar. Requerimientos de confiabilidad y mantenimiento Detalla los requerimientos de confiabilidad y mantenimiento para el sistema propuesto.

Procedimientos para pruebas de aceptación Se ocupa de los procedimientos usados para determinar si el sistema completo cumple sus especificaciones

Estas especificaciones tienen el objetivo de que el usuario de este sistema continúe en el futuro con el desarrollo de más aplicaciones que ayuden al mejor funcionamiento del producto que tiene como función mantener al cliente actualizado sobre el estado del equipo que llevo para su mantenimiento, así como el administrador apuntar sus observaciones sobre el equipo recibido y sus especificaciones. Estas especificaciones tienen el objetivo de detallar de forma concisa cada necesidad planteada mediante la recoleccion de informacion, para así poder garantizar la construccion de un sistema óptimo.A su vez garantizara formalmente que todas las necesidades expuestas sean expresadas y solucionadas mediante la implementacion, contruccion y ejecucion del aplicativo.

https://sites.google.com/site/metodologiareq/capitulo-iii https://www.wikiteka.com/apuntes/que-es-un-requerimiento/ https://books.google.es/books?hl=es&lr=&id=gQWd49zSut4C&oi=fnd&pg=PR14&dq= requerimientos+software&ots=s745pqtBqf&sig=Svvafq6p1rHuDbbo5MxAkwHbxis#v= onepage&q=requerimientos%20software&f=false