Continuamente se estarán publicando los avances obtenidos y las fases de desarrollo en la cual se encuentra el proyecto.
lunes, 5 de diciembre de 2011
Conclusiones
El proceso de llevar acabo esta investigación de desarrollo de este proyecto ha servido como base para poder llevar acabo la implementación de dicho proyecto en un periodo de tiempo a corto y mediano plazo en el cual se definirán los puntos importantes restantes para llevarlo acabo. Todo el desarrollo llevado acabo hasta el momento sin duda alguna ha sido de gran utilidad y sobre todo comprendiendo mas a fondo todo lo que se debe llevar acabo en el desarrollo de proyectos de software.
Calculo de Costos
EVALUACIÓN EX-POST
Se lleva a cabo durante la etapa de operación para determinar si es conveniente continuar con el proyecto o definir los requerimientos de reprogramación necesarios para lograr los objetivos de impacto perseguidos. Esta evaluación también se puede llevar a cabo una vez concluida la operación. Consiste en la medición o sistematización de los resultados acumulados de:
- Cobertura
- Localización
- Eficacia
- Eficiencia
- Efectos
- Impacto
- Relación entre los costos y el impacto.
A diferencia de la evaluación ex-ante, en que se trabaja con objetivos y metas a alcanzar según las estimaciones existentes, en la ex-post se utilizan los datos reales, medidos en el proyecto.
Cuando se cuenta con un sistema de monitoreo, los datos relativos a la gestión debieran estar medidos, de lo contrario se deben calcular especialmente, utilizando los procedimientos indicados en los capítulos anteriores.
Una actividad inicial de la evaluación ex-post es identificar el momento más adecuado para llevarla a cabo, considerando la disponibilidad de información confiable y válida con los requerimientos de toma de decisiones para la gestión.
Calcular los costos reales del proyecto
En esta etapa se realizan las mismas acciones que en la evaluación ex-ante. Se debe:
- Confeccionar un flujo de costos. Tomando como base los datos de la formulación y programación, se ajustan los valores con la información real. Se deben incluir tanto los ítems ya ejecutados como los que ocurrirán entre el momento de la evaluación y el horizonte del proyecto.
- Actualizar los costos a la fecha de análisis. Considerar la fecha de evaluación como punto de referencia.
- Anualizar los costos.
- Construir la matriz de costos reales (incluyendo CTAr, SAPr, CUPr).
- Después de verificar los costos en que realmente se ha incurrido, se los puede contrastar con los estimados durante la programación.
La estimación de costes (recursos, equipos y tiempo empleado) es una de las razones de ser de la ingeniería del software. Aunque no siempre aplicable en entornos de software libre, donde no suele ser posible realizar una planificación de recursos disponibles, es conveniente conocer las métricas y métodos que nos permitirán predecir el esfuerzo que supondrá implementar un sistema o alguna de sus prestaciones.
La estimación suele realizarse basándose en modelos matemáticos que parten del “tamaño” estimado del proyecto, y de constantes que lo ajustan según las tecnologías usadas, recursos de que disponemos, etc. Los modelos nos permiten estimar el esfuerzo requerido (habitualmente en horas/hombre o meses/hombre) para terminar el proyecto.
Obviamente, la clave está en estimar el “tamaño” del proyecto. Aun sabiendo lo poco indicativo que puede llegar a ser, son bastantes los modelos que usan las líneas de código para determinar el tamaño de un proyecto (COCOMO, COCOMO II).
Asegurar que el proyecto es completado dentro del presupuesto previsto.
Fuentes:
CEPAL. Formulación, Evaluación y Monitoreo de Proyectos Sociales. División de Desarrollo Social. Ernesto Cohen, Rodrigo Martínez. Recuperado el 3 de Diciembre 2011, de http://www.eclac.org/dds/noticias/paginas/8/15448/Manual_dds_200408.pdf
UOC. Ingeniería del software entornos de SL. David Aycart Pérez, Marc Gibert Ginestà, Martín Hernández Matías, Jordi Mas Hernández. Recuperado el 17 de Noviembre 2011, de http://ocw.uoc.edu/computer-science-technology-and-multimedia/software-engineering-in-free-software-environments/software-engineering-in-free-software-environments/XP06_M2112_01486.pdf
Universidad de Cantabria. Ingeniería del software II. Juan
Hernández
Marqués. Recuperado el 3 de Diciembre 2011, de http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-ii/materiales/tema3-fundamentosGestionProyectos.pdf
lunes, 21 de noviembre de 2011
Diagramas de Componentes
UML define cinco estereotipos estándar que se aplican a los componentes:
• Executable: Especifica un componente que se puede ejecutar en un nodo. Library: Especifica una biblioteca de objetos estática o dinámica.
• Table: Especifica un componente que representa una tabla de una base de datos.
• File: Especifica un componente que representa un documento que contiene código fuente o datos.
• Document: Especifica un componente que representa un documento
Dependencias entre componentes
Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente.
Subsistemas
• Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación
• Son paquetes estereotipados en <subsistemas>
• Los subsistemas organizan la vista de realización de un sistema
• Cada subsistema puede contener componentes y otros subsistemas
• La descomposición en subsistemas no es necesariamente una descomposición funcional
• La relación entre paquetes y clases en el nivel lógico es el queexiste entre subsistemas y componentes en el nivel físico
• Paquetes (Categorias) y clases en el nivel lógico. Paquetes (Subsistemas) y componentes en el nivel físico
Fuentes:
• Executable: Especifica un componente que se puede ejecutar en un nodo. Library: Especifica una biblioteca de objetos estática o dinámica.
• Table: Especifica un componente que representa una tabla de una base de datos.
• File: Especifica un componente que representa un documento que contiene código fuente o datos.
• Document: Especifica un componente que representa un documento
Dependencias entre componentes
Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente.
Subsistemas
• Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación
• Son paquetes estereotipados en <subsistemas
• Los subsistemas organizan la vista de realización de un sistema
• Cada subsistema puede contener componentes y otros subsistemas
• La descomposición en subsistemas no es necesariamente una descomposición funcional
• La relación entre paquetes y clases en el nivel lógico es el queexiste entre subsistemas y componentes en el nivel físico
• Paquetes (Categorias) y clases en el nivel lógico. Paquetes (Subsistemas) y componentes en el nivel físico
El desarrollo orientado a objeto está muy relacionado con el desarrollo basado en componentes, en el sentido de que las clases con sus propiedades de encapsulación y abstracción se ven en muchas ocasiones como componentes cerrados de un sistema. Así pues, la notación UML incluye un diagrama de componentes que según la definición del OMG “muestra las dependencias entre componentes software, incluyendo los clasificadores que los especifican (por ejemplo las clases de implementación) y los artefactos que los implementan, como los ficheros fuente, binarios, scripts, etc.”.
En muchos casos en los que podrían usarse diagramas de componentes, se usan los diagramas de despliegue (que veremos más adelante), ya que éstos nos permiten modelar además dónde va a implantarse cada componente y bajo qué configuración o parámetros. Así pues, el diagrama de componentes ha quedado tradicionalmente relegado a modelar la arquitectura del sistema a nivel lógico o de entorno de negocio
Finalmente, la lista de buenas prácticas en la representación de componentes es la siguiente:
• Aplicar los estereotipos de forma consistente.
• Aunque usemos UML 1.5, la representación de las interfaces de los componentes mediante círculos es mucho más clara que una simple flecha entre ellos.
• Ya que la interfaz es un conjunto de métodos, intentemos no representar demasiadas interfaces, es aconsejable agruparlas bajo un mismo nombre y crear después un diagrama detallado del componente.
• Los componentes pueden heredar unos de otros. En este caso, la flecha que utilizamos en los casos de uso para expresar generalización puede servir perfectamente.
• Para mejorar la comprensión de un diagrama de componentes, es preferible conectarlos siempre a través de interfaces. Es más consistente y evita confusiones o dudas sobre su interpretación.
UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf
Ingeniería de Software. Modelo de implementación: Diagrama de componentes y despliegue. Recuperado el 20 de Noviembre 2011, de http://www.dsi.uclm.es/asignaturas/42530/pdf/M2tema12.pdf
Diagramas de Secuencia
Los diagramas de secuencia modelan el flujo de la lógica dentro del sistema de forma visual, permitiendo documentarla y validarla. Pueden usarse tanto en análisis como en diseño, proporcionando una buena base para identificar el comportamiento del sistema.
Típicamente se usan para modelar los escenarios de uso del sistema, describiendo de qué formas puede usarse. La secuencia puede expresar tanto un caso de uso completo como quizá un caso concreto del mismo contemplando algunas alternativas.
También son una buena herramienta para explorar la lógica de una operación compleja o los elementos implicados en la prestación de un servicio. Nos pueden ayudar a identificar cuellos de botella en la fase de diseño, detectar cuáles van a ser las clases más complejas de implementar y decidir cuáles de ellas van a necesitar diagramas de estados (que veremos más adelante) para facilitar su implementación.
Se componen de los siguientes elementos:
• Objeto: instancia de una clase que podemos empezar a identificar como participante en la secuencia de operaciones que representa este caso de uso.
• Actor: los actores pueden comunicarse con los objetos, por lo tanto formarán parte de este diagrama.
• Vida del objeto: indicamos la existencia de un objeto a lo largo
del tiempo mediante una línea discontinua. El fin del mismo se indica mediante un aspa.
• Activación: indicamos cuándo el objeto está realizando una tarea concreta.
• Mensaje: la comunicación entre objetos y sus activaciones.
Una de las características de los diagramas de secuencia es que casi no necesitan aclaraciones en cuanto a su notación. En la parte superior, vemos los participantes en la secuencia (también denominados “clasificadores” que implementan la misma). En general siempre será un actor el que inicie la secuencia, y el resto de participantes pueden ser objetos (representados con una caja en la que escribiremos el nombre del objeto), otros actores, o quizá un caso de uso completo.
Cada participante tiene un intervalo en el que éste está activo en la secuencia, que se indica mediante un rectángulo sobre la línea discontinua que representa la vida del objeto. El rectángulo empiezacuando el objeto recibe un mensaje (representado mediante una flecha que incorpora el nombre de la llamada) y termina cuando éste devuelve su última respuesta (representada mediante una flecha discontinua). Los mensajes suelen incluir números de secuencia que facilitan la comprensión del diagrama y el seguimiento del orden en que se producen los mensajes. A veces un error puede provocar una línea discontinua de retorno hasta el primer participante, de forma similar a cómo se propagaría una excepción. Así pues, las líneas de retorno pueden incluir también etiquetas para indicar si representan un error o no. Finalmente, un aspa al final de la vida del objeto indica que éste puede destruirse.
Finalmente, enumeramos un conjunto de buenas prácticas en la representación de diagramas de secuencia:
• El orden entre los mensajes y los participantes debe ser siempre de izquierda a derecha y de arriba abajo para facilitar la comprensión del diagrama.
• El nombre de los actores debe ser consistente con los casos de uso.
• El nombre de los objetos debe ser consistente con los diagramas de clases.
• Incluir notas en las secuencias.
• Sólo incluir el aspa de destrucción del objeto en casos en que proporcione información sobre cuándo debe destruirse, en caso contrario “ensuciaremos” el diagrama innecesariamente.
Fuentes:
Típicamente se usan para modelar los escenarios de uso del sistema, describiendo de qué formas puede usarse. La secuencia puede expresar tanto un caso de uso completo como quizá un caso concreto del mismo contemplando algunas alternativas.
También son una buena herramienta para explorar la lógica de una operación compleja o los elementos implicados en la prestación de un servicio. Nos pueden ayudar a identificar cuellos de botella en la fase de diseño, detectar cuáles van a ser las clases más complejas de implementar y decidir cuáles de ellas van a necesitar diagramas de estados (que veremos más adelante) para facilitar su implementación.
Se componen de los siguientes elementos:
• Objeto: instancia de una clase que podemos empezar a identificar como participante en la secuencia de operaciones que representa este caso de uso.
• Actor: los actores pueden comunicarse con los objetos, por lo tanto formarán parte de este diagrama.
• Vida del objeto: indicamos la existencia de un objeto a lo largo
del tiempo mediante una línea discontinua. El fin del mismo se indica mediante un aspa.
• Activación: indicamos cuándo el objeto está realizando una tarea concreta.
• Mensaje: la comunicación entre objetos y sus activaciones.
Una de las características de los diagramas de secuencia es que casi no necesitan aclaraciones en cuanto a su notación. En la parte superior, vemos los participantes en la secuencia (también denominados “clasificadores” que implementan la misma). En general siempre será un actor el que inicie la secuencia, y el resto de participantes pueden ser objetos (representados con una caja en la que escribiremos el nombre del objeto), otros actores, o quizá un caso de uso completo.
Cada participante tiene un intervalo en el que éste está activo en la secuencia, que se indica mediante un rectángulo sobre la línea discontinua que representa la vida del objeto. El rectángulo empiezacuando el objeto recibe un mensaje (representado mediante una flecha que incorpora el nombre de la llamada) y termina cuando éste devuelve su última respuesta (representada mediante una flecha discontinua). Los mensajes suelen incluir números de secuencia que facilitan la comprensión del diagrama y el seguimiento del orden en que se producen los mensajes. A veces un error puede provocar una línea discontinua de retorno hasta el primer participante, de forma similar a cómo se propagaría una excepción. Así pues, las líneas de retorno pueden incluir también etiquetas para indicar si representan un error o no. Finalmente, un aspa al final de la vida del objeto indica que éste puede destruirse.
Finalmente, enumeramos un conjunto de buenas prácticas en la representación de diagramas de secuencia:
• El orden entre los mensajes y los participantes debe ser siempre de izquierda a derecha y de arriba abajo para facilitar la comprensión del diagrama.
• El nombre de los actores debe ser consistente con los casos de uso.
• El nombre de los objetos debe ser consistente con los diagramas de clases.
• Incluir notas en las secuencias.
• Sólo incluir el aspa de destrucción del objeto en casos en que proporcione información sobre cuándo debe destruirse, en caso contrario “ensuciaremos” el diagrama innecesariamente.
Fuentes:
Popkin Software and Systems. Modelado de Sistemas con UML. Un estudio a fondo de UML. Diagramas de Secuencia. Recuperado el 20 de Noviembre 2011, de http://www.ibiblio.org/pub/linux/docs/LuCaS/Tutoriales/doc-modelado-sistemas-UML/multiple-html/c12.html
UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf
Suscribirse a:
Entradas (Atom)