CORPORACIÓN UNIVERSITARIA REMINGTON
MARIO JAVIER PARRA VALLEJO
Temas de Investigación:
MODELOS EVOLUTIVOS DE SOFTWARE
PROBLEMAS EN EL DESARROLLO DE SOFTWARE
REFLEXION EVOLUCIÓN SISTEMAS DE SOFTWARE
PROBLEMAS EN EL DESARROLLO DE SOFTWARE
REFLEXION EVOLUCIÓN SISTEMAS DE SOFTWARE
Docente:
Ing. FABIAN PARRA PAY
ESPECIALIZACIÓN EN GERENCIA DE INFORMÁTICA
SISTEMAS DE SOFTWARE
San Juan de Pasto, Mayo 2014
ACTIVIDAD 2
1. Cuáles
son los modelos evolutivos de software y porque se caracterizan?
2. Cuáles
son los problemas más frecuentes en el desarrollo de software, explíquelo con
un ejemplo.
3. Que
reflexión puede sacar frente a la evolución que ha presentado los sistemas de
software frente a la facilidad de uso, adaptabilidad, costos.
DESARROLLO ACTIVIDAD:
1. Cuáles son los modelos evolutivos de software y porque se caracterizan?
MODELOS EVOLUTIVOS DE SOFTWARE
1.1 MODELO INCREMENTAL
1.2 MODELO EN ESPIRAL
1.3. MODELO WINWIN
1.4. MODELO DE DESARROLLO CONCURRENTE
Se caracterizan porque:
· Se adaptan más fácilmente a los cambios introducidos a lo largo del desarrollo.
· Iterativos
· En cada iteración se obtienen versiones más completas del SW.
Qué es un modelo de desarrollo?
Un modelo de desarrollo es una representación abstracta de un proceso de software, cada modelo representa el proceso de desarrollo de software de una manera en particular. A pesar de estar definidos claramente, no representan necesariamente la realidad de cómo se debe desarrollar el software, sino que establece un enfoque común. Un modelo puede ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo.
En forma general podemos clasificar los modelos de desarrollo en 3 grupos:
1. El modelo en cascada. Considera las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución, y 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. Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones abstractas. Éste se refina basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades.
3. Ingeniería del software basada en componentes. Este enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca en integrar estos componentes en el sistema más que en desarrollarlos desde cero.
Aunque existen muchos tipos de modelos de desarrollo, de forma genérica la mayoría está clasificada en una de estas 3 categorías, y estos a pesar de ser diferentes a veces son usados de manera simultáneamente especialmente en sistemas grandes.
Desarrollo Evolutivo
El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.
Existen dos tipos de desarrollo evolutivo:
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos grandes problemas:
1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. 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. 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.
Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.
El modelo incremental es una unión de las mejores funcionalidades del modelo de cascada y del modelo de prototipos. A medida que se presenta un prototipo se produce un “incremento”, que es una iteración del proceso anterior pero aplicando las experiencias aprendidas del proceso anterior. A diferencia del modelo de prototipos, los prototipos de este modelo están orientados a ser operacionales en cada incremento y no ser solo una “previa” de cómo sería el sistema en su versión final.
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
· Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
· Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
· Si un error importante es realizado, sólo la última iteración necesita ser descartada.
· Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
· Si un error importante es realizado, el incremento previo puede ser usado.
· Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.
En la figura se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus actividades genéricas asociadas. Aquí se observa claramente cada ciclo cascada que es aplicado para la obtención de un incremento; estos últimos se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la figura 5 se muestra como secuencial puro.
Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, así por ejemplo, en la figura, mientras se realiza el diseño detalle del primer incremento ya se está realizando en análisis del segundo.
Ventajas:
El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
Desventajas:
El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
Critica:
En este modelo se debe especificar con precisión todo lo que el sistema va a hacer antes de desarrollarlo. Lo cual lo hace manejable y disminuiría los costos.
1.2 MODELO EN ESPIRAL
Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe así:
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.
Características:
· Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
· Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
· Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
· Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
· Si un error importante es realizado, sólo la última iteración necesita ser descartada.
· Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
· Si un error importante es realizado, el incremento previo puede ser usado.
· Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.
En la figura se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus actividades genéricas asociadas. Aquí se observa claramente cada ciclo cascada que es aplicado para la obtención de un incremento; estos últimos se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la figura 5 se muestra como secuencial puro.
Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, así por ejemplo, en la figura, mientras se realiza el diseño detalle del primer incremento ya se está realizando en análisis del segundo.
Ventajas:
El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
Desventajas:
El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
Critica:
En este modelo se debe especificar con precisión todo lo que el sistema va a hacer antes de desarrollarlo. Lo cual lo hace manejable y disminuiría los costos.
1.2 MODELO EN ESPIRAL
Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe así:
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.
· Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
· Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.
Funcionamiento del modelo Espiral
En cada vuelta tomamos en cuenta:
· Los Objetivos: Que necesidad debe envolver el programa.
· Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través de diferentes puntos como son:
o Características: experiencia del personal, exigencias a efectuar.
o Formas de gestión del programa.
o Riesgo tomado con cada alternativa.
· Desarrollar y Verificar: Programar y probar el programa .
· Se planificaran los siguientes pasos y se volverá a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones la radial y la angular:
o Angular=Avance del proyecto Software, dentro de un ciclo.
o Radial=Aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos largos como pueden ser la creación de un Sistema Operativo. Y que necesitan constantes cambios.
Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.
Desventajas:
Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto.
Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.
Critica:
Este modelo es útil para grandes proyectos pero no ha sido utilizado tanto como el lineal secuencial o el de prototipos. Tiene similitud con el modelo en cascada, pero aquí lo enfoca en un sistema más real.
1.3. MODELO WINWIN
Una variante interesante del Modelo Espiral previamente visto es el "Modelo Espiral Win-Win" (Barry Boehm). El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.
"Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando ambas partes ganan".
Las mejores negociaciones se fuerzan en obtener "Victoria & Victoria" (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociación.
El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral; se definen las siguientes actividades:
1 - Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren).
2 - Determinación de "condiciones de victoria" de los directivos (saber qué necesitan y los satisface)
3 - Negociación de las condiciones "victoria" de los directivos para obtener condiciones "Victoria & Victoria" (negociar para que ambos ganen).
(*) Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la organización si tiene éxito o criticado si no.
El modelo WinWin hace énfasis en la negociación inicial, también introduce 3 hitos en el proceso llamados "puntos de fijación", que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del software.
Critica:
En este modelo las actividades que se definen son importantes como lo son: la identificación del sistema, la determinación de las condiciones y la negociación de estas.
1.4. MODELO DE DESARROLLO CONCURRENTE
Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software.
Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.
Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes.
En algunos proyectos, múltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantención sobre un componente 2, mientras que se está haciendo codificación sobre un componente 3, mientras se realiza diseño sobre una etapa 4, y especificación de requisitos sobre un componente 5.
Critica:
Este modelo se utiliza cuando las actividades están ocurriendo simultáneamente así, se posibilita el conocimiento del estado real en el que se encuentra el proyecto.
2. Cuáles son los problemas más frecuentes en el desarrollo de software, explíquelo con un ejemplo.
RTA./
Se Podría decir que
hay tres problemas comunes, dos de ellos habituales y un tercero de índole
social y se explica con un ejemplo a continuación:
A. Necesidades no satisfechas o no identificadas
En el caso de las necesidades no satisfechas o no
identificadas, el error puede aparecer debido a que se omiten datos durante el
desarrollo del proyecto, es por esto que es muy importante no saltar ninguna
etapa del ciclo de vida del desarrollo de sistemas. Otra causa de
insatisfacción de necesidades es la mala definición de las expectativas de un
proyecto en sus orígenes, ya que si no están bien definidos los requerimientos
máximos y mínimos que el proyecto debe satisfacer desde el comienzo, los
desarrolladores verán afectado su trabajo por el “síndrome de las necesidades
que crecen” el cual les dejara hacer cambios en el proyecto en cualquier
momento sin detenerse a pensar si esos cambios serán buenos para el proyecto
como un todo (por supuesto todos estas modificaciones acarrearan alteraciones
en los costos y en los tiempos de entrega).
B. Los habituales: atrasos y costes
Uno de los rasgos característicos y síntoma de
“normalidad informática” es que los proyectos informáticos se atrasan y se
exceden en los presupuestos económicos.
Decir que
el tiempo y dinero se duplican, triplican o cuadruplican ya no tiene sentido,
es un hecho y tradición del vulgo. Esto sucede debido a que un proyecto
generalmente exige un estudio de viabilidad en el cual muchas veces no se
incluyen datos completamente precisos de la cantidad de recursos que cada tarea
consumirá, y es en base a este estudio que se hacen estimaciones de los
recursos totales que el proyecto va a necesitar. Ya se sabe que en un proyecto
informático hay muchas cosas no definidas, pero si esto es sabido y repetido se
puede prever. Basta con ver cómo otras profesiones han resuelto estos problemas
sabiendo que existen y luego apoyándose con herramientas pero no dejando al
azar el propio azar.
En cuanto
al atraso, generalmente se debe a que los gestores del proyecto no son buenos
gestionando los tiempos de entrega de cada una de las diferentes tareas que el
proyecto involucra, es así que cuando tienen un retraso no son capaces de
alterar los plazos de entrega finales creyendo que podrán recuperar el tiempo
perdido con largas noches y extensos fines de semana. En general esta es una
muy mala política de trabajo porque no siempre es posible acelerar otras tareas
para ahorrar tiempo en la entrega final.
Por
ejemplo, Glass señala que el 40% de los proyectos informáticos son cancelados
por estos excesos; mientras, un 33% se enfrentan a cambios de tiempo, costes y
alcance. Sin embargo, esta imagen no es propia de la informática, por ejemplo
Ribera, nos muestra algunos ejemplos dignos de mención:
§ El
proyecto del Opera House de Sidney pasó de 7 millones de dólares a 107 millones
de dólares.
§ El
proyecto de desarrollo del avión F-22 Raptor que ha superado un coste del
billón de dólares.
§ El
proyecto del túnel del Canal de la Mancha, cuyo coste inicial de 7,5 billones a
llegado a los 17,5 billones de dólares, y se terminó en 1994 en lugar de 1992.
Pero no
es necesario pensar en esas grandes empresas humanas, cuya complejidad puede
justificar cualquier superación de estimaciones. Se puede pensar en el simple
atraso en la construcción de un edificio, algo tan habitual y corriente que se
nos pasa desapercibido. Lo que se quiere decir es que fuera de la Informática,
los proyectos también se atrasan y cuestan más caros por motivos tan diversos y
variopintos como los que se escuchan en informática. Lo que es preocupante es
que dentro de la Informática estos problemas se manifiestan tanto a gran escala
(como los ejemplos dados por Ribera) como a escala “casera”, viéndose afectado
por tanto todo el tejido socio-económico, incluyendo aspectos como el
crecimiento organizacional, los planes de empresa, o el presupuesto de una
PyME. Y lo peor, se consideran “normales”(!!!!).
C. El social: la imposición de los resultados
Aparte de los comunes problemas de tiempo y coste,
está en lo que podría llamarse el problema de ‘adopción por decreto’.
En muchas
ocasiones los productos informáticos son impuestos por las jerarquías
administrativas sin una asimilación y/o aceptación del personal o los
trabajadores.
Según
ciertas culturas este tema resulta conflictivo y un problema a ser resuelto. Un
caso de cultura que rechaza esta situación es la escandinava, así, Iivari y
Lyytinen destacan que los productos informáticos son artefactos surgidos y
definidos por quienes les usarán, los trabajadores.
El
problema es básicamente de los principios ligados a la historia de la
ingeniería, donde ella busca ser generadora de soluciones a las necesidades de
la humanidad, aportando artefactos con un valor agregado y márgenes de ganancia
social siempre positivos para el ‘hombre de la calle’. Esta visión se
contradice con la costumbre informática de imponer soluciones según el último
avance en el área, la última tendencia o lo que sencillamente hay que tener. Al
final, ocurren ajustes de trabajo de índole tayloristas que imponen aparentes
mejores niveles de eficiencia, lo cual produce una confusión en los fines, por
ejemplo, se confunde la búsqueda de procesos de negocios más eficientes (que
muchas veces no requiere tecnología) con el aumento de velocidad computacional
(se cree que con meter más maquinaria todo será mejor), y/o se confunden
mejoras de la eficacia que se pueden conseguir con nuevas prácticas laborales
con simples automatizaciones de prácticas de trabajo.
En una sociedad
del conocimiento este tipo de actitudes no son permitidas. Imponer resultados
no es positivo y más aún cuando existe una tecnología que es esencialmente
socio organizacional como las TIC, pues es necesaria la participación libre y
colaborativa de todas las personas involucradas en un proceso de construcción
de productos informáticos, sean tanto diseñadores de sistemas como usuarios
finales.
Entre otras situaciones que se presentan con mayor frecuencia en todo desarrollo de software y en especial en el mundo, el desarrollo de software, son los siguientes:
1. Presión excesiva en el tiempo de ejecución.
2. Cambios en las especificaciones del proyecto.
3. Ausencia de especificaciones técnicas.
4. Ausencia de un proyecto documentado o correctamente documentado.
5. y 6. Demasiadas innovaciones superficiales.
7. Añadir en el desarrollo funcionalidades que no estaban originalmente. (features creep ó requirements creep).
8. Ausencia del método científico.
9. Ignorar lo obvio.
10. Comportamiento poco ético.
A continuación aparecen estos 10 errores más comunes y las medidas que habría que adoptar para evitarlos:
1. Estimación del proyecto con tiempos demasiado ajustados:
Realizar estimaciones objetivas.
Asignar más recursos.
Utilizar mejores recursos.
Priorizar los requerimientos.
Requerimientos no especificados.
Versiones de definitivas por fases.
2. Cambios en las especificaciones:
Desarrollo iterativo.
Modificar el control de la gestión.
3. Ausencia de especificaciones técnicas:
Desarrollo de las especificaciones iniciales.
Gestión correcta de las actualizaciones en lo relativo a las especificaciones.
Gestión a nivel de base de las especificaciones.
Tener un arquitecto del software.
4. Ausencia de un proyecto documentado o correctamente documentado:
Desarrollo de un plan inicial.
Llevar registro periódico y actualizado del proyecto.
Gestión de las líneas maestras del plan de proyecto.
La designación de un jefe de proyectos capacitado.
5. y 6. Demasiadas innovaciones superficiales:
Estudio de los fundamentos.
Análisis de impacto.
Una gestión continua de los riesgos.
Tener un arquitecto de software.
7. Añadir en el desarrollo funcionalidades que no estaban originalmente proyectadas:
Requerimiento de los fundamentos iniciales.
Gestión de los fundamentos del proyecto.
Gestión de los riesgos del proyecto.
Tener un arquitecto del software.
8. No utilizar el método científico:
Realizar prototipos.
Desarrollo incremental.
Medición de las prestaciones técnicas.
9. Ignorar lo obvio:
Los cálculos que van por detrás.
Asimilación de las lecciones aprendidas.
10. Comportamiento poco ético:
Ambientes de trabajo ético y de cultura de trabajo.
Estar adherido al código de ética.
Estos 10 mandamientos que no deberían violarse en el desarrollo de todo software.
¿ Por qué
fallan los Proyectos ? de Software?
1.
Planificación Irreal
2 Mala
Calidad del Trabajo
3 Personal
Inapropiado
4 No Controlar
los Cambios
1.Planificación
Irreal
“El sistema
es para hoy y con costo 0”
Los
ingenieros no son capaces de enfrentar un plan porque:
• NO están
entrenados para usar métodos de planificación.
•
Frecuentemente, las estimaciones NO se basan en datos reales.
2 Mala
Calidad del Trabajo
CAUSAS
•Prácticas
pobres de ingeniería
•Carencia de
métricas de calidad
•Inadecuado
entrenamiento en calidad
•Decisiones
de los directivos guiadas por una planificación irreal
CONSECUENCIAS
• Tiempos de
pruebas impredecibles
• Productos
con muchos defectos
• Demoras en
la aceptación de los usuarios
• Extensa
garantía de servicio y reparaciones
“Una pobre
calidad afecta la planificación y torna ineficente el proceso de prueba”
3. Personal
Inapropiado
PROBLEMAS COMUNES
Demora del
personal
• Escaso
personal
• Miembros
del equipo a tiempo parcial
• Personal
con conocimientos inapropiados
CONSECUENCIAS
El trabajo se
demora o descuida
• Trabajo
ineficiente
• Sufre la
moral del equipo
Con
independencia del plan, los proyectos deben comenzar en tiempo y con todo el
personal.
4 Cambios NO
controlados
HECHOS a
RECORDAR:
• Siempre
ocurren cambios en los requerimientos.
• Los planes
del proyecto se basan en el alcance del trabajo conocido.
• Los cambios
siempre requieren más trabajo.
• Sin planes
detallados, los equipos no pueden estimar el efecto o magnitud de los cambios.
• Si los
equipos no controlan cada cambio, se pierde gradualmente el control del plan
del
Proyecto.
A
continuación se resumen los errores que ocurren con mayor frecuencia, los que ocurren con menor frecuencia y los que de
ocurrir tienen más impacto:
Errores que
ocurren con mayor frecuencia
1. Planificaciones demasiado optimistas
2. Expectativas no realistas (o pedirle a un
proyecto algo imposible)
3. Excesivas tareas (cuando, por ejemplo, los
desarrolladores están en muchos proyectos a la vez)
4. Insuficiente aseguramiento de la calidad
5. Oficinas ruidosas
6. Incorporación de características (por
ejemplo, introducir nuevos requisitos a mitad de proyecto)
7. Hacerse ilusiones (por ejemplo, cerrar los
ojos a lo que se nos viene encima)
8. Gestión del riesgo insuficiente
9. Confundir estimaciones con objetivos
(cuando por ejemplo el objetivo es tener el software en 3 meses, y de ahí se
fija que el desarrollo serán 3 meses)
10. Omitir tareas relacionadas con la
estimación (no guardar históricos para realizar mejores estimaciones, al
estimar obviar tareas como son las reuniones, etc.)
Errores que
ocurren con menor frecuencia
1. Cambio de herramientas en mitad del
proyecto
2. Falta de control automatizado del código
fuente
3. Desarrollo dirigido por la investigación
4. Convergencia prematura o muy frecuente
(forzar el cierre de una versión antes de que sea posible)
5. Estimar obviando el uso de nuevas
herramientas o métodos (obviando, por ejemplo, el coste de aprendizaje)
6. Negociaciones y el “tira y afloja” (entre,
por ejemplo, desarrollo y comerciales)
7. El síndrome de la bala de plata
8. Errores en la subcontratación
9. Llevar al equipo en la oscuridad (cuando,
por ejemplo, los jefes de proyecto ocultan al equipo el avance y plan de
proyecto)
10. Problemas con el equipo
Errores que
provocan problemas de mayor impacto
1. Expectativas no realistas (o pedirle a un
proyecto algo imposible)
2. Equipo poco preparado
3. Planificaciones demasiado optimistas
4. Hacerse ilusiones (por ejemplo, cerrar los
ojos a lo que se nos viene encima)
5. Insuficiente aseguramiento de la calidad
6. Diseño inadecuado
7. Falta de apoyo al proyecto
8. Confundir estimaciones con objetivos
(cuando por ejemplo el objetivo es tener el software en 3 meses, y de ahí se
fija que el desarrollo serán 3 meses)
9. Excesivas tareas (cuando, por ejemplo, los
desarrolladores están en muchos proyectos a la vez)
10. Falta de involucración del usuario.
3. Que reflexión puede sacar frente a la evolución que ha presentado los sistemas de software frente a la facilidad de uso, adaptabilidad, costos.
RTA./
RTA./
Se pueden sacar las siguientes reflexiones frente a la evolución que han presentado los sistemas de Software así:
En los modelos evolutivos se produce un sistema inicial que evoluciona según las necesidades del cliente hasta cumplir con los requisitos de este, para luego producir un sistema que satisfaga sus necesidades. Este enfoque enlaza las actividades de especificación, desarrollo y validación. La cual podemos mencionar algunas ventajas como:
- Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.
- También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.
- Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.
- Reduce costos y aumenta la probabilidad de éxito.
- Exige disponer de las herramientas adecuadas.
- Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería.
- Puede adaptarse y aplicarse a lo largo de la vida del software.
- 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 niveles evolutivos.
- Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
- Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemáticos.
Las metodologías de desarrollo comienzan a interesarse no sólo en lograr que el proyecto sea puesto en funcionamiento sino en minimizar costos durante su desarrollo y sobre todo durante su mantenimiento. Los nuevos métodos van buscando minimizar riesgos y, puesto que los errores más perjudiciales se producen en los primeros pasos, se comienza ya desde la fase más general del estudio por analizar los riesgos que significa seguir con las siguientes fases del desarrollo.
La trascendencia de las metodologías se ha hecho notoria, pasando de solo programar, luego a establecer funciones en etapas o módulos, continuar en resaltar en la primera etapa el análisis de los requisitos, seguido de basarse en objetos, y por último agilizar el desarrollo del software y minimizar los costos. Estos cambios de paradigma han logrado las mejoras para desarrollar software y aunque principalmente buscar acortar el tiempo de solución sin reprochar los recursos disponibles
Además un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido.
Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).
Los modelos de procesos permiten al analista de sistemas desarrollar un plan de requisitos del software, permiten establecer un trabajo en forma ordenada, además que existen muchos modelos que se adaptan a las exigencias del proyecto, solo debemos saber cual nos conviene, pero lo mas importante, es que estos modelos nos llevan a presentar los proyectos al cliente de manera que éste vea su diseño y sus funciones y que la mayoría de ellos están orientados al mantenimiento.
BIBLIOGRAFIA
- http://tema3isoftware.blogspot.com/p/modelos-de-desarrollo-tecnicas-y.html
- www.slideshare.net/jpbthames/modelos-evolutivos-incremental-y-espiral
- «Ingeniería del Software», 7ª Edición, por Ian Sommerville, 4.1.2.
- http://cestay.wordpress.com/2012/01/28/ingenieria-del-proyecto-el-problema-del-desarrollo-de-software-27-problemas-comunes/
GRACIAS
MARIO JAVIER PARRA VALLEJO
Ingeniero de Sistemas
