Ingenieria de software - 1er parcial

Maak een Begin. Het is Gratis
of registreren met je e-mailadres
Rocket clouds
Ingenieria de software - 1er parcial Door Mind Map: Ingenieria de software - 1er parcial

1. A. Desarrollamos software de calidad

1.1. El software: Un producto ubicuo, indispensable y vital

1.2. La Naturaleza del Software

1.2.1. dif vs productos clasicos

1.2.1.1. sofware se desarrolla o modifica con intelecto

1.2.1.2. el calculo de costo es distinto

1.2.1.3. construccion basada en componentes vs uso personal

1.2.1.4. el software no se desgasta

1.3. Problemas al desarrollar

1.3.1. demora mucho tiempo en desarrollar software

1.3.2. los costos de desarrollo son altos, mayores a la estimacion inicial

1.3.3. es imposible encontrar todos los errores en las pruebas

1.3.4. se gasta mucho tiempo y esfuerzo en mantenimiento.

1.3.5. es dificil medir el avance

1.4. Proceso de desarrollo

1.4.1. procedimientos

1.4.1.1. definicion inicial (def del proyecto)

1.4.1.2. analisis de los requerimientos y su vialidad (requisito del usuario)

1.4.1.3. diseño general y detallado (se detallan req)

1.4.1.4. codificacion

1.4.1.5. pruebas (encontrar errores)

1.4.1.6. implementacion (puesta en marcha)

1.4.1.7. mantenimiento (correctivo y continuo)

1.4.2. Protectoras de calidad

1.4.2.1. Segumiento y control del proyecto de software (evalua proceso vs plan)

1.4.2.2. administracion de riesgos (evalua riesgos)

1.4.2.3. Aseguramiento de calidad de software

1.4.2.4. Revisiones tecnicas (evalua -> eliminar errores en cada etapa)

1.4.2.5. Mediciones y metricas (defini y reune mediciones del proceso, proyecto y producto)

1.4.2.6. Adm. de la configuracion de software (cambios)

1.4.2.7. Adm. de la reutilizacion

1.4.2.8. Preparacion y produccion del producto de trabajo (modelos, documentos, etc)

2. A. Clave de un relevamiento exitoso

2.1. Tres conceptos claves

2.1.1. Adecuada comprension del requemiento

2.1.2. empezar a construir sin haber comprendido la problematica puede ser un error. se soluciona con prototipos

2.1.3. las tareas deben adaptarse segun el proyecto

2.2. componentes de cada etapa

2.2.1. Concepcion (idea basica de problema, personas que lo requieren)

2.2.2. Indagacion (definiciones: ambitos (dentro o fuera), entendimiento y volatilidad (demanda en el tiempo)

2.2.3. Elaboracion (diagramas)

2.2.4. Negociacion (problemas no detectados, renegociar condiciones y plazo)

2.2.5. Especificacion (producto final de esta etapa. describe funciones, desempeño y restricciones. escribe conjunto de modelos)

2.2.6. Validaciones (revision tecnica. requerimientos realistas y validos)

2.2.7. Adm. de los requerimiento (cambios)

2.3. Problemas

2.3.1. habituales

2.3.1.1. usuarios no tienen claro lo que desean

2.3.1.2. ocultan informacion. miedo a perder trabajo

2.3.1.3. no se involucran

2.3.1.4. nuevos requerimiento finalizado el relevamiento

2.3.1.5. no comprenden problemas tecnicos

2.3.1.6. terminologia ambigua

2.3.1.7. relevamiento parcial

2.3.1.8. encajar sistemas en procesos

2.3.1.9. no todas ideas / pedidos deben llevarse a cabo

2.3.1.10. ideas de diseñadores no son validas para usuario

2.3.1.11. no es facil encontra al usuario clave

2.3.2. habituales no considerado

2.3.2.1. organizacion desconoce realmente sus problemas

2.3.2.2. no se tiene en cuenta requerimiento ni pautas iniciales

2.3.2.3. usuarios y jefes no quieren implementar nuevo sistema

2.3.2.4. usuario ocultan o paralizan info

2.3.2.5. programador con duda, no siempre accede al usuario

2.3.2.6. usuarios son personas y reaccionan de modo diferente

2.3.3. escenarios hostiles

2.3.3.1. sistema viene impuesto de arriba

2.3.3.2. nueva tecnologia sin usuario clave para relevar

2.3.3.3. areas de sistemas se oponen a software ajeno

2.3.3.4. intereses opuestos entre dos o mas areas

2.3.3.5. hay intereses politicos / economicos opuestos.

2.3.4. mitos sobre relevamiento

2.3.4.1. primera etapa es el relevamiento (existen comunicacion inicial, estudio de factibilidad y plan y presupuesto)

2.3.4.2. usuarios claves son los jefes o los que mas conocen (buscar operario clasificados, evitar usuarios toxicos)

2.3.4.3. entrevistas deben seguir proceso formal (utilizar metodos informales o descontracturados)

2.3.4.4. cuanto mas profundo el relevamiento mejor entendido el problema (cantidad no es sinomino de calidad, aporte marginal)

2.3.4.5. Programadores no deben participar en relevamiento (puede ser beneficiosa)

2.3.5. Enfoque alternativo

2.3.5.1. hay personas del otro lado

2.3.5.2. ingenieria de requerimiento vs relevamiento (buscar en vez de que aparezca)

2.3.5.3. aprovechar el primer encuentro (se establecen lazos de confianza)

3. A. Modelo para desarrolo de software

3.1. Enfoque clasico

3.1.1. analisis (relevamiento)

3.1.2. diseño (solucion informatica)

3.1.3. codificacion

3.1.4. prueba

3.1.5. puesta en marcha

3.2. Propuesta integral

3.2.1. Comunicacion inicial (primer contacto, lineamietno basicos y problemas)

3.2.2. estudio de factibilidad (se puede desarrollar o no, por costo, por solucion, etc)

3.2.3. plan y presupuesto (estimar recursos humanos, software y de entorno)

3.2.4. Construccion de la aplicacion usando un modelo (abarcan etapas de analisis, diseño, codificacion, pruebas y puesta en marcha)

3.2.5. proteccion de la calidad (auditoria, revisiones tecnicas, riesgos y contingencia, mediciones y metricas, control de cambios y versiones, verificacion y seguimiento del plan, cumplimiento de plazo y elaboracion de documento y registros.

3.2.6. garantia (etapa que solucione errores, se debe incluir en los costos del proyecto)

3.2.7. mantenimiento (necesidad de cambios o mejoras)

3.3. Distintos problemas y sistemas, distintos modelos

3.3.1. tamaño de software a desarrollar (empresas grandes distintas a chicas)

3.3.2. complejidad para obtener requerimiento

3.3.3. complejidad tecnica (equipos, maquinas industriales)

3.3.4. tiempo disponible (cuanto tardara)

3.3.5. riesgo (perdida de apoyo politico, personal, presupuesto)

3.4. Modelo linea secuencial

3.4.1. etapas: ingenieria de requerimientos (busqueda activa), diseño, codificacion, prueba, despliegue

3.4.2. ventajas

3.4.2.1. modelo simple, sensillo y probado.

3.4.2.2. para proyectos sencillos es modelo menos costoso y mas rapido

3.4.3. desventajas

3.4.3.1. rara vez sigue tan secuencial

3.4.3.2. errores en primera etapa se arrastran hasta el final

3.4.3.3. estado de bloqueo por secuencia

3.4.3.4. es dificl que el cliente especifique todos los requerimientos al inicio

3.4.3.5. cliente no ve el software hasta que no este terminado

3.5. Modelo lineal secuencial interativo o incremental

3.5.1. entregar sistema de partes, primera version y se agregan funcionalidades (modulos)

3.5.2. ventajas

3.5.2.1. entregas parciales reducen complejidad de proyecto y mejoran estimaciones

3.5.2.2. usuarios reciben version rapidamente

3.5.2.3. menos personal concurrente

3.5.2.4. implementaciones parciales mas sencillas

3.5.3. desventajas

3.5.3.1. sigue siendo un esquema secuencial

3.5.3.2. errores de primera etapa se arrastran

3.5.3.3. estados de bloqueos

3.6. Modelo de prototipos

3.6.1. es una version acotada del software para que el cliente intacture y tener un feedback de lo q quiere. se trabaja hasta que se finalicen los requerimientos.

3.6.2. etapas: relevamiento rapido, diseño de prototipo, generacion del prototipo, prueba, despliegue y retroalimentacion, contruccion de la aplicacion utilizando un modelo.

3.6.3. ventajas

3.6.3.1. mejor definicion y comprension de requerimientos iniciales

3.6.3.2. permite un testeo de funciones complejas

3.6.3.3. reduce incertidumbre

3.6.4. desventajas

3.6.4.1. el cliente puede tentarse de utilizar el prototipo

3.6.4.2. desarrolladores tentados de entregar como producto final

3.6.4.3. funcionalidad vistas en prototipo no esten en version final

3.7. Modelo en espiral

3.7.1. suceso recorriendo distintas etapas produciendo versiones operativas del software en cada vuelta

3.7.2. etapas: ingenieria de requerimiento, diseño, analisis de riesgos (via de escapa), codificacion, prueba, despliegue

3.7.3. Ventajas

3.7.3.1. entrega sucesivas y analisis de riesgos, apto para desarrollos riesgosos y con incertidumbre

3.7.3.2. puede utilizarse en todo el ciclo de vida

3.7.4. desventajas

3.7.4.1. no es simple medir riesgos

3.7.4.2. el cliente no entiende que el final fue planificado

3.7.4.3. resulta mas caro que otros modelos.

3.8. Modelo de desarrollo rapido de aplicaciones

3.8.1. utilizacion de herramientas RAD (rapid application development), construir en 30 a 90 dias.

3.8.2. etapas: ingenieria de requerimiento, diseño, codificacion, prueba, despliegue

3.8.3. ventajas

3.8.3.1. tiempo de desarrollo se acotan

3.8.3.2. reduce tiempo de pruebas y errores no dectados

3.8.3.3. sistemas portables o facil migracion entre entornos y sistemas operativos

3.8.4. desventajas

3.8.4.1. cliente debe asignar disponibilidad

3.8.4.2. no todos los proyectos son aptos para RAD

3.8.4.3. menor performance y mayor consumo de recursos

3.8.4.4. complicada implementacion en proyectos grandes, requiere mucho personal

3.9. Otros modelos

3.9.1. basado en componentes

3.9.1.1. reutilizacion de software y ensamble de componentes existentes

3.9.2. metodos formales

3.9.2.1. modelos matematicos para evitar errores

3.10. Eleccion de un modelo adecuado

3.10.1. problemas a resolver

3.10.1.1. tamaño (sistemas chicos -> modelo lineal, sistemas grandes -> modelo evolutivo)

3.10.1.2. complejidad de los requerimientos (prototipo)

3.10.1.3. complejidad tecnica (complejas -> prototopo, evaludar riesgos -> espiral)

3.10.1.4. tiempos disponibles (desarrollo rapido de aplicaciones)

3.10.1.5. entornos riesgosos (modelo en espiral)

3.11. limitaciones

3.11.1. requerimientos se plantean de antemano y no permite cambios

3.11.2. existe escasa participacion de usuarios

3.11.3. cronograma son definidos de antemano

3.11.4. ciclo de desarrollo demasiado extenso para determinadas organizaciones

3.11.5. documentacion y procesos formales no siempre bienvenidos

3.11.6. solucion: modelos agiles

4. A. Desarrollo Agil

4.1. comparacion agil vs tradicionales

4.1.1. tradicional: requisitos definidos al inicio, sin posibilidad de cambio, el sistema se entrega completo, usuario no forma parte del desarrollo, el usuario se adapta al asistema

4.1.2. agil: no existe especificacion inicial, los cambios son frecuentes, sistema siempre en desarrollo, participacion del usuario es vital, sistema se adapta al contecto.

4.1.3. Tradicional: organizaciones con entornos estables

4.1.4. agil: entornos cambiantes

4.2. Metodo agil

4.2.1. Definicion:

4.2.1.1. Documento sobre tecnicas y procesos para desarrollar software

4.2.2. principios

4.2.2.1. satisfaccion de cliente con entrega temprana

4.2.2.2. son bienvenidos los requisitos cambiantes

4.2.2.3. entregar software que funcione en periodos cortos

4.2.2.4. personas del negocio trabajan en el negocio

4.2.2.5. individuos motivados

4.2.2.6. conversaciones cara a cara

4.2.2.7. software que funciona es la principal medida de progreso

4.2.2.8. promueven el desarrollo sostenido

4.2.2.9. atencion continua mejora agilidad

4.2.2.10. simplicidad

4.2.2.11. equipos auto organizados

4.2.2.12. equipo reflexiona y ajusta conducta

4.2.3. Valores

4.2.3.1. individuos e interacciones sobre procesos y herramientas (recurso humano como factor de exito)

4.2.3.2. software funcionando sobre documentacion extensa (agil documentacion necesaria)

4.2.3.3. colaboracion con el cliente sobre negociacion contractual (cliente participacion constante)

4.2.3.4. respuesta ante el cambio sobre seguir un plan (planificacion flexible)

4.3. Programacion extrema

4.3.1. definicion

4.3.1.1. metodo agil, con buenas practicas de programacion, liberacion frecuente, potencia las relaciones interpersonales, promoviendo el trabajo en equipo.

4.3.2. valores

4.3.2.1. simplicidad (en el diseño)

4.3.2.2. comunicacion

4.3.2.3. retroalimentacion

4.3.2.4. coraje (programar para hoy, deshacerse de un codigo inutil)

4.3.2.5. respeto

4.3.3. Practicas

4.3.3.1. planeacion incremental (tarjetas de historia, y se liberan)

4.3.3.2. liberaciones pequeñas (libera minimo de funcionalidad, luego se agregan)

4.3.3.3. diseño simple (cubrir requerimientos actuales)

4.3.3.4. Refactorizacion (optimizar codigo)

4.3.3.5. programacion en pares (uno programa el otro comprueba)

4.3.3.6. propiedad colectiva (no pertenece a 1 persona)

4.3.3.7. integracion continua (integrar y probar sistema)

4.3.3.8. ritmo sustentable (gran cantidad de tiempo no es optimo)

4.3.3.9. cliente en sitio

4.3.4. Ciclo de vida

4.3.4.1. historia -> desglosar historia -> planear libercion -> desarrollar integrar -> liberacion -> evaluar sistema -> inicio

4.3.5. pruebas en xp

4.3.5.1. caracteristicas

4.3.5.1.1. desarrollo en la primera prueba (escribo y pruebo)

4.3.5.1.2. des. pruebas incrementales a partir de escenario (pruebas de aceptacion)

4.3.5.1.3. involucramiento del usuario (pruebas de cliente)

4.3.5.1.4. uso de marcos de pruebas automatizadas (para primera prueba)

4.3.6. Programacion en pares

4.3.6.1. uno codifica el otro trata de mejorarlo (coductor y acompañante)

4.3.6.2. ventajas

4.3.6.2.1. apoya la idea de la propiedad y responsabilidad colectiva

4.3.6.2.2. actua como revision informal

4.3.6.2.3. ayuda a la refactorizacion

4.3.6.2.4. enseñanza

4.3.6.2.5. multiples desarrolladores constituyen al diseño

4.3.6.2.6. mayor disciplina

4.3.7. ventajas

4.3.7.1. se adapta a desarrollos pequeños y grandes

4.3.7.2. optimiza tiempo de desarrollo

4.3.7.3. comparte conocimiento

4.3.7.4. codigo simple y entendible

4.3.8. desventajas

4.3.8.1. no tiene definicion de costo y tiempo

4.3.8.2. precencia constante del usuario

4.3.8.3. desarrolladores celosos del codigo

4.4. Scrum

4.4.1. Proceso

4.4.1.1. 3 fases. 1. planeacion del bosquejo. 2.serie de ciclos o sprint: unidad de planeacion donde se valora el trabajo a realizar y se implementa software. 3. la funcionalidad se entrega y se reinicia el cliclo

4.4.2. caracteristicas

4.4.2.1. sprint tienen longitud fisica (2 a 4 semanas)

4.4.2.2. punto de partida es producto backlog (lista de trabajo)

4.4.2.3. fase de seleccion selecciona caracteristicas y funcionalidades

4.4.2.4. equipo desarrolla (reuniones breves diarias) se aisla del cliente y lo organiza el scrum master: protege al grupo de distracciones)

4.4.2.5. finaliza sprint, trabajo se revisa y se presenta.

4.4.2.6. fase de cierre concluye con la documentacion requerida (ayuda, manuales de usuario y lecciones aprendidas)

4.4.3. Principios

4.4.3.1. control de procesos empiricos: para la toma de decisiones: transparencia, inspeccion, adaptacion

4.4.3.2. auto organizacion

4.4.3.3. colaboracion (3 dimensiones: conciencia, articulacion y apropiacion)

4.4.3.4. priorizacion basada en el valor

4.4.3.5. time boxing (optimizacion de tiempo, reuniones)

4.4.3.6. desarrollo iterativo (satisfaccion de cliente)

4.4.4. Roles

4.4.4.1. Product owner (la voz del cliente)

4.4.4.2. equipo scrum (creacion de entregables)

4.4.4.3. scrum master (faculitador del equipo. guia facilita y les enseña)

4.4.4.4. cerdos (comprometido) gallina (involucrado)

4.4.5. ventajas

4.4.5.1. adaptabilidad

4.4.5.2. transparencia

4.4.5.3. retroalimentacion continua

4.4.5.4. mejoras continuas

4.4.5.5. entrega continua de valor

4.4.5.6. ritmo sostenible (al mismo ritmo)

4.4.5.7. motivacion

4.4.5.8. resolucion rapida de problemas

4.4.5.9. entregables efectivos

4.4.6. criticas

4.4.6.1. equipo subre estres

4.4.6.2. equipo toma camino mas corto

4.4.6.3. dificil en proyectos grandes

4.4.6.4. supone equipo motivado y formado

4.4.6.5. propone cliente involucrado

4.4.6.6. muchas reuniones diarias

4.5. ventajas desventeajas limitaciones

4.5.1. ventajas

4.5.1.1. rapida respuesta a cambios

4.5.1.2. clientes observan avance de proyecto

4.5.1.3. entregables parciales

4.5.1.4. reduce tiempos de costo y capacitacion

4.5.2. dificultades

4.5.2.1. cliente sigue con tareas operativas no proyecto

4.5.2.2. miembros no tienen personalidad adecuada (trabajo en equipo)

4.5.2.3. priorizar cambios es dificil

4.5.2.4. mantener simplicidad requiere un trabajo adicional

4.5.2.5. dificil implementar en empresas grandes

4.5.3. limitaciones

4.5.3.1. falta documentacion de diseño

4.5.3.2. problemas derivados de la comunicacion oral

4.5.3.3. los desarrollos no tienen la misma secuenciabilidad

4.5.3.4. restricciones por tamaño de proyecto, lugar geografico

4.5.3.5. contratos por tiempo insumido, dificil de administrar

4.6. conclucion

4.6.1. no es sinomino de rapido, con errores, y sin calidad.

4.6.2. indica acotar procesos tradicionales.

4.6.3. no implica

4.6.3.1. aucencia de documentacion, suprimir etapas, todo rapido (sin calidad), dejar las actividades protectoras

5. L.1. introduccion

5.1. Preguntas

5.1.1. que es software: programa de computo y documentacion asociada

5.1.2. atributos del buen software: entregar al usuario funcionalidad y desempeño requerido.

5.1.3. dif entre ingenieria sistemas y software: sistema basado en computadoras. software es una disciplina que se interesa por todos los aspectos de la produccion de software

5.2. tipos de productos

5.2.1. genericos

5.2.2. personalizados

5.3. etica

5.3.1. confidencialidad

5.3.2. competencia

5.3.3. derecho de propiedad intelectual

5.3.4. mal uso de computadora

5.4. puntos claves

5.4.1. ■ La ingeniería de software es una disciplina de ingeniería que se interesa por todos los aspectos de la producción de software. ■ El software no es sólo un programa o programas, sino que también incluye documentación. Los atributos esenciales de los productos de software son mantenimiento, confiabilidad, seguridad, eficiencia y aceptabilidad. ■ El proceso de software incluye todas las actividades que intervienen en el desarrollo de software. Las actividades de alto nivel de especificación, desarrollo, validación y evolución son parte de todos los procesos de software. ■ Las nociones fundamentales de la ingeniería de software son universalmente aplicables a todos los tipos de desarrollo de sistema. Dichos fundamentos incluyen procesos, confiabilidad, seguridad, requerimientos y reutilización de software. ■ Existen muchos tipos diferentes de sistemas y cada uno requiere para su desarrollo de herramientas y técnicas adecuadas de ingeniería de software. Existen pocas, si es que hay alguna, técnicas específicas de diseño e implementación que son aplicables a todos los tipos de sistemas. ■ Las ideas fundamentales de la ingeniería de software son aplicables a todos los tipos de sistemas de software. Dichos fundamentos incluyen procesos de administración de software, confiabilidad y seguridad del software, ingeniería de requerimientos y reutilización de software. ■ Los ingenieros de software tienen responsabilidades con la profesión de ingeniería y la sociedad. No deben preocuparse únicamente por temas técnicos. ■ Las sociedades profesionales publican códigos de conducta que establecen los estándares de comportamiento esperados de sus miembros.

6. L.2. Procesos de software

6.1. modelos

6.1.1. modelo en cascada

6.1.2. desarrollo incremental

6.1.3. reutilizacion

6.1.3.1. etapas

6.1.3.1.1. analisis de componentes

6.1.3.1.2. modificacion de requisitos

6.1.3.1.3. diseño con reutilizacion

6.1.3.1.4. desarrollo e integracion

6.2. Actividades

6.2.1. especificacion del software (identificar que se quiere y resticciones)

6.2.2. diseño e implementacion (convertir especificacion en ejecutable)

6.2.2.1. entrada de diseño: plataforma de info, especificacion de requerimiento, datos

6.2.2.2. actividades de diseño: diseño arquitectonico, interfaz, componentes, base de datos

6.2.2.3. salida: arquitectura del sistema, base de datos, interfaz componentes

6.2.3. validacion

6.2.3.1. prueba de desarrollo

6.2.3.2. prueba de sistema (integracion de sistema)

6.2.3.3. prueba de aceptacion

6.2.4. evolucion del software

6.2.4.1. que sea posible el mantenimiento

6.3. enfrentar cambio

6.3.1. prototipo

6.3.2. entrega incremental

6.3.3. espiral

6.4. proceso de unificacion racional

6.4.1. conjunto de elementos de todos los modelos de procesos genericos

6.4.2. fases

6.4.2.1. concepcion

6.4.2.2. elaboracion

6.4.2.3. contruccion

6.4.2.4. transicion

6.4.3. buenas practicas

6.4.3.1. desarrollo de manera iterativa

6.4.3.2. gestion de requerimientos

6.4.3.3. usar arquitecturas basadas en componentes

6.4.3.4. software modelado visualmente

6.4.3.5. verificar calidad de software

6.4.3.6. controlar los cambios del software

6.5. puntos claves:

6.5.1. ■ Los procesos de software son actividades implicadas en la producción de un sistema de software. Los modelos de proceso de software consisten en representaciones abstractas de dichos procesos. ■ Los modelos de proceso general describen la organización de los procesos de software. Los ejemplos de estos modelos generales incluyen el modelo en cascada, el desarrollo incremental y el desarrollo orientado a la reutilización. ■ La ingeniería de requerimientos es el proceso de desarrollo de una especificación de software. Las especificaciones tienen la intención de comunicar las necesidades de sistema del cliente a los desarrolladores del sistema. ■ Los procesos de diseño e implementación tratan de transformar una especificación de requerimientos en un sistema de software ejecutable. Pueden usarse métodos de diseño sistemáticos como parte de esta transformación. ■ La validación del software es el proceso de comprobar que el sistema se conforma a su especificación y que satisface las necesidades reales de los usuarios del sistema. ■ La evolución del software tiene lugar cuando cambian los sistemas de software existentes para satisfacer nuevos requerimientos. Los cambios son continuos y el software debe evolucionar para seguir siendo útil. ■ Los procesos deben incluir actividades para lidiar con el cambio. Esto puede implicar una fase de creación de prototipos que ayude a evitar malas decisiones sobre los requerimientos y el diseño. Los procesos pueden estructurarse para desarrollo y entrega iterativos, de forma que los cambios se realicen sin perturbar al sistema como un todo. ■ El Proceso Unificado Racional es un modelo de proceso genérico moderno que está organizado en fases (concepción, elaboración, construcción y transición), pero separa las actividades (requerimientos, análisis y diseño, etcétera) de dichas fases.

7. L.4. Ingenieria de requerimientos

7.1. definicion

7.1.1. de usuario son enunciados, en lenguaje natural de lo que se espera del sistema.

7.1.2. de sistema son descripciones de las funciones, servicios y restricciones de un sistema de software.

7.2. requerimientos funcionales y no funcionales

7.2.1. funcionales

7.2.1.1. enunciados acerca del servicio que el sistema debe proveer, reaccionar frente a entradas. tambien dice los que no debe hacer

7.2.2. no funcionales

7.2.2.1. requerimientos que no se relacionan directamente con el servicio. ej fiabilidad, tiempo de respuesta y uso de almacenamiento.

7.2.2.2. clasificacion

7.2.2.2.1. requerimiento del producto (restringen el comportamiento del software)

7.2.2.2.2. requerimiento de la organizacion (politicas y procedimientos de la organizacion)

7.2.2.2.3. requerimientos externos (regulatorios)

7.3. documento de requerimientos de software

7.3.1. definicion

7.3.1.1. es un comunicado oficial de lo que debe implementar los desarrolladores del sistema. incluye los requerimientos del usuario como especificacion detallada de los requerimientos del sistema.

7.3.2. estructura

7.3.2.1. prefacio, introduccion, glosario, definicion de requerimientos de usuario, arquitectura del sistema, especificaciones de requerimietno, modelos de sistemas, evolucion del sistema, apendices, indices

7.4. especificaciones de requerimientos

7.4.1. es el proceso de escribir los requierimientos de usuario y de sistemas

7.4.2. formas de escribir

7.4.2.1. enunciado en lenguaje natural (Es expresivo, intuitivo y universal)

7.4.2.2. lenguaje natural estructurado (estandar)

7.4.2.3. lenguajes de descripcion de diseño

7.4.2.4. anotaciones graficas (UML)

7.4.2.5. especificaciones matematicas.

7.5. proceso de ingenieria de requisitos

7.5.1. estudio de factibilidad, adquisicion y analisis, especificacion y valoracion

7.6. adquisicion y analisis de requerimientos

7.6.1. ciclo de vida

7.6.1.1. descubrimiento de requerimientos (recopilar informacion sobre el sistema)

7.6.1.2. clasificacion y organizacion de requerimientos

7.6.1.3. priorizacion y negociacion de requerimientos

7.6.1.4. especificacion de requerimientos

7.6.2. entrevistas

7.6.2.1. cerradas (preguntas preestablecidas)

7.6.2.2. abiertas (no tiene agenda predefinida)

7.6.3. escenarios

7.6.3.1. bosquejos de la descipcion de requerimiento

7.6.4. caso de uso

7.6.4.1. son una tecnica de descubrimiento de requerimientos. identifica actores y tipo de interaccion.

7.6.4.2. diagrama de caso de uso a alto nivel

7.6.5. etnografia

7.6.5.1. es una tecnica de observacion que se usa para entender los procesos operacionales y ayudar a derivar requerimientos de apoyo par adichos procesos

7.6.5.2. requerimiento

7.6.5.2.1. forma en que trabaja la gente

7.6.5.2.2. cooperacion y conocimiento de las actividades de otras personas

7.6.5.3. generacion de prototipos

7.6.6. validacion de requerimientos

7.6.6.1. es un proceso de verificar que los requerimientos definan el sistema que quiera el cliente.

7.6.6.2. comprobaciones

7.6.6.2.1. de validez

7.6.6.2.2. de consistencia (no debe haber conflicto)

7.6.6.2.3. de totalidad

7.6.6.2.4. de realismo

7.6.6.2.5. verificabilidad (reducir conflicto entre cliente y contratista)

7.6.6.3. tecnicas

7.6.6.3.1. revision de requerimientos

7.6.6.3.2. creacion de prototipos

7.6.6.3.3. generacion de casos de prueba

7.6.7. administracion de requerimientos

7.6.7.1. nuevo requiermiento por mejoras

7.6.7.1.1. ambientales empresariales

7.6.7.1.2. individuos que pagan por un sistema y los usuarios por otros

7.6.7.1.3. empresas grandes con usuarios diversos

7.6.7.2. planeacion

7.6.7.2.1. identificar el requerimiento

7.6.7.2.2. proceso de administracion de cambios (conjunto de actividades qeu valuan efecto y costo de los cambios)

7.6.7.2.3. politicas de seguimiento

7.6.7.2.4. implementacion del cambio

7.7. puntos importantes

7.7.1. ■ Los requerimientos para un sistema de software establecen lo que debe hacer el sistema y definen las restricciones sobre su operación e implementación. ■ Los requerimientos funcionales son enunciados de los servicios que debe proporcionar el sistema, o descripciones de cómo deben realizarse algunos cálculos. ■ Los requerimientos no funcionales restringen con frecuencia el sistema que se va a desarrollar y el proceso de desarrollo a usar. Éstos pueden ser requerimientos del producto, requerimientos organizacionales o requerimientos externos. A menudo se relacionan con las propiedades emergentes del sistema y, por lo tanto, se aplican al sistema en su conjunto. ■ El documento de requerimientos de software es un enunciado acordado sobre los requerimientos del sistema. Debe organizarse de forma que puedan usarlo tanto los clientes del sistema como los desarrolladores del software. ■ El proceso de ingeniería de requerimientos incluye un estudio de factibilidad, adquisición y análisis de requerimientos, especificación de requerimientos, validación de requerimientos y administración de requerimientos. ■ La adquisición y el análisis de requerimientos es un proceso iterativo que se representa como una espiral de actividades: descubrimiento de requerimientos, clasificación y organización de requerimientos, negociación de requerimientos y documentación de requerimientos. ■ La validación de requerimientos es el proceso de comprobar la validez, la consistencia, la totalidad, el realismo y la verificabilidad de los requerimientos. ■ Los cambios empresariales, organizacionales y técnicos conducen inevitablemente a cambios en los requerimientos para un sistema de software. La administración de requerimientos es el proceso de gestionar y controlar dichos cambios.

8. L.5. Modelado de sistema

8.1. introduccion

8.1.1. definicion

8.1.1.1. es el proceso para desarrollar modelos abstractos de un sistema, repesentacion grafica notaciones en el lenguaje de modelado unificado (UML)

8.1.2. perspectiva

8.1.2.1. externa

8.1.2.2. interaccion

8.1.2.3. estructural

8.1.2.4. comportamiento

8.1.3. diagramas

8.1.3.1. diagrama de actividad (actividad del proceso)

8.1.3.2. diagrama de caso de uso (interacciones entre un sistema y su entorno)

8.1.3.3. diagrama de secuencias (interacciones entre los actores y el sistema)

8.1.3.4. diagrama de clases (clases de objeto y asociaciones)

8.1.3.5. diagrama de estados (reaccion frente a eventos)

8.2. modelo de contexto

8.2.1. frontera del sistema, funcionalidad que se incluira en el sistema y cual no

8.3. modelo de interaccion

8.3.1. interacciones

8.3.1.1. usuario sistema

8.3.1.2. sistema y otros sistemas

8.3.1.3. entre componentes del sistema

8.3.2. modelado

8.3.2.1. casos de uso

8.3.2.1.1. simple escenario de los que el usuario espera del sistema

8.3.2.2. diagrama de secuencias

8.3.2.2.1. sucesion de interacciones entre los actores y los objetos del sistema

8.4. modelo estructurales

8.4.1. Los modelos estructurales son modelos estáticos, que muestran la estructura del diseño del sistema, o modelos dinámicos, que revelan la organización del sistema cuando se ejecuta.

8.4.2. diagrama de clases

8.4.2.1. clases y sus asociaciones

8.4.2.1.1. 1. El nombre de la clase de objeto está en la sección superior.

8.4.2.1.2. 2. Los atributos de clase están en la sección media. Esto debe incluir los nombres del atributo y, opcionalmente, sus tipos.

8.4.2.1.3. 3. Las operaciones (llamadas métodos en Java y en otros lenguajes de programación OO) asociadas con la clase de objeto están en la sección inferior del rectángulo.

8.4.3. generalizacion

8.4.3.1. cada entidad se agrupa en una clase mas general

8.5. modelos de comportamiento

8.5.1. modelos dinamicos del sistema conforme se ejecutan, responde a estimulos

8.5.2. modelado dirigido por datos

8.5.2.1. secuencia de acciones de datos de entradas y salidas

8.5.2.2. DFD diagrama de flujo de datos (funcion o proceso)

8.5.3. modelado dirigido por un evento

8.5.3.1. como responde el sistema a eventos externos e internos

8.5.3.2. diagramas de estado (estado y eventos) (estado / estimulo)

8.6. ingenieria dirigida por modelo

8.6.1. es un enfoque donde los modelos son las salidas principales del proceso

8.7. puntos claves

8.7.1. ■ Un modelo es una visión abstracta de un sistema que ignora algunos detalles del sistema. Pueden desarrollarse modelos complementarios del sistema para mostrar el contexto, las interacciones, la estructura y el comportamiento del sistema. ■ Los modelos de contexto muestran cómo un sistema a modelar se coloca en un entorno con otros sistemas y procesos. Ayudan a definir las fronteras del sistema a desarrollar. ■ Los diagramas de caso de uso y los diagramas de secuencia se emplean para describir las interacciones entre usuario/sistema a diseñar y usuarios/otros sistemas. Los casos de uso describen interacciones entre un sistema y actores externos; los diagramas de secuencia agregan más información a éstos al mostrar las interacciones entre objetos del sistema. ■ Los modelos estructurales indican la organización y arquitectura de un sistema. Los diagramas de clase se usan para definir la estructura estática de clases en un sistema y sus asociaciones. ■ Los modelos del comportamiento se usan para describir la conducta dinámica de un sistema en ejecución. Pueden modelarse desde la perspectiva de los datos procesados por el sistema, o mediante los eventos que estimulan respuestas de un sistema. ■ Los diagramas de actividad se utilizan para modelar el procesamiento de datos, en que cada actividad representa un paso del proceso. ■ Los diagramas de estado se utilizan para modelar el comportamiento de un sistema en respuesta a eventos internos o externos. ■ La ingeniería dirigida por modelo es un enfoque al desarrollo del software donde un sistema se representa como un conjunto de modelos que pueden transformarse automáticamente a código ejecutable.

9. L.6. Diseño arquitectonico

9.1. decisiones

9.1.1. es un proceso creativo en el cual se diseña las funcionalidades que tendra el sistema.

9.1.2. no funcionales

9.1.2.1. rendimiento

9.1.2.2. seguridad

9.1.2.3. proteccion

9.1.2.4. disponibilidad

9.1.2.5. mantenibilidad

9.2. patrones arquitectonicos

9.2.1. arquitectura en capas

9.2.2. arquitectura de repositorio

9.2.3. arquitectura cliente servidor

9.2.4. arquitectura de tuberia y filtro

9.3. arquitecturas de aplicaciones

9.3.1. encapsulan las principales caracteristicas de una clase

9.3.2. formas de uso

9.3.2.1. punto de partida para el proceso de diseño arquitectonico

9.3.2.2. lista de verificacion de diseño

9.3.2.3. una forma de organizar el trabajo de equipo de desarrollo

9.3.2.4. un medio apra valorar los componentes de reutilizacion

9.3.2.5. un vocabulario para hablar acerca de los tipos de aplicaciones

9.3.3. sistema de procesamiento de transacciones

9.3.3.1. procesar peticiones contra la base de datos modificando datos.

9.3.4. sistemas de informacion

9.3.4.1. permite controlar gran parte de la informacion (idem arquitectura en capas)

9.3.5. sistema de procesamiento de lenguaje

9.3.5.1. convierte lenguaje natural en programacion

9.4. puntos claves

9.4.1. ■ Una arquitectura de software es una descripción de cómo se organiza un sistema de software. Las propiedades de un sistema, como rendimiento, seguridad y disponibilidad, están influidas por la arquitectura utilizada. ■ Las decisiones de diseño arquitectónico incluyen decisiones sobre el tipo de aplicación, la distribución del sistema, los estilos arquitectónicos a usar y las formas en que la arquitectura debe documentarse y evaluarse. ■ Las arquitecturas pueden documentarse desde varias perspectivas o diferentes vistas. Las posibles vistas incluyen la conceptual, la lógica, la de proceso, la de desarrollo y la física. ■ Los patrones arquitectónicos son medios para reutilizar el conocimiento sobre las arquitecturas de sistemas genéricos. Describen la arquitectura, explican cuándo debe usarse, y exponen sus ventajas y desventajas. ■ Los patrones arquitectónicos usados comúnmente incluyen el modelo de vista del controlador, arquitectura en capas, repositorio, cliente-servidor, y tubería y filtro. ■ Los modelos genéricos de las arquitecturas de sistemas de aplicación ayudan a entender la operación de las aplicaciones, comparar aplicaciones del mismo tipo, validar diseños del sistema de aplicación y valorar componentes para reutilización a gran escala. ■ Los sistemas de procesamiento de transacción son sistemas interactivos que permiten el acceso y la modificación remota de la información, en una base de datos por parte de varios usuarios. Los sistemas de información y los sistemas de gestión de recursos son ejemplos de sistemas de procesamiento de transacciones. ■ Los sistemas de procesamiento de lenguaje se usan para traducir textos de un lenguaje a otro y para realizar las instrucciones especificadas en el lenguaje de entrada. Incluyen un traductor y una máquina abstracta que ejecuta el lenguaje generado.

10. L.7. Diseño e implementacion

10.1. introduccion

10.1.1. se desarrolla un sistema de software ejecutable.

10.2. diseño orientado a objetos con el uso de UML

10.2.1. contecto e intaccion del sistema

10.2.1.1. modelo de contexto

10.2.1.2. modelo de interaccion

10.2.2. diseño arquitectonico

10.2.2.1. identificar principales componentes del sistema e interacciones. luego organice en modelo de capas o cliente servidor

10.2.3. identificacion de clase de objetos

10.2.3.1. aumenta la comprension del sistema. diagrama de clases.

10.2.4. modelos de diseño

10.2.4.1. tipos

10.2.4.1.1. modelos estructurales

10.2.4.1.2. modelos dinamicos (diagrama de secuencia)

10.2.5. especificacion de interfaz

10.2.5.1. diagrama de clases

10.3. Patrones de diseño

10.3.1. los patrones y lenguajes de patron son formas de describir mejores practicas, buenos diseños y captan la experiencia de tal manera que es posible que otros reutilicen la experiencia.

10.4. conflictos de implementacion

10.4.1. aspectos importantes

10.4.1.1. reutilizacion

10.4.1.1.1. niveles

10.4.1.2. administracion de configuracion

10.4.1.2.1. gestion de versiones

10.4.1.2.2. integracion de sistema

10.4.1.2.3. rastreo de problemas

10.4.1.3. desarrollo huesped objetivo

10.4.1.3.1. requerimiento de hardware y software de un componente

10.4.1.3.2. requerimientos de disponibilidad de sistema

10.4.1.3.3. comunicaciones de componentes

10.5. desarrollo de codigo abierto

10.5.1. licencias de codigo abierto

10.5.1.1. gratuitas reciprocas

10.5.1.2. gratuitas, con componentes q no tiene necesidad de publicarlas

10.5.1.3. licencia no reciprocas

10.6. puntos claves

10.6.1. ■ El diseño y la implementación del software son actividades entrelazadas. El nivel de detalle en el diseño depende del tipo de sistema a desarrollar y de si se usa un enfoque dirigido por un plan o uno ágil. ■ Los procesos del diseño orientado a objetos incluyen actividades para diseñar la arquitectura del sistema, identificar objetos en el sistema, describir el diseño mediante diferentes modelos de objeto y documentar las interfaces de componente. ■ Durante un proceso de diseño orientado a objetos, puede elaborarse una variedad de modelos diferentes. En ellos se incluyen modelos estáticos (modelos de clase, modelos de generalización, modelos de asociación) y modelos dinámicos (modelos de secuencia, modelos de máquina de estado). ■ Las interfaces de componente deben definirse con precisión, de modo que otros objetos puedan usarlos. Para definir interfaces es posible usar un estereotipo de interfaz UML. ■ Cuando se desarrolla software, siempre debe considerarse la posibilidad de reutilizar el software existente, ya sea como componentes, servicios o sistemas completos. ■ La administración de la configuración es el proceso de gestionar los cambios a un sistema de software en evolución. Es esencial cuando un equipo de personas coopera para desarrollar software. ■ La mayoría del desarrollo de software es desarrollo huésped-objetivo. Se usa un IDE en una máquina para desarrollar el huésped, que se transfiere a una máquina objetivo para su ejecución. ■ El desarrollo de código abierto requiere hacer públicamente disponible el código fuente de un sistema. Esto significa que muchos individuos tienen la posibilidad de proponer cambios y mejoras al software.

11. L.8.Prueba de software

11.1. etapas

11.1.1. prueba de desarrollo (a medida que escribe el codigo)

11.1.2. versiones de pruebas (version completa antes de pasarselo a los usuarios)

11.1.3. prueba de usuario

11.2. puntos claves

11.2.1. ■ Las pruebas sólo pueden mostrar la presencia de errores en un programa. Si embargo, no pueden garantizar que no surjan fallas posteriores. ■ Las pruebas de desarrollo son responsabilidad del equipo de desarrollo del software. Un equipo independiente debe responsabilizarse de probar un sistema antes de darlo a conocer a los clientes. En el proceso de pruebas de usuario, clientes o usuarios del sistema brindan datos de prueba y verifican que las pruebas sean exitosas. ■ Las pruebas de desarrollo incluyen pruebas de unidad, donde se examinan objetos y métodos individuales; pruebas de componente, donde se estudian grupos de objetos relacionados; y pruebas del sistema, donde se analizan sistemas parciales o completos. ■ Cuando pruebe software, debe tratar de “romperlo” mediante la experiencia y los lineamientos que elijan los tipos de casos de prueba que hayan sido efectivos para descubrir defectos en otros sistemas. ■ Siempre que sea posible, se deben escribir pruebas automatizadas. Las pruebas se incrustan en un programa que puede correrse cada vez que se hace un cambio al sistema. ■ El desarrollo de la primera prueba es un enfoque de desarrollo, donde las pruebas se escriben antes de que se pruebe el código. Se realizan pequeños cambios en el código, y éste se refactoriza hasta que todas las pruebas se ejecuten exitosamente. ■ Las pruebas de escenario son útiles porque imitan el uso práctico del sistema. Implican trazar un escenario de uso típico y utilizarlo para derivar casos de prueba. ■ Las pruebas de aceptación son un proceso de prueba de usuario, donde la meta es decidir si el software es suficientemente adecuado para desplegarse y utilizarse en su entorno operacional.

12. L.3. Desarrollo agil de software

12.1. caracteristicas

12.1.1. proceso especificacion, diseño e implementacion se entrelazan

12.1.2. sistema se desarrolla en diferentes versiones

12.1.3. interfaz se desarrolla usando una elaboracion interativo

12.2. dificultades

12.2.1. disponibilidad de usuario

12.2.2. personalidad de equipo

12.2.3. priorizar cambios extremadamente dificil

12.2.4. mantener la simplicidad requiere trabajo adicional

12.2.5. cambios de cultura

12.3. programacion extrema

12.3.1. pruebas

12.3.1.1. primera prueba

12.3.1.2. desarrollo de pruebas incrementales

12.3.1.3. involucramiento de usuarios

12.3.1.4. pruebas automatizadas

12.4. programacion en pares

12.5. administracion de un proyecto agil

12.5.1. planeacion de bosquejo y diseño

12.5.2. sprint: valoracion, seleccion, desarrollo, revision.

12.5.3. cierre del proyecto

12.6. puntos claves

12.6.1. ■ Los métodos ágiles son métodos de desarrollo incremental que se enfocan en el diseño rápido, liberaciones frecuentes del software, reducción de gastos en el proceso y producción de código de alta calidad. Hacen que el cliente intervenga directamente en el proceso de desarrollo. ■ La decisión acerca de si se usa un enfoque de desarrollo ágil o uno basado en un plan depende del tipo de software que se va a elaborar, las capacidades del equipo de desarrollo y la cultura de la compañía que diseña el sistema. ■ La programación extrema es un método ágil bien conocido que integra un rango de buenas prácticas de programación, como las liberaciones frecuentes del software, el mejoramiento continuo del software y la participación del cliente en el equipo de desarrollo. ■ Una fortaleza particular de la programación extrema, antes de crear una característica del programa, es el desarrollo de pruebas automatizadas. Todas las pruebas deben ejecutarse con éxito cuando un incremento se integra en un sistema. Capítulo 3 ■ Puntos clave 77 ■ El método de Scrum es un método ágil que ofrece un marco de referencia para la administración del proyecto. Se centra alrededor de un conjunto de sprints, que son periodos fijos cuando se desarrolla un incremento de sistema. La planeación se basa en priorizar un atraso de trabajo y seleccionar las tareas de importancia más alta para un sprint. ■ Resulta difícil el escalamiento de los métodos ágiles para sistemas grandes, ya que éstos necesitan diseño frontal y cierta documentación. La integración continua es prácticamente imposible cuando existen muchos equipos de desarrollo separados que trabajan en un proyecto.