jueves, 25 de octubre de 2012

caso de uso


Casos de Uso (Use Case)
Introducción
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
  • Actor.
  • Casos de Uso.
  • Relaciones de Uso, Herencia y Comunicación.
Elementos:
Ejemplo:
Como ejemplo esta el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:
  • Registrar el número de ítemes ingresados.
  • Imprimir un recibo cuando el usuario lo solicita:
    1. Describe lo depositado
    2. El valor de cada item
    3. Total
  • El usuario/cliente presiona el botón de comienzo
  • Existe un operador que desea saber lo siguiente:
    1. Cuantos ítemes han sido retornados en el día.
    2. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
  • El operador debe además poder cambiar:
    1. Información asociada a ítemes.
    2. Dar una alarma en el caso de que:
      1. Item se atora.
      2. No hay más papel.
Como una primera aproximación identificamos a los actores que interactuan con el sistema:
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:
Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.
Entonces, el diseño completo del diagrama Use Case es:

domingo, 21 de octubre de 2012

Ciclo de vida Rup


CICLO DE VIDA DE RUP
DIAGRAMA GENERAL DE RUP 



FASES DEL CICLO DE VIDA DE RUP

En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con un producto intermedio.
Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con los objetivos de la misma
.

      


INICIO

•    El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto.
•    Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos.
•    Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la viabilidad de desarrollar el proyecto.

ELABORACIÓN

•    El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseño e implementación en la siguiente fase.
•    La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluación del riesgo.

CONSTRUCCIÓN
•    El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base.
•    Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de las operaciones para optimizar costos, tiempo y calidad.

TRANSICIÓN
•    Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios.
•    Se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario.
•    En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización.

lunes, 15 de octubre de 2012

Cerdos y gallinas


Espero y esta este ejemplo del ciclo de vida scrum le agrade es el que indentifica esta metologia ya que en ella se explica dos roles muy importante dentro de este método llamado scrum 

Cerdos y gallinas: metodología Scrum

La metodología Scrum es un modelo de gran utilidad para todos aquellos quienes su actividad esté relacionada a la realización de proyectos para terceras partes. Buenos ejemplos de este tipo de profesionales son los arquitectos, programadores, consultores, desarrolladores web, publicistas, etc.
De una manera muy sintética consiste en la definición de un conjunto de prácticas y roles, para el establecimiento del proceso de desarrollo que se llevará a cabo durante la ejecución del proyecto. Los tres roles de los que se compone la metodología Scrum son el ScrumMaster, que se asimila al director de proyecto, el Product Owner, es decir, el cliente que puede ser interno o externo y el Team, que engloba el equipo que ejecuta el proyecto.
El proceso se inicia con una reunión de los roles para establecer el Sprint Planning. El Product Owner identifica los elementos del Product Backlog, es decir, el conjunto de requisitos priorizados que definen el trabajo a realizar y que quiere que el equipo complete por lo que se lo comunica a los miembros del equipo
El equipo determina la cantidad del trabajo al que puede comprometerse durante el siguiente sprint. En el desarrollo de cada sprint nadie puede cambiar el Sprint Backlog lo que significa que los requisitos permanecen invariables hasta la culminación del sprint que puede durar de 15 a 30 días.
Uno de los principios esenciales de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan, lo que implica que el equipo ha de estar abierto a afrontar nuevos desafíos. Por tanto requiere una planteamiento de maximización de la capacidad del equipo para responder a nuevos requisitos no planificados ni programados.
Para el establecimiento de roles se establece una comparación con los cerdos y las gallinas. Los primeros, los cerdos, son los que están comprometidos con el proyecto y el proceso Scrum y lo componen:
§  El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio.
§  ScrumMaster (o Facilitador), cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. Es quien hace que las reglas se cumplan.
§  Team tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo.
Los roles gallina en realidad no son parte del proceso pero deben tenerse en cuenta. Incluyen a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

este es un

martes, 9 de octubre de 2012

COCOMO

la verdad este fue un tema q nos falto en la exposicion y quiero compartilo con ustedes

MODELO COCOMO
Barry Boehm en su libro "economía de la ingeniería de software" detalla un modelo amplio de estimación de costos llamado COCOMO (Constructive Cost Model). La palabra "constructive" se refiere a el hecho que el modelo ayuda a un estimador a comprender mejor la complejidad del software; este modelo es un ejemplo de variable simple estático y es usado por miles de administradores de proyecto de software .
COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de desarrollo, equipamiento y mantenimiento).
El modelo provee tres "niveles" de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.
Básico, es un modelo estático simplemente evaluado que calcula el esfuerzo (y costo) del desarrollo del software como función del programa expresado en líneas de código (LDC estimados).
Intermedio, calcula el esfuerzo del desarrollo del software como función del tamaño del programa y un conjunto de "guías de costo" que incluye una evaluación subjetiva del producto, hardware, personal y de los atributos del proyecto.
Avanzado, incorpora todas las características de la versión intermedia con una evaluación del impacto de las vías de costo en cada fase (análisis, diseño, etc) del proceso de la ingeniería de software.
El modelo básico se extiende para considerar un conjunto de atributos de guías de costo que pueden agruparse en cuatro categorías principales:
Producto ( por ej. Requerimientos de software, confiabilidad, tamaño de la base de datos, y complejidad del producto).
Computadora (por ej. Restricciones en el tiempo de ejecución y almacenamiento).
Personal (por ej. Capacidad de análisis, experiencia en aplicaciones tanto en lenguajes de programación y capacidad del programador)
Proyecto (por ej. Uso de practicas modernas de programación, uso de herramientas de software y requerimiento de un plan de desarrollo).
En cada nivel de aplicación están definidos para tres tipos de proyectos de software:
Modo orgánico, proyectos de software relativamente pequeños y sencillos en los que pequeños equipos con buena experiencia en la aplicación trabajan en un conjunto de requerimiento poco rígidos.
Modo semi-acoplado(semi-detached), un proyecto de software intermedio en tamaño y complejidad en el cual equipos con distintos niveles de experiencia debe satisfacer requerimientos poco y medio rígidos
Modo acoplado(detached), un proyecto de software que debe ser desarrollado dentro un conjunto estricto de hardware, software y de restricciones operativas.
Modos que están basados en la complejidad de la aplicación y el desarrollo del ambiente. El modelo de esfuerzo general aplicable a todos los niveles de aplicación y modos está dado por :
Donde:
E = es el esfuerzo estimado expresado en hombres-mes
EDSI es el número estimado de líneas de código distribuidas en miles para el proyecto
a, h son constantes determinadas por el modo del desarrollo, ambos incrementados por la complejidad de la aplicación.
EAF es el factor de ajuste de esfuerzo, es igual a 1 para la modelo básica e igual al producto de 15 factores de costo para la modelo intermedia y avanzada. Cada factor de costo multiplicativo es reflexivo de un incremento proporcional (> 1) o decremento (<1) en costo.
A continuación veremos los coeficientes para el modelo intermedio que depende de modo de desarrollo:
MODO DE DESARROLLO
A
b
c
d
Organic
3.2
1.05
2.5
0.38
Semi-detached
3.0
1.12
2.5
0.35
Embedded
2.8
1.20
2.5
0.32

Modo básico utiliza el tamaño y el modo intermedio 15 manejadores de costo que son los siguientes:
Manejadores de Costo
Very Low
Low
Nominal
High
Very High
Extra High
ACAP Analyst Capability
1.46
1.19
1.00
0.86
0.71
-
AEXP Applications Experience
1.29
1.13
1.00
0.91
0.82
-
CPLX Product Complexity
0.70
0.85
1.00
1.15
1.30
1.65
DATA Database Size
-
0.94
1.00
1.08
1.16
-
LEXP Language Experience
1.14
1.07
1.00
0.95
-
-
MODP Modern Programming Practices
1.24
1.10
1.00
0.91
0.82
-
PCAP Programmer Capability
1.42
1.17
1.00
0.86
0.70
-
RELY Required Software Reliability
0.75
0.88
1.00
1.15
1.40
-
SCED Required Development Schedule
1.23
1.08
1.00
1.04
1.10
-
STOR Main Storage Constraint
-
-
1.00
1.06
1.21
1.56
TIME Execution Time Constraint
-
-
1.00
1.11
1.30
1.66
TOOL Use of Software Tools
1.24
1.10
1.00
0.91
0.83
-
TURN Computer Turnaround Time
-
0.87
1.00
1.07
1.15
-
VEXP Virtual Machine Experience
1.21
1.10
1.00
0.90
-
-
VIRT Virtual Machine Volatility
-
0.87
1.00
1.15
1.30
-