Bibliografía
Ø Tema 1: Proyectos
Ø Tema 2: Ciclo de la vida del proyecto del
software
Ø Tema 3: Identificación de diagramas UML
Ø Tema 1: Proyectos
1.1 ¿Qué
es un proyecto?
Un proyecto es un conjunto de acciones que se planifican a
fin de conseguir una meta u objetivo previamente establecido, para lo que se
cuenta con una determinada cantidad de recursos y tiempo
1.2 Tipos
de Proyecto
Proyecto
comunitario o social:
conjunto de actividades orientadas a crear el producto, servicio o resultado
que satisfaga las necesidades más urgentes de una comunidad.
Ejemplo: 1.-
Proyectos para brindar ayuda a niños de la calle
2.- Proyecto
para la construcción de áreas o espacios dentro de una zona a beneficio de la sociedad
o comunidad.
Son ejecutados por:
*Algún
miembro de la sociedad
*Gobierno *Grupo social
existente
Proyecto
de vida: Representa, en
su conjunto, “lo que el individuo quiere ser” y “lo que él va a hacer” durante
toda su vida.
Son ejecutados por:
*Un solo individuo
de la sociedad
Proyecto
productivo: Son
proyectos que buscan generar estabilidad económica y obtener ganancias en
dinero.
Son ejecutados por:
*Empresas *negocios *inversionistas *empresarios *organizaciones *corporativos
Proyecto
de informática:
Representa, la elaboración de alguna aplicación, software de base de datos,
pagina web, o producto tecnológico Con el fin de mejorar por medio de la tecnología
nuestra vida cotidiana.
Son ejecutados por:
*Ingenieros
en sistemas * Diseñadores de
sistemas * Programadores
*Técnicos *Diseñadores
gráficos *Informáticos.
1.3 Concepto
de planeación de proyectos de software
La planificación de proyectos forma
parte de la gestión de proyectos,
la cual se vale de cronogramas tales como diagramas de Gantt para del progreso
dentro del entorno del proyecto.
Es el proceso para cuantificar el tiempo y recursos que un proyecto costará.
Ø Tema 2: Ciclo de la vida del proyecto del
software
2.1 Concepto
de ciclo de vida del software
Es el proceso que se sigue
para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y
retiro del sistema. Se definen las distintas fases intermedias que se requieren
para validar el desarrollo de
un software, es decir, para garantizar que el software cumpla los requisitos
para la aplicación y verificación de los procedimientos de desarrollo, se
asegura de que los métodos utilizados son apropiados.
2.2 Descripción
de tipos de ciclos de vida del desarrollo del software
INGENIERÍA
DE SISTEMAS
En
esta etapa el analista luego de un minucioso y detallado estudio de los
sistemas de una organización, detecta un problema o una necesidad que para su
solución y/o satisfacción es necesario realizar un desarrollo de software.
ANÁLISIS
En
esta etapa se debe entender y comprender de forma detallada cual es la
problemática a resolver, verificando el entorno en el cual se encuentra
Ingeniería,
descripción o análisis.
DISEÑO
Una
vez que se tiene la suficiente información del problema solucionar, es
importante determinar la estrategia que se va a utilizar para resolver el
problema. Esta etapa es conocida bajo el CÓMO se va a solucionar.
CODIFICACIÓN E IMPLEMENTACIÓN:
partiendo
del análisis y diseño de la solución, en esta etapa se procede a desarrollar el
correspondiente programa que solucione el problema mediante el uso de una
herramienta computacional determinada (Lenguaje de programación tales como:
C++, Java, C#, Cobol, PHP, ASP, JSP entre otros.).
PRUEBAS
Y DEPURACION:
Los
errores humanos dentro de la programación de los computadores son muchos y
aumentan considerablemente con la complejidad del problema. Cuando se termina
de escribir un programa de computador, es necesario realizar las debidas
pruebas que garanticen el correcto funcionamiento de dicho programa bajo el
mayor número de situaciones posibles alas que se pueda enfrentar.
Es la guía o comunicación escrita en
sus diferentes formas, ya sea en enunciados, procedimientos, dibujos o
diagramas que se hace sobre el desarrollo de un programa. La importancia de la
documentación radica en que a menudo un programa escrito por una persona, es
modificado por otra
IMPLANTACIÓN
en esta etapa se instala el software en los
dispositivos computacionales y se pone en marcha la ejecución e utilización del
software.
MANTENIMIENTO
una vez instalado un programa y puesto
en marcha para realizar la solución del problema previamente planteado o
satisfacer una determinada necesidad, es importante mantener una estructura de actualización,
verificación y validación que permitan a dicho programa ser útil y mantenerse
actualizado según las necesidades o requerimientos planteados durante su vida útil.
2.3
Descripción de las etapas del ciclo de vida del software Cascada
Diseño,
desarrollo, implementación, pruebas, mantenimiento.
Este
modelo asume que todo se lleva a cabo y tiene lugar tal y como se había
planeado en la fase anterior, y no es necesario pensar en asuntos pasados que
podrían surgir en la siguiente fase. Este modelo no funcionará correctamente si
se dejan asuntos de lado en la fase previa. La naturaleza secuencial del modelo
no permite volver atrás y deshacer o volver a hacer acciones. Este modelo es
recomendable cuando el desarrollador ya ha diseñado y desarrollado softwares
similares con anterioridad, y por eso está al tanto de todos sus dominios.
Modelo
repetitivo
Este
modelo guía el proceso de desarrollo de software en repeticiones. Proyecta el
proceso de desarrollo de forma cíclica repitiendo cada paso después de cada
ciclo en el proceso de SDLC. El software primero se desarrolla en menor escala
y se siguen y tienen en consideración todos los pasos. Entonces, por cada
repetición, más módulos y características son diseñados, codificados, evaluados
y añadidos al software. Cada ciclo produce un software completo, con más
características y capacidad que los previos. Después de cada repetición, el
equipo directivo puede concentrarse en la gestión de riesgos y prepararse para
la siguiente repetición. Como el ciclo incluye pequeñas porciones de la
totalidad del proceso software, es más fácil gestionar el proceso de
desarrollo, pero a la vez se consumen más recursos.
Modelo
en espiral
El
modelo en espiral es una combinación de ambos modelos, el repetitivo y uno del
modelo SDLC. Se puede ver como si se combina un modelo de SDLC combinado con un
proceso cíclico (modelo repetitivo). Este modelo considera el riesgo, factor
que otros modelos olvidan o no prestan atención en el proceso. El modelo
empieza determinando los objetivos y las limitaciones del software al inicio de
cada repetición. En la siguiente etapa se crean los modelos de prototipo del
software. Esto incluye el análisis de riesgos. Luego un modelo estándar de SDLC
se usa para construir el software. En la cuarta etapa es donde se prepara el
plan de la siguiente repetición.
Modelo
V
El
mayor inconveniente del modelo de cascada es que solo se pasa a la siguiente
fase cuando se completa la anterior, por tanto, no es posible volver atrás si
se encuentra algún error en las etapas posteriores. El Modelo V aporta opciones
de evaluación del software en cada etapa de manera inversa. En cada etapa, se
crea la planificación de las pruebas y los casos de pruebas para verificar y
validar el producto según los requisitos de la etapa. Por ejemplo, en la etapa
de recogida de requisitos, el equipo de evaluadores prepara las pruebas de caso
correspondientes a los requisitos. Más tarde, cuando el producto se desarrolla
y está preparado para ser evaluado, las pruebas de caso en esta etapa verifican
el software y su validez según sus requisitos. Esto hace que tanto la
verificación como la validación vayan en paralelo. Este modelo también se
conoce como modelo de validación y verificación.
Modelo
Big Bang
Este
modelo es el modelo con la forma más simple. Requiere poca planificación, mucha
programación y también muchos fondos. Este modelo se conceptualiza alrededor de
la teoría de creación del universo 'Big Bang'. Tal como cuentan los
científicos, después del big bang muchas galaxias, planetas y estrellas
evolucionaron. De la misma manera, si reunimos muchos fondos y programación,
quizá podemos conseguir el mejor producto de software. Para este modelo, se
requiere poca planificación. No sigue ningún proceso concreto, y a veces el
cliente no está seguro de las futuras necesidades y requisitos. Por tanto, la
entrada o input respecto a los requisitos es arbitraria. Este modelo no es
recomendable para grandes proyectos de software, pero es bueno para aprender y
experimentar.
Ø Tema 3: Identificación de diagramas UML
3.1 Concepto
de UML y objetivo
UML es un lenguaje con un alcance muy grande y que cubre diversos conjuntos de dominios arquitectónicos en el diseño de aplicaciones. Por ello, no todas sus capacidades de modelados son necesariamente útiles en todos los dominios o aplicaciones. UML permite seleccionar sólo aquellas partes del lenguaje que sean realmente útiles. El objetivo de UML es “proporcionar a desarrolladores de software, arquitectos de sistemas e ingenieros de software de herramientas para
el análisis, diseño e implementación de sistemas basados en software, así como
modelar procesos de negocio y similares. El modelado captura las partes
esenciales del sistema
3.2 Tipos de
diagramas de UML
Diagramas
de uso
Los Casos de
Uso no forma parte de la llamada Fase de Diseño, sino parte de la
fase de Análisis, respondiendo el interrogante ¿Qué?. De forma que
al ser parte del análisis ayuda a describir que es lo que el sistema
debe hacer.
Estos diagramas muestran operaciones que se esperan de una aplicación o
sistema y como se relaciona con su entorno, es por ello que se ve desde el
punto de vista del usuario. Describen un uso del sistema y como éste interactúa
con el usuario.
Los casos de usos se representan en el diagrama
por una elipses la cual denota un requerimiento solucionado por el sistema.
Diagrama de clases
En UML el diagrama de clases es
uno de los tipos de diagramas o símbolo estático y tiene como fin describir la
estructura de un sistema mostrando sus clases, atributos y relaciones entre
ellos.
Estos diagramas son utilizados durante el proceso
de análisis y diseño de los sistemas informáticos, en donde se intentan
conformar el diagrama conceptual de la información que se manejará en el
sistema.
Como ya sabemos UML es un modelado
de sistema Orientados a Objetos, por donde los conceptos de este paradigma se
incorporan a este lenguaje de modelado.
Los
diagramas de clases tienen las siguientes características:
·
Las clases define el ámbito de definición de un
conjunto de objetos.
·
Cada objeto pertenece a una clase.
·
Los objetos se crean por instanciación de las
clases.
Diagrama de objetos
Forma parte de la vista estática del sistema. En
este diagrama se modelan las instancias de las clases del Diagrama de Clases.
Este diagrama cabe aclarar que cuenta con objetos y enlaces. En estos diagramas
también es posible encontrar las clases para tomar como referencia su
instanciación.
En otras palabras,
el Diagrama de Objetos muestra un conjunto de objetos y sus relaciones en
un momento concreto. Los Diagramas de Objetos son realmente útiles para
modelar estructuras de datos complejas
Diagrama de Estados
Un estado es una condición durante la vida de un
objeto, de forma que cuando dicha condición se satisface se lleva a cabo alguna
acción o se espera por un evento.
El estado de un objeto se puede caracterizar
por el valor de uno o varios de los atributos de su clase, además,
el estado de un objeto también se puede caracterizar por la existencia de
un enlace con otro objeto.
El diagrama de estados engloba todos los mensajes
que un objeto puede enviar o recibir, en otras palabras es un escenario que
representa un camino dentro de un diagrama.
Como característica de estos diagramas siempre cuentan con dos estados
especiales, el inicial y el final, con la particularidad que este diagrama
puede tener solo un estado inicial pero varios estados finales.
Una transición entre estados representa un cambio de un estado origen a un
estado sucesor destino que podría ser el mismo que el estado origen, dicho
cambio de estado puede estar aparejado con alguna acción. Además, las
acciones se asocian a las transiciones y se consideran que ocurre de forma
rápida e interrumpible.
Los elementos que componen estos diagramas son:
Círculo lleno, apuntando el estado inicial.
· Círculo hueco que contiene un círculo lleno más
pequeño en el interior, indicando el estado final.
· Rectángulo redondeado dividido por una línea
horizontal, indicado los estados, en la parte de arriba se encuentra el nombre
del estado y abajo se indica la actividad que realiza.
·
Flecha, la cual denota la transición, el nombre del
evento que causa esta transición etiqueta el cuerpo de la flecha.
Diagrama de actividad
Un
Diagrama de Actividades representa un flujo de trabajo paso a paso de negocio y
operacionales de los componentes en un sistema.
En UML 1, un diagrama de actividades es una variación del Diagrama de Estados
UML donde los estados representan operaciones y las transiciones representan
las actividades que ocurren cuando la operación es completa.
En la actualidad, el diagrama de actividades en UML 2.0 es similar al aspecto
del diagrama en UML 1, solo que ahora la semántica está basada en lo que se
conoce como Redes de Petri. En UML 2.0, el diagrama general de interacción está
basado en el diagrama de Actividad.
Componentes:
·
Inicio: el inicio de un diagrama de actividades es
representado por un círculo de color negro sólido.
·
Actividad: Una actividad representa la acción que
será realizada por el sistema la cual representa dentro de un óvalo.
·
Transición: Una transición ocurre cuando se lleva
acabo el cambio de una actividad a otra, la transición es representada
simplemente por una línea con una flecha en su terminación para indicar su
dirección.
Diagrama de Secuencia
Un Diagrama de Secuencias muestra una interacción
ordenada según la secuencia temporal de eventos y el intercambio de
mensajes. Los diagramas diagramas de secuencia ponen especial énfasis en el
orden y el momento en el que se envían los mensajes a los objetos.
En los diagramas de Secuencias los
elementos están representados por líneas intermitentes verticales, con el
nombre del objeto en la parte más alta.
Los mensajes pueden ser o bien síncronos, el
tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta
que el método finalice, o asíncronos donde se devuelve el control directamente
al objeto que realiza la llamada.
Los mensajes síncronos tienen una caja vertical en un lateral del objeto
invocante que muestra el flujo del control del programa.
Diagrama de Colaboración
Un diagrama de colaboración, se puede decir que
es una forma alternativa al diagrama de secuencias a la hora de mostrar un
escenario.
Este tipo de diagrama muestra las interacciones que ocurren entre los objetos
que participan en una situación determinada.
A diferencia del diagrama de secuencia, el
diagrama de colaboración se enfoca en la relación entre los objetos y su
topología de comunicación.
Diagrama de componentes
Lo que
distingue el Diagrama de Componentes de otro tipo de
diagramas es sin duda su contenido. Normalmente contiene componentes,
interfaces y relaciones entre ellos. Los componentes perteneces a un
mundo físico, es decir, representan a un bloque de construcción al modelar
aspectos físicos de un sistema.
Cada
componente debe tener un nombre que lo distinga de los demás. Al igual que
las clases los componentes pueden enriquecerse con compartimientos adicionales
que muestran sus detalles.
Diagrama de Despliegue
Básicamente este
tipo de diagrama se utiliza para modelar el Hardware utilizado en la
implementación del sistema y la relaciones entre sus componentes.
Los elementos usados
por este tipo de diagrama son nodos, componentes y asociaciones. En el UML 2.0
los componentes ya no están dentro de nodos, en cambio puede
haber artefactos (archivo, un programa, una biblioteca o Base de datos) u
otros nodos dentro de nodos.
Además, los Diagramas de Despliegue muestran la
configuración en funcionamiento del sistema incluyendo su software y su
hardware. Para cada componente de un diagrama es necesario que se deba
documentar las características técnicas requeridas, el tráfico de red, el
tiempo de respuesta, etc.
3.3
Ejemplifica cada uno
- Clases
- Objetos
- Casos de uso
- De secuencia
- De colaboración
- De transición de estado
- De actividad
- De componentes
- De despliegue
- VÍDEO UML
