Beruflich Dokumente
Kultur Dokumente
Introducción:
El Gartner Group sugiere que “una adherencia consistente a
lineamientos de una metodología moderadamente rigurosa
puede proporcionar a 70% de las organizaciones [desarrollo
de sistemas] una mejora de productividad de al meno 30% en
dos años” ¨1¨
Incremental
concepto
El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque
incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de
desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta
adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes
denominaciones:
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva
de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica
secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada
secuencia lineal produce un incremento del software. El primer incremento generalmente es un
producto esencial denominado núcleo.
Características
Sin embargo, no se trata de iteraciones independientes. Por el contrario, están vinculadas de forma
que cada una suponga un avance con respecto a la anterior. Otras características esenciales de este
modelo son:
Para que esto sea posible, se debe tener en cuenta que las iteraciones no pueden ser demasiado rígidas y
que no existan tareas simultáneas. El modelo incremental exige un encadenamiento progresivo de cada
tarea. Scrum y Kanban son las herramientas más conocidas que emplean este modelo de gestión.
Fases o etapas
El modelo de gestión incremental no es un modelo necesariamente rígido, es decir, que puede
adaptarse a las características de cualquier tipo de proyecto, existen al menos 7 fases que debemos tener
en cuenta a la hora de implementarlo:
Conclucion
Utilización de la ingeniería de software como mecanismo de aplicación y evaluación de la
eficiencia y calidad operacional de un sistema de función crítica, visto como la definición de
criterios de operación bajo condiciones y límites establecidos por el sistema y por las
características externas del medio externo. En el desarrollo de productos de software las etapas
de análisis de requerimientos y diseño toma gran parte del tiempo del proyecto. El modelo
planteado en este proyecto pretende establecer unos parámetros de diseño generales que
permitan agilizar la implementación de proyectos tipo sistemas de control por software, cuya base
común es el procesamiento de señales digitales en busca de comportamientos de interés
(caracterización de señales). La utilización de un ciclo de vida específico para el desarrollo de
software,
Desarrollo evolutivo
Concepto:
Características
Fases o etapas
VENTAJAS
Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una
mejora de la calidad del software.
Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del
cliente.
DESVENTAJAS
Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema
se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del
sistema.
Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la
estructura del software haciendo costoso el mantenimiento.
Desarrollo en espiral
Concepto
Carateristicas
Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente. Este modelo es
el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los
programas modernos de PC´s. La ingeniería puede desarrollarse a través del ciclo de vida clásico o
el de construcción de prototipos. Ver fig. 3 anexos Este es el enfoque más realista actualmente
Fases o etapas
Determinar o fijar los objetivos. En este paso se definen los objetivos específicos para
posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña
una planificación detallada de gestión y se identifican los riesgos. 2. Análisis del riesgo. En este
paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se
definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean
estrategias alternativas. 3. Desarrollar, verificar y validar. En este tercer paso, después del análisis
de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla. 4.
Planificar. En este último paso es donde el proyecto se revisa y se toma la decisión si se debe
continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes
para la siguiente fase del proyecto.
VENTAJAS DEL MODELO ESPIRAL No requiere una definición completa de los requerimientos del
software a desarrollar para comenzar su funcionalidad. En la terminación de un producto desde el
final de la primera iteración es muy factible aprobar los requisitos. Sufrir retrasos corre un riesgo
menor, por que se comprueban los conflictos presentados tempranamente y existe la forma de
poder corregirlos a tiempo.
DESVENTAJAS DEL MODELO ESPIRAL Existe complicación cuando se evalúa los riesgos. Se requiere
la participación continua por parte del cliente. Se pierde tiempo al volver producir inicialmente
una especificación completa de los requerimientos cuando se modifica o mejora el software.
CONCLUCIÓN
Concepto
Boehm, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo
Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que
aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas
de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente
quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas
y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el
producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo
ciclo.
Características:
1.1Iterativo e Incremental
1.3Centrado en la arquitectura
VENTAJAS
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora.
Como el software evoluciona a medida que progresa el proceso, el desarrollador y el
cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de
prototipos en cualquier etapa de evolución del producto.
El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas
las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de
que se conviertan en problemas.
En la utilización de grandes sistemas a doblado la productividad.
DESVENTAJAS
Conclusión
Los conceptos anteriormente tratados – dirigido por casos de uso,
centrado en arquitectura, desarrollo iterativo e incremental – son igualmente
importantes. La arquitectura provee la estructura sobre la cual guiar el trabajo
en iteraciones, mientras que los casos de uso definen las metas y dirigen el
trabajo en cada iteración. Remover cualquiera de estos conceptos reducirá
severamente el valor del Proceso Unificado. Es como una mesa de tres patas, sin
alguna de ellas, la mesa se caerá.
Cascada:
Concepto:
Por otro lado en esta entrada del blog se analizara el modelo en cascada como un
ciclo de vida descriptivo.
Carateristicas:
Fases o etapas.
Ventajas del Modelo Cascada
No se pasa a otra etapa si no está cumplida la actual
Una gran cantidad de énfasis en la documentación
El método de cascada también es bien conocido entre los desarrolladores de software
por lo que es fácil de usar. Es más fácil desarrollar una variedad de software a través
de este método en el corto espacio de tiempo.
Desventajas del Modelo Cascada
Existen variaciones del cliente que el cascada no puede asumir si ya ha pasado una
etapa.
Se pierde una gran cantidad de tiempo.
Las pruebas se dan bastante tarde en el proceso de desarrollo
La documentación para proyectos pequeños es pesada
CONCLUSIÓN
El modelo en Cascada es un método clásico de desarrollo de software orientando
a proyectos que tengan bien definidos sus requerimientos y que no sean
entregados en tiempo corto. Si se analiza el modelo en cascada se enfoca puntos
importantes, uno de esos puntos es que este método nació para para la
construcción de hardware y que con el pasar el tiempo se acoplo al desarrollo de
software, otro punto es que cuenta con algunas desventajas que han querido ser
modificadas por alguno modelos mencionados anteriormente en la
documentación.
Concepto
Concepto
Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas
frecuentes.
Refactorización del código, es decir, reescribir ciertas partes del código para aumentar
su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de
garantizar que en la refactorización no se ha introducido ningún fallo.
Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo
de cada módulo en grupos de trabajo distintos, este método promueve el que todo el
personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas
de regresión garantizan que los posibles errores serán detectados.
Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo
funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta
que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si
se requiere, que realizar algo complicado y quizás nunca utilizarlo.
CARACTERÍSTICAS XP
Metodología basada en prueba y error
Fundamentada en Valores y Prácticas
Expresada en forma de 12 Prácticas–Conjunto completo–Se soportan unas
a otras–Son conocidas desde hace tiempo. La novedad es juntarlas
Etapas y fases
metodología.
Ventajas:
Programación organizada.
Menor taza de errores.
Satisfacción del programador.
Desventajas:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.
CONCLUSIONES
Apostolado de metodologías exitosas
Aporte de la experiencia práctica a los modelos teóricos
Enfoque de conjunto de prácticas como rompecabezas
Tecnología en expansión
Importancia de revisitar las metodologías desde la experiencia práctica