Desarrollo de Proyectos Informáticos

DESARROLLO DE PROYECTOS INFORMTICOS
Gua para el estudiante
Elaborado por la formadora:
VERNICA FABIANA RINCN CANTOR
INSTITUTO COLOMBIANO DE APRENDIZAJE
INCAP
Programa Tcnico Laboral en Operacin de Sistemas Informticos de Computacin
Mdulo Gua
Desarrollo de Proyectos Informticos
EL SIGUIENTE MATERIAL SE PREPAR CON FINES ESTRICTAMENTE ACADMICOS, DE ACUERDO CON EL ARTCULO 32 DE LA LEY 23 DE 1982, CUYO TEXTO ES EL SIGUIENTE:
ARTCULO 32: Es permitido utilizar obras literarias, artsticas o parte de ellas, a ttulo de ilustracin en obras destinadas a la enseanza, por medio de publicaciones, emisiones o radiodifusiones, o grabaciones sonoras o visuales, dentro de los lmites justificados por el fin propuesto, o comunicar con propsito de enseanza la obra radiodifundida para fines escolares, educativos, universitarios y de formacin personal sin fines de lucro, con la obligacin de mencionar el nombre del autor y el ttulo de las obras utilizadas.
Desarrollo de Proyectos Informticos Instituto Colombiano de Aprendizaje Elaborado por: Vernica Fabiana Rincn Cantor
Editado por: Instituto Colombiano de Aprendizaje INCAP Avenida Caracas No. 63-66 Prohibida la reproduccin parcial o total bajo cualquier forma (Art. 125 Ley 23 de 1982) Bogot Colombia Versin 01 - Julio 2010
2
Instituto Colombiano de Aprendiza je INCAP
CONTENIDO
PRESENTACIN GUA METODOLGICA UNIDAD UNO CICLO DE VIDA DEL SOFTWARE ETAPAS DEL CICLO DE VIDA DEL SOFTWARE MODELOS DEL CICLO DE VIDA DEL SOFTWARE Modelo en cascada Modelo en Espiral E Modelo Incremental Modelo Evolutivo Modelo Concurrente METODOLOGAS Metodologa CMMI Metodologa ISO Metodologa SCRUM TCNICAS DE RECOLECCION DE DATOS Introspeccin Entrevista Abierta Cuestionario Grupos de Discusin Tormenta de Ideas Entrevistas Observacin FICHA PARA ENTREVISTAS ESPECIFICACION DE REQUERIMIENTOS FORMATO IEEE830 REQUERIMIENTOS UNIDAD DOS UML DIAGRAMAS DE CASO DE USO DIAGRAMAS DE SECUENCIA HERRAMIENTAS CASE MODELO ENTIDAD RELACION CRONOGRAMAS BIBLIOGRAFIA
3
5 6 10 11 14 15 16 18 20 21 22 23 25 25 26 27 28 30 30 31 32 33 33 37 47 51 52 55 59 60 61 63
Mdulo Gua
Apreciado estudiante: Usted escogi al INCAP para que lo oriente en el camino de la formacin profesional. La institucin le proporcionar un formador, quien le ayudar a descubrir sus propios conocimientos y habilidades. El INCAP, le ofrece adems, recursos para que usted alcance sus metas, es decir, lo que se haya propuesto y para ello dispondr de mdulos gua, audiovisuales de apoyo, sistemas de evaluacin, aula y espacios adecuados para trabajos individuales y de grupo. ste mdulo gua que constituye adems un portafolio de evidencias de aprendizaje, est distribuido de la siguiente manera: PRESENTACIN: Es la informacin general sobre los contenidos, la metodologa, los alcances la importancia y el propsito del mdulo. GUA METODOLGICA: Orienta la prctica pedaggica en el desarrollo del proceso de formacin evaluacin y se complementa con el documento de la didctica para la formacin por competencias de manejo del formador. DIAGNSTICO DE ESTILO DE APRENDIZAJE: Que le permitir utilizar la estrategia ms adecuada para construir sus propios aprendizajes. AUTOPRUEBA DE AVANCE: Es un cuestionario que tiene como finalidad que usted mismo descubra, qu tanto conoce los contenidos de cada unidad, y le sirve de insumo para la concertacin de su formacin y el reconocimiento de los aprendizajes previos por parte de su formador (talleres que se encuentran al final de cada unidad). CONTENIDOS: Son el cuerpo de la unidad y estn presentados as: Unidad Logro de competencia laboral Indicadores de logro: Evidencias Didctica del mtodo inductivo Activo para el desarrollo de las competencias: FDH: Formador Dice y Hace, FDEH: Formador Dice y Estudiante Hace, EDH: Estudiante Dice y Hace. VALORACIN DE EVIDENCIAS BIBLIOGRAFA
PRESENTACIN
Presentacin Desarrollar un software significa construirlo simplemente
mediante su descripcin. Una de las mayores deficiencias en la prctica de construccin de software es la poca atencin que se presta a la discusin del problema. En general, los
desarrolladores se centran en la solucin dejando el problema inexplorado. El problema a resolver debe ser deducido a partir de su solucin. El presente mdulo ofrece al estudiante herramientas para desarrollar un software, donde intervienen muchas personas como lo es el cliente, quien tiene el problema en su empresa y desea que sea solucionado; para esto existe el analista, encargado de hacerle llegar todos los requerimientos y necesidades que tiene el cliente a los programadores quienes son las personas encargadas de realizar la codificacin y diseo del sistema para despus probarlo e instalarlo al cliente. Es as como intervienen varias personas, ya que un slo individuo no podra determinar todo lo necesario y lo ms seguro es que le haga falta algn requerimiento o alguna parte del nuevo sistema y entre ms estn involucradas, mejor para cubrir con todos los requerimientos del sistema.
5
Mdulo Gua
GUA METODOLGICA
Gua metodolgica
La estrategia metodolgica del INCAP, para la formacin tcnica del aprendiz mediante competencias laborales, comprende dos caminos: 1. Las clases presenciales dictadas por el Formador haciendo uso del mtodo inductivo activo 2. El trabajo prctico de los estudiantes dirigido y evaluado por el Formador, a travs de talleres, desarrollo de casos, lecturas y consultas de los temas de clase etc. Con esto se busca fomentar en el estudiante el anlisis, el uso de herramientas tecnolgicas y la responsabilidad. Los mdulos gua utilizados por el INCAP, para desarrollar cada uno de los cursos, se elaboran teniendo en cuenta sta metodologa. Sus caractersticas y recomendaciones de uso son: A cada unidad de aprendizaje le corresponde un logro de competencia laboral el cual viene definido antes de desarrollar su contenido. Seguidamente se definen los indicadores de logro o sea las evidencias de aprendizaje requeridas que evaluar el Formador. Glosario: Definicin de trminos o palabras utilizadas en la unidad que son propias del tema a tratar. Desarrollo de la unidad dividida en contenidos breves seguidos por ejercicios, referenciados as: FDH (El Formador Dice y Hace): Corresponde a la explicacin del contenido y el desarrollo de los ejercicios por parte del Formador. FDEH (El Formador Dice y el Estudiante Hace): El estudiante desarrolla los ejercicios propuestos y el Formador supervisa. EDH (El estudiante dice y hace): Es el trabajo prctico que desarrollan los estudiantes fuera de la clase, a travs de talleres, desarrollo de casos, lecturas y consultas de los temas, los cuales deben ser evaluados por el Formador. Al final de cada unidad se puede presentar un resumen de los contenidos ms relevantes y ejercicios generales. 6
Instituto Colombiano de Aprendiza je INCAP DIAGNSTICO INFORMACIN GENERAL Regional_____________Programa__________________Mdulo____________ Estudiante_________________________Formador_______________________
EVALUACIN DIAGNSTICA Estilo de aprendizaje_______________________________________________
Mdulo Gua
Unidad
Ciclo de Vida requerimientos
Uno
y Anlisis
1
de
T E M A S
1. Ciclo de Vida del Software y Metodologas 2. Tcnicas de Recoleccin de Datos 3. Anlisis de Requerimientos
Logro de Competencia Laboral
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 2. Conoce tcnicas de recoleccin y las diferentes formas de anlisis y organizacin 3. Elabora propuestas de trabajo de acuerdo con las necesidades expuestas en los requerimientos segn normas y protocolos
Conocimiento
Conocimiento
Producto
Mdulo Gua
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 SOFTWARE

Necesidades: 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 de una relacin
situadas en
el contexto
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).
11
Mdulo Gua
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 tener Diseo: 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, programacin. sin Es errores de diseo que y/o sean
conveniente
planteadas al menos tanto a nivel de cada mdulo (aislado del resto), como de integracin del sistema (segn sea la naturaleza del proyecto
12
Instituto Colombiano de Aprendiza je INCAP en cuestin se podrn tener en cuenta pruebas adicionales, p.ej. de rendimiento).
Validacin: Esta etapa tiene como objetivo

verificar 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).
13
Mdulo Gua
El Formador Dice y el Estudiante Hace: 3. MODELOS DEL CICLO DE VIDA DEL SOFTWARE
Un 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 que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
14
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 cascada Este modelo muestra en 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.
15
Mdulo Gua
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. Finaliza cuando 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.
VENTAJA Este modelo es sencillo porque slo 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 ESPIRAL

Es 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.
16
Instituto Colombiano de Aprendiza je INCAP 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 Riesgos 3.- Ingeniera 4.- Evaluacin
En cada vuelta o iteracin hay que tener en cuenta Los 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.
17
Mdulo Gua
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 debe las etapas del los proyecto riesgos y si de se aplica se
adecuadamente
reducir
antes
que
conviertan 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.
18
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 cuatro 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 quien 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.
19
Mdulo Gua
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.
20
3.4. MODELO EVOLUTIVO
El modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes
versiones 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 indefinidamente
21
Mdulo Gua
Desventajas 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
22
Instituto Colombiano de Aprendiza je INCAP 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. 2. 3. 4. 5. 6. Acortar los tiempos de desarrollo de los productos. Elevar la productividad. Aumentar la flexibilidad. Mejor utilizacin de los recursos. Productos de alta calidad. Reduccin en los costos de desarrollo de los productos.
Ventajas - Excelente para proyectos en los que se conforman grupos de trabajo independientes. - Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas Si no se dan las condiciones sealadas no es aplicable.
Si no existen grupos de trabajo no se puede trabajar en este mtodo
4. METODOLOGAS
Conjunto 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
23
Mdulo Gua
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 finales CARACTERSTICAS DE UNA METODOLOGA Existencia de reglas predefinidas Cobertura total del ciclo de desarrollo Verificaciones intermedias Planificacin y control Comunicacin efectiva Utilizacin sobre un abanico amplio de proyectos Fcil formacin Herramientas CASE Actividades que mejoren el proceso de desarrollo Soporte al mantenimiento Soporte de la reutilizacin de software METODOLOGA 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
24
Instituto Colombiano de Aprendiza je INCAP 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 plazos Soluciones: 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).
25
Mdulo Gua
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.
26
Instituto Colombiano de Aprendiza je INCAP Esta metodologa est basada entre muchas bajo estas premisas: a) b) c) Los individuos por encima de los procesos y herramientas En entregar soluciones por encima de reportes de seguimiento. 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 costo. 2. 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 DATOS

La 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
27
Mdulo Gua
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
28
Instituto Colombiano de Aprendiza je INCAP 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
29
Mdulo Gua
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?
30
Instituto Colombiano de Aprendiza je INCAP 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.
CUESTIONARIO
Consisten 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 DISCUSIN
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.
31
Mdulo Gua
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 conclusiones
TORMENTA 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
32
Instituto Colombiano de Aprendiza je INCAP 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.
33
Mdulo Gua
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.
34
El Formador Dice y el estudiante Hace: FICHA PARA ENTREVISTAS

Informacin del Proyecto Proyecto: Entrevistador(es): Entrevistado(s): Fecha de la Entrevista: Lugar de la Entrevista: Documentos Relacionados: NOMBRE DEL PROYECTO NOMBRE DE LA PERSONA(S) NOMBRE DE LA PERSONA(S) FECHA LUGAR Propuesta del Proyecto > Pblico objetivo y beneficios Glosario de trminos TAREAS: Copie este archivo por cada entrevista hecha. Complete los detalles. Haga una coneccin de este archivo a la seccin de "Notas de Entrevistas y Lluvias de Ideas" de userneeds.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 preguntas 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?
35
Mdulo Gua
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 en la entrevista se utiliza un significado poco usual para cierto trmino. Aada conectores 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 los lugares desde 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.
36

3. 4. 5. 6.
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!" Seleccione a los entrevistados que representen a todos los inversionistas importantes. Revise sus preguntas. Cree que pueden ser contestadas? Le ayudarn a alcanzar sus objetivos? Si no es as, redctelas de nuevo. Decida si desea hacer esta entrevista va email, telfono o en persona 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 existentes, sistemas, equipo o personas, asegrese de entender de qu 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. Las entrevistas son para entender los problemas, no para resolverlos o programar fechas de entrega. 11. Anote los elementos de los que puede obtener mayor 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.
37
Mdulo Gua
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 va 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. 2.

El estudiante deber entrevistarse con su cliente y desarrollar la
ficha anterior. Realizar como mnimo 3 entrevistas. 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: ESPECIFICACIN DE REQUERIMIENTOS

El 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 cumplir. De forma ms refinada:
38
Instituto Colombiano de Aprendiza je INCAP 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 impuesta.
De manera formal, los requerimientos se consignan 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.
39
Mdulo Gua
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.
Se sugiere seleccionar una plantilla del estndar de la IEEE:
1.
Enunciado resumen del proyecto
Por ejemplo: El propsito de este proyecto es crear una terminal de ventas a ser utilizada en tiendas supermercado.
2.
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 OBLIGATORIO
IMPORTANTE: 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 sistemas Desempeo: Velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperacin, etc. Atributos: Portabilidad, mantenimiento, seguridad, etc.
4. Otros requerimientos Participantes Grupos afectados

40
Instituto Colombiano de Aprendiza je INCAP Acepciones Riesgos Glosario
Limitaciones: 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 implementar
No 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 proyectos Quines 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 pruebas
Cules son las caractersticas deseables de un lder de proyecto? Motivador Organizado

41
Mdulo Gua
Innovador Solucionador 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
42
Instituto Colombiano de Aprendiza je INCAP 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.
RIESGOS
El 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 stos 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.
43
Mdulo Gua
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 y a menudo ponen en peligro el proyecto o el producto. 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 el 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).
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
44
Instituto Colombiano de Aprendiza je INCAP 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 fiables (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, etc.). 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 Versin: Interno de X.Y.Z SRS > Conjunto de casos de uso SRS > Conjunto de caractersticas Propuesta de proyecto Conjunto de caractersticas LIGAS A OTROS ESTNDARES RELEVANTES LIGAS A OTROS DOCUMENTOS
Formas Anexas: Documentos Relacionados:
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.
45
Mdulo Gua
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 mens, 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?
46
Instituto Colombiano de Aprendiza je INCAP 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
47
Mdulo Gua
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
48
FORMATO IEEE830 REQUERIMIENTOS
Especificacin de requisitos de software Proyecto: [Nombre del proyecto] Revisin [99.99]
[Mes de ao]
49
Mdulo Gua
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 [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

41
Instituto Colombiano de Aprendiza je INCAP Ficha del documento
Fecha
Revisin
Autor
Verificado calidad. [Firma o sello]
dep.
[Fecha]
[Rev]
[Descripcion]
Documento validado por las partes en fecha: [Fecha] Por el cliente Por la empresa suministradora
Fdo. D./ Da [Nombre]
Fdo. D./Da [Nombre]
42
Instituto Colombiano de Aprendiza je INCAP Contenido FICHA DEL DOCUMENTO CONTENIDO 1 INTRODUCCIN 1.1 Propsito 1.2 Alcance 1.3 Personal involucrado 1.4 Definiciones, acrnimos y abreviaturas 1.5 Referencias 1.6 Resumen 2 DESCRIPCIN GENERAL 2.1 Perspectiva del producto 2.2 Funcionalidad del producto 2.3 Caractersticas de los usuarios 2.4 Restricciones 2.5 Suposiciones y dependencias 2.6 Evolucin previsible del sistema 3 REQUISITOS ESPECFICOS 3.1 Requisitos comunes de los interfaces 3.1.1 Interfaces de usuario 3.1.2 Interfaces de hardware 3.1.3 Interfaces de software 3.1.4 Interfaces de comunicacin 3.2 Requisitos funcionales 3.2.1 Requisito funcional 1 3.2.2 Requisito funcional 2 3.2.3 Requisito funcional 3 3.2.4 Requisito funcional n 3.3 Requisitos no funcionales 3.3.1 Requisitos de rendimiento 3.3.2 Seguridad 3.3.3 Fiabilidad 3.3.4 Disponibilidad 3.3.5 Mantenibilidad 3.3.6 Portabilidad 3.4 Otros requisitos 4 APNDICES
42 43 44 44 44 44 44 44 44 45 45 45 45 45 45 45 45 46 46 46 46 46 47 47 47 47 47 47 47 47 47 48 48 48 48 48
43
Mdulo Gua
Introduccin [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 [Inserte aqu el texto] Propsito del documento Audiencia a la que va dirigido Alcance [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 Nombre [Inserte aqu el texto] Rol [Inserte aqu el texto] Categora [Inserte aqu el texto] profesional Responsabilidades [Inserte aqu el texto] Informacin de [Inserte aqu el texto] contacto Aprobacin [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 [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 Referencia Titulo Ruta Fecha Autor [Ref.] [Ttulo] [Ruta] [Fecha] [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 [Inserte aqu el texto] Descripcin del contenido del resto del documento
44
Instituto Colombiano de Aprendizaje INCAP Explicacin de la organizacin del documento Descripcin general Perspectiva del producto [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 [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 usuario [Inserte aqu el texto] Formacin [Inserte aqu el texto] Habilidades [Inserte aqu el texto] Actividades [Inserte aqu el texto] Descripcin de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia tcnica. Restricciones [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 [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 [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
45
Mdulo Gua
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 [Inserte aqu el texto] Nombre de requisito [Inserte aqu el texto] Tipo Requisito Restriccin Fuente del requisito [Inserte aqu el texto] Prioridad del requisito Alta/Esencial Media/Deseado 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 [Inserte aqu el texto] Descripcin detallada de todas las entradas y salidas del sistema de software. Interfaces de usuario [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 [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 [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 [Inserte aqu el texto]
46
Baja/ Opcional
Instituto Colombiano de Aprendizaje INCAP Describir los requisitos del interfaces de comunicacin si hay comunicaciones con otros sistemas y cuales son las protocolos de comunicacin. Requisitos funcionales [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 [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 [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 [Inserte aqu el texto]
47
Mdulo Gua
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 [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 [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 [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 [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 [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
48
Instituto Colombiano de Aprendizaje INCAP
Unidad Dos
Diseo de Requerimientos
T E M A S
1. 2. 3. 4. UML Diagramas de Caso de Uso Diagramas de Secuencia MER Cronograma de Actividades
5.
Logro de Competencia
1. Elaboracin de informe de diseo para determinar las necesidades tecnolgicas, representar el bosquejo de la solucin al problema mediante diagramas de casos de uso, de secuencia, diagramas de flujo y MER apoyado en el anlisis de requerimientos.
Indicadores de Logro
Conoce los conceptos de UML Elabora informe de diseo proponiendo alternativas de solucin Elabora cronogramas, casos de uso, secuencia y MER
Evidencia de
Conocimiento
Producto
Producto
49
Mdulo Gua
El Formador Dice y Hace: UML (Unified Modeling Language)

Lenguaje Unificado de Modelado (LUM) o (UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables.
Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Diagramas de Casos de Uso para modelar los procesos business. Diagramas de Secuencia para modelar el paso de mensajes entre objetos. Diagramas de Colaboracin para modelar interacciones entre objetos. Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. Diagramas de Clases para modelar la estructura esttica de las clases en el sistema.
50
Instituto Colombiano de Aprendizaje INCAP Diagramas de Objetos para modelar la estructura esttica de los objetos en el sistema. Diagramas de Componentes para modelar componentes. Diagramas de Implementacin para modelar la distribucin del sistema.
DIAGRAMAS DE CASO DE USO

El Diagrama de Caso de Uso nos da el punto de entrada para analizar los requisitos del sistema, y el problema que necesitamos solucionar. Describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso estn representados por elipses y los actores estn, por ejemplo, los casos de uso se muestran como parte del sistema que est siendo modelado, los actores no. El modelado de Casos de Uso es la tcnica ms efectiva y a la vez la ms simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cmo un sistema o negocio funciona actualmente, o cmo los usuarios desean que funcione, el objetivo es construir un Diagrama de Caso de Uso para cada tipo de escenario diferente en el sistema. Cada escenario muestra una secuencia diferente de interacciones entre actores y el sistema, Ejemplo:
51
Mdulo Gua
La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta interaccin es esencial para una descripcin coherente del comportamiento deseado, quizs los lmites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interaccin entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa pueden jugar varios papeles o roles. As el Chef y el Cajero podran ser realmente la misma persona.
Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual describe notacin grfica para esas relaciones. Inclusin (include o use) Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente
52
Instituto Colombiano de Aprendizaje INCAP comunes desde mltiples casos de uso a una descripcin individual, desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "include". Extensin (Extend) Es otra forma de interaccin, un caso de uso dado, (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensin. La extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. Generalizacin En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notacin es una lnea solida terminada en un tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til factorizar comportamientos comunes, restricciones al caso de uso general,
describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.
53
Mdulo Gua
DIAGRAMAS DE SECUENCIA
Es un tipo de diagrama usado para modelar interaccin entre objetos en un sistema segn UML En ingls se pueden encontrar como "sequence diagram". Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada mtodo de la clase. Mientras que el diagrama de casos de uso permite el modelado de una vista del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Tpicamente uno examina la descripcin de un caso de uso para determinar qu objetos son necesarios para la implementacin del escenario. Si tienes modelada la descripcin de cada caso de uso como una secuencia de
54
Instituto Colombiano de Aprendizaje INCAP varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales. El Diagrama de Secuencia es uno de los diagramas ms efectivos para modelar interaccin entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a la parte inferior; la distribucin horizontal de los objetos es arbitraria. Ejemplo:
Un evento de un sistema es un hecho externo de entrada que un actor produce en un sistema. Una operacin de un sistema es una accin que este ejecuta en respuesta a un evento del sistema.
55
Mdulo Gua
En el Diagrama anterior, el evento pasarProducto inicia una operacin del mismo nombre Pasar Producto. Las operaciones se identifican de sus eventos. Las operaciones se registran listndolas como en la tabla a la
derecha. La tabla se entiende como: Operaciones del tipo sistema.
CMO ELABORAR UN DIAGRAMA DE SECUENCIA

Para elaborar diagramas de la secuencia de un sistema que describan el curso normal de los eventos en un caso de uso: Trace una lnea que represente el sistema como una caja negra. Identifique los actores que operan directamente sobre el sistema. Trace una lnea por cada uno de ellos. A partir del curso normal de eventos del caso de uso identifique los eventos Externos del sistema que son generados por los actores. Mustrelos grficamente en el diagrama. A la izquierda del diagrama puede incluir el texto del caso de uso. Los nombres deben comenzar con un verbo (Agregar, introducir, terminar, pasar, etc.)
Ejemplo:
introducirProducto ( ) Es un buen nombre. introducirTeclaOprimida ( ) Es un nombre poco idneo, es como no debe hacerse.
56
Instituto Colombiano de Aprendizaje INCAP
57
Mdulo Gua
Desarrollo de Proyectos Informticos El Formador Dice y el estudiante Hace: HERRAMIENTAS CASE
Las herramientas CASE (Computer Aided Software Engineering), son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del proyecto, calculo de costes,
implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras. De acuerdo con Kendall y Kendall la ingeniera de sistemas asistida por ordenador es la aplicacin de tecnologa informtica a las actividades, las tcnicas y las metodologas propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseadas, en el caso de CASE para automatizar o apoyar una o ms fases del ciclo de vida del desarrollo de sistemas. Cuando se hace la planificacin de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, tambin se puede escoger una herramienta CASE (Computer-Aided SoftwareEngineering) que permita llevar a cabo el resto de tareas del modo ms eficiente y efectivo posible. Una herramienta CASE suele incluir: Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin de bases de datos. Herramientas de diseo para dar apoyo al anlisis de datos. Herramientas que permitan desarrollar el modelo de datos corporativo, as como los esquemas conceptual y lgico. Herramientas para desarrollar los prototipos de las aplicaciones.
58
Instituto Colombiano de Aprendizaje INCAP El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicacin de bases de datos. Cualquier herramienta CASE para desarrollar diagramas, alguna de las siguientes versiones de prueba, disponibles por 30 das, puede utilizarse:
- Rational Rose. Disponible en www.ibm.com
- Visio. Disponible en www.microsoft.com
- Poseidon. Disponible en http://gentleware.com/index.php
- Poseidon for UML community edition. Herramienta case UML gratuita sin lmite de tiempo de uso disponible en: http://www.gentleware.com/index.php?id=ce
MODELO ENTIDAD-RELACION
Formalmente, los diagramas E-R son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen la informacin que trata un sistema de informacin y el software que lo automatiza, pasos a seguir para el diagrama entidad-relacin: 1. Una entidad se relaciona con otra entidad con una lnea continua, ya
que no lleva flechas, es solo una direccin continua. 2. Toda relacin debe de llevar una cardinalidad (determina el nivel de
cardinalidad). 3. Una relacin entre dos entidades siempre se va a dar por medio de
un rombo (si tienes una entidad alumno, otra materia, se traza una lnea en el medio de la lnea se pone un rombo, dentro del rombo se pone "el alumno se inscribe", el nivel seria uno a muchos ya que el alumno se inscribe a varias materias).
59
Mdulo Gua
Entidad Se representa mediante un rectngulo o "caja" etiquetada en su interior mediante un identificador. Ejemplos de entidades habituales en los sistemas de informacin son: factura, persona, empleado, salario etc. Atributo Se representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Relaciones Se representa mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante lneas con las entidades (rectngulos) que relaciona.
CRONOGRAMAS
Consiste en una lista de todos los elementos terminales de un proyecto con sus fechas previstas de comienzo y final. Hay tambin herramientas libres y de cdigo abierto para la generacin de cronogramas de proyecto disponibles para la mayora de plataformas, stas ofrecen la creacin de listas de tareas, la asignacin de recursos, precedencias y diagramas de Gantt. Otros paquetes de software son:
Planner dotProject GanttProject KPlato Microsoft Project Open workbench netOffice netOffice Dwins TaskJuggler TUTOS
60
Instituto Colombiano de Aprendizaje INCAP Ejemplos de Cronogramas:
El Estudiante Dice y Hace:
1. Utilizando una herramienta case el estudiante elaborar los diagramas de caso de uso, diagramas de secuencia de su proyecto. 2. Elaborar el MER, y diccionario de datos de la base de datos de su proyecto.
61
Mdulo Gua
Desarrollo de Proyectos Informticos Bibliografa
Jacobson, I. 1998. "Applying UML in The Unified Process" Presentacin. Rational Software. Presentacin disponible en http://www.rational.com/uml como UMLconf.zip Lewis G. 1994. "What is Software Engineering?" DataPro (4015). Feb 1994. pp. 1-10. Marilyn Mantei en The effect of Programming Team Structures on Programming Tasks, 1981 Constantine, L. en Work Organization: Paradigms for Project Management and Organization, 1993. Rodrguez Diez, Gustavo. Ingeniera de Requerimientos. Notas de la clase de Metodologas de Diseo de Sistemas 2. Instituto Tecnolico de Estudios Superiores de Monterrey, Campus Monterrey 2001. Richard H. Thayer, Merlin Dorfman. Software Requerements Engineering, IEE 1997 Dean Leffingwell, Don Widring. Managing Software Requirements (A Unifiend Approach). Addison Wesley 2000
62

Desarrollo de Proyectos Informáticos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Desarrollo de Proyectos Informáticos

Enviado por

Direitos autorais:

Formatos disponíveis

DESARROLLO DE PROYECTOS INFORMTICOS

Gua para el estudiante

Elaborado por la formadora:

VERNICA FABIANA RINCN CANTOR

INSTITUTO COLOMBIANO DE APRENDIZAJE

Programa Tcnico Laboral en Operacin de Sistemas Informticos de Computacin

Desarrollo de Proyectos Informticos

Instituto Colombiano de Aprendiza je INCAP

Desarrollo de Proyectos Informticos

Instituto Colombiano de Aprendiza je INCAP

Presentacin Desarrollar un software significa construirlo simplemente

Desarrollo de Proyectos Informticos

Instituto Colombiano de Aprendiza je INCAP DIAGNSTICO INFORMACIN GENERAL Regional_____________Programa__________________Mdulo____________ Estudiante_________________________Formador_______________________

EVALUACIN DIAGNSTICA Estilo de aprendizaje_______________________________________________

Desarrollo de Proyectos Informticos

Logro de Competencia Laboral

Instituto Colombiano de Aprendiza je INCAP

Desarrollo de Proyectos Informticos

El Formador Dice y Hace: 1. Ciclo de vida del software

Instituto Colombiano de Aprendiza je INCAP

2. ETAPAS DEL CICLO DE VIDA DEL SOFTWARE

Desarrollo de Proyectos Informticos

Validacin: Esta etapa tiene como objetivo

Mantenimiento y Evolucin: Finalmente la

Desarrollo de Proyectos Informticos

Instituto Colombiano de Aprendiza je INCAP

3.1. MODELO EN CASCADA

Fases del Modelo Cascada

Desarrollo de Proyectos Informticos

3.2. MODELO EN ESPIRAL

problemas con la interfaz.

Desarrollo de Proyectos Informticos

Instituto Colombiano de Aprendiza je INCAP

3.3 . MODELO INCREMENTAL

Desarrollo de Proyectos Informticos

Instituto Colombiano de Aprendiza je INCAP

3.4. MODELO EVOLUTIVO

Desarrollo de Proyectos Informticos

Desventajas Si no se dan las condiciones sealadas no es aplicable.

Si no existen grupos de trabajo no se puede trabajar en este mtodo

Desarrollo de Proyectos Informticos

Desarrollo de Proyectos Informticos

Fuerte inversin econmica.

El Estudiante Dice y Hace:

El Formador Dice y Hace: TCNICAS DE RECOLECCION DE DATOS

Desarrollo de Proyectos Informticos

Desarrollo de Proyectos Informticos

Desarrollo de Proyectos Informticos

Desarrollo de Proyectos Informticos

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

Instituto Colombiano de Aprendiza je INCAP

El Formador Dice y el estudiante Hace: FICHA PARA ENTREVISTAS

Preguntas y Respuestas de la Entrevista

Desarrollo de Proyectos Informticos

Lista de Pendientes de la Entrevista

Instituto Colombiano de Aprendiza je INCAP

Desarrollo de Proyectos Informticos

El Estudiante Dice y Hace: 1. 2.

recoleccin de datos realiz y mostrando los resultados de cada uno.

El Formador Dice y Hace: ESPECIFICACIN DE REQUERIMIENTOS

Desarrollo de Proyectos Informticos

Se sugiere seleccionar una plantilla del estndar de la IEEE:

Enunciado resumen del proyecto

Instituto Colombiano de Aprendiza je INCAP DIAGNSTICO INFORMACIN GENERAL Regional_ProgramaMdulo Estudiante_Formador_________