viernes, 30 de noviembre de 2007

Model Driven Programming

La programación orientada a modelos es un modelos generado del sistema de la perspectiva del usuario, así se transfiere a un lenguaje de UML así teniendo el UML se puede hacer o aplicar a diferente tipos de programación, así se divide en pequeños subsistemas que nos permiten fácilmente realizar el sistema sin errores. La programación orientada a modelos esta impulsada por el desarrollo de software, es un paradigma que se esfuerza por llevar a cabo la manipulación del modelo abstracto que estamos tratando de lograr a través de un cuerpo de lenguaje de programación de código.

Link 1

Link 2

Link 3


Sergio Adián Montaño Araujo 1º E

viernes, 23 de noviembre de 2007

Entrega 2, Equipo 2




En esta ocación las actividades requeridas para la entrega del trabajo no las repartimos entre los integrantes del equipo de Análisis y Modelado de Softwrae. Aqui cada quien se encargo de un poco del trabajo que entregariamos el 23 vde Novienbre del año en curso. Aqui me todo acer algunos diagramas y tambien lo que es el Caso de Uso, Autor, Propósito y Descripcion de cada caso de uso de algunos diagramas que realizamos junto con el equipo de trabajo. Al final de ralizar las actividades que nos tocaron a cada uno se llebo acabo una junta pa la recolección del materia a tentregar el 23 de Nov. del año en curso. Asi se llebó acabo todo el proceso del trabajo que casi estuve dentro del el como casi todos los integrantes del equipo. Bueno esto es un poco de la descripción de lo que se realizo en el equipo y de lo que realize en conjunto con los integrantes del equipo.



Sergio Adrian Montaño Araujo "1ºE"

viernes, 16 de noviembre de 2007

Primera Entrega. Equipo 2


Bueno este pequeño espacio va dirigido hacia lo que realice con mi equipo sobre el sistema que estamos llevando acabo en esta material de Analisis y madelado de software. Aqui participe con mi equipo sobre darles el conocimiento sobre nuetro sistema a los nuevos integrantes del equipo asi aclarando sus dudas y preguntas de esta manera quedan informados los nuevos integrantes del equipo sobre el sistema desarrollado durante el semestre. Tambien tube paricipacion sobre la corrección de los documentos que entregamos el dia de hoy. Asi trabajamos todos en equipo y se llebo acabo el trabajo con exito esperando buena calificacion sobre el trabajo de hoy. Bueno es es una breve explicación sobre las actividades echas en las dos reuniones que tubimos el equipo. Me despido, que tengan un buen puente!!!! bye....


Descarga el Trabajo dando click Aqui

Tarea " Diagramas "

·


Para descargar la tarea da click Aqui


Gracias, bye...



·

miércoles, 14 de noviembre de 2007

Tarea "Caso de Uso" UML

Descarga la tarea de Sergio Adrian Montaño Araujo

Has click Aqui


Gracias! bye....

lunes, 1 de octubre de 2007

Las Personas en las Metodologías de Ingieniería en Software: Resumen

UN PEQUEÑO RESUMEN...Comenzamos...:D...

1. Las personas al Inicio de la Informática: Protoingeniería del Software.

Los “protoingenieros de software” (por llamar de alguna manera a los primeros profesionales del software), eran visionarios altamente calificados, generalmente adelantados a su tiempo. La Máquina Analítica era un proto-ordenador que podía ser programado para solucionar una amplia gama de problemas lógicos y computacionales. Las metodologías estructuradas hacen fuerte separación ente los datos y los procesos.
Adicionalmente, se intenta mecanizar las tareas del programador, teniendo como ideal la generación del código mediante herramientas CASE. El programador es altamente reemplazable.
Algunos autores destacados en esta área son Yourdon (Análisis Estructurado Moderno), Page-Jones (Diseño Estructurado), Constantine, DeMarco (Orientación a Procesos), etc.
Ante la necesidad de normalizar el proceso desarrollo se propusieron unas metodologías que priman las fases, actividades y tareas antes que a las personas: lo más importante es el rol que juega la persona dentro del proceso de desarrollo. Estos roles suelen ser muy similares en todos los procesos: administrador de proyecto, analista, diseñador, programador, probadores, asegurador de calidad, documentalista, ingeniero de manutención, ingeniero de validación y verificación, administrador de la configuración. Para cada uno de estos roles, se definen sus objetivos, actividades, interacción con otros roles, herramientas a utilizar, perfil de las personas en ese rol y un plan de trabajo.

3.3. Ejemplo: Las personas en RUP

Las personas en RUP se denominan Trabajadores, siendo la definición de este término:
“Puesto que puede ser asignado a una persona o equipo, y que requiere responsabilidades y habilidades como realizar determinadas actividades o desarrollar determinados artefactos”

En un proyecto de RUP existen los siguientes roles
Rol
Descripción
Jefe de proyecto
Supervisor y responsable del proyecto
Analista del Proceso de Negocio
Coordina el modelado de los CU de negocio
Diseñador del Proceso de Negocio
Describe el workflow de uno o varios casos de uso de negocio
Revisor del Proceso de Negocio
Revisa los artefactos generados del workflow de Modelado de Negocio
Analista de Sistemas
Es el responsable de un conjunto de requisitos: Requisitos funcionales,
Requisitos no funcionales
Especificador de Casos de Uso
Asumen las responsabilidades de las descripciones detalladas de uno o más casos de uso
Diseñador de Interfaces de Usuario
Forma visual de los interfaces de usuario, esquema de pantallas, modelos de interfaz grafica
Arquitecto
Describe el modelo de la arquitectura, es responsable de la integridad del modelo de análisis y de la integridad de los modelos de diseño y despliegue
Revisor de Requisitos
Revisa los artefactos generados en el workflow de Análisis de Requisitos
Ingeniero de Componentes
Define y mantiene las responsabilidades, atributos, relaciones y requisitos de una o varias clases de análisis
Ingeniero de Casos de Uso
Analiza un Caso de Uso, Captura requisitos especiales sobre la realización del caso de uso y es responsable de la integridad de una o más realizaciones de casos de uso-diseño
Integrador de Sistemas
Planifica la secuencia de construcciones necesarias en cada iteración
Diseñador de Pruebas
Responsable de la integridad del modelo de pruebas y plantear las pruebas
Ingeniero de Pruebas de
Implantación
Verifica los componentes integrados en la construcción que se derivan de los casos de prueba que especifican una realización de un caso de uso-diseño
Ingeniero de Pruebas de Sistemas
Prueba de las pruebas técnicas: rendimiento, estrés, carga,..


3. Las personas en las metodologías ágiles

En los procesos ágiles, las personas vuelven a tomar un valor importante: el éxito de estos procesos es función de la participación, preparación e involucramiento de las personas en el mismo [12]. Generalmente estos procesos deben ser conducidos y llevados a cabo por personas con características muy especiales. El cambio de estas personas afecta fuertemente al proceso. De hecho, estos procesos están también orientados a las personas, buscando un mayor estado de bienestar para las personas que llevan a cabo el proceso de software a cambio de un mayor grado de compromiso. Por lo tanto, podemos decir que las personas tienen un rol muy importante en este tipo de procesos.

3.1. Procesos ágiles

Los procesos ágiles ofrecen un enfoque diametralmente opuesto al de las metodologías
predictivos para gestionar y controlar el desarrollo de productos y proyectos de software.
El resultado de esto fue el “Manifiesto para desarrollo ágil de software”.

3.2. Las metodologías ágiles más famosas

Actualmente, existe una amplia variedad de metodologías ágiles.
Extreme programming (de kent beck y ward cunningham)
Crystal Clear
Scrum
DSDM (Dynamic System Development Method )
Highsmith´s Adaptive software development (de Jim Highsmith)

3.3. Ejemplo: Las personas en Extreme Programming (XP)

Las personas son muy importantes en Extreme Programming. De hecho, el motivo de su existencia según Kent Beck es mejorar la calidad de vida de los integrantes de los equipos de desarrollo de software.
Podrán cambiar la dirección del proyecto a mitad del desarrollo, sin incurrir en costes excesivos
Como se puede apreciar, estas promesas apuntan al bienestar social de los 2 stakeholders determinantes en un proceso de desarrollo: el equipo de desarrollo y el cliente.
XP se basa en mucha comunicación en el equipo. Por esto, los integrantes de éste deben ser personas con una combinación de aptitudes técnicas y sociales. En un proyecto de XP existen los siguientes roles


Referencia:

Las Personas en las Metodologías de Ingieniería en Software

sábado, 8 de septiembre de 2007

Programacion Orientada a Objetos.

La Programación Orientada a Objetos, es un paradigma de programación que define los programas en términos de "clases de objetos", objetos que son entidades que combinan estado (datos), comportamiento (procedimientos o métodos) e identidad (propiedad del objeto que lo diferencia del resto). La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar. De esta forma, un objeto contiene toda la información, (los denominados atributos) que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso entre objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, dispone de mecanismos de interacción (los llamados métodos) que favorecen la comunicación entre objetos (de una misma clase o de distintas), y en consecuencia, el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan (ni deben separarse) información (datos) y procesamiento (métodos).