unidad 2
TRANSCRIPT
I N S T I T U T O T E C N O L O G I C O D E
C H I L P A N C I N G O
I N V E S T I G A C I O N 2 U N I D A D :
“ C A P T U R A D E R E Q U I S I T O S ”
I N T E G R A N T E S D E L E Q U I P O :
B E L L O S A L V A D O R B E N I T O
C A S T R O M A R T I N E Z J O R G E L U I S
R O S A S E V A N G E L I S T A L U I S A N G E L
V A Z Q U E Z M O R A N I D I A L I Z Z E T H
V E L A M O R Q U E C H O D I E G O A R M A N D O
1
INDICE
INTRODUCCION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 TIPOS DE REQUISITOS. . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 FUENTES Y DATOS PARA EL ANALISIS DEL SISTEMA. . . . . . . . . . . 7
2.3 SELECCIÓN Y DISEÑO DE INSTRUMENTOS PARA . . . . . . . . . . . 9
LA RECOPILACION DE INFORMACION.
2.4 CAPTURA DE REQUISITOS DE CANDIDATOS . . . . . . . . . . . . . . 11
2.5 SELECCIÓN DE METODOLOGIA DE DESARROLLO . . . . . . . . . . . 13
2.6 MODELO DEL NEGOCIO . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 MODELO DEL DOMINIO. . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8 VALIDACION DE REQUERIMIENTOS . . . . . . . . . . . . . . . . . . . 18
2.9 DEFINICION DE PROPUESTA DE SOLUCION . . . . . . . . . . . . . . . 21
CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
BIBLIOGRAFIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2
INTRODUCCION
La captura de requisitos se refiere al acto de descubrir o averiguar en circunstancias difíciles lo que se debe construir. De hecho es tan difícil para los equipos de proyecto que estos empiezan a a escribir código antes de determinar lo que este código debe hacer.
A pesar de las numerosas técnicas existentes en la ingeniería del software, los fracasos en los proyectos de desarrollo de sistemas software se pueden considerar comunes. Con demasiada frecuencia los sistemas se entregan más tarde de lo esperado, con mayor coste del previsto, y no cumplen con las necesidades reales de los usuarios del sistema o de la organización en la que se han de implantar. En la mayoría de los casos, los fracasos no se deben a que las personas que participan en el desarrollo del sistema no sean competentes o a una mala práctica de ingeniería de software, sino que son consecuencia de problemas relacionados con los requisitos del sistema.
Antes de desarrollar cualquier sistema software es necesario comprender qué deberá hacer y cómo dará soporte a las metas. Esta necesidad implica la comprensión del dominio de aplicación, de las restricciones operacionales del sistema, de la funcionalidad y de las características no funcionales del sistema.
La principal medida del éxito y de la calidad de un sistema software es el grado en el que cumple con el propósito para el que fue ideado, es decir, sus requisitos.
3
2.1 TIPOS DE REQUISITOS
FUNCIONALES:
La técnica inmediata para identificar los requisitos del sistema se basa en los caso de uso, estos casos de uso capturan los requisitos funcionales como los no funcionales.
Cada usuario quiere que el sistema haga algo para él es decir lleve a cabo ciertos casos de uso
Para el usuario un caso de uso es un modo de usar el sistema.
En consecuencia si los analistas pueden describir todos los casos de uso que necesita el usuario sabrán lo que debe hacer el sistema.
La captura de los casos de uso realmente necesarios, como aquellos que soportan el negocio y que le permitirá al usuario realizar más cómodamente su trabajo requiere conocer en profundidad las necesidades de los usuarios y clientes, para lo cual se debe conocer el contexto del sistema
NO FUNCIONALES:
Los requisitos no funcionales especifican propiedades del sistema como restricciones de entorno, o implementación, rendimiento, dependencias de la plataforma, facilidad de mantenimiento, extensibilidad, fiabilidad.
Ej. Requisitos especiales para el caso de uso Pagar Factura.
4
Requisito de Rendimiento: Cuando un comprador envía una factura para su pago, el sistema deberá responder con una
Verificación de la solicitud a menos de 0.1 seg. En el 90% de los casos. La duración de esta verificación nunca deberá excederlos 10 seg. A menos que la conexión de red no funcione, en cuyo caso se deberá informar al usuario.
CARACTERISTICAS DE LOS REQUISITOS
Es importante no perder de vista que un requerimiento debe ser:
Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
Posible de probar o verificar: Si un requerimiento no se puede
comprobar, entonces ¿cómo se sabe si se cumplió con él o no?
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su
redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles
en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector
Para llevar a cabo las actividades de los requisitos deben de pasar por 4 etapas o fases para que se lleven a cabo para a completar los procesos:
Extracción
5
Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc.
Es importante, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuan bien éste satisfaga las necesidades del cliente.
Análisis
Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento.
Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.
Especificación
En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle.
En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utiliza cada vez más para la obtención de requerimientos.
Validación
La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos.
6
2.2 FUENTES DE DATOS PARA EL ANALISIS DEL SISTEMA:
Los objetivos específicos de la gestión de datos son:
Obtener los datos y prepararlos para el análisis
El sistema de gestión de datos incluye la supervisión del flujo de datos desde los sujetos de investigación a los analistas de datos. Antes de poder analizarlos, los datos deben ser recogidos, revisados, codificados, computarizados, verificados, confirmados y convertidos a formularios adecuados para llevar a cabo el análisis. El proceso debe ser adecuadamente documentado para fundamentar el análisis e interpretación.
Mantener el control de calidad y la seguridad de los datos
Las amenazas con respecto a la calidad de los datos surgen en todos los puntos en que se obtienen y/o modifican datos. El valor de la investigación se verá muy afectado por el control de calidad, pero lograr y mantener la calidad requiere actividades que a menudo son banales y difíciles de motivar. El control de calidad incluye:
Prevenir y detectar errores en los datos a través de procedimientos escritos,
entrenamiento, procedimientos de verificación, y evitando complejidades innecesarias.
Evitar o eliminar las inconsistencias, errores, y datos faltantes a través de la
revisión de los formularios de recolección de datos (en forma ideal cuando el acceso a las fuentes de los datos aún está disponible para permitir
7
resolver las dudas) y los conjuntos de datos.
Evaluar la calidad de los datos a través de los apuntes de los
entrevistadores, codificadores, editores de datos, a través del interrogatorio de los sujetos, y a través de revisiones o repeticiones de la recolección de datos para sub-muestras
“Sentir” los datos, evitar interpretaciones equivocadas y descuidos
importantes.
Permitir las solicitudes de información, revisión, reconstrucción, y archivo
En cualquier momento durante y hasta después de que se completa el proyecto puede surgir la solicitud de los instrumentos y/o de los datos o preguntas sobre los mismos. La agencia financiadora requerirá un informe final.
8
2.3 SELECCIÓN Y DISEÑO DE INSTRUMENTOS PARA LA RECOPILACION DE INFORMACION.
Herramientas para Análisis:
Estas herramientas ayudan a los especialistas en sistemas a documentar un sistema existente, ya sea éste manual o automatizado, u a determinar los requerimientos de una nueva aplicación.
9
Herramientas para la recolección de datos:
Capturan detalles que describen los sistemas y procedimientos en uso. Documentan procesos y actividades de decisión. Se utilizan para apoyar la tarea de identificar requerimientos.
Herramientas para la diagramación:
Crean representaciones gráficas de sistemas y actividades. Apoyan el dibujo y revisión de diagramas de flujo de datos e iconos asociados con el análisis estructurado. Asimismo incluyen programas para representación en diagramas de flujo.
Herramientas para el diccionario:
Registran y mantienes descripciones de los elementos del sistema tales como grupos de datos, procesos y almacenamiento de datos. Con frecuencia proporcionan la capacidad de examinar las descripciones del sistema para decidir si son incompletas o inconsistentes.
MÉTODOS PARA LA OBTENCIÓN DE INFORMACIÓN:
Todo análisis y diseño de un sistema implica la búsqueda y obtención de información relevante para la estructuración y definición de problemas, generación de soluciones, validación de soluciones, etc.La información en una organización no siempre es fácil de obtener, más bien es un proceso lento y costoso, que exige tiempo y dedicación por parte del analista de sistemas. Las fases de búsqueda de información en cualquier proyecto, suelen ser grandes consumidoras de tiempo, y el éxito de los resultados depende en gran medida de la calidad de la información.Es muy común que la información requerida no se encuentre escrita, o inclusive que ésta no se conozca. Esto hace necesaria la interacción del analista con las personas del sistema para identificar y/o generar la información faltante.
Si se cuenta con información escrita formal y adecuada utilícelas, le ahorraría tiempo y le facilitaría la comprensión del sistema.Existen métodos básicos para recopilar información dentro de una organización o sistema social.
10
Estos incluyen
a) Cuestionariosb) Entrevistasc) Sondeosd) Encuestase) Collagef) Dibujosg) Diagramas de flujo de datosh) Tablas de Organizacióni) Descripción de puestosj) Manuales Operativos.k) Representación física de las Organizaciones.
2.4 CAPTURA DE REQUISITOS CANDIDATOS
Hay diferentes puntos de partida para la captura de requisitos. En algunos casos comenzamos haciendo un modelo del negocio o partimos de uno ya desarrollado. En otros casos si es un sistema acotado que no da soporte al negocio podemos partir de un modelo de objetos sencillo como un modelo del dominio. En otros casos el cliente puede ya haber desarrollado una especificación
11
completa de requisitos no basada en objetos, de la cual podemos partir. En forma típica, el flujo de trabajo de requisitos incluye los siguientes pasos:
Enumerar los requisitos candidatos. Comprender el contexto del sistema. Capturar requisitos funcionales. Capturar requisitos no funcionales
Enumerar los requisitos candidatos
La lista de características deseadas del sistema constituyen los requisitos candidatos. De cada característica se registra:
Nombre corto Descripción Estado (propuesto, aprobado, incluido, o validado) Coste estimado de implementación (en término de tipos de recursos y
horas- hombre) Prioridad (crítico, importante, o secundario) Nivel de riesgo asociado a la implementación de la característica (crítico,
significativo, ordinario)
Estos valores se utilizan para estimar el tamaño del proyecto y decidir cómo dividirlo en secuencia de iteraciones. La prioridad y nivel de riesgo asociados por ejemplo, se utiliza para decidir en qué iteración se implementará la característica.
Comprender el contexto del sistema
Hay por lo menos dos aproximaciones para expresar el contexto de un sistema: modelado del dominio y modelado del negocio. Un modelo del dominio describe los conceptos importantes del contexto como objetos del dominio relacionados entre sí. Un modelo del negocio es más amplio. Describe los procesos con el objetivo de comprenderlos. El modelado del negocio especifica que procesos de negocio soportará el sistema
Capturar requisitos funcionalesLos requisitos funcionales son capturados por medio de casos de uso, que conforman el modelo de casos de uso. Los casos de uso también capturan requisitos no funcionales específicos de un caso de uso determinado
Capturar requisitos no funcionales
12
Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la implementación, rendimientos, etc. Hay requisitos no funcionales específicos para un caso de uso y otros genéricos para la aplicación. Los que son específicos para un caso de uso, pueden documentarse junto con el caso de uso correspondiente. Los que son más genéricos se documentan por medio de una lista de requisitos adicionales.
2.5 SELECCIÓN DE METODOLOGIA DE DESARROLLO
La buena selección metodologías; y también el buen desarrollo software; es producto o resultado de una buena selección de estándares y normas para trabajar mediante una Metodología de Desarrollo de Software fija. En la actualidad, la experiencia en el área de la Informática me ha permitido comprender que el diseño y el desarrollo de software no es una tarea sencilla, por mucho tiempo esta labor se ha llevado adelante sin una metodología definida.
13
Sabemos por conocimiento puramente profesional que las metodologías tradicionales se basan en normas provenientes de estándares seguidos por el entorno de desarrollo; con una fuerte y cierta resistencia a los cambios donde todo se encuentra impuesto externamente y poseen un proceso muy controlado, con numerosas normas. Pero eso no es todo, dichas metodologías tradicionales necesitan un contrato prefijado donde el cliente interactúa con el equipo de desarrollo mediante reuniones con grupos grandes los cuales requieren de más artefactos y el resultado final se basa en la arquitectura del software es esencial.
Las metodologías agiles son todo lo contario. Se basan en heurísticas provenientes de prácticas de producción de código; total y completamente preparados para cambios durante el proyecto las cuales son impuestas internamente por el equipo con proceso menos controlado, con pocos principios. Así como también con un contrato flexible e incluso inexistente, donde el cliente es parte del desarrollo y los grupos son pequeños por lo que se incluyen pocos artefactos y existe un menor énfasis en la arquitectura del software.
antes de desarrollar un producto software, necesitamos comprender la visión del producto, la cual podemos obtenerla en base a la vinculación con el cliente, y un previo establecimiento del modelo de ciclo de vida del software, así como la gestión de los requisitos, el plan de desarrollo y también la parte de la integración del proyecto. Esto nos permitirá tener un amplio panorama donde podremos ver las medidas de progreso del proyecto, así como las métricas para evaluar la calidad, las maneras de medir el riesgo, y saber con ello como gestionar los cambios y así establecer una línea de meta; lo que nos ayuda para poder seleccionar una metodología de desarrollo de software; pues al ver lo que realmente necesitamos, podremos ver que es lo que nos proporciona una metodología tradicional y una ágil, independientemente de cuál seleccionemos para llevar a cabo el desarrollo de nuestro software, ya que tenemos variedades de metodologías tanto tradicionales como agiles. Lo que se debe tener claro es que, para tener una selección optima de metodología, este aspecto no ha sido tratado de manera adecuada, sobre todo en el ámbito de las metodologías tradicionales, y en el caso de las ágiles no existe un criterio unificado para poder llevar una debida selección de la metodología a tratar para poder desarrollar un software de calidad. Ahora bien por lo anteriormente mencionado podemos tener una guía de orientación, o una formulación inicial para la debía selección, el cual puede llenar las expectativas base del cliente, que es un coste del desarrollo inicial relativamente bajo, con un software fácil de mantener, portable a nuevo hardware
14
y sobre todo que haga lo que el cliente quiere, ya que en base a la información existente a la fecha y a la experiencia personal, puedo decir que la formulación para poder seleccionar una buena metodología se basa en una buena selección por criterios de expertos y por conocimiento de desarrollo en la rama de los analistas y diseñadores que nos guie a la pura necesidad del cliente y la metodología que se acople a dicha necesidad.
2.6 MODELO DEL NEGOCIO
Un modelo de negocio, también conocido como diseño de negocio, es la planificación que realiza una empresa respecto a los ingresos y beneficios que intenta obtener. En un modelo de negocio, se establecen las pautas a seguir para atraer clientes, definir ofertas de producto e implementar estrategias publicitarias, entre muchas otras cuestiones vinculadas a la configuración de los recursos de la compañía.Se propone un marco formado de los siguientes bloques:
Segmento de clientes.
15
Propuesta de Valor.
Canales de distribución.
Relaciones con clientes.
Flujos de ingresos.
Recursos claves.
Actividades claves.
Red de proveedores.
Costo de la estructura.
Existen distintos tipos de modelo de negocio. El más básico y antiguo es conocido como el modelo del tendero, que consiste en instalar un negocio en el lugar donde deberían encontrarse los clientes potenciales, y allí desplegar la oferta de productos y servicios.
El modelo del cebo y el anzuelo, desarrollado a comienzos del siglo XX, supone la oferta de un producto básico a bajo precio, incluso soportando pérdidas (el cebo), para después cobrar precios excesivos por los recambios o insumos asociados (el anzuelo). Este modelo de negocio es muy común en el negocio de las impresoras,
16
que tienen un costo muy bajo en comparación al de los cartuchos de tinta.
Las innovaciones en los modelos de negocios son cada vez más frecuentes en la economía actual, donde todos los sectores son muy dinámicos. Encontrar el modelo de negocio adecuado resulta una ventaja competitiva para las empresas.
En algunos casos, las empresas parecen funcionar con éxito pero, en realidad, no está claro su modelo de negocio. Por lo tanto, no se define con precisión cómo esas empresas van a obtener sus ingresos y ser rentables. Ese es el caso de muchos sitios de Internet, que consiguen millones de visitantes y se vuelven muy populares, pero que no tienen el modelo necesario para garantizar su éxito financiero.
2.7 MODELO DEL DOMINIO
Un Modelo de Dominio es un artefacto de la disciplina de análisis, construido con
las reglas de UML durante la fase de concepción, en la tarea construcción del
modelo de dominio, presentado como uno o más diagramas de clases y que
contiene, no conceptos propios de un sistema de software sino de la propia
realidad física.
Los modelos de dominio pueden utilizarse para capturar y expresar el 17
entendimiento ganado en un área bajo análisis como paso previo al diseño de un
sistema, ya sea de software o de otro tipo. Similares a los mapas mentales
utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como
un medio para comprender el sector industrial o de negocios al cual el sistema va
a servir.
Brainstorming y refinamiento: Es una filosofía basada en las metodologías ágiles y, como éstas, propone que la conversación sea el medio de comunicación para compartir información de la forma más rápida y eficiente.
Un Modelo de Dominio borrador: En base a la conversación se puede ir construyendo un esbozo de lo que será el modelo de dominio. El experto irá corrigiendo lo que a él le parezca que no está correcto y desarrollador y experto llegarán a un acuerdo.
Un Diagrama de Clases temprano: Con este modelo de dominio borrador, podemos construir una versión early de un diagrama de clases.
Un Prototipo muy simple guiado por un framework de automatización
18
de pruebas: Esto es, sentarse y, con el esbozo del diagrama de clases y el modelo de dominio, construir un prototipo bien simple del dominio.
Feedback del Prototipo: El experto de dominio interactuará con el prototipo, revisando si las reglas de negocio son correctas, si el sistema hace lo que debe hacer y, en base al feedback recibido, el equipo corregirá el modelo de dominio, lo mejorará y lo refinará. Así, volverá a corregir el prototipo y también el modelo de dominio.
Este proceso se repetirá hasta que el modelo, el diagrama y el prototipo sean correctos.
2.8. VALIDACIÓN DE REQUERIMIENTOS.
La validación de requerimientos, trata de mostrar que estos realmente definen el
sistema que el cliente desea. Coincide prácticamente con el análisis ya que este
implica encontrar problemas con los requerimientos. La validación de
requerimientos es importante debido a que los errores en el documento de
requerimientos pueden conducir a importantes costes al repetir el trabajo cuando
son descubiertos durante el desarrollo o después de que el sistema esté en uso.
El coste de arreglar un problema en los requerimientos haciendo un cambio en el
sistema es mucho mayor que repara los errores de diseño o los de codificación. La
razón de esto es que un cambio en los requerimientos normalmente significa que
el diseño y la implementación del sistema también deben cambiar y que este debe
probarse nuevamente.
Durante el proceso de validación de requerimientos, se deben llevar a cabo
verificaciones sobre requerimientos en el documentó de requerimientos. Estas
verificaciones comprenden:
1. Verificaciones de validez. Un usuario puede pensar que se necesita un
sistema para llevar acabo ciertas funciones. Sin embargo, el razonamiento
y el análisis pueden identificar que se requieren funciones adicionales o
diferentes necesidades, y cualquier conjunto de requerimientos es
19
inevitable un compromiso en el entorno del stakeholder.
2. Verificaciones de consistencia . Los requerimientos en el documento no
deben contradecirse. Esto es, no deben haber restricciones o descripciones
contradictorias de la misma función del sistema.
3. Verificación de completitud . El documento de requerimientos debe incluir
requerimientos que definan todas las funciones y restricciones propuestas
por el usuario del sistema.
4. Verificaciones de realismo. Utilizando el conocimiento de la tecnología
existente, los requerimientos deben verificarse para asegurar que se
pueden implementar. Estas verificaciones también deben tener en cuenta el
presupuesto y la confección de agendas para el desarrollo del sistema.
5. Verificabilidad . Para reducir la posibilidad de discusiones entre el cliente y el
contratista, los requerimientos del sistema siempre deben redactarse de tal
forma que sean verificables. Esto significa que deben poder escribir un
conjunto de pruebas que demuestren que el sistema a entregar cumple
cada uno de los requerimientos especificados.
Pueden utilizarse, en conjunto o de forma individual, varias técnicas de validación
de requerimientos:
1. Revisión de requerimientos. Los requerimientos son analizados
sistemáticamente por un equipo de revisores. Este proceso se trata en la
siguiente sección.
2. Construcción de prototipos. En este enfoque de validación, se muestra un
modelo ejecutable del sistema a los usuarios finales y a los clientes. Estos
pueden experimentar con este modelo para ver si cumple sus necesidades
reales.
20
3. Generación de casos de prueba. Los requerimientos deben poder probarse.
Si las pruebas para estos se conciben como parte del proceso de
validación, a menudo revela los problemas en los requerimientos. Si una
prueba es difícil o imposible de diseñar, normalmente significa que los
requerimientos serán difíciles de implementar y deberían ser considerados
nuevamente. Desarrollar pruebas para los requerimientos del usuario antes
de que se escriba código es una parte fundamental de la programación
externa.
Se deben llevar a cabo diferentes tipos de verificación:
Verificación de validez
Verificación de consistencia
Verificación de integridad
Verificación de realismo
Verificabilidad
Técnicas de validación:
Revisiones de requerimientos
Construcción de prototipos
Generación de casos de prueba
Análisis de consistencia automático (CASE, BD requerimientos)
2.9 DEFINICION DE PROPUESTA DE SOLUCION
Esta fase se ocupa de la reunión y estudio a detalle de los datos del sistema en operación y la especificación de los nuevos requerimientos del sistema a desarrollar.Con la recopilación de datos se completan los datos resultantes de la fase 1, añadiendo detalles sobre el sistema actual. Son medios comunes para acometer tal recopilación: Las entrevistas, cuestionarios, encuestas a usuarios finales, así como también, las consultas a documentos y manuales que contengan
21
lineamientos de funcionamiento o normas de procedimientos de operación. Existen varias técnicas y herramientas útiles para el análisis de datos. Una de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones de la organización de manera gráfica. Estos diagramas sirven para desarrollar el llamado diccionario de datos, el cual contiene la definición de los datos usados en el sistema, así como sus características de tipo, tamaño, limitaciones o especificaciones especiales. La documentación de la etapa de análisis recoge la descripción del sistema de información en uso, los requerimientos para el nuevo sistema y un probable plan de desarrollo en un reporte dirigido a la gerencia. Este reporte permite tomar la decisión de proseguir o no con el proyecto. El aspecto más importante de cualquier propuesta es identificar y comprender el problema que el cliente busca resolver. Uno de los puntos del desarrollo de una propuesta de solución es presentar una noción propia del problema, así como la propuesta para resolverlo, con el fin de convencer al cliente de que tal propuesta es la mejor. Para ello, se presentara lo que implica una descripción de los problemas:
1.- La Naturaleza del problema.2.- La historia del problema.3.- Las características del problema.4.- Las soluciones alternas consideradas.5.- La solución o la técnica seleccionada.
CONCLUSION
Como ya hemos visto una correcta captura y gestión de los requisitos de las aplicaciones permite reducir el tiempo de los proyectos. Esto supone mejorar el time to market, fundamental dada la competitividad de hoy en día, y reducir costes, implicando a menos recursos en la fase de desarrollo y pruebas.
Ya comprendimos que Un requisito es una característica de un sistema De información que representa una “condición para su aceptación por parte del usuario. Una
22
administración ineficiente de los requisitos, o inconsistencias entre éstos y el diseño y la programación de las aplicaciones hace que se generen los errores más Costosos y complicados de resolver de las aplicaciones, ya que afectan a la concepción de las mismas en su conjunto.Actividades como la especificación y la gestión de requisitos del usuario deben ser consideradas como unas de las más críticas dentro de todo el proceso de desarrollo, ya que no sólo es necesario identificar y especificar correctamente esos requisitos, sino que además es necesario realizar un seguimiento de su Aplicación durante todo el ciclo de vida del proyecto.
REFERENCIAS
“Ingeniería de software: un enfoque práctico” Roger Pressman, VI edición,
Sommerville Ian, 2005, “Ingeniería del Software”, Sétima edición, México
DF, Editorial Pearson.
http://elblogdelfrasco.blogspot.mx/2009/02/ddd-parte-1-poniendo-el-modelo-
23
de.html
http://manuelgross.bligoo.com/que-es-un-modelo-de-negocio-la-fuente-de-
tu-competitividad
http://www.itescam.edu.mx/principal/webalumnos/sylabus/asignatura.php?
clave_asig=IFF-1005&carrera=IINF-2010-220&id_d=57
http://losinformaticos213.blogspot.mx/2009/03/aplicacion-de-la-toma-de-
decicisones-en.html
http://rzamurianos.wordpress.com/2011/06/12/introduccin-al-flujo-de-
requisitos/
http://synergix.wordpress.com/2008/07/10/modelo-de-dominio/
http://gracielaresendiz04.blogspot.mx/2010_04_01_archive.html
24