sábado, 12 de mayo de 2012
“DESARROLLO ÁGIL PARA EL LENGUAJE DE PROGRAMACIÓN A TRAVÉS DEL TRABAJO COLABORATIVO”
República Bolivariana
de Venezuela
Universidad Pedagógica
Experimental Libertador
Instituto
Pedagógico “Rafael Alberto Escobar
Lara”
“DESARROLLO ÁGIL PARA EL LENGUAJE DE
PROGRAMACIÓN A TRAVÉS DEL TRABAJO
COLABORATIVO”
Maracay, Venezuela
“DESARROLLO ÁGIL PARA EL LENGUAJE DE
PROGRAMACIÓN A TRAVÉS DEL TRABAJO COLABORATIVO”
RESUMEN
El desarrollo ágil para el lenguaje de programación a trabes del
trabajo colaborativo esta basado en la búsqueda, formación y explotación de las
habilidades de los programadores, a trabes de la fusión de las teorías del
trabajo colaborativo y los contenidos de la materia Lenguaje de Programación I
del diseño curricular 1996 de la Universidad Pedagógica
Experimental Libertador Núcleo- Maracay Venezuela, en donde los participantes
“llámense docentes o alumnos” forman equipos de trabajo donde cada uno expone
sus habilidades apoyándose en las habilidades del otro, construyendo un equipo
que escapa al individualismo siendo así más ágil y efectivo al momento de crear
programas de cualquier índole, “la tendencia hacia los programadores ermitaños,
donde ellos y sólo ellos son los receptores del conocimiento se está dejando
atrás y los equipos de personas, programando en una cordial y ágil línea da
mejores resultados, en menor tiempo.
Descriptores: Trabajo Colaborativo, Lenguaje de Programación,
Conocimiento y Aprendizaje, Equipo de trabajo.
Introducción
En
2001, Kent Beck y otros 16 notables
desarrolladores, escritores y consultores (conocidos como la "Alianza
Ágil") firmaron el "Manifiesto para el desarrollo ágil de
software", el cual establecía:
Hemos
descubierto mejores formas de desarrollar software al construirlo por nuestra
cuenta y ayudar a otros a hacerlo. Por medio de este trabajo hemos llegado a
valorar:
A
los individuos y sus interacciones sobre los procesos y las herramientas.
Al
software en funcionamiento sobre la documentación extensa.
A la
colaboración entre los integrantes del equipo para la elaboración del software.
A la
respuesta al cambio sobre el seguimiento de un plan.
Un
manifiesto se asocia por lo general con un movimiento político emergente:
aquel que ataca a la vieja vanguardia y sugiere un cambio revolucionario (en el
mejor de los casos para mejorar). De alguna forma, esto es con exactitud de lo
que se trata el desarrollo ágil.
A
pesar de que las ideas subyacentes que conducen al desarrollo ágil han estado
presentes por muchos años, no ha sido sino hasta la década pasada que estas
ideas han cristalizado en un "movimiento". En esencia, los métodos
ágiles se desarrollaron en un intento por superar las debilidades advertidas y
reales en el lenguaje de programación. El desarrollo ágil proporciona
beneficios importantes, pero es imposible aplicarlo en todos los proyectos,
productos, personas y situaciones.
Es
por ello que la incorporación del trabajo colaborativo o groupware en el desarrollo ágil son palabras para
designar el entorno en el cual todos los participantes del proyecto trabajan,
colaboran y se ayudan para la realización del propósito o fin buscando así
maximizar los resultados y minimizar la pérdida de tiempo e información en
beneficio de los objetivos comunes.
Objetivos
Objetivo General
Desarrollar
a su máxima expresión la agilidad de los integrantes de un grupo de (ya
sea estudiantes o profesores) a través del lenguaje de programación y
comprensión de las teorías del trabajo
colaborativo asistido por computadora.
Objetivos específicos
1.-
Reforzar las teorías de Trabajo colaborativo
asistido por computadora, lenguaje de programación y desarrollo ágil.
2.- Precisar y dar a conocer uno o más aspectos para la formación de los participantes a la preparación de
equipos de trabajo bajo el concepto de lo colaborativo utilizando las
herramientas computacionales, siendo este punta fundamental para la elaboración
de software el lenguaje de programación.
3.- Dar a
conocer a través del trabajo colaborativo asistido por computadora los valores,
principios y prácticas que permitirán el diseño y moldeado de Software
educativo de una manera efectiva y rápida.
¿Qué es el Desarrollo Ágil?
El
desarrollo ágil de software, combina una filosofía y un conjunto de directrices
de crecimiento; en donde la filosofía busca la satisfacción del usuario final
junto a la entrega temprana o rápida del mismo; formación de equipos de
proyecto con alta motivación (trabajo colaborativo), métodos informales de
programación y simplicidad general del desarrollo de los software todo esto
para alcanzar las metas propuestas por los equipos de trabajos de una manera mas
rápida y eficaz con menos desgate tanto humano como temporal.
Agilidad:
Según Ivar Jacobson 2002, Agilidad se ha convertido actualmente en la palabra
de moda en cuanto se describe un moderno proceso de software. Cualquiera es
ágil. Un equipo ágil es un equipo rápido que responde de manera apropiada a los
cambios. Éstos son, en gran parte, la materia del desarrollo de software.
Cambios en el software que se va a construir, cambios entre los miembros del
equipo, cambios debidos a las nuevas tecnologías, cambios de todo tipo que
pueden incidir en el producto que se construye o en el proyecto que crea el
producto. En cualquier actividad de software se debe incluir un soporte para
los cambios, esto es algo que adoptamos porque es el alma y el corazón del software.
Un equipo ágil reconoce que el software lo desarrollaron individuos que
trabajan en equipo y que las aptitudes de esta gente, y su capacidad para
colaborar, son esenciales para el éxito del proyecto.
De
acuerdo a la visión de Jacobson, la insistencia en el cambio es el conductor
primordial hacia la agilidad. Los ingenieros de software deben tener pies
veloces si quieren ajustarse a los cambios rápidos que describen Jacobson.
Proceso ágil:
cualquier proceso ágil de software se caracteriza de una manera que refiere
tres suposiciones claves acerca de la mayoría de los proyectos de software:
- Resulta difícil predecir cuáles requisitos del software
persistirán y cuáles cambiarán. De igual forma, es difícil presagiar cómo
cambiarán las prioridades del usuario final mientras se ejecuta el
proyecto.
- para muchos tipos de software, el diseño y la construcción están
intercalados. Esto es, ambas actividades se deben realizar de manera
conjunta, de modo que los modelos de diseño sean probados conforme se
crean. Resulta difícil predecir cuánto diseño se necesita antes de que la
construcción se utilice parta probar el diseño.
- El análisis, el diseño y la construcción no son predecibles
(desde el punto de vista de la planeación), lo que sería deseable.
Dados
los puntos anteriores, surge una pregunta importante: ¿cómo se crea un proceso
susceptible de manipular en forma impredecible? La respuesta, como ya se ha
puntualizado antes, reside en la adaptabilidad del proceso (a un proyecto y a
condiciones técnicas que cambian con rapidez). Por lo tanto, un proceso ágil
debe ser adaptable.
Políticas del desarrollo ágil: existe un debate considerable (a veces estridente) sobre los
beneficios y la aplicabilidad del desarrollo ágil del software como alternativa
a procesos de ingeniería del software más convencionales. Nadie esta en contra
de la agilidad. La pregunta real es: ¿Cuál es la mejor manera de lograrla?
Igual de importante es la pregunta: ¿cómo se construye un software que
satisfaga hoy las necesidades de los usuarios y muestre las características de
calidad que le permitan extenderse y escalar para cubrir alargo plazo las
necesidades del cliente?
Factores humanos: los
defensores del desarrollo ágil del software resaltan la importancia de los
factores de las personas en un desarrollo ágil exitoso. Highsmith 2001, “El
desarrollo ágil se centra en los talentos y las habilidades de los individuos,
puesto que el proceso se ajusta a personas y equipos específicos”. El punto
clave en esta afirmación es que el proceso se ajusta a las necesidades de las
personas y el equipo y no al revés.
¿Qué es el trabajo colaborativo?
El trabajo colaborativo se define como una serie
de procesos intencionales de un grupo
para alcanzar objetivos específicos, más herramientas de software diseñadas
para dar soporte y facilitar el trabajo. En el marco de una
organización, el trabajo en grupo con soporte tecnológico se presenta como un
conjunto de estrategias tendientes a maximizar los resultados y minimizar la
pérdida de tiempo e información en beneficio de los objetivos organizacionales.
El mayor desafío es lograr la motivación y participación activa del recurso
humano. Además deben tenerse en cuenta los aspectos tecnológico, económico y
las políticas de la organización.
Trabajo colaborativo o groupware son palabras
para designar el entorno en el cual todos los participantes del proyecto
trabajan, colaboran y se ayudan para la realización del proyecto.
¿Quién
lo hace?
Los estudiantes, docente, ingenieros, gerentes,
clientes, y usuarios finales de un proyecto en desarrollo de software, los
cuales trabajan juntos en un equipo ágil: un
equipo con organización propia y que controla su propio destino por así
decirlo. Un equipo ágil fomenta la comunicación y la colaboración entre todos
los que trabajan en él.
¿Por
qué es importante?
El ambiente moderno de los negocios ocasiona que
los sistemas modernos de varios sectores como educativos y de negocios ocasiona
que los sistemas basados en computadoras y los productos de de software que
estén acelerados y en cambio continuo. El desarrollo ágil es una opción
razonable para el desarrollo convencional para ciertas clases de software y
ciertos tipos de proyectos de software. Se ha demostrado su utilidad al
entregar sistemas exitosos con rapidez.
¿Cuáles son los pasos a seguir?
El
desarrollo ágil podría llamarse con mayor precisión “ingeniera del software
ligera”. Las actividades básicas del marco del trabajo se conservan, pero éstas
se conforman como un conjunto mínimo de tareas que empuja al equipo de proyecto
hacía la construcción y la entrega del mismo de una forma exitosa y
eficaz.
Modelo ágil de procesos: la historia de la ingeniería del software está llena de decenas de descriptores y metodologías,
métodos de modelado y notaciones, herramientas y tecnologías obsoletas. Cada
elemento surgió con notoriedad y después lo eclipsó algo nuevo y
(supuestamente) mejor. Con la introducción de un espectro de modelos ágiles de
procesos, cada uno en busca de su aceptación dentro de la comunidad del desarrollo
de software, el movimiento ágil está en la misma ruta histórica.
Esto
no es algo malo. Antes de que uno o más modelos o métodos sean aceptados como
un estándar de facto, todos deben competir por los corazones y las mentes de
los programadores. Los “ganadores” evolucionan con la mejoría que proporciona
la práctica, mientras que los “perdedores” desaparecen o se unen a los modelos
“ganadores”.
Programación externa: A pesar de que los primeros trabajos sobre las ideas y los métodos
asociados con la programación externa se realizaron a finales de la década de
los 80, el trabajo fundamental sobre la materia, escrito por Kent Beck 1999.
La
programación externa utiliza un enfoque orientado a objetos como su paradigma
de desarrollo preferido. La programación externa abarca un conjunto de reglas y
prácticas que ocurren en el contexto de cuatro actividades del marco de
trabajo: planeación, diseño, codificación y pruebas. En la figura siguiente se
ilustra el proceso de la programación externa y se observa algunas de las ideas
y tareas calve asociadas con cada actividad del marco de trabajo.
Planeación: La
actividad de planeación comienza creando una serie de historias (también
llamadas historias del usuario) que describen las características y la funcionalidad
requeridas para el software que se construirá. Cada historia la escribe el
usuario final y se coloca en una carta índice. El usuario final le asigna un
valor (es decir, una prioridad) a la historia basándose en los valores
generales del proyecto. Los miembros del equipo de la programación externa
evalúan entonces cada historia y le asignan un costo, el cual se mide en
semanas de desarrollo. Si la historia requiere más de tres semanas de
desarrollo, se le pide al usuario final que la divida en historias menores, y
se realiza de nuevo la asignación del valor y el costo. Es importante destacar
que las historias nuevas pueden escribirse en cualquier momento.
“La programación externa es una disciplina de desarrollo de software
que se basa en valores de simplicidad, comunicación, retroalimentación y
audacia.” Ron Jeffries.
Diseño: El
diseño de la programación externa (PE) sigue de manera rigurosa el principio MS
(mantenerlo simple). Siempre se prefiere un diseño simple respecto de una
presentación más compleja. Además, el diseño ofrece una guía de implementación
para una historia como está escrita, ni más ni menos. Se desaprueba el diseño
de funcionalidad extra5 (porque el desarrollador supone que se requerirá más
tarde).
Si se encuentra un problema difícil de diseño como parte del diseño de
la historia, la PE
recomienda la creación inmediata de un prototipo operacional de esa porción
del diseño. El prototipo del diseño, llamado la solución pico, se implementa y
evalúa. El propósito es reducir el riesgo cuando comience la verdadera
implementación y validar las estimaciones originales en la historia que
contiene el
Codificación: La PE recomienda que después de
diseñar las historias y realizar el trabajo de diseño preliminar el equipo no
debe moverse hacia la codificación, sino que debe desarrollar una serie de
pruebas de unidad que ejerciten cada una de las Historias que vayan a incluirse
en el lanzamiento actual (incremento de software).
Una vez creada la prueba de unidad, el desarrollador es más capaz de
centrarse en lo que debe implementarse para pasar la prueba de unidad. No se
agrega nada extraño (MS). Una vez que el código está completo, la unidad puede
probarse de inmediato, y así proporcionar una retroalimentación instantánea a
los desarrolladores.
Un concepto clave durante la actividad de codificación (y uno de los
aspectos de la PE
de los que más se ha hablado) es la programación en pareja. La PE recomienda que dos personas
trabajen juntas en una estación de trabajo de computadora para crear el código
de una historia. Esto proporciona un mecanismo para la resolución de problemas
en tiempo real (dos cabezas piensan mejor que una) y el aseguramiento de la
calidad en las mismas condiciones. También alienta que los desarrolladores se
mantengan centrados en el problema que se tiene a la mano. En la práctica, cada
persona tiene un papel sutilmente diferente. Por ejemplo, una persona puede
pensar en los detalles de codificación de una porción particular del diseño,
mientras que la otra se asegura de que se sigan los estándares de codificación
(una parte requerida de la PE )
y que el código que se genera "coincida" con el diseño más amplio de
la historia. Cuando los programadores completan su trabajo el código que
desarrollaron se integra con el trabajo de otros. En algunos casos esto lo
lleva a cabo diariamente el equipo de integración. En otros casos, la pareja de
programadores es la responsable de la integración. Esta estrategia de
"integración continua" ayuda a evitar problemas de compatibilidad e
interfaz y proporciona un ambiente de "prueba de humo" que ayuda a
descubrir los errores desde el principio.
Pruebas: Ya
se ha hecho notar que la creación de una prueba de unidad antes de comenzar la
codificación es un elemento clave para el enfoque de la PE. Las pruebas de unidad
que se crean y deben implementarse con un marco de trabajo que permita
automatizarlas (por lo tanto, pueden ejecutarse de manera fácil y repetida). Esto
apoya una estrategia de regresión de prueba
cuando el código se modifica.
Cuando las unidades individuales de prueba se organizan en un conjunto
universal de pruebas, las pruebas de integración y validación del sistema
pueden realizarse a diario. Esto proporciona al equipo de PE una indicación
continua del progreso y también puede encender luces de emergencia previas si
las cosas salen mal. Wells 1991 establece: "Arreglar problemas pequeños
cada pocas horas toma menos tiempo que arreglar problemas enormes justo antes
de la fecha límite".
Desarrollo adaptativo de software (DAS)
El desarrollo adaptativo de software (DAS) lo propuso Jim Highsmith
1998 como una técnica para construir software y sistemas complejos. Los apoyos
filosóficos del DAS se enfocan en la colaboración humana y la organización
propia del equipo. Highsmith 1998 expone lo anterior cuando escribe:
La
organización propia es una propiedad de los sistemas adaptativos complejos,
similar a un "aja" colectivo; es en el momento de energía creativa
cuando surge la solución a algún problema persistente. La organización propia
emerge cuando los individuos, los agentes independientes (células en un cuerpo,
especies en un ecosistema, desarrolladores en un equipo de software) cooperan
[colaboran] para crear salidas emergentes. Una salida emergente es una
propiedad más allá de la capacidad de cualquier agente individual. Por ejemplo,
las neuronas individuales del cerebro no poseen conciencia, pero en forma colectiva
generan la propiedad de la conciencia. Tendemos a ver este fenómeno del surgimiento
colectivo como un accidente, o al menos como independiente y sin reglas. El
estudio de la organización propia demuestra que dicha visión es errónea.
Melé: (termino
derivado de una jugada de rugby) es un modelo ágil de proceso que desarrollaron
Jeff Sutherland y su equipo a principios de la década de los 90. En años recientes Schwaber y Beedle 2001 han
presentado el desarrollo de los métodos de melé los cuales son conscientes con
el manifiesto del desarrollo ágil.
Los equipos de trabajo pequeños están organizados para "maximizar
la comunicación, minimizar los gastos generales y maximizar el hecho de
compartir conocimiento tácito e informal".
El proceso debe adaptarse a los cambios técnicos y de negocios
"para asegurar que se produzca el mejor producto posible".
El proceso produce incrementos frecuentes de software "los cuales
se pueden inspeccionar, ajustar, probar, documentar y construir".
El trabajo de desarrollo y la gente que lo realiza están divididos en
"particiones o paquetes de bajo acoplamiento".
Conforme se construye el producto se realizan pruebas y documentación
constantes.
Los procesos de melé proporcionan la "capacidad de declarar un
producto como 'realizado' siempre que esto se requiera (porque la competencia
acaba de hacer un lanzamiento, porque la compañía necesita el dinero, porque el
usuario/cliente necesita las funciones, porque ya se está en el momento en que
se prometió..." Advanced Development Methods, Inc 1996.
Con los principios de la melé se guían las actividades dentro de un
proceso que incorpora las siguientes actividades del marco de trabajo:
requisitos, análisis, diseño, evolución y entrega. En cada actividad del marco
de trabajo las tareas de trabajo suceden dentro del patrón de proceso (tratado
en el párrafo siguiente) llamado sprint. El trabajo realizado dentro de un
sprint (el número requerido de sprints variará de acuerdo con el tamaño y la
complejidad del producto) se adapta al problema y con frecuencia lo modifica en
tiempo real el equipo de melé.
¿Cuál es el Producto Obtenido?
Todo
aquel que ha trabajado bajo la modalidad de desarrollo ágil tienen la misma
visión: el único producto de trabajo realmente importante es un incremento del
software en funcionamiento, el cual se entrega al usuario final en la fecha
prometida.
¿Cómo estar seguro de lo que he hecho correctamente?
Si
el equipo de software está de acuerdo en que el proceso funciona y dicho equipo
produce incrementos de software entregables que satisfacen al usuario final,
entonces el trabajo está bien hecho.
Conclusión
Una filosofía ágil para la creación del software se relaciona con
cuatro aspectos clave: la importancia de la organización propia de los equipos,
los cuales controlan el trabajo que realizan; comunicación y colaboración entre
los miembros del equipo y entre los profesionales que desarrollan “trabajo
colaborativo”; un reconocimiento de que el cambio representa una oportunidad;
y un especial cuidado en la entrega rápida del software que satisfaga al
usuario final. Los modelos de proceso ágil se diseñaron para cumplir con cada
uno de estos aspectos.
La programación extrema (PE) es el proceso ágil que más se utiliza.
Organizada como cuatro actividades del marco de trabajo —planeación, diseño,
codificación y pruebas—, la PE
sugiere algunas técnicas innovadoras y poderosas que permiten a un equipo ágil
crear frecuentes lanzamientos de software al entregar características y
funcionalidad que describe y después prioriza usuario final.
El desarrollo de software adaptativo (DSA) destaca la colaboración
humana y la organización propia del equipo fusionando las teorías del trabajo
colaborativo. Organizado con tres actividades del marco de trabajo
—especulación, colaboración y aprendizaje—, el DSA utiliza un proceso iterativo
que incorpora la planeación del ciclo adaptativo, métodos de recopilación de requisitos
relativamente rigurosos y un ciclo iterativo de desarrollo que incorpora grupos
enfocados en el cliente y revisiones técnicas formales como mecanismos de
re-troalimentación en tiempo real.
El método de desarrollo de sistemas dinámicos (MDSD) define tres
diferentes ciclos iterativos —iteración funcional del modelo, iteración de
diseño y construcción e implementación— precedidos por dos actividades del
ciclo de vida adicionales: estudio de factibilidad y estudio de negocios.
La melé subraya el uso de un conjunto de patrones de proceso de
software que han probado su efectividad en proyectos con límites de tiempo muy
ajustados, requisitos cambiantes y que son críticos para el negocio. Cada
patrón de proceso define un conjunto de tareas de desarrollo y permite al
equipo de melé construir un proceso que se adapte a las necesidades del
proyecto.
En concordancia con todo lo anteriormente descrito, el desarrollo ágil
en conjunto a las teorías del trabajo colaborativo las cuales están inmersas de
una forma muy intrínseca en las concepciones de la creación de software fuese
cual fuese su naturaleza, hoy en día estas concepciones forman parte del aula
de clases mas en niveles educativos donde la enseñanza del lenguaje de
programación sigue patrones rígidos que a la final influyen en el estudiante a
seguir líneas individualistas que lo encierran en prolongadas jornadas de
programación, propiciando un desgaste físico y la perdida del objetivo final.
La intención de este trabajo es mostrar y propiciar la adquisición de
metodologías que permitan tener un mejor desempeño en el aula a la hora de
realizar tareas referidas al lenguaje de programación. Aun en cuanto a esto no
quiere decir que solamente es para el aula sino para varios tipos de ámbitos
tanto educativos como empresariales.
Referencias
Beck, K, Extreme Programming Explained:
Embrace Change, Addison-Wesley, 1999.
Beedle, M. eí al, "SCRUM: An extension
pattern language for hyperproductive software development", incluido en:
Pattern Languages of Program Design 4, Addison Wesley, Long-man, Reading , MA
Jacobson, I, "A Resounding 'Yes' to Agüe
Processes—But Also More", Cutter IT Journal,
vol. 15, núm. 1, enero de 2002, pp. 18-24. UEF01) Jeffries, R, et ai, Extreme Programming
Installed, Addison-Wesley, 2001.
Schwaber, K.y M Qeed\e, Agüe Software
Development withSCRUM, Prentice-Hall, 2001.
.
Mitos y desarrollo del Software.
Universidad Pedagógica de el Salvador.
Cátedra:
Ingeniería en sistema
de software.
Alumno:
Alex
Balmore Gómez Cornejo.
Tema:
Mitos
y desarrollo del
Software.
Índice.
Introducción. 3
Objetivos. 4
Mitos
del software. 5-6
Mitos
de gestión. 7
Mitos
del cliente. 8
Desarrollo
ágil. 9
Procesos
xp. 10
DAS. 11
Scrum. 12
Procesos
escrum. 13
Conclusión. 14
Fin.
Introducción.
Actualmente
en nuestro País resaltan personajes con buena calidad de software
La
humanidad sin creerlo pero nosotros tenemos la capacidad de ser grandes
desarrolladores de ello surge la necesidad de comprender como evaluar u
software dejando de fuera mitos surgidos en muchos casos por la manera de cómo
fue desarrollado el sistema
Objetivos.
General.
Desarrollo del software.
Especifico.
Ø
Comprendes los mitos de software.
Ø
Tipos de mitos que surgen y como invadirlos.
Ø
Indagar sobre otros mitos de programación y
procesos.
|
Mitos Del Software
(admón.).
|
Los mitos del software-creencias del desarrollo acerca del software y de los procesos
empleados para construirlo- se pueden rastrear hasta los
primeros días de la computación del desarrollo. Los mitos tienen
ciertos atributos que los convierten en reales no cambiantes.
Muchas de las causas de la
crisis del software pueden ser encontradas en una mitología que surge durante
los primeros años del desarrollo del software Los mitos del software propagaron
información errónea y con fusión
Mito:
Si fallamos en la
planificación podemos añadir más programadores
y recuperar el tiempo perdido.
Realidad:
y recuperar el tiempo perdido.
Realidad:
Ley de Brooks:
"Agregar gente a un proyecto atrasado, lo
atrasa aún más".
Razón: Crear software no es una tarea particional, como dice el
Principio de Brooks: "Gestar a un bebé tarda 9 meses, no importa cuántas mujeres sean asignadas a la tarea.
atrasa aún más".
Razón: Crear software no es una tarea particional, como dice el
Principio de Brooks: "Gestar a un bebé tarda 9 meses, no importa cuántas mujeres sean asignadas a la tarea.
Mito:
Una declaración general de
los objetivos es suficiente para
comenzar a escribir los programas; podemos dar los detalles más adelante.
comenzar a escribir los programas; podemos dar los detalles más adelante.
Realidad:
Una mala definición inicial es la principal
causa del trabajo en
vano. Es esencial una descripción formal y detallada del ámbito de la
información, funciones, rendimiento, interfaces y criterios de validación.
Esto solo puede determinarse después de una exhaustiva comunicación
entre el cliente y el analista.
vano. Es esencial una descripción formal y detallada del ámbito de la
información, funciones, rendimiento, interfaces y criterios de validación.
Esto solo puede determinarse después de una exhaustiva comunicación
entre el cliente y el analista.
Mito:
Una vez que hicimos el
programa y funciona, nuestro trabajo ha terminado.
Realidad:
Realidad:
Los datos industriales
indican que entre el 50% y el 70% de
todo el esfuerzo dedicado a un programa se realizará después de que se
le haya entregado al cliente por primera vez
todo el esfuerzo dedicado a un programa se realizará después de que se
le haya entregado al cliente por primera vez
|
Mitos
_de Gestión
(Profesional).
|
Los gestores están normalmente bajo la presión de
cumplir presupuestos, hacer que no se retrase el proyecto y mejorar la calidad.
El gestor se agarra a un mito del software aun que tal creencia sólo disminuya
la presión temporalmente.
Mito:
¿Por qué debemos cambiar nuestra forma de desarrollar
el Software? Estamos haciendo el mismo tipo de programación a hora que hace
diez años.
Realidad:
Aunque el dominio de la aplicación puede ser el mismo,
la demanda de una mayor productividad y calidad, y el papel crítico del
software en objetivos comerciales estratégicos, ha aumentado sustancialmente.
|
Mitos_del_cliente.
|
Un cliente que solicita una aplicación software puede
ser interno a la compañía o una compañía exterior El cliente cree en los mitos
que existen sobre el software debido a que los gestores y trabajadores responsa
sables hacen muy poco para corregir la mala Información Los mitos conducen a
que el cliente se cree una falsa expectativa y finalmente, quede insatisfecho
con el desarrollo del software
Mito:
Una declaración general de los objetivos es suficiente
para comenzar a escribir los programas, podemos dar los detalles más adelante
Realidad:
Una mala definición inicial es
la principal causa del trabajo baldío en software. Una descripción formal y
detallada del dominio de la información, funciones, rendimiento, interfaces,
ligaduras de diseño y criterios de Validación es esencial. Estas
características pueden determinarse sólo después de una exhaustiva comunicación
entre el cliente y el analista.
Evaluación
|
Desarrollo
ágil.
|
¿Qué es?
Podría decirse que es el
trabajo desarrollado para la realización de un proyecto. Hay innumerables
métodos de desarrollo ágil pero todos tienen un fin que es crear un software
confiable. El software desarrollado en una unidad de tiempo es llamado una
iteración, la cual debe durar de una a cuatro semanas.
|
Esto
consta de:
|
|
Planificación.
Análisis de
requerimientos.
Diseño.
Codificación.
Revisión y documentación.
|
Lo que se pretende con
esto es crear un demo el cual se haya desarrollado sin ningún error al momento
de la ejecución. Estos métodos ágiles enfatizan las comunicaciones cara a cara
en vez de la documentación.
Programación
extrema xp.
Este método de programación está basado en metodologías tradicionales
adaptables a los cambios, en cualquier
etapa del desarrollo. Es considerado como la mejor metodología de desarrollo
todo por lo que esta de acorde y se puede modificar y incluso darle cambios
drásticos sin que el obtenga daños en
ninguna de sus etapas.
Procesos
de xp.
Codificar
Es necesario codificar y plasmar nuestras ideas a través del código. En programación, el código expresa la interpretación del problema, así podemos
utilizar el código para comunicar, para hacer comunes las ideas, y por tanto
para aprender y mejorar.
Hacer pruebas
Las pruebas dan la oportunidad de saber si lo implementado
es lo que en realidad se tenía en mente. Las pruebas nos indican que nuestro
trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese
originar un fallo en nuestro sistema, entonces habremos acabado
por completo.
Escuchar
Si vamos a hacer pruebas tenemos que preguntar si lo
obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a
nuestros clientes cuáles son los problemas de su negocio, debemos de
tener una escucha activa explicando lo que es fácil y difícil de obtener, y la
realimentación entre ambos nos ayudan a todos a entender los problemas.
Diseñar
El diseño crea una estructura que organiza la lógica del sistema, un buen diseño
permite que el sistema crezca con cambios en un solo lugar. Los diseños deben
de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo
apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños,
estos deben de ser corregidos cuanto antes.
Resumiendo las actividades de Xp: Tenemos que codificar
porque sin código no hay programas, tenemos que hacer pruebas
por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que
escuchar, porque si no escuchamos no sabemos qué codificar ni probar, y tenemos
que diseñar para poder codificar, probar y escuchar
indefinidamente.
Desarrollo Adoptivo del
Software
(DAS).
Es
una propuesta de desarrollo para software y sistemas de mayor complejidad
apoyada en la colaboración humana y de equipo.
Los métodos ágiles enfatizan
las comunicaciones cara a cara en vez de la documentación. La mayoría de los
equipos ágiles están localizados en una simple oficina abierta, a veces
llamadas "plataformas de lanzamiento" La oficina debe incluir revisores,
escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software
funcional es la primera medida del progreso. Combinado con la preferencia por
las comunicaciones cara a cara, generalmente los métodos ágiles son criticados
y tratados como "indisciplinados" por la falta de documentación
técnica.
Scrum.
Scrum, más que una
metodología de desarrollo software, es una forma de auto-gestión de los equipos
de programadores. Un grupo de programadores deciden cómo hacer sus tareas y
cuánto van a tardar en ello. Scrum ayuda a que trabajen todos juntos, en la
misma dirección, con un objetivo claro.
Scrum permite además seguir de forma clara el avance de las tareas a
realizar, de forma que los "jefes" puedan ver día a día cómo progresa
el trabajo.
Sin embargo, Scrum no es una metodología de desarrollo,
puesto que no indica qué se debe hacer para hacer el código. Debería, por
tanto, complementarse con alguna otra metodología de desarrollo. Se lleva bien
con las metodologías ágiles y en concreto, con la programación extrema.
Procesos
del Scrum.
En Scrum un
proyecto se ejecuta en bloques temporales cortos y fijos. Cada iteración tiene
que proporcionar un resultado completo, un incremento de producto final que sea
susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo
solicite.
El proceso
parte de la lista de
objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta
lista el cliente prioriza los objetivos balanceando el
valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera
regular el cliente puede maximizar
la utilidad de lo que se desarrolla y el retorno de
inversión mediante la re
planificación de objetivos que
realiza al inicio de cada iteración.
Conclusión.
Cada personal de desarrollo de
sistemas debe de tener la manera de compren lo que su sistema requiere para
evitar que surjan inconvenientes en procesos de demás que aun no se han
detallado.
De igual manera demos saber utilizar un método de
programación como el de xp para cuando
el sistema u desarrollo requiera cambios no nos daría problemas u otros
inconvenientes.
Suscribirse a:
Entradas (Atom)