En esta oportunidad les comparto un artículo relacionado a la gestión de requisitos, lo cual es parte fundamental en todo proyecto de desarrollo de software.
1. INTRODUCCIÓN
Entonces, para atacar estos riesgos o problemas que pueden suceder en cualquier proyecto de software, es necesario aplicar buenas prácticas en la gestión de los requisitos ya que los requisitos guían el desarrollo del sistema en todo el ciclo de vida.
En todo proyecto de desarrollo de software, sobre todo en proyectos medianos o grandes, el analista debe capturar y describir los requisitos que los clientes o usuarios desean que el sistema haga o cumpla. Sin embargo, no basta sólo con capturar y describir los requisitos para que sean entregados a los diseñadores y desarrolladores de software, sino que también es necesario hacer una adecuada gestión de los mismos a lo largo del proyecto o ciclo de vida del sistema que se está desarrollando. En consecuencia, muchos proyectos de software fracasan debido a una mala o escasa gestión de los requisitos y este fracaso se puede percibir cuando el producto entregado no satisface las expectativas de los clientes o usuarios, o cuando los requisitos no han sido cumplidos por el sistema, es decir, no se ha construido el producto correctamente o no se ha construido el producto correcto.
Entonces, para atacar estos riesgos o problemas que pueden suceder en cualquier proyecto de software, es necesario aplicar buenas prácticas en la gestión de los requisitos ya que los requisitos guían el desarrollo del sistema en todo el ciclo de vida.
Por tanto, en este artículo se describen y comentan conceptos relacionados a los requisitos y las buenas prácticas. Para ello, el artículo se ha organizado de la siguiente manera: en la Sección 2 se muestra un breve marco teórico relacionado a los requisitos; en la Sección 3 se describe la forma de asumir la gestión de los requisitos aplicando buenas prácticas; en la Sección 4 se presentan las conclusiones; y en la Sección 5 las recomendaciones finales.
2. MARCO TEÓRICO
A continuación se describe los principales conceptos asociados al tema tratado.
Requisitos:
Los requisitos son capacidades y condiciones con las cuales debe ser conforme el sistema y más ampliamente, el proyecto [3].
Gestión de requisitos:
La gestión de requisitos es un enfoque sistemático para encontrar, documentar, organizar y hacer el seguimiento de los requisitos cambiantes de un sistema [4].
Tipos de requisitos:
Los requisitos de pueden clasificar de acuerdo al modelo FURPS+ [4], que significa los siguientes cinco tipos de requisitos:
- Funcionalidad (Functional).
- Usabilidad (Usability).
- Fiabilidad (Reliability).
- Rendimiento (Performance).
- Soporte (Suppotability).
El "+" de FURPS+ incluye los otros siguiente tipos:
- Restricciones de diseño.
- Requisitos de implementación.
- Requisitos de la interfaz.
- Requisitos físicos.
- Requisitos legales.
Algunos de estos requisitos se denominan colectivamente atributos de calidad o requisitos de calidad de un sistema. Estos comprenden usabilidad, fiabilidad, rendimiento y soporte. También se pueden clasificar en requisitos funcionales, la F de FURPS+ (comportamiento), y requisitos no funcionales (todo lo demás) [2].
Niveles de requisitos:
Los requisitos pueden estar descritos a diferentes niveles de detalle y se definen como [1]:
- Necesidad: un requerimiento de un interesado (Stakeholder).
- Característica: un servicio proporcionado por el sistema, por lo general formulada por un analista de negocios; un objetivo de una característica es cumplir con una necesidad de los interesados.
- Caso de uso: una descripción del comportamiento del sistema en términos de secuencia de acciones (requisito funcional).
- Requisito suplementario: otro de los requisitos (por lo general es un requisito no funcional) que no pueden ser capturados en los casos de uso.
- Escenario: una secuencia específica de acciones; un camino específico a través de un caso de uso.
- Caso de prueba: una especificación de entradas de prueba, las condiciones de ejecución y los resultados esperados.
La siguiente figura muestra las relaciones que existen entre los diferentes niveles de requisitos.
Rastreabilidad:
La rastreabilidad es la capacidad para rastrear un elemento del proyecto hasta otros elementos del proyecto relacionados, especialmente los que están relacionados con requisitos [4].
3. GESTIÓN DE REQUISITOS Y BUENAS PRÁCTICAS
Si bien, la gestión de requisitos en proyectos de software ya es considerado una buena práctica en la ingeniería de software, muchas veces se cometen errores en esta actividad.
Mucho de los errores cometidos en la gestión de los requisitos se debe a la mala documentación, descripción o especificación de los mismos. O peor aún, a la falta de documentación o especificación. Si bien es cierto que la documentación o especificación de los requisitos demanda esfuerzo y tiempo en los proyectos, este esfuerzo y tiempo consumido puede ser necesario para garantizar que lo que se va a construir esté acorde a lo requerido y por tanto los interesados (el cliente o usuarios) y el grupo de desarrollo estén de acuerdo. La documentación o especificación de los requisitos definen un contrato entre los interesados y el grupo de desarrollo. A parte de esto, la especificación de los requisitos sirve para las pruebas funcionales y las pruebas de aceptación del producto final. Por ejemplo, los casos de prueba serán elaborados en base a los distintos escenarios de los casos de uso, todos los escenarios deberán ser probados para garantizar que la funcionalidad está bien implementada. Sin embargo, no se trata de documentar por documentar los requisitos. Es decir, los requisitos deben ser documentados o especificados a diferentes niveles de detalle y dependiendo de la complejidad de los procesos o sistema a desarrollar. Para esto es necesario distinguir los diferentes tipos de requisitos y los diferentes niveles que se pueden aplicar, esto ayuda también a la organización y seguimiento de los requisitos. En el marco teórico se ha descrito los tipos de requisitos y sus diversos niveles. Por otra parte, es importante entender que la documentación o especificación de los requisitos debe seguir un proceso metodológico. Otra buena práctica en la ingeniería de software es asumir un proceso iterativo e incremental y no un proceso lineal o en cascada. Por tanto, los requisitos se especifican a diferentes niveles de detalle en diferentes iteraciones según cómo vaya avanzando el proyecto o se haya planificado. Por ejemplo, en la primera iteración se deben capturar y describir la mayor cantidad de las necesidades de los interesados. Estas necesidades están descritas de la manera como lo perciben o definen los interesados del sistema. Mayormente están descritas de una forma general y poco detallada o precisa, pero ayudan a entender la magnitud del sistema que se desea. También ayudan en la estimación inicial del esfuerzo para el proyecto. Una necesidad para un Sistema de Biblioteca puede ser: NEC01 - El sistema deberá permitir realizar el préstamo de libros. Esta necesidad (requisito de alto nivel) nos da una idea general o un primer alcance de lo que se desea para el Sistema de Biblioteca. Luego, según se vaya entendiendo mejor el requisito, se puede derivar o expresar en una o más características que detalla un poco más el requisito inicial. Estás características pueden ser: CAR01 - El sistema deberá permitir registrar el préstamo de libros solicitando como datos de entrada obligatorio el código del ejemplar, el DNI del solicitante y capturar de forma automática la fecha y hora del sistema; y CAR02 - El sistema deberá mostrar un mensaje de advertencia si el solicitante tiene algún préstamo pendiente y no dejar registrar el nuevo préstamo. Si nos damos cuenta, las características CAR01 y CAR02 están asociadas y provienen de la necesidad NEC01. Esta descripción de requisitos en necesidades y características se pueden agrupar y documentar en un solo documento llamado Visión. La Visión es un producto de trabajo muy utilizado en RUP y que ayuda en la gestión de los requisitos. Por tanto, es conveniente elaborar la Visión en la primera iteración del proyecto describiendo las principales necesidades y características. Hablando en términos de RUP, la primera iteración del proyecto pertenece a la fase de Inicio y es donde se deben capturar los principales requisitos y evaluar la viabilidad del proyecto. Si el proyecto es viable, se planifica la siguiente iteración. Se recomienda que una iteración deba durar entre 2 a 6 semanas, esto si es que el grupo de desarrollo no es muy grande (menos de 15 personas por iteración), de lo contrario podría demandar más tiempo. En la segunda iteración, que en términos de RUP podría pertenecer a la fase de Elaboración, el documento Visión puede ser actualizado o refinado con más necesidades y características. Las necesidades y características podrían estar descritas como requisitos funcionales o no funcionales. La necesidad NEC01 y las características CAR01 y CAR02 están descritas como requisitos funcionales. Otra necesidad para el Sistema de Biblioteca puede ser: NEC02 - El sistema deberá ejecutarse en Web y tener una navegación fácil y clara. De igual forma, este requisito no dice mucho pero así lo pensó el interesado y el analista tendrá que plasmarlo en el documento Visión. La necesidad NEC02 es un requisito no funcional y puede ser detallado un poco mejor en características. Estas características son descritas por el analista según vaya entendiendo mejor el requisito o se vaya concretando con el interesado. Así, las características que pueden derivar de la necesidad NEC02 son: CAR03 - El sistema deberá ejecutarse en los navegadores Internet Explorer y Mozilla Firefox; y CAR04 - El sistema deberá mostrar una barra de menús de dos niveles como máximo en la página principal y una barra de herramientas con botones de acceso rápido a las funciones más importantes. Y con la lista de necesidades y características descritas en el documento Visión, el analista puede ir encontrando casos de uso y requisitos suplementarios. Los casos de uso describen requisitos funcionales y los requisitos suplementarios describen requisitos no funcionales. El caso de uso debe ser el artefacto más importante en la gestión de los requisitos porque permite definir la funcionalidad del sistema y especificar mejor el requisito en un conjunto de acciones del actor y el sistema. También, otra técnica para encontrar casos de uso es identificar los actores que interactuarán con el sistema. Estos actores buscan objetivos a cumplir con el sistema y de esos objetivos se pueden derivar los casos de uso. Entonces, siguiendo con el proceso metodológico, a partir de la segunda iteración se pueden especificar los casos de uso. Por cuestiones de agilidad en el proyecto, una buena práctica sería especificar en detalle, con flujo básico y flujos alternativos, sólo los casos de uso de alta prioridad que pueden ser los de mayor riesgo o complejos, los de mayor relevancia para el negocio, o los más significativos para la arquitectura. Los casos de uso de media o baja prioridad se pueden especificar a partir de la tercera iteración y en menor detalle, incluso no es necesario describir su flujo básico y flujos alternativos. Para la especificación detallada se pueden usar los modelos o plantillas descritos en [1], [4] o [5]. Así mismo, un caso de uso de alta prioridad podría ser especificado en varias iteraciones, por ejemplo, en una iteración se podría especificar en detalle el flujo básico y en la siguiente iteración los flujos alternativos e incluso refinar el flujo básico. Así, retornando al ejemplo del Sistema de Biblioteca, un caso de uso que podría derivar de la necesidad NEC01 y de las características CAR01 y CAR02 es: CU01 - Registrar préstamo de libros. Este caso de uso podría ser considerado de alta prioridad por ser de gran relevancia para el proceso de negocio de la biblioteca, por tanto, debe ser especificado en detalle con su flujo básico y sus flujos alternativos. Por otra parte, los requisitos suplementarios también derivan de las características detallando aún más el requisito. El requisito suplementario que puede derivar de la característica CAR03 es: SUP01 - El sistema deberá ejecutarse en los navegadores Internet Explorer versión 7 y superior, y Mozilla Firefox versión 8 y superior. Los requisitos suplementarios se pueden clasificar según el modelo FURPS+ y ser descritos en el documento Especificaciones Suplementarias como lo maneja RUP. Los casos de uso y los requisitos suplementarios son los que se tomarán en cuenta para el diseño, la implementación y las pruebas. Los casos de uso son necesarios para las pruebas funcionales y de aceptación, y los requisitos suplementarios son necesarios para las pruebas de sistema que tengan que ver con pruebas de rendimiento, pruebas de seguridad, pruebas de usabilidad, pruebas de carga y volumen.
Otro de los errores que se comenten en la gestión de los requisitos es la falta de seguimiento. Debemos tener presente que a pesar que se describan o detallen los requisitos como en los casos de uso, estos puede cambiar con el tiempo. Por lo tanto, es necesario asegurar que los requisitos se mantengan actualizados a lo largo de las iteraciones del proyecto. Los requisitos por lo general van tomando forma o van madurando según transcurra las iteraciones, esperando que estén lo suficientemente maduros y estables a partir de la 4 o 5 iteración. En RUP esto puede equivaler a las iteraciones de la fase de Construcción. Sin embargo, algunos requisitos pueden estar cambiando en la fase de Construcción e incluso en la fase de Transición lo cual se torna más riesgoso para el proyecto. Entonces, para poder hacer un adecuado seguimiento y cambio a los requisitos, es necesario realizar la rastreabilidad de los mismos. Esto se puede lograr gracias a una buena organización y relación entre los diversos niveles de requisitos. Por ejemplo, en el sistema de Biblioteca, si la funcionalidad ya implementada de registrar un préstamo de libro debe cambiar en algún aspecto por requerimiento del interesado, el analista deberá identificar a qué caso de uso corresponde el cambio, y además, deberá identificar qué otros requisitos se ven afectados, es decir, por ejemplo, que a partir del caso de uso CU01 se identifica las características CAR01 y CAR02, y a partir de las características se identifica la necesidad NEC01. En consecuencia, los requisitos podrán ser rastreados y actualizados en todos los niveles.
4. CONCLUSIONES
Podemos concluir que se hace necesaria la gestión de requisitos en todo proyecto de software, sobre todo en proyectos medianos y grandes que demanden un gran número de requisitos y muchas personas involucradas en la gestión, análisis, diseño, implementación y pruebas. Seguir las buenas prácticas y aplicar las técnicas adecuadas nos ayudan a asegurar éxito en los proyectos.
5. RECOMENDACIONES FINALES
Para completar el artículo, se recomienda lo siguiente:
- Seguir un proceso iterativo e incremental.
- Gestionar el proyecto de forma ágil, esto implica: utilizar sólo la documentación necesaria que agregue valor al proyecto o sirva realmente para la gestión; planificar iteraciones cortas con objetivos bien definidos; seleccionar los artefactos adecuados para el proyecto; detallar los requisitos (casos de uso) sólo cuando sean necesarios; planificar actividades de revisión de requisitos periódicamente involucrando a los analistas, programadores e interesados.
- Usar herramientas de modelado y gestión.
- Hacer uso de guiones gráficos o prototipos de GUI para ayudar en la especificación de los requisitos funcionales o casos de uso.
REFERENCIAS BIBLIOGRÁFICAS
[1] Peter Zielczynski, Requirements Management Using IBM Rational RequisitePro. 1ª edición. IBM Press, 2008.
[2] Craig Larman. UML y Patrones, Una Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado. 2ª edición. Pearson, 2003.
[3] Jacobson, Booch, Rumbaugh. El Proceso Unificado de Desarrollo de Software. 1ª edición. Pearson, 2000.
[4] The Rational Unified Process Product. The browser based online documentation for the RUP. IBM Corporation 2007.
[5] Alistair Cockburn. Writing Effective Use Cases. 1ª edición. Addison-Wesley, 2001.
Hola a todos, invito a participar con sus comentarios o aportaciones.
ResponderEliminarComo sabemos Para que un cliente este satisfecho con un proyecto debe explicar de forma clara sus requisitos con sus características, así siendo entendido por el analista de sistemas para aplicar la gestión de requisitos y características teniendo un desarrollo que guiara un sistema de ciclo de vida aplicativo de calidad y un proyecto de calidad .
ResponderEliminarHola Paolo.
EliminarTener presente que en muchos casos los clientes no explican bien sus requisitos y ni siquiera los tienen claro lo que desean. Por tanto recae mucha responsabilidad en los analistas saber y lograr capturar e ir concretando el requisito con el cliente. Los requisitos van madurando según avanza el proyecto, por eso es necesaria una correcta gestión.
Saludos.
Prof. Lain:
ResponderEliminarGracias por compartir este artículo tan valioso especialmente para aquellas personas que desarrollan o implementan software, el tema de las buenas practicas como punto de partida es esencial, este artículo lo detalla de forma clara y precisa, así como también tener en cuenta que en cada proyecto de desarrollo de un sistema se debe conocer el proceso de la Unidad de Negocio...
Hola Judith.
EliminarCorrecto lo que concluyes, siempre es necesario entender los procesos de negocio antes de describir los requisitos de software. Entendiendo y modelando los procesos de negocio los analistas de sistemas definirán de mejor forma los requisitos y estarán alineados a los objetivos del negocio. En posteriores publicaciones hablaré sobre el modelado de procesos de negocio, saludos.
Muy interesante con el FURPS+ podemos utilizar un buen enfoque para elaborar software y saber que tipo características y restricciones le vamos añadir al software para así elaborar una buena gestión de requisitos y necesidades que tienen los usuarios para obtener un producto(software) de calidad.Saber cuales son las Características, Necesidades y hacer de Casos de Uso como en el ejemplo que menciono de la biblioteca y este blog son de gran ayuda para futuros profesionales.
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminarLa más interesante de como se elabora en la gestión de requisitos, es la realización de los procesos generales (requisito de alto nivel)
ResponderEliminarse genera soluciones óptimas a través de subsoluciones eficaces a generar subprocesos(los requisitos necesarios para la realización del principal)que ayuda a que la elaboración llegue a ser más sencilla.
Como dice muchas vez el cliente no tiene sus ideas claras eso también aria que el analista tome más de 2 o 6 semanas en hacer las iteración si en caso que se tome más tiempo a mi opinión creo que eso sería mejor ya que el analista analizaría mucho mejor las iteración y de tener más reuniones con el cliente así aria un buen caso de uso .
ResponderEliminarRUP(Rational Unified Process) es conocido como la “mejores prácticas” que ayuda poder tener un buen desarrollo de software y que sus partes más importantes es la administración de requerimiento y la notación de los casos de uso
El tema de gestión de requisitos es muy importante en la relación del proyecto, porque estos definen en esencia la funcionalidad y características que tendrá el sistema.
ResponderEliminarMuchos proyectos fracasan por la ineficiente gestión y análisis de los requerimientos que desea el cliente para su sistema, u otros aspectos como:
- Cambio de prioridad del negocio.
- Porque el analista comprendió de modo diferente las especificaciones que quería el cliente.
- Porque el cliente cambio el ambiente de negocio.
- Porque se cambio el problema que se esta resolviendo.
Estas son algunas de las frecuentes razones por las que fracasan los sistemas y por ende los proyectos,porque solo una vez se tuvo entrevista con el cliente para hacer la especificación de requisitos y no tener en cuenta que estas pueden cambiar a lo largo de la realización del proyecto.
Para tener un buen resultado en la realización del proyecto debemos definir los tipos y niveles de requisitos de manera adecuada siempre estando en una constante comunicación con el cliente para informarnos de cualquier cambio que se pueda presentar.
Este artículo nos aclara muchas dudas acerca de desarrollo o implementación de software, el tema de las buenas practicas como el de seguir un proceso iterativo e incremental nos facilita mucho el trabajo el cual se hará mas flexible a cambios o mantenimientos, con respecto a los niveles de requisitos es la manera mas eficiente de seguir un proyecto con el fin de ver el comportamiento del sistema y cumplir con las metas propuestas por iteración o por nivel.Excelente aporte.
ResponderEliminarEn este articulo podemos apreciar lo que nos ofrece el modelado de negocio con vision general de la organizacion a la que se le va a desarrollar el sistema automatizado de informacion mientras que la gestion de requisitos centra su actividad en la especificacion de la informacion correspondiente a cada proceso y la manera en que se van a representar estas en el producto final y para ello se apoya en los requisitos funcionales, no funcionales y casos de uso.
ResponderEliminarSe puede concluir que el correcto desarrollo de estas etapas resulta imprescindible para la obtención de un producto final de calidad.
Nota: Para agregar algo adicional sobre los casos de uso
s una buena herramienta para la captura y el análisis de requisitos. Los casos de uso permiten definir de forma sencilla el comportamiento del sistema desde el punto de vista de interacción con el usuario u otros sistemas.
Un caso de uso es una descripcion textual de la secuencia de interacción de los usuarios (actores) con el sistema. Al escribir el caso de uso se considera al sistema como una “caja negra”, ya que no nos importa lo que sucede dentro sino las posibles interacciones entre el sistema y el usuario.
"no todo lo que se programa es CÓDIGO" esta frase hace referencia a que de nada sirve tener los mejores programadores del mundo y un sistema de gestión pésimo y/o incompetente, esta es la razón por la cual de debe de tener un adecuado y meticuloso sistema de gestión con el cual cubra los tipos de requerimientos(obtención de requisitos, definición, verificación y revisión) como por ejemplo: funcionalidad, Usabilidad,Fiabilidad, Rendimiento, Soporte, etc.
ResponderEliminarAdemás también se tiene que tomar muy en cuenta los roles()y las responsabilidades; por último seguir las mejores prácticas en este desarrollo de los requisitos:
Documentar el alcance y visión del proyecto: permitirá tener un mejor entendimiento de los requisitos y asegurará que todas las personas involucradas en el proyecto trabajen hacia la misma meta.
Mantener un glosario del proyecto: facilitará una comunicación efectiva asegurando un entendimiento unánime.
Uso de técnicas de obtención de requisitos de usuario: para facilitar esta tarea.
Involucrar a toda la gente implicada: asegura una validación temprana del entendimiento de los requisitos.
Desarrollo incremental de requisitos: puede minimizar la cantidad de re-trabajo del proyecto.
Captura de requisitos usando casos de uso: será más fácil gestionar los requisitos y hacer un seguimiento de los mismos.
Validar requisitos: para mejorar el éxito de los proyectos es crítico que se validen los requisitos de forma adecuada.
Verificar requisitos: para asegurar que los requisitos proporcionan una base adecuada para llevar a cabo el diseño, la construcción y las pruebas.
Priorizar requisitos: para determinar aquellos que se deberían cumplir en la primera versión o producto y aquellos que pueden llevarse a cabo en sucesivas versiones.
Establecer líneas base de los requisitos: para asegurar que cualquier modificación en los requisitos que cambie la línea base se trata como cambios de alcance.
Comunicación abierta: para asegurar que la información relacionada con los requisitos se comunica de forma consistente. Una comunicación abierta también implica comunicar a la gente correcta y al conjunto mínimo de personas.
Gestión de cambios de los requisitos: es esencial gestionar estos cambios de forma efectiva y eficiente.
Uso de herramientas para la gestión de requisitos: para facilitar la gestión de requisitos.
Mantener trazabilidad de requisitos: para llevar un seguimiento de la vida de un requisito.
Establecer un plan de mejora de procesos para la ingeniería de requisitos: para cumplir con las necesidades actuales y futuras de forma más eficiente y con mayor calidad.
Formar a los analistas de requisitos: para asegurar que los analistas de requisitos tienen el conocimiento, entre otros aspectos, de cómo escribir buenos requisitos, etc.
esta es una url interesante que encontré!
ResponderEliminarhttp://www.delonia.com/?page=servicios_calidad
Buen aporte, Ing.Lain Cárdenas Escalante, sobre el tema de los SURPS muy interesate. Pero gustaria dejar un pequeño aporte sobre ese tema.
ResponderEliminarEl modelo FURPS incluye, factores de calidad y los atributos, restricciones de diseño y requerimientos de implementación, físicos y de interfaz. Una limitación de este modelo de calidad es que no tiene en cuenta la portabilidad de los productos software que se estén considerando, factor digno de consideración en función de las exigencias actuales que recaen sobre el proceso de desarrollo del software.
Mauro Ángel Sánchez Suárez
Hola Mauro, agradezco tu comentario, pero para precisar mejor, la el requisito del tipo Soportabilidad también incluye otros tipos que son:
EliminarCapacidad de prueba
Adaptabilidad
Mantenimiento
Compatibilidad
Configurable
Capacidad de actualización
Facilidad de instalación
Escalabilidad
Portabilidad
Interoperabilidad
Conformidad
Remplazabilidad
Cambiabilidad
Saludos.
Gracias por el dato eso nu sabia jojojojo, saludos
EliminarSi bien es cierto los mejores productos, desde el punto de vista del usuario, son aquellos creados por desarrolladores que tienen muy claro lo que se pretende conseguir con el producto y cómo obtenerlo. Para llegar a este punto, se debe entender el trabajo del usuario, cómo afectará el producto a su trabajo y cómo se adecuará a los objetivos de la organización.
ResponderEliminarEs ahí donde interviene la obtención de requisitos que se define como el proceso de identificar las necesidades del negocio, solucionando las posibles disparidades entre las personas involucradas en el mismo, con el propósito de definir y destilar los requisitos para cumplir las restricciones impuestas por las distintas partes.
Se dice que un buen proceso de obtención de requisitos soporta el desarrollo de la especificación de los requisitos, de tal forma que tengan los siguientes atributos:
-Deben ser completos, consistentes y han de estar dentro del alcance del proyecto
-Deben tener un único identificador
-Cumplen con los objetivos de los clientes
-Son viables y apropiados para el desarrollo
-Los requisitos han de ser “testeables” (deben tener capacidad de prueba).
Definir bien los requerimientos es un procedimiento muy importante durante el desarrollo de un software ya que serán estos los que indiquen que funciones tendrá el software y de que manera las va a ejecutar, por ello es importante primero tener bien definida esta parte para empezar a programar las funciones del software. Si los requerimientos del sistema no están bien definidos (ya sea por que el cliente no explico bien su necesidad o por que el analista malinterpreto tal necesita; esto suele pasar por que el lenguaje natural es muy ambiguo) el producto final puede que no satisfaga las necesidad del cliente.
ResponderEliminarSamir Morales Cuevas
Si bien la gestión como el desarrollo de requisitos son procesos contemplados por los principales modelos de mejora de procesos orientados al desarrollo de software.
ResponderEliminarEn si los modelos de mejora de procesos que describen los procesos que una organización debe ejecutar para la adquisición, desarrollo y mantenimiento de productos y servicios software.
Puede que el propósito de la gestión de requisitos es gestionar los requisitos de los productos del proyecto y de sus componentes e identificar las inconsistencias entre requisitos, planes del proyecto y productos de trabajo.
-Desarrollar los requisitos de cliente
-Desarrollar los requisitos de producto
-Analizar y validar los requisitos
En si en conclusión : Una eficiente gestión de requisitos a lo largo de todo el ciclo de vida del proyecto contribuye eficazmente a la calidad del producto final y al grado de satisfacción del cliente.
Este artículo deja muy en claro la importancia de la buenas practicas y la buena gestión de requisitos, ya que son la semilla para que un producto satisfaga las necesidades de los clientes.
ResponderEliminarTodo se empieza desde la buena documentación y especificación de los requisitos; ya que, si el cliente se da a entender con los requisitos, entonces el analista,los desarrolladores, todos aquellos que intervienen en el desarrollo del producto; podrán brindar un software que este acorde con los señalado anteriormente.
Conclusión: La gestión de requisitos y las buenas practicas son la base de todo buen proyecto(Satisfactorio para los clientes y usuarios).
Sabemos que es necesario hacer una adecuada gestión, a lo largo del proyecto o ciclo de vida del sistema que se está desarrollando, para que el cliente este satisfecho con un proyecto deba explicar de forma clara. Lo más interesante es que se elabora en la gestión de requisitos con características para el analista de sistemas.
ResponderEliminarMuy Interesante y muy útil para los nuevos desarrolladores ya que menciona todo lo que debemos tener en cuenta cuando se crea un nuevo programa. Donde lo más importante es la elaboración de requerimientos del sistema que se tienen que tomar con mucha cautela y en forma ordenada.
ResponderEliminarSeria de gran ayuda estimado profesor que amplíe un poco mas la información dada en la parte de "Niveles de requisitos".
Hola, me parece muy interesante la interracción entre el cliente y el grupo de desarrollo,por el hecho de que para desarrollar un sistema a una persona y más si tiene cierto grado de complejidad, primero deberiamos entender bien lo que requiere el cliente y permitirle darle seguimiento al producto en sus diferentes interacciones, el cliente es quien solicita el sistema y es quien va a hacer uso del mismo por ende su satisfacción debe ser la mayor prioridad del grupo desarrollar de ella va depender el éxito o fracaso del trabajo de los especialistas, que muchas veces no establecen esta buena relación con sus clientes, que son el por qué de su proyecto
ResponderEliminarHola: Buenas noches
ResponderEliminarEste artículo es bien útil para los desarrolladores ya que menciona todo lo que debemos de tener en cuenta para poder desarrollar e implementar un software de alta calidad.
Además con respecto a la gestión de los requisitos es muy importante realizar una muy buena documentación, descripción o especificación aunque generaría una demanda alta en esfuerzo y tiempo en los proyectos, pero a su vez teniendo en cuenta la especificación de los requisitos nos garantizará la aceptación de nuestro producto final a desarrollar por ende puedo concluir que la gestión de requisitos y las buenas practicas son la base de todo buen proyecto satisfactorio tanto para los clientes y los usuarios.
Para expandir un poco más nuestros conocimientos, se resaltará acerca de los prototipos...
ResponderEliminar¿Que es un PROTOTIPO?
Un prototipo es un borrador de un producto en otras palabras una simulación de los requisitos.
Algunos de los objetivos de los prototipos son:
- Desarrollar un modelo de trabajo de los componentes funcionales clave de un sistema.
- Mejorar la comunicación de los requisitos entre el analista, el usuario final y los miembros del equipo de desarrollo.
- Permitir a los usuarios finales y analistas explorar arquitecturas alternativas.
- Validar y verificar los requisitos del usuario final.
Beneficios
El uso de prototipos se debería usar para todos los sistemas interactivos. Hay que considerar que una revisión seria por los usuarios finales puede resultar casi siempre en un cambio.
Algunos de los beneficios que se obtienen son:
- Los prototipos fundamentalmente ayudan en la comunicación entre el usuario final y las personas encargadas del desarrollo.
- El usuario final consigue un mejor entendimiento del sistema propuesto que el que obtendría de una documentación escrita.
- Es más fácil para el programador construir un sistema desde un modelo de funcionamiento que desde un documento de diseño.
- Los usuarios finales son capaces de probar el diseño y proporcionar sus entradas antes de que el tiempo y el dinero se hayan expandido.
- Los prototipos hacen a un sistema ser más intuitivo y reduce la cantidad de documentación escrita requerida.
- Los prototipos animan y requieren la participación activa de los usuarios finales.
Dificultades
- La estructura de los prototipos se corrompe por cambios constantes.
- Los prototipos requieren una participación activa de los usuarios finales.
- Un prototipo no puede sustituir completamente una especificación en papel. Los prototipos deberían complementar, no reemplazar.
- Numerosas cuestiones de diseño no son y no pueden ser documentadas de forma adecuada mediante el uso de prototipos; estas cuestiones se pueden olvidar sin querer.
- Los prototipos con frecuencia conducen a un acuerdo prematuro del diseño físico.
Hola, seria bueno que te puedas identificar con tu nombre, saludos.
EliminarIng Los niveles de requisitos son muy importantes para la elaboracion de un buen software para la empresa que lo requiere. ¿Pero estos tambien son utiles para sacar el valor del Software para la empresa?.
ResponderEliminarPues sin una buena documentacion muchas veces se sobreestima el costo de una elaboracion de software que a la larga se va a aumentar considerablemente por no tener una buena documentacion de requisitos.
bueno para poder aplicar un software .. primero es preguntar al cliente como lo desea su aplicación ,pero cuando un cliente te explica solo podemos entender el 30% y el otro 70% ya esparte del analista o desarrollador , para eso se avanza un prototipo pequeño y mostrarlo al cliente si esto lo que el desea .
ResponderEliminar1er paso : si el cliente da el visto bueno del sistemas o aplicación que uno desarrolla de acuerdo de la necesidades de la empresa.
2do paso: el cliente da un plazo de 1 mes hasta 4 meses al analista o desarrollador para acabar el sistema .
3er paso : es implementar el sistema a la empresa por prueba de 15 días para ver si existe falla en la ejecución y se capacita a las personas que van a utilizar esta aplicación.
todo requisito es importante para ejecutar cualquier software y que sea beneficiado a la empresa que lo necesita .
PUBLICADO POR : PIER PAOLO GARCIA VILLALOBOS
ESTUDIANTE DE ING. DE SISTEMAS
Me parece interesante este aporte, ya que también se establecen mecanismos que garantizan la trazabilidad de los requisitos a lo largo de todo el ciclo de vida, hacia atrás, hacia delante y entre ellos. Esto permite proveer una relación entre requisitos, diseño e implementación del sistema y el reconocimiento temprano de aquellos que no son satisfechos y constituye un instrumento estratégico con enfoque proactivo, que permite al gestor del proyecto adoptar, desarrollar e implementar adecuadamente las actividades de gestión de los requisitos de una forma disciplinada, coherente y repetitiva con una eficiencia gestión de requisitos a lo largo de todo el ciclo de vida del proyecto que contribuye eficazmente a la calidad del producto final y al grado de satisfacción del cliente.
ResponderEliminarAlumno: Jean Pierre Alvarez Mendoza
Para poder aser un buen sistema lo primero es saber que es lo que quiere el cliente, pero al momento de hacer la consulta, este cliente puede saber lo que pide pero no solo sabe plasmar bien. Es por ello que se recomienda hacer sistemas el programa por etapas y si el cliente esta satisfecho continuamos con la siguiente.
ResponderEliminarY en cada eta enseñar al cliente para ver si esta satisfecho.
Jose Antonio Torres Plasencia
Muy interesante este tema ya que de los requisitos y de la forma como analicemos depende el software a crear y sus funcionalidades, por lo tanto el determinar los requisitos es basico y elemental.Me podria recomendar otro software aparte del Rational Requisit-Pro.Gracias por la informacion
ResponderEliminarSin lugar a duda en todo proyecto de desarrollo de software es muy importante captar los requisitos que los usuarios quieren que el software o sistema haga, y para eso es necesario hacer una buena gestión de los mismos para que así el cliente se sienta conforme. Resumiendo es un tema de mucha importancia para los analistas y diseñadores de sistemas porque es uno de los procesos mas importantes para desarrollar un software.
ResponderEliminarEs un tema muy interesantes, ya que es una base para generar éxitos en proyectos que realicemos a lo largo de nuestra vida pz el tema de la gestión de requisitos en todo proyecto de software es necesario ya que es un medio de comunicación con el usuario para lograr el objetivo general que es hacer lo que el usuario requiere..
ResponderEliminarPor otro lado le quería dar las gracias por poder brindarnos esta información que nos ayuda a tener mucho mas conocimientos y aprender día a día a desarrollar mejores proyectos e ir superándonos mas como buenos profesionales. GRACIAS!! Y muchas felicidades por su bebita que Dios bendiga y proteja a su familia todos los días de su vida muchas bendiciones; gracias.
Es un tema de vital importancia ya que comprende todos los aspectos de la producción de software; desde las etapas iniciales de las especificaciones del sistema hasta el mantenimiento de este después que se utiliza. Esto permite a las compañias competir mas efectivamente usando nuevos sistemas desarrollados para compararlos con sus necesidades en el negocio.
ResponderEliminarQue tal Ingeniero ! bueno acabando de leer este articulo me doy cuenta que para llegar a un buen desarrollo de Sw. es de suma importancia definir bien los requisitos porque es la base principal donde se van a recopilar datos de los usuarios y estos especificando como quieren que el sistema se realice o que características tenga el Sw. bueno en resumen los Analistas tienen que tener habilidad para esto para poder comprender lo que los usuarios desean ya que una de las principales fallas es por que ellos no se dejan entender y eso hace de que se haga una "falsa" documentación. Bueno Ing.Lain gracias por la información con esto queda mas que claro sobre las buenas practicas al momento de desarrollar un Sw.
ResponderEliminarSi bien es cierto que el analista debe capturar y describir los requisitos de los clientes, pero debe de seguir en contacto con los clientes para asi cada cierto tiempo( de acuerdo a cada iteración que es de 2 a 6 semana) mostrarle el avance y asi el cliente pueda ver si lo estan haciendo como el ha solicitado para que pueda satisfacer las expectativas del cliente.Por eso se debe realizar una buena gestión. Interesante tema Ing. Laín
ResponderEliminarRealmente un artículo bastante ilustrativo en lo referente a buenas prácticas en la gestión de requerimientos, lo cual estoy seguro nos servirá de guía en el desarrollo del proyecto planteado y mas adelante en el desenvolvimiento profesional.
ResponderEliminarMuchas gracias ingeniero Lain.
buen blog, dan a conocer los pasos correctos para el desarrollo de proyectos de software; te dan a conocer el tiempo para generar los objetivos, requisitos necesarios para el proyecto, para que los clientes esten satisfechos, obteniendo un producto de calidad que cubra sus necesidades requeridas.
ResponderEliminarPara realizar un proyecto de software , debemos tener ciertos detalles :
ResponderEliminartodo software tiene un ciclo de VIDA Y PROCESO.
1. Un buen análisis .
2. cumplir los requerimiento del sistema.
3. el diseño al detalle del software.
4. desarrollo.
5. ejecución del software.
6. capacitación y monitorio del software.
Con estos requisitos básicos, podemos tener un proyecto de calidad dentro de la Ingeniera de software con las buenas practicas .
La lectura en este blog nos deja claro ,con el conocimiento dela Aplicación de buenas prácticas en la gestión de requisitos.
PIER PAOLO GARCIA VILLALOBOS
ING DE SISTEMAS
Es una buena guia para corregir los errores que los ingenieros novatos tienen a la hora de crear soluciones para sus clientes.
ResponderEliminarCONCLUSION: Es importante capturar y describir los requisitos para que sean entregados a los diseñadores y desarrolladores de software es necesario aplicar buenas prácticas en la gestión de los requisitos ya que guían el desarrollo del sistema en todo el ciclo de vida, cuando el producto es entregado y satisface las expectativas de los clientes o usuarios, entonces es cuando los requisitos han sido cumplidos por el sistema, es decir, se ha construido el producto correctamente.
ResponderEliminarnombre: RUBIO FLORES CECILIA
curso:Analisis de diseño
ucv
es un articulo muy interesante especialmente para las personas que desarrollan e implementan software el tema de las buenas practicas, es esencial, este artículo lo detalla de forma clara y precisa, así como también tener en cuenta que en cada proyecto de desarrollo de un sistema se debe conocer el proceso de la unidad de negocio. También se establecen mecanismos que garantizan la fiabilidad de los requisitos a lo largo plazo de todo el ciclo de vida.
ResponderEliminarMuy buen artículo referente a las buenas prácticas en la gestión de requerimientos para poder empezar a construir un buen producto software, pero es importante tener en cuenta que hay que tener una constante comunicación con el cliente para ir capturando los requisitos de este.
ResponderEliminarLa gestión de requisitos y las buenas prácticas son la base de todo buen proyecto para que tanto clientes como usuarios queden satisfechos.
Excelente aporte ingeniero, es muy importante captar los requerimientos del cliente en la primera etapa del proyecto ya que en esta etapa debemos esforzaros mas por captar los requerimientos de los usuarios con el fin de que estos queden satisfechos con el producto.
ResponderEliminarUna adecuada gestión de requisitos nos asegura que los riesgos del proyecto disminuyan a pesar de que estos puedan cambiar durante las iteraciones, si se ha hecho un adecuado seguimiento de los requerimientos rápidamente podemos plasmarlo en la etapa en que se encuentre el proyecto.
Un requerimiento puede ser funcional y no funcional, estos pueden variar en el tiempo, por eso es necesario estar en constante contacto con el cliente para estar al tanto de estos, nuestro propósito principal como desarrolladores de software es brindar un software con el cual el cliente quede satisfecho y eso se logra haciendo uso de las buenas practicas en el proceso de desarrollo de software.
Muy buen articulo, la metodología y pasos a seguir del ingeniero de Sistemas son fundamentales para lograr un buen desarrollo del sistema.Pero hay una cosa que no tengo bien claro, la cual es que debe de hacer un ingeniero de Sistemas si se encuentra con la pequeña dificultad de que su cliente no puede definir bien los requerimientos y características que desea aplicar al software, si es cierto se debe desarrollar paso a paso y debe de existir una presentación de avance cada cierto tiempo pero si el cliente no tiene definido sus requerimientos entonces ¿El no debe de comenzar el proyecto hasta que quede claro los requerimiento del cliente? o ¿Puede aportar requerimientos?
ResponderEliminarHola, gracias por las preguntas, doy mis comentarios al repecto:
ResponderEliminarTodo proyecto siempre parte por una necesidad del cliente de querer mejorar en sus servicios o procesos de su negocio y para esto va a requerir un sistema informático. Por tanto el proyecto debe iniciarse por solicitud del cliente, tenga o no claro los requerimientos para el sistema que necesita. Entonces, es tarea y responsabilidad del Analista de capturar y especificar los requerimientos para el sistema aplicando técnicas y una adecuada metodología, así los requerimientos no estén definidos o claros para el cliente. Por lo general los clientes no tienen definido de una manera clara sus requerimientos, pero si pueden tener una visión muy general de lo que esperan para su sistema, por eso la metodología nos sugiere iniciar con un artefacto VISION que es donde podemos capturar las primeras necesidades generales del clientes, estas necesidades (requisitos de alto nivel) deberán ser cada vez más concretas según se vaya analizando mejor los requisitos y por eso el Analista irá definiendo y especificando en mayor detalle los requerimientos hasta llegar a los Casos de Uso (artefacto que describe en detalle los requerimientos funcionales). Es recomendable elaborar con ayuda del cliente el artefacto VISIÓN en las primeras dos semanas de iniciar el proyecto, luego sabremos más o menos qué se espera del sistema, además podemos ir estimando el tiempo o esfuerzo que demandaría y un costo aunque esto no debería ser algo concreto aún.
Otra forma de atacar los requisitos desconocidos para el sistema, es analizar primero los procesos de negocio que están más directamente vinculados o relacionados con el sistema que vamos a desarrollar. A partir de este análisis de los procesos que implica identificarlos y modelarlos se podrá identificar también los requerimientos e ir elaborando el artefacto Visión.
Por último, si el Analista tiene experiencia y conocimiento del proceso que está analizando, podrá aportar con la definición de los requerimientos pero siempre con aprobación del cliente. No olvidar que es conveniente que el Analista siempre debe trabajar con un experto del dominio (cliente o usuario conocedor del dominio o proceso de negocio) para poder analizar y definir adecuadamente los requisitos del sistema.
Saludos.
Un muy buen aporte el cual nos explica muy correctamente el ciclo del software por el cual obligatoriamente debe pasar todo producto desarrollado antes de ser dado al usuario final , nos da buena informacion sobre el tiempo que se establece a principio de todo proyecto el cual en la mayoria de casos no cumplimos por cualquier contratiempo, siempre es bueno ser precavido en todo ello
ResponderEliminarWilliam Rojas Zuñiga
ResponderEliminarla importancia de tener en cuenta varios puntos claves en la que muchos proyectos de software no consideran o pasan desapercibidos seria el fracaso por la mala gestion de requisitos; por ello los requisitos deben ser documentados a diferentes niveles de detalle, se debe asumir un proceso interativo e incremental conforme se vaya avanzando el proyecto, y se deben mantener actualizados los requisitos con el transcurso de las iteraciones del proyecto.Todo esto conlleva esfuerzo y tiempo tomado pero serviria de mucho para el desarrollo e implementacion de los proyectos de software y satisfacer lo que el cliente requiere.
Alumna : Thania Heldy Hernandez Perez
ResponderEliminarComo podemos ver en este articulo. La creación de un software no es simplemente diseñar y programar, sino que para el logro de este es necesario seguir diferentes pasos los cuales nos ayudaran a crear un software de calidad y la satisfacción del cliente. y lo mas importante para mi es siempre estar en contacto con el cliente ya que esto ayuda a que estemos actualizados todo el tiempo y poder crear un software que sera de gran utilidad para el cliente y los que lo usen.
Alumno Pereda Morales Deyvi.
ResponderEliminarEste artículo deja muy claro la importancia que tiene las buenas o mejores practicas...el detalle es comprometerse con el cliente e ir de la mano conjuntamente, ademas como futuros ingenieros de sistemas debemos tener en cuenta que en muchos de los casos los clientes o entidades con las que trabajaremos y que solicitan servicios, no explican bien sus requisitos u necesidades y en el peor de los casos no tienen en claro lo que desean. Por ende recae mucha responsabilidad en los analistas de sistemas; el saber y concebir capturar las ideas mas importantes e ir dilucidando los requisito con el cliente. Una buena gestión con respecto a los requisitos, lograra un avance significativo en el proyecto a realizar.puesto que un proyecto de software tiene un proceso y un tiempo de desarrollo.
Solo para terminar ... Ing. cual serian las pautas para realizar un buen análisis e identificar las ideas que nos quieren brindar (los clientes)?
Alumno:Guayan Castillo Juan Carlos
ResponderEliminarpodemos darnos cuenta de que no solo se le deba dejar el trabajo al analista de capturar todos los requerimientos del cliente sino que en gran parte debe haber una coordinación entre todos para lograr satisfacer los requerimientos pedidos y creo que el analista es el puente entre el cliente y un buen proyecto
como se que mi proyecto no fracasara pues es no soltar al cliente en todos las iteraciones que se deban hacer pues como se dijo a veces el cliente dice una cosa y luego sus necesidades cambian a lo largo del proyecto por eso se debe tener en cuenta una estructura bien definida también es de mucha ayuda mostrar prototipos o betas al cliente si es de su agrado y para saber si vamos por el buen camino gracias por la información
Cuando se inicia un Proyecto se traza como Objetivo desarrollar un Software de Calidad que cumplan o superen las expectativas del Cliente y/o Usuario pero lo más importante logre Optimizar los Procesos. El crear un Software de Calidad es una gran preocupación a los que se le dedican muchos esfuerzos.
ResponderEliminarEste artículo nos brinda información sobre los "Requisitos" que son aquellas condiciones que son el pilar del Software. Dichos requisitos los obtenemos durante la etapa de Análisis de la Organización donde el Cliente nos informa sobre los Requerimientos. El registro de Requerimientos pueden ser modificados e incrementados durante el Proceso del Desarrollo del Software en las Pruebas de verificación con el Cliente.
ing. Lain
ResponderEliminarEn la parte de Niveles de requisitos el cliente vendría a darnos su necesidad y vendría hace el actor del negocio pero cuando hablamos de las caracterizas, en este caso el actor del negocio seria el encargado de describir las características osea el analista?
Alumna :Aredo Rojas Judy Marivel
ResponderEliminarlos pasos a seguir para desarrollar la gestión de un proyecto son claras y se deben manejar de una forma secuencial para que cada requisito este completo y claro donde no se escape información valiosa .pero mi duda esta reflejada en cuando se tiene que desarrollar un software para una empresa y esta empresa no esta bien definida sus desiciones y cambia constantemente cuando tardaría cada iteracion para poder desarrolllar un software completo?
Muy buen aporte, sobre todo al detallarnos las partes y procesos que debemos realizar y tener presente al momento de Desarrollar algún proyecto o Software, pero lo que mas importante se puede rescatar de este aporte es que nos ayuda a comprender que no debemos dejar de lado al cliente, ni mucho menos abandonarlo, cada paso que demos en el desarrollo del SW debemos de consultar con el cliente para que de este modo el pueda entender y aclarar lo que necesita y nosotros a la vez podamos ayudarlo y entenderlo. Todo esto nos ayuda a la buena practica para la gestión de Requisitos.
ResponderEliminarGracias.
Estudiante: Flavio Kevin, Ku Sosa
ResponderEliminarEste articulo esta muy interesante Ingeniero,especialmente cuando tenemos ese tipo de problemas con los clientes debido a que en la fase de desarrollo del software,no hemos mantenido una constante comunicación con los clientes y por ende nuestro trabajo aunque halla sido el mejor elaborado no cubriría con las expectativas de los clientes o usuarios y hay que pensar seriamente en recordar que los requerimientos son muy importantes durante el desarrollo del software.
Ingeniero mi pregunta en el articulo menciona que:"para poder hacer un adecuado seguimiento y cambio a los requisitos, es necesario realizar la rastreabilidad" me podría informar mas sobre eso..
Gracias por el articulo
Me gustó sobre el tema de los SURPS muy interesante.
ResponderEliminarUn requerimiento puede ser funcional y no funcional, estos pueden variar en el tiempo, por eso es necesario estar en constante contacto con el cliente para estar al tanto de estos, nuestro propósito principal como desarrolladores de software es brindar un software con el cual el cliente quede satisfecho y eso se logra haciendo uso de las buenas practicas en el proceso de desarrollo de software.Podemos decir que el cliente es e
Buen punto.
Grasias por la información
Este articulo es muy interesante , porque nos ayuda a resolver muchas dudas, y generar buenas expectativas. La gestión de requisitos es necesaria para los proyectos de software no fracasen , Definir bien los requerimientos durante el desarrollo de un software ayudándonos de esta forma a encontrar , organizar , y no tener ningún tipo de error en la documentación.
ResponderEliminarEste articulo es muy interesante , porque nos ayuda a resolver muchas dudas, y generar buenas expectativas. La gestión de requisitos es necesaria para los proyectos de software no fracasen , Definir bien los requerimientos durante el desarrollo de un software ayudándonos de esta forma a encontrar , organizar , y no tener ningún tipo de error en la documentación.
ResponderEliminarEn mi opinion la Gestion de Requisitos debe ser desarrollado durante TODO EL CICLO DE VIDA del proyecto lo cual permitiria obtener una relación entre requisitos, diseño e implementación del sistema y a su vez desarrollando adecuadamente las actividades en forma disciplinada, coherente y tambien teniendo una buena gestion haria eficaz la calidad del producto final y que tenga un grado de satisfacción del cliente.
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminarEn opinion sobre el articulo que colgo profesor lo más interesante de como se elabora en la gestión de requisitos, es la realización de procesos generales
ResponderEliminarse genera soluciones óptimas a través de sub soluciones eficaces a generar sub procesos que ayuda a que la elaboración llegue a ser un poco mas rapida y sencilla de procesar.
Buenas noches profesor: Ing. Lain Cardenas
ResponderEliminarComo Analistas debemos de dar mucha prioridad a la Gestión de los Requisitos y hacer un seguimiento continuo de ellos, y que involucre a todos los participantes en la elaboración del proyecto (clientes y usuarios) y así poder detectar algún problema en la definición de sus necesidades y poder actualizar los requisitos siguiendo una metodología que sea iterativa e incremental.
Para lograr la correcta definición de los requisitos es necesario saber con exactitud cuáles son las necesidades del cliente para analizarlas y obtener los requerimientos necesarios del negocio para el proyecto.
Otro punto muy importante y siguiendo las buenas practicas, son las reuniones de trabajo con un grupo formado por el cliente (usuarios) para fortalecer el análisis de las necesidades y así hacer una buena Gestión para la captura de los requisitos de una manera muy eficaz.
No olvidarnos también de ir documentando toda la información que es importante para el negocio y hacer el uso de prototipos para ayudarnos en la especificación de los requisitos.
Es excelente el aporte que hace a la comunidad...
Definir bien los requisitos es parte fundamental para el desarrollo e implementación de un software, ya que mediante las necesidades que podamos encontrar, el software cumplirá su objetivo que es cubrir las necesidades del cliente para mejora de su empresa.
ResponderEliminarEn el post define a puntos muy importantes para la hora de elaborar el proyecto, y en que muchos casos no se toma mucho en cuenta, pero que en realidad es algo fundamental, como es la documentación de requisitos ya que en base a ello, nuestro proyecto lograra satisfacer necesidades del cliente.
ResponderEliminarLa gestión de requisitos es indispensable para desarrollar un producto de calidad adaptado o desarrollado para solucionar un problema en particular para ello se debe tener en cuenta los procesos de calidad y una buena metodología. Estos requisitos deben ser claros, consistentes y viables que se llegan a obtener después de un buen análisis y entrevistas continuas con el cliente.
ResponderEliminarEn este aporte se establecen mecanismos que garantizan el seguimiento de los requisitos a lo largo de todo un proyecto, lo cual permite tener una buena relación entre requisitos, diseño del software, esto permite al responsable del proyecto adoptar, desarrollar e implementar adecuadamente las actividades de gestión de los requisitos de una forma disciplinada, coherente y repetitiva con una eficiencia gestión de requisitos, lo cual contribuye eficazmente a la calidad del producto final y al grado de satisfacción del cliente.
ResponderEliminarAlumno: Wildo Alexander Leòn Moreno
Buenas noches profesor: Ing. Lain Cardenas
ResponderEliminarComo Analistas debemos de dar mucha prioridad a la Gestión de los Requisitos y hacer un seguimiento continuo de ellos, y que involucre a todos los participantes en la elaboración del proyecto (clientes y usuarios) y así poder detectar algún problema en la definición de sus necesidades y poder actualizar los requisitos siguiendo una metodología que sea iterativa e incremental.
Para lograr la correcta definición de los requisitos es necesario saber con exactitud cuáles son las necesidades del cliente para analizarlas y obtener los requerimientos necesarios del negocio para el proyecto.
Otro punto muy importante y siguiendo las buenas practicas, son las reuniones de trabajo con un grupo formado por el cliente (usuarios) para fortalecer el análisis de las necesidades y así hacer una buena Gestión para la captura de los requisitos de una manera muy eficaz.
No olvidarnos también de ir documentando toda la información que es importante para el negocio y hacer el uso de prototipos para ayudarnos en la especificación de los requisitos.
Es excelente el aporte que hace a la comunidad...
Alumno: Jorge Alexander Jiménez Azabache
Muchas veces el cliente no especifica muy bien los requisitos del sistema lo cual puede causar problemas al hacer el software. Para evitar esto es importante hacer un seguimiento a las necesidades especificadas por el usuario y así convertirlas en requisitos de software para luego llevarlas a nuestro software.
ResponderEliminarAlumno: José Benjamín Cabrera Villarreal
La gestión de requisitos permite que los involucrados en el desarrollo de software tengan siempre presente lo que el cliente desea y no se cometan errores en el proceso para la obtención del producto final. Se debe tener presente que muchas veces el cliente no está seguro de lo que quiere, por eso es necesario que el analista comprenda los procesos de negocios para poder obtener y analizar los requisitos. Además es necesario mantener un constante seguimiento de estos, para asegurarnos por si hay algún cambio en los requisitos o se desea agregar algo.
ResponderEliminarALUMNA: Milagros Madeleine Miñano Ochoa.
Buenas noches Profesor Lain Cardenas:
ResponderEliminarEl aporte que nos acerca con este post es de mucha importancia para el proceso de creación de un software de calidad y para comprender la trascendencia de los requisitos. Para un buen desarrollo de la gestión de requisitos es indispensable estar en contacto con el cliente, pues en el proceso de creación del software puede tender a requerir de nuevos requisitos y/o cambiar alguno de los ya brindados al analista. Él debe ser una persona capaz de asimilar y comprender los requisitos del cliente para poder proyectarse al producto final que entregará.
Saludos,
Linda Maryorett Reaño Aliaga.
Son muy interesantes las definiciones y prácticas del tema de la Gestión y sobretodo en el área de requisitos, en mi opinión es muy necesario porque en todos los proyectos de software que llevaremos siempre se van a generar requisitos en la gestión, el análisis, el diseño, en la implacablemente y en la fase de pruebas y esto nos ayuda a concebir ideas clave que vamos a implementarlas en el futuro.
ResponderEliminarMuy buen artículo y sin duda siempre queda la semilla de la curiosidad para seguir indagando.
Saludos.
Buenas Tardes Ing. Lain Cardenas:
ResponderEliminarBueno a mi parecer es muy importante entender cada uno de los procesos de negocio antes de describir cada uno de los requisitos de software que estemos desarrollando.
Al respeto con este articulo es muy interesante e importante mas especialmente para las personas que elaboran e implementan software en el tema de las buenas practicas, este artículo lo detalla de forma clara y precisa en como se debe desarrollar, es esencial, así como también tener en cuenta que en cada proyecto de desarrollo de un sistema se debe conocer todo el proceso que tiene la unidad de negocio.
Alumno: Castillo Miranda, George
Ing. Muy Buenos días, Gracias por el artículo, es muy que nos haga recordar que no solo basta capturar y describir los requisitos de los clientes o usuarios desean que cumpla el sistema a trabajar. Muchas veces los proyectos fracasan ya que no se lleva una buena gestión.
ResponderEliminarUna buena gestión de requisitos nos asegura que los riesgos del proyecto disminuyan. Todo comienza desde la buena documentación y especificación de los requisitos; si el cliente o usuarios se da a entender con los requisitos, entonces todos aquellos que intervienen en el desarrollo del producto; podrán brindar un software que cumpla las expectativas del cliente.
Después de leer esta nota, nos damos cuenta lo necesario que es estar en constante contacto con el cliente ára sí comprender los requisitos que este quiere para su sistema y así tener un software de calidad. Digo que es necesario el contacto, diálogo ya que a lo largo de todo el proceso de desarrollo el cliente puede ser más exigente con sus requerimientos o querer modificarlos, así por eso nosotros al llevar el contacto con el cliente y al tenerlo todo en etapas de desarrollo, se nos hará más fácil el agregado o modificación de uno.
ResponderEliminarSaludos,
Carlos Pérez
EN EL TEMA DEL LOS FURPS+ ... queda muy claro que tenemos que tener en cuenta esos puntos, que sirvan de referencia para la solides del software, pero no entiendo muy bien lo del signo (+), Ud mensiona que son TIPOS de requisitos, pero investigando en otro post encontre que le llaman RESTRICCIONES, entonces como mezclo esas dos definiciones ??, me podria explicar por que les llaman restricciones.? o es que por ser restricciones son requisitos.?
ResponderEliminarGRACIAS.
Hola Hardy, como se comenta en el post, el + de FURPS+ se refiere a otros tipos de requisitos como: Restricciones de diseño, Requisitos de implementación, Requisitos de la interfaz, Requisitos físicos, Requisitos legales. Todos estos pueden ser considerados también restricciones, condiciones, o características que el sistema a desarrollar debe cumplir.
EliminarSaludos.
Buen aporte!! nos vemos mañana para aprender mas de los temas!
ResponderEliminarAtte : Orlando Molina Maldonado
EliminarPara lograr un buen producto es necesario realizar una metodología iterativa e incremental como los RUP, y además haciendo uso de requisitos se puede gestionar de una mejor manera aquellos procesos que deseamos desarrollar. También es necesario tener en cuenta aquellos requisitos funcionales y no funcionales, los últimos para poder evaluar un software.
ResponderEliminarComo se puede apreciar en el artículo, es necesario el uso de buenas practicas para no cometer errores y que estos seas difíciles de controlar a lo largo del proceso del modelado del software.
El uso correcto de las buenas practicas como punto de partida es esencial, este artículo lo detalla de forma clara y precisa, así como también tener en cuenta que en cada proyecto
ResponderEliminarde desarrollo de un sistema se debe conocer el proceso de la Unidad de Negocio...
Es cierto que esto ayuda mucho al momento de analizar el negocio y encontrar algunas debilidades respectivamente en puntos que nosotros no nos dariamos cuenta a simple vista, posteriormente esta claro que se podrian mejorar los procesos obteniento un pequeño o gran impacto dependiendo de cuan grande sea el cambio.
ResponderEliminarPor otro lado como todos sabemos no podemos llegar a ser analistas en un corto periodo de tiempo y para eso se necesita mucha practica, siempre hay algo nuevo que aprender y para eso tenemos que actualizar nuestras tecnicas constantemente, cada dia tenemos que leer un poco porque esta no es una carrera como las demas, sino es una carrera que se desarrolla cada dia y que se siguen implementando temas y muchas herramientas diversas.
Encuentro su blog interesante y no tan complicado de comprender. Saludos!
La gestión de los requisitos nos permite obtener de forma adecuada la información de los usuarios, y que debidamente procesado se convertirán en las condiciones que deberá cumplir el sistema para la realización de los procesos organizativos.
ResponderEliminarUna prioridad en una gestión de requisitos es la RETROALIMENTACIÓN entre el usuario y el analista para poder ir filtrando los requerimientos necesarios para el obtención de un producto de calidad . Esta retroalimentación debe hacerse constantemente y no una sola vez , esto se considera una buena práctica .
ResponderEliminarMuy interesante aporte ingeniero, es una muy buena practica llevar el proyecto de la mano con el cliente y así poder garantizar un producto final que satisfaga la necesidad del negocio, ademas que estos detalles nos hacen mas confiables como desarrolladores de proyectos de software
ResponderEliminarLas buenas prácticas es un tema esencial en el análisis del proyecto ya que es necesario poder comprender los procesos del negocio y es por ello que el cliente debe tener en claro sus necesidades y si no fuera así, entonces es responsabilidad del analista el poder interpretar el requerimiento mediante una comunicación constante con el cliente durante todo el desarrollo del proyecto para de esa manera cumplir de manera satisfactoria con los objetivos del negocio.
ResponderEliminares un buen tema
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminarPara evitar un fracaso en proyectos de software no solo es necesario conocer las necesidades del cliente sino realizar una buena gestión de los requisitos.Estos generalmente van cambiando con el transcurso de las iteraciones lo cual puede poner en riesgo el avance del proyecto; por lo general se recomienda realizar técnicas adecuadas que nos ayuden a realizar un proyecto exitoso.
ResponderEliminarEste comentario ha sido eliminado por el autor.
EliminarAtte: Sandra Jimenez Acosta
EliminarExcelente aporte ingeniero, todo proyecto siempre parte por una necesidad del cliente y para esto se debe tener bien claro la gestión de requerimientos, ya que es el eje fundamental de todo proyecto, una adecuada gestión nos garantizara un buen desarrollo del sistema a realizar. Por lo tanto es necesario distinguir los diferentes tipos de requisitos y los diferentes niveles que se pueden aplicar, esto ayuda también a la organización y seguimiento de los requisitos, ya que estos pueden variar con el tiempo por lo tal es necesario mantenerlos actualizados, otro punto importante es tener en cuenta el uso de las buenas prácticas como se puede apreciar en el artículo con el objetivo de no cometer errores y a si obtendremos, el aseguramiento de la calidad, en lo referente a la organización de requisitos, con la finalidad de obtener el producto que desee el cliente con la máxima eficiencia
ResponderEliminaringeniero. Depende de nuestro esfuerzo y seguir todos los pasos sugeridos para que el cliente quede satisfecho con nuestro trabajo, por tal motivo, es necesario hacer una análisis profundo de los requerimientos del cliente, pero siempre estando en contacto con el cliente por cualquier percance, eso nos hará hacernos conocidos en el medio y triunfar profesionalmente.
ResponderEliminarPreviamente se tenia que haber filtrado algunos requerimientos como puliendo por decirlo así y ir poniéndose de acuerdo con el cliente de lo que necesita realmente (Retroalimentacion). Si mas adelante sucediera que el cliente dijese que le faltase algún requerimiento en el software sera nuestro error por no hacer un correcto análisis de requerimientos.
EliminarIngeniero. si después de todas las entrevistas con el cliente, y en el proceso del desarrollo del sistema, satisfacemos todos sus requerimientos, a la hora que ya le vamos a entregar el sistema nos dice que le falta unos requerimientos, es obligación nuestra acatar dicho pedido o ya no?
ResponderEliminarEs muy interesante el aporte para la gestión de requisitos del sistema entre los tipos de requisitos que se habla" FURPS " para poder realizar un sistema de negocio grande.¿sera aplicable también para caso de un sistema pequeño?
ResponderEliminarEn este artículo deja muy en claro la importancia de hacer una buena documentación y la buena gestión de requisitos, ya que es la parte esencial para que un producto satisfaga las necesidades del cliente.
ResponderEliminarSe comienza con una buena documentación y especificación de los requisitos, ya que si el cliente se da a entender con los requisitos, entonces el analista y los desarrolladores, podrán brindar un software de calidad que satisfaga la necesidad del cliente.
En Conclusión: Aplicar la gestión de requisitos y las buenas practicas es pilar de un buen desarrollo de proyecto.
Es cierto como desarrolladores nuestro principal objetivo es desarrollar un software capaz de soportar las actuales necesidades del cliente, a la larga este software tiende a degradarse ya que las necesidades en un negocio varían conforme pasa el tiempo.
ResponderEliminarEn cambio al hacer una buena gestión de los requisitos del cliente, con una documentación precisa y un buen proceso de desarrollo del sistema a implementar tiende a ser un mejor producto para nuestro cliente.
Si bien es cierto lo que explico el desarrollo incremental es uno de los más recomendados para desarrollar un software, como desarrolladores independientes se nos haría más fácil acoplarnos, ¿qué hacer si trabajamos en una empresa orientada al desarrollo en modelo lineal y que usa una ingeniería basada en la exagerada reutilización?
Alumno: Quisquiche Siccha Reibin Charles
Hola.
EliminarComo respuesta a tu pregunta te podría decir que si una empresa esta desarrollando en base a un método lineal o en cascada seguro tiene problemas, entonces hay que identificar esos problemas que se generan por el uso de este método y luego plantear alternativas o nuevas estrategias para evitar caer en los mismos problemas, se debe platear estrategias orientadas a prácticas de desarrollo iterativo e incremental. La adopción de estás prácticas no es simple, se debe concientizar a los grupos de desarrollo a que vayan aplicando pero es necesario la participación de un experto para que guíe a los grupos.
Interesante lectura, aunque cabe recalcar que, si bien el proceso iterativo e incremental es optimo para el desarrollo de la mayoría de sistemas, cuenta con algunas desventajas si es utilizado junto a una gestión ágil. Como por ejemplo su problema con los sistemas grandes, donde una arquitectura estable es necesaria para una planificación rápida y la identificación de requisitos importantes; o la falta de documentación adicional que, aunque a veces puede ser vista como una ventaja, hace al proceso no visible desde una perspectiva administrativa.
ResponderEliminarPor lo general los proyectos grandes requieren de mayor documentación que los proyectos pequeños, las prácticas ágiles están más aplicadas a proyectos medianos o pequeños.
EliminarSi bien es cierto, el enfoque del articulo esta centrado en conceptos relacionados a los requisitos en proyectos medianos o grandes, y las buenas prácticas van de la mano con esto. Creo que es conveniente también aplicar cada una de estas buenas prácticas para proyectos pequeños, teniendo en cuenta que la documentación no tendrá la misma extensión o detalle. Ya que en mi opinión todas las buenas practicas apuntan a cumplir con la rastreabilidad. Y la rastreabilidad es la capacidad que le otorgamos a nuestra documentación para facilitar su constante actualización a lo largo del ciclo de vida del proyecto; produciendo de esta manera una correcta "visualización" del software en cada una de las iteraciones.
ResponderEliminarProfesor Lain, estoy de acuerdo en la importancia de este tema, al ser muy util para nuestro proyecto, en especial sobre la importancia del seguimiento, ya que a veces el cliente pide algun requisito que el programador no tenia en cuenta, y si no se ha investigado sobre la función de su empresa, habría una mal interpretasión tal y como en la imagen que usted mostró en clase.
ResponderEliminarPiero A. Tejada Santander
Es importante tener en cuenta que la mayoría de veces, el cliente no suele explicar los requisitos de manera correcta e incluso no sabe qué es lo que desea, por tanto el analista debe saber capturar e ir concretando los requisitos junto con el cliente. Es por ello que se recomienda un proceso iterativo e incremental, realizar una buena documentación y especificación de los requisitos(funcionales y no funcionales), buena comunicación y redacción, entender bien los procesos de negocio y una gestión ágil del proyecto. Estas practicas nos serán de mucha utilidad en la gestión de proyectos medianos y grandes, los cuales suelen demandar un numero grande de personas involucrados en ello y además permitirá que el equipo involucrado en el proyecto tenga conocimiento acerca de lo que el cliente desee y no se entregue un producto diferente a lo que el cliente necesita.
ResponderEliminarProfesor muy buen aporte acerca de la gestión de requisitos, yo creo que si en esta etapa las cosas se hacen bien definidas y establecidas, hay una gran posibilidad de exito, porque los requerimientos son muy febles a ser mal interpretados, y el esfuerzo no sirve de nada si al cliente no le convenciste de que el trabajo realizado cumplió con los requisitos, En esta etapa mas que experiencia se necesita empatia con los interesados, es una cuestion de Quimica en la relacion durante todo el tiempo de trabajo, y aparte que para lo demas si, la experiencia y el der un buen desarrollador pesará para la meta.
ResponderEliminarLa gestión y/o análisis de requerimientos es una parte fundamental del desarrollo de software, pero lamentablemente muchas veces estos o no son interpretados de la forma correcta por los analistas o los clientes no los saben definir. Es por eso que me apreció muy importante e interesante su recomendación de usar un proceso iterativo e incremental en lugar de proceso iterativo e incremental, como una buena practica ya que los requisitos se especifican por partes o incrementos en un orden de importancia, para que de esta manera se reduzcan los errores y así eliminar los costos que estos generan. Muchas Gracias por el aporte ingeniero
ResponderEliminarUna reflexión interesante sería que después de entregar el software al cliente, éste te felicite y te diga , sí tu programa tiene funcionalidades interesantes , hasta hace lo que no te he pedido que haga sin embargo no hace lo que quiero o necesito que haga xd. Para evitar llegar a esa situación es necesario trabajar bien el análisis de requisitos y asegurarse de que la interpretación del analista de los procesos del cliente son fiables además de luego de observar las necesidades de lo que se necesita que haga el software , asegurarse luego con mas detalle en las características y casos de uso que lo que se está haciendo es lo que el cliente desea , involucrando al cliente como parte del proceso y con el desarrollo incremental haciendo prototipos de los casos de uso que ya se tenga identificados como casos de uso importantes dentro del proceso de negocio que va a automatizar el software.
ResponderEliminarEs importante tener bien definido los requerimientos,ya que es un procedimiento fundamental durante el desarrollo de un software pues estos indicaran que funciones tendrá el software.
ResponderEliminarPor lo tanto, la gestión de requisitos es la base de todo buen proyecto,satisfactorio para los clientes y usuarios.
La gestión de requisitos es una etapa critica en un proyecto de software ya que los requerimientos son cambiantes y si no están bien definidos puede llevarte a fracasar el proyecto. Así que es aconsejable usar buenas practicas de tal forma que debemos hacer que el cliente enfoque claramente su requerimientos de esta forma se dará inicio al desarrollo de un proyecto de calidad. (Ghersonn Andree Izquierdo Melgar)
ResponderEliminarLas ideas clave que se me vienen a la mente con respecto a buena gestión de requisitos son:
ResponderEliminar- El cliente solo puede comprometerse a hacer el seguimiento y evaluación del proyecto. No se le puede exigir que sepa perfectamente lo que necesita al principio del proyecto, las técnicas de gestión de requisitos permitirán ayudarle a identificar la solución que requiere.
- Se debe persuadir al cliente y explicarle lo importante que son las técnicas para la recopilación de requisitos, ya que es fundamental que tanto él como los desarrolladores puedan entender las necesidades del sistema.
- Los requisitos deben llegar a un nivel lo suficientemente profundo como para que cliente y el equipo de desarrollo lo entiendan. Esto se logra centrándose en los procesos complejos, mientras que el resto podría acotarse superficialmente, profundizando en estos en próximas etapas de evolución de software.
- Los requisitos funcionales permiten desarrollar casos de prueba, cuando evolucionan a escenarios. Los no funcionales permiten evaluar el rendimiento del sistema, asi como también otras características de calidad.
-El seguimiento de los requisitos puede apoyarse en el desarrollo de los prototipos, ilustrando así como es que se llevarían en la práctica ciertas funcionalidades y permitiendo observar como reacciona el usuario frente a ellos.
Aprecio mucho el post que nos ha compartido y la reflexión que nos lleva es que trabajando bien la parte del análisis lograremos que haya poco esfuerzo en implementación y desarrollo, ya que tendremos la certeza de que lo que estamos codificando está encaminándose a satisfacer una necesidad del cliente. Así mismo, sería muy triste y poco beneficioso para el proyecto terminar de implementar una función compleja pero que al final no aporta ningún beneficio o ha sido desarrollada para seguir un flujo de pasos ajeno al que el usuario esta acostumbrado. Esto no quiere decir que este tipo de problemas no lleguen a ocasionarse, pero también si sabemos que un requerimiento no esta muy definido podemos desarrollarlo hasta cierto punto y luego de una revisión continuarlo poco a poco, hasta que la funcionalidad se halla desarrollado por completo y sea aprobada por el cliente.
Agradezco al profesor Lain por sus charlas en clase, porque nos encamina a visualizar problemas de la realidad y de esa manera, las cosas no se quedan solo en la teoría.
Sin duda la gestión de requisitos es vital en el proceso de desarrollo de un software, ya que la calidad y el éxito de un proyecto empieza por una correcta Gestión de Requisitos. Por ende, es correcto afirmar que el proceso de gestión de requisitos finaliza cuando el cliente este completamente satisfecho con el producto final. Además es importante mencionar que el costo de una buena captación de requisitos y análisis del sistema a desarrollar es menor comparado con el costo resultante de tener requisitos pobres.
ResponderEliminarAsimismo me parece muy interesante cuando recomienda que es preferible usar
un proceso iterativo e incremental en ves de uno lineal o cascada, ya que así
estaríamos mas en contacto con el interesado, de manera que se pueda mejorar
la captación de requisitos que se haya hecho en una primera reunión. Gracias
por el aporte Ingeniero.
La especificacion de requerimientos es muy importante ya que sin ellos no podrá ser posible llevar a cabo las etapas de diseño y construcción correctamente. Algunos requerimientos pueden variar en la construcción del proyecto. Es por ello que su recomendación de utilizar proceso incremental en la elaboración del proyecto o software es muy buena, ya que permitirá evitar errores graves al finalizar el proyecto como es costo y tiempo. Entonces el proceso incremental hace participé al cliente, dándole el alcance de los avances para que este verifique que la funcionalidad valla de acuerdo a sus necesidades.
ResponderEliminarhacer una buena especificacion de requisitos, nos ayudara a que el proyecto software final
ResponderEliminarfuncione correctamente segun las especificaciones que el cliente o usuario solicito.
ademas hay que tener presente que exixsten niveles de requisitos:
*modelo vision:
-nesecidades
-caracteristicas
*caso de usos
*escenario
asi mismo importante entender que la documentación o especificación de
los requisitos debe seguir un proceso metodológico.
y hay que recalcar que en la ingeniería de software es asumir un proceso iterativo e incremental y no un proceso lineal o en cascada
Es importante saber diferenciar los diferentes tipos de requisitos y los diferentes niveles que se pueden aplicar, lo cual ayuda a mantener un mejor orden y coherencia con el producto que se desea construir. Se debe seguir un proceso iterativo e incremental en la ingeniería de software, es decir, los requisitos se especificaran a detalle en cada versión del proyecto y ademas existirá un menor riesgo del que el usuario este poco satisfecho.
ResponderEliminarLas buenas practicas para la gestión de requisitos también nos aseguran la consistencia entre los requisitos y el sistema construido y además tienen como objetivos principales gestionar la recogida de requisitos y obtener la aprobación de los participantes del proyecto.
Es importante que el analista pueda hacer una adecuada descripción de los requisitos ya que los diseñadores y desarrolladores de software deben tener en claro que es lo que van hacer en el proyecto para que puedan entregar un producto que satisfaga las necesidades del cliente. Es por eso que se deben seguir las buenas practicas para que las necesidades y características del software que se va a desarrollar queden documentados, estos deben ser detallados para que así puedan tener un seguimiento, pues con el tiempo estos pueden cambiar por lo que deben mantenerse actualizados a lo largo de la elaboración del proyecto.
ResponderEliminarLa Gestión de Requisitos tiene a gestionar eficientemente esta importante etapa
ResponderEliminaren el análisis del software, debido a que es muy frecuente la insatisfacción del cliente al momento de recibir el software dado que las conformidades en los requerimientos obtenidos mediante esta fase no se han detallado. Para esto de debe apoyar en mediante buenas practicas permitan obtener requerimientos más coherentes con el
producto que se desea construir.
La gestión de requisitos en la Ingeniería de Software, se ha constituido en una de las
ResponderEliminarprincipales estrategias para garantizar desde las primeras etapas del proceso de desarrollo de software, proceso encargado de la identificación, asignación, verificación, y modificación de los requisitos a lo largo del ciclo de vida del software. Además es considerada como uno de los procesos más importantes dentro de la Ingeniería de Requisitos. Con una buena Gestión de Requisitos se logra crear software de buen rendimiento que satisface realmente las necesidades del usuario.
La gestión de requisitos es una parte importante de una organización que desarrolla sus propios proyectos de software, puesto que es vital para reducir los riesgos inherentes a ellos. Las buenas prácticas de gestión de los requerimientos aseguran que únicamente los requisitos necesarios estén disponibles a todos los miembros del equipo del proyecto y que los cambios sean realizados bajo circunstancias controladas. Los requisitos que son acordados y aprobados por todos los asociados o propietarios del proyecto, contribuirán a garantizar que los objetivos establecidos se cumplan.
ResponderEliminarEste artículo me ayudo mucho a comprender que La aplicación de buenas prácticas en la gestión de requisitos de software es una condición fundamental para
ResponderEliminarlograr productos de calidad.lo cual es importante para desarrollo de software que mantengan una
investigación constante alrededor de nuevas técnicas que mejoren actividades de requisitos.
Este documento me dejo en claro la importancia que tiene el conocimiento de la ingenierìa de Requerimientos y con ella la Gestion de Requisitos, pero sin dejar de mencionar que para el desarrollo de un buen software depende de una intensa comunicacion entre el cliente y el analista de requerimientos.
ResponderEliminarComo es bien sabido para la obtención de un buen resultado o producto el cliente debe ser especifico en los requisitos que quiere que tenga su sistema debe ser claro ,consistente para que el grupo de este a cargo de desarrollar el sistema pueda entender y llegar a lo que el cliente necesita cumpliendo todas sus necesidades ya que sin ellos no podrá ser posible llevar a cabo las etapas de diseño y construcción correctamente.
ResponderEliminarPara una buena gestión de requisitos se debe documentar ,hacer una especificación detalles a detalle que es lo que el cliente necesita para que el grupo que este a cargo tengan un mismo requisito y la información no se distorsionen y lleguen en conjunto a un solo resultado,para que esto sea posible debe existir buena comunicación e integración del grupo para satisfacer las necesidades del cliente,luego que se haya documentado los requisitos debe ver una verificación para asegurar que la especificación de requisito del producto es una representación exacta de las necesidades del cliente luego de esto se gestionan los cambios donde se podrá evaluar, trazar y reportar cambios propuestos y aprobados a la especificación del producto.
Alumna: Hoyos Perez Gianella
La gestión de requisitos es uno de los pasos base para el buen desarrollo de un software. Con la presente información me fui adentrando en lo que en sí viene a formar parte de la capacitación profesional que tiene un ingeniero de Sistemas. ¿Los prototipos se deben usar en cualquier caso? ¿O solo para el grandes y medianos proyectos? Gracias de antemano
ResponderEliminarLa gestión de los requisitos es necesario en cualquier tipo de proyecto, pero se puede manejar de distintas maneras dependiendo las características de los proyectos y la experiencia de los analistas.
EliminarEs muy importante aplicar las buenas prácticas en la gestión de requisitos, para poder llevar un buen desarrollo de software y así lograr un software que cumpla con todas las funcionalidades del sistema que necesita el cliente.
ResponderEliminarLos requisitos son tan importantes que de ellos depende que tan buenos serán los posibles prototipos que se presenten al cliente, para corroborar los posibles cambios o validar ciertas cuestiones en el avance. También nos ayudan a entender el diseño desde diferentes perspectivas para lograr así un software de calidad.
ResponderEliminarEn este artículo se presenta un estudio de los enfoques más representativos de la ingeniería de
ResponderEliminarrequisitos orientada por aspectos que podrían ayudar a resolver problemas que enfrentan las compañías de software durante las
etapas tempranas de desarrollo. Se hace un análisis comparativo entre los enfoques, a partir de los criterios de alcance, trazabilidad,
composición de requisitos, manejo de conflictos, mapeo,
validación-verificación y escalabilidad. Los resultados obtenidos permiten detectar las
oportunidades que el enfoque de aspectos ofrece para mejorar el proceso de los requisitos.
Como se describe en este articulo : Mucho de los errores cometidos en la gestión de los requisitos se debe a la mala documentación, descripción o especificación de los mismos. bueno como bien sabemos el analista debe captura a todas sus necesidad que cliente quiere , para que su sistema cumpla con con todas las funcionalidades y restricción de operación para su negocio(mediante caso de uso que se conlleva en un determinado Escenario). Sin embargo no sólo basta con capturar y describir los requisitos que el cliente o usuario describa sino describirlo mediante un conjunto de características para poder derivar todas las necesidades de el cliente y conllevar en un rango mas detallado y entendible (valida requisitos funcionales) , por lo que todo este procedimiento se debe adoptar a un mayor seguimiento al cliente u usuario en diferentes interacción(Proceso incremental e interactivo ) para así garantizar un buen resultado del producto (mediante presentaciones de Prototipos) en base a cada comentario que el cliente o usuario realmente requiera ( requisitos deban Actualizarse ).
ResponderEliminarAtten: James Avila Villarreal
Creo que es un tema muy importante pero la mayor responsabilidad depende de los analistas porque ellos deben identificar bien los requerimientos ¿Pero como saber si todos los requerimientos están definidos correctamente ?
ResponderEliminarLos proyectos de software fracasan por la mala Gestión de Requisitos,los analistas no logran obtener todos los requerimientos necesarios que necesita el cliente, esto hace que el sistema desarrolle funcionalidades que no están establecidas,eso quiere decir que no hubo una buena coordinación.
ResponderEliminarun sistema debe utilizar el FURPS+ que ayude a la documentación o especificación
en diferentes niveles de detalle y dependiendo de la complejidad de los procesos o sistema a desarrollar.
¿Como determinar la complejidad de los procesos,teniendo en cuenta la Gestión de Requisitos?
Este articulo es muy importante ya que nos brinda información acerca de las buenas practicas y la buena gestión de requisitos que comprenden todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer, los buenos requisitos deben ser medibles y comprobables, para garantizar que la funcionalidad esta bien implementada.
ResponderEliminarEs necesario asegurar que los requisitos se mantengan actualizados a lo largo de las iteraciones del proyecto para así poder comprender perfectamente los requisitos del software.
El enfoque que tiene este artículo se basa en conceptos relacionados a los requisitos en proyectos para grandes o pequeñas empresas, y las buenas prácticas van de la mano con esto. Es muy interesante el aporte para la gestión de requisitos del sistema entre los tipos de requisitos que se habla" FURPS " para poder realizar un sistema de negocio grande. Ya que en mi opinión todas las buenas practicas apuntan a cumplir con la rastreabilidad. Estas prácticas nos serán de mucha utilidad en la gestión de proyectos medianos y grandes, los cuales suelen demandar un numero grande de personas involucrados en ello y además permitirá que el equipo involucrado en el proyecto tenga conocimiento acerca de lo que el cliente desee y no se entregue un producto diferente a lo que el cliente necesita.
ResponderEliminarRealizar la gestión de requisitos en toda aplicación. es muy importante ya que nos va a permitir tener un control de todo lo que cliente espera que haga el sistema (requerimientos).
ResponderEliminar