Professional Documents
Culture Documents
TRABAJO INVESTIGATIVO # 1
Presentado por:
INGENIERIA DE SOFTWARE
TRABAJO INVESTIGATIVO # 1
Presentado por:
DAMIAN SAMAEL TOVAR BOHRQUEZ 20132578120
SEBASTIN GAMBOA BAUTISTA 20131078091
FREDY ENRIQUE GALINDO OSMA 20132578018
JULIAN DAVID MRQUEZ FUENTES - 20122078213
Presentado a:
JUAN CARLOS GUEVARA BOLAOS
Introduccin
Hoy en da, el software es una parte integral de la mayora de los sistemas. Para
ejecutar proyectos software de forma satisfactoria y construir productos de alta
calidad, los profesionales del software necesitan entender las caractersticas nicas
del software y el enfoque usado para desarrollar y mantener software. Este curso
permitir entender qu es el software y cules son los objetivos y componentes de la
ingeniera del software, as como entender los conceptos de ciclo de vida del software
y metodologa. Adems, se vern los principales modelos de ciclo de vida del software
y la diferenciacin entre metodologas tradicionales y giles.
Ingeniera de Software
Definicin
La ingeniera del software es una disciplina de la ingeniera que comprende los
aspectos de la produccin del software desde el inicio hasta el mantenimiento,
existen dos frases claves:
1. Disciplina de la ingeniera: Todo ingeniero aplica teoras, mtodos y
herramientas, que utilizan de una forma selectiva para poder solucionar
el problema, tambin tienen restricciones en su trabajo, restricciones
financieras y organizacionales.
2. Todos los aspectos de la produccin de software: Esta rama no solo
comprende los procesos tcnicos de un desarrollo de software, sino que
tambin actividades de gestin de proyectos y desarrollo de
herramientas.
En conclusin, los ingenieros de software tienen un enfoque sistemtico y
organizado, ya que esta es la forma ms efectiva de crear un software de alta
calidad.
Ingeniera del Software es la aplicacin prctica del conocimiento cientfico en el
diseo y construccin de programas de computadora y la documentacin asociada
requerida para desarrollar, operar y mantenerlos. Se conoce tambin como
desarrollo de software o produccin de software.
Objetivos
Caractersticas
Historia
Durante los primeros aos de la informtica, el software era un aadido. La
programacin se consideraba un "arte", para el que no existan metodologas, era
un proceso que se realizaba sin planificacin alguna, la programacin se
desarrollaba a medida para cada necesidad concreta, y en consecuencia tena
muy poca difusin.
En una segunda poca se estableci el software como producto y aparecieron las
empresas dedicadas al desarrollo y distribucin masiva del mismo. El origen del
El software en la actualidad
Hoy en da el software tiene un doble papel. Es un producto, pero simultneamente es
el vehculo para hacer entrega de un producto. Como producto permite el uso del
hardware, ya sea, por ejemplo, un ordenador personal o un telfono mvil celular. El
software hace entrega de lo que se considera como el producto ms importante del
siglo veintiuno, la informacin. Este transforma datos personales para que sean ms
tiles en un entorno local, gestiona informacin comercial para mejorar la
competitividad, proporciona el acceso a redes a nivel mundial, y ofrece el medio de
adquirir informacin en todas sus formas.
Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se
desarrolla un proyecto de desarrollo de software.
Modelo Cascada
Es el modelo ms bsico y ha servido como bloque de construccin para los
dems paradigmas de ciclo de vida. Est basado en el ciclo convencional de una
ingeniera y su visin es muy simple: el desarrollo de software se debe realizar
siguiendo una secuencia de fases. Cada etapa tiene un conjunto de metas bien
definidas y las actividades dentro de cada una contribuyen a la satisfaccin de
metas de esa fase o quizs a una sub secuencia de metas de la misma. El
arquetipo del ciclo de vida abarca las siguientes actividades:
1.
2.
3.
4.
5.
6.
7.
Anlisis de requisitos.
Diseo del Sistema.
Diseo del Programa.
Codificacin.
Pruebas.
Implantacin.
Mantenimiento.
Funcionamiento
Anlisis de requerimientos
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada
SRD (documento de especificacin de requisitos), que contiene la especificacin
completa de lo que debe hacer el sistema sin entrar en detalles internos.
Es importante sealar que en esta etapa se debe consensuar todo lo que se
requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no
pudindose requerir nuevos resultados a mitad del proceso de elaboracin del
software.
Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos,
as como de pruebas y ensayos para corregir errores.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de
ser entregado al usuario final.
Verificacin
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el sistema
no falle.
En la creacin de desarrollo de cascada se implementa los cdigos de
investigacin y pruebas del mismo
Mantenimiento
Una de las etapas ms crticas, ya que se destina un 75% de los recursos, es el
mantenimiento del Software ya que al utilizarlo como usuario final puede ser que
no cumpla con todas nuestras expectativas.
Modelo Espiral
El desarrollo en espiral es un modelo de ciclo de vida del software definido por
primera vez por Barry Boehm en 1986 dndole la direccin nueva al modelo en el
cual fue incorporar los puntos fuertes y evitar las dificultades de otros modelos
desplazando el nfasis de administracin hacia la evaluacin y resolucin del
riesgo. De esta manera se permite tanto a los desarrolladores como a los clientes
detener el proceso cuando se lo considere conveniente, utilizado generalmente en
la Ingeniera de software.
Las actividades de este modelo se conforman en una espiral, en la que cada
bucle o iteracin representa un conjunto de actividades. Las actividades no estn
fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis
de riesgo, comenzando por el bucle interior.
Funcionamiento
Funcionamiento
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta
frecuencia.
- El usuario se involucra ms.
- Difcil de evaluar el coste total.
- Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a
operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Pipeline
La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo
de datos en un proceso comprendido por varias fases secuenciales, siendo la
entrada de cada una la salida de la anterior.
Esta arquitectura es muy comn en el desarrollo de programas para el intrprete
de comandos, ya que se pueden concatenar comandos fcilmente con tuberas
(pipe). Tambin es una arquitectura muy natural en el paradigma de programacin
funcional, ya que equivale a la composicin de funciones matemticas.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos
obtenidos del usuario por medio de una interfaz alfanumrica.
Caractersticas
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta
frecuencia.
- El usuario se involucre ms.
- Difcil de evaluar el costo total.
- Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a
operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Modelo Prototipo
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se
construyan rpidamente para comprender con facilidad y aclarar ciertos aspectos en
los que se aseguren que el desarrollador, el usuario, el cliente estn de acuerdo en lo
que se necesita as como tambin la solucin que se propone para dicha necesidad y
de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se
encarga del desarrollo de diseos para que estos sean analizados y prescindir de
ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el
alcance del producto ,pero no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto de
objetivos generales para el software a desarrollarse sin delimitar detalladamente los
requisitos de entrada procesamiento y salida, es decir cuando el responsable no
Funcionamiento
Metodologa RUP
Qu es?
La metodologa RUP o Proceso Unificado Racional (Rational Unified Process), es
un proceso de ingeniera de software que est orientado a la asignacin de tareas
y roles dentro de un proyecto de desarrollo. Esta metodologa tiene como objetivo
principal asegurar un desarrollo de software ptimo para as poder cumplir todas
las necesidades que tiene el usuario previsto en un lmite de tiempo acordado y
con un presupuesto manejable o previsible.
Por qu usarla?
La metodologa RUP es una metodologa que es muy completa y extensa que al
estar orientada a la asignacin de roles y tareas permite una mejor organizacin
en cualquier proyecto pequeo de software que dure algunos meses hasta a un
proyecto de software de gran escala que dure aos.
Qu caractersticas tiene esta metodologa?
La metodologa RUP consta de las siguientes caractersticas:
- Es dirigida por casos de uso: Los casos de uso son implementados para capturar
los requisitos de importancia que tiene el usuario, no solo desde el punto de vista
de funcionalidad del sistema que vayamos a realizar, sino tambin de los actores
que se vern identificados en el uso del mismo. Adems, la implementacin de los
casos de uso nos ayuda en la gua del diseo que le dar al sistema, en su
implementacin y en la verificacin de pruebas que se le hagan al mismo.
En la siguiente figura podemos ver el papel fundamental que cumplen los casos de
uso en la metodologa RUP:
En la anterior imagen podemos ver que los casos de uso no solo inician el proceso de
desarrollo, sino que se une o encadena a otros procesos, como lo son su anlisis,
diseo, su implementacin y respectivas pruebas segn el sistema a desarrollar.
Qu fases tiene?
La metodologa RUP consta de las siguientes fases:
Fase de Inicio
Fase de Elaboracin
Fase de desarrollo
Fase de cierre.
Fase de Inicio: Durante esta fase se define el modelo del negocio y el alcance que
le queremos dar a nuestro proyecto. Es aqu donde hacemos los diferentes casos
de uno e identificamos los actores que intervienen y los roles que realizan en el
mismo, adems de realizar el desarrollo del plan de negocio donde se va a
determinar el uso y asignacin de recursos para el desarrollo del proyecto.
Esta fase tiene como objetivos finales los siguientes:
- Establecer el mbito del proyecto, as como sus lmites.
- Realizar los casos de uso fundamentales para el sistema adems de definir los
escenarios bsicos de funcionalidad.
- Mostrar arquitecturas candidatas para el desarrollo de los escenarios principales.
Prototipo Operacional
Documentos Legales
Caso del Negocio Completo
Lnea de Base del Producto completa y corregida que incluye todos los
modelos del sistema
Descripcin de la Arquitectura completa y corregida
Las iteraciones de esta fase irn dirigidas normalmente a conseguir una
nueva versin
Metodologa XP
Qu es?
La metodologa XP o Programacin Extrema (Extreme Programming) es una
metodologa gil centrada en las relaciones interpersonales, el trabajo en equipo,
el continuo aprendizaje de los integrantes de trabajo, dar soluciones sencillas a los
problemas planteados pero que estas cumplan con la solucin completa de los
mismos.
Por qu usarla?
Es conveniente usar la metodologa XP porque es una metodologa liviana,
queriendo decir esto que es muy fcil de manejar y dar rpidos resultados,
adems de manejar un conjunto de prcticas para el desarrollo de software
tambin est basada en diferentes ideas acerca de cmo enfrentar un problema
en ambientes cambiantes y, para terminar es una metodologa que en vez de
planificar y analizar todo el diseo, arquitectura y lgica de desarrollo, lo va
haciendo un poco cada vez mientras se va avanzando en el proyecto siendo agiles
en el manejo de riesgos que pongan en peligro el proyecto.
Qu caractersticas tiene esta metodologa?
La metodologa XP tiene las siguientes caractersticas:
- Es una metodologa basada en prueba y error para obtener un software que
realmente funcione: Es decir, consiste en probar una alternativa y verificar si
funciona; si esta funciona entonces, ya se tiene una solucin. En caso contrario es
necesario probar una nueva alternativa. Se usa este mtodo porque es un mtodo
orientado a soluciones, es decir, que no se intenta descubrir porque funciona la
alternativa, simplemente solo se busca alcanzar la solucin; se busca la solucin a
un problema especfico y no a problemas externos o adicionales, pero es costoso
debido a que se necesitan varios medios para poder llegar a una solucin que
quizs es posible no encontrarla.
-
Est orientada hacia quien produce y usa el software: Es decir, que se tiene
mucho en cuenta al cliente y/o usuario, haciendo ellos parte del equipo de
trabajo que colaborara con la solucin del problema.
Combina las mejores prcticas de desarrollo de software llevndolas al
extremo, de ah el nombre de la metodologa.
Los requisitos del sistema pueden cambiar sin que exista un alto riesgo de
prdida de recursos puesto que no se analiza a futuro como habamos
dicho anteriormente, sino que se va haciendo a medida que le damos
avance al proyecto.
Es una excelente metodologa para pequeos proyectos y se suele trabajar
de a pares teniendo un mximo de 12 integrantes de trabajo.
El equipo de trabajo tiene la oportunidad de ampliar sus conocimientos
continuamente.
Qu fases tiene?
La metodologa XP consta de 4 fases principales que son:
Fase de planificacin del proyecto: Esta fase est delimitada por las siguientes
prcticas:
- Historias de usuario: El primer paso a realizar en cualquier proyecto de
software que se desarrolle con esta metodologa debe empezar en definir la
historia del usuario con el cliente. Estas historias tienen la misma finalidad que
los casos de uso pero con la diferencia de que no se toman en cuenta los
detalles y se toma desde el punto de vista del cliente, es decir, en un lenguaje
que no es tcnico. Esto se hace con el fin de estimar tiempos de desarrollo con
lo que el cliente describe en su escrito.
- Release Planning: es una planificacin donde los desarrolladores y clientes
establecen tiempo de implementacin ideales en base a la historia del usuario,
la prioridad con que ser implementada y el tiempo en que tardara en
publicarse las diferentes versiones del programa y se especifica de qu
manera ser evaluado el trabajo desarrollado.
- Iteraciones: La metodologa XP suele desarrollarse en iteraciones de 3
semanas aproximadamente. En cada iteracin los clientes seleccionan las
historias de usuario definidas en el punto anterior.
- Velocidad del proyecto: Es una medida que representa la rapidez con que se
desarrolla un proyecto. Calcularla es muy fcil porque se cuenta el nmero de
historias de usuario que pueden ser implementadas, as sabiendo el nmero de
historias que podrn ser desarrolladas en cada iteracin. Esta etapa se
reevala cada 3 o 4 iteraciones puesto que estn sujetas al cambio.
Fase de diseo: Esta fase est delimitada por las siguientes prcticas:
- Diseos simples: Se busca hacer todo lo menos complicado posible para
conseguir un diseo fcilmente entendible e implementarle que necesite menos
tiempo y esfuerzo para desarrollarlo.
- Glosario de trminos: Usar glosarios de trminos y una correcta especificacin
de los nombres de mtodos y clases ayudar a comprender el diseo y
facilitar sus posteriores ampliaciones y la reutilizacin del cdigo.
- Riesgos: Se sugiere que unas pajeras de desarrolladores estn dedicadas
solamente a investigar y reducir lo mximo posible el o los riesgos que se
puedan presentar en la solucin del problema.
- Funcionalidad extra: No se toma en cuenta una funcionalidad extra debido a
que segn esta metodologa, el desarrollo de esta funcionalidad requiere un
desperdicio de tiempo y recursos en una funcionalidad que probablemente no
vaya a ser tomada en cuenta.
- Refactorizar: Esto se realiza con el fin de modificar y mejorar la estructura y
codificacin de cdigos ya creados sin alterar su funcionalidad. En pocas
palabras, es volverlos a revisar para poderlos optimizar dado el caso.
- Tarjetas C.R.C: El uso de tarjetas de clases, responsabilidades y colaboracin
permiten al programador centrarse y apreciar el desarrollo orientado a objetos
olvidndose as de la programacin clsica.
Fase de codificacin: Como ya habamos comentado en la fase de planificacin
del proyecto, el cliente es una parte ms del equipo de desarrollo; su presencia es
indispensable en las distintas fases de XP. A la hora de codificar una historia de
usuario su presencia es an ms necesaria. No olvidemos que los clientes son los
que crean las historias de usuario y negocian los tiempos en los que sern
implementadas. Antes del desarrollo de cada historia de usuario el cliente debe
especificar detalladamente lo que sta har y tambin tendr que estar presente
cuando se realicen los test que verifiquen que la historia implementada cumple la
funcionalidad especificada.
Se deben crear las aplicaciones que realizarn los test con un entorno de
desarrollo especfico para test.
Hay que someter a test las distintas clases del sistema omitiendo los mtodos
ms triviales.
Se deben crear los test que pasarn los cdigos antes de implementarlos.
Un punto importante es crear test que no tengan ninguna dependencia del
cdigo que en un futuro evaluar. Hay que crear los test abstrayndose del
futuro cdigo, de esta forma aseguraremos la independencia del test respecto
al cdigo que evala.
El uso de los test es adecuado para observar la refactorizacin. Los test
permiten verificar que un cambio en la estructura de un cdigo no tiene por qu
cambiar su funcionamiento.
Test de aceptacin: Los test mencionados anteriormente sirven para evaluar
las distintas tareas en las que ha sido dividida una historia de usuario.
Para asegurar el funcionamiento final de una determinada historia de usuario
se deben crear "Test de aceptacin"; estos test son creados y usados por los
clientes para comprobar que las distintas historias de usuario cumplen su
cometido.
Al ser las distintas funcionalidades de nuestra aplicacin no demasiado
extensas, no se harn test que analicen partes de las mismas, sino que las
pruebas se realizarn para las funcionalidades generales que debe cumplir el
programa especificado en la descripcin de requisitos.
Metodologa MSF
Qu es?
Microsoft Solutions Framework (MSF) es un enfoque personalizable para entregar
con xito soluciones tecnolgicas de manera ms rpida, con menos recursos
humanos y menos riesgos, pero con resultados de ms calidad. MSF ayuda a los
equipos de trabajo a enfrentarse directamente a las causas ms habituales de
fracaso de los proyectos de software y tecnolgicos en general, con el fin de
mejorar las tasas de xito de las empresas y as como su calidad en las
soluciones planteadas.
Por qu usarla?
Es viable usar la metodologa MSF porque tiene como objetivos principales alinear los
objetivos del negocio por medio del uso de la tecnologa, adems de establecer de
manera clara los objetivos, roles y responsabilidades a cada uno de los integrantes
del equipo de trabajo. Tambin implementa un proceso iterativo controlados por hitos
(puntos de control), gestionar los riesgos de manera proactiva y, por ultimo responder
con eficacia ante los cambios que puedan presentarse.
Qu caractersticas tiene?
La metodologa MSF consta de las siguientes caractersticas:
-
Fomentar una comunicacin abierta. Para que el equipo sea eficaz y eficiente,
tanto usted como su equipo deben compartir niveles de informacin apropiados
entre los miembros del equipo y en toda la empresa. El equipo debe comprender
la naturaleza de lo que se debe hacer y el modo en que se comunican los
miembros del equipo y los contactos externos. Lo difcil es determinar un nivel
apropiado para cada relacin y qu informacin se debe compartir.
Intentar lograr una visin compartida. El hecho de tener una visin compartida
empodera a los miembros del equipo y les permite actuar con agilidad para
poder tomar decisiones rpidas pero bien fundadas con el objetivo de lograr
una visin. Al tener una visin compartida, los miembros del equipo pueden ir
satisfaciendo los requisitos a medida que se vayan detectando.
Empodere a los miembros del equipo. Empoderar a los miembros del equipo no
solo es una de las muchas maneras de sobrevivir en un entorno en constante
cambio, sino que los miembros del equipo tambin aprenden a encontrar modos
de alcanzar el xito de manera creativa y a ayudarse unos a otros. Si no se
Qu fases tiene?
A continuacin, tomaremos el siguiente cuadro para visualizar y entender cada una de
las fases y procesos realizados en la metodologa MSF, as como sus resultados.
Metodologa SCRUM
Qu es?
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas
prcticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene
origen en un estudio de la manera de trabajar de equipos altamente productivos.
Qu caractersticas tiene?
La metodologa SCRUM consta de las siguientes caractersticas generales:
-
Qu fases tiene?
La metodologa SCRUM consta de las siguientes fases:
- Planificacin o pre - juego
- Desarrollo de Sprints o juego
- Cierre o Post - Juego
Pre Juego: Definicin de una nueva versin basada en la pila actual, junto con
una estimacin de coste y agenda. Si se trata de un nuevo sistema, esta fase
abarca tanto la visin como el anlisis. Si se trata de la mejora de un sistema
existente comprende un anlisis de alcance ms limitado. Arquitectura: Diseo de
la implementacin de las funcionalidades de la pila. Esta fase incluye la
modificacin de la arquitectura y diseo generales.
En esta fase se obtienen los siguientes resultados:
- Desarrollo de un backlog completo.
- Determinacin de la fecha de entrega y la funcionalidad de una o ms versiones.
- Seleccin de la versin ms adecuada para desarrollo inmediato.
- Trazado de los paquetes del producto (objetos) sobre los elementos del backlog
de la versin elegida.
- Seleccin del equipo o equipos para desarrollar la nueva versin.
- Evaluacin y control adecuado de los riesgos.
- Estimacin del coste de la versin, incluyendo desarrollo, material, marketing,
formacin y despliegue.
- Conformidad de la direccin y financiacin del proyecto.
Post Juego: Cuando el equipo de gestin siente que las variables de tiempo,
parte completada, requisitos, coste y calidad estn alineadas para producir una
nueva versin, declaran cerrada la versin, dando paso a esta fase. En esta fase
se prepara el producto generado para producir una nueva versin. Entre las tareas
de cierre se encuentran: integracin, pruebas del sistema, documentacin de
usuario, preparacin del material de formacin y marketing.
Metodologa FDD
Qu es?
La metodologa FDD o Desarrollo impulsado por la Funcin (Feature Driven
Development), es una metodologa gil para el desarrollo de sistemas, basado en
la calidad del software, que incluye un monitoreo constante del sistema. Como las
otras metodologas adaptables, se enfoca en iteraciones cortas que entregan
funcionalidad tangible Dicho enfoque no hace nfasis en la obtencin de los
requerimientos sino en cmo se realizan las fases de diseo y construccin. Sin
embargo, fue diseado para trabajar con otras actividades de desarrollo de
software y no requiere la utilizacin de ningn modelo de proceso especfico.
Adems, hace nfasis en aspectos de calidad durante todo el proceso e incluye un
monitoreo permanente del avance del proyecto. Al contrario de otras
metodologas, FDD afirma ser conveniente para el desarrollo de sistemas crticos.
Por qu usarla?
Es pertinente usar la metodologa FDD porque el equipo de desarrollo no malgasta
el tiempo y dinero del cliente desarrollando soluciones innecesariamente
generales y complejas que en realidad no son un requisito del mismo, adems que
cada componente final que est en el desarrollo ha sido probado y tambin
satisface los requerimientos dados por el cliente. Al ser una metodologa gil, esta
permite el continuo cambio de requisitos (si as se requiere); tambin minimiza los
costos y una de sus ventajas ms grandes es que involucran al cliente dentro del
proceso junto con el equipo de desarrollo.
Qu caractersticas tiene?
La metodologa FDD consta de las siguientes caractersticas:
-
Qu fases tiene?
La metodologa FDD cuenta con 4 fases secuenciales que nombraremos a
continuacin:
Desarrollo del modelo general: Cuando esta fase comienza, los expertos del
dominio ya tienen una idea del contexto y los requerimientos del sistema. Es
probable que el documento de especificacin de requerimientos ya exista. Sin
embargo, FDD no hace nfasis en la recoleccin y administracin de los
requerimientos. Los expertos del dominio presentan un informe llamado
walkthrough en el cual los miembros del equipo son informados a travs de una
descripcin de alto nivel del sistema.
Construccin de lista de rasgos: Los walkthroughs, el modelo de objetos y los
requerimientos existentes ofrecen una buena base para construir una construccin
de lista de rasgos que resuma la funcionalidad del sistema a ser desarrollado. En
dicha lista, el equipo de desarrolladores presenta cada una de las funcionalidades
evaluadas por el cliente.
Metodologa DSDM
Qu es?
El DSDM o Mtodo de Desarrollo de Sistemas Dinmicos (Dinamic Systems
Deveploment Method) es una metodologa de desarrollo de software originalmente
basado en la metodologa de Desarrollo de Aplicacin Rpida. DSDM es un
acercamiento reiterativo e incremental que acenta el envolvimiento del usuario
continuo. Su meta es entregar los sistemas del software a tiempo y en el
presupuesto mientras ajustando para los requisitos cambiantes a lo largo del
proceso de desarrollo.
Por qu usarla?
Es pertinente usar esta metodologa porque la calidad del producto es mejorada a
travs de la participacin de los usuarios a lo largo del ciclo de vida del proyecto y
la naturaleza iterativa del desarrollo, adems de asegurar desarrollos rpidos.
Tambin reduce los costos de proyectos a travs de las ventajas mencionadas
anteriormente y, por ltimo, permite realizar cambios de forma muy sencilla.
Qu caractersticas tiene?
La metodologa DSDM cuenta con las siguientes caractersticas generales:
-
Todos los cambios pueden ser reversibles, es decir que se puede volver a
un punto base pre definido si las cosas no salen bien. Esto con el fin de
manejar los riesgos presentes en proyectos de este tipo.
Se realiza una verificacin de calidad a lo largo del proceso de desarrollo y
no solo al final.
En esta metodologa no existen contra tiempos
Qu fases tiene?
La metodologa DSDM cuenta con 3 fases principales que son las siguientes:
PARADIGMAS DE PROGRAMACIN
Definicin
-Ejemplo o ejemplar.
Teora o conjunto de teoras cuyo ncleo centralse acepta sin cuestionar y que
suministra la base ymodelo para resolver problemas y avanzar en elconocimien
to. El paradigma newtoniano.
Un paradigma de programacin indica un mtodo de realizar cmputos y la
manera en que se deben estructurar y organizar las tareas que debe llevar a cabo
un programa. Un paradigma de programacin provee (y determina) la visin y
mtodos de un programador en la construccin de un programa o subprograma.
Los paradigmas fundamentales estn asociados a determinados modelos de
cmputo. Tambin se asocian a un determinado estilo de programacin.
Los lenguajes de programacin suelen implementar, a menudo de forma parcial,
varios paradigmas.
TIPOS DE PARADIGMAS
Los paradigmas fundamentales estn basados en diferentes modelos de cmputo
y por lo tanto afectan a las construcciones ms bsicas de un programa.
La divisin principal reside en el enfoque imperativo (indicar el cmo se debe
calcular) y el enfoque declarativo (indicar el qu se debe calcular).
El enfoque declarativo tiene varias ramas diferenciadas: el paradigma funcional, el
paradigma lgico, la programacin reactiva y los lenguajes descriptivos.
Otros paradigmas se centran en la estructura y organizacin de los programas, y
son compatibles con los fundamentales:
Ejemplos: Programacin estructurada, modular, orientada a objetos,
orientada a eventos, programacin genrica.
Por ltimo, existen paradigmas asociados a la concurrencia y a los sistemas de
tipado.
Habitualmente se mezclan todos los tipos de paradigmas a la hora de hacer la
programacin. De esa manera se origina la programacin multiparadigma, pero el
que actualmente es ms usado de todos esos paradigmas es el de la
programacin orientada a objetos.
Para poder describir todos los objetos de un programa, conviene agrupar stos en
clases.
Clase: Podemos considerar una clase como una coleccin de objetos que poseen
caractersticas y operaciones comunes. Una clase contiene toda la informacin
necesaria para crear nuevos objetos.
Encapsulacin: Es una tcnica que permite localizar y ocultar los detalles de un
objeto. La encapsulacin previene que un objeto sea manipulado por operaciones
distintas de las definidas. La encapsulacin es como una caja negra que esconde
los datos y solamente permite acceder a ellos de forma controlada.
Las principales razones tcnicas para la utilizacin de la encapsulacin son:
1) Mantener a salvo los detalles de representacin, si solamente nos interesa el
comportamiento del objeto.
2) Modificar y ajustar la representacin a mejores soluciones algortmicas o a
nuevas tecnologas de software.
Abstraccin: En el sentido ms general, una abstraccin es una representacin
concisa de una idea o de un objeto complicado. En un sentido ms especfico, la
abstraccin localiza y oculta los detalles de un modelo o diseo para generar y
manipular objetos. Una abstraccin tiene un significado ms general que la
encapsulacin, pudiendo hablar de abstraccin de datos en lugar de
encapsulacin de datos.
Objetos: Un objeto es una entidad lgica que contiene datos y un cdigo que
manipula estos datos; el enlazado de cdigo y de datos, de esta manera suele
denominarse encapsulacin. Cuando se define un objeto, se est creando
implcitamente un nuevo tipo de datos.
Polimorfismo: Significa que un nombre se puede utilizar para especificar una clase
genrica de acciones.
Herencia: La herencia es un proceso mediante el cual un objeto puede adquirir las
propiedades de otro objeto.
Clase: Las clases son declaraciones de objetos, tambin se podran definir como
abstracciones de objetos. Esto quiere decir que la definicin de un objeto es la
clase. Cuando programamos un objeto y definimos sus caractersticas y
funcionalidades en realidad lo que estamos haciendo es programar una clase. En
los ejemplos anteriores en realidad hablbamos de las clases coche o fraccin
porque slo estuvimos definiendo, aunque por encima, sus formas.
Propiedades en clases
Las propiedades o atributos son las caractersticas de los objetos. Cuando
definimos una propiedad normalmente especificamos su nombre y su tipo. Nos
podemos hacer a la idea de que las propiedades son algo as como variables
donde almacenamos datos relacionados con los objetos.
Mtodos en las clases
Son las funcionalidades asociadas a los objetos. Cuando estamos programando
las clases las llamamos mtodos. Los mtodos son como funciones que estn
asociadas a un objeto.
6.3 Ejemplo 1
Ejemplo 2
Un perro es un objeto.
Los objetos tienen dos caractersticas: Un estado y un comportamiento. Podemos
fijarnos que por ejemplo un perro tiene un estado: nombre, color, raza, altura, etc.
y un comportamiento: ladrar, cavar pozo, llorar, dormir, comer, etc.
Podramos tener la clase Perro, una instancia de esta clase podra ser el objeto
perro llamado "Chicho". La clase Perro especificara que todos los perros tendran
un nombre, color de pelo, una altura. Mientras que la instancia "Chicho" contendr
valores especficos para cada uno de estos atributos.
6.1 Programacin orientada a eventos
6.2 La programacin dirigida por eventos es un paradigma de programacin en el
que tanto la estructura como la ejecucin de los programas van determinados por
los sucesos que ocurran en el sistema, definidos por el usuario o que ellos mismos
provoquen.
Para entender la programacin dirigida por eventos, podemos oponerla a lo que
no es: mientras en la programacin secuencial (o estructurada) es el programador
el que define cul va a ser el flujo del programa, en la programacin dirigida por
eventos ser el propio usuario o lo que sea que est accionando el programa
el que dirija el flujo del programa. Aunque en la programacin secuencial puede
haber intervencin de un agente externo al programa, estas intervenciones
ocurrirn cuando el programador lo haya determinado, y no en cualquier momento
como puede ser en el caso de la programacin dirigida por eventos.
El creador de un programa dirigido por eventos debe defi- nir los eventos que
manejarn su programa y las acciones que se realizarn al producirse cada uno
de ellos, lo que se conoce como el administrador de evento. Los eventos
soportados estarn determinados por el lenguaje de programacin utilizado, por el
sistema operativo e incluso por eventos creados por el mismo programador. En la
programacin dirigida por eventos, al comenzar la ejecucin del programa se
llevarn a cabo las inicializaciones y dems cdigo inicial y a continuacin el
Otros
AS3
Bibliotecas
C y C++
Qt
GTK+
Java
AWT
Swing
SWT
Web
ASP.NET (Mediante Javascript con el Modelo Code-behind)
6.3 Ejemplo
Ejemplo de programa orientado a eventos en pseudo lenguaje:
While (true) {
Switch (event) {
case mousse_button_down:
case mouse_click:
case keypressed:
case Else:
}
}
Ejemplo 2
Ejemplo 2
EL PERSONAL
El factor humano siempre ser el ms importante en el desarrollo de soluciones
software, muchos empresarios famosos, lderes de empresas tecnolgicas,
coinciden que el xito que han alcanzado sus empresas no se debe a las
herramientas que utilizan, es la gente y el trabajo en equipo.
EL PRODUCTO
Muchas veces cuando un cliente pide que le construyan una solucin, siempre
pregunta cunto me va a costar? Pues bien, todo producto requiere estimaciones
cuantitativas y una adecuada planificacin. Una adecuada recoleccin de
informacin y un anlisis detallado de los requerimientos proporciona la
informacin necesaria para dar una estimacin del costo del producto. Antes de
planear un proyecto, se debe establecer los objetivos y el alcance que tendr el
proyecto, adems de sus restricciones tcnicas y de gestin. Con una buena
planificacin se puede estimar el tiempo que tomar desarrollar o construir el
producto y redimensionar el valor cuantitativo del producto.
EL PROCESO
El proceso del software proporciona un marco de trabajo desde el cual se puede
establecer un plan detallado para la construccin del software. Todas las
actividades del marco de trabajo se las pueden aplicar a la mayora de proyectos
de software, sino es a todos. El equipo de desarrollo debe elegir el proceso
adecuado y que le permita obtener una solucin o producto que satisfaga las
necesidades o requerimientos del cliente.
EL PROYECTO
Cuando se gestiona un proyecto exitoso, es necesario entender que este puede
llegar a fracasar. Segn John Reel, existen 10 razones por las cuales un proyecto
puede fracasar:
1. El personal de software no entiende las necesidades de los clientes.
2. El mbito del producto est mal definido.
3. Los cambios se gestionan mal.
4. La tecnologa elegida cambia.
5. Las necesidades comerciales cambian.
6. Los plazos de entrega no son realistas.
7. Los usuarios se resisten a la utilizacin del software.
8. Se pierde el patrocinio.
9. El equipo del proyecto carece de personal con las habilidades apropiadas.
10. Los gestores evitan las mejores prcticas y las lecciones aprendidas.
Conclusiones
-
Bibliografa
-
5
ciclos
de
vida
del
Software.
Extrado
http://es.slideshare.net/rockrlos/5-ciclos-de-vida-del-softwarefixed
- Sistemas
de
Software.
http://aposta.uv.es/givaro/modulo/Ciclo.htm
Extrado
de:
de:
Ciclo de Vida del Software NTP 12207 [en lnea]. 11 febrero 2016. Disponible
en:https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=
8&cad=rja&uact=8&ved=0ahUKEwi4g4vxgfnKAhXIWSYKHTt_DCUQFghK
MAc&url=http%3A%2F%2Fwww.ongei.gob.pe%2Feventos%2FProgramas_
docu%2F135%2FPrograma_1264.ppt&usg=AFQjCNHfFxUmQCAkHET3nro
zolEKcFPxtg
Rational
Unified
Process
(RUP).Extrado
de:
http://ima.udg.edu/~sellares/EINFES2/Present1011/MetodoPesadesRUP.pd
f
Metodologa
XP.
Extrada
http://es.slideshare.net/Piskamen/metodologa-xp
Fases
de
la
Programacin
Extrema:
http://programacionextrema.tripod.com/fases.htm
Extrado
de:
de:
Extrado
de:
FDD:
Feature
Driven
Depveloment.
http://ingenieriadesoftware.mex.tl/61162_FDD.html
Dynamic
Systems
Development
Method.
Extrado
de:
http://ingenieriadesoftware.mex.tl/images/18149/DSDM%20documento.pdf
Objetivos
de
la
Ingeniera
de
Software.
Extrado
http://www.etsisi.upm.es/estudios/grados/software/objetivos
Proyectos
de
desarrollo
de
Software.
Extrado
de:
http://arantxa.ii.uam.es/~proyectos/teoria/C5_Proyectos%20de%20desarroll
o%20software.pdf
Extrado
de:
de: