Primera Clase (5 de Agosto del 2009)

MODULO I GESTIÓN DE PROYECTOS (PMI)

1. Conceptos Básicos:

El ciclo de vida de la administración de un proyecto es estándar. Todos

los proyectos tienen las mismas etapas de vida: iniciación, cierre, etc. El
proyecto es específico y tiene ese mismo fin. Los conceptos básicos son
las 4P:

a) Personal: Necesitamos un equipo de trabajo, hay que tener en cuenta

definir los roles de cada persona, todos los del grupo es importante
que tengan actitud (inteligencia emocional buena, yo conmigo mismo
y con los demás). Técnica de los sombreros

b) Producto: que es lo que voy a hacer, lo que entrego. La actividad mas

importante es el alcance, definirlo.

 Alcance: a que me voy a comprometer, hasta donde llego.

Triángulo de hierro. WBS(Work Breakdown structure),es una
técnica para definir el alcance, este me mejora el alcance y me
ayuda a definir los entregables. Time Boxing, es una técnica
donde si no pude entregar 4 reporte, entrego 2.

Alcance

Proceso

Tiempo Recursos

 Objetivos: debemos estar pendientes con los objetivos de

nuestro proyecto para cumplirle al cliente, son los objetivos no
funcionales.

 Alternativas: debo evaluar alternativas de solución del

producto, siempre pensar que se va a hacer y como se va a
hacer antes de hacerlo. Esto garantiza equivocarme menos.
Busca tomar decisiones técnicas para las soluciones.

c) Proceso: Los procesos ortodoxos como secuencial, cascada, etc y

heterodoxos, que son mas agiles como scrumb y programación
extrema. Es la elección del modelo o proceso del software, se
pueden hacer híbridos también.
 d) Proyecto: el seguimiento es una tarea importante, es la clave del
proyecto. Existen 10 señales que indican que un proyecto está en
peligro:

 El personal de software no entiende al cliente

 El alcance del producto está mal definido

 Los cambios se gestionan mal

 La tecnología elegida cambia

 Las necesidades comerciales cambian

 Los plazos de entrega no son realistas

 Los usuarios se resisten

 Se pierde el patrocinio

 El equipo de proyecto carece de personal con las habilidades

apropiadas

 Los gestores (y los profesionales) evitan las mejores prácticas

y las lecciones aprendidas

Próximas clases:

• Gestión temporal: como manejar programas y tiempo

• Estimación en proyecto de software.

• Gestión de riesgos: Alternativas para eliminar el riesgo

• Gestión de calidad: gestionar la calidad

• Gestión del cambio: los software siempre cambian

Pressman 6ta edición pag. 660->libro guia de modulo de gestión de proyectos.

www.technet.com.co/hpajaro

Segunda Clase (12 de Agosto del 2009):

El software es un producto? No es un producto, es un medio para entregar

conocimientos, aunque tiene todas las características de un producto, el
verdadero producto es el conocimiento que dejas en el software. Medios para
almacenar conocimiento: ADN, guarda la información genética de los humanos
pero no se modifica mucho, el cerebro es otro medio, este se modifica
constantemente pero es volátil, los libros son medios de conocimientos y el
software, se automodifica y modifica su entorno de manera ilimitada, cosa que
no hacen los otros. El problema general del software es el tiempo que duramos
para aprender y no sabemos el proceso para saber.

El desarrollo del software es un proceso de adquisición de conocimientos,

cuando adquieres conocimientos aprendes, entonces el desarrollo del software
es un proceso de aprendizaje.

Hay 5 niveles de ignorancia:

1. Estamos en el nivel 0 de ignorancia cuando probablemente conozco algo

de algo.

2. Estoy en el primer nivel de ignorancia cuando no se algo (sabes lo que

no sabes)

3. Estoy en el segundo nivel cuando yo no se lo que no se.

4. Tercer de nivel de ignorancia cuando yo no tengo un proceso para

encontrar lo que no se.

5. Cuarto nivel de ignorancia es cuando no se sabe que existen los 5

niveles de ignorancia.

Libro claveA new model for the production and managment of

software.

Primera ley del software: “Solo podemos hacer un software si

conocemos el proceso para hacerlo”.

GESTIÓN TEMPORAL

Principios Básicos para gestionar el tiempo de entrega de un software:

1. Compartimentalización: descomponer el software en actividades

vitales

2. Interdependencia: Se debe determinar cual es la relación entre las

actividades, cual tarea va primero, cual le sigue.
 3. Asignación de tiempo: Debo ser capaz de asignar tiempo para
realizar cada tarea. Hay que tratar de dividir cada tarea.

4. Validación del esfuerzo: Saber el número de personas para

realizar las distintas tareas.

5. Definición de responsabilidades: debo definir el responsable de

cada tarea.

6. Definición de resultados: Cada tarea debe tener un resultado

definido.

7. Definición de hitos: Un hito es un entregable aprobado por el

cliente, también puede ser un suceso importante, se representa
por un rombo negro;

PERT (Técnica de evaluación y revisión de programa) /CMP (Método

de ruta crítica): Realizar el grafo con todas las tareas y reconocer las
rutas críticas para saber cuando va a durar mi proyecto.

Para realizar un cronograma:

# Actividad/tarea: cada tarea debe tener un responsable, dentro de

cada actividad debe haber una tarea de validación y entrega (hito). Al
lado de esto se coloca los meses en que vas a trabajar con sus cuatro
semanas y voy tachando lo que hago y cuanto duro en cada tarea.

1. Ing. De requisitos

1.1.

1.2

1.3 Validación de requisitos

1.4 Especificación final(hito)

2. Diseño

2.1

2.2

Herramienta o técnica de Seguimiento: Análisis de valor ganado: se gana lo

que termine, pero para ganarla se tiene que aprobar. Hay que realizar también
un cuadro, así:
# Actividad/Tarea Semana Hrs(planeadas) HrsAcum. %Hrs
Acum.
T1 1 5 5 10%
T2 1 10 15 33%
T3 2 7 22 44%
50 50 100%

Realizar estimativo de software:

Horasestimadas=200*50.000:Valor de la hora=$10.000.000
HorasDisponibles=HorasProyecto/0.7:Eficiencia por hora=2.85
Tres personas: 20->Horas semanales por persona
20
20
10
70/0.7:Ef->100 horas semanales deben trabajar 3Semanas

Tercera Clase (19 de Agosto del 2009):

GESTIÓN DE RIESGOS: Conjunto de actividades para liderar que buscan la

minimización o eliminación de los riesgos. Lo que está detrás de la gestión de
riesgos es un valor=prevención;
Esto depende de la actitud, la cual puede ser Proactiva o reactiva, esta ultima
sólo aprende de los errores y la proactiva es la actitud esencial.
Riesgo: Evento inesperado que puede producir pérdidas, si no produce
pérdidas no es riesgo.
Procesos para gestionar riesgos:
1. Identificar riesgos: En software hay varias fuentes de identificación:
Problemas de alcance y de complejidad. Puede haber riesgos de clientes,
cuando este núnca se encuentre y nunca te puede atender. Puede haber
riesgos asociados y presupuestales, también cuando no conoces la
tecnología, es un riesgo; Puede haber riesgos en el equipo de trabajo
como las personas conflictivas.
2. Evaluación de riesgos:
o Determinar la probabilidad de ocurrencia:
Alta: >/80%
Media: 50 -<80%
 Baja: <50%
o El impacto: Los últimos dos son los que interesan.
1. Despreciable
2. Marginal
3. Crítico
4. Catastrófico
3. Hacer una tabla de riesgos: tipificar los riesgos, ejemplo:
# Descripción Tipo Probabilidad Impacto VE(valor
esperado)
El VE es el producto de la probabilidad por el valor numérico estimado
de la pérdida.
4. Seleccionar los riesgos de interes: los selecciono en dos categorías: Alto
impacto y de alta probabilidad de ocurrencia.

Planes de acción:

5. Realizar el plan Preventivo: todas las acciones que se hagan para evitar
o eliminar el riesgo.
6. Realizar el Plan de contingencia: Todo aquello que se haga para
minimizar la pérdida después que ocurre.
Plan de continuidad de negocio: BCP y administración de continuidad de
negocios MCP
7. Seguimiento: Hay que realizarle seguimiento a los controles o
procedimientos para minimizar los riesgos, ejemplo: Realizar los Backup
y no revisar si funcionan.

GESTIÓN DE CALIDAD: Todas las acciones que se emprenden para tener

un producto de calidad. Se tienen requisitos del cliente y tecnológicos. Se debe
tener un procedimiento para saber que se cumplen con requisitos. La causa
de la mala calidad es la variación, no se debe variar el estándar del
proceso; Si no se tiene un estándar no puede haber calidad. Para lograr calidad
se tiene que escoger un proceso y no cambiarlo sino para mejorarlo. Ejemplo
de estándar: casos de uso.
Calidad: Es cumplir requisitos del cliente, satisfacer sus necesidades.
Elementos de gestión de calidad:
1. Revisiones técnicas formales (RTF): procedimiento para revisar los
componentes del software y llevarlos a la línea base. La revisión tiene
que ser hecha por dos o mas personas, no una. La línea base es cuando
se llega a un punto que se diga que esta listo y no se modifica mas y si
se modifica hay que pasar a evaluarle los riesgos. Un enemigo del
software es el cambio. Cuando se hace esto, se cumple con calidad.
Existe una metodología de calidad, se llama 6σ. Partetto: el 80% de los
problemas son causados por un 20% de cosas, los pocos vitales (Los errores
son causados por pocas causas). Esta metodología la usa 6 σ.
2. Mejorar el proceso, eliminando las causas.
3. Control del proceso.

Cuarta Clase (26 de Agosto del 2009): Se sigue con gestión de

calidad.

Mejoramiento continuo: Siempre se puede mejorar, analizando tus errores y

tratando de eliminarlos.
Poka - yoke: Es un dispositivo, mecanismo o ente que evita o alerta al usuario
para que no cometa fallas. Hay que pensar siempre que los errores del usuario
son culpa de un no control del software, hay que tratar de alertar al usuario a
que no cometa errores de digitación, por ejemplo alertar al usuario cuando al
comenzar un nuevo año el digite una fecha del año pasado.

GESTIÓN DEL CAMBIO: Si no se gestiona el cambio, es posible que este

quede mal , hay que avisar del cambio a la gente, capacitarlos, y acompañarlos
en todo el proceso; Siempre hay que ir mas alla. El cambio es uno de los
factores por los cuales el proyecto puede fallar. Hay que tener el cuenta el
cambio de las personas, ya que estas no quieren cambiar. La gestión de
cambios acaba cuando el software termina.

Conceptos importantes:
 Gestión de configuración:
 Componentes: -Requisitos
-Modales
-Clases
-BD
-Documentación
-Herremientas
 Trazabilidad: Poder saber de donde vienen las cosas.
 Versión: versionar es parte de la gestión del cambio, siempre de menor a
mayor, Ejemplo: 1.0, 1.0.1.1, 2.0. Hay versiones: mayores
Menores
Existen software que manejan esto de las versiones, ej: CVS.; Para el
versionamiento es muy importante la trazabilidad, ya que si no se de
donde vienen las cosas, no se puede versionar.
 Linea Base: un componente esta en linea base cuando ya se ha revisado
y quedo listo, cuando a partir de alli no puede ser cambiado sin antes
hacerle un procedimiento especial de control de cambios.
Formato de Control de cambios: Es un documento formal e histórico,
esto lo tienen que aprobar, ya que al final van las firmas; Hay que tener
en cuenta tener un ambiente de prueba (esto lo puedo hacer con
virtualizadores) y un ambiente productivo (después que se probó que
todo funcionó con el ambiente de prueba). Ejemplo:
Fecha:
Integrantes:
Descripción del cambio:
Riesgos:
Plan preventivo:
Plan contigencia:
Conclusiones:
Recomendaciones:
Principio de gestión de cambios:
• Siempre cambie una cosa a la vez, no varias
• ¿Puede devolverme o deshacer?, siempre hay que preguntarse esto
antes de cambiar algo.
Para el 1er parcial: métricas de puntos funcional, en pressman 6. Cap. 15, el
ejercicio 15.5. Lecturas: cuarta dimensión y leyes de software. Leer en
pressman métricas basadas en la función, pag. 496.

MODULO 2: MODELO ORIENTADO A OBJETOS

Ingeniería del software, Ingeniería del software

Enfoque Estructurado orientada a objetos
La ingeniería de software 1 es la La ingeniería de software orientada
estructurada, basada en la base de a objetos reutiliza el código. El
datos, en el diseño relacional, se centro de este modelo son las
trabaja con: funciones, módulos y clases, jerarquía de clases y, por lo
procedimientos. Aquí se encuentran tanto los objetos; Tiene muchas
las bases de datos relacionales. Se ventajas, el código es mas
hacía análisis, diseño estructurado, compacto, reutilizable. Las
prueba. No tiene muchas visiones dificultades de los modelos es tratar
del sistema. de guardarlos. Las bases de datos
son DB40, esta tienen mayor
capacidad de abstracción, son un
poco mas abstractas. Acá se hace
análisis orientado a objetos, diseño
orientado a objetos y prueba orienta
a objetos. Una de las ventajas es
que aquí se enfoca en el dominio
del problema, del cliente; También
tiene múltiples visiones del sistema.
Un objeto es una entidad que encapsula datos (estado) y comportamiento. Los
objetos se caracterizan por tener: Estado, Comportamiento e identidad. Estos
pertenecen a un agrupamiento, los que comparten características o
comportamiento común es una clase. El objeto si existe, la clases, no, son
abstracciones de los objetos; Por esos se dice que un objeto es una
instancia de una clase en memoria, sin embargo hay clases que no se
instancian.
Datos (principal) y código
Clase: Son objetos agrupados que comparten características y
comportamiento en común.
La clase es una abstracción, no es igual al objeto, comparten muchas cosas en
común, pero no son iguales.

Las características fundamentales del modelo orientado a objetos:

• Encapsulamiento: Proteger a los datos del exterior.
• Herencia
• Polimorfismo

Quinta Clase (02 de Septiembre del 2009): Se sigue con modelo

orientado a objetos.

Tres pilares del Modelo orientado a objetos MOO:

MOO

Enc
Poli
aps Her mor
ula enci fism
mie a o
nto

Encapsulamiento: ocultamiento de la información

Tres etapas del encapsulamiento: - Abstracción: de buena calidad, se busca

una solución mas v
sencilla y no se obtiene a la primera.

- Ocultamiento

- División de responsabilidades: cada objeto

debe tener responsabilidades, ojala muy
pocas.
La identidad es importante para el software, como el ID, es único para el objeto
y no se vuelve a utilizar, la identidad debe permanecer con el objeto aún
después de destruido.
El comportamiento es lo que el objeto hace, su funcionalidad.
El estado es la característica que hace referencia al funcionamiento interno del
objeto, el comportamiento cambia el estado, esta es una característica
temporal, esta es la diferencia del modelo relacional de antes con este
orientado a objetos, en el relacional el estado nunca cambia.
La implementación es como se hacen las cosas, el Dominio es el espacio donde
el problema vive; Existen metodologías, como D3 (Domain Driven
Development: desarrollo manejado por el dominio)
Las clases comparten un mismo tipo de objetos; Un mensaje es como un objeto
le dice a otro que haga algo.
Una interfaz es la manera como llego al objeto, es una lista de servicios que
provee un componente, te dice que hacer pero no como hacerlo, un ejemplo de
esto es un contrato.
Como implemento el encapsulamiento en C#? para esto utilizo una clase
Los modificadores de acceso protegen la clase. (Private void print): estos son:
- Public: todo el mundo tienen acceso
- Protected: La misma clase y los hijos son los
que tienen acceso.
- Prívate: Solo tienen acceso la misma clase

Ejemplo: Class figure

{
Private nombre
}
Si se encapsula bien no hay efectos colaterales.
Trucos para lograr una abstracción efectiva:
- Concéntrese en lo general y no en lo particular
- Trate de buscar un concepto, no un caso específico
- La abstracción es importante pero no hay que paralizarse por eso, no se
puede lograr a la primera vez
 Sexta Clase (09 de Septiembre del 2009): Se hablan sobre las
notas del 1er corte.

Notas: 5 de asistencia, 3 en el trabajo y 3.5 en el examen, en total 3.6

Public: modificador de acceso
LIFO: Pila
FIFO: Cola
Ejemplo de cómo realizar un proceso completo de abstracción y
encapsulamiento:
Public Class Pila{
Private Nodo Nombres;  Aquí ensapsulo
Public Void Insertar (nodo x)
{  También encapsulo
}
Public Nodo Sacar()
{
}
Herencia: Es un tipo de relación entre objetos, es un tipo de relación “Es un”,
dentro de esta relación hay una clase base y una clase hija y una clase
derivada hereda de una clase base. Hay otra relación “Tiene Un”
Base Subclase
- Superclase - Derivada
- Madre - Hija
Ejemplo para hacer herencia en c#:

Public class cliente: Persona

{
----
}

: Elemento base, “Es un”. Ej: el cliente es una persona.Persona=Madre;

Cliente:Hija.
Elementos claves de la herencia:
- Sobreescritura(Overridden): La nueva clase hereda el método o atributo
de la clase base pero provee una nueva definición. permite especializar
un objeto.
 - New: Se crean métodos nuevos para la clase derivada.
- Recursive: la nueva clase simplemente hereda un método o atributo de
la clase base.
3 formas principales en las cuales se puede aplicar la herencia:
1. Para reutilizar la implementación. Se usa todo el código de la madre
2. Por diferencia: Cuando a la clase hija se le colocan métodos distintos,
cuando a la clase hija le agrego los nuevos métodos que la distinguen de
la madre.
3. Sustitución: Aquí se encuentra el principio de sustitución de LISKOV=
Como una hija es una madre, puede reemplazarla. (Cuando no se
cumple LISKOV, algo está mal)
Conectabilidad: Es cuando se cumple el principio de sustitución de LISKOV.
La herencia ayuda a lograr los objetivos de la programacaión orientada a
objetos:
- Natural
- Reusable
- Mantenibilidad
- Extendible
- Timely

Polimorfismo: Cuando un objeto tiene varios comportamientos, se usa

cuando quiero generalizar métodos, ej: método abrir, pero puede ser abrir una
ventana, etc. Cuando tengo un método que se llama igual, pero se comporta
distinto; el polimorfismo no necesita la herencia, ya que este reutiliza el
comportamiento. Cuando generalizo el espíritu del comportamiento, utilizo
polimorfismo. Polimorfismo por sobreescritura de método:
4 tipos de polimorfismo:
 Por inclusión ó puro: Cuando se aplica el principio de sustitución, se
aplica polimorfismo por inclusión.
 Parametrico:
 Por sobreescritura
 Por sobrecarga
Para el taller:
Diseñar un aplicación definir 4 clases
-Complejo: 3 + 5i
- Matrices: 3x3
- Fracciones: ¾ + 5/3 = 41/28, sumar en cruz
- Enteros:
Ej: T Sumar (Ta, Tb)
m1=m.Sumar(A,B)
m1.mostrar

Ejemplo:
Matriz: Complej

+ i

Fraccione Enteros:
A
+
B

Procesa

Nota= El método de losa cuatro botones debe ser igual.

Generacidad: Averiguar “Generics” en c#
El tipo del objeto es un parámetro, puede cambiar en tiempo de ejecución.

Septima Clase (de Septiembre del 2009):

Una interfaz siempre va a ser pública, su nombre siempre va a empezar por i

mayúscula.

<T>= Tipo de dato genérico

Las interfaces tienen sólo métodos y no se implementa nada.

_: estándar que representa atributos de una clase

Una clase puede tener varios contructores con el mismo nombre.

UML:

Es una análisis de modelamiento para diseñar Software; es el lenguaje de

modelamiento unificado; es un lenguaje para hacer esquemas, es gráfico.

Octava Clase (30 de Septiembre del 2009):

Uan herramienta clave para los usuarios finales son los casos de uso, estos
sirven para modelar un sistema.

Grupo para proyecto SI para implementar la técnica de seguimiento de

análisis de valor ganado.

DB4O: manejador de bases se datos.

5 pasos para hacer analisis orientado a objetos: (Ejemplos para un SI de

documentación digital)

1. Identificar los actores. Ej: Digitalizador, cliente, administrador, lejagador

(no interactúa directamente con el sistema), catalogador y posiblemente
el Scanner.

2. Se crea las listas preliminares de casos de uso:

3. Refinar y nombrar los casos de uso

4. Definir la secuencia de eventos

5. Modelar tus casos de uso

Los casos de uso son la interación entre los Actor y un sistema donde el actor
puede ser un usuario o no, es cualquier cosa que interactue con el sistema de
manera externa. Un actor es el que dispara un proceso, ejemplo: todos los dias
se mande correos a varios usuarios donde le demos alguna información, esto
es un actor.
Simbolo del actor en UML: (Un muñequito), el nombre del actor debe ser facil y
que se pueda recordar
Procesos completo que el sistema realiza: casos de uso; casi siempre son
verbos que actuan sobre objetivos.
<< >>: Esto indica que lo que esta adentro es un estereotipo, para cuando
quiero crear mas elementos en mi diseño.
Novena Clase (07 de Octubre del 2009):

DIAGRAMAS DE INTERACCIÓN:

Diagrama de secuencias: La secuencialidad en los casos de uso se modela en

los diagrama de secuencias.
Cuando se ve dos puntos : y al lado izquierdo no hay nada, la palabra de la
derecha es la instancia.
Diagramas de colaboraciones: Determinar quien hace que y quien colabora con
quien, ayuda a determinar con quien se comunica el objeto, a quien colabora.
Diagrama de actividades: busca meterse en el detalle de los procesos.

Decima Clase (14 de Octubre del 2009): Hicimos el parcial 2 y

damos clase

Una clase se representa asi:

Nombre de la
clase

Atributos

Operaciones
Un metodo es una operación implementada. UML es sensible al tipo de datos.
Si se coloca protected, private es opcion del diseñador.

Un estereotipo es una forma de extender el UML y se representa asi: << >>.

Pueden haber muchos estereotipos en una clase.

Cuando una clase es abstracta, su metodos deben ser implementados por los
hijos, no por la misma y su nombre debe ir en itálica para diferenciarse. Esto
generaliza el comportamiento de los objetos de la misma clase. Ej: Figura
geometrica es una clase abstracta y cuadrado es hija de esta clase, yo no
puedo implementar el area en la clase madre solo en las hijas como circulo,
triangulo, etc.

No tiene sentido tener clases aisladas, porque sus objetos se relacionana entre
si. Los tres tipos de relaciones son:

- Dependencia: Se representa con una flecha punteada

 - Asociacion: Indica que un objeto contiene a otro, se simboliza por una
linea y una flecha arriba de la linea que apunta al contenedor. Se divide
en dos:

1. Agregación, aqui hay una relacion tiene un., aquí existe una relacion
entre iguales y no dependen la una de la otra; Se simboliza con una
linea y al final un rombo.

2. Composición: Una composición es otro tipo de asociación, aquí no

hay una relación de iguales, se simboliza por una linea y al final un
rombo negro que apunta al objeto que es considerado el todo, ej:
Banco y sucursal. No hay sucursal(parte) sin banco(contenedor).

- Generalizacion: Es una relación Es un, como la herencia, se simboliza

por una linea con una flecha blanca.

Multiplicidad parecido a cardinalidad.

El rol (lo que hace el objeto)de un objeto es su comportamiento mas su estado.

Asociaciones reflexivas: Una clase se puede relacionar con ella misma.

Pregunta parcial: Cual es el criterio de cuando usar interfaz y cuando usar

clases abstractas? Una interfaz es una clase abstracta sin atributos, los
atributos me dicen esto.

Proyecto, tareas, usuario. Centrarse en el tiempo, importante la gráfica. No hay

fuente.

Onceava Clase (28 de Octubre del 2009): Documentación del

proyecto:

Correcciones para la documentación:

En requisitos:

 todos los requisitos deben ser medibles, por ejemplo no se puede poner
“llevar una programación clara y entendible.”

 No colocar dos requisitos en uno

 Enfocarse en nuestro caso en el tiempo

 Se puede utilizar la palabra “Crud”, ejemplo: crud de proyectos, incluir el

término en el glosario, todas las palabras desconocidas se colocan en el
glosario.

 Colocar porcentaje de frecuencia de las tareas, frecuencia acumulada

  Saber como va el proyecto en el transcurso del tiempo

 Cuenta solo cuando la tarea se termina en un 100%, la tarea se gana

cuando se cumple

 Colocar en requisitos: “el sistema no manejara presupuestos”

 Los requisitos deben ser lo mas claro posible y llevar una aclaración. En
vez de justificación, se coloca ¿para que es importante el requisito?

 En vez de semáforo: el sistema manejara un indicador de alerta gráfico.

(7), en el requisito se debe poner el qué y en el caso debe explicar que
hacer, dentro del caso de uso no debe decir como hacer las coas, sino
que hacer. Ejemplo: el sistema debe validar el ingreso, pero no decirle:
implementar encriptación.

 Uno debe saber cuales son los requisitos críticos

Casos de uso crítico:

 En nuestro trabajo estaban muy simple, hay que colocar casos de uso
reales, detallarlo mas posible para que el programador pueda hacer
algo.

 No colocar en el caso de uso: hacer un combo, luego puedo agregar una

nota.

 Un caso de uso es un proceso completo, por lo tanto deber ser relevante.

Nuevos formatos de casos de uso y requisitos:

Alcance: hasta donde debo llegar; Alcance del semáforo: el sistema solo
manejara estos tres colores.

Nivel: de componente, de funciones y de sistemas. Saber que afecta el caso

de uso. Aquí pueden ir las siguientes palabras: Sistema, subsistema,
componente y función.

Precondiciones y Postcondiciones: pre: es el estado del sistema que debe

tener para poder realizar el proceso, la postcondicion es como queda el
sistema después del proceso, hay veces que no hay precondiciones.

Reglas de negocio: es una combinación de requisitos que se vuelve una

condición, son restricciones que hay que colocar y no son requisitos. La nomina
tiene reglas de negocio, como se debe calcular la hora extra, esta es una regla
de negocio, el IVA tiene muchas reglas. Se puede hacer una tabla aparte de
reglas de negocio, aquí irían fórmulas.

Trigger: Se coloca que o quien dispara el proceso, si es un actor si es un

sistema, se supone que es el actor principal pero hay que ser mas especifico.

Asesorias: Lunes y jueves de noche.

Diagrama de clases: se debe colocar especificamente que hace cada clase, en

usuario no debe ir crear actividades, debe ir crear usuarios. En la clase usuario
va usuario y password.

La presentación sería un 28 de Noviembre/09

Doceava Clase (04 de Noviembre del 2009):

Diseño orientado a objetos: Construir una solución.

Pasos basicos para hacer diseño OO:

1. Hacer una lista inicial de objetos

2. Refinamiento (Refinar: pasar de lo abstracto a lo concreto, pasar de un

grado de abstracción mayor a uno menor ej: Programar) de las
responsabilidades de los objetos. De toda la lista de los objetos, añado,
uno, etc.: En esta parte hay que analizar que hace cada objeto. Existe un
técnica que nos dice como determinar responsabilidades: CRC (Clase
Responsabilidad Colaboración) Card, ejemplo de una tarjeta CRC: En las
colaboraciones sería quien usa al objeto

Class name

Colaboraciones
Responsabilidad
es

Cohesion: Es cuando un objeto realiza una sola tarea

Acoplamiento: Relaciones entre objetos

Responsabilidad no significa quien hace las cosas, sino que hace.

3. Desarrollar puntos de interacción: detallar las interacciones entre los

objetos

Interacción: cuando un objeto usa a otro objeto, aquí tengo que definir
interfaces
 Agente: son intermediarios entre dos objetos

4. Detallar las relaciones entre objetos:

Realización: cuando un objeto usa una interfaz

5. Construir tu modelo:

Una relación normal es una asociación

Tips para pasar de la lista inicial de objetos a la siguiente etapa:

1. Todo actor se vuelve a clase

2. Cada uno de los objetos potenciales los vuelvo clase

3. Cualquier evento vuelvalo clase

4. Considere los objetos con los cuales se muestra la información de una

clase como un objeto (Ej: un formulario)

5. Represente sistemas terceros como una clase

Treceava Clase (11 de Noviembre del 2009): (Patrones)

PATRONES:

• Patrones creacionales: son para crear objetos, los claves son: Abstract
factory, builder, factory method, prototype, singleton (instancia unica);
Este ultimo te garantiza que el objeto se creará una sola vez, ya que
tener objetos repetidos genera problemas; Garantiza la existencia de
una unica instancia.

El abstract factory garantiza que se escoja el constructor adecuado por

medio del objeto del que se esta hablando.

• Patrones estructurales: los mas importantes son: adapter, bridge,

composite, decorator, facade, flyweigth, proxy. El patron adapter nos
ayuda a que las librerias sean compatibles, lo que hace es una clase que
envuelve a otra. El patron proxy engaña a un objeto haciendolo creer
que esta usando otro cuando la verdad es que esta usando un
intermediario.

• Patrones de comportamiento: importantes: observer, iterator, strategy

(en tiempo de ejecución se define que metodo usa)
 • Patrones de sistema, el mas usado es MVC (modern view control), lo usa
joomla, utilizamos 3 capas, este sabe separar las clases en 3 capas.

• El controlador es el codigo que esta detrás de los controles.

Catorceava Clase (18 de Noviembre del 2009): (c#)

_: Indica que es una variable y le sigo el nombre.

Conectar BD: Es un constructor porque tiene el mismo nombre de la clase, es

mas que un método. Tenemos que atachar la base de datos, ponerle la ruta.

La base de datos del proyecto debe estar en Bin Debug

@: significa que los caracteres que estan adentro son literales

\: Sirve para definir simbolos, lo utilizo doble pero tengo que quitarle el arrova.

En el proyecto hay que aplicar Singleton.

Para recuperar la conexión, para encapsularla, que no la puedo cambiar.: get

Con.close: cerrar la conexión

Queryds: Es un Query que devuelve un daset(conjunto de tablas)

Adapter.fills: Para llenar el dataset

Cmd: Ejecuta cualquer instrucción SQL

ExecuteReader: devuelve un dato de solo lectura

Dataset: Deuelve datos que se pueden cambiar

Toda clase tiene otra que la controla.

En program.cs cambio para ejecutar diferentes formularios.

BindingSource:Es un control que permite enlazar un control de una ventana

con un dataset .

Pasos para programar un ComboBox:

1. Crear binding Source

2. Parametrizarlo, cambiarle las propiedades

3. Irme a las propiedades del control y añadirle lo que falta

4. Luego en la tabla de propiedades, expando databinding y en la
propiedad text le coloco ninguno.