REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN

U. E COLEGIO “MARÍA AUXILIADORA”

BARQUISIMETO – LARA

Fases en el diseño de un sistema

empleando metodología incremental
del desarrollo de un sistema

Estudiante:

Paola Urbina

Sección: 5to “B”

Profe: Paul Pereira

Área: Sistemas de información

Metodología Incremental del desarrollo de un sistema de información

Es un conjunto de actividades llevadas a cabo para desarrollar y poner en marcha un Sistema
de Información, Es un sistema de procesos, métodos y herramientas coherentes entre sí y el
contexto de una situación de interés o problemática para solucionarlo, sin embargo consisten
en identificar el suprasistema y objetivos, explicar el comportamiento o propiedades de todo
el suprasistema, definir y determinar el comportamiento del mismo

Objetivos de la metodología para el desarrollo de un sistema de información

Definir actividades a llevarse a cabo en un Proyecto de S.I.

Unificar criterios en la organización para el desarrollo de S.I.
Proporcionar puntos de control y revisión
Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en sí
Satisfacer las necesidades de los usuarios del sistema
Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al
desarrollo
Ajustarse a los plazos y costos previstos en la planificación
Generar de forma adecuada la documentación asociada a los sistemas
Facilitar el mantenimiento posterior de los sistemas

Tipos de metodología para el desarrollo de sistemas

Estructurada:
Se maneja como proyecto
Gran volumen de datos y transacciones
Abarca varias áreas organizativas de la empresa
Tiempo de desarrollo largo
Requiere que se cumplan todas las etapas, para poder cumplir las siguientes
(progresión lineal y secuencial de una fase a la otra.

Incremental:
Se deriva de la estructurada
Permite seguir secuencias ascendentes o descendentes en las etapas del
desarrollo
Permite cumplir etapas o fases en paralelo, por lo que es más flexible que la
estructurada.

Prototipos
Desarrolla modelo en escala del sistema propuesto (sistema objetivo)
 En otras palabras, desarrolla un “demo”, que de ser aprobado por el usuario, se
culmina con todas las funcionalidades.
Se prueba y refina hasta que usuarios conformes
Identifica necesidades de información
Maneja principales procedimientos orientados a transacciones
Produce informes críticos
Permite consultas rudimentarias
Complementa especificaciones imprecisas y/o incompletas de los usuarios.

Orientada a Objetos
No modela la realidad, sino la forma en que las personas comprenden y
procesan la realidad
Es un proceso ascendente basado en una abstracción de clases en aumento
Se basa en identificación de objetos, definición y organización de librerías de
clases, y creación de macros para aplicaciones específicas
Utiliza menor cantidad de código
Es más reutilizable

Etapas
Modelo de la cascada:

Hay veces en las que los requerimientos para cierto problema se comprende bien:
cuando el trabajo desde la comunicación hasta el despliegue fluye en forma
razonablemente lineal. Esta situación se encuentra en ocasiones cuando deben
hacerse adaptaciones o mejoras bien definidas a un sistema ya existente (por
ejemplo: una adaptación para software de contabilidad que es obligatorio hacer
debido a cambios en las regulaciones gubernamentales). También ocurre en cierto
número limitado de nuevos esfuerzos de desarrollo, pero sólo cuando los
requerimientos están bien definidos y tienen una estabilidad razonable.

El modelo de cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque

sistemático y secuencial para el desarrollo del software, que comienza con la
especificación de los requerimientos por parte del cliente y avanza a través de
planeación, modelado, construcción y despliegue, para concluir con el apoyo del
software terminado.

Una variante de la representación del modelo de la cascada se denomina modelo

en V. A medida que el equipo de software avanza hacia abajo desde el lado
izquierdo de la V, los requerimientos básicos del problema mejoran hacia
representaciones técnicas cada vez más detalladas del problema y de su solución.
Una vez que se ha generado el código, el equipo sube por el lado derecho de la V,
y en esencia ejecuta una serie de pruebas que validan cada uno de los modelos
creados cuando el equipo fue hacia abajo por el lado izquierdo. Este último
proporciona una forma de visualizar del modo de aplicación de las acciones de
verificación y validación al trabajo de ingeniería inicial.

El modelo de cascada es el paradigma más antiguo de la ingeniería de software.

Sin embargo, en las últimas décadas, las críticas hechas al modelo han
ocasionado que incluso sus defensores más obstinados cuestionen su eficacia.
Dentro los problemas que en ocasiones surgen al aplicar el modelo de cascada se
encuentran los siguientes:

Es raro que los proyectos reales sigan el flujo secuencial propuesto por el
modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma
indirecta. Como resultado, los cambios generan confusión conforme el
equipo del proyecto avanza.

A menudo, es difícil para el cliente enunciar en forma explícita todos los

requerimientos. El modelo de la cascada necesita que se haga, tiene
dificultades para aceptar la incertidumbre natural que existe al principio de
muchos proyectos.

El cliente debe tener paciencia. No se dispondrá de una versión funcional

del (de los) programa(s) hasta que un proyecto esté muy avanzado. Un
error grande sería desastroso si se detectara hasta revisar el programa en
funcionamiento.

Modelo lineal secuencial

El modelo lineal secuencial sugiere un enfoque sistemático secuencial, para el

desarrollo del software que comienza en un nivel de sistemas y progresa con el
análisis, diseño, codificación, pruebas y mantenimiento .

Modelado de sistemas de información: Esta visión del sistema es esencial

cuando el software se debe interconectar con otros elementos como hardware,
personas y bases de datos. La ingeniería de información abarca los requisitos que
se recogen en el nivel de empresa estratégico y en el nivel del área de negocio.
Generación de código: El diseño se debe traducir en una forma legible por la
máquina. Si se lleva a cabo el diseño de una forma detallada, la generación de
código se realiza mecánicamente.

Pruebas: Realizar las pruebas para la detección de errores y asegurar que la

entrada definida produce resultados reales de acuerdo con los resultados
requeridos.

Modelo de proceso incremental: El modelo incremental combina los elementos

de los flujos de proceso lineal y paralelo. El modelo incremental aplica secuencias
lineales en forma escalonada a medida que avanza el calendario de actividades.
Cada secuencia lineal produce "incrementos" de software suceptibles de
entregarse de manera parecida a los incrementos producidos en un flujo de
proceso evolutivo.

Cuando se utiliza el modelo incremental, es frecuente que el primer programa sea

el producto fundamental. Es decir, se abordan los requerimientos básico, pero no
se porporcionan muchas características suplementarias. El cliente usa el producto
fundamental (o lo somete a una evaluación detallada). Como resultado del uso y
evaluación, se desarrolla un plan para el incremento que sigue. el plan incluye la
modifcación del producto fundamental para cumplir mejor las necesidades del
cliente, así como la entrega de características adicionales y más funcionalidad.
Este proceso se repite después de entregar cada incremento, hasta terminar el
producto final.

El modelo de proceso incremental se centra en que en cada incremento se

entrega un producto que ya opera. Los primeros incrementos son versiones
desnudas del producto final, pero porporcionan capacidad que sirve al usuario y
también le dan una plataforma de evaluación, también tiene como objetivo un
crecimiento progresivo de la funcionalidad. Es decir, el producto va evolucionando
con cada una de las entregas previstas hasta que se amolda a lo requerido por el
cliente o destinatario.

Este enfoque, que se usó inicialmente para proyectos de software aunque más
tarde se aplicó a otros sectores, establece entregas parciales mediante un
calendario de plazos. En cada una de ellas, el producto debe mostrar una
evolución con respecto a la fecha anterior; nunca puede ser igual.
Una de las claves para que esto se haga efectivo es la evaluación de las etapas.
Los responsables del proyecto deben analizar si los resultados parciales son los
esperados y si, sobre todo, apuntan al objetivo principal. De no ser así, deberán
intervenir en él e implementar las soluciones que la situación requiera, La principal
diferencia del modelo incremental con los modelos tradicionales es que las tareas
están divididas en iteraciones, es decir, pequeños lapsos en los cuales se trabaja
para conseguir objetivos específicos. Con los modelos tradicionales no pasaba
esto; era necesario esperar hasta el final del proceso.

Modelo de proceso evolutivo

Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que

permiten desarrollar versiones cada vez más completas del software.

Modelo espiral

El modelo de desarrollo espiral es un generador de modelo de proceso impulsado

por el riesgo, que se usa para guiar la ingeniería concurrente con participantes
múltiples de sistemas intensivos en software. Tiene dos características que los
distinguen entre los demás:

Es el enfoque cíclico para crecimiento incremental del grado de definición de un

sistema y su implementación, mientras que disminuye su grado de riesgo.

Es un conjunto de puntos de referencia de anclaje puntual para asegurar el

compromiso del participante con soluciones factibles y mutuamente satisfactorias.

Un modelo espiral es dividido por el equipo de software en un conjunto de

actividades estructurales. Para fines ilustrativos, se utilizan las actividades
estructurales ya analizadas. Cada una de ellas representa un segmento de la
trayectoria espiral.

Al comenzar el proceso evolutivo, el equipo de software realiza actividades

implícitas en un circuito alrededor de la espiral en el sentido horario, partiendo del
centro. El riesgo se considera conforme se desarrolla cada revolución. En cada
paso evolutivo se marcan puntos de referencia puntuales: combinación de
productos del trabajo y condiciones que se encuentran a lo largo de la trayectoria
de la espiral.
El primer circuito alrededor de la espiral da como resultado el desarrollo de una
especificación del producto; las vueltas sucesivas se usan para desarrollar un
prototipo y, luego, versiones cada vez más sofisticadas del software. Cada paso a
paso por la región de planeación da como resultado ajustes en el plan del
proyecto. El costo y la programación de actividades se ajustan con base en la
retroalimentación obtenida del cliente después de la entrega. Además, el gerente
del proyecto ajusta el número planeado de iteraciones que se requieren para
terminar el software.

Modelos concurrentes

El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente,

permite que un equipo de software represente elementos iterativos y concurrentes.

La actividad modelado puede estar en cualquiera de los estados mencionados en

un momento dado. En forma similar, es posible representar de manera análoga
otras actividades, acciones o tareas (por ejemplo, comunicación o construcción).
Todas las actividades de ingeniería de software existen de manera concurrente,
pero se hallan en diferentes estados.

La actividad de comunicación termina su primera iteración al principio de un

proyecto y existe en el estado de cambios de espera. La actividad de modelado,
ahora hace una transición al estado en desarrollo, la actividad de modelado pasa
del estado en desarrollo al de cambios de espera.

Modelos de desarrollo basado en componentes

El modelo de desarrollo basado en componentes incorpora muchas de las

características del modelo espiral. Es de naturaleza evolutivo y demanda un
enfoque iterativo para la creación de software. Sin embargo, el modelo de
desarrollo basado en componentes construye aplicaciones a partir de fragmentos
de software prefabricados.

Sin importar la tecnología usada para crear los componentes, el modelo de

desarrollo basado en componentes incorpora las etapas siguientes:

Se investigan y evalúan, para el tipo de aplicación de que se trate, productos

disponibles basados en componentes.

Se consideran los aspectos de integración de los componentes.

Se diseña una arquitectura del software para que reciba los componentes.

Se integran los componentes en la arquitectura.

Se efectúan pruebas exhaustivas para asegurar la funcionalidad apropiada.

 El modelo del desarrollo basado en componentes lleva a la reutilización del

software, y eso da a los ingenieros de software varios beneficios en cuanto a la
mensurabilidad.

Justificación

Una metodología incremental presenta la ventaja de ser dinámica y flexible

permite usar las salidas de las etapas precedentes, como entradas en las etapas
sucesivas, y facilita corregir cualquier error detectado o llevar a cabo mejoras en
los distintos productos que se generan a lo largo de su aplicación, todas las
metodologías existentes, así como la que se presenta, se basan en la metodología
clásica o en cascada, y una vez que se conoce esa metodología clásica, es más
fácil aplicar cualquiera de las metodologías que de ella se derivan, Sin embargo, lo
que normalmente se hace es presentar las metodologías para que el analista
ponga en práctica la que más le sea conveniente, tomando elementos de cada
una de ellas, a lo largo de los últimos años, en Venezuela se enseñan, en los
recintos universitarios y centros de educación especializada, metodologías de
Desarrollo de Sistemas propuestas por diversos autores.

Análisis previo

 Es el proceso de estudiar su situación con la finalidad de observar cómo trabaja y

decir si es necesario realizar una mejora; el encargado de realizar estas tareas es
el analista de sistemas, se conoce un estudio de sistemas para detectar todos los
detalles de la situación actual en la empresa. La información reunida con este
estudio sirve como base para crear varias estrategias de diseño. Los
administradores deciden qué estrategia seguir. Los gerentes, empleados y otros
usuarios finales que se familiarizan cada vez más con
el empleo de computadoras están teniendo un papel muy importante en el
desarrollo de sistemas.
Todas las organizaciones son sistemas que actúan recíprocamente con su medio
ambiente recibiendo entradas y produciendo salidas. Los sistemas, que pueden
estar formados por otros sistemas más pequeños denominados subsistemas,
funcionan para alcanzar fines específicos. Sin embargo, los propósitos o metas se
alcanzan sólo cuando se mantienen el control.
Un sistema de información es un conjunto de elementos que interactúan entre sí
con el fin de apoyar las actividades de una empresa o negocio. El equipo
computacional: el hardware necesario para que el sistema de información pueda
operar

Análisis funcional:
El análisis funcional consiste en:
Relevar necesidades de información de los usuarios para establecer los
requerimientos del sistema.
Interpretar el proceso de negocio o actividad objeto del sistema para comprenderlo
y desarrollar modelos que representen la realidad de la organización y su
operatoria.
Definir el alcance funcional del proceso o sistema, tomando en cuenta las
prioridades establecidas y estimar su tamaño para establecer una línea de base
para el proyecto.
Analizar el problema objeto del proyecto para especificar los requisitos de
software.
Validar los requisitos especificados para asegurarse que representan las
necesidades de las partes interesadas.
Transferir los requisitos de software al resto del equipo para facilitar su
comprensión e implementación en artefactos de software.
Verificar la funcionalidad del software para asegurarse que satisface los requisitos
planteados.
Generar el soporte documental para el usuario.
Implantar el sistema o procedimiento en la organización.
Administrar los requerimientos y las solicitudes de cambio de los requisitos de
software.
Generar propuestas innovadoras y/o emprendimientos productivos propios del
ámbito del análisis funcional de sistemas informáticos.

Diseño del sistema

El objetivo del proceso de Diseño del Sistema de Información, es la definición de

la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto
con la especificación detallada de los componentes del sistema de información, a
partir de dicha información, se generan todas las especificaciones de construcción
relativas al propio sistema, así como la descripción técnica del plan de pruebas, la
definición de los requisitos de implantación y el diseño de los procedimientos de
migración y carga inicial, éstos últimos cuando proceda. Su construcción implica lo
siguiente, diseño de la Arquitectura del Sistema, entorno tecnológico, Seguridad,
Operación y administración, Diseño de la Arquitectura Modular e Interfaz de
Usuario, modelo físico de datos, resultado análisis de consistencia,
especificaciones de construcción , plan de migración y carga inicial especificación
del entorno, niveles y planificación de las pruebas, requisitos de Implantación .
También para realizar su diseño es importante:
Fase de integración y periodo de pruebas. El objetivo de esta etapa es corroborar
que el diseño propuesto cumple con los requisitos de negocio establecidos. Puede
ser necesario repetir las pruebas tantas veces como haga falta para evitar errores
y, de hecho, conviene que el usuario final dé su conformidad con el resultado. Por
último, este estadio concluye con la verificación y validación, que ayudan a
asegurar la compleción del programa con éxito.
Fase de implementación. En esta etapa del ciclo de vida de un sistema de
información hay que proceder a la instalación del hardware y software elegidos,
crear las aplicaciones correspondientes, someterlas a pruebas, crear la
documentación pertinente y capacitar a los usuarios. La conversión de datos es
importante en este estadio, en el que ya se empieza a trabajar en el nuevo
sistema.
Fase de mantenimiento. Esta etapa del ciclo de vida de un sistema de información
está relacionada con las operaciones del día a día. Por lo general, consiste en
introducir los ajustes necesarios para mejorar el rendimiento y corregir los
problemas que puedan surgir. Una vez concluye la etapa de implementación se
suele abrir un periodo de operación supervisada, durante el que las actividades de
mantenimiento cobran una especial importancia, al orientarse a hacer backups,
dar soporte a los usuarios, resolver fallos, optimizar el sistema para cuestiones
relacionadas con la seguridad o la velocidad y revisar el software para garantizar
la alineación con las metas del negocio

Programación y mantenimiento:
Mantenimiento:
Para cualquier organización industrial el mantenimiento es considerado un
factor estratégico en la búsqueda de incrementar los niveles de productividad,
calidad y seguridad en una empresa. El desempeño de un sistema de
información, el mantenimiento implica un constante y eficiente manejo de
información, lo cual permite a la gerencia integrar las acciones de la empresa
durante el desarrollo de los procedimientos y actividades correspondientes a su
entorno productivo, debe asegurar que se siguen satisfaciendo las necesidades
del usuario. Barrera de Mantenimiento Todos los recursos se destinan al
mantenimiento. No hay más recursos, Cuando se elaboran planes para
la estrategia de información, las organizaciones no pueden dejar de considerar
que el mantenimiento de sistemas es la fase más prolongada y costosa del ciclo
de vida de los sistemas. Las implicaciones del volumen de trabajo para
mantenimiento de los planes de estrategia de información en una organización es
un tema que merece atención especial. La estructura de organización necesita
flexibilidad para apoyar el mantenimiento de los sistemas existentes
concurrentemente con la ejecución de nuevas tecnologías. Es importante
considerar la evaluación y monitoreo de un sistema en términos del mantenimiento
necesario y, en consecuencia, reducir o contener los costos implícitos.

Programación:

Bibliografía

Kendall & Kendall; Análisis y Diseño de Sistemas; 3ª Edición; Pearson Educación