UNIDAD 1: Los sistemas de informacin

Propiedades de los sistemas

Todo elemento es necesario , para el objetivo del sistema.
Ninguna parte tiene un efecto independiente sobre el todo y cada una es afectada por lo menos por otra parte.
Un sistema no puede subdividirse en subsistemas independientes.
El comportamiento de un sistema est determinado tanto por las caractersticas de las partes que lo componen como por
la interconexin de las mismas(de su interaccin).

Foco de atencin: Elemento que se aisla para estudiar. En sistema lmite de inters o lmite de sistema-
Foco de anlisis: de los elementos que quedan fuera del lmite solo interesar la interaccin que tengan con el sistema, es decir
las entradas que provean y las salidas que utilicen.
Contexto del sistema: Conjunto de elementos que quedaron fuera del lmite del sistema pero que tienen relacin con l.

Procesamiento: situamos los datos en un contexto determinado o complementamos su significado incompleto .

Utilidad o significacin: la informacin estimula a la accin y su valor reside en que permite decidir mejor.

Transacciones:
Los procedimientos de tratamiento se comprenden bien y se pueden describir en detalle.
Aparecen pocas excepciones a los procedimientos normales.
Hay un gran volumen.
Existe gran similitud entre ellas.

Ciencia: Estudia para conocer, el objetivo es el conocimiento. Establece la idea, el concepto.

Ingeniera: Conoce para trabajar, el objetivo es la produccin.

Ingeniera del software:

Es una disciplina que comprende todos los aspectos de la produccin del software desde las etapas iniciales de la
especificacin del sistema hasta el mantenimiento de este despus de que se utiliza.
No solo comprende los procesos tcnicos del desarrollo de software, sino tambin con actividades tales como la gestin
de proyectos de software y el desarrollo de herramientas, mtodos y teoras de apoyo a la produccin de sw.
UNIDAD 2: Procesos de desarrollo de sistemas de informacin

Problema:
El problema suele tener explcita o implcitamente la forma de una pregunta, pero no toda pregunta es necesariamente un
problema.
Es una situacin de necesidad o una realidad insatisfactoria que requiere ser transformada.
La solucin de un problema implica analizar la situacin, los recursos disponibles, el costo, las estrategias de accin, los
procedimientos, la toma de decisiones y la materializacin de la solucin.

Proyecto:
Es un conjunto de etapas, actividades y tareas para alcanzar un objetivo que implica un trabajo no inmediato, a un plazo
relativamente largo.
Implica un principio y un final
Utiliza diversos recursos finitos y cuenta con un presupuesto.
Sus actividades son nicas y esencialmente no repetitivas.
Tiene un objetivo.
Requiere un jefe de proyecto y personal de desarrollo, cuyos roles y estructura de equipo deben definirse y desarrollarse.
Tiene que planificarse.
Debe medir su progreso frente al plan.
Suele coexistir con otros proyectos y competir por los recursos.
Existen fuerzas internas y externas, que deben identificarse y tratarse, que influyen en l.
Es un emprendimiento temporal con el objetivo de crear un producto o servicio nico.
Temporal: que tiene un comienzo definido y un fin definido, se alcance o no los objetivos.
nico: significa que el producto o servicio es diferente de alguna forma a cualquier otro producto o servicio.
Comienzan por problemas, oportunidades o requerimientos del negocio.

Alcance: es todo el trabajo que se desee realizar con el de que el cliente quede satisfecho con el producto o servicio y se
cumplan los criterios de aceptacin acordados al inicio del proyecto.

Visin:
Proyeccin a cinco aos.
Es el foco al cual dirigir todos nuestros esfuerzos y recursos.
Que productos se podrn ltimamente obtener en un mundo perfecto.
Misin:
Resume para qu estamos en este mundo.
El alcance del proyecto define los conceptos y rasgos de la solucin propuesta.
Las limitaciones identifican ciertas capacidades o funciones que el sistema no va a incluir.

Pasos para resolver problemas: Pasos en sistemas de informacin

a. Determinar el problema y sus asociados.
b. Conocer las causas del problema.
c. Redefinir el problema.
d. Proponer soluciones.
e. Evaluar y seleccionar soluciones.
Analizar el sistema de informacin.
Estudio de viabilidad.
Captura de anlisis de requerimientos.
Disear el sistema de informacin.

f. Planear la operacin y ponerla en marcha. Desarrollar(codificar) e implementar el sistema de informacin.

g. Evaluar los resultados. Probar y mantener sistemas de informacin.

Objetivos de los procesos :

Aceleracin de un proceso.
Optimizacin de un proceso al eliminar pasos innecesarios o duplicados.
Combinacin de procesos.
Reduccin de errores en la captura de informacin mediante la modificacin de formularios y pantallas de despliegue.
Reduccin de almacenamiento redundante.
Reduccin de salidas redundantes.
Mejora en la integracin de sistema y subsistemas.
Objetivos corporativos:
Mejora de las ganancias corporativas.
Apoyo a la estrategia competitiva de la organizacin.
Mayor cooperacin(operaciones conjuntas) con socios y distribuidores.
Incremento del apoyo a las operaciones internas con el fin de producir bienes y servicios de manera eficaz y ms eficiente
Incremento al apoyo a la toma de decisiones internas para que estas sean ms eficaces.
Mejora del servicio al cliente.
Incremento en la moral de los empleados.

Desarrollo de sistemas:
Definicin
Desarrollo
Mantenimiento

Viabilidad:
No es una decisin a cargo del anlisis de sistema sino de los directivos de la organizacin.
Es til para desechar los proyectos que se contraponen con los objetivos de la organizacin, que desde el punto de vista
tcnico no son factibles y que no ofrecen un aliciente econmico.

Estudio de viabilidad:
La entrada es una descripcin resumida del sistema y de cmo ste pretende contribuir a los procesos del negocio.
Los resultados deberan ser un informe que recomiende si merece o no la pena seguir con la ingeniera de requerimientos
y el proceso de desarrollo del sistema.

Metodologa:
Define quin debe hacer qu, cundo y cmo debe hacerlo.
Elementos: Actividades, personas, proceso de sw, herramientas, roles, artefactos y notacin.

Riesgo:
Es un problema que todava no lleg.
Implica dos caractersticas: Incertidumbre y prdida.
Pueden ser del proyecto, del producto y del negocio
Riesgo del proyecto: afectan a la planificacin o a los recursos.
Riesgo del producto: afectan a la calidad o al desempeo del software.
Riesgo del negocio: afectan a la organizacin que desarrolla el software
UNIDAD 3: Identificacin de los requerimientos del sistema

Fuentes de datos:
Stakeholders: clientes, usuarios, expertos del dominio.
Documentos del universo de discurso
Documentos externos al universo de discurso
Software interno/externo

Modalidad de la entrevista:
Dirigidas o estructuradas.
No estructuradas o libres o de inicio y final abierto.

Embudo: aborda el conocimiento por deduccin . Mtodo por el cual se precede lgicamente de lo universal a lo particular.

Pirmide: aborda el conocimiento por induccin. Extraer a partir de determinadas observaciones o experiencias particulares, el
principio general que en ellas est implcito.

Rombo: comienzan con una pregunta especfica, pasan hacia preguntas generales y terminan con una pregunta especfica.

Entrevista estructurada:
Asegura la elaboracin uniforme de las preguntas para todos los que van a responder
Fcil de administrar y evaluar.
Evaluacin ms objetiva tanto de quienes responden como de las respuestas a las preguntas.
Se necesita un limitado entrenamiento del entrevistador.
Resulta en entrevistas ms pequeas.
Alto costo de preparacin.
Los que responden pueden no aceptar un alto nivel en la estructura y carcter mecnico de las preguntas.
Un alto nivel en la estructura puede no ser adecuado para todas las situaciones.
El alto nivel en las estructuras reduce responder en forma espontnea, as como la habilidad del entrevistador para
continuar con comentarios hacia el entrevistado.

Entrevista no estructurada:
El entrevistador tiene mayor flexibilidad al realizar las preguntas adecuadas a quien corresponde.
El entrevistador puede explotar reas que surgen espontneamente durante la entrevista.
Puede producir informacin sobre rea que se minimizaron o en las que no se pens que fueran importantes.
Puede utilizarse negativamente el tiempo, tanto de quien responde como del entrevistador.
Los entrevistadores pueden introducir sus sesgos en las preguntas o al informar de los resultados.
Puede recopilarse informacin extraa.
El anlisis y la interpretacin de los resultados pueden ser largos.
Toma tiempo extra recabar los hechos esenciales.

Tipos de entrevistas
Iniciales o preliminares: Se realiza al cliente para determinar la visin que tiene l del sistema para as determinar los
aspectos de negocio que se tendrn en cuenta
De recoleccin de datos: Para adquirir conocimiento especfico, de grado fino. Investigacin detallada.
De seguimiento: Resuelven dudas, aclaran espacios en blanco de entrevistas anteriores. Son necesarias, no se las
puede evitar.

Proceso de la entrevista:
Definicin de objetivos: Qu informacin se desea obtener con la entrevista.
Planificacin: Tipo de preguntas y estructuras, A quin entrevisto?
Concrecin: Cita por anticipado. Se debe definir fecha, lugar, horario y duracin.
Realizacin: Presentacin/apertura, desarrollo, conclusin.
Evaluacin: Normalmente se realiza un informe de la entrevista y se enva al entrevistado para ver si es aceptado.
UNIDAD 4: Ingeniera de requerimientos

Requisito:
Una condicin o capacidad necesaria por un usuario para solucionar un problema o lograr un objetivo.
Una condicin o capacidad que debe cumplir o poseer un sistema o componente de un sistema para satisfacer un
contrato, estndar, especificacin u otro documento formalmente impuesto.
Es lo que el Software va a hacer para satisfacer los requerimientos del usuario.

Ingeniera de requisitos: Es el proceso sistemtica de desarrollar requerimientos a travs de un proceso cooperativo e iterativo
de analizar el problema, documentar las observaciones resultantes en una variedad de formatos de representacin y chequear la
precisin de la comprensin obtenida.

Requerimientos:
Son la descripcin de los servicios proporcionados por el sistema y sus restricciones operativas.
Un requerimiento es una restriccin al espacio de soluciones aceptables para un proyecto.
Es una condicin que debe ser cumplida por el resultado final de un proyecto para que ste sea considerado exitoso y/o
de calidad.
De su adecuada obtencin, administracin, anlisis y especificacin depende en gran medida el xito del proyecto y la
calidad del producto final.
Es lo que el usuario nos pide, lo que necesita.

Ingeniera de requerimientos: es el proceso de descubrir, analizar, documentar y verificar servicios y restricciones operativas del
sistema.

Descripcin de un requisito:
Una utilidad para el usuario.
Una propiedad general del sistema.
Una restriccin general del sistema.
Como llevar a cabo cierto clculo.
Una restriccin sobre el desarrollo del sistema.

Requerimientos del usuario:

Son requisitos de alto nivel, tambin denominados features o caractersticas cuando se trata de productos orientados al
mercado.
Enuncian una condicin que deber cumplir el sistema pero a un nivel de detalle insuficiente como para que a partir de l
pueda implementarse una solucin.

Requisitos funcionales:
Definen qu debe hacer un sistema.
Deben especificar el comportamiento externo del sistema.
Describen con detalle, los servicios o funciones que debe ofrecer el sistema(software) a los usuarios para alcanzar los
objetivos.
Tradicionalmente se han documentado como prrafos de texto libre.

Requisitos no funcionales:
Definen cmo debe ser el sistema.
Son condiciones que se le imponen al sistema a desarrollar relacionadas con aspectos principalmente de calidad,
usabilidad, rendimiento, disponibilidad, fiabilidad, seguridad, compatibilidad con hardware o software, etc.

Requisito del producto: especifican que el producto entregado debe comportarse de una manera determinada.

Requisitos organizacionales: son una consecuencia de las polticas y procedimientos organizacionales.

Requisitos externos: Surgen factores que son externos al sistema y su proceso de desarrollo.

Requisitos de informacin(almacenamiento):
Describen qu informacin debe almacenar el sistema para poder cumplir los objetivos de nivel superior.
Deben identificar el concepto relevante sobre el que se debe guardar informacin as como qu datos especficos
relativos al concepto son importantes para cumplir los objetivos del sistema.

Ingeniera de requerimientos:
El proceso de RE no es un proceso lineal.
Conjunto de actividades que intentan entender las necesidades de los usuarios y traducirlas en afirmaciones precisas y
no ambiguas que se usarn en el desarrollo del sistema.
Ingeniera de requisitos(IR):
Conjunto de actividades de cuya ejecucin se obtiene, valida y mantiene el documento de requisitos del sistema.

Etapas de IR
Educcin de requisitos: Se basa en la captura y descubrimiento de los requerimientos. Es una activada ms humana
que tcnica.
Anlisis y negociacin de requerimientos del usuario: Se estudian los requerimientos obtenidos, a fin de poder
detectar, la presencia de reas no especificadas, requerimientos contradictorios, etc.
Anlisis
Clasificacin
Modelacin conceptual
Negociacin de requisitos
Documentacin de requisitos: Es el modo habitual de guardar y comunicar requisitos.
DRU: se escribe desde el punto de vista del usuario/cliente/interesado. Describe el dominio del problemas.
ERS: desarrolla mucho ms los contenidos del DRU. Describe el dominio de la solucin.
Verificacin y validacin de los requisitos del sw
GAP
UNIDAD 5: Modelado de los sistemas

Modelo:
Es representacin abstracta de la realidad, no tiene valor por si mismos y tiene un fin especfico, poniendo nfasis en
determinados aspectos.
Son utilizados para identificar los componentes y la interfaz de un sistema, es decir, para ver si nosotros entendimos lo
que el cliente necesita.
Debe ser grfico y con apoyo textuales
Deben ser posibles de verlos en forma segmentable (sucesivos refinamientos de detalles)
Deben ser minimamente redundantes (representar cada cosa en el nivel de detalle adecuado)
Deben ser transparente al lecto.
Deben tener poca simbologa diferente y reglas simple de escritura.

DFD:
Es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre s por
conductos y tanques de almacenamiento de datos.
Enfoca la atencin del lector en las funciones del sistema, sin permitir que las relaciones entre datos distraigan su
atencin.
Est compuesto por procesos o funciones, almacenes, terminadores y flujos de datos.
Los flujos representan datos en movimiento, mientras los almacenes representan datos en reposo.
DER:
Es un modelo de red que describe con un alto nivel de abstraccin la distribucin de datos almacenados en un sistema.
Enfoca la atencin en las relaciones entre datos sin permitir la distraccin del lector por las caractersticas funcionales.

DTE:
Enfatiza en comportamiento dependiente del tiempo del sistema.
Enfoca su atencin en la caracterstica del tiempo, sin permitir que el lector se distraiga con las funciones o los datos.
Los principales componentes son estados y flechas que representan los cambios de estados.

DD:
Es un listado organizado de todos los datos pertinentes al sistema con definiciones precisas y rigurosas, para que tanto
el usuario como el analista tengan un entendimiento comn de todas las entradas, salidas, componentes de almacenes y clculos
intermedios.
Describe el significado de los flujos y almacenes del DFD.
Describe la composicin de agregado de paquetes completos (Clientes) que pueden descomponerse en unidades ms
elementales (DNI, tel, etc.).
Describe la composicin de los paquetes de datos de los almacenes.
Especifica los valores y unidades de los flujos y almacenes (carcter, dgito, etc.).
Describe los detalles de las relaciones entre almacenes que se enfatizan en el DER.

Especificacin de procesos:
Es la descripcin de que es lo que sucede en cada burbuja primitiva de nivel ms bajo en un DFD.
Su propsito es definir lo que debe hacerse para transformar las entradas en salidas.
Es una descripcin detallada de la poltica de negacin del usuario que cada burbuja lleva a cabo.
Debe expresarse de manera que puedan verificar el usuario como el analista.
El proceso debe especificarse en una forma que pueda ser comunicada efectivamente al pblico amplio que se est
involucrando.
No debe imponer o implicar decisiones de diseo e implantaciones arbitrarias.

Lenguaje estructurado:
Es un lenguaje con estructura y su propsito es hacer un balanceo razonable entre la precisin del lenguaje formal de
programacin y la informalidad y legibilidad del lenguaje cotidiano.
Permite que se combinen frases en forma limitadas que se toman de la construccin acostumbrada de la programacin
estructurada, como ser: Si-entonces-otro, hacer-Mientras, repetir-hasta y caso.

Pre-condiciones:
Describen todas las cosas que deben darse antes de que el proceso pueda empezar a ejecutarse.
Que entradas se encuentran disponibles.
Que relacin debe existir entre las entradas.
Que relacin debe existir entre entradas y almacenes.
Que relacin debe existir entre diferentes almacenes o dentro de un almacn dado.

Post-condiciones:
Describen lo que debe darse cuando el proceso ha concluido, es como una garanta.
Las salidas que generar o producir el proceso.
Las relaciones que existirn entre los valores de salida y los de entrada.
Las relaciones que existirn entre los valores de salida y los valores en uno o varios almacenes.
Los cambios que se hayan dando en los almacenes.
UNIDAD 6: Metodologa de anlisis estructurado moderno

Modelo fsico actual:

Es un modelo del sistema que actualmente esta empleando el usuario.
El sist. puede ser manual o automatizado, o una mezcla de ambos.

Modelo lgico actual:

Es el modelo de los requerimientos puros o esenciales que realiza el sistema actual de usuario.
Este modelo muestra lo que el sistema hara si hubiera disponible una tecnologa perfecta.

Modelo lgico nuevo:

Es un modelo de los requerimientos puros o esenciales del sistema nuevo que el usuario quiere.
En el caso ideal es igual que el modelo lgico actual.
Esta situacin es factible si el usuario est completamente satisfecho con la funcionalidad del sistema actual, pero no con
su implantacin.
En la mayora de los casos el usuario pedir funciones adicionales.

Modelo fsico nuevo:

Es un modelo que muestra las limitaciones de implantacin impuestas por el usuario.
Una de las limitaciones ms importante es la determinacin de la frontera de automatizacin (funciones que se
automatizarn y las que no).

Modelo esencial:
Es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos de usuario, diciendo lo mnimo posible,
acerca de cmo se implantar.
Esto significa que el modelo supone que se tiene disponible una tecnologa perfecta.
Debe evitarse describir implantaciones especficas de procesos en el sistema.
El modelo esencial debe describir el contenido de los flujos o almacenes de datos, sin describir el medio u organizacin
fsica de los datos.

Modelo ambiental:
Define la interfaces entre el sistema y el resto del mundo, es decir modela el exterior del sistema.
Es importante saber que informaciones entran al sistema desde el ambiente exterior, y que informacin produce como
salida al ambiente externo.
Consiste en identificar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema, pero no a todos
los acontecimientos, sino a lo que necesitan una respuesta del sistema.

Declaracin de propsitos: Es una declaracin textual breve y concisa del propsito del sistema, dirigida al nivel administrativo
superior, la administracin de los usuarios, y otros que no estn directamente involucrados con el desarrollo del sistema.

Diagrama de contexto: Es un caso especial del DFD, en donde una sola burbuja representa todo el sistema.

Lista de acontecimientos: Es una lista narrativa de los estmulos que ocurren en el mundo exterior.

Ciclo de vida de la metodologa de Yourdon

Anlisis: Uso de herramientas de modelado y elaboracin de modelos.
Diseo: El diseador debe asegurar que los requerimientos del usuario se puedan implementar de manera real con
tecnologa computacional.
Modelo de procesadores: especificar HW y SW que requiere el sistemas.
Modelo de tareas: asignar HW y SW a las tareas.
Modelo de implantacin de programas: Muestra la organizacin jerrquica de mdulos dentro de una tarea.
Programacin y prueba: La programacin es implantar en algn lenguaje de programacin lo que el analista ha
especificado y el diseador especificado. Por su parte la prueba ejercita al sistema para asegurar que produzca las salidas
apropiadas y se comporte de manera esperada frente a los diversos estmulos de entrada
Mantenimiento: Conversin, instalacin y capacitacin.
UNIDAD 7: El paradigma de la orientacin a objetos

Clase: describa un conjunto de objetos del Contexto del Problema, que tienen las mismas caractersticas y el mismo
comportamiento.

Objeto: es una entidad del mundo real que tiene caractersticas (atributos) propiedades y cumple con determinadas funciones.

Comportamiento bien determinado: agrupa todas las competencias de un objeto y describe las acciones y reacciones de ese
objeto.

Estado interno que corresponde al conjunto de variables de instancia. Estas pueden hacer referencia a las propiedades
intrnsecas del objeto u otros objetos con los cuales pueda colaborar para llevar a cabo sus responsabilidades. Es privado del
objeto.

identidad: es nica y la distingue de otro y es independiente de cualquiera de sus caractersticas. Un objeto solo idntico a s
mismo.

Herencia: el mecanismo que permite definir una clase de objetos tomando como base la definicin de otra clase. La clase que
hereda las caractersticas de otra clase y la clase que da partida reciben los calificativos de subclase y superclase
respectivamente.

Encapsulamiento: es la cualidad que tienen los objetos de ocultar los detalles de implementacin y su estado interno del mundo
exterior.

Mensajes: el comportamiento de un objeto est definido en trminos de los mensajes que este entiende. Al enviarle un mensaje a
un objeto este responde activando el mtodo asociado a este mensaje.
Siempre se debe contar con dos objetos, un emisor y un receptor. El emisor enva un mensaje al receptor. El receptor recibe el
mensaje y busca entre sus mtodos aquel que coincida con el nombre del mensaje, si encuentra el mtodo correspondiente,
procede a ejecutarlo. El receptor deber retornar el objeto como resultado del envi del mensaje.
Para especificar un mensaje se debe asignarle un nombre e indicar cules son los parmetros requeridos para resolver el
mensaje.

Mtodos: es la contraparte funcional del mensaje. Expresa la forma de llevar a cabo la semntica propia de un mensaje particular
(el cmo). Un mtodo puede realizar tres cosas: modificar el estado interno, colaborar con otros objetos, retornar y terminar.

Polimorfismo: el mecanismo que permite definir e invocar funciones idnticas en denominacin e interfaz, pero con
implementacin deferente. El polimorfismo es posible gracias a la herencia.
Implica que el objeto que enva un mensaje no necesita conocer la instancia de la clase receptora.

Clase abstracta: es una clase que no se puede instanciar. Se usa nicamente para definir subclases. Se utilizan cuando
deseamos definir una abstraccin que englobe objetos de distintos tipos y queremos hacer uso del polimorfismo.
UNIDAD 8: Casos de uso

Caso de uso: es una forma de usar el sistema. El usuario interacta con el sistema interactuando con sus casos de uso.

Vista de casos de uso: captura el comportamiento del sistema, de un subsistema, o de una clase, tal como se muestra a un
usuario desde el exterior.

Actor
Un actor es una idealizacin de una persona externa, de un proceso, o de una cosa que interacta con el sistema.
Los actores son objetos que residen fuera del sistema, en tanto que los casos de uso son objetos que residen dentro del sistema.
Un actor participa en uno o ms casos de uso.
Un actor puede ser caracterizado por un conjunto de atributos que caracterizan su estado.
Los actores pueden ser definidos en jerarquas de generalizacin.
Un actor puede ser una persona, otro sistema informtico, o un proceso.

Clasificacin de Actores
Primarios: Inicia el caso de uso y obtiene beneficios.
Secundarios: Solo participa en forma pasiva, ayudando a otros actores a cumplir sus objetivos.

Caso de uso
Un caso de uso es una secuencia de transacciones realizadas por el sistema que brinda un resultado de valor a un actor en
particular.
Un caso de uso es una unidad coherente de funcionalidad, externamente visible, proporcionada por una unidad del
sistema y expresada por secuencias de mensajes intercambiados por el sistema y uno o ms actores.
El propsito del caso de uso es definir una pieza de comportamiento coherente, sin revelar la estructura interna del
sistema.

Capturan requerimientos funcionales del sistema:

El modelo de casos de uso define el comportamiento del sistema a travs de un conjunto de casos de uso. El entorno
del sistema es descrito por un conjunto de actores que usan el sistema a travs de los casos de uso.
El modelo de casos de uso es una vista externa del sistema, en tanto que los modelos de objetos son vistas internas del mismo.

Estructuran los modelos de objetos en vistas manejables:

Un objeto puede participar en varios casos de uso.
Pueden definirse todas las responsabilidades de un objeto viendo los roles en que participa en todos los casos de uso.
Cuando se implementan, los casos de uso son realizados mediante colaboraciones entre clases del sistema.
Una colaboracin es una realizacin de un caso de uso.

Caractersticas de los casos de uso

Estn expresados desde el punto de vista del actor
Se documentan con texto informal. Describe el qu y no el cmo.
Describen tanto lo que hace el actor, como lo que hace el sistema cuando interacta con l, aunque el nfasis est puesto
en la interaccin.
Un caso de uso es una clase.
Un escenario es una instancia de un caso de uso.
Son inicializados por un actor.

Generalizacin
Un caso de uso se puede especializar en uno o ms casos de uso hijos, utilizando una relacin de generalizacin.
La generalizacin se llama a veces relacin es-un-tipo-de: Un elemento es-un-tipo-de un elemento ms general.
Una clase hija, hereda las propiedades de sus clases padres.

Inclusin
Un caso de uso puede incluir en su comportamiento el comportamiento de otro caso de uso base a travs de una relacin de
inclusin.
Cuando varios casos de uso comparten descripciones similares, para evitar redundancia y maximizar la reutilizacin, se pueden
extraer dichas secuencias comunes. La relacin de inclusin es una relacin de dependencia entre casos de uso.

Extensin
Un caso de uso se puede definir como una extensin incremental de un caso de uso base.
Siempre se instancia un caso de uso base, en tanto que las extensiones son instanciadas bajo determinadas condiciones. No se
genera una instancia de una extensin.
Las extensiones modelan un comportamiento opcional del comportamiento obligatorio del caso de uso.

Casos de uso primario y secundario

Casos Primarios: Son aquellos que se corresponden con procesos del negocio.
Casos Secundarios: Son aquellos que no corresponden con procesos del negocio y cuya ejecucin solo es necesaria
para que el sistema funciones normalmente.
UNIDAD 10: Proceso unificado de desarrollo del software

RUP
El Proceso Unificado (RUP) es un proceso de desarrollo de software: conjunto de actividades necesarias para transformar
los requisitos del usuario en un sistema software.
RUP es un marco genrico que puede especializarse para una variedad de tipos de sistemas, diferentes reas de aplicacin,
tipos de organizaciones, niveles de aptitud y diferentes tamaos de proyectos.
RUP est basado en componentes. El software esta formado por componentes interconectados a travs de interfaces.
RUP est dirigido por casos de uso, centrado en la arquitectura, y es iterativo e incremental.

Dirigido por casos de uso

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos
de uso modelan los requerimientos funcionales del sistema.
Todos los casos de uso juntos constituyen el modelo de casos de uso.
Los casos de uso tambin guan el proceso de desarrollo.
Los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, avanza a travs de una
serie de flujos de trabajo que parten de los casos de uso.

Centrado en la arquitectura
La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construccin.
El concepto de arquitectura software incluye los aspectos estticos y dinmicos ms significativos del sistema.
Los casos de uso y la arquitectura estn profundamente relacionados. Los casos de uso deben encajar en la arquitectura, y
a su vez la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y a futuro.

Iterativo e incremental
Es prctico dividir el esfuerzo de desarrollo de un proyecto de software en partes ms pequeas o mini proyectos.
Cada mini proyecto es una iteracin que resulta en un incremento.
Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos a crecimientos en el producto.
Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y ejecutarse de una forma planificada.
Los desarrolladores basan la seleccin de lo que implementarn en cada iteracin en dos cosas: el conjunto de casos de uso
que amplan la funcionalidad, y en los riesgos ms importantes que deben mitigarse.

Beneficios del enfoque iterativo

La iteracin controlada reduce el riesgo a los costes de un solo incremento.
Reduce el riesgo de retrasos en el calendario atacando los riesgos ms importantes primero.
Acelera el desarrollo. Los trabajadores trabajan de manera ms eficiente al obtener resultados a corto plazo.
Tiene un enfoque ms realista al reconocer que los requisitos no pueden definirse completamente al principio.

El Ciclo de Vida del Proceso Unificado

El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una
versin del sistema.

Fases
Cada ciclo constas de cuatro fases: inicio, elaboracin, construccin, y transicin.
Cada fase se subdivide en iteraciones. En cada iteracin se desarrolla en secuencia un conjunto de disciplinas o flujos de
trabajos.

Disciplinas
Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un rea especfica dentro del
proyecto total. Las ms importantes son: Requerimientos, Anlisis, Diseo, Codificacin, y Prueba.

Cada disciplina est asociada con un conjunto de modelos que se desarrollan. Estos modelos estn compuestos por artefactos.
Los artefactos ms importantes son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseo,
modelo de implementacin, y modelo de prueba.

Hitos
Cada fase finaliza con un hito.
Cada hito se determina por la disponibilidad de un conjunto de artefactos.
Un conjunto de modelos o documentos que han sido desarrollados hasta alcanzar un estado predefinido.
Los hitos tambin permiten controlar la direccin y progreso del trabajo.
Fase de Inicio
Durante la fase de inicio se desarrolla una descripcin del producto final, y se presenta el anlisis del negocio.
En esta fase se identifican y priorizan los riesgos mas importantes.
El objetivo de esta fase es ayudar al equipo de proyecto a decidir cuales son los verdaderos objetivos del proyecto.
La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida.

Fase de Elaboracin
Durante la fase de elaboracin se especifican en detalle la mayora de los casos de uso del producto y se disea la
arquitectura.
El resultado de esta fase es la lnea base de la arquitectura.
La fase de elaboracin finaliza con el hito de la Arquitectura del Ciclo de Vida.

Fase de Construccin
Durante la fase de construccin se crea el producto. La lnea base de la arquitectura crece hasta convertirse en el sistema
completo.
La fase de construccin finaliza con el hito de Capacidad Operativa Inicial.

Fase de Transicin
La fase de transicin cubre el perodo durante el cual el producto se convierte en la versin beta.
Las iteraciones en esta fase continan agregando caractersticas al software. Sin embargo las caractersticas se
agregan a un sistema que el usuario se encuentra utilizando activamente.
El equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del sistema desarrollado en la
fase anterior.
La fase de transicin finaliza con el hito de Lanzamiento del Producto.

Un proceso conducido por casos de uso

La primera disciplina que se desarrolla dentro de cada iteracin es la de requerimientos (posiblemente luego de realizar
un modelado del dominio o del negocio). El objetivo de esta fase es determinar los requerimientos del sistema. Los
requerimientos funcionales son plasmados a travs de casos de uso en un Modelo de Casos de Uso.
Para cada caso de uso debe especificarse sus caminos o secuencias de acciones posibles.
Los casos de uso tambin se utilizan como contenedores para los requisitos no funcionales.
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante, representan
requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso, el cual describe la funcionalidad
total del sistema. Los casos de uso no son solo una herramienta para especificar los requisitos de un sistema, tambin guan su
diseo, implementacin, y prueba; esto es, guan el proceso de desarrollo.
Basndose en el modelo de casos de uso, los desarrolladores crean una serie de modelos de diseo e implementacin que llevan
a cabo los casos de uso. Dirigido por casos de uso quiere decir que el proceso de desarrollo sigue un hilo (avanza a travs de
una serie de flujos de trabajo que parten de los casos de uso). Los casos de uso finales son la fuente a partir de la cual los
ingenieros de prueba constituyen sus casos de prueba.

Creacin del modelo de anlisis a partir de los casos de uso

El modelo del anlisis es opcional. En l, se describen un conjunto de Clases del Anlisis que se utilizan para realizar una
descripcin abstracta de la realizacin de los casos de uso del modelo de casos de uso.
El modelo de anlisis crece incrementalmente a medida que se analizan ms y ms casos de uso. En cada iteracin elegimos
un conjunto de casos de uso y los reflejamos en el modelo de anlisis.
Cada clase debe cumplir todos sus roles de colaboracin: las responsabilidades de una clase son sencillamente la recopilacin
de todos los roles que cumple en todas las realizaciones de casos de uso en las que la clase participa.

Caso de prueba es un conjunto de entradas de prueba, condiciones de ejecucin, y resultados esperados, desarrollados para un
objetivo concreto, tal como probar un camino concreto a travs de un caso de uso, o verificar que se cumple un requisito
especfico.
Un procedimiento de prueba es una especificacin de cmo llevar a cabo la preparacin, ejecucin, y evaluacin de los
resultados de un caso de prueba particular.
Un proceso centrado en al arquitectura

Desarrollo de la arquitectura: El resultado de la fase de elaboracin es la lnea base de la arquitectura.

Descripcin de la arquitectura: La lnea base de la arquitectura, es la versin interna del sistema al final de la fase de
elaboracin. El conjunto de modelos que describen esta lnea base se denomina Descripcin de la Arquitectura.
La vista de la arquitectura del modelo de casos de uso: Presenta los actores y casos de uso ms importantes.
La vista de la arquitectura del modelo de diseo: Presenta los clasificadores ms importantes para la arquitectura
pertenecientes al modelo de diseo.
Tambin presentan como se realizan los casos de uso en trminos de esos clasificadores.
La vista de la arquitectura del modelo de despliegue: Presenta los nodos interconectados y las clases activas que se
ejecutan en ellos identificados durante el diseo.
La vista de la arquitectura del modelo de implementacin: El modelo de implementacin es una correspondencia directa
de los modelos de diseo y de despliegue.

La arquitectura en un sistema de SW se describe mediante diferentes vistas del sistema en construccin.

El concepto de arquitectura de SW incluye los aspectos estticos y dinmicos ms significativos del sistema. La arquitectura es
una vista del diseo completo (una vista del modelo de casos de uso, del modelo de anlisis, del modelo de diseo, del modelo
de despliegue, del modelo de implementacin) con las caractersticas ms importantes resaltadas.
El arquitecto desarrolla la forma o arquitectura a partir de la comprensin de un conjunto reducido de casos de uso fundamentales
o crticos (usualmente no ms del 10 % del total).
En forma resumida, podemos decir que el arquitecto:
Crea un esquema en borrador de la arquitectura, comenzando por la parte de la arquitectura que no es especfica de los
casos de uso (por ej. una plataforma), pero debe poseer una comprensin general de los casos de uso fundamentales.
A continuacin, trabaja con un subconjunto de los casos de uso especificados, con aquellos que representan las
funciones clave del sistema en desarrollo. Cada caso de uso seleccionado se especifica en detalle y se realiza en
trminos de subsistemas, clases y componentes.
A medida que los casos de uso se especifican y maduran, se descubre ms de la arquitectura. Esto, a su vez, lleva a la
maduracin de ms casos de uso.

El proceso contina hasta que se considere que la arquitectura es estable.

Importancia y necesidad de una arquitectura
Se necesita una arquitectura para:
Comprender el sistema
Organizar el desarrollo
Fomentar la reutilizacin
Hacer evolucionar el sistema.

El Proceso Unificado es Iterativo e Incremental

Dividir el trabajo en partes ms pequeas o mini proyectos. Cada mini proyecto es una iteracin que resulta en un incremento.
Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto. Las iteraciones
deben estar controladas. Esto significa que deben seleccionarse y ejecutarse de una forma planificada.
Los desarrolladores basan la seleccin de lo que se implementar en una iteracin en dos factores:
La iteracin trata un grupo de casos de uso que juntos amplan la utilidad del producto desarrollado hasta ahora.
La iteracin trata los riesgos ms importantes.

Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la ltima iteracin. Un
incremento no necesariamente es aditivo, especialmente en las primeras fases del ciclo de vida pero si lo son en las fases
posteriores.
En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseo utilizando la
arquitectura seleccionada como gua, implementan el diseo mediante componentes y verifican que los componentes satisfacen
los casos de uso. Cuando una iteracin no cumple sus objetivos, los desarrolladores deben revisar sus decisiones previas y
probar con un nuevo enfoque.

Los beneficios de un proceso iterativo controlado son:

Reduce el coste de riesgo a los costes de un solo incremento
Reduce el riesgo de no sacar al mercado el producto en el calendario previsto. Mediante la identificacin de riesgos en
fases tempranas del desarrollo.
Acelera el ritmo de esfuerzo de desarrollo, los desarrolladores trabajan de manera ms eficiente para obtener resultados
claros a corto plazo
Reconoce que las necesidades del usuario y sus correspondientes requisitos no pueden definirse complemente al
principio. Se refinen en iteraciones sucesivas
Conceptos claves

Proceso de Ingeniera de Software : Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo. En
ingeniera de software, el objetivo es construir un producto de software nuevo o extender uno existente.

Disciplina: Una disciplina es una coleccin de actividades relacionadas vinculadas con un rea especfica del proyecto.

Flujo de trabajo: Un flujo de trabajo describe la secuencia en que se realizan las actividades en una disciplina, quienes la
realizan (trabajadores) y que artefactos producen.

Trabajador (Rol): Un trabajador o rol, define un comportamiento o responsabilidades de un individuo o grupo de individuos
trabajando en equipo, en el contexto de una organizacin de ingeniera de software.

Actividad: Los trabajadores realizan actividades. Una actividad es algo que realiza un trabajador para proveer un resultado de
valor en el contexto de un proyecto.

Pasos:Las actividades son descompuestas en pasos.

Pasos de anlisis: donde el trabajador comprende la naturaleza de la tarea, examina los artefactos de entrada, y
formula las salidas.
Pasos de accin: donde los trabajadores crean o actualizan algunos artefactos.
Pasos de revisin: donde los trabajadores inspeccionan los resultados segn determinados criterios.

Artefactos: Las actividades tienen artefactos de entrada y de salida. Un artefacto es un producto de trabajo en un proceso: los
trabajadores utilizan artefactos para realizar actividades y producen artefactos como resultado de sus actividades.
LAS CUATRO P EN EL DESARROLLO DEL SW (Persona, Proyecto, Producto y Proceso)

PERSONA

Los principales autores de un proyecto de SW son los arquitectos, desarrolladores, ingenieros de prueba, y el personal de gestin
que le da soporte, adems de usuarios, clientes y otros interesados. Hay personas implicadas en el desarrollo de un producto de
SW durante todo su ciclo de vida.
Por lo tanto el proceso que gua este desarrollo debe orientarse a las personas, es decir, debe funcionar bien para las personas
que lo utilizan.
Los Procesos de Desarrollo afectan a las personas
El modo en que se organiza y gestiona un proyecto SW afecta profundamente a las personas implicadas en l. Los siguientes
conceptos tienen un papel importante:
Viabilidad del proyecto: la mayora de la gente no disfruta trabajando en proyectos que parecen imposibles. Los
proyectos que no son viables pueden detenerse en una fase temprana alivindose as los problemas de moral.
Gestin de riesgo: de igual forma cuando la gente siente que los riesgos no han sido analizados y reducidos, se sienten
incmodos.
Estructuras de equipos: la gente trabaja de manera ms eficaz en grupos pequeos de 6 a 8 miembros
Planificacin del proyecto: cuando la gente cree que la planificacin de un proyecto no es realista, la moral se hunde (la
gente no quiere trabajar si nunca podr obtener los resultados deseados)
Facilidad de comprensin del proyecto: a la gente le gusta saber lo que est haciendo
Sensacin de cumplimiento: en un ciclo de vida iterativo, la gente recibe retroalimentacin frecuentemente, lo cual a su
vez hace llegar a conclusiones. Un ritmo de trabajo rpido combinado con conclusiones frecuentes aumenta la sensacin
de progreso de la gente.
Convirtiendo recursos en trabajadores
Son puestos a los cuales se pueden asignar personas. Un tipo de trabajador es un papel que un individuo puede desempear en
el desarrollo de SW. Usamos el trmino rol para hablar de los papeles que cumple un trabajador. Un trabajador puede asumir
roles en relaciones con otros trabajadores en diferentes flujos de trabajo.
Cada trabajador es responsable de un conjunto completo de actividades. Los trabajadores necesitan la informacin requerida
para llevar a cabo sus actividades, necesitan comprender cules son sus roles en relacin con los de los otros trabajadores.
El proceso unificado describe formalmente los puestos que las personas pueden asumir en el proceso. Un trabajador puede
representar a un conjunto de personas que trabajan juntas.
Una persona puede ser muchos trabajadores durante la vida de un proyecto.

PROYECTO

Es el elemento organizativo a travs del cual se desarrolla el proyecto del SW. El resultado de un proyecto es una versin de un
producto.
El primer proyecto dentro del ciclo de vida desarrolla y obtiene el sistema o producto inicial. Debe preocuparse por:
Una secuencia de cambio: los proyectos de desarrollo obtienen productos como resultados, pero el cambio hasta
obtenerlos es una serie de cambios. Cada fase, cada ciclo y cada iteracin modifican el sistema de ser una cosa a otra
distinta.
Una serie de iteraciones: dentro de cada fase de un ciclo, los trabajadores llevan a cabo las actividades de la fase a
travs de una serie de iteraciones. Cada iteracin implementa un conjunto de pasos de uso relacionados o atena
algunos riesgos. Se puede decir que una iteracin es un mini proyecto.
Un patrn organizativo: la idea de proceso es proporcionar un patrn dentro del cual las personas en su papel de
trabajadores ejecutan un proyecto. Este patrn indica los tipos de trabajadores que el proyecto necesita y los artefactos
por los cuales hay que trabajar.

PRODUCTO
Artefactos que se crean durante la vida del proyecto, como los modelos, cdigo fuente, ejecutables, y documentacin.
Artefactos
Es cualquier tipo de informacin creada, producida, cambiada o utilizada por los trabajadores en el desarrollo del sistema. Por
ejemplo, los diagramas UML y su texto asociado, y los prototipos.
Hay dos tipos de artefactos: de ingeniera y de gestin. Nos centraremos solo en los de ingeniera que son creados durante las
fases del proceso (requisito, anlisis, etc.). Los artefactos de gestin solo duran lo que dura la vida del proyecto (por ej.: anlisis
del negocio, plan de asignacin de personas).
Un sistema posee una coleccin de modelos
El artefacto ms interesante utilizado en el PU es el modelo. Cada trabajador necesita una perspectiva diferente del sistema.
La construccin de un sistema es un proceso de construccin de modelos, utilizando distintos tipos para describir todas las
perspectivas diferentes del sistema.
Relaciones entre Modelos
Un sistema contiene todas las relaciones y restricciones entre elementos incluidos en diferentes modelos. Un sistema no solo es
una coleccin de modelos sino que tambin contiene las relaciones entre ellos. Cada caso de uso del modelo de casos de uso
tiene una relacin con una colaboracin en el modelo de anlisis. Esta relacin se llama en UML traza. Tambin hay trazas entre
los dems modelos: el de diseo y anlisis y entre el de implementacin y diseo. Las trazas no aaden informacin semntica
acerca de los modelos relacionados, simplemente los conectan.
PROCESO
Un proceso de ingeniera de SW es una definicin del conjunto completo de actividades necesarias para transformar los requisitos
de usuario en un producto. Un proceso es una plantilla para crear proyectos.
En el contexto del proceso unificado, el trmino proceso se refiere a los procesos de negocios claves en una empresa de
desarrollo de SW, es decir, que se dedica a fabricar SW.
En el Proceso unificado, proceso hace referencia a un contexto que sirve como plantilla que puede reutilizarse para crear
instancias de ella.
El proceso es una definicin del conjunto de actividades, no su ejecucin. No solo cubre el primer ciclo de desarrollo, sino todos
los posteriores.
UNIDAD 11: El flujo de trabajo de requisitos

Metodologas giles

XP

Es uno de los mtodos ms recientes, utilizados por desarrolladores chicos. Forma parte de los llamados procesos giles.
Enfocado ms a la codificacin.

Caractersticas:
Grupos pequeos, menos de 10 personas.
No existe jerarqua por lo tanto requiere comunicacin.
Programacin sencilla (no invierte en pruebas extras).
El programa fuente no se documenta
La nica manera de controlar las cosas es por medio de las entradas peridicas
La refactorizacin es un costo significativo al principio, pero reduce el costo de mantenimiento en el futuro, evita el olor a
cdigo (antes de poner parches es preferible hacer el cdigo de vuelta)

La programacin extrema da por supuesto que es imposible prever todo antes de comenzar a programar; es imposible o si lo
fuera es demasiado costoso e innecesario, ya que muchas veces se gasta demasiado tiempo y recursos en cambiar la
documentacin de la planificacin para que se parezca al cdigo. Para evitar esto, XP intenta implementar una forma de trabajo
donde se adapte fcilmente a las circunstancias.
Bsicamente consiste en trabajar estrechamente con el cliente, haciendo pequeas iteraciones (mini-entregas), cada dos
semanas, donde no existe ms documentacin que el cdigo en s; cada versin contiene las modificaciones necesarias segn el
cliente vaya retroalimentando el sistema (por eso es necesaria la disponibilidad del cliente durante todo el desarrollo).
Para suplir la falta de requisitos, casos de uso, y dems herramientas; XP utiliza historias de usuarios, la historia de usuario es
una frase corta que representa alguna funcin que realizara el sistema. Cada historia de usuario no puede demorar en
desarrollarse ms de una semana, si as lo requiera, debe segmentarse.

Proceso Unificado
Ventajas:
Desarrollo basado en componentes
Iterativo e incremental
Desventajas
Cantidad de artefactos (todo lo que hay que construir durante el desarrollo)

4 Variables: (Costo Tiempo Calidad Alcance)

En los modelos tradicionales son definidos por el uso (las 4).
En XP, 3 variables pueden ser definidas por el usuario y una por el grupo de programacin en base a las otras 3. Preferible el
alcance, en un negocio contino con el usuario.
Pensado para grupos de trabajos chicos, no tiene jerarquas, es un grupo de iguales, el usuario forma parte del grupo.

Los 4 valores son:

Comunicacin (se da en equipos de trabajo de no ms de 10 personas)
Sencillez (resolver de la mejor manera posible solo lo que me pide el usuario, cuando se presentan cambios los analizo,
pero no invierto en un futuro incierto)
Retroalimentacin (se realiza entre el equipo de trabajo y el usuario. Al haber comunicacin y pruebas constantes, la
retroalimentacin es el sistema mismo, l responde)
Valenta (coraje ante los problemas y afrontarlos)

Las 4 actividades son:

Codificar
Hacer pruebas
Escuchar
Disear (refactorizar)
La XP se basa en 12 principios bsicos agrupados en 4 categoras

Retroalimentacin a escala fina

1. Desarrollo guiado por pruebas: Prueba del programador y del cliente. Concepto de pruebas automticas, base de la XP
pero no poseemos los entornos para realizarlos. Se van acumulando pruebas, se prueba lo nuevo con lo ya probado para
ver si algo que antes funcionaba con lo nuevo ya no lo hace.
2. Proceso de planificacin: XP no es codificar y tirar, existe una planificacin previa, una definicin de lo que tenemos
que hacer.
3. El cliente en el sitio: Se dice que XP servir solo para desarrollos internos porque es difcil tener al usuario como parte
del grupo de trabajo, que el cliente nos d un usuario idneo para resolver las dudas que tengamos.
4. Programacin en parejas: 2 personas trabajando en lo mismo. Dicen que mejora notablemente la calidad porque se
busca la mejor forma de resolver los problemas y se intercambian las ideas. Se escriben en paralelo las pruebas a
hacerse. Se acorta el tiempo. Las parejas deben ir rotndose, lo cual quita la propiedad del cdigo, es mayor el grupo que
conoce que no hay dependencias.

Proceso continuo en lugar de por Lotes

5. Integracin Continua: Cada vez que se hace algo se junta con lo anterior y se analiza el impacto, constantemente se
agregan funciones al conjunto.
6. Refactorizacin: Corregir el cdigo todas las veces que sea necesario, si lo puedo mejorar lo hago. Olor a cdigo: al no
cambiar las clases cuando poda hacerlo.
7. Entregas Pequeas: 2 o 3 semanas a lo sumo, de entregas que son de valor para el usuario.

Entendimiento compartido
8. Diseo Simple: Que haga lo que tenga que hacer de la mejor manera posible con un cdigo simple que me permita
introducir cambios.
9. Metfora del Sistema: Modo narrativo de lo que el sistema tiene que hacer.
10. Propiedad Colectiva del Cdigo: Relacionado con la programacin en parejas. Deben haber estndares de codificacin
que todos deben respetarlo. El cdigo es de todos.
11. Estndares de codificacin: Deben ser estrictamente respetados para poder corregir lo que otro hizo, trabajar en
pareja, evitar dependencia de cdigo.

Bienestar del programador

12. La semana de 40 horas: Paso sostenible. La planificacin debe estar basada en que el programador tiene que trabajar
entre 35 y 45 horas por semana, para que rinda, escriba el cdigo de col. Pasos sostenible, evitando picos de trabajo,
stress.

XP supone
Las personas que son las claves en el proceso de desarrollo
Los programadores son profesionales, no necesitan supervisor
Los procesos se aceptan y se acuerdan, no se imponen
Desarrolladores y gerentes comparte en liderazgo del proyecto
El trabajo de los desarrolladores con las personas que conocen el negocio se regulan y controlan.
Fases de la metodologa XP
Planificacin
Negocio
mbito Qu debe resolver el SW?
Prioridad Qu debe ser hecho en primer lugar?
Composicin de Versiones Cunto es necesario para volver a aportar valor?
Fechas de versiones Fechas para presencia del SW?
Tcnico
Estimaciones Cunto lleva implementar una caracterstica?
Consecuencias, informar sobre consecuencias de las decisiones que adopta el negocio
Procesos Cmo se organiza el trabajo en el equipo?
Programacin detallada: en una versin Qu se resolver primero?
Pequeas versiones.
Diseo
Metfora
Diseo sencillo
Funcionen todas las pruebas
No existe lgica duplicada (que una funcin est en una sola clase y no que est repartida en varias
haciendo lo mismo)
Manifiesta cada intencin importante para los programadores
Tiene el menor nmero posible de clases, mtodos o funciones
Desarrollo
Remodificacin
Programacin por parejas
Propiedad colectiva
Integracin continua
40 horas semanales
Cliente in situ
Estndares de codificacin
Pruebas
Del programador
De interaccin
De aceptacin (antes de poner en funcionamiento, las hace el usuario, elabora como las hace al escribir los
relatos)

Implementacin (Proceso de Clientes) Implantacin (Puesta en produccin).

SOLUCIONES DE XP
Retrasos y desviaciones: versiones cortas (que me permiten ir haciendo ajustes y ver el grado de avance)
Cancelar el proyecto: entregar peridicas (lo que yo entrego, le sirve)
Sistemas deteriorados y defectuosos: pruebas constantes (de integracin)
Requerimientos mal comprendidos: cliente dentro del equipo
Cambios de negocios: versiones cortas (facilitan cambios a realizar)
Falsa riqueza: realizar tareas prioritarias (algo que hacemos pero no aporta valor)
Cambios de personal: anima el contacto y la integracin

Objetivo y visin del sistema sirve para todo lo que hagamos

FDD: DESARROLLO DIRIGIDO POR FUNCIONES

Situacin intermedia entre RUP Y XP
Se trabaja en equipo pero hay responsabilidad
Hay una propiedad del cdigo, se intercambian opiniones, pero al hacer cambios debe estar presente el dueo
Puntos Clave

RUP XP
Pesado Ligero
Dividido en 4 fases Cercano al desarrollo
Las fases se dividen en iteraciones Se basa en UserStories
Los artefactos son el objetivo de cada Fuerte comunicacin con el cliente
actividad
Se basa en roles (trabajadores) El cdigo fuente pertenece a todos
UML Programacin en parejas
Muy organizativo Test como base de la funcionalidad
Mucha documentacin Solo el mnimo de organizacin
Pobre en cuanto a la documentacin