U3, Captura de Requisitos de SI

1

Instituto Tecnológico Superior de Coatzacoalcos Análisis y Modelado de Sistemas de Información - 5o Sem – Ingeniería en Informática

Unidad 3: Captura de Requisitos

Objetivo:El estudiante Identificará las áreas de oportunidad en una organización, para la propuesta y diseño de sistemas de información. También analizará diversas alternativas de solución a partir de la identificación y definición de requerimientos especificados por el cliente.

3.1. Tipos de requisitos.Requisito. En la ingeniería de sistemas, un requisito (del inglés requirement: ‘requisito’) es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de software.

En la ingeniería clásica, los requisitos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen qué debe hacer el sistema, pero no cómo hacerlo.

La fase de captura, licitación y registro de requisitos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requisitos, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.

¿Qué es un requisito?Es una condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).Es una condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).Es una condición o capacidad que debe ser conformada por el sistema (RUP).Es algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).

Requisitos en ingeniería de software y sistemasEn ingeniería de sistemas existen tres tipos de requisitos.Un requisito funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requisito especifica algo que el sistema entregado debe ser capaz de realizar.

Un requisito no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.

Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto.

Una colección de requisitos describe las características o atributos del sistema deseado. Se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los diseñadores.

En la ingeniería de software se aplica el mismo significado, sólo que el énfasis está puesto en el propio software.Pseudorequerimientos: Son aquellos referidos al entorno donde sera instalado o implementado el sistema, que determinan en gran medida su desarrollo, pueden ser cuestiones como hardware y software.

L.S.C.A. Raúl Monforte ChulínMORCH Systems

2


Características de los requisitos:Los requisitos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.Necesario: Lo que pida un requisito debe ser necesario para el producto.No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes.Consistente: Ningún requisito debe entrar en conflicto con otro requisito diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requisitos debe ser consistente también.Completo: Los requisitos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.Alcanzable: Un requisito debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.Verificable: Se debe poder verificar con absoluta certeza, si el requisito fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.

Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema. Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de algún modo, pueden sustituir o mapear con esta lista de características.

Análisis de requisitosLa etapa en que se estudian los requisitos para verificar que estén correctamente adecuados a las características mencionadas es conocida como Análisis de requisitos. En la misma se enfocan e intentan solucionar las deficiencias que los requisitos puedan tener.

El análisis de requisito también conocido cola la ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software.

Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos – un conjunto de actividades que son denominadas análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve problemas y como negociador.

El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy probable que haya ambigüedad.

El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.

El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.


3


3.2. Fuentes de datos para el análisis del sistema.Fuentes de Datos para el análisis de sistemas.Las razones para iniciar un análisis de sistema son:

* La necesidad de resolver un problema.

Este sucede cuando el sistema no funciona como se esperaba, entonces se recurre al analista de sistemas.* Las nuevas necesidades.

Esto es cuando surgen nuevas disposiciones en la organización, puede tratarse de una nueva ley, practica contable, practica administrativa, etc.

Para identificar las modificaciones o adiciones al sistema.* La implantación de una nueva tecnología (tiende a reemplazar el equipo existente).* Mejoramiento general de los sistemas.

Existen básicamente tres fuentes de hechos dentro y alrededor de la organización:1. El sistema actual. Es verdaderamente raro que un analista tenga la oportunidad de desarrollar un sistema de información en donde anteriormente no haya existido ninguno. Con frecuencia se dedica una gran cantidad de tiempo investigando y documentando el sistema anterior, pero un análisis de ventajas y desventajas puede ayudar a determinar cuándo y qué tan extensamente debe estudiarse el sistema anterior.

Las principales ventajas de analizar el sistema anterior:* Eficacia del sistema actual.* Ideas de diseño.* Reconocimiento de recursos.* Conocimiento de conversión.* Punto de partida común.

Las principales desventajas de analizar el sistema anterior:* Gastos* Barreras Innecesarias.* Conocer que el sistema automatizado ya exista.* Conocer que el sistema automatizado no exista.

Para saber cuanto se ha invertido al sistema, como se documenta el sistema, si aporta pocos o muchos resultados y si hay cuello de botella utilizar el diagrama de flujo de datos.

Aspectos a considerar en el sistema actual.* Eficacia en el sistema actual.

Es una oportunidad para conocer si el sistema es satisfactorio, si requiere modificaciones menores, mantenimiento o bien si hay que reemplazar al sistema.* Ideas de diseño.


4


Permite o apoya al analista en ideas de diseño así como apreciar notablemente en como se hacen y en que forma las actividadespor el sistema.* Reconocimiento de recursos.

Le va a permitir al analista con que recursos se cuenta como lo que seria el personal, las instalaciones de infraestructura, el equipo de computo y la formade operación.* Conocimiento de conversión.

Se coordinaran aquellas funciones que se dejaran hacer al sistema anterior, pero tengo que tener la observación de cómo se hacen, como sehacia antes y ahora. Para hacer algunas modificaciones, de cómo van a reaccionar los usuarios.

2. Fuentes internas. Las fuentes más importante de hechos de estudio a disposición del analista es la gente. Los requerimientos de información puede ser planteado mejor por los usuarios de la información.

El papeleo describe la forma en que una organización esta estructurada.

La gente va a incluir a la gerencial, al personal de oficina o usuarios directos, que son los que se encargan de procesar la información.Ventaja: La gente nos dice que es lo que necesita.Desventaja: Cuando necesitamos información la gente es mas cerrada por conservar su trabajo, etc.

Papeleo dentro de la organización o documentación.

Aquí se utilizan tres tipos de documentos:Documentos que describen como esta organizada la empresa. Ejemplo: Descripción de puestos.Documentos que describen lo que planea hacer la empresa. Ejemplo: Presupuestos, etc.Documentos que describen lo que hace la empresa.Ejemplo: Nominas, estados financieros, etc.

3. Fuentes externas. La exploración de otros subsistemas de información dentro de la organización puede ser una fuente útil de recopilación de datos, procesamiento de datos o de ideas y técnicas para el reporte de la información.

Aquellas organizaciones que están fuera de la organización. Ejemplo : Clientes, proveedores, competencia, etc.Revistas que nos dan información teórica o practica que pueden ayudar al analista.

Los cursos, seminarios, talleres, etc.

3.3. Selección y diseño de instrumentos para la recopilación de Información.Recopilación de InformaciónRecopilación de datos: Deberá dirigirse al registro de aquellos hechos que permitan conocer y analizar lo que realmente sucede en la unidad o tema que se investiga. Esto consiste en la recolección, síntesis, organización y comprensión de los datos que se requieren.


5


Se conocen dos tipos de fuentes:1. Primarias: que contienen información original no abreviada ni traducida.2. Secundarias: obras de referencia que auxilian al proceso de investigación.

Se conoce otra división que se conforma por las siguientes fuentes:-Documentales-De campo.

Fichas bibliográficas, de trabajo y hemerográficasLas fuentes de recolección de datos son todos los registros de aquellos hechos que permitan conocer y analizar lo que realmente sucede en el tema que se investiga. Concluida la parte preparatoria de la investigación se inicia la fase de recopilación de datos.

Para recabar la información existente sobre el tema, el investigador se auxilia de instrumentos como las fichas de trabajo; hay diversos tipos de fichas de trabajo como:Fichas de trabajo para fuentes documentales, fichas de trabajo de una revista, fichas de trabajo de un periódico, para investigación de campo, para observación, fichas bibliográficas y hemerográficas.

Técnicas para la recolección de datos o métodos de obtención de información pueden ser:* Entrevista:Esta herramienta consiste básicamente en reunirse una o varias personas y cuestionarlas en forma adecuada para obtener información. La entrevista es una conversación dirigida, con un propósito especifico y que usa un formato de preguntas y respuestas.

Con la entrevista se busca obtenerla opinión y sentimientosdel entrevistado acerca del sistema actual, los objetivos de la organización y los personales. En ocasiones las opiniones de la persona pueden ser mas importantes y mas reveladoras que los hechos, debido a que el entrevistado conoce mejor la organización que el analista.

Los objetivos son información importante que puede ser recogida en la entrevista. Los hechos pueden representar los hechos pasados, los objetivos futuros. En la entrevista, se esta dando una relación con alguien que probablemente es extraño. Por tanto se necesita dar confianza, comprensión rápidamente pero al mismo tiempo, se debe mantener el control de la entrevista.

Dentro de la entrevista se deberá vender el sistema proporcionando al entrevistado información necesaria, las entrevistas permiten la interacción con las preguntas y sus significado. En una entrevista el analista tiene la oportunidad de refinar una pregunta, definir un termino dudoso; cambiar el curso de las preguntas, responder una apariencia confusa y en general controlar el contexto. “Cinco pasos para la preparación de la entrevista”.Lectura del material a fondo.Leer y comprender tanta información acerca del entrevistado y su organización como le sea posible. Este material es obtenido, a veces, mediante una llamada rápida a la persona de contacto para pedirle un reporte de la función que desempeña la organización; pudiera ser esta una publicación.

Este servirá para conocer el lenguaje que usanlos miembros de la organización, así como es la organización.


6


Establecimiento de los objetivos de la entrevista.Debe usarse la información de fondo y la propia experiencia para establecer los objetivos de la entrevista. En esta punto deberá incluir cada una de las áreas de tratamiento de información y su comportamiento en la toma de decisiones de las cuales deberá hacer preguntas acerca de: fuentes de información, formatos de la información, frecuencia de la toma de decisiones, cualidades de la información y estilo en la toma de decisiones.

Decidir a quien entrevistar.Deben incluir personas clave de todos los niveles que serán afectados por el sistema de información de alguna forma.

Prepare al entrevistado.Prepare a la persona que va a ser entrevistada, dándole a conocer con anticipación y que tenga tiempo para prepararse para la entrevista. Las entrevistas deben de durar de 45 a una hora, mas tiempo haría de esta una actividad difíciltanto para el entrevistado como para el analista.

Decida el tipo de pregunta y su estructura.Es necesario antes de realizar la entrevista, escribir preguntas para tratar de abarcar las áreas principalesde la toma de decisiones descubiertas cuando se averiguaron los detalles de la entrevista. Tipo de preguntasPreguntas abiertas:Son aquellas preguntas que describen hechos o situaciones por parte del entrevistado con una gran cantidad de detalles que a juicio del entrevistado son importantes.

Los beneficios de usar este tipo de preguntas son: Pone confortable al entrevistado. Permite que el analista recoja el vocabulario del entrevistado, el cual refleja su educación, valores, actitudes y

creencias. Proporciona riqueza de detalles. Revela caminos para preguntas posterioresque podrían haber quedado sin atacar Hace que sea mas interesante para el entrevistado. Permite la espontaneidad. Se les puede usar en un aprieto si es que el entrevistador es tomado por sorpresa. Las desventajas del uso de estas preguntas son: El usar estas preguntas pueden dar como resultado muchos detalles revelantes. Se puede perder el control en la entrevista. Permitir respuestas que pueden llevarse demasiado tiempo para la cantidad de información útil obtenida. Puede demostrar que el entrevistado no esta preparado. Puede dar la impresión de falta de objetivo en la entrevista.

Preguntas cerradas:En las preguntas cerradas las respuestas posibles están cerradas al entrevistado, debido a que solamente puede responder con un numero finito, tal como “ninguno”, “uno”, o “quince”.


7


Una pregunta cerrada limita las respuestas disponibles al entrevistado. Tal vez esta familiarizado con las preguntas cerradas que hay en los exámenes de selección múltiple de la escuela. Se le hace una pregunta y se lo dan cinco respuestas, pero no se le permite que escriba su propia respuesta y que cuente como respuesta correctamente contestada.

Ejemplo.¿Qué tantos reportes genera en un mes?¿Desde hace cuanto trabaja para Barkerloo Brothers?¿Cuál de las siguientes fuentes de información es mas valiosa para usted:Formas de queja de clientes archivadas.Interacción cara a cara con el cliente.La devolución de mercancía por si misma.Liste sus dos prioridades máxima para el departamento de ventas.¿Quién recibe esta salida?Un tipo especial de pregunta cerrada es la pregunta bipolar. Esto limita todavía mas al entrevistado, permitiéndole solamente una selección de algún extremo, tal como si o no, cierto o falso, de acuerdo o desacuerdo.¿Usa usted una microcomputadora?¿Esta usted de acuerdo o no en que las funciones de contestadora automática valdrían la pena?¿Quiere usted recibir una impresión de computadora de su estado de cuenta cada mes?¿su departamento de contabilidad proporciona transferencia de fondos electrónicay automática de los cheques de nomina para los empleados porhoras?¿Estaforma estacompletamente llenada?

Los beneficios de usar estas preguntas cerradas de cualquier tipo incluyen: Se ahorra tiempo. Se facilita la comparación de las entrevistas. Se llega al punto. Se mantiene control sobre la entrevista. Se tratan muchos temas rápidamente. Se obtienen datos revelantes. Sin embargo, las desventajas del uso depreguntas cerradas son sustanciales. Incluyen: Ser aburridas para el entrevistado. No llegan a obtener grandes detalles (debido a que el entrevistador proporciona el marco de referencia para el

entrevistado. Se pierden ideas principales por la razón anterior. No se llega a establecer una relación armoniosa entre el entrevistador y el entrevistador.

Entrevistas estructuradas:En una entrevistaestructurada todo esta planeadoy el plan es seguido estrictamente. Laspreguntas cerradasson la parte medular de una entrevista completamenteestructurada.

Entrevista no estructurada:En esta entrevista el tiempo no tiene límite y por lo tanto es posible recolectar información de todo tipo y se necesita la habilidad del entrevistador para improvisar y tocar áreas no contempladas.


8


Las ventajas de la entrevista no estructurada son:1) El entrevistador tiene mayor flexibilidad para cambiar los tiempos de la entrevista para que se puedan cubrir todos los temas.2) El entrevistador puede ahondar en áreas que aparecen de manera espontánea durante la entrevista.

Las desventajas de la entrevista no estructurada son:1) Uso ineficiente del tiempo por parte de los participantes de la entrevista.2) El entrevistador puede introducir sus propios sesgos en las entrevistas o al notificar sus resultados.3) Se puede obtener información no relevante y/o ajena al problema.4) El análisis de los resultados puede llevarse mucho tiempo.5) Se necesita más tiempo para reunir hechos esenciales.

* Cuestionario: Están constituidos por series de preguntas escritas, predefinidas, secuenciadas y separadas por capítulos o temática específica.

Los cuestionarios son técnicas de recopilación de información que permiten que los analistas estudien actitudes, creencias, comportamientos y características de varias personas principales en la organización que pueden ser afectadas por los sistemas actuales y enproceso.

Las actitudes son lo que la gente de la organización dice que quiere. Las creencias son lo que la gente piensa que es, de hecho cierto. El comportamiento es lo que hacen los miembros de la organización. Las características son propiedades de las personas o cosas.

Las respuestas obtenidas mediante cuestionarios usando preguntas cerradas pueden ser cuantificadas. Las respuestas a cuestionarios de preguntas abiertas sonanalizadas e interpretadasde otras formas. Las preguntas sobre actitudes y creencias son notablemente sensibles a la redacción escogida por el analista.

Los cuestionarios pueden ser usados para determinar que tan amplio o limitado es el sentimiento expresado en una entrevista. Pueden ser usados para investigar a una gran muestra de usuarios de un sistema, para tratar de encontrar problemas o recoger cosas importantes antes para realizar la entrevista.

El cuestionario requiere un amplio tiempo de planeación.

¿Que es lo que debo hacer para usar un cuestionario?. Las personas a quien debe de preguntarse están ampliamente dispersas (diferentes lugares dentro de la

organización). Se debe conocer el grado en que se aprueba o desaprueba una característica particular del sistema propuesto

dependiendo de la cantidad de personas: Se hace un estudio exploratorio para medir la opinióngeneral; darle al proyecto una dirección especifica: Se debe utilizar el cuestionario para asegurarse de cualquier problema en el sistema actual que este

identificado.


9


Definición de preguntas en el uso del cuestionario:La diferencia entre las preguntas de una entrevista y un cuestionario; se encuentran en que el cuestionario exige al analista ser muy claro; el flujo de preguntas deber ser coherente; las preguntas del interlocutor anticipadas y la administración del cuestionario planeada a detalle.

Los tipos básicos de preguntas usadas son las abiertas y las cerradas:Preguntas abiertas:Son aquellas quedejan todas las posibles opciones de respuesta al interlocutor; es decir; usa términos como describe; en su opinión; que siente; etc. Cuando considere este tipo de preguntas anticipe el tipo de respuesta a obtener; para u correcta interpretación. Por lo tanto si escribe una pregunta de este tipo debe ser lo suficientemente estrecha para guiar al interlocutor a que responda de forma especifica.

Ejemplo:¿Cuales son los problemas más frecuentes que presenta su sistema de información?a___________________________________________________________________________________________________________________b___________________________________________________________________________________________________________________c___________________________________________________________________________________________________________________

De los problemas listados anteriormente, ¿cual es el que se presenta con mayor frecuencia?______________________________________________________________________________________________________________________________________________________________________________

¿Porque?________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Preguntas cerradas:Conocidas también como enunciados. Son aquellas que se limitan o cierran las opciones de respuesta disponibles.

Ejemplo:De acuerdo a sus necesidades marque con una cruz el nombre del software que usa para sus actividades diarias con mayor frecuencia:( ) Word ( ) Visual fox ( ) Excell Turbo C ( )( ) Power point ( ) Java

Note que no se solicita preferencia y se limita solo a uno.

Las preguntas cerradas deben ser usadas cuando el analista sea capaz de generar listas donde todas las reapuestas posibles ala pregunta se involucren y cuando todas las respuestas listadas sean mutuamente excluyentes con el objetivo de seleccionar una. Debe cuidarse al generar preguntas cerradas de que la lista de respuesta sea limitada; ya que de no hacerlo así; esta lista se volvería infinita. Es necesario usar preguntas cerradas cuando se va analizar un gran numero de personas.


10


Formato del cuestionario Deje bastante espacio en blanco alrededor del cuestionario. Use papel blanco o muy claro. Deje suficiente espacio para las respuestas, usar de 3 a 5 líneas. Pida que las respuestas sean encerradas en un circulo. Use adjetivos que le ayudena determinar el formato. Respuestas escritas para calcular el espacio. Sea consistente en el estilo (orden o sombreado de preguntas) Orden en las preguntas. Las preguntas importantes para el interlocutor van primero. Agrupe conceptos de contenido similar. Emplee tendencias asociativas de los interlocutores. Ponga primero los termino menos controvertidos.

* Encuesta: La recolección de información se hace a través de formularios, los cuales tienen aplicación en aquellos problemas que se pueden investigar por métodos de observación, análisis de fuentes documentales y demás sistemas de conocimiento.

Esta técnica de recolección de información es la más usadas, a pesar de que cada vez pierde mayor credibilidad por el sesgo de las personas encuestadas, la encuesta se fundamenta en el cuestionario o conjunto de preguntas que se preparan con el propósito de obtener información de las persona.

* Observación: La observación esotra técnica útil para el analistaen su proceso de investigación, consiste en observar a las personas cuando efectúan su trabajo. Como técnica de investigación, la observación tiene amplia aceptación científica.

La observación es una técnica de observación de hechos durante la cual el analista participa activamenteo actúa como espectador de las actividades llevadas a cabo por una persona para conocer mejor su sistema.

El propósito de la observación es múltiple, permite al analista determinar que se esta haciendo, como se esta haciendo, quien lo hace, cuando se lleva a cabo, cuanto tiempo toma, donde se hace y porque se hace.

Tipos de observaciónEl analista puede observar de tres maneras básicas: Puede observar a una persona o actividad sin que elobservado se de cuenta y sin interactuar por parte del propio

analista. El analista puede observar una operación sin intervenir para nada pero estando la persona observada

enteramente conciente de la observación. Se puede observar y estar en contacto con las personas observadas. La interrogación puede

consistirsimplemente en preguntar respecto a una actividad especifica, pedir una explicación, etc.


11


La observación puede emplearse para verificar los resultados de una entrevista, o bien como preparación de la misma . También es otra técnica valiosa para recopilar datos que implican relaciones. La observación tiende a adquirir mayor sentido al nivel técnico del procesamiento de datos, donde las tareas se cuantifican mas fácilmente. Entre estas tareas encontramos la recopilación, acumulación y transformación de los datos.

Pasos de la observación:1. Determinar y definir aquelloque se va a observar.2. Estimar el tiempo necesario de observación.3. Obtener la autorización para llevar a cabo la observación.4. Explicar a las personas que van a ser observadaslo que se va hacer y las razones para ello.

Conducciòn de la observación1. Familiarizarse con los componentes físicos del área inmediata a observar.2. Mientras se observa,medir el tiempo en forma periódica.3. Anotar lo que se observa lo más específicamente posible, evitando las generalidades y las descripciones vagas.4. Si se está en contacto con las personas observadas, es necesario abstenerse de hacer comentarios cualitativos o queimplique un juicio de valor.5. Observar las reglas de cortesía y seguridad. Seguimiento de la observación.1. Documentar y organizar formalmente las notas e impresiones entre los analistas.2. Revisar los resultados y conclusiones junto con la persona observada, el supervisor inmediato y posiblemente otro analista.

La observación le permite al analista de sistemas generar experiencia en cuanto a observar y como observar.

Se recomienda el uso de la observación con otras técnicas para maximizar su efectividad, sobre todo cuando se trata de analistas con poca experiencia.

Muestreo y recopilación de documentos.Dos técnicas adicionales a disposición del analista, particularmente en las tareas de indagación de hechos, son el muestreo y la recopilación de documentos. Ambas técnicas están orientadas a los papeles y documentos almacenados en toda la organización. Ambas técnicas proporcionan una fuente de información que no puede obtenerse con ningún otro enfoque de indagación de hechos.

Análisis e interpretación de información:La interpretación de los resultados de la indagación lleva inmediatamente a la solución. El análisis del instrumento de recolección de información de campo (encuesta), fue utilizando el análisis individual de preguntas que se realiza con base en los porcentajes que alcanzan las distintas respuestas de cada pregunta.

Para llevar a cabo este tipo de análisis se diseño una forma donde se tabulan las respuestas en base a la cantidad de personas que contestaron cada respuesta y el porcentaje que representa del total de la muestra.

Redacción y presentación del informe:El objetivo del informe es presentar a los lectores el proceso que se realizó para presentar una solución al problema planteado, para lo cual es necesario hacer la presentación del problema, los métodos empleados para su estudio, los


12


resultados obtenidos, las conclusiones a las que se llegaron y las recomendaciones en base a estas.

Con respecto a la estructura del informe, ésta es sencilla y sigue fielmente los pasos fundamentales del diseño de la investigación, ya que el informe debe ser la respuesta a lo planteado por el diseño de investigación.

El formato y contenido de este reporte incluye:1.- Una nueva exposición de la razón y alcance del análisis2.- Una lista de los principales problemas identificados3.- Una presentación de todos los requerimientos de los usuarios4.- Una planeación de todas las suposiciones hechas por el analista de sistemas para el análisis de datos.

3.4. Captura de requisitos candidatos.El propósito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto.

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 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 candidatosLa 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 que iteración se implementará la característica.

Comprender el contexto del sistemaHay 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 entres 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 negociosoportará el sistema.


13


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 tambien capturan requisitos no funcionales específicos de un caso de uso determinado.

Capturar requisitos no funcionalesLos 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 metodología de desarrollo.Selección de las metodologíasEl acelerado desarrollo de software en la actualidad y la necesidad de que los proyectos sean concluidos exitosamente siendo un producto de gran valor para los clientes, generan grandes cambios en las metodologías adoptadas por los equipos para cumplir sus objetivos, puesto que unas se adaptan mejor que otras al contexto del proyecto brindando mejores ventajas. Debido a ello es de vital importancia la selección de una metodología robusta que ajustada en un equipo cumpla con sus metas, y satisfaga mas allá de las necesidades definidas al inicio del proyecto.

En el momento de seleccionar una metodología para aplicar en la construcción de un sistema es necesario tener en cuenta las características del proyecto y del equipo y ser adaptada al contexto del mismo. Una de las características principales a tener en cuenta es la complejidad del sistema a desarrollar, es decir, es necesario valorar la complejidad del proceso a automatizar, la cantidad de requisitos que deben ser implementados en el sistema y la complejidad y cantidad de información que se maneja en el proceso. La complejidad puede ser alta, media o baja en dependencia de las características antes mencionadas. Por ejemplo un proceso económico de una empresa es más complejo que el proceso de marketing de la misma.

En el área de informática los sistemas que se realizan responden a peticiones no solo del propio centro de trabajo sino de otras áreas que necesitan automatizar su gestión.

Criterios de selección de Metodologías de desarrollo de SoftwareLa 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.

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 impuestas 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 mas 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


14


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 una menor énfasis en la arquitectura del software.

Todo lo anteriormente mencionado, me ayuda a concluir algunas cosas. Es claro que 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 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.

El desarrollo de software no es una tarea sencilla, por mucho tiempo esta labor se ha llevado adelante sin una metodología defi nida. Al respecto algunos autores defi nen una metodología como una colección de procedimientos, técnicas, herramientas y documentos auxiliares que ayudan a los desarrolladores de software en sus esfuerzos por implementar nuevos sistemas de información. En las dos últimas décadas, respecto a estas metodologías de desarrollo de software se ha entablado un intenso debate entre dos grandes corrientes. Por un lado, las denominadas metodologías tradicionales, centradas en el control del proceso, con un riguroso seguimiento de las actividades involucradas en ellas. Por otro lado, las metodologías ágiles, centradas en el factor humano, en la colaboración y participación del cliente en el proceso de desarrollo y a un incesante incremento de software con iteraciones muy cortas. El artículo presenta una propuesta, en medio de este debate, para seleccionar una metodología de desarrollo de software.

3.6. Modelo del negocio.Modelo de negociosUn modelo de negocio, también llamado diseño de negocio o diseño empresarial, es el mecanismo por el cual un negocio busca generar ingresos y beneficios. Es un resumen de cómo una compañía planifica servir a sus clientes. Implica tanto el concepto de estrategia como el de implementación. Comprende el conjunto de las siguientes cuestiones:* Cómo seleccionará sus clientes* Cómo define y diferencia sus ofertas de producto


15


* Cómo crea utilidad para sus clientes* Cómo consigue y conserva a los clientes* Cómo sale al mercado (estrategia de publicidad y distribución)* Cómo define las tareas que deben llevarse a cabo* Cómo configura sus recursos* Cómo consigue el beneficio

En una definición más actual, podemos decir que un "modelo de negocio describe el modo en que una organización crea, distribuye y captura valor". Esta definición conlleva un tratamiento del concepto que va mucho más allá de la generación de ingresos o gastos, y divide el concepto en partes más pequeñas (p.e. Segmentos de clientes, proposición de valor, canales, relación con los clientes, esquema de ingresos, recursos clave, actividades clave, socios clave y estructura de costos) que pueden ser abordadas, tanto de un modo individual, como analizando como se configuran las relaciones entre ellas.

Tipos de modelos de negociosGeneralmente, los modelos de negocio de las compañías de servicio son más complejos que las de fabricantes y vendedores. El modelo más viejo y básico es el del tendero. Este modelo consiste en instalar una tienda en el sitio donde deberían estar los clientes potenciales y desplegar la oferta de un producto o servicio.

A lo largo de los años los modelos de negocio han llegado a ser mucho más sofisticados. El modelo del cebo y el anzuelo (también llamado el de las cuchillas y la maquinilla o el de los productos atados) fue introducido a principios del siglo XX. Consiste en ofrecer un producto básico a un precio muy bajo, a menudo a pérdidas (el cebo) y entonces cobrar precios excesivos por los recambios o productos o servicios asociados. Algunos ejemplos son los de la maquinilla de afeitar (cebo) y las cuchillas (anzuelo); las impresoras (cebo) y los cartuchos de tinta (anzuelo); y las cámaras de fotos (cebo) y el revelado de fotografías (anzuelo). Una variante interesante de este modelo es un desarrollador de software que ofrece gratis su lector de textos pero cobra muchos cientos de dólares por su procesador de textos.

En los años 1950, aparecieron nuevos modelos de negocio de la mano de McDonald's y Toyota. En los años 1960, los innovadores fueron Wal-Mart y los hipermercados. En los 1970 nacieron nuevos modelos de negocio introducidos por Federal Express y Toys "Я" Us; en los 1980 por Blockbuster, Home Depot, Intel, y Dell Computer; en los 1990 porSouthwest Airlines, eBay, Amazon.com, y Starbucks. Cada una de estas innovaciones en modelos de negocio pueden proporcionar a una compañía una ventaja competitiva. Pero los tiempos están cambiando y las compañías deben replantearse continuamente su diseño de negocio, cambiando sus modelos al ritmo en que el valor cambia de un sector industrial a otro. Hoy en día, el éxito o fracaso de una compañía depende sobre todo de cómo se adapta su diseño de negocio a las prioridades de sus clientes.

El modelo de negocio, es aquel en el cual se planifica de manera ordenada y sistemática todo el proceso que ha de llevarse a cabo en el establecimiento y desarrollo de un negocio, por tanto debes de incluir desde el aporte de sus accionistas hasta contemplar todos los posibles desembolsos necesarios para poder operar, tales como licencias, maquinarias y equipos, capacitación, estudio de mercado, etc. Con una Visión clara, objetivos bien definidos y una buena Misión, se han de elaborar los forecast(pronósticos) y presupuestos, Cash Flow (flujos de caja), tanto como sean necesarios para el buen desenvolvimiento, es decir, es mejor cometer un error en Papeles y no en la realidad, ya que es más complejo un modelo de negocio en una compañía de Servicios, que si fuera una de Fabricación o distribución de productos.3.7. Modelo del dominio.


16


Modelo de 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 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.

El siguiente diagrama es un pequeño ejemplo de Modelo de Dominio, en este caso, referido al Metro o sistema de transporte subterraneo de una ciudad cualquiera.

En este diagrama se ve que un Usuario del Metro tiene cero o más boletos, comprados estos en una maquina de Venta de Boletos; dicha maquina “crea” los boletos los cuales son consumidos en un viaje, el cual tiene una estación de origen y otra de destino. Finalmente se ve que una estación tiene una o más maquinas de venta así como empleados de limpieza, seguridad y operaciones.

Es posible capturar un mayor grado de detalle en uno de estos modelos; corresponde al analista decidir cuanto detalle va a ser necesario y hasta donde llegar a modelar. El objetivo es capturar lo necesario para comprender donde va a funcionar el sistema que estamos diseñando y esto demanda una cantidad distinta de detalles cada vez.

El modelo de dominio puede ser tomado como el punto de partida para el diseño del sistema. Esto es así ya que cuando se realiza la programación orientada a objetos, se supone que el funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el mapa de conceptos del modelo de domino constituye una primera versión del sistema.

En la aproximación llamada Desarrollo Guiado por Modelos al modelo de dominio se le conoce como Modelo Independiente del Computador o CIM, por sus siglas en inglés. El CIM es el que da inicio al proceso de desarrollo y ocupa el rol, tanto de modelo de requisitos como de modelo análisis.

Por otra parte, cuando se sigue una aproximación Centrada en Casos de Uso como RUP/UP, el modelo de dominio es utilizado como entrada en la tarea análisis de los casos de uso en la construcción de los llamados escenarios de análisis.

Es decir, y con esto quiero concluir, que el modelo de dominio ocupa un rol protagónico en el desarrollo moderno de software y constituye un artefacto que vale la pena tener en nuestros proyectos.

3.8. Validación de requerimientos.Los requisitos una vez definidos necesitan ser validados.Es necesario asegurar que el análisis realizado y los resultados obtenidos de la etapa de definición de requisitos son correctos. Pocas son las propuestas existentes que ofrecen técnicas para la realización de la validación y muchas de ellas consisten en revisar los modelos obtenidos en la definición de requisitos con el usuario para detectar errores o inconsistencias.

El proceso de validación de requisitos debe realizarse o de lo contrario se corre el riesgo de implementar una mala especificación, con el costo que eso conlleva.


Figura 3.7 Ejemplo de Modelo de Dominio de un sistema de subterráneo.

17

Figura 3.8 La validación en el proceso de requisitos.


Los parámetros a comprobar por la especificación son:1. Validez: No basta con preguntar a un usuario, todos los potenciales usuarios pueden tener puntos de vista distintos y necesitar otros requisitos.

2. Consistencia: No debe haber contradicciones entre unos requisitos y otros.

3. Completitud: Deben estar todos los requisitos. Esto es imposible en un desarrollo iterativo, pero, al menos, deben estar disponibles todos los requisitos de la iteración en curso.

4. Realismo: Se pueden implementar con la tecnología actual.

5. Verificabilidad: Tiene que existir alguna forma de comprobar que cada requisito se cumple.

Validación de Requisitos. La validación de requisitos tiene como misión demostrar que la definición de los requisitos define realmente el sistema que el usuario necesita o el cliente desea (Lowe & Hall, 1999). El proceso de validación de requisitos comprende actividades que generalmente se realizan una vez obtenida una primera versión de la documentación de requisitos.

La actividad de validación tiene como entrada el documento de requisitos, los estándares relacionados y el conocimiento de la organización, y como salida se obtiene una lista de problemas y una lista de acciones recomendadas.

Técnicas de validación de requisitos:Reviews o Walk-throughs: Está técnica consiste en la lectura y corrección de la completa documentación o modelado de la definición de requisitos. Con ello solamente se puede validar la correcta interpretación de la información transmitida. Más difícil es verificar consistencia de la documentación o información faltante.

Auditorías: La revisión de la documentación con esta técnica consiste en un chequeo de los resultados contra una checklist predefinida o definida a comienzos del proceso, es decir sólo una muestra es revisada.

Matrices de trazabilidad: Esta técnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo (Durán, Bernáldez, Ruíz &Toro, 1999). Es necesario ir viendo qué objetivos cubre cada requisito, de esta forma se podrán detectar inconsistencias u objetivos no cubiertos.

Prototipos: Algunas propuestas se basan en obtener de la definición de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario (Olsina,1999). Esta técnica tiene el problema de que el usuario debe entender que lo que está viendo es un prototipo y no el sistema final.

2.9. Definición de propuesta de solución. Requisito (sistemas).Propuesta de la solución

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


18


nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado del análisis. 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 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 grafica. 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 ala 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

Lema:El mejor amigo del estudiante es el conocimiento, pues en el encontraras que hacer en el mañana. Y recuerda un licenciado no es una copia, es original y se atreve a cambiar una realidad, no importa el tiempo o el espacio, todo es posible mientras creas que es así.

Gracias a Dios: Ya vas hacer profesionista, ser profesional es parte de una mejor calidad de vida para ti y para toda tu familia, lograrlo es una gran satisfacción de manera espiritual, emocional, social y laboral; búscalo, esfuérzate y disfrútalo; y veras que ser profesionista es excelentemente profesional.

MORCH Systems.


U3, Captura de Requisitos de SI

Documents

Transcript of U3, Captura de Requisitos de SI