DESARROLLO DE PROYECTOS INFORMTICOS

DESARROLLO DE PROYECTOS INFORMTICOSGua para el estudiante

Elaborado por el formador:Mauico Flores RolyPrograma Tcnico Laboral en SistemasCONTENIDOPRESENTACIN5

GUA METODOLGICA6

UNIDAD UNO

CICLO DE VIDA DEL SOFTWARE10

ETAPAS DEL CICLO DE VIDA DEL SOFTWARE11

MODELOS DEL CICLO DE VIDA DEL SOFTWARE14

Modelo en cascadaE15

Modelo en Espiral16

Modelo Incremental18

Modelo Evolutivo20

Modelo Concurrente21

METODOLOGAS22

Metodologa CMMI23

Metodologa ISO25

Metodologa SCRUM25

TCNICAS DE RECOLECCION DE DATOS26

Introspeccin27

Entrevista Abierta28

Cuestionario30

Grupos de Discusin30

Tormenta de Ideas31

Entrevistas32

Observacin33

FICHA PARA ENTREVISTAS33

ESPECIFICACION DE REQUERIMIENTOS37

FORMATO IEEE830 REQUERIMIENTOS47

UNIDAD DOS

UML51

DIAGRAMAS DE CASO DE USO52

DIAGRAMAS DE SECUENCIA55

HERRAMIENTAS CASE

59

MODELO ENTIDAD RELACION60

CRONOGRAMAS61

BIBLIOGRAFIA63

Ciclo de Vida y Anlisis de requerimientos

TEMAS

1. Ciclo de Vida del Software y Metodologas2. Tcnicas de Recoleccin de Datos3. Anlisis de requerimientos

Logros de Competencia

1. Conocer el ciclo de vida del software y aplicar tcnicas de recoleccin de datos (entrevistas, observacin) de acuerdo a los requerimientos del cliente, elaborar informe de especificacin de requisitos de software utilizando herramientas informticas segn protocolos y normas.

Indicador de Logro Evidencia de

1. Conoce el ciclo de vida del software y

las metodologas Conocimiento

2. Conoce tcnicas de recoleccin y las diferentes formas de anlisis y organizacin Conocimiento

3. Elabora propuestas de trabajo de acuerdo

con las necesidades expuestas en los

requerimientos segn normas y protocolos Producto

El Formador Dice y Hace:

1. Ciclo de vida del software Software: procedimientos y reglas lgicas escritas en la forma de programas y aplicaciones, que definen el modo de operacin de la computadora. Es la suma total de los programas de computadora, procedimientos, reglas, la documentacin asociada y los datos que pertenecen a un sistema de cmputo. Aplicacin: es un tipo de programa informtico diseado como herramienta para permitir a un usuario realizar uno o diversos tipos de trabajo. Ciertas aplicaciones desarrolladas 'a medida' suelen ofrecer una gran potencia ya que estn exclusivamente diseadas para resolver un problema especfico. Desarrollo de Software: es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo". Concretamente "define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo: Ciclo de Vida: Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se mueve un proyecto de desarrollo de software. Desde la fase inicial hasta la fase final. El propsito es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicacin, es decir, para garantizar que el software cumpla los requisitos para la aplicacin y verificacin de los procedimientos de desarrollo: se asegura de que los mtodos utilizados son apropiados. 2. ETAPAS DEL CICLO DE VIDA DEL SOFTWARENecesidades: esta etapa tiene como objetivo la consecucin de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecer al usuario del sistema a desarrollar (qu, y no cmo, se va a desarrollar).

Dado que normalmente se trata de necesidades del cliente para el que se crear la aplicacin, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relacin comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial). Especificaciones: Por medio de esta etapa se obtendr un nuevo documento que definir con ms precisin el sistema requerido por el cliente.Lo ms normal ser que no resulte posible obtener una buena especificacin del sistema a la primera; sern necesarias sucesivas versiones del documento en que irn quedando reflejada la evolucin de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados).

Anlisis: Es necesario determinar qu elementos intervienen en el sistema a desarrollar, as como su estructura, relaciones, evolucin en el tiempo, detalle de sus funcionalidades, ... que van a dar una descripcin clara de qu sistema vamos a construir, qu funcionalidades va a aportar y qu comportamiento va a tenerDiseo: Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar cmo va a hacerlo (cmo debe ser construido el sistema?; aqu se definirn en detalle entidades y relaciones de las bases de datos, se pasar de casos de uso esenciales a su definicin como casos expandidos reales, se seleccionar el lenguaje ms adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, libreras, configuraciones hardware, redes, etc.).

Implementacin: Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programacin y/o para un determinado sistema gestor de bases de datos.Pruebas: el objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseo y/o programacin. Es conveniente que sean planteadas al menos tanto a nivel de cada mdulo (aislado del resto), como

de integracin del sistema (segn sea la naturaleza del proyecto en cuestin se podrn tener en cuenta pruebas adicionales, p.ej. de rendimiento).Validacin: Esta etapa tiene como objetivo la verificacin de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase tambin es interesante contar con los use cases, generados a travs de las correspondientes fases previas, que servirn de gua para la verificacin de que el sistema cumple con lo descrito por estos).Mantenimiento y Evolucin: Finalmente la aplicacin resultante se encuentra ya en fase de produccin (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondr ya pequeas operaciones tanto de correccin como de mejora de la aplicacin (p.ej. mejora del rendimiento), as como otras de mayor importancia, fruto de la propia evolucin (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).

El Formador Dice y el estudiante Hace:

3. MODELOS DEL CICLO DE V IDA DEL SOFTWAREUn modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transicin asociadas entre estas etapas.

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software.

Define las fases primarias esperadas de ser ejecutadas durante esas fases.

Ayuda a administrar el progreso del desarrollo, y

Provee un espacio de trabajo para la definicin de un detallado proceso de desarrollo de software.

As, los modelos por una parte suministran una gua para los desarrolladores de software con el fin de ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran un marco para la administracin del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc. 3.1. MODELO EN CASCADA

Es un modelo base para los dems modelos. Fue definido por Royce y se trata principalmente de que se debe completar un paso correctamente sin ningn error para pasar al siguiente. Caractersticas del modelo cascadaEste modelo muestra de una forma bsica el desarrollo de software, y representa en fases separadas procesos fundamentales.Dice que se debe probar el software despus de construirlo y antes de operarlo. Cada fase tiene como salida documentacin.Fases del Modelo Cascada Las fases son: Ingeniera y Anlisis del Sistema: establece requisitos de los elementos del sistema. Anlisis de los requisitos del software: identifica las funciones del software, el rendimiento, sus interfaces y la informacin. Diseo: se basa en estructura de datos, arquitectura del software el detalle de los procedimientos y la caracterizacin de la interfaz. Adems escoge las herramientas para la codificacin. Codificacin: el diseo se traduce en lenguaje de mquina. Pruebas: Aqu se comprueba si existe algn error con el software o si funciona correctamente. Hasta que sea aceptado por el usuario. Mantenimiento: esta fase se da debido a que despus de la entrega pudo haber errores en el software, o el software no se adapte al entorno externo o que el cliente requiera ampliaciones funcionales o de rendimiento.VENTAJAEste modelo como es sencillo solo utiliza los pasos intuitivos para desarrollar software, adems es fcil de explicarlo al cliente.DESVENTAJAS Los proyectos raramente siguen el flujo secuencial, hay iteraciones El cliente no puede establecer al principio todos los requisitos. El cliente deber tener paciencia pues la versin operativa del producto solo estar disponible en las ltimas etapas del proyecto.3.2. MODELO EN ESPIRALEs una serie de ciclos los cuales se repiten en forma de espiral, cada vez que se avanza un ciclo se va alcanzando un nivel superior hasta concluir el proyecto. Lo caracterstico de este modelo es que incluye un anlisis de riesgo es decir que podemos analizar si el proyecto puede continuar o mejor lo suspendemos.Este modelo se basa en que antes de hacer algo debemos analizarlo, tambin debemos buscar varias opciones de resolucin de problemas para de all escoger la opcin ms conveniente, y adems analizar los riesgos que se pueda tener. Este modelo necesita de otro para poder desarrollarse. Se debe escoger el modelo cascada cuando se pierda el control del presupuesto o por el calendario; y el de prototipeo cuando tengamos problemas con la interfaz. El modelo espiral consta de 4 cuadrantes que son sus fases y se dividen de la siguiente forma:1.- Planificacin 2.- Anlisis de Riesgos3.- Ingeniera 4.- Evaluacin

En cada vuelta o iteracin hay que tener en cuentaLos Objetivos: Que necesidad debe cubrir el producto.

Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:

1. Caractersticas: experiencia del personal, requisitos a cumplir, etc.

2. Formas de gestin del sistema.

3. Riesgo asumido con cada alternativa.

VENTAJAS

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.

Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.

El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto.

El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto y si se aplicaadecuadamente debe reducir los riesgos antes de que seconviertan en problemas

DESVENTAJAS

Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es controlable.

Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas.

Genera mucho tiempo en el desarrollo de sistemas.

3.3 . MODELO INCREMENTAL

El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.

Al igual que los otros mtodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

El Modelo Incremental es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos.

Ventajas:

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.

Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.

El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento.

Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada.

Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.

Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico.

Desventajas:

El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos.

Requiere de mucha planeacin, tanto administrativa como tcnica.

Requiere de metas claras para conocer el estado del proyecto.

3.4. MODELO EVOLUTIVO

El modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandesversiones sucesivas de un producto. El modelo evolutivo asume que, los requerimientos son cuidadosamente examinados, y slo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin parcial del sistema que recibe slo estos requerimientos.El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es actualizada, y una segunda versin el producto es desarrollada y desplegada. El proceso se repite indefinidamenteDesventajas

El proceso no es visible. Se tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rpidamente es muy costoso producir documentos que reflejen cada versin

Los sistemas tienen una estructura deficiente, tendiendo a daar la estructura del software

Se requieren tcnicas y herramientas especiales, permiten un desarrollo rpido pero suelen ser incompatibles con otras herramientas o tcnicas

3.5. MODELO CONCURRENTE

Es un modelo de tipo de red donde todas las personas actan simultneamente o al mismo tiempo. Por ejemplo, el personal est escribiendo requisitos diseando, codificando, haciendo pruebas y probando la integracin (todo al mismo tiempo). El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades tcnicas importantes, tareas y estados asociados a ellas.

Orientada a integrar sistemticamente y en forma simultnea el diseo de productos y procesos, para que sean considerados desde un principio todos los elementos del ciclo de vida de un producto, desde la concepcin inicial hasta su disposicin final. Debe otorgar adems una organizacin flexible y bien estructurada, proponer redes de funciones apoyadas por tecnologas apropiadas y arquitecturas comunes de referencia (ej: computadores en red y en bases de datos).

Los objetivos globales que se persiguen con la implementacin de la IC son:

1. Acortar los tiempos de desarrollo de los productos.

2. Elevar la productividad.

3. Aumentar la flexibilidad.

4. Mejor utilizacin de los recursos.

5. Productos de alta calidad.

6. Reduccin en los costos de desarrollo de los productos.

VentajasExcelente para proyectos en los que se conforman grupos de trabajo independientes.Proporciona una imagen exacta del estado actual de un proyecto.

DesventajasSi no se dan las condiciones sealadas no es aplicable.Si no existen grupos de trabajo no se puede trabajar en este mtodo4. METODOLOGASConjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software

Tarea: actividades elementales en que se dividen los procesos

Procedimiento: definicin de la forma e ejecutar la tarea

Tcnica: herramienta utilizada para aplicar un procedimiento

Herramienta: para realizar una tcnica, podemos apoyarnos en las herramientas software que automatizan sus aplicacin.

Producto: resultado de cada etapa.

METODOLOGA VS CICLO DE VIDA

Una metodologa puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica qu es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cmo hacerlo.

La metodologa indica cmo hay que obtener los distintos productos parciales y finalesCARACTERSTICAS DE UNA METODOLOGA

Existencia de reglas predefinidasCobertura total del ciclo de desarrolloVerificaciones intermediasPlanificacin y controlComunicacin efectivaUtilizacin sobre un abanico amplio de proyectosFcil formacinHerramientas CASEActividades que mejoren el proceso de desarrolloSoporte al mantenimientoSoporte de la reutilizacin de softwareMETODOLOGA CMMI: El modelo CMMI proporciona un marco para la mejora de procesos que pueden ayudar a una organizacin en la mejora de sus procesos y su habilidad para desarrollar, adquirir y mantener sus productos y servicios.

El uso de estas metodologas ofrece a las Organizaciones un instrumento til para la sistematizacin de las actividades que dan soporte al Ciclo de Vida del Software, estableciendo unas pautas de trabajo que permiten alcanzar los siguientes objetivos:

Proporcionar o disear Sistemas de Informacin que ayuden a conseguir los fines de la Organizacin mediante la definicin de un marco estratgico para el desarrollo de los mismos.

Dotar a la Organizacin de Productos Software que satisfagan las necesidades de los usuarios dando una mayor importancia al Anlisis de Requisitos.

Facilitar la comunicacin y entendimiento entre los distintos participantes en la produccin de software a lo largo del Ciclo de Vida del Proyecto, teniendo en cuenta su papel y responsabilidad, as como las necesidades de todos y cada uno de ellos.

Se contempla el desarrollo de Sistemas de Informacin para las distintas tecnologas que actualmente estn conviviendo y los aspectos de Gestin de Proyectos que aseguran el cumplimiento de sus objetivos en trminos de calidad, coste y plazosSoluciones:

Compromiso asegurado

Automatizar lo ms posible las actividades de control y gestin de los procesos de los proyectos

Comenzar a documentar los procesos implcitos, en la medida de lo posible o plantillas en office, implementacin de sistemas de gestin

Utilizacin de sistemas libres para minimizar los costos de implementacin

Problemtica:

Requiere mucho esfuerzo, compromiso de toda la organizacin

Comenzar a disear y/o documentar procesos, luego desplegarlos y ponerlos en prctica

Requiere un mnimo de cantidad de personal (no menos de 10 personas en la prctica)

Fuerte inversin econmica

METODOLOGIA ISO: Las series de ISO 9000 son un grupo de 5 individuales, pero relacionadas, estndares internacionales de administracin de la calidad y aseguramiento de calidad.

ISO 9001:2000 sistemas de Gestin Requisitos

ISO 9004:2000 Sistemas de Gestin de la Calidad Gua de mejoras del funcionamiento

ISO 9001:2000 es la norma que contiene los requisitos que debe cumplir una organizacin para la implementacin de un Sistema de Gestin.

ISO 9000-3: dedicada al proceso de desarrollo con calidad del software. Gua para la aplicacin para el desarrollo, implementacin y mantenimiento de software.

Beneficios de la Norma:

Mejor documentacin de los sistemas

Cambio cultural positivo

Incremento en la eficiencia y productividad

Mayor percepcin de calidad

Se ampla la satisfaccin del cliente

Se reducen las auditoras de calidad de los clientes

Agiliza el tiempo de desarrollo de un sistema.

ISO 12207

Esta norma esta orientada a los procesos de ciclo de vida del software de la organizacin ISO.

Establece un proceso de ciclo de vida para el software que incluye procesos y actividades que se aplican desde la definicin de requisitos, pasando por la adquisicin y configuracin de los servicios del sistema, hasta la finalizacin de su uso.

METODOLOGIA SCRUM: Esta metodologa se basa en una filosofa del desarrollo gil de software. Lo interesante es que si un integrante del equipo se cae se viene abajo todo el equipo as que deben de estar coordinados para que todos vayan a la misma velocidad.

Esta metodologa est basada entre muchas bajo estas premisas:

a) Los individuos por encima de los procesos y herramientas

b) En entregar soluciones por encima de reportes de seguimiento.

c) A dar respuesta a los cambios en lugar de ceirse a seguir un plan

Debe de haber una cohesin de equipo fuerte, porque el triunfo de un hito no es el triunfo de un solo jugador sino de todo el equipo, l mismo entrega el resultado. Todos colaboramos para obtener el triunfo y empujamos al que no est caminando como se debe.

Se centra en presentar al cliente la solucin que l pueda operar y usar, no solamente en entregar un reporte de lo que se ha hecho, de esta forma el cliente ve el progreso y puede decir cuando o no parar. Esto es una fortaleza ya que la mayora est acostumbrada a un plan y el resultado lo ve al final del proyecto.

Con la metodologa SCRUM el cliente va viendo el resultado del producto y decide si sigue o termina el producto en ese momento. O inclusive tan radical como se escucha darle un giro completo.El Estudiante Dice y Hace:

1. El estudiante Investigar informacin sobre la certificacin CMM, organizaciones de software con certificacin CMM. Tamao, Tiempo requerido para lograr la certificacin y costo2. El estudiante elaborara un cuadro comparativo de los modelos de ciclo de vida del software indicando (concepto, ventajas, desventajas y proyectos a utilizar.El Formador Dice y Hace:

TCNICAS DE RECOLECCION DE DATOSLa solucin de un problema complejo, normalmente implica satisfacer las necesidades de diversos grupos de inters. Estos grupos pueden ser divididos en clientes y usuarios: Un cliente es una persona que tiene influencia sobre los requerimientos del sistema aunque no vaya a ser un usuario del mismo, mientras que los usuarios son las personas o grupos de personas que van a interactuar directamente con el sistema.

Entender las necesidades de clientes y usuarios es una parte fundamental de un proyecto. Para entender las necesidades de estas personas hay que empezar por identificarlos. Algunas preguntas que podemos hacer para ayudarnos en esta labor son:Cules sern los diferentes roles organizacionales que usaran el sistema?

Quin va a pagar por el sistema?

Qu otra persona se ver afectada por las salidas que el sistema produce?

Quin es responsable de evaluar y aceptar el sistema cuando se libere?

Quin ser responsable de darle mantenimiento al sistema?Una vez que hemos identificado a los clientes y usuarios podemos aplicar varias tcnicas para identificar cules son sus necesidades. La siguiente seccin describe esas tcnicas y algunas herramientas que ayudan a entender cules son las necesidades de los usuarios respecto al sistema que se va a construir.

INTROSPECCIN:

La introspeccin es el medio ms obvio y comnmente usado para entender los requerimientos de un sistema. Consiste en estudiar el ambiente del usuario para posteriormente tratar de imaginar qu es lo que me gustara que hiciera el sistema si yo estuviera a cargo de hacer el trabajo con su ayuda.

Esta tcnica es til pero hay que considerar que la experiencia de un analista de sistemas es muy diferente que la experiencia de los usuarios potenciales del software y por lo tanto es difcil que las conclusiones del analista reflejen la experiencia de las personas que hacen la tarea da con da.

Esto se hace ms evidente en el diseo de la interfaz grfica del usuario, lo que para un analista es el comportamiento comn de un software, puede resultar confuso o frustrante para un usuario. Tradicionalmente, debido a las limitaciones grficas que anteriormente tenan las computadoras, se creaba una brecha entre el diseo de la aplicacin y las necesidades de uso del usuario, sin embargo debido a la evolucin de los ambientes grficos el paradigma est cambiando: La obligacin del usuario no es aprender a dominar una tecnologa, es la tecnologa la que debe ayudar al usuario a hacer su trabajo. La explosin del Internet ha creado nuevas especialidades como user experience en las cuales la psicologa y la sociologa son las principales herramientas cientficas.

La recomendacin, cuando se usa la introspeccin, es apoyarla con la informacin previa que generan otras tcnicas como por ejemplo la entrevista abierta. En cualquier caso es recomendable validar cualquier duda con un experto de dominio. Los expertos de dominio son personas con mucha experiencia en un rea particular del negocio que es de inters para el sistema. Por ejemplo, en el caso de una lnea de produccin, el operador de alguna mquina de la lnea puede ser un experto de dominio que aporte valiosa informacin para la automatizacin del proceso.ENTREVISTA ABIERTA

Con los objetivos en mente, se saca la lista de datos que quiero conseguir y que fuentes son las mas adecuadas para proporcionrmelos. Segn lo anterior decido que instrumento me conviene.

Una de las principales consideraciones a tomar en cuenta en una entrevista es lograr que la predisposicin del entrevistador no influya en el resultado de la narrativa capturada. Como proveedores de soluciones, estamos acostumbrados a identificar soluciones al mismo tiempo que escuchamos problemas, cuando hacemos esto, tendemos a influenciar las respuestas del entrevistado, provocando una mala comprensin del problema o una reduccin en el grado de libertad de la solucin.

Una entrevista debe considerar preguntas libres de contexto (Gausse and Weinberg, 1989), es decir, preguntas que no influencien las respuestas de los entrevistados hacia las respuestas que queremos or. Por ejemplo:

Quines son los usuarios del sistema?

Qu problemas tienen actualmente?

Cules son sus necesidades respecto a la solucin?Algunos consejos que pueden ayudarnos durante una entrevista:

No hagas preguntas donde se suponga de antemano que la gente puede describir actividades complejas. En general la gente puede hacer muchas cosas que no puede describir. Cuando necesites entender una actividad compleja separa la pregunta en varias partes o utiliza otra tcnica como la investigacin de campo.

Haz preguntas abiertas que le permitan al usuario extenderse en sus respuestas y a ti comprender mejor su problemtica.

No hagas preguntas que influencien la respuesta del entrevistado: Usted necesita una pantalla para realizar esta tarea, verdad?

No hagas preguntas para controlar la conversacin: Podemos regresar a la pregunta anterior?

No hagas preguntas que se respondan as mismas: 50 elementos en esta lista son suficientes, verdad?

Evita preguntas que empiecen con Por qu?. Habitualmente estas preguntas ponen al entrevistado a la defensiva porque aparentan cuestionar la manera en que hace su trabajo.

No esperes respuestas sencillas. Cuando las obtengas sigue preguntando para descubrir ms ruinas enterradas.

No apures al entrevistado para que responda. Si haces esto probablemente no querr responder tu prxima pregunta.

Por ltimo lo ms importante: Escucha con atencin.CUESTIONARIOConsisten en una serie de preguntas que el entrevistador hace de manera secuencial o que se entregan al entrevistado para que l mismo conteste.

Los cuestionarios tienen la deficiencia de que no utilizan los elementos de interaccin de la entrevista, por lo tanto se corre el riesgo de que, dado que la persona a la que se entrevista tiene diferente historia y por lo tanto diferentes conocimientos y categoras para clasificar los conceptos, algunas preguntas se malinterpreten o resulten irrelevantes y fuera de contexto.GRUPOS DE DISCUCIN

Para tener una visin general y rpida de lo que un grupo de personas piensa, puede usar un grupo de discusin. En estos grupos, a manera de pltica informal un moderador hace la entrevista para encontrar la informacin deseada.Consiste en involucrar a los usuarios en el proceso de desarrollo mediante talleres o workshops en los cuales se identifican los requerimientos. En los talleres pueden utilizarse diferentes tcnicas para ir descubriendo requerimientos como "Casos de Uso", "Story Boards", "Modelos" o "Prototipos".

Los grupos de desarrollo tienen el inconveniente de que no son comunidades naturales, por lo tanto es difcil que los participantes compartan categoras. Otro riesgo en estos talleres es que, dadas las jerarquas que existen dentro de una empresa, alguno de los participantes puede no sentirse libre para expresar su opinin o puede sentirse obligado a dar una opinin sobre un punto que desconoce o en el que l no es experto.Algunas recomendaciones para conducir un grupo de desarrollo son:

Da a todos la oportunidad de hablar. Esto es esencial para que el workshop se considere imparcial.

Procura que la sesin se mantenga andando. Existe una tendencia natural a que el workshop se convierta en una sesin de quejas. Identifica los problemas/requerimientos pero no profundices. Una vez que se ha identificado un problema/requerimiento avanza al siguiente.

Permanece alerta para recoger informacin y hallazgos.

Al final, resume la sesin y trabaja en generar conclusionesTORMENTA DE IDEAS

La Tormenta de Ideas consiste en listar todas las ideas sobre un tema que se le ocurren a un auditorio determinado y posteriormente filtrarlas, desarrollarlas y priorizarlas.

Una sesin de este tipo comienza con la aclaracin del objetivo. El objetivo es muy importante porque permite mantener en foco la sesin, sin embargo no debe de ser limitante para la creatividad de las ideas expresadas, es ms las ideas ms descabelladas pueden resultar en soluciones innovadoras. Los participantes deben de aportar ideas sin interrupcin y tantas como sea posible, para lograr esto, el moderador debe crear un ambiente en el que la creatividad y la apertura de mente tengan un lugar prioritario, por ejemplo evitando crticas o debates durante la aportacin de ideas.

Cuando las ideas comienzan a repetirse y los participantes empiezan a demorarse mucho tiempo entre idea e idea, es momento de suspender la sesin y pasar a filtrar, combinar, ordenar y priorizar las ideas. Al hacer esto, es necesaria la participacin del grupo mediante debates y consensos. El moderador debe de evitar que la discusin se vuelva personal o que los debates se prolonguen demasiado, esto puede lograrse usando rondas de votacin con prioridades, en las cuales a los miembros se les da una cantidad de puntos que deben distribuir entre las diferentes opciones, nunca asignado ms del 50% de sus puntos a una opcin. Al final se suman los puntos y la opcin con ms puntos resulta ganadora.

ENTREVISTA:

Es una serie de preguntas que puede realizarse personalmente, por telfono, correo o por correo electrnico. Segn su diseo estas pueden ser:

Estructurada: es un cuestionario con preguntas que requieren seleccin de una sola respuesta.

Semi-estructurada: contiene preguntas de seleccin y preguntas abiertas.

OBSERVACIN

A veces UD preferir observar la conducta de personas, objetos y sucesos o algn fenmeno de inters, en forma directa.

La observacin puede hacerse de la siguiente manera:

Estructurada: se especifica previamente lo que se va a observar y como se va a registrar la observacin

No estructurada: El observador anota todos los aspectos que le parezcan importantes es ms exploratoria.El Formador Dice y el estudiante Hace:

FICHA PARA ENTREVISTASInformacin del Proyecto

Proyecto:NOMBRE DEL PROYECTO

Entrevistador(es):NOMBRE DE LA PERSONA(S)

Entrevistado(s):NOMBRE DE LA PERSONA(S)

Fecha de la Entrevista:FECHA

Lugar de la Entrevista:LUGAR

Documentos Relacionados:Propuesta del Proyecto > Pblico objetivo y beneficiosGlosario de trminos

TAREAS: Copie este archivo por cada entrevista hecha. COmplete los detalles. Haga una liga de este archivo a la seccin de "Notas de Entrevistas y Lluvias de Ideas" de user-needs.html.

Impacto del proceso: La planeacin de preguntas para las entrevistas con inversionistas es la clave para un levantamiento de datos efectivo. Los buenos requerimientos son necesarios para construir el sistema correctamente. Estas notas debern ser guardadas como parte de la documentacin en requerimientos del usuario para ser referenciadas cuando la especificacin de requerimientos de software sea redactada o actualizada.

Preguntas y Respuestas de la Entrevista

TAREAS: Antes de la entrevista, planee las preguntar que va a hacer. Despus, escriba las respuestas que recibi y cualquier otra pregunta o respuesta adicional que pueda surgir.

Cmo se dio cuenta de la necesidad de este producto?

RESPUESTA

Qu tipos de usuarios podran utilizar este producto?

RESPUESTA

Podra dar un ejemplo de cmo un usuario podra utilizar el producto?

RESPUESTA

Existe algn riesgo por utilizar este producto?

RESPUESTA

PREGUNTA1

RESPUESTA1

PREGUNTA2

RESPUESTA2

PREGUNTA3

RESPUESTA3

PREGUNTA4

RESPUESTA4

Otras Notas de la Entrevista

TAREAS: Anote todo lo dems que haya surgido de la entrevista, ya sea explcita o implcitamente. Recuerde confirmar los datos que recab implcitamente si tuviera dudas sobre ellos. Por ejemplo, tome notas de que el entrevista utiliza un significado poco usual para cierto trmino. Aada ligas a cualquier documento que le entregue el entrevistado.

NOTA

NOTA

NOTA

Lista de Pendientes de la Entrevista

Antes de la entrevista

1. Decida que objetivos desea cumplir

2. Prepare una lista de preguntas

Pregunte sobre las cosas que conoce y que desea conocer, basado en su entendimiento actual de los requerimientos

Mantenga las preguntas simples. No utilice preguntas con muchas partes, rompa los temas complejos en preguntas individuales.

Confirme las suposiciones ms importantes. Por ejemplo: "Ud. es la persona que utilizar este programa, cierto?" "El total necesita ser impreso y actualizado por cada elemento que se escanea, verdad?"

Evite sugerir o hacer preguntas de muchas partes, porque la respuesta correcta podra ser una que Ud. no conozca todava. Por ejemplo, INCORRECTO: "Ud. entrara al sistema desde su escritorio aqu o desde su casa?" CORRECTO: "Cules son algunos de los lugares de donde entrara al sistema?" "Desde aqu en mi oficina, pero tambin cuando trabajo con otras personas algunas veces me conecto desde las computadoras en sus oficinas o desde una computadora en el laboratorio o en la sala de juntas... as que no quisiera una cookie guardada aqu."

Trate de encontrar la prioridad para cada requerimiento: esencial, esperado, deseado u opcional.

Escriba ms preguntas abiertas para ver si nuevos requerimientos de importancia salen a la luz.

No haga muchas preguntas que parezcan fuera del tema., podra accidentalmente cambiar el enfoque o hacer especulaciones incorrectas. Por ejemplo, "Le gustara que el sistema hiciera tambin estas otras diez caractersticas?" "Claro!"

3. Seleccione a los entrevistados que representen a todos los inversionistas importantes.

4. Revise sus preguntas. Cree que pueden ser contestadas? Le ayudarn a alcanzar sus objetivos? Si no es as, redctelas de nuevo.

5. Decida si desea hacer esta entrevista va email, telfono o en persona

6. Programe una entrevista segn la conveniencia del entrevistado. Planee que la entrevista dure no ms de una hora.

Durante la entrevista

1. Sea atento, corts y profesional

2. Presntese Ud. mismo y explique por qu est Ud. ah.

3. ASegrese que est entrevistando a la persona que fue a entrevistar. Consiga su informacin de contacto (por ejemplo, su direccin de email) si an no la tiene.

4. Pida permiso para tomar notas. No grabe en cinta o video.

5. Confirme el tiempo disponible con el que cuentan Ud. y el entrevistado para esta sesin.

6. D una indicacin rpida del tipo y nmero de preguntas que va a hacer

7. Haga todas las preguntas.

8. Escuche. Es para eso que esta Ud. ah.

9. Si el entrevistado se refiere a documentos existente, sistemas, equipo o personas, asegrese de entender de el o ella est hablando. Si es importante, pregunte si puede conseguir una copia o una pantalla (pero no solicite nada que pueda ser confidencial), o tome nota de los aspectos importantes de los elementos a los que se refiere. Apunte las URLs de cualquier sitio web pblico existente que salga en la entrevista.

10. Intente no responder las preguntas Ud. mismo, o reaccionar a las solicitudes del entrevistado haciendo promesas de resolver sus problemas. La entrevistas son para entender los problemas, no para resolverlos o programar fechas de entrega.

11. Anote los elementos de los puede obtener ms informacin ms tarde. Por ejemplo, si el entrevistado empieza a explicarle con detalle algo que Ud. sabe que puede aprender por su cuenta, o si el entrevistado no conoce la respuesta y empieza a especular, debera intentar seguir con la siguiente pregunta.

12. Si se da cuenta que ha preparado mal las preguntas, concntrese en obtener informacin que le ayudar a preparar las siguientes preguntas correctamente.

13. Termine puntualmente. Si necesita ms tiempo contine via email o en una reunin posterior.

14. Resuma los elementos de accin que investigar ms tarde

15. Pregunte si el entrevistado tiene preguntas para Ud., o si hay algo ms que desea que Ud. le pregunte.

16. Asegrese de dejar sus datos de contacto

17. Agradezca al entrevistado por su tiempo

Despus de la entrevista

1. En las primeras 24 horas, lea sus notas y complete los detalle importantes que fueron mencionados pero que no anot

2. Capture sus notas para que las pueda compartir con su equipo y archivadas

3. Formule cualquier pregunta importante que desee hacer despus

4. Dentro de 2 o 3 das despus, enve un mensaje por email para

Agradecer al entrevistado de nuevo

Confirmar que tiene la direccin de correo correcta, y facilitar a sus entrevistados la comunicacin con Ud.

Pregunte cualquier pregunta que tenga an El Estudiante Dice y Hace:

1. El estudiante deber entrevistarse con su cliente y desarrollar la ficha anterior, realizar como mnimo 3 entrevistas2. El estudiante realizara un informe indicando que tipos de recoleccin de datos realiz y mostrando los resultados de cada uno.El Formador Dice y Hace:

ESPECIFICACION DE REQUERIMIENTOSEl correcto manejo de los requerimientos es un factor del que depende el xito del proyecto.Un requerimiento es una condicin o capacidad que el sistema debe cumplirDe forma ms refinada Una capacidad del sistema requerida por el usuario para resolver un problema o alcanzar un objetivo Capacidad que el sistema debe poseer o brindar a fin de satisfacer un contrato, especificacin, estndar o alguna otra documentacin formalmente impuestaDe manera formal, los requerimientos se documentan en el Documento de Especificacin de Requerimientos (SRS), (Software Requirements Specification)El SRS sirve como contrato entre desarrolladores y cliente.Existe una serie de atributos que debe tener una especificacin de software:

Claridad/Carencia de ambigedad: Cada uno de los requerimientos tiene una sola interpretacin posible.

Completa: Todo lo que el software debe hacer est incluido en las especificaciones. Las respuestas a cualquier tipo de datos de entrada en cualquier situacin posible estn incluidas en las especificaciones.

Correcta: Cada uno de los requerimientos representa algo que el sistema requiere.

Entendible: Cualquier tipo de lector puede, fcilmente, comprender el significado de todos los requerimientos con una explicacin mnima

Verificable: Existe alguna tcnica finita y costeable que puede ser usada para verificar que cada uno de los requerimientos especificados est incluido en el sistema terminado.

Consistente: No existen conflictos entre requerimientos.

Factible: Existe por lo menos un diseo y una implementacin que satisfacen todos los requerimientos especificados.

Rastreable: Est escrita de manera que facilita la referencia de cada requerimiento individual. El origen de cada requerimiento est claro.

Concisa: Es lo ms corta posible, sin afectar otras cualidades de la especificacin.

Diseo Independiente: Existe ms de un diseo e implementacin que satisface correctamente todos los requerimientos del sistema.

Modificable: Tiene una estructura y estilo que permiten hacer cambios de una manera fcil, completa y consistente.

No redundante: Los requerimientos no estn repetidos

Precisa: Se usan cantidades numricas cuando es posible con el apropiado nivel de precisin.En general los siguientes pero se sugiere seleccionar una plantilla del estndar de la IEEE1. Enunciado resumen del proyectoPor ejemplo:. El propsito de este proyecto es crear una terminal de ventas a ser utilizada en tiendas supermercado2. Cliente o Clientes:Por ejemplo: Tiendas Ramrez y Asociados.

3. Requerimientos funcionales del sistema: lo que se supone debe hacer el sistema, como:El sistema debe autorizar crditos OBLIGATORIOIMPORTANTE: Los requerimientos funcionales pueden capturarse en forma de lista o por medio de casos de uso (siguiente tema).Funcionales: Qu va a hacer el sistema Interfaces externas, cmo interacta el sistema con el hardware, personas, y otros sistemasDesempeo: Velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperacin, etc.Atributos: Portabilidad, mantenimiento, seguridad, etc.4. Otros requerimientos Participantes Grupos afectados Acepciones Riesgos GlosarioLimitaciones: estndares, lenguaje de implementacin, polticas de integridad de la base de datos, lmite de recursos, sistemas operativos, etc.

Correcto Los requerimientos reflejan una necesidad real Cada requerimiento es uno que el software deber implementarNo ambiguo Una sola interpretacin No usar ms de una palabra para un mismo trmino (pedido u orden, por ejemplo) Glosario si es necesario PERSONAL

Sin duda el elemento ms valioso en el desarrollo de proyectosQuines participan en un proyecto de software?

Programadores Lder de proyecto

Arquitectos de software Usuarios

Analistas/Diseadores Clientes

Ingenieros de requerimientos

Ingenieros de proceso

Ingenieros de pruebasCules son las caractersticas deseables de un lder de proyecto?

Motivador

Organizado

InnovadorSolucionador de Problemas

Cmo se organiza el equipo de trabajo?

Centralizado Controlado (CC): El jefe del equipo se encarga de la resolucin de problemas a alto nivel y la coordinacin interna del equipo. La comunicacin entre el jefe y los miembros del equipo es vertical.

Descentralizado Controlado (DC): Un jefe definido que coordina tareas especficas y jefes secundarios con responsabilidades sobre subtareas. La resolucin de problemas es una actividad del grupo, la comunicacin es horizontal y vertical.Descentralizado Democrtico (DD) o Egoless: No tiene un jefe permanente, se nombran de acuerdo a la tarea. La solucin de problemas se hace por consenso. La comunicacin es horizontal.Qu factores se deben considerar cuando se estructura un equipo de software?

Complejidad del proyecto (dificultad del problema, tamao del software)

Tiempo de desarrollo.

Modularidad.

Calidad.Comunicacin requerida.

Discusin sobre ventajas y desventajas de cada tipo de organizacin.Cmo creamos un equipo de alto rendimiento?

Confianza entre los miembros del equipo.

Distribucin de habilidades de acuerdo al problema.Los inconformistas deben ser excluidos.

Qu factores pueden contaminar el desempeo de un equipo?

Atmsfera de trabajo frentica, malgastan energa y se descentran de los objetivos

Alta frustracin causada por factores tecnolgicos, del negocio o personales que provocan friccin entre los miembros del equipo.

Procedimientos coordinados pobremente o fragmentados o una definicin pobre o impropiamente elegida del modelo de procesos que se convierte en un obstculo a saltar.

Definicin confusa de los papeles a desempear produciendo una falta de responsabilidad y la acusacin correspondiente.

Continua y repetida exposicin al fallo que conduce a una prdida de confianza y una cada de la moral.RIESGOSEl riesgo siempre implica dos caractersticas:

Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de probabilidad. Prdida: Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o prdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de prdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categoras de riesgos

Los riesgos del proyecto amenazan al plan del proyecto. Es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificacin temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificacin temporal, personal (asignacin y organizacin), recursos. cliente y requisitos y su impacto en un proyecto de software.

Los riesgos tcnicos amenazan la calidad y la planificacin temporal del software que hay que producir. Si un riesgo tcnico se convierte en realidad, la implementacin puede llegar a ser difcil o imposible. Los riesgos tcnicos identifican problemas potenciales de diseo, implementacin, de interfaz. verificacin y de mantenimiento. Adems. las ambigedades de especificaciones, incertidumbre tcnica, tcnicas anticuadas y las "tecnologas punta" son tambin factores de riesgo. Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo que pensbamos.

Los riesgos del negocio amenazan la viabilidad del software a construir Los riesgos del negocio a menudo ponen en peligro ei proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son:

1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado),

2. Construir un producto que no encaja en la estrategia comercial general de la compaa (riesgo estratgico),

3. Construir un producto que ei departamento de ventas no sabe cmo vender

4. Perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios de personal (riesgo de direccin)

4. Perder presupuesto o personal asignado (riesgos de presupuesto).

5. Es extremadamente importante recalcar que no siempre funciona una categorizacin tan sencilla. Algunos riesgos son simplemente imposibles de predecir. Otra categorizacin general de los riesgos ha sido propuesta por Charette. Los riesgos conocidos son todos aquellos que se pueden descubrir despus de una cuidadosa evaluacin del plan del proyecto. del entorno tcnico y comercial en el que se desarrolla el proyecto y otras fuentes de informacin fables (p. ej.: fechas de entrega poco realistas. falta de especificacin de requisitos o de mbito del software. o un entorno pobre de desarrollo), los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (ej.: cambio de personal, mala comunicacin con el cliente. disminucin del esfuerzo del personal a medida que atienden peticiones de mantenimiento). Pueden ocurrir pero son extremadamente difciles de identificar por adelantado.El Formador Dice y el estudiante Hace:

EJEMPLO DOCUMENTO ESPECIFICACION DE REQUERIMIENTOS

Especificacin de Requerimientos de Software (SRS)

Informacin de la versin

Proyecto:

NOMBREDELPROYECTO

Nmero Interno de Versin:X.Y.Z

Formas Anexas:SRS > Conjunto de casos de usoSRS > Conjunto de caractersticas

Documentos Relacionados:Propuesta de proyectoConjunto de caractersticasLIGAS A OTROS ESTNDARES RELEVANTES

LIGAS A OTROS DOCUMENTOS

Impacto del proceso: Especificacin de Requerimientos de Software (SRS) define de forma precisa el producto de software que se va a construir. Las decisiones hechas escribiendo la SRS estn basados en informacin de los documentos de la propuesta del proyecto y requerimientos del usuario. El conjunto de requerimientos de SRS deben ser satisfechos en el diseo del sistema. La SRS es verificada y validada por la actividades marcadas en el plan de QA.

Introduccin

TAREAS: Proveer un breve resumen de esta entrega del producto. Puede copiar el texto de la propuesta del proyecto, pegarla aqu, y resumirlo.

PRRAFO

PRRAFO

Para ms informacin, vea la propuesta del proyecto.

Casos de Uso

RESUMEN DE UN PRRAFO

Detalles:

Los actores son descritos en el documento de requerimientos del usuario.

El conjunto de casos de uso use case suite enumera los casos de uso en una forma organizada.

Requerimientos Funcionales

RESUMEN DE UN PRRAFO

Detalles:

El conjunto de caractersticas enumera todas las caractersticas en una forma organizada.

Requerimientos No-Funcionales

TAREAS: Describa los requerimientos no funcionales para esta entrega. Abajo se pueden ver algunos ejemplos.

Cules son los requerimientos de usabilidad?

Nuestro principal criterio para hacer el sistema usable es la dificultad de realizar cada caso de uso de alta frecuencia. La dificultad depende de el nmero de pasos, el conocimiento que el usuario debe tener en cada paso, las decisiones que el usuario debe realizar en cada paso, y la mecnica de cada paso (por ejemplo, escribir el ttulo de un libro de forma exacta es difcil, hacer click en una lista es fcil).

La interfaz del usuario deber ser tan familiar como sea posible a los usuarios que han usado otras aplicaciones web y aplicaciones de escritorio en Windows. Por ejemplo, seguiremos las guas de la UI para nombrar los menus, botones y las cajas de dilogo siempre que sea posible.

Cul es la confiabilidad y los requerimientos de ltimo minuto?

PRRAFO

PRRAFO

Detalles:

DETALLE

DETALLE

DETALLE

Cules son los requerimientos de precaucin?

PRRAFO

PRRAFO

Detalles:

DETALLE

DETALLE

DETALLE

Cules son los requerimientos de seguridad?

El acceso ser controlado con nombres de usuario y contraseas.

Solo los usuarios con derechos de administrador podrn accesar las funciones administrativas, los usuarios normales no podrn.

Detalles:

Las contraseas debern tener de 4 a 14 caracteres de longitud

No utilizaremos comunicaciones encriptadas (SSL) para este sitio

DETALLE

Cules son los requerimientos de desempeo y escalabilidad?

PRRAFO

PRRAFO

Detalles:

DETALLE

DETALLE

DETALLE

Cules son los requerimientos de mantenimiento y actualizacin?

La capacidad de mantenimiento es nuestra habilidad para realizar cambios al producto en el tiempo. Necesitamos una capacidad de mantenimiento fuerte para retener a nuestros primeros clientes. Resolveremos esto anticipando varios tipos de cambios y documentando cuidadosamente nuestro diseo y nuestra implementacin.

La capacidad de actualizacin es nuestra habilidad para entregar nuevas versiones del producto a bajo costo a los clientes con un mnimo de tiempo de descarga o disrupcin. Una caracterstica clave para apoyar este objetivo es la descarga automtica de parches o actualizaciones y actualizaciones del equipo del usuario final. Tambin debemos utilizar formatos para archivos de datos que incluyan suficientes meta-datos para permitirnos trasformar con seguridad la informacin existente del usuario durante una actualizacin.

Detalles:

DETALLE

DETALLE

DETALLE

Cules son los requerimientos de soportabilidad y operabilidad?

La soportabilidad es nuestra habilidad de proveer soporte tcnico eficiente y a buen precio. Nuestro objetivo es limitar nuestros costos de soporte a solo 5% de las tarifas de licenciamiento anual. Las caractersticas de actualizacin automtica del producto no ayudar a entregar fcilmente parches a los usuarios finales. La gua del usuario y el sitio web del producto incluyen una gua de resolucin de problemas y una lista de informacin que debe tener a la mano antes de contactar a soporte tcnico.

La operabilidad es nuestra habilidad de hospedar y operar el software como un ASP (Proveedor de Servicios de Aplicaciones). Las caractersticas del producto debern ayudarnos a alcanzar nuestros objetivos de 99.9% en lnea (con 43 minutos mximo fuera de lnea por mes). Las caractersticas principales que soporten esto son la capacidad de crear respaldos de datos en tiempo de operacin, y el monitoreo de la aplicacin.

Cules son los requerimientos del ciclo de vida del negocio?

El ciclo de vida del negocio de un producto incluye todo lo que le pasa a ese producto sobre un periodo de varios aos, desde la decisin inicial de compra, a travs de importantes pero poco frecuentes casos de uso, hasta el retiro del producto. Los requerimientos principales de del ciclo de vida son listados abajo.

Detalles:

Los clientes debern se capaces de manejar el nmero de licencias con el que ya cuentan y de hacer decisiones informadas sobre las compras de ms licencias cuando sea necesario

el producto deber soportar operacin diaria y nuestra auditora de fin de ao

La informacin del cliente deber ser almacenada en un formato que sea accesible incluso despus de que la aplicacin sea retirada.

Requerimientos Ambientales

TAREAS: Describa los requerimientos ambientales para esta entrega. Los requerimientos ambientales describen el sistema ms grande hardware, software, y los data con el que este producto debe trabajar. Se proveen algunos ejemplos ms abajo.

Cules son los requerimientos de hardware del sistema?

PRRAFO

PRRAFO

Detalles:

DETALLE

DETALLE

Cules son los requerimientos de software del sistema?

PRRAFO

PRRAFO

Detalles:

DETALLE

DETALLE

Qu Interfaces de Aplicacin del Programa (APIs) deben incluirse?

PRRAFO

PRRAFO

Detalles:

Debemos implementar esta API estndar.

DETALLE

DETALLE

Cules son los requerimientos de importacin y exportacin de datos?

PRRAFO

PRRAFO

Detalles:

El sistema deber almacenar todos los datos en una base de datos SQL estndar, donde pueda ser accesado por otros programas.

El sistema podr almacenar todos los datos en un archivo XML, usando una DTD estndar.

El sistema deber leer y escribir archivos .XYZ vlidos para ser usados por OTRA APLICACIN

FORMATO IEEE830 REQUERIMIENTOS

Especificacin de requisitos de software

Proyecto: MACROBUTTON NOMACRO [Nombre del proyecto]Revisin MACROBUTTON NOMACRO [99.99]

MACROBUTTON NOMACRO [Mes de ao]

Instrucciones para el uso de este formato

Este formato es una plantilla tipo para documentos de requisitos del software.

Est basado y es conforme con el estndar IEEE Std 830-1998.

Las secciones que no se consideren aplicables al sistema descrito podrn de forma justificada indicarse como no aplicables (NA).

Notas:

Los textos en color azul son indicaciones que deben eliminarse y, en su caso, sustituirse por los contenidos descritos en cada apartado.

Los textos entre corchetes del tipo MACROBUTTON NoMacro [Inserte aqu el texto] permiten la inclusin directa de texto con el color y estilo adecuado a la seccin, al pulsar sobre ellos con el puntero del ratn.

Los ttulos y subttulos de cada apartado estn definidos como estilos de MS Word, de forma que su numeracin consecutiva se genera automticamente segn se trate de estilos Titulo1, Titulo2 y Titulo3.

La sangra de los textos dentro de cada apartado se genera automticamente al pulsar Intro al final de la lnea de ttulo. (Estilos Normal indentado1, Normal indentado 2 y Normal indentado 3).

El ndice del documento es una tabla de contenido que MS Word actualiza tomando como criterio los ttulos del documento.

Una vez terminada su redaccin debe indicarse a Word que actualice todo su contenido para reflejar el contenido definitivo.

De la plantilla de formato del documento & Coloriuris http://www.qualitatis.org

Ficha del documento

FechaRevisinAutorVerificado dep. calidad.

MACROBUTTON NoMacro [Fecha]MACROBUTTON NoMacro [Rev]MACROBUTTON NoMacro [Descripcion]MACROBUTTON NoMacro [Firma o sello]

Documento validado por las partes en fecha: MACROBUTTON NoMacro [Fecha]Por el clientePor la empresa suministradora

Fdo. D./ Da MACROBUTTON NoMacro [Nombre]Fdo. D./Da MACROBUTTON NoMacro [Nombre]

Contenido

3Ficha del documento

4Contenido

61Introduccin

61.1Propsito

61.2Alcance

61.3Personal involucrado

61.4Definiciones, acrnimos y abreviaturas

61.5Referencias

61.6Resumen

72Descripcin general

72.1Perspectiva del producto

72.2Funcionalidad del producto

72.3Caractersticas de los usuarios

72.4Restricciones

72.5Suposiciones y dependencias

72.6Evolucin previsible del sistema

73Requisitos especficos

83.1Requisitos comunes de los interfaces

83.1.1Interfaces de usuario

83.1.2Interfaces de hardware

83.1.3Interfaces de software

83.1.4Interfaces de comunicacin

83.2Requisitos funcionales

93.2.1Requisito funcional 1

93.2.2Requisito funcional 2

93.2.3Requisito funcional 3

93.2.4Requisito funcional n

93.3Requisitos no funcionales

93.3.1Requisitos de rendimiento

93.3.2Seguridad

93.3.3Fiabilidad

93.3.4Disponibilidad

103.3.5Mantenibilidad

103.3.6Portabilidad

103.4Otros requisitos

104Apndices

Introduccin

MACROBUTTON NoMacro [Inserte aqu el texto]La introduccin de la Especificacin de requisitos de software (SRS) debe proporcionar una vista general de la SRS. Debe incluir el objetivo, el alcance, las definiciones y acrnimos, las referencias, y la vista general del SRS.

Propsito

MACROBUTTON NoMacro [Inserte aqu el texto] Propsito del documento

Audiencia a la que va dirigido

Alcance

MACROBUTTON NoMacro [Inserte aqu el texto] Identificacin del producto(s) a desarrollar mediante un nombre

Consistencia con definiciones similares de documentos de mayor nivel (ej. Descripcin del sistema) que puedan existir

Personal involucrado

NombreMACROBUTTON NoMacro [Inserte aqu el texto]

RolMACROBUTTON NoMacro [Inserte aqu el texto]

Categora profesionalMACROBUTTON NoMacro [Inserte aqu el texto]

ResponsabilidadesMACROBUTTON NoMacro [Inserte aqu el texto]

Informacin de contactoMACROBUTTON NoMacro [Inserte aqu el texto]

AprobacinMACROBUTTON NoMacro [Inserte aqu el texto]

Relacin de personas involucradas en el desarrollo del sistema, con informacin de contacto.

Esta informacin es til para que el gestor del proyecto pueda localizar a todos los participantes y recabar la informacin necesaria para la obtencin de requisitos, validaciones de seguimiento, etc.

Definiciones, acrnimos y abreviaturas

MACROBUTTON NoMacro [Inserte aqu el texto]Definicin de todos los trminos, abreviaturas y acrnimos necesarios para interpretar apropiadamente este documento. En ella se pueden indicar referencias a uno o ms apndices, o a otros documentos.

Referencias

ReferenciaTituloRutaFechaAutor

MACROBUTTON NoMacro [Ref.]MACROBUTTON NoMacro [Ttulo]MACROBUTTON NoMacro [Ruta]MACROBUTTON NoMacro [Fecha]MACROBUTTON NoMacro [Autor]

Relacin completa de todos los documentos relacionados en la especificacin de requisitos de software, identificando de cada documento el titulo, referencia (si procede), fecha y organizacin que lo proporciona.

Resumen

MACROBUTTON NoMacro [Inserte aqu el texto] Descripcin del contenido del resto del documento

Explicacin de la organizacin del documento

Descripcin general

Perspectiva del producto

MACROBUTTON NoMacro [Inserte aqu el texto]Indicar si es un producto independiente o parte de un sistema mayor. En el caso de tratarse de un producto que forma parte de un sistema mayor, un diagrama que site el producto dentro del sistema e identifique sus conexiones facilita la comprensin.

Funcionalidad del producto

MACROBUTTON NoMacro [Inserte aqu el texto]Resumen de las funcionalidades principales que el producto debe realizar, sin entrar en informacin de detalle.

En ocasiones la informacin de esta seccin puede tomarse de un documento de especificacin del sistema de mayor nivel (ej. Requisitos del sistema).

Las funcionalidades deben estar organizadas de manera que el cliente o cualquier interlocutor pueda entenderlo perfectamente. Para ello se pueden utilizar mtodos textuales o grficos.

Caractersticas de los usuarios

Tipo de usuarioMACROBUTTON NoMacro [Inserte aqu el texto]

FormacinMACROBUTTON NoMacro [Inserte aqu el texto]

HabilidadesMACROBUTTON NoMacro [Inserte aqu el texto]

ActividadesMACROBUTTON NoMacro [Inserte aqu el texto]

Descripcin de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia tcnica.

Restricciones

MACROBUTTON NoMacro [Inserte aqu el texto]Descripcin de aquellas limitaciones a tener en cuenta a la hora de disear y desarrollar el sistema, tales como el empleo de determinadas metodologas de desarrollo, lenguajes de programacin, normas particulares, restricciones de hardware, de sistema operativo etc.

Suposiciones y dependencias

MACROBUTTON NoMacro [Inserte aqu el texto]Descripcin de aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo una asuncin puede ser que determinado sistema operativo est disponible para el hardware requerido. De hecho, si el sistema operativo no estuviera disponible, la SRS debera modificarse.

Evolucin previsible del sistema

MACROBUTTON NoMacro [Inserte aqu el texto]Identificacin de futuras mejoras al sistema, que podrn analizarse e implementarse en un futuro.

Requisitos especficos

Esta es la seccin ms extensa y ms importante del documento.

Debe contener una lista detallada y completa de los requisitos que debe cumplir el sistema a desarrollar. El nivel de detalle de los requisitos debe ser el suficiente para que el equipo de desarrollo pueda disear un sistema que satisfaga los requisitos y los encargados de las pruebas puedan determinar si stos se satisfacen.

Los requisitos se dispondrn en forma de listas numeradas para su identificacin, seguimiento, trazabilidad y validacin (ej. RF 10, RF 10.1, RF 10.2,...).

Para cada requisito debe completarse la siguiente tabla:

Nmero de requisito MACROBUTTON

MACROBUTTON NoMacro [Inserte aqu el texto]

Nombre de requisitoMACROBUTTON NoMacro [Inserte aqu el texto]

Tipo FORMCHECKBOX Requisito FORMCHECKBOX Restriccin

Fuente del requisitoMACROBUTTON NoMacro [Inserte aqu el texto]

Prioridad del requisito FORMCHECKBOX Alta/Esencial FORMCHECKBOX Media/Deseado FORMCHECKBOX Baja/ Opcional

y realizar la descripcin del requisito

La distribucin de los prrafos que forman este punto puede diferir del propuesto en esta plantilla, si las caractersticas del sistema aconsejan otra distribucin para ofrecer mayor claridad en la exposicin.

Requisitos comunes de los interfaces

MACROBUTTON NoMacro [Inserte aqu el texto]Descripcin detallada de todas las entradas y salidas del sistema de software.

Interfaces de usuario

MACROBUTTON NoMacro [Inserte aqu el texto]Describir los requisitos del interfaz de usuario para el producto. Esto puede estar en la forma de descripciones del texto o pantallas del interfaz. Por ejemplo posiblemente el cliente ha especificado el estilo y los colores del producto. Describa exacto cmo el producto aparecer a su usuario previsto.

Interfaces de hardware

MACROBUTTON NoMacro [Inserte aqu el texto]Especificar las caractersticas lgicas para cada interfaz entre el producto y los componentes de hardware del sistema. Se incluirn caractersticas de configuracin.

Interfaces de software

MACROBUTTON NoMacro [Inserte aqu el texto]Indicar si hay que integrar el producto con otros productos de software.

Para cada producto de software debe especificarse lo siguiente:

Descripcin del producto software utilizado

Propsito del interfaz

Definicin del interfaz: contiendo y formato

Interfaces de comunicacin

MACROBUTTON NoMacro [Inserte aqu el texto]Describir los requisitos del interfaces de comunicacin si hay comunicaciones con otros sistemas y cuales son las protocolos de comunicacin.

Requisitos funcionales

MACROBUTTON NoMacro [Inserte aqu el texto]Definicin de acciones fundamentales que debe realizar el software al recibir informacin, procesarla y producir resultados.

En ellas se incluye:

Comprobacin de validez de las entradas

Secuencia exacta de operaciones

Respuesta a situaciones anormales (desbordamientos, comunicaciones, recuperacin de errores)

Parmetros

Generacin de salidas

Relaciones entre entradas y salidas (secuencias de entradas y salidas, formulas para la conversin de informacin)

Especificacin de los requisitos lgicos para la informacin que ser almacenada en base de datos (tipo de informacin, requerido)

Las requisitos funcionales pueden ser divididos en sub-secciones.

Requisito funcional 1

Requisito funcional 2

Requisito funcional 3

Requisito funcional n

Requisitos no funcionales

Requisitos de rendimiento

MACROBUTTON NoMacro [Inserte aqu el texto]Especificacin de los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el nmero de terminales, el nmero esperado de usuarios simultneamente conectados, nmero de transacciones por segundo que deber soportar el sistema, etc.

Todos estos requisitos deben ser mesurables. Por ejemplo, indicando el 95% de las transacciones deben realizarse en menos de 1 segundo, en lugar de los operadores no deben esperar a que se complete la transaccin.

Seguridad

MACROBUTTON NoMacro [Inserte aqu el texto]Especificacin de elementos que protegern al software de accesos, usos y sabotajes maliciosos, as como de modificaciones o destrucciones maliciosas o accidentales. Los requisitos pueden especificar:

Empleo de tcnicas criptogrficas.

Registro de ficheros con logs de actividad.

Asignacin de determinadas funcionalidades a determinados mdulos.

Restricciones de comunicacin entre determinados mdulos.

Comprobaciones de integridad de informacin crtica.

Fiabilidad

MACROBUTTON NoMacro [Inserte aqu el texto]Especificacin de los factores de fiabilidad necesaria del sistema. Esto se expresa generalmente como el tiempo entre los incidentes permisibles, o el total de incidentes permisible.

Disponibilidad

MACROBUTTON NoMacro [Inserte aqu el texto]Especificacin de los factores de disponibilidad final exigidos al sistema. Normalmente expresados en % de tiempo en los que el software tiene que mostrar disponibilidad.

Mantenibilidad

MACROBUTTON NoMacro [Inserte aqu el texto]Identificacin del tipo de mantenimiento necesario del sistema.

Especificacin de quien debe realizar las tareas de mantenimiento, por ejemplo usuarios, o un desarrollador.

Especificacin de cuando debe realizarse las tareas de mantenimiento. Por ejemplo, generacin de estadsticas de acceso semanales y mensuales.

Portabilidad

MACROBUTTON NoMacro [Inserte aqu el texto]Especificacin de atributos que debe presentar el software para facilitar su traslado a otras plataformas u entornos. Pueden incluirse:

Porcentaje de componentes dependientes del servidor.

Porcentaje de cdigo dependiente del servidor.

Uso de un determinado lenguaje por su portabilidad.

Uso de un determinado compilador o plataforma de desarrollo.

Uso de un determinado sistema operativo.

Otros requisitos

MACROBUTTON NoMacro [Inserte aqu el texto]Cualquier otro requisito que no encaje en ninguna de las secciones anteriores.

Por ejemplo:

Requisitos culturales y polticos

Requisitos Legales

Apndices

MACROBUTTON NoMacro [Inserte aqu el texto]Pueden contener todo tipo de informacin relevante para la SRS pero que, propiamente, no forme parte de la SRS.El Estudiante Dice y Hace:

1. El estudiante elaborara el anlisis de requerimientos de la aplicacin utilizando el formato IEEE830

Unidad Uno

1

INSTITUTO COLOMBIANO DE APRENDIZAJE INCAP

4