Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Calidad Intrnseca: Todas las pequeas partes que conforman el producto final deben ser
construidas con calidad desde el primer momento y no esperar que un proceso futuro sea el
encargado de agregarla. Esto se traduce en integracin continua, automatizacin de procesos
repetitivos (testing, deploy, etc) y eliminacin de cdigo duplicado al momento de detectarlo;
pero tambin en facilitar las discusiones cara a cara por sobre e-mail y en la disponibilidad de
personas.
Tomar decisiones con toda la informacin (Diferir compromiso): Este principio advierte que
no es buena idea tomar decisiones en base a estimados o adivinanzas. Las decisiones se deben
postergar hasta el momento en que se tenga la mayor cantidad de informacin, sin caer en la
irresponsabilidad.
Entregar Rpido: Al entregar rpido se produce un ciclo de feedback ptimo y permite al
equipo de desarrollo ajustar su modelo a la realidad con una mayor precisin y menor costo para
el proyecto. Esto tambin se traduce en limitar la cola de tareas pendientes a un mnimo dado,
para que siempre el alcance de lo que resta quepa dentro del contexto mental del equipo. Limita
el trabajo en curso para cada persona de manera que puedan enfocarse en cada tarea a mano.
Respetar a las personas: Entrega el poder de tomar decisiones a quienes tienen el
conocimiento y experiencia tcnica para hacerlo, es decir, quienes implementarn finalmente las
decisiones. Realiza entrenamientos internos o externos e incentiva la curiosidad intelectual.
Alienta el espritu por mejorar el oficio.
Optimizar el todo: Enfoca tus esfuerzos de optimizacin en el flujo de valor que sale hacia el
usuario y no en cada una de las partes que conforman tu proceso, usa una mirada global para
optimizar. Siempre ten en tu nmina los mejores profesionales, tcnicos y empleados que
puedas conseguir, finalmente es el equipo el que hace la diferencia.
Codificar y corregir
Modelo en cascada
Desarrollo evolutivo
Desarrollo formal de sistemas
Desarrollo basado en reutilizacin
Desarrollo incremental
Desarrollo en espiral
Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en
una mejora de la calidad del software.
Es ms efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del
cliente.
Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad
importantes.
marco.
4. Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se integran los
componentes y subsistemas. La integracin es parte del desarrollo en lugar de una actividad
separada.
Este modelo consta de 4 fases ilustradas en la Figura 9. A continuacin se describe cada fase:
1. Anlisis de componentes: Se determina qu componentes pueden ser utilizados para el sistema
en cuestin. Casi siempre hay que hacer ajustes para adecuarlos.
2. Modificacin de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los
componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay
que seguir buscando componentes ms adecuados (fase 1).
3. Diseo del sistema con reutilizacin: Se disea o reutiliza el marco de trabajo para el sistema.
Se debe tener en cuenta los componentes localizados en la fase 2 para disear o determinar este
marco.
4. Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se integran los
componentes y subsistemas. La integracin es parte del desarrollo en lugar de una actividad
separada.
Este modelo a diferencia de los otros toma en consideracin explcitamente el riesgo, esta es una
actividad importante en la administracin del proyecto.
El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones se determinan
distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se
evalan los riesgos con actividades como anlisis detallado, simulacin, prototipos, etc. Se desarrolla
un poco el sistema.
MTODOS:
Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin
de programas, pruebas y mantenimiento. Estos mtodos dependen de un conjunto de principios bsicos
que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas
descriptivas.
METODOLOGA:
Un proceso de software detallado y completo suele denominarse Metodologa. Las metodologas se
basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental, etc.).
Adicionalmente una metodologa debera definir con precisin los artefactos, roles y actividades
involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin de la metodologa al
proyecto, guas para uso de herramientas de apoyo, etc. Habitualmente se utiliza el trmino mtodo
para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas) actividades
del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo.
En actividades de anlisis y diseo, podemos clasificar las metodologas en dos grupos:
Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte, considerando su
filosofa de desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del
proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de Metodologas
Tradicionales. Otras metodologas, denominadas Metodologas giles, estn ms orientadas a la
generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeos.
A continuacin se revisan brevemente cada una de estas categoras de metodologas.
Metodologas estructuradas
Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la Programacin
Estructurada, luego a mediados de los 70s aparecieron tcnicas para el Diseo (por ejemplo: el
diagrama de Estructura) primero y posteriormente para el Anlisis (por ejemplo: Diagramas de Flujo de
Datos). Estas metodologas son particularmente apropiadas en proyectos que utilizan para la
implementacin lenguajes de 3ra y 4ta generacin.
Metodologas orientadas a objetos
Su historia va unida a la evolucin de los lenguajes de programacin orientada a objeto, los ms
representativos: a fines de los 60s SIMULA, a fines de los 70s Smalltalk-80, la primera versin de C+
+ por Bjarne Stroustrup en 1981 y actualmente Java11 o C# de Microsoft. A fines de los 80s
comenzaron a consolidarse algunos mtodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de conseguir una
unificacin de sus mtodos y notaciones, que posteriormente se reorienta a un objetivo ms modesto,
para dar lugar al Unified Modeling Language (UML)12, la notacin OO ms popular en la actualidad.
Metodologas tradicionales (no giles)
Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin durante todo el
proceso de desarrollo; llamadas tambin metodologas tradicionales o clsicas, donde se realiza una
intensa etapa de anlisis y diseo antes de la construccin del sistema.
Todas las propuestas metodolgicas antes indicadas pueden considerarse como metodologas
tradicionales. Aunque en el caso particular de RUP, por el especial nfasis que presenta en cuanto a su
adaptacin a las condiciones del proyecto (mediante su configuracin previa a aplicarse), realizando
una configuracin adecuada, podra considerarse gil.
Metodologas giles
Un proceso es gil cuando el desarrollo de software es incremental (entregas pequeas de software, con
ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana
comunicacin), sencillo (el mtodo en s mismo es fcil de aprender y modificar, bien documentado), y
adaptable (permite realizar cambios de ltimo momento).
ACTIVIDADES
Planificacin
La importante tarea a la hora de crear un producto de software es obtener los requisitos o el anlisis de
los requisitos. Los clientes suelen tener una idea ms bien abstracta del resultado final, pero no sobre
las funciones que debera cumplir el software.
Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un anlisis del mbito del
desarrollo. Este documento se conoce como especificacin funcional.
Implementacin, pruebas y documentacin
La implementacin es parte del proceso en el que los ingenieros de software programan el cdigo para
el proyecto.
Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del
proceso tiene la funcin de detectar los errores de software lo antes posible.
La documentacin del diseo interno del software con el objetivo de facilitar su mejora y su
mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentacin de un API, tanto
interior como exterior.
Despliegue y mantenimiento
El despliegue comienza cuando el cdigo ha sido suficientemente probado, ha sido aprobado para su
liberacin y ha sido distribuido en el entorno de produccin.
Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores de
software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta
inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del
software. El mantenimiento y mejora del software de un software con problemas recientemente
desplegado puede requerir ms tiempo que el desarrollo inicial del software. Es posible que haya que
incorporar cdigo que no se ajusta al diseo original con el objetivo de solucionar un problema o
ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que
sea oportuno redisear el sistema para poder contener los costes de mantenimiento.
Tcnicas y herramientas:
Son un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y
desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software.
Las Herramientas CASE son un conjunto de mtodos, utilidades y tcnicas que facilitan la
automatizacin del ciclo de vida del desarrollo de sistemas de informacin, completamente o en alguna
de sus fases.
La sigla genrica para una serie de programas y una filosofa de desarrollo de software que ayuda a
automatizar el ciclo de vida de desarrollo de los sistemas.
Una innovacin en la organizacin, un concepto avanzado en la evolucin de tecnologa con un
potencial efecto profundo en la organizacin. Se puede ver al CASE como la unin de las herramientas
automticas de software y las metodologas de desarrollo de software formales.
El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:
Anlisis de datos y procesos integrados mediante un repositorio.
Generacin de interfaces entre el anlisis y el diseo.
Generacin del cdigo a partir del diseo.
Control de mantenimiento.
Tipos de Herramientas CASE
No existe una nica clasificacin de herramientas CASE, es difcil incluirlas en una clase determinada.
Podran clasificarse atendiendo a:
Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que abarca.
La arquitectura de las aplicaciones que produce.
Su funcionalidad.
Las herramientas CASE, en funcin de las fases del ciclo de vida abarcadas, se pueden agrupar de la
forma siguiente:
Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del
ciclo de vida del desarrollo de sistemas. Son llamadas tambin CASE workbench.
Las herramientas I-CASE se basan en una metodologa. Tienen un repositorio y aportan tcnicas
estructuradas para todas las fases del ciclo de vida. Estas son las caractersticas que les confieren su
mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo, no todas ellas son modernas
en el sentido de aprovechar la potencia de las estaciones de trabajo o la utilizacin de lenguajes de alto
nivel o tcnicas de prototipo.
Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la
automatizacin y soporte de las actividades desarrolladas durante las primeras fases del desarrollo:
anlisis y diseo.
Una estrategia posible es utilizar una U-CASE para anlisis y diseo, combinada con otras
herramientas ms modernas para las fases de construccin y pruebas. En este caso, habra que vigilar
cuidadosamente la integracin entre las distintas herramientas.