1. L.1. introduccion
1.1. Preguntas
1.1.1. que es software: programa de computo y documentacion asociada
1.1.2. atributos del buen software: entregar al usuario funcionalidad y desempeño requerido.
1.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
1.2. tipos de productos
1.2.1. genericos
1.2.2. personalizados
1.3. etica
1.3.1. confidencialidad
1.3.2. competencia
1.3.3. derecho de propiedad intelectual
1.3.4. mal uso de computadora
1.4. puntos claves
1.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.
2. L.2. Procesos de software
2.1. modelos
2.1.1. modelo en cascada
2.1.2. desarrollo incremental
2.1.3. reutilizacion
2.1.3.1. etapas
2.1.3.1.1. analisis de componentes
2.1.3.1.2. modificacion de requisitos
2.1.3.1.3. diseño con reutilizacion
2.1.3.1.4. desarrollo e integracion
2.2. Actividades
2.2.1. especificacion del software (identificar que se quiere y resticciones)
2.2.2. diseño e implementacion (convertir especificacion en ejecutable)
2.2.2.1. entrada de diseño: plataforma de info, especificacion de requerimiento, datos
2.2.2.2. actividades de diseño: diseño arquitectonico, interfaz, componentes, base de datos
2.2.2.3. salida: arquitectura del sistema, base de datos, interfaz componentes
2.2.3. validacion
2.2.3.1. prueba de desarrollo
2.2.3.2. prueba de sistema (integracion de sistema)
2.2.3.3. prueba de aceptacion
2.2.4. evolucion del software
2.2.4.1. que sea posible el mantenimiento
2.3. enfrentar cambio
2.3.1. prototipo
2.3.2. entrega incremental
2.3.3. espiral
2.4. proceso de unificacion racional
2.4.1. conjunto de elementos de todos los modelos de procesos genericos
2.4.2. fases
2.4.2.1. concepcion
2.4.2.2. elaboracion
2.4.2.3. contruccion
2.4.2.4. transicion
2.4.3. buenas practicas
2.4.3.1. desarrollo de manera iterativa
2.4.3.2. gestion de requerimientos
2.4.3.3. usar arquitecturas basadas en componentes
2.4.3.4. software modelado visualmente
2.4.3.5. verificar calidad de software
2.4.3.6. controlar los cambios del software
2.5. puntos claves:
2.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.
3. L.4. Ingenieria de requerimientos
3.1. definicion
3.1.1. de usuario son enunciados, en lenguaje natural de lo que se espera del sistema.
3.1.2. de sistema son descripciones de las funciones, servicios y restricciones de un sistema de software.
3.2. requerimientos funcionales y no funcionales
3.2.1. funcionales
3.2.1.1. enunciados acerca del servicio que el sistema debe proveer, reaccionar frente a entradas. tambien dice los que no debe hacer
3.2.2. no funcionales
3.2.2.1. requerimientos que no se relacionan directamente con el servicio. ej fiabilidad, tiempo de respuesta y uso de almacenamiento.
3.2.2.2. clasificacion
3.2.2.2.1. requerimiento del producto (restringen el comportamiento del software)
3.2.2.2.2. requerimiento de la organizacion (politicas y procedimientos de la organizacion)
3.2.2.2.3. requerimientos externos (regulatorios)
3.3. documento de requerimientos de software
3.3.1. definicion
3.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.
3.3.2. estructura
3.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
3.4. especificaciones de requerimientos
3.4.1. es el proceso de escribir los requierimientos de usuario y de sistemas
3.4.2. formas de escribir
3.4.2.1. enunciado en lenguaje natural (Es expresivo, intuitivo y universal)
3.4.2.2. lenguaje natural estructurado (estandar)
3.4.2.3. lenguajes de descripcion de diseño
3.4.2.4. anotaciones graficas (UML)
3.4.2.5. especificaciones matematicas.
3.5. proceso de ingenieria de requisitos
3.5.1. estudio de factibilidad, adquisicion y analisis, especificacion y valoracion
3.6. adquisicion y analisis de requerimientos
3.6.1. ciclo de vida
3.6.1.1. descubrimiento de requerimientos (recopilar informacion sobre el sistema)
3.6.1.2. clasificacion y organizacion de requerimientos
3.6.1.3. priorizacion y negociacion de requerimientos
3.6.1.4. especificacion de requerimientos
3.6.2. entrevistas
3.6.2.1. cerradas (preguntas preestablecidas)
3.6.2.2. abiertas (no tiene agenda predefinida)
3.6.3. escenarios
3.6.3.1. bosquejos de la descipcion de requerimiento
3.6.4. caso de uso
3.6.4.1. son una tecnica de descubrimiento de requerimientos. identifica actores y tipo de interaccion.
3.6.4.2. diagrama de caso de uso a alto nivel
3.6.5. etnografia
3.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
3.6.5.2. requerimiento
3.6.5.2.1. forma en que trabaja la gente
3.6.5.2.2. cooperacion y conocimiento de las actividades de otras personas
3.6.5.3. generacion de prototipos
3.6.6. validacion de requerimientos
3.6.6.1. es un proceso de verificar que los requerimientos definan el sistema que quiera el cliente.
3.6.6.2. comprobaciones
3.6.6.2.1. de validez
3.6.6.2.2. de consistencia (no debe haber conflicto)
3.6.6.2.3. de totalidad
3.6.6.2.4. de realismo
3.6.6.2.5. verificabilidad (reducir conflicto entre cliente y contratista)
3.6.6.3. tecnicas
3.6.6.3.1. revision de requerimientos
3.6.6.3.2. creacion de prototipos
3.6.6.3.3. generacion de casos de prueba
3.6.7. administracion de requerimientos
3.6.7.1. nuevo requiermiento por mejoras
3.6.7.1.1. ambientales empresariales
3.6.7.1.2. individuos que pagan por un sistema y los usuarios por otros
3.6.7.1.3. empresas grandes con usuarios diversos
3.6.7.2. planeacion
3.6.7.2.1. identificar el requerimiento
3.6.7.2.2. proceso de administracion de cambios (conjunto de actividades qeu valuan efecto y costo de los cambios)
3.6.7.2.3. politicas de seguimiento
3.6.7.2.4. implementacion del cambio
3.7. puntos importantes
3.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.
4. L.5. Modelado de sistema
4.1. introduccion
4.1.1. definicion
4.1.1.1. es el proceso para desarrollar modelos abstractos de un sistema, repesentacion grafica notaciones en el lenguaje de modelado unificado (UML)
4.1.2. perspectiva
4.1.2.1. externa
4.1.2.2. interaccion
4.1.2.3. estructural
4.1.2.4. comportamiento
4.1.3. diagramas
4.1.3.1. diagrama de actividad (actividad del proceso)
4.1.3.2. diagrama de caso de uso (interacciones entre un sistema y su entorno)
4.1.3.3. diagrama de secuencias (interacciones entre los actores y el sistema)
4.1.3.4. diagrama de clases (clases de objeto y asociaciones)
4.1.3.5. diagrama de estados (reaccion frente a eventos)
4.2. modelo de contexto
4.2.1. frontera del sistema, funcionalidad que se incluira en el sistema y cual no
4.3. modelo de interaccion
4.3.1. interacciones
4.3.1.1. usuario sistema
4.3.1.2. sistema y otros sistemas
4.3.1.3. entre componentes del sistema
4.3.2. modelado
4.3.2.1. casos de uso
4.3.2.1.1. simple escenario de los que el usuario espera del sistema
4.3.2.2. diagrama de secuencias
4.3.2.2.1. sucesion de interacciones entre los actores y los objetos del sistema
4.4. modelo estructurales
4.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.
4.4.2. diagrama de clases
4.4.2.1. clases y sus asociaciones
4.4.2.1.1. 1. El nombre de la clase de objeto está en la sección superior.
4.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.
4.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.
4.4.3. generalizacion
4.4.3.1. cada entidad se agrupa en una clase mas general
4.5. modelos de comportamiento
4.5.1. modelos dinamicos del sistema conforme se ejecutan, responde a estimulos
4.5.2. modelado dirigido por datos
4.5.2.1. secuencia de acciones de datos de entradas y salidas
4.5.2.2. DFD diagrama de flujo de datos (funcion o proceso)
4.5.3. modelado dirigido por un evento
4.5.3.1. como responde el sistema a eventos externos e internos
4.5.3.2. diagramas de estado (estado y eventos) (estado / estimulo)
4.6. ingenieria dirigida por modelo
4.6.1. es un enfoque donde los modelos son las salidas principales del proceso
4.7. puntos claves
4.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.
5. L.7. Diseño e implementacion
5.1. introduccion
5.1.1. se desarrolla un sistema de software ejecutable.
5.2. diseño orientado a objetos con el uso de UML
5.2.1. contecto e intaccion del sistema
5.2.1.1. modelo de contexto
5.2.1.2. modelo de interaccion
5.2.2. diseño arquitectonico
5.2.2.1. identificar principales componentes del sistema e interacciones. luego organice en modelo de capas o cliente servidor
5.2.3. identificacion de clase de objetos
5.2.3.1. aumenta la comprension del sistema. diagrama de clases.
5.2.4. modelos de diseño
5.2.4.1. tipos
5.2.4.1.1. modelos estructurales
5.2.4.1.2. modelos dinamicos (diagrama de secuencia)
5.2.5. especificacion de interfaz
5.2.5.1. diagrama de clases
5.3. Patrones de diseño
5.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.
5.4. conflictos de implementacion
5.4.1. aspectos importantes
5.4.1.1. reutilizacion
5.4.1.1.1. niveles
5.4.1.2. administracion de configuracion
5.4.1.2.1. gestion de versiones
5.4.1.2.2. integracion de sistema
5.4.1.2.3. rastreo de problemas
5.4.1.3. desarrollo huesped objetivo
5.4.1.3.1. requerimiento de hardware y software de un componente
5.4.1.3.2. requerimientos de disponibilidad de sistema
5.4.1.3.3. comunicaciones de componentes
5.5. desarrollo de codigo abierto
5.5.1. licencias de codigo abierto
5.5.1.1. gratuitas reciprocas
5.5.1.2. gratuitas, con componentes q no tiene necesidad de publicarlas
5.5.1.3. licencia no reciprocas
5.6. puntos claves
5.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.
6. L.3. Desarrollo agil de software
6.1. caracteristicas
6.1.1. proceso especificacion, diseño e implementacion se entrelazan
6.1.2. sistema se desarrolla en diferentes versiones
6.1.3. interfaz se desarrolla usando una elaboracion interativo
6.2. dificultades
6.2.1. disponibilidad de usuario
6.2.2. personalidad de equipo
6.2.3. priorizar cambios extremadamente dificil
6.2.4. mantener la simplicidad requiere trabajo adicional
6.2.5. cambios de cultura
6.3. programacion extrema
6.3.1. pruebas
6.3.1.1. primera prueba
6.3.1.2. desarrollo de pruebas incrementales
6.3.1.3. involucramiento de usuarios
6.3.1.4. pruebas automatizadas
6.4. programacion en pares
6.5. administracion de un proyecto agil
6.5.1. planeacion de bosquejo y diseño
6.5.2. sprint: valoracion, seleccion, desarrollo, revision.
6.5.3. cierre del proyecto
6.6. puntos claves
6.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.
7. A. Desarrollamos software de calidad
7.1. El software: Un producto ubicuo, indispensable y vital
7.2. La Naturaleza del Software
7.2.1. dif vs productos clasicos
7.2.1.1. sofware se desarrolla o modifica con intelecto
7.2.1.2. el calculo de costo es distinto
7.2.1.3. construccion basada en componentes vs uso personal
7.2.1.4. el software no se desgasta
7.3. Problemas al desarrollar
7.3.1. demora mucho tiempo en desarrollar software
7.3.2. los costos de desarrollo son altos, mayores a la estimacion inicial
7.3.3. es imposible encontrar todos los errores en las pruebas
7.3.4. se gasta mucho tiempo y esfuerzo en mantenimiento.
7.3.5. es dificil medir el avance
7.4. Proceso de desarrollo
7.4.1. procedimientos
7.4.1.1. definicion inicial (def del proyecto)
7.4.1.2. analisis de los requerimientos y su vialidad (requisito del usuario)
7.4.1.3. diseño general y detallado (se detallan req)
7.4.1.4. codificacion
7.4.1.5. pruebas (encontrar errores)
7.4.1.6. implementacion (puesta en marcha)
7.4.1.7. mantenimiento (correctivo y continuo)
7.4.2. Protectoras de calidad
7.4.2.1. Segumiento y control del proyecto de software (evalua proceso vs plan)
7.4.2.2. administracion de riesgos (evalua riesgos)
7.4.2.3. Aseguramiento de calidad de software
7.4.2.4. Revisiones tecnicas (evalua -> eliminar errores en cada etapa)
7.4.2.5. Mediciones y metricas (defini y reune mediciones del proceso, proyecto y producto)
7.4.2.6. Adm. de la configuracion de software (cambios)
7.4.2.7. Adm. de la reutilizacion
7.4.2.8. Preparacion y produccion del producto de trabajo (modelos, documentos, etc)
8. A. Clave de un relevamiento exitoso
8.1. Tres conceptos claves
8.1.1. Adecuada comprension del requemiento
8.1.2. empezar a construir sin haber comprendido la problematica puede ser un error. se soluciona con prototipos
8.1.3. las tareas deben adaptarse segun el proyecto
8.2. componentes de cada etapa
8.2.1. Concepcion (idea basica de problema, personas que lo requieren)
8.2.2. Indagacion (definiciones: ambitos (dentro o fuera), entendimiento y volatilidad (demanda en el tiempo)
8.2.3. Elaboracion (diagramas)
8.2.4. Negociacion (problemas no detectados, renegociar condiciones y plazo)
8.2.5. Especificacion (producto final de esta etapa. describe funciones, desempeño y restricciones. escribe conjunto de modelos)
8.2.6. Validaciones (revision tecnica. requerimientos realistas y validos)
8.2.7. Adm. de los requerimiento (cambios)
8.3. Problemas
8.3.1. habituales
8.3.1.1. usuarios no tienen claro lo que desean
8.3.1.2. ocultan informacion. miedo a perder trabajo
8.3.1.3. no se involucran
8.3.1.4. nuevos requerimiento finalizado el relevamiento
8.3.1.5. no comprenden problemas tecnicos
8.3.1.6. terminologia ambigua
8.3.1.7. relevamiento parcial
8.3.1.8. encajar sistemas en procesos
8.3.1.9. no todas ideas / pedidos deben llevarse a cabo
8.3.1.10. ideas de diseñadores no son validas para usuario
8.3.1.11. no es facil encontra al usuario clave
8.3.2. habituales no considerado
8.3.2.1. organizacion desconoce realmente sus problemas
8.3.2.2. no se tiene en cuenta requerimiento ni pautas iniciales
8.3.2.3. usuarios y jefes no quieren implementar nuevo sistema
8.3.2.4. usuario ocultan o paralizan info
8.3.2.5. programador con duda, no siempre accede al usuario
8.3.2.6. usuarios son personas y reaccionan de modo diferente
8.3.3. escenarios hostiles
8.3.3.1. sistema viene impuesto de arriba
8.3.3.2. nueva tecnologia sin usuario clave para relevar
8.3.3.3. areas de sistemas se oponen a software ajeno
8.3.3.4. intereses opuestos entre dos o mas areas
8.3.3.5. hay intereses politicos / economicos opuestos.
8.3.4. mitos sobre relevamiento
8.3.4.1. primera etapa es el relevamiento (existen comunicacion inicial, estudio de factibilidad y plan y presupuesto)
8.3.4.2. usuarios claves son los jefes o los que mas conocen (buscar operario clasificados, evitar usuarios toxicos)
8.3.4.3. entrevistas deben seguir proceso formal (utilizar metodos informales o descontracturados)
8.3.4.4. cuanto mas profundo el relevamiento mejor entendido el problema (cantidad no es sinomino de calidad, aporte marginal)
8.3.4.5. Programadores no deben participar en relevamiento (puede ser beneficiosa)
8.3.5. Enfoque alternativo
8.3.5.1. hay personas del otro lado
8.3.5.2. ingenieria de requerimiento vs relevamiento (buscar en vez de que aparezca)
8.3.5.3. aprovechar el primer encuentro (se establecen lazos de confianza)
9. A. Modelo para desarrolo de software
9.1. Enfoque clasico
9.1.1. analisis (relevamiento)
9.1.2. diseño (solucion informatica)
9.1.3. codificacion
9.1.4. prueba
9.1.5. puesta en marcha
9.2. Propuesta integral
9.2.1. Comunicacion inicial (primer contacto, lineamietno basicos y problemas)
9.2.2. estudio de factibilidad (se puede desarrollar o no, por costo, por solucion, etc)
9.2.3. plan y presupuesto (estimar recursos humanos, software y de entorno)
9.2.4. Construccion de la aplicacion usando un modelo (abarcan etapas de analisis, diseño, codificacion, pruebas y puesta en marcha)
9.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.
9.2.6. garantia (etapa que solucione errores, se debe incluir en los costos del proyecto)
9.2.7. mantenimiento (necesidad de cambios o mejoras)
9.3. Distintos problemas y sistemas, distintos modelos
9.3.1. tamaño de software a desarrollar (empresas grandes distintas a chicas)
9.3.2. complejidad para obtener requerimiento
9.3.3. complejidad tecnica (equipos, maquinas industriales)
9.3.4. tiempo disponible (cuanto tardara)
9.3.5. riesgo (perdida de apoyo politico, personal, presupuesto)
9.4. Modelo linea secuencial
9.4.1. etapas: ingenieria de requerimientos (busqueda activa), diseño, codificacion, prueba, despliegue
9.4.2. ventajas
9.4.2.1. modelo simple, sensillo y probado.
9.4.2.2. para proyectos sencillos es modelo menos costoso y mas rapido
9.4.3. desventajas
9.4.3.1. rara vez sigue tan secuencial
9.4.3.2. errores en primera etapa se arrastran hasta el final
9.4.3.3. estado de bloqueo por secuencia
9.4.3.4. es dificl que el cliente especifique todos los requerimientos al inicio
9.4.3.5. cliente no ve el software hasta que no este terminado
9.5. Modelo lineal secuencial interativo o incremental
9.5.1. entregar sistema de partes, primera version y se agregan funcionalidades (modulos)
9.5.2. ventajas
9.5.2.1. entregas parciales reducen complejidad de proyecto y mejoran estimaciones
9.5.2.2. usuarios reciben version rapidamente
9.5.2.3. menos personal concurrente
9.5.2.4. implementaciones parciales mas sencillas
9.5.3. desventajas
9.5.3.1. sigue siendo un esquema secuencial
9.5.3.2. errores de primera etapa se arrastran
9.5.3.3. estados de bloqueos
9.6. Modelo de prototipos
9.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.
9.6.2. etapas: relevamiento rapido, diseño de prototipo, generacion del prototipo, prueba, despliegue y retroalimentacion, contruccion de la aplicacion utilizando un modelo.
9.6.3. ventajas
9.6.3.1. mejor definicion y comprension de requerimientos iniciales
9.6.3.2. permite un testeo de funciones complejas
9.6.3.3. reduce incertidumbre
9.6.4. desventajas
9.6.4.1. el cliente puede tentarse de utilizar el prototipo
9.6.4.2. desarrolladores tentados de entregar como producto final
9.6.4.3. funcionalidad vistas en prototipo no esten en version final
9.7. Modelo en espiral
9.7.1. suceso recorriendo distintas etapas produciendo versiones operativas del software en cada vuelta
9.7.2. etapas: ingenieria de requerimiento, diseño, analisis de riesgos (via de escapa), codificacion, prueba, despliegue
9.7.3. Ventajas
9.7.3.1. entrega sucesivas y analisis de riesgos, apto para desarrollos riesgosos y con incertidumbre
9.7.3.2. puede utilizarse en todo el ciclo de vida
9.7.4. desventajas
9.7.4.1. no es simple medir riesgos
9.7.4.2. el cliente no entiende que el final fue planificado
9.7.4.3. resulta mas caro que otros modelos.
9.8. Modelo de desarrollo rapido de aplicaciones
9.8.1. utilizacion de herramientas RAD (rapid application development), construir en 30 a 90 dias.
9.8.2. etapas: ingenieria de requerimiento, diseño, codificacion, prueba, despliegue
9.8.3. ventajas
9.8.3.1. tiempo de desarrollo se acotan
9.8.3.2. reduce tiempo de pruebas y errores no dectados
9.8.3.3. sistemas portables o facil migracion entre entornos y sistemas operativos
9.8.4. desventajas
9.8.4.1. cliente debe asignar disponibilidad
9.8.4.2. no todos los proyectos son aptos para RAD
9.8.4.3. menor performance y mayor consumo de recursos
9.8.4.4. complicada implementacion en proyectos grandes, requiere mucho personal
9.9. Otros modelos
9.9.1. basado en componentes
9.9.1.1. reutilizacion de software y ensamble de componentes existentes
9.9.2. metodos formales
9.9.2.1. modelos matematicos para evitar errores
9.10. Eleccion de un modelo adecuado
9.10.1. problemas a resolver
9.10.1.1. tamaño (sistemas chicos -> modelo lineal, sistemas grandes -> modelo evolutivo)
9.10.1.2. complejidad de los requerimientos (prototipo)
9.10.1.3. complejidad tecnica (complejas -> prototopo, evaludar riesgos -> espiral)
9.10.1.4. tiempos disponibles (desarrollo rapido de aplicaciones)
9.10.1.5. entornos riesgosos (modelo en espiral)
9.11. limitaciones
9.11.1. requerimientos se plantean de antemano y no permite cambios
9.11.2. existe escasa participacion de usuarios
9.11.3. cronograma son definidos de antemano
9.11.4. ciclo de desarrollo demasiado extenso para determinadas organizaciones
9.11.5. documentacion y procesos formales no siempre bienvenidos
9.11.6. solucion: modelos agiles
10. A. Desarrollo Agil
10.1. comparacion agil vs tradicionales
10.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
10.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.
10.1.3. Tradicional: organizaciones con entornos estables
10.1.4. agil: entornos cambiantes
10.2. Metodo agil
10.2.1. Definicion:
10.2.1.1. Documento sobre tecnicas y procesos para desarrollar software
10.2.2. principios
10.2.2.1. satisfaccion de cliente con entrega temprana
10.2.2.2. son bienvenidos los requisitos cambiantes
10.2.2.3. entregar software que funcione en periodos cortos
10.2.2.4. personas del negocio trabajan en el negocio
10.2.2.5. individuos motivados
10.2.2.6. conversaciones cara a cara
10.2.2.7. software que funciona es la principal medida de progreso
10.2.2.8. promueven el desarrollo sostenido
10.2.2.9. atencion continua mejora agilidad
10.2.2.10. simplicidad
10.2.2.11. equipos auto organizados
10.2.2.12. equipo reflexiona y ajusta conducta
10.2.3. Valores
10.2.3.1. individuos e interacciones sobre procesos y herramientas (recurso humano como factor de exito)
10.2.3.2. software funcionando sobre documentacion extensa (agil documentacion necesaria)
10.2.3.3. colaboracion con el cliente sobre negociacion contractual (cliente participacion constante)
10.2.3.4. respuesta ante el cambio sobre seguir un plan (planificacion flexible)
10.3. Programacion extrema
10.3.1. definicion
10.3.1.1. metodo agil, con buenas practicas de programacion, liberacion frecuente, potencia las relaciones interpersonales, promoviendo el trabajo en equipo.
10.3.2. valores
10.3.2.1. simplicidad (en el diseño)
10.3.2.2. comunicacion
10.3.2.3. retroalimentacion
10.3.2.4. coraje (programar para hoy, deshacerse de un codigo inutil)
10.3.2.5. respeto
10.3.3. Practicas
10.3.3.1. planeacion incremental (tarjetas de historia, y se liberan)
10.3.3.2. liberaciones pequeñas (libera minimo de funcionalidad, luego se agregan)
10.3.3.3. diseño simple (cubrir requerimientos actuales)
10.3.3.4. Refactorizacion (optimizar codigo)
10.3.3.5. programacion en pares (uno programa el otro comprueba)
10.3.3.6. propiedad colectiva (no pertenece a 1 persona)
10.3.3.7. integracion continua (integrar y probar sistema)
10.3.3.8. ritmo sustentable (gran cantidad de tiempo no es optimo)
10.3.3.9. cliente en sitio
10.3.4. Ciclo de vida
10.3.4.1. historia -> desglosar historia -> planear libercion -> desarrollar integrar -> liberacion -> evaluar sistema -> inicio
10.3.5. pruebas en xp
10.3.5.1. caracteristicas
10.3.5.1.1. desarrollo en la primera prueba (escribo y pruebo)
10.3.5.1.2. des. pruebas incrementales a partir de escenario (pruebas de aceptacion)
10.3.5.1.3. involucramiento del usuario (pruebas de cliente)
10.3.5.1.4. uso de marcos de pruebas automatizadas (para primera prueba)
10.3.6. Programacion en pares
10.3.6.1. uno codifica el otro trata de mejorarlo (coductor y acompañante)
10.3.6.2. ventajas
10.3.6.2.1. apoya la idea de la propiedad y responsabilidad colectiva
10.3.6.2.2. actua como revision informal
10.3.6.2.3. ayuda a la refactorizacion
10.3.6.2.4. enseñanza
10.3.6.2.5. multiples desarrolladores constituyen al diseño
10.3.6.2.6. mayor disciplina
10.3.7. ventajas
10.3.7.1. se adapta a desarrollos pequeños y grandes
10.3.7.2. optimiza tiempo de desarrollo
10.3.7.3. comparte conocimiento
10.3.7.4. codigo simple y entendible
10.3.8. desventajas
10.3.8.1. no tiene definicion de costo y tiempo
10.3.8.2. precencia constante del usuario
10.3.8.3. desarrolladores celosos del codigo
10.4. Scrum
10.4.1. Proceso
10.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
10.4.2. caracteristicas
10.4.2.1. sprint tienen longitud fisica (2 a 4 semanas)
10.4.2.2. punto de partida es producto backlog (lista de trabajo)
10.4.2.3. fase de seleccion selecciona caracteristicas y funcionalidades
10.4.2.4. equipo desarrolla (reuniones breves diarias) se aisla del cliente y lo organiza el scrum master: protege al grupo de distracciones)
10.4.2.5. finaliza sprint, trabajo se revisa y se presenta.
10.4.2.6. fase de cierre concluye con la documentacion requerida (ayuda, manuales de usuario y lecciones aprendidas)
10.4.3. Principios
10.4.3.1. control de procesos empiricos: para la toma de decisiones: transparencia, inspeccion, adaptacion
10.4.3.2. auto organizacion
10.4.3.3. colaboracion (3 dimensiones: conciencia, articulacion y apropiacion)
10.4.3.4. priorizacion basada en el valor
10.4.3.5. time boxing (optimizacion de tiempo, reuniones)
10.4.3.6. desarrollo iterativo (satisfaccion de cliente)
10.4.4. Roles
10.4.4.1. Product owner (la voz del cliente)
10.4.4.2. equipo scrum (creacion de entregables)
10.4.4.3. scrum master (faculitador del equipo. guia facilita y les enseña)
10.4.4.4. cerdos (comprometido) gallina (involucrado)
10.4.5. ventajas
10.4.5.1. adaptabilidad
10.4.5.2. transparencia
10.4.5.3. retroalimentacion continua
10.4.5.4. mejoras continuas
10.4.5.5. entrega continua de valor
10.4.5.6. ritmo sostenible (al mismo ritmo)
10.4.5.7. motivacion
10.4.5.8. resolucion rapida de problemas
10.4.5.9. entregables efectivos
10.4.6. criticas
10.4.6.1. equipo subre estres
10.4.6.2. equipo toma camino mas corto
10.4.6.3. dificil en proyectos grandes
10.4.6.4. supone equipo motivado y formado
10.4.6.5. propone cliente involucrado
10.4.6.6. muchas reuniones diarias
10.5. ventajas desventeajas limitaciones
10.5.1. ventajas
10.5.1.1. rapida respuesta a cambios
10.5.1.2. clientes observan avance de proyecto
10.5.1.3. entregables parciales
10.5.1.4. reduce tiempos de costo y capacitacion
10.5.2. dificultades
10.5.2.1. cliente sigue con tareas operativas no proyecto
10.5.2.2. miembros no tienen personalidad adecuada (trabajo en equipo)
10.5.2.3. priorizar cambios es dificil
10.5.2.4. mantener simplicidad requiere un trabajo adicional
10.5.2.5. dificil implementar en empresas grandes
10.5.3. limitaciones
10.5.3.1. falta documentacion de diseño
10.5.3.2. problemas derivados de la comunicacion oral
10.5.3.3. los desarrollos no tienen la misma secuenciabilidad
10.5.3.4. restricciones por tamaño de proyecto, lugar geografico
10.5.3.5. contratos por tiempo insumido, dificil de administrar
10.6. conclucion
10.6.1. no es sinomino de rapido, con errores, y sin calidad.
10.6.2. indica acotar procesos tradicionales.
10.6.3. no implica
10.6.3.1. aucencia de documentacion, suprimir etapas, todo rapido (sin calidad), dejar las actividades protectoras
11. L.6. Diseño arquitectonico
11.1. decisiones
11.1.1. es un proceso creativo en el cual se diseña las funcionalidades que tendra el sistema.
11.1.2. no funcionales
11.1.2.1. rendimiento
11.1.2.2. seguridad
11.1.2.3. proteccion
11.1.2.4. disponibilidad
11.1.2.5. mantenibilidad
11.2. patrones arquitectonicos
11.2.1. arquitectura en capas
11.2.2. arquitectura de repositorio
11.2.3. arquitectura cliente servidor
11.2.4. arquitectura de tuberia y filtro
11.3. arquitecturas de aplicaciones
11.3.1. encapsulan las principales caracteristicas de una clase
11.3.2. formas de uso
11.3.2.1. punto de partida para el proceso de diseño arquitectonico
11.3.2.2. lista de verificacion de diseño
11.3.2.3. una forma de organizar el trabajo de equipo de desarrollo
11.3.2.4. un medio apra valorar los componentes de reutilizacion
11.3.2.5. un vocabulario para hablar acerca de los tipos de aplicaciones
11.3.3. sistema de procesamiento de transacciones
11.3.3.1. procesar peticiones contra la base de datos modificando datos.
11.3.4. sistemas de informacion
11.3.4.1. permite controlar gran parte de la informacion (idem arquitectura en capas)
11.3.5. sistema de procesamiento de lenguaje
11.3.5.1. convierte lenguaje natural en programacion
11.4. puntos claves
11.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.
12. L.8.Prueba de software
12.1. etapas
12.1.1. prueba de desarrollo (a medida que escribe el codigo)
12.1.2. versiones de pruebas (version completa antes de pasarselo a los usuarios)
12.1.3. prueba de usuario
12.2. puntos claves
12.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.