Instituto Privado Tecnológico Spencer W. Kimball
Bachiller Industrial y Perito en Computación
Quinto Grado
Curso: Análisis de Sistemas.
Cat: Álvaro Martínez
Tema: Metodologías para el desarrollo de software
Nombre: Delvin Estuardo Félix Torres
Sección: Única
Clave: 4
Carnet: 21CP
Fecha: 20/05/2015
Introducción.
En el siguiente trabajo veremos la utilidad de las metodologías las cuales se
basan en una combinación de los modelos de proceso genéricos (cascada,
evolutivo, incremental, espiral entre otros).los cuales no son de mucha utilidad
para la precisión los artefactos, roles y actividades involucrados en el desarrollo
de software.
Contenido METODOLOGÍAS PARA DESARROLLO DE SOFTWARE ...........................................1
Ciclo de vida del software ..............................................................................................6
Modelos de ciclo de vida ...................................................................................................7
Modelo en cascada ......................................................................................................7
Modelo V ....................................................................................................................... 8
METODOLOGÍA RUP ...................................................................................................... 9
Fases de desarrollo del software…………………………………………………………9
TIPOS………………………………………………………………………………………….10
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
1 DELVIN ESTUARDO FELIX TORRES
METODOLOGÍAS PARA DESARROLLO DE SOFTWARE
Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, espiral entre otros).
Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas,
guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o
algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si
tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las
metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del
proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o también denominadas
Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños,
hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso.
A continuación se revisan brevemente cada una de estas categorías de metodologías: METODOLOGÍAS ESTRUCTURADAS
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron
técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan
para la implementación lenguajes de 3ra y 4ta generación. Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE
(Francia), MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & Demarco e Information Engineering.
METODOLOGÍAS ORIENTADAS A OBJETOS Su historia va unida a la evolución de los lenguajes de programación orientada
a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
2 DELVIN ESTUARDO FELIX TORRES
actualmente Java o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que
posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación Orientada a Objetos más popular en la actualidad.
Algunas metodologías orientadas a objetos que utilizan la notación UML son:
Rational Unified Process (RUP),
OPEN,
MÉTRICA (que también soporta la notación estructurada).
METODOLOGÍAS TRADICIONALES Las metodologías no ágiles son aquellas que están guiadas por una fuerte
planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.
Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el
especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.
METODOLOGÍAS ÁGILES Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y
desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y
modificar, bien documentado), y adaptable (permite realizar cambios de último momento). Entre las metodologías ágiles identificadas son:
Extreme Programming
Scrum
Familia de Metodologías Crystal
Feature Driven Development
Proceso Unificado Rational, una configuración ágil
Dynamic Systems Development Method
Adaptive Software Development
Open Source Software Development
SEGUIDAMENTE DETALLAREMOS LAS SIGUIENTES METODOLOGÍAS PARA DESARROLLO DE SOFTWARE:
Rational Unified Process (RUP)
Extreme Programming (XP)
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
3 DELVIN ESTUARDO FELIX TORRES
SCRUM
Como se explicó en el concepto anterior, un modelo para el desarrollo de
software es una representación abstracta de un proceso. Cada modelo representa un proceso desde una perspectiva particular y así proporcione
información parcial sobre el proceso. Éstos modelos generales no son descripciones definitivas de los procesos del software más bien son
abstracciones de los procesos que se pueden utilizar para el desarrollo del software. Puede pensarse en ellos como marcos de trabajo del proceso y que pueden ser adaptados para crear procesos más específicos. Los modelos que
mencionaremos en este punto son: 1) El modelo en cascada. Considera las actividades fundamentales del proceso
especificación, desarrollo, validación y evolución. Los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera.
2) El modelo de desarrollo evolutivo (espiral). Este enfoque entrelaza las
actividades especificación, desarrollo y validación. Es decir surge de un sistema inicial que se desarrolla rápidamente a partir de especificaciones abstractas. Basándose en las peticiones del cliente para producir un sistema
que satisfaga sus necesidades.
3) El modelo de desarrollo basado en componentes. Éste enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo se enfoca en integrar estos componentes en el sistema
más que en desarrollarlos desde cero. Estos tres modelos se utilizan ampliamente en la práctica actual de la ingeniería del software, no se excluyen
mutuamente y a menudo se utilizan juntos especialmente para el desarrollo de grandes sistemas.
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
4 DELVIN ESTUARDO FELIX TORRES
A. El modelo en cascada Según Royce (1970), el modelo de cascada se derivó de procesos de sistemas
más generales. Éste modelo se muestra en la figura 2.22 y sus principales etapas se transforman en actividades fundamentales del desarrollo:
1) Análisis y definición de requerimientos. Los servicios restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven de manera específica al sistema.
2) Diseño del sistema y del software. El proceso de diseño del sistema divide
los requerimientos en sistemas ya sea hardware Soto. Establece una arquitectura completa del sistema, el diseño del software identifique describe los elementos abstractos que son fundamentales para el software y sus
relaciones.
3) Implementaciones prueba de unidades. Durante esta etapa el diseño del software se lleva a cabo como un conjunto de unidades de programas, la prueba de unidades implica verificar que cada una cumpla con su función
específica.
4) Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y se prueban como un sistema completo para así asegurar que se cumplan los requerimientos del software, después se entrega
al cliente. 5) Funcionamiento y mantenimiento. En esta fase el sistema se instala y se
pone en funcionamiento práctico el mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida, mejorar la
implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren en nuevos requerimientos.
B. El modelo de desarrollo evolutivo (espiral)
El modelo en espiral que Boehm propuso es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada. Cuando se
aplica este modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Cada una de las actividades del marco de trabajo
representa un segmento de la ruta en espiral. Este modelo se basa en la idea de desarrollar una implementación inicial,
exponiéndola a los comentarios del usuario y refinándola a través de las diferentes versiones que se generan hasta que se desarrolle un sistema
adecuado.
Las actividades de especificación, desarrollo y validación se entrelazan en vez de separarse, con una rápida retroalimentación entre estas. Existen dos tipos de desarrollo evolutivo:
1) Desarrollo exploratorio, en este caso el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
5 DELVIN ESTUARDO FELIX TORRES
desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.
2) Prototipos desechables, el objetivo de este proceso de desarrollo evolutivo
es comprender los requerimientos del cliente para así desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar los requerimientos del cliente que no se comprenden del todo.
Haciendo referencia a la producción del software, un enfoque evolutivo suele
ser más efectivo que el enfoque en cascada, ya que satisface las necesidades inmediatas de los clientes. La ventaja de un software que se basa en un
enfoque evolutivo es que las especificaciones se pueden desarrollar de forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su problema, esto se puede reflejar en el software. Sin embargo, desde la
perspectiva de ingeniería y de gestión, el enfoque evolutivo tiene dos problemas:
1) El proceso no es visible. Esto significa que los administradores tienen que hacer entregas regulares para medir el progreso del producto. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen
cada versión del sistema.
2) A menudo los sistemas tienen una estructura deficiente. Esto hace referencia que los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea
difícil y costosa.
Para sistemas pequeños y de tamaño medio (hasta 500,000 líneas de código), el enfoque evolutivo de desarrollo es el mejor. Los problemas del desarrollo
evolutivo se hacen particularmente agudos para sistemas grandes y complejos con un período de vida largo, donde diferentes equipos desarrollan distintas partes del sistema. Es difícil establecer una arquitectura del sistema usando
este enfoque, ya que hace difícil integrar las contribuciones de los equipos. Para sistemas grandes se recomienda un proceso mixto es decir que incorpore
las mejores características del modelo en cascada y del desarrollo evolutivo. Esto implica desarrollar un prototipo desechable, utilizando un enfoque evolutivo para resolver incertidumbres en la especificación del sistema. Puede
entonces no implementarse utilizando un enfoque más estructurado.
C. El modelo de desarrollo basado en componentes En la mayoría de los proyectos de desarrollo de software existe la reutilización.
Por lo general esto sucede informalmente cuando las personas conocen diseños o códigos similares al requerido. Los buscan, los modifican según lo creen necesario y los incorporan en un nuevo sistema. El enfoque evolutivo, la
reutilización es indispensable para el desarrollo más ágil de un sistema. Esta reutilización es independiente del proceso de desarrollo que se utilice. Sin
embargo, en los últimos años ha surgido un enfoque de desarrollo de software denominado " ingeniería de software basada en componentes", el cual se basa
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
6 DELVIN ESTUARDO FELIX TORRES
en la reutilización. Este enfoque se basa en la reutilización y se compone de una gran base de componentes de software que son reutilizables.
Aunque la etapa de especificación de requerimientos y la revalidación son
comparables con otros procesos, las etapas intermedias en el proceso orientado a la reutilización son diferentes. Estas etapas son:
1) Análisis de componentes. En esta se buscan los componentes para implementar los con base en su especificación. Por lo general, no existe una concordancia exacta y los componentes que se utilizan sólo proporcionan parte
de la funcionalidad requerida.
2) Modificación de requerimientos. En esta etapa los requerimientos se analizan utilizando información acerca de los componentes que se han descubierto. Entonces dichos componentes se modifican para reflejar los
componentes disponibles, la actividad de análisis de componentes se puede llevar a cabo para buscar soluciones alternativas.
3) Diseño del sistema con reutilización. En esta fase los diseñadores tienen en cuenta los componentes que se reutiliza y que se organizan el marco de trabajo
para que los satisfaga. Si dichos componentes no están disponibles se puede diseñar nuevos software.
4) Desarrollo e integración. El software que no se puede adquirir externamente se desarrolla y se integra a los componentes. En este modelo, la integración
del sistema es parte del proceso de desarrollo, más que una actividad separada.
El modelo de desarrollo de software basado en componentes creado por
Boehm (1988), tiene la ventaja de reducir la cantidad de software que se debe desarrollar y por ende reduce los costos y los riesgos. También permite una entrega más rápida del software. Sin embargo, los compromisos a los
requerimientos son inevitables y esto da lugar a un sistema que no cumpla con las necesidades reales de los usuarios. Pressman (2006), detecto que:
“El software de computadoras moderno se caracteriza por el cambio con tiempos de entrega son muy reducidos y una necesidad intensa de satisfacer al cliente/usuario. En muchos casos, el tiempo de llegada al mercado es el
requisito de gestión más importante. Si se pierde una ventana del mercado, el mismo proyecto de software puede perder su significado”.
Ciclo de vida del software El término ciclo de vida del software describe el desarrollo de software, desde la fase
inicial hasta la fase final. El propósito de este programa es definir las distintas fases
intermedias que se requieren para validar el desarrollo de la aplicación, 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.
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
7 DELVIN ESTUARDO FELIX TORRES
Estos programas se originan en el hecho de que es muy costoso rectificar los errores que
se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los
errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores
concentrarse en la calidad del software, en los plazos de implementación y en los costos
asociados.
El ciclo de vida básico de un software consta de los siguientes procedimientos:
Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia
global.
Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los
requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
Diseño general: requisitos generales de la arquitectura de la aplicación.
Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
Programación (programación e implementación): es la implementación de un lenguaje
de programación para crear las funciones definidas durante la etapa de diseño.
Prueba de unidad: prueba individual de cada subconjunto de la aplicación para
garantizar que se implementaron de acuerdo con las especificaciones.
Integración: para garantizar que los diferentes módulos se integren con la aplicación.
Éste es el propósito de la prueba de integración que está cuidadosamente
documentada.
Prueba beta (o validación), para garantizar que el software cumple con las
especificaciones originales.
Documentación: sirve para documentar información necesaria para los usuarios del
software y para desarrollos futuros.
Implementación
Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y
las actualizaciones secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una
aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el
equipo de desarrolladores.
Modelos de ciclo de vida
Para facilitar una metodología común entre el cliente y la compañía de software, los
modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo
involucradas y la documentación requerida, de manera que cada etapa se valide antes de
continuar con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de
manera que (texto faltante).
Modelo en cascada
Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la
documentación para garantizar que cumple las especificaciones y los requisitos antes de
pasar a la fase siguiente: En Ingeniería de software el desarrollo en cascada, también
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
8 DELVIN ESTUARDO FELIX TORRES
llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de
esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque
metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software,
de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior Al
final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se
encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo
fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.
Modelo V
El modelo de ciclo de vida V proviene del principio que establece que los
procedimientos utilizados para probar si la aplicación cumple las
especificaciones ya deben haberse creado en la fase de diseño.
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
9 DELVIN ESTUARDO FELIX TORRES
METODOLOGÍA RUP
El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas
RUP, es un proceso de desarrollo de software y junto con el Lenguaje
Unificado de Modelado UML, constituye la metodología estándar más utilizada
para el análisis, implementación y documentación de sistemas orientados a
objetos. El RUP no es un sistema con pasos firmemente establecidos, sino que
trata de un conjunto de metodologías adaptables al contexto y necesidades de
cada organización, donde el software es organizado como una colección de
unidades atómicas llamados objetos, constituidos por datos y funciones, que
interactúan entre sí.
RUP es un proceso para el desarrollo de un proyecto de un software que define
claramente quien, cómo, cuándo y qué debe hacerse en el proyecto
RUP como proceso de desarrollo
• RUP es explícito en la definición de software y su trazabilidad, es decir,
contempla en relación causal de los programas creados desde los
requerimientos hasta la implementación y pruebas.
• RUP identifica claramente a los profesionales (actores) involucrados en el
desarrollo del software y sus responsabilidades en cada una de las actividades.
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
10 DELVIN ESTUARDO FELIX TORRES
Fases de desarrollo del software
· Inicio
· Elaboración
· Construcción
· Transición
El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un
modelo de proceso de software evolutivo donde se conjuga la naturaleza de
construcción de prototipos con los aspectos controlados y sistemáticos del
MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo
rápido de versiones incrementales del software que no se basa en fases
claramente definidas y separadas para crear un sistema.
En el modelo espiral, el software se desarrolla en una serie de versiones
incrementales. Durante las primeras iteraciones la versión incremental podría
ser un modelo en papel o un prototipo, durante las últimas iteraciones se
producen versiones cada vez más completas del sistema diseñado.
EL modelo en espiral se divide en un número de actividades de marco de
trabajo, también llamadas REGIONES DE TAREAS , Cada una de las regiones
están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO
DE TAREAS que se adaptan a las características del proyecto que va a
emprenderse en todos los casos se aplican actividades de protección.
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
11 DELVIN ESTUARDO FELIX TORRES
TIPOS
El modelo espiral tuvo varias modificaciones que son:
Modelo Original de Boehm.
Modelo Típico de Seis Regiones.
Modelo WINWIN.
Publicado por Grupo Espiral Php en 9:27 No hay comentarios:
MODELO ORIGINAL DE BOEHM
No hay un número definido de iteraciones. Las iteraciones debe decidirlas el
equipo de gestión de proyecto
Cada vuelta se divide en 4 sectores:
Planeación: determinación de los objetivos, alternativas y restricciones
Análisis de riesgo: análisis de alternativas e identificación/resolución de
riesgos
Ingeniería: desarrollo del producto hasta "el siguiente nivel".
Evaluación: valoración por parte del cliente de los resultados obtenidos.
El movimiento de la espiral, ampliando con cada iteración su amplitud radial,
indica que cada vez se van construyendo versiones sucesivas del software,
cada vez más completas.
Uno de los puntos más interesantes del modelo, es la introducción al proceso
de desarrollo a las actividades de análisis de los riesgos asociados al desarrollo
y a la evaluación por parte del cliente de los resultados del software.
El modelo de la cascada es uno de los primeros modelos empleados en el
desarrollo de software, se popularizo en 1970 por Winston Royce y aún está
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
12 DELVIN ESTUARDO FELIX TORRES
vigente en algunos desarrollos. Éste modelo se define como una secuencia de
actividades a ser seguidas en orden, donde la estrategia principal es definir
y seguir el progreso del desarrollo de software hacia puntos de revisión bien
definidos, es decir, se codifica y reparan los errores; es un proceso continuo de
codificación y reparación. Sus características principales son:
-Es lineal
-Las actividades están relacionadas secuencialmente
-Cada etapa tiene una entrada y una salida
-Es rígido y sistemático: La entrada de una actividad es la salida de la etapa -
anterior, por lo cual no se puede dar inicio a la siguiente fase.
-Es monolítico: Existe una única fecha de entrega.
-La implementación se pospone hasta que no se comprendan los objetivos.
-Los documentos a entregar rigen el proceso de software
INSTITUTO TECNOLOGICO SPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ
DELVIN ESTUARDO FELIX TORRES
Conclusión.
El desarrollo del software y la programación es uno de los pilares fundamentales de la
informática y al cual se dedican muchas horas de esfuerzos en empresas, colegios,
academias y universidades.
Conforme a la tecnología va avanzando, van apareciendo nuevas soluciones, nuevas
formas de programación, nuevos lenguajes y un sin fin de herramientas que intentan
realizar el trabajo del desarrollador un poco más fácil.
INSTITUTO TECNOLOGICO SPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ
DELVIN ESTUARDO FELIX TORRES
Recomendación.
Lo único que puedo recomendar es que se nos sigan implementando nuevas técnicas de
aprendizaje ya bien darnos a conocer más sobre estos temas ya que para nosotros como
estudiantes de la carrera de computación se nos tienen que dar a conocer estos
conocimientos para aplicarlos en el campo de estudio o en la vida diaria para salir adelante
sabiendo cómo hay que realizar cualquier tipo de problema que se nos presenta en cuanto a
computación.
INSTITUTO TECNOLOGICO SPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ
DELVIN ESTUARDO FELIX TORRES
E- GRAFIAS.
http://www.academia.edu/6362716/METODO_EN_CASCADA
http://modeloespiral.blogspot.com/
http://ingenieriadesoftwarerigo.blogspot.com/2012/09/software-libre-para-generar-uml-
y.html
http://es.kioskea.net/contents/223-ciclo-de-vida-del-software
http://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESARROLLO+DE+SOFTW
ARE
http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm
http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
Top Related