Diseño de Sistemas.

es el proceso de definición de la arquitectura, módulos, interfaces y datos de un

sistema para satisfacer unos requisitos previamente especificados.
El diseño de sistemas podría verse como la aplicación de teoría de sistemas al desarrollo de un
nuevo producto

Proceso de Construcción de Sistema.

En la fase de construcción del sistema de información, se aplicarán las normas de codificación que
correspondan, se integrarán de forma continua los componentes desarrollados y se utilizarán
aquellas herramientas que proporcionen soporte a las tareas de esta fase

Concepto de Integración y prueba de Sistema.

Integración es el acto de unir, incorporar y/o entrelazar partes para que forme parte de un todo.

Hoy en día, se usa la palabra integración mayormente como un concepto social que abarca
diferentes campos como la integración social, regional, económica, religiosa, racial, organizacional,
etc.
Las pruebas del sistema tienen como objetivo ejercitar profundamente el sistema comprobando
la integración del sistema de información globalmente, verificando el funcionamiento correcto de
las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de
información con los que se comunica.
Son pruebas de integración del sistema de información completo, y permiten probar el sistema en
su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones
funcionales y técnicas se cumplen. Dan una visión muy similar a su comportamiento en el entorno
de producción.

Concepto de implementación y mantenimiento de Sistema.

La implementación constituye la realización de determinados procesos y estructuras en un

sistema. Representa así la capa más baja en el proceso de paso de una capa abstracta a una capa
más concreta

El mantenimiento de sistemas informáticos implica la ejecución de diferentes tareas y acciones

destinadas a mantener la funcionalidad de los equipos durante el mayor tiempo posible.
Estas tareas se aplican tanto a nivel de hardware (servidores físicos, periféricos…) como de
software e información, es decir, que incluyen los componentes físicos, los sistemas operativos y
los sistemas de datos e información.

Considerando que los sistemas informáticos hacen uso de ordenadores para almacenar
información en diferentes formatos, dichos datos deben estar a disposición de los usuarios
autorizados para acceder a ellos.

Así, a través del mantenimiento de sistemas informáticos logramos garantizar la seguridad de

acceso, la fiabilidad y el correcto funcionamiento de estos datos.
Diseño Lógico y Físico.

El diseño lógico del sistema consiste en desarrollar modelos lógicos que describan la esencia del
sistema, lo que tiene que hacer independientemente del modo en que se implante físicamente.

Al suprimir en el diseño lógico la tecnología, el analista de sistemas tiene mayor libertad de

movimiento a la hora de diseñar un modelo que cumpla con todos los requerimientos del nuevo
sistema.

El modelo lógico es la representación de la estructura y las relaciones de los datos esenciales del
negocio eso es para el modelo de datos.

El diseño lógico traduce los escenarios de uso creados en el diseño conceptual en un conjunto de
objetos de negocio y sus servicios. el diseño lógico se convierte en partes en la especificación
funcional que se usa en el diseño físico

El diseño físico forma parte del proceso general de diseño de una base de datos. En particular, se
realiza después del diseño lógico de la misma. En el diseño lógico se genera un conjunto de tablas
normalizadas a partir del esquema con- ceptual creado en la fase de diseño conceptual de la base
de datos.

¿ Cuáles son los pasos básicos en el diseño de sistema?

Fase de planificación. En esta fase se prepara el diseño y posterior implementación del sistema. Es
necesario definir el alcance del proyecto, justificarlo y escoger una metodología para su desarrollo.
También es preciso asociar las diferentes actividades a plazos de tiempo y designar roles y
responsabilidades.

Fase de análisis. Una vez que el equipo de proyecto se decide por una metodología de desarrollo
determinada, da comienzo la segunda etapa en el ciclo de vida de un sistema de información. Es la
que tiene que ver con el análisis y donde se busca concretar una serie de requisitos, que son los
que regirán el nuevo sistema o los cambios a introducir en el antiguo, si con el proyecto se busca
su actualización.

Fase de diseño. En este estadio el equipo de proyecto tendrá que determinar cómo el nuevo
sistema de información cumplirá con los requisitos aplicables. Es por ello que, a estas alturas del
ciclo de vida de un sistema de información conviene identificar soluciones potenciales, evaluarlas y
elegir la más conveniente.

Fase de desarrollo. El desarrollo software marca un antes y un después en la vida del sistema y
significa, además, el inicio de la producción. El cambio es una constante durante esta etapa, en la
que suele ser recomendable poner el foco en la formación y capacitación de los usuarios y el
equipo técnico.

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.
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.

pasos para el desarrollo y diseño de un sistema.

La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y

administrar un proyecto para llevarlo a cabo con grandes posibilidades de éxito. Esta
sistematización indica cómo se divide un proyecto en módulos más pequeños para normalizar
cómo se administra el mismo.

Planificación

Antes de empezar un proyecto de desarrollo de un sistema de información, es necesario hacer

ciertas tareas que influirán decisivamente en el éxito del mismo. Dichas tareas son conocidas
como el fuzzy front-end del proyecto, puesto que no están sujetas a plazos.

Algunas de las tareas de esta fase incluyen actividades como la determinación del ámbito del
proyecto, la realización de un estudio de viabilidad, el análisis de los riesgos asociados, la
estimación del coste del proyecto, su planificación temporal y la asignación de recursos a las
diferentes etapas del proyecto.

Análisis

Por supuesto, hay que averiguar qué es exactamente lo que tiene que hacer el software. Por eso,
la etapa de análisis en el ciclo de vida del software corresponde al proceso a través del cual se
intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de
los requerimientos del sistema (las características que el sistema debe poseer)

Diseño

En esta fase se estudian posibles opciones de implementación para el software que hay que
construir, así como decidir la estructura general del mismo. El diseño es una etapa compleja y su
proceso debe realizarse de manera iterativa.

Es posible que la solución inicial no sea la más adecuada, por lo que en tal caso hay que refinarla.
No obstante, hay catálogos de patrones de diseño muy útiles que recogen errores que otros han
cometido para no caer en la misma trampa.

Implementación

En esta fase hay que elegir las herramientas adecuadas, un entorno de desarrollo que facilite el
trabajo y un lenguaje de programación apropiado para el tipo de software a construir. Esta
elección dependerá tanto de las decisiones de diseño tomadas como del entorno en el que el
software deba funcionar.

Al programar, hay que intentar que el código no sea indescifrable siguiendo distintas pautas como
las siguientes:

Evitar bloques de control no estructurados.

Identificar correctamente las variables y su alcance.

Elegir algoritmos y estructuras de datos adecuadas para el problema.

Mantener la lógica de la aplicación lo más sencilla posible.

Documentar y comentar adecuadamente el código de los programas.

Facilitar la interpretación visual del código utilizando reglas de formato de código previamente
consensuadas en el equipo de desarrollo.

También hay que tener en cuenta la adquisición de recursos necesarios para que el software
funcione, además de desarrollar casos de prueba para comprobar el funcionamiento del mismo
según se vaya programando.

Pruebas

Como errar es humano, la fase de pruebas del ciclo de vida del software busca detectar los fallos
cometidos en las etapas anteriores para corregirlos. Por supuesto, lo ideal es hacerlo antes de que
el usuario final se los encuentre. Se dice que una prueba es un éxito si se detecta algún error.

Instalación o despliegue

La siguiente fase es poner el software en funcionamiento, por lo que hay que planificar el entorno
teniendo en cuenta las dependencias existentes entre los diferentes componentes del mismo.

Es posible que haya componentes que funcionen correctamente por separado, pero que al
combinarlos provoquen problemas. Por ello, hay que usar combinaciones conocidas que no
causen problemas de compatibilidad.

Uso y mantenimiento

Esta es una de las fases más importantes del ciclo de vida de desarrollo del software. Puesto que el
software ni se rompe ni se desgasta con el uso, su mantenimiento incluye tres puntos
diferenciados:

Eliminar los defectos detectados durante su vida útil (mantenimiento correctivo).

Adaptarlo a nuevas necesidades (mantenimiento adaptativo).

Añadirle nuevas funcionalidades (mantenimiento perfectivo).

Aunque suene contradictorio, cuanto mejor es el software más tiempo hay que invertir en su
mantenimiento. La principal razón es que se usará más (incluso de formas que no se habían
previsto) y, por ende, habrá más propuestas de mejoras.

la integración incremental y cuáles son sus ventajas

Dentro de las tantas opciones que la gestión de proyectos tiene para el desarrollo de software, el
modelo incremental es una de las mejores. Es útil cuando el equipo no tiene la suficiente
experiencia o cuando hay objetivos de riesgos altos. Por ello hay que saber cómo funciona el
modelo incremental.

Este modelo hace posible que no se repitan procesos en el desarrollo de software y el cliente
puede tener avances progresivos. Veamos cómo funciona y dónde se aplica el modelo
incremental.

El modelo incremental de gestión de proyectos 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.

1 ventajas más importante es que permite no repetir el proceso ya implementado

2 t permite tener una buena implementación a la hora de realizar un proyecto

3 ves de manera detallada como funciona el proyecto y como funcionara a la hora de muéstraselo

Cómo elaborar un plan de prueba para un software

Analizar los requerimientos de desarrollo de software

Para elaborar un plan de pruebas de software lo primero que debes hacer es entender los
requerimientos de usuario que componen la iteración o proyecto, que son el sujeto de la
verificación de calidad que se va a realizar.

Deberás analizar toda la información de la ingeniería de requisitos, incluyendo la matriz de

trazabilidad, especificaciones y diseño funcional, requisitos no funcionales, casos de uso, historias
de usuario (si estás trabajando con metodologías ágiles), entre otra documentación.

También es muy importante realizar entrevistas con el equipo encargado de la ingeniería de

requisitos para aclarar dudas y ampliar la información que sea necesaria.

Identificar las funcionalidades nuevas a probar

A partir de la documentación del análisis de requisitos y de las entrevistas con el equipo de

ingeniería de requisito y desarrollo, debes identificar e incluir en el plan de pruebas de software en
la lista de las funcionalidades.
Si estás trabajando con un sistema informático nuevo, no tendrás problemas en discernir, pues
todas serán nuevas.

En el caso de desarrollos de software integrados a un sistema existente es necesario revisar con

los analistas de negocio y también con los arquitectos de software las funcionalidades que forman
parte del desarrollo de software, en todas las capas de la arquitectura.

Identificar las funcionalidades de sistemas existentes que deben probarse

Se debe identificar las funcionalidades existentes que estén siendo impactadas por el desarrollo de
alguna forma, considerando todos los componentes afectados en todas las capas de la
arquitectura de software.

Existen dos situaciones que se puede encontrar al identificar estas funcionalidades:

Funcionalidades modificadas de cara al usuario: Por ejemplo, si una funcionalidad está siendo
modificada agregando más pantallas o cambios a su flujo de proceso, debe ser incluida en el plan
de pruebas de software.

Funcionalidades modificadas en sus componentes internos: Son funcionalidades no modificadas

de cara al usuario, manteniendo la misma interfaz gráfica y flujo de procesos, sin embargo, si se
modifican componentes internos que comparten con otras funcionalidades del sistema, en las
capas de lógica de negocio o acceso a datos. Estas deben incluirse en el plan de pruebas de
software para determinar a partir de ellas pruebas de regresión a realizar.

Quienes pueden suministrar la información serán los Analistas de negocio o Arquitectos de

software, familiarizados con el sistema informático implementado en entorno de producción.

Definir la estrategia de pruebas

Consiste básicamente en seleccionar cuáles son los tipos de pruebas de software que se deben
realizar.

Es recomendable seguir un marco de referencia para determinar los tipos de prueba, como por
ejemplo los tipos de pruebas de software definidos por el ISTQB.

Definir os criterios de inicio, aceptación y suspensión de pruebas

Criterios de aceptación o rechazo

Para definir los criterios de aceptación o rechazo, es necesario definir el nivel de tolerancia a fallos
de calidad. Si la tolerancia a fallos es muy baja puede definirse como criterio de aceptación que el
100% de los casos de prueba estén sin incidencias. Lograr este margen en todos los casos de
prueba principales y casos bordes será muy difícil, y podría comprometer los plazos del proyecto
(incrementa los riesgos), pero asegura la calidad del producto.

Por otra parte, puede ser que la intención sea realizar un Soft Launch, o un mínimo producto
viable, en ese caso se podría definir como criterio de aceptación el 100% de los casos de prueba
principales (considerados clave) y 20% de casos de prueba no principales (casos borde).

Una vez logradas las condiciones, se darán por aceptadas las pruebas y el desarrollo de software.
Criterios de inicio o reanudación:

Definen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas. Por ejemplo,
en el caso de inicio la condición podría ser la instalación de los componentes de software en el
ambiente y que los casos de pruebas de verificación de ambiente sean exitosos.
Para el caso de la reanudación las condiciones están relacionadas, se determina a partir de cuales
criterios de suspensión se presentaron para detener las pruebas. Una vez que estás condiciones ya
no existan (sean solventadas) se procede con la reanudación.

Criterios de suspensión

Las condiciones van a depender de los acuerdos de nivel de servicio (SLAs) internos de la
organización y también de los acuerdos establecidos en cada proyecto individual.

Por ejemplo, si se tiene un equipo de pruebas que comparte su esfuerzo entre varios proyectos, se
puede definir un criterio de suspensión exigente, un determinado porcentaje de casos fallidos que
resulten en incidencias. Si la condición se cumple, se detienen las pruebas y se dedica el personal a
otras actividades,

Por otra parte, si se tiene un equipo de pruebas con personal dedicado, el criterio de suspensión
puede ser poco exigente, por ejemplo solo ocurriendo si se bloquean por incidencia todos los
casos de prueba.