Está en la página 1de 10

PRINCIPIOS, MODELOS, MTODOs, METODOLOGAS TCNICAS,

ACTIVIDADES Y HERRAMIENTAS EN EL PROCESO DE


DESARROLLO DE SOFTWARE
Principios:
Eliminar Desperdicios: Desperdicio es todo aquello en lo que invertimos recursos pero que no
es traducido en valor para nuestro cliente. Este principio nos advierte que siempre hay que estar
en la bsqueda de eliminar desperdicios en nuestro proceso, en cualquiera de las formas que
este pueda presentar.Crear Conocimiento: El proceso debiera considerar en todas las reas que
sea posible, transmitir el conocimiento de una forma rpida y eficiente para que el equipo est
lo ms nivelado en el entendimiento de lo que se produce, cmo se produce y para qu se
produce

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.

MODELOS DE PROCESO DE SOFTWARE

Codificar y corregir
Modelo en cascada
Desarrollo evolutivo
Desarrollo formal de sistemas
Desarrollo basado en reutilizacin
Desarrollo incremental
Desarrollo en espiral

Codificar y corregir (Code-and-Fix)


Este es el modelo bsico utilizado en los inicios del desarrollo de software. Contiene dos pasos:
Escribir cdigo.
Corregir problemas en el cdigo.
Se trata de primero implementar algo de cdigo y luego pensar acerca de requisitos, diseo, validacin,
y Mantenimiento.
Este modelo tiene tres problemas principales:
Despus de un nmero de correcciones, el cdigo puede tener una muy mala estructura, hace
que los arreglos sean muy costosos.
Frecuentemente, an el software bien diseado, no se ajusta a las necesidades del usuario, por lo
que es rechazado o su reconstruccin es muy cara.
El cdigo es difcil de reparar por su pobre preparacin para probar y modificar.
Modelo en cascada
El modelo en cascada consta de las siguientes fases:
1. Definicin de los requisitos: Los servicios, restricciones y objetivos son establecidos con los
usuarios del sistema. Se busca hacer esta definicin en detalle.
2. Diseo de software: Se particiona el sistema en sistemas de software o hardware. Se establece
la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los
componentes del sistema.
3. Implementacin y pruebas unitarias: Construccin de los mdulos y unidades de software.
Se realizan pruebas de cada unidad. Departamento de Sistemas Informticos y Computacin.
4. Integracin y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se
entrega el conjunto probado al cliente.
5. Operacin y mantenimiento: Generalmente es la fase ms larga. El sistema es puesto en
marcha y se realiza la correccin de errores descubiertos. Se realizan mejoras de
implementacin. Se identifican nuevos requisitos.

Algunos problemas que se observan en el modelo de cascada son:


Las iteraciones son costosas e implican rehacer trabajo debido a la produccin y aprobacin de
documentos.
Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las
siguientes fases.
Los problemas se dejan para su posterior resolucin, lo que lleva a que estos sean ignorados o
corregidos de una forma poco elegante.
Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el
largo tiempo de entrega del producto.
Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difcil responder a
cambios en los requisitos.
Este modelo slo debe usarse si se entienden a plenitud los requisitos. An se utiliza como parte de
proyectos grandes.
Desarrollo evolutivo
La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial, exponerla a los
comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado.
Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario, ya que las
actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.
Existen dos tipos de desarrollo evolutivo:
Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos
hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene ms claras. El
sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario.
Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para
mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por
definir los requisitos que no estn claros para el usuario y se utiliza un prototipo para
experimentar con ellos.
El prototipo ayuda a terminar de definir estos requisitos.
Entre los puntos favorables de este modelo estn:
La especificacin puede desarrollarse de forma creciente.

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.

Desde una perspectiva de ingeniera y administracin se identifican los siguientes problemas:


Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema
se necesita desarrollar rpido, no es efectivo producir documentos que reflejen cada versin del
sistema.
Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la
estructura del software haciendo costoso el mantenimiento.
Se requieren tcnicas y herramientas: Para el rpido desarrollo se necesitan herramientas que
pueden ser incompatibles con otras o que poca gente sabe utilizar.
Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa
ejecutable.
Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa
ejecutable.
Observaciones sobre el desarrollo formal de sistemas:
Permite demostrar la correccin del sistema durante el proceso de transformacin. As, las
pruebas que verifican la correspondencia con la especificacin no son necesarias.

Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad
importantes.

Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.


Desarrollo basado en reutilizacin
Como su nombre lo indica, es un modelo fuertemente orientado a la reutilizacin.
Este modelo consta de 4 fases ilustradas en la 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 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.

Desventajas de este modelo:


Los compromisos en los requisitos son inevitables, por lo cual puede que el software no
cumpla las expectativas del cliente.
Las actualizaciones de los componentes adquiridos no estn en manos de los desarrolladores del
sistema.
Procesos iterativos
A continuacin se expondrn dos enfoques hbridos, especialmente diseados para el soporte de las
iteraciones:
Desarrollo Incremental.
Desarrollo en Espiral.
Desarrollo incremental
Es una combinacin del Modelo de Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones
hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo,
dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen
conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Entre las ventajas del modelo incremental se encuentran:


Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a
usarlo desde el primer incremento.
Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del
sistema.
Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada
incremento.
Las partes ms importantes del sistema son entregadas primero, por lo cual se realizan ms
pruebas en estos mdulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas).
Cada incremento debe aumentar la funcionalidad.
Es difcil establecer las correspondencias de los requisitos contra los incrementos.
Es difcil detectar las unidades o servicios genricos para todo el sistema.
Desarrollo en espiral
Es actualmente uno de los ms conocidos y fue propuesto por Boehm El ciclo de desarrollo se
representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una
actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del
producto. Se realiza un diseo detallado del plan administrativo. Se identifican los riesgos y se
elaboran estrategias alternativas dependiendo de estos.
2. Evaluacin y reduccin de riesgos: Se realiza un anlisis detallado de cada riesgo identificado.
Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo
los pasos para reducir los riesgos.
3. Desarrollo y validacin: Se escoge el modelo de desarrollo despus de la evaluacin del riesgo.
El modelo que se utilizar (cascada, sistemas formales, evolutivo, etc.) depende del riesgo
identificado para esa fase.
4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.

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.

SELECCIN DEL MODELO APROPIADO SEGN LAS CARACTERISTICAS


DE LOS PROYECTOS DE SOFTWARE
Cuando se gestiona un proyecto exitoso, es necesario entender que este puede llegar a fracasar. Segn
John Reel, existen 10 razones por las cuales un proyecto puede fracasar:
1. El personal de software no entiende las necesidades del los clientes.
2. El mbito del producto est mal definido.
3. Los cambios se gestionan mal.
4. La tecnologa elegida cambia.
5. Las necesidades comerciales cambian.
6. Los plazos de entrega no son realistas.
7. Los usuarios se resisten a la utilizacin del software.
8. Se pierde el patrocinio.
9. El equipo del proyecto carece de personal con las habilidades apropiadas.
10.
Los gestores evitan las mejores prcticas y las lecciones aprendidas.
Para tener xito en la consecucin de un proyecto es necesario comenzar con pie derecho, esto se lo
logra trabajando duro para entender el problema y dar una solucin adecuada. Se debe rastrear el
proyecto conforme se elabora el producto y se aprueba por parte del grupo de control de calidad. Es
importante que el gestor del proyecto tome decisiones inteligentes para no poner en riesgo el desarrollo
de la solucin. Por ltimo, se debe analizar los resultados obtenidos para obtener la experiencia
necesaria en la construccin de otros proyectos.

También podría gustarte