CURRICULUM: Lorena Villatoro

2.1.1 Currículum:
Lorena Guadalupe Villatoro Díaz

DATOS PERSONALES

• DUI : 03411613 – 4
• NIT : 0614-271285-106-7
• LICENCIA DE CONDUCIR : 0614-271285-106-7
• EDAD : 23 años
• ESTADO CIVIL : Soltera
• PROFESIÓN : Estudiante Universitaria.
•Número de Telefono: 7768-2028
• E–MAIL : villatoro_@hotmail.com


ESTUDIOS REALIZADOS

• 2004 - 2009 ESTUDIOS UNIVERSITARIOS (VII ciclo), UNIVERSIDAD DON BOSCO
• 2002- 2003: BACHILLERATO GENERAL, COLEGIO EUCARISTICO
• 1999 – 2001: EDUCACIÓN BÁSICA, COLEGIO EUCARÍSTICO
• 1996 – 1998 EDUCACION SECUNDARIA, ESC. PARROQUIAL
  
• 1993 – 1995: EDUCACION PRIMARIA, ESC. PARROQUIAL
  
• 1990 – 1992: EDUCACIÓN PARVULARIA, CIRCULO INFANTIL,“MADRE DOLORES MEDINA”. DIVINA PROVIDENCIA
  

OTROS ESTUDIOS

• 1999 – 2000: TÉCNICO EN DISEÑO GRÁFICO, CENTRO TÉCNICO MONS. ROMERO
• 1997 – 1999: DIPLOMADO EN OPERADOR EN COMPUTADORAS. CENTRO TÉCNICO MONS. ROMERO

2.1.2 Reconocimientos:

2.1.3 Proyecto de vida:

• MISION

Primer periodo:
Ser un profesional responsable e integro, capaz de enfrentar nuevos retos y cumplir las metas que me proponga a corto y largo plazo, ya sea en mi ambito laboral como personal.

Segundo periodo

Apendrer y poner en practica cada uno de los temas vistos en este periodo para realizar un mejor proyecto de cátedra en ingenieria de software.

Tercer periodo: ALcanzar cada una de mis metas propuestas para este periodo como para el ciclo que es ser cada dia mejor una estudiante.

• VISION

Primer periodo
Como profesional tener un alto grado de conocimientos en el desarrollo de software de calidad para poder brindar al usuario un mejor servicio y asi poder facilitar el manejo de información.

Segundo Periodo

Demostrar cada una de mis habilidades a la hora de realizar nuestro proyecto de cátedra en Ingenieria de software y lo que no se aprenderlo.

Tercer periodo:
En este periodo tomare en cuenta cada tema brindado por la Licda. Alejandrina y a la vez tomar en cuenta cada una de las observasiones para que cada dia que pase ser un mejor profesional.

EXPECTATIVA
Mi propósito en el presente ciclo, en cuanto a la materia de Ingenieria de Software es aprender, analizar y desarrollar la capacidad de solucionar problemas de cualquier índoles basándome en la tecnología, ya que como futura ingeniera en ciencias de la computación, estoy en un momento de mi vida, donde debo adquirir la mayor cantidad de conocimientos, para que cuando me gradué ponerlo en práctica. Con la ayuda de nuestro docente y guía, de la Licda Alejadrina Velásquez, se que aprenderé, ya que la materia. deseando haber aprendido no lo básico de Ingenieria de Software, sino haber profundizado en muchos temas que nos ayuden a cultivar nuestra profesión.

• FORTALEZAS

Es que me gusta aprender cosas nuevas y cuando algo no le entiendo me gusta investigar y así aprender.

Me gusta ponerme metas ya sea a corto y largo plazo y cumplirlas.

Soy una persona dedicada y responsable en mis estudios .

• DEBILIDADES

La organización de mi tiempo, creo que aun no puedo distribuirlo bien.

No tengo un excelente hábito de la lectura.


MI SUEÑO Y PROPOSITO DE MI VIDA

Primeramente graduarme ser una profesional; pero aparte de esto sueño con crear mi propia empresa en la cual pondria en practica el marketing de negocios y estabilizarme economicamente.

Además aprender o especializarme en bases de datos de SQL SERVER, ORACLE ya que trabajar con bases de datos me gusta mucho.


2.2 Evidencias académicas

2.2.1 Malla académica



Materias cursadas en este ciclo

• Fisica I
• Gestión e innovación
• Microprocesadores
• PHP
• Ingeniería de Software

Fisica I: es una materia básica pero no menos importante; ya que ampliaremos nuestros conocimientos y apartir de esta podre llevar fisica II, EMA, y SEL I.

Gestión e innovación: está materia se me hace muy importante ya que estoy aprendiendo como inicializar mi propia empresa, además estoy aprendiendo como crear un plan de negocios.

Microprocesadores: es una materia en la cual te enseñan a programar en lenguaje ensamblador.

PHP: materia la cual es importante para mi ya que estoy aprendiendo a crear una página web dinámica.

Ingeniería de Software: está materia me parece importante ya que estoy aprendiendo como desarrollar un software; pero a la vez para que este sea de calidad.

• 2.2.2 RESUMEN EJECUTIVO

En este capitulo "Base de Desarrollo de Software"

Aprendi que es importante tomar en cuenta los requerimientos desde su inicialización hasta su finalización para que el software q se desarrolle sea de calidad.

En la parte de construcción se lleva la mayor parte del trabajo para el éxito o el fracaso. Si en un principio la calidad del código no es optima, es casi imposible volver hacia atrás y mejorarla, y podemos perder mucho tiempo: No tener unos buenos métodos pueden forzar a que se tenga que reescribir las partes principales del sistema y pueden introducir errores sutiles que pueden tardar mucho tiempo para encontrarlos y corregirlos.

el control de calidad nos proporciona un apoyo para obtener la máxima velocidad de desarrollo. Para ello tenemos que realizar todas las pruebas necesarias para encontrar los errores para que al final el sistema funcione correctamente como se esperaba. Hacemos las revisiones técnicas ya que estas tienden a encontrara errores de diferentes tipos ya que las revisiones proporcionan un foro para que los desarrolladores muestren sus conocimientos sobre los métodos recomendables, aumentando las posibilidades de desarrollo rápido.

CASO DE ESTUDIO

En este caso de estudio aplicamos la norma ISO 12207 ‘EL CICLO DE VIDA’ a un caso real de una empresa exportadora de café que deseada implementar una página web para que cada uno de sus cliente se les facilitara hacer sus pedidos por medio de los medios electrónicos, además a la vez implementar o poner en práctica el marketing electrónico

La norma ISO 12207 nos da una serie de pasos o procedimientos en los cuales tenemos que tomar en cuenta a la hora de elaborar un nuevo software para una empresa y para que dicho software sea de calidad hay que tomar en cuenta cada uno de los requerimientos dados en la ISO 12207.

2.2.3 Resumen de puntos

RESUMEN DE CLASES DEL PERIODO UNO

MODELOS GENÉRICOS
Modelo de Cascada
• Separar en distintas fases de especificación y desarrollo.
Desarrollo Evolutivo
• La especificación y el desarrollo están intercalados.
Prototipo
• Un modelo sirve de prototipo para la construcción del sistema final.
Transformación Formal
• Un modelo matemático del sistema se transforma formalmente en la implementación.
Desarrollo basado en Reutilización
• El sistema

Fases del Modelo de Cascada
• Análisis de requerimientos y definición.
• Diseño del sistema y del software.
• Implementación y prueba de unidades
• Integración y prueba del sistema.
• Operación y mantenimiento.
• La dificultad en esta modelo reside, en la dificultad de hacer cambios entre etapas.
Problemas y Riesgos con los Modelos.
• Cascada.
Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño.
Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida.
• Prototipado.
Bajo riesgo para nuevas aplicaciones debido a que las especificaciones y el diseño se llevan a cabo paso a paso.
Alto riesgo debido a falta de visibilidad
• Evolutivo.
Alto riesgo debido a la necesidad de tecnología avanzada y habilidades del grupo desarrollador.

Planteamiento de Objetivos
• Se identifican los objetivos específicos para cada fase del proyecto.
Identificación y reducción de riesgos.
• Los riesgos clave se identifican y analizan, y la información sirve para minimizar los riesgos.
Desarrollo y Validación.
• Se elige un modelo apropiado para la siguiente fase del desarrollo.
Planeación.
• Se revisa el proyecto y se trazan planes para la siguiente ronda del espiral.

Ventajas del Modelo de Espiral
• Centra su atención en la reutilización de componentes y eliminación de errores en información descubierta en fases iniciales.
• Los objetivos de calidad son el primer objetivo.
• Integra desarrollo con mantenimiento.
• Provee un marco de desarrollo de hardware/software.

En conclusión
La Ingeniería de software concierne a las teorías, métodos y herramientas para el desarrollo, administración y evolución de productos de software.
Los productos de software consisten de programas y documentación. Los atributos de los productos son, mantenabilidad, dependabilidad, eficiencia y usabilidad.
El proceso de software consiste en aquellas actividades involucradas en el desarrollo de software.
El modelo de cascada considera cada actividad del proceso como una actividad discreta.
El modelo de desarrollo evolutivo considera actividades del proceso en forma concurrente.
El modelo de espiral se basa en análisis de riesgos.
La visibilidad del proceso involucra la creación de documentos o resultados de las actividades.
Los Ingenieros de software deben tener responsabilidades éticas, sociales y profesionales.

RESUMEN DE TERCER PERIODO

ARQUITECTURA DE SOFTWARE

¿Qué es la Arquitectura del Software? Existen muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la responsabilidad de:
* Definir los módulos principales
* Definir las responsabilidades que tendrá cada uno de estos módulos
* Definir la interacción que existirá entre dichos módulos:
* Control y flujo de datos
* Secuenciación de la información
* Protocolos de interacción y comunicación
* Ubicación en el hardware

La Arquitectura del Software aporta una visión abstracta de alto nivel, posponiendo el detalle de cada uno de los módulos definidos a pasos posteriores del diseño.

La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: “La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución”.


El objetivo principal de la Arquitectura del Software es aportar elementos que ayuden a la toma de decisiones y, al mismo tiempo, proporcionar conceptos y un lenguaje común que permitan la comunicación entre los equipos que participen en un proyecto. Para conseguirlo, la Arquitectura del Software construye abstracciones, materializándolas en forma de diagramas (blueprints) comentados.

No hay estándares en cuanto a la forma y lenguaje a utilizar en estos blueprints. De todas formas, existe consenso en cuanto a la necesidad de organizar dichas abstracciones en vistas, tal y como se hace al diseñar un edificio. La cantidad y tipos de vistas difiere en función de cada tendencia arquitectónica.

Quizá uno de los modelos más conocidos es el “4+1” de Philippe Kruchten, vinculado al Rational Unified Process (RUP), que define cuatro vistas diferentes:
* Vista lógica: describe el modelo de objetos.
* Vista de proceso: muestra la concurrencia y sincronía de los procesos.
* Vista física: muestra la ubicación del software en el hardware.
* Vista de desarrollo: describe la organización del entorno de desarrollo.
* Existe una quinta vista que consiste en una selección de casos de uso o de escenarios que los arquitectos pueden elaborar a partir de las cuatro vistas anteriores.

La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema. Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información.

La Arquitectura de Software establece los fundamentos para que analistas, diseñadores, programadores, etc. trabajen en una línea común que permita alcanzar los objetivos del sistema de información, cubriendo todas las necesidades.

Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.

La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.

Modelos o vistas.

Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa.

Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:
• La visión estática: describe qué componentes tiene la arquitectura.
• La visión funcional: describe qué hace cada componente.
• La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí

Arquitecturas más comunes

Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son:

• Monolítica. Donde el software se estructura en grupos funcionales muy acoplados.

• Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones.

• Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia).

2.2.4 Otras evidencias de aprendizaje
http://delta.cs.cinvestav.mx/~pmejia/softeng/Arquitecturas.ppt
http://www.scribd.com/doc/210452/Arquitectura-de-Software-Adrian-Lasso

2.3 Evidencias Profesionales

2.3.1 Comentarios de empleadores actuales o anteriores.

2.3.2 Actividades profesionales: