Análisis y diseño de sistemas

Introducción:
El Gartner Group sugiere que “una adherencia consistente a
lineamientos de una metodología moderadamente rigurosa
puede proporcionar a 70% de las organizaciones [desarrollo
de sistemas] una mejora de productividad de al meno 30% en
dos años” ¨1¨

El desarrollo de sistemas se refiere a todas las actividades

que deben realizarse para crear sistemas de información en
una organización; asimismo alude a procesos relacionados
para lograrlo.

Puesto que los ambientes organizacionales específicos y las

tecnologías generales cambian con el tiempo, las
organizaciones necesitan nuevos sistemas, o bien requieren
revisar ampliamente los sistemas existentes, para continuar
cumpliendo con sus objetivos. De tal modo, el desarrollo de
sistemas es un proceso continuo en todas las organizaciones
que hacen uso de ellos.

Al mismo tiempo, los sistemas de información son costosos y

el desarrollo de sistemas tiende a fallar. Por ello, es muy
deseable adquirir nuevos sistemas mediante algún tipo de
proceso que:

Reduzca el riesgo de falla.

Produzca sistemas que realmente aumenten la eficacia de la
organización.
 Metodologías de desarrollo de software

Incremental

concepto
El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque
incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de
desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta
adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes
denominaciones:

 Método de las comparaciones limitadas sucesivas.

 Ciencia de salir del paso.
 Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva
de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica
secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada
secuencia lineal produce un incremento del software. El primer incremento generalmente es un
producto esencial denominado núcleo.

Características

Sin embargo, no se trata de iteraciones independientes. Por el contrario, están vinculadas de forma
que cada una suponga un avance con respecto a la anterior. Otras características esenciales de este
modelo son:

 Los incrementos son pequeños.

 Permite una fácil administración de las tareas en cada iteración.
 La inversión se materializa a corto plazo.
 Es un modelo propicio a cambios o modificaciones.
 Se adapta a las necesidades que surjan.

Para que esto sea posible, se debe tener en cuenta que las iteraciones no pueden ser demasiado rígidas y
que no existan tareas simultáneas. El modelo incremental exige un encadenamiento progresivo de cada
tarea. Scrum y Kanban son las herramientas más conocidas que emplean este modelo de gestión.

Fases o etapas
El modelo de gestión incremental no es un modelo necesariamente rígido, es decir, que puede
adaptarse a las características de cualquier tipo de proyecto, existen al menos 7 fases que debemos tener
en cuenta a la hora de implementarlo:

1. Requerimientos: son los objetivos centrales y específicos que persigue el proyecto.

2. Definición de las tareas y las iteraciones: teniendo en cuenta lo que se busca, el siguiente paso
es hacer una lista de tareas y agruparlas en las iteraciones que tendrá el proyecto. Esta
 agrupación no puede ser aleatoria. Cada una debe perseguir objetivos específicos que la definan
como tal.
3. Diseño de los incrementos: establecidas las iteraciones, es preciso definir cuál será la
evolución del producto en cada una de ellas. Cada iteración debe superar a la que le ha
precedido. Esto es lo que se denomina incremento.
4. Desarrollo del incremento: posteriormente se realizan las tareas previstas y se desarrollan los
incrementos establecidos en la etapa anterior.
5. Validación de incrementos: al término de cada iteración, los responsables de la gestión del
proyecto deben dar por buenos los incrementos que cada una de ellas ha arrojado. Si no son los
esperados o si ha habido algún retroceso, es necesario volver la vista atrás y buscar las causas de
ello.
6. Integración de incrementos: una vez son validados, los incrementos dan forma a lo que se
denomina línea incremental o evolución del proyecto en su conjunto. Cada incremento ha
contribuido al resultado final.
7. Entrega del producto: cuando el producto en su conjunto ha sido validado y se confirma su
correspondencia con los objetivos iniciales, se procede a su entrega final.

Ventajas Software a medida

1. Cubre necesidades empresariales específicas, necesidades del negocio de

flujos específicos y se adapta a las necesidades específicas de un negocio.
2. Orientado a la integración con otras aplicaciones de la organización
3. Puede cambiarse o adecuarse con el tiempo, de acuerdo a los cambios de
la organización
4. Bajos costos en modificación e implementación
5. Flexibilidad en comparación a los paquetes de software
6. Se puede implementar por módulos.

Desventajas del software a medida

1. Para las necesidades de grandes empresas, el costo del desarrollo a

medida puede ser mayor a un software empaquetado
2. Si no se programa bajo ciertos estándares y no se lleva a cabo unas
adecuadas pruebas del software, estos puedes presentar errores frecuentes.
3. Requiere de un seguimiento post implementación que puede llegar a
durar varias semanas (Dependiendo del tamaño del Software).
4. De no tener clara las necesidades o un adecuado levantamiento de
información o validación de los requerimientos, se puede llegar a recaer en
sobrecostos para poder solucionar dichos problemas.

Conclucion
Utilización de la ingeniería de software como mecanismo de aplicación y evaluación de la
eficiencia y calidad operacional de un sistema de función crítica, visto como la definición de
criterios de operación bajo condiciones y límites establecidos por el sistema y por las
características externas del medio externo. En el desarrollo de productos de software las etapas
de análisis de requerimientos y diseño toma gran parte del tiempo del proyecto. El modelo
planteado en este proyecto pretende establecer unos parámetros de diseño generales que
permitan agilizar la implementación de proyectos tipo sistemas de control por software, cuya base
común es el procesamiento de señales digitales en busca de comportamientos de interés
(caracterización de señales). La utilización de un ciclo de vida específico para el desarrollo de
software,

Desarrollo evolutivo

Concepto:

El desarrollo evolutivo es una metodología de desarrollo de software muy

relacionada con, pero claramente distinta de, desarrollo por prototipos. El énfasis
esta puesto sobre la importancia de obtener un sistema de producción flexible
y expansible Así, si los requerimientos cambian durante el desarrollo del sistema,
entonces con un mínimo de esfuerzo y tiempo se puede desarrollar un sistema de
trabajo flexible.
La diferencia fundamental entre desarrollo evolutivo y prototipos de software es
que el desarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo que
tendría la propiedad de satisfacer los nuevos requerimientos lo más rápido posible.
En contraste, prototipos usa un enfoque iterativo solo para determinar los
requerimientos generacionales Por lo tanto el tiempo tomado entre cada Hite
ración es mucho más importante para el desarrollo evolutivo. En la figura 10 se
puede ver gráficamente esta diferencia.

Características
 Fases o etapas

VENTAJAS

 La especificación 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 más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del
cliente.

DESVENTAJAS

 Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema
se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del
sistema.

 Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la
estructura del software haciendo costoso el mantenimiento.

 Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que

pueden ser incompatibles con otras o que poca gente sabe utilizar.
Conclusión
A medida que un programa en evolución cambia, su estructura se hace más
compleja, a menos que se lleven a cabo esfuerzos activos para evitar este
fenómeno.
 Evolución del programa.
La evolución del programa es un proceso autor regulador, y una medición de
atributos del sistema, como el tamaño, el tiempo entre versiones, el número de
errores advertidos, etc., revela las tendencias estadísticas significativas y las
características invariantes.
 Conservación de la estabilidad organizativa.
Durante el tiempo de vida de un programa, su rapidez de desarrollo es casi
constante e independiente de los recursos dedicados al desarrollo del sistema.
 Conservación de la familiaridad

Desarrollo en espiral

Concepto

En el proceso de desarrollo de software un sistema informático está compuesto por hardware y

software. El buen funcionamiento del hardware es, en principio, comparable a la de cualquier otro
equipo de cómputo existente. Sin embargo, respecto al software, su construcción y resultados han
sido en el pasado cuestionados debido a los problemas asociados a ellos: Los sistemas no
responden a las expectativas de los usuarios. Los programas “se caen” con cierta frecuencia. Los
costes del software son difíciles de prever y normalmente superan las estimaciones propuestas
con anterioridad. La modificación del software es una tarea difícil y costosa. En el desarrollo de
software, se establece algunas particularidades como los modelos de ciclo de vida del software,
uno de estos modelos es el llamado “El Modelo Evolutivo Espiral” cuyo autor es Barry Boehm
(1988), este tipo de modelo permite tener en cuenta el riesgo que aparece al momento de
desarrollar software, se comienza analizando las diferentes alternativas de procesos en el diseño
del software, se selecciona el riesgo más asumible y se hace un ciclo de la espiral. Si el usuario
requiere hacer avances en el software, se evalúa las diferentes alternativas y riesgos y se realiza un
nuevo giro a la espiral, así hasta que llegue un momento en el que el software diseñado sea
aceptado y no necesite mejorarse con un nuevo ciclo.

Carateristicas

Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente. Este modelo es
el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los
programas modernos de PC´s. La ingeniería puede desarrollarse a través del ciclo de vida clásico o
el de construcción de prototipos. Ver fig. 3 anexos Este es el enfoque más realista actualmente

Fases o etapas

Determinar o fijar los objetivos. En este paso se definen los objetivos específicos para
posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña
una planificación detallada de gestión y se identifican los riesgos. 2. Análisis del riesgo. En este
paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se
definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean
estrategias alternativas. 3. Desarrollar, verificar y validar. En este tercer paso, después del análisis
de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla. 4.
Planificar. En este último paso es donde el proyecto se revisa y se toma la decisión si se debe
continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes
para la siguiente fase del proyecto.

VENTAJAS DEL MODELO ESPIRAL No requiere una definición completa de los requerimientos del
software a desarrollar para comenzar su funcionalidad. En la terminación de un producto desde el
final de la primera iteración es muy factible aprobar los requisitos. Sufrir retrasos corre un riesgo
menor, por que se comprueban los conflictos presentados tempranamente y existe la forma de
poder corregirlos a tiempo.

DESVENTAJAS DEL MODELO ESPIRAL Existe complicación cuando se evalúa los riesgos. Se requiere
la participación continua por parte del cliente. Se pierde tiempo al volver producir inicialmente
una especificación completa de los requerimientos cuando se modifica o mejora el software.

CONCLUCIÓN

El prototipo del modelo en espiral para la ingeniería de software es en la actualidad el enfoque

más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque
evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y
reaccionar a los riesgos en cada nivel del modelo en espiral. Utiliza la creación de prototipos como
un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo
desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de
prototipos.

Proceso unificadode rational (rup)

Concepto
Boehm, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo
Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que
aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas
de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente
quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas
y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el
producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo
ciclo.

Características:

1.1Iterativo e Incremental

1.2Dirigido por los casos de uso

1.3Centrado en la arquitectura

1.4Enfocado en los riesgos

 Fases o etapas:

EL modelo en espiral se divide en un número de actividades de marco de trabajo, también

llamadas REGIONES DE TAREAS , Cada una de las regiones están compuestas por un conjunto
de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del
proyecto que va a emprenderse en todos los casos se aplican actividades de protección.

VENTAJAS
 El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora.
 Como el software evoluciona a medida que progresa el proceso, el desarrollador y el
cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
 El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de
prototipos en cualquier etapa de evolución del producto.
 El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas
las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de
que se conviertan en problemas.
 En la utilización de grandes sistemas a doblado la productividad.

DESVENTAJAS

 Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

 Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
 Genera mucho tiempo en el desarrollo del sistema
 Modelo costoso
 Requiere experiencia en la identificación de riesgos

Conclusión
Los conceptos anteriormente tratados – dirigido por casos de uso,
centrado en arquitectura, desarrollo iterativo e incremental – son igualmente
importantes. La arquitectura provee la estructura sobre la cual guiar el trabajo
en iteraciones, mientras que los casos de uso definen las metas y dirigen el
trabajo en cada iteración. Remover cualquiera de estos conceptos reducirá
severamente el valor del Proceso Unificado. Es como una mesa de tres patas, sin
alguna de ellas, la mesa se caerá.
Cascada:

Concepto:

La clase de la fecha Octubre 13 del 2014 se retroalimento todo lo que había

suscitado el semestre anterior con enfoque breve.

Se notó la importancia de recordar argumentos teóricos de los ciclos de vidas de

software tanto así que el objeto de clase se logró alcanzar cuando los integrantes
del curso compartieron ideas de lo aprendido, dando así un dinamismo. La
Docente argumentaba cosas que en cierto modo solo no existían en la mente de
los estudiantes.

Por otro lado en esta entrada del blog se analizara el modelo en cascada como un
ciclo de vida descriptivo.

Carateristicas:

 Requerimientos “Considerado el paso más importante“

 Diseño “Componentes, Modulo , interfaces .. otros ”
 Construcción “Consiste en la construcción del Producto”
 Integración “Compilación de módulos de forma global”
 Test “Prueba y error etapa de test en algunos casos”
 Instalación “Etapa de implementación si está bien testeado”
 Mantenimiento “Etapa consecuente a mantener la App”

Fases o etapas.
 Ventajas del Modelo Cascada
 No se pasa a otra etapa si no está cumplida la actual
 Una gran cantidad de énfasis en la documentación
 El método de cascada también es bien conocido entre los desarrolladores de software
por lo que es fácil de usar. Es más fácil desarrollar una variedad de software a través
de este método en el corto espacio de tiempo.
Desventajas del Modelo Cascada
 Existen variaciones del cliente que el cascada no puede asumir si ya ha pasado una
etapa.
 Se pierde una gran cantidad de tiempo.
 Las pruebas se dan bastante tarde en el proceso de desarrollo
 La documentación para proyectos pequeños es pesada

CONCLUSIÓN
El modelo en Cascada es un método clásico de desarrollo de software orientando
a proyectos que tengan bien definidos sus requerimientos y que no sean
entregados en tiempo corto. Si se analiza el modelo en cascada se enfoca puntos
importantes, uno de esos puntos es que este método nació para para la
construcción de hardware y que con el pasar el tiempo se acoplo al desarrollo de
software, otro punto es que cuenta con algunas desventajas que han querido ser
modificadas por alguno modelos mencionados anteriormente en la
documentación.

Concepto
Concepto

Actualmente la mayoría de los programadores no pensamos en una metodología

de desarrollo a la hora de crear algún software, o sea tenemos cierta tendencia en
embebernos en cuestiones técnicas, hablar de lenguajes de programación, de
técnicas de programación, de entornos de desarrollo o de editores de recursos.
Pero se nos pasan por alto temas muy importantes como es la ingeniería de
software, la manera en que debemos de hacer nuestro software. Alrededor de
cómo hacer software hay un gran número de teorías, propuestas, etc. El primer
paso es conocer las metodologías más relevantes o buscar a alguien que las
conozca, y en una situación ideal haber trabajado con varias de ellas.
No hay metodología que funcione de manera universal, de hecho cada vez más
las metodologías se conciben como Marco Metodológico que son necesario
ajustar para cada organización y tipo de Proyecto. Realizar este ajuste es algo que
requiere de una experiencia y un conocimiento previo. El problema con la
implantación de una metodología es que no se suele tener una segunda
oportunidad.
Carcteristicas

Las características fundamentales del método son:

 Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

 Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,

incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la
codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java,
DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres
últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework
orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.

 Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo

por dos personas en un mismo puesto. La mayor calidad del código escrito de esta
manera -el código es revisado y discutido mientras se escribe- es más importante que la
posible pérdida de productividad inmediata.

 Frecuente integración del equipo de programación con el cliente o usuario. Se

recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

 Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas
frecuentes.

 Refactorización del código, es decir, reescribir ciertas partes del código para aumentar
su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de
garantizar que en la refactorización no se ha introducido ningún fallo.
 Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo
de cada módulo en grupos de trabajo distintos, este método promueve el que todo el
personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas
de regresión garantizan que los posibles errores serán detectados.

 Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo
funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta
que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si
se requiere, que realizar algo complicado y quizás nunca utilizarlo.
 CARACTERÍSTICAS XP
 Metodología basada en prueba y error
 Fundamentada en Valores y Prácticas
 Expresada en forma de 12 Prácticas–Conjunto completo–Se soportan unas
a otras–Son conocidas desde hace tiempo. La novedad es juntarlas


Etapas y fases

metodología.

Ventajas:
Programación organizada.
Menor taza de errores.
Satisfacción del programador.

Desventajas:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.

CONCLUSIONES
Apostolado de metodologías exitosas
Aporte de la experiencia práctica a los modelos teóricos
Enfoque de conjunto de prácticas como rompecabezas
Tecnología en expansión
Importancia de revisitar las metodologías desde la experiencia práctica