DISEÑO Y DESARROLLO DE SISTEMAS

[pic 1][pic 2]INSTITUTO POLITÉCNICO NACIONAL

UNIDAD INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS (UPIICSA)

CONTEXTO OCCIDENTAL DE LA INGENIERÍA INDUSTRIAL

TEMA: DISEÑO Y DESARROLLO DE SISTEMAS.

EQUIPO #4

INTEGRANTES:

• ROJAS RAMÍREZ ISRAEL ALEJANDRO
• ROSAS DOLORES FERNANDA GUADALUPE
• SANTILLÁN MAYO LUIS ÁNGEL
• TORRES RÍOS ÁLVARO NOEL
• ZAMUDIO HERNÁNDEZ ANA NATHALIA

SECUENCIA: 1IM11

PROFESOR: ING. VICTOR MANUEL RUEDA BALDERAS

FECHA: 20 DE DICIEMBRE DE 2020.

INDICE

INTRODUCCIÓN…………………………………………………………………1

CICLO DE VIDA DEL DESARRLLO DEL SISTEMA………………………… ?

CONCLUSIÓN…………………………………………………………………

CONCLUSIONES INDIVIDUALES………………………………………….

BIBLIOGRAFÍA……………………………………………………………….

INTRODUCCIÓN

Fase 4: Diseño del sistema Durante la cuarta fase, Diseño del sistema, el equipo de proyecto encara el “cómo” de la solución elegida. Por ejemplo, una aplicación de la base de datos debería ser capaz de aceptar información de los usuarios y almacenarla. Éstas son funciones generales, pero ¿Cómo las implementará el equipo? Por ejemplo, ¿Cuántas pantallas de entrada son necesarias y cómo se verán? ¿Qué tipo de opciones de menú debe haber? ¿Qué tipo de base de datos usará el sistema? Los analistas y programadores involucrados hasta este punto, usan con frecuencia una combinación de diseño descendente y ascendente para responder esas preguntas. En el Diseño Descendente, el equipo comienza con el panorama general y se va al detalle. Se ocupan de las funciones principales que el sistema debe proporcionar y las dividen en actividades más y más pequeñas. Cada una de estas actividades será programada en la siguiente fase CVDS. En el Diseño Ascendente, el quipo comienza con los detalles (Por ejemplo, los reportes que serán producidos por el sistema) y entonces se dirigen al panorama general (las funciones o procesos principales). Este enfoque es particularmente apropiado cuando los usuarios tienen requerimientos específicos para la salida –por ejemplo, cheques para pago de nómina, los cuales deben contener ciertas piezas de información-. A través de la fase 4, el administrador del equipo del proyecto revisa el progreso en el diseño de diferentes componentes del sistema. Al final de la fase se lleva a cabo una revisión más amplia, involucrado 14 normalmente al departamento que será afectado y a la administración superior. Si el diseño pasa la inspección, el desarrollo comienza. En algunos casos la revisión pone de relieve problemas con la solución general, y el equipo debe regresar a analizar o terminar el proyecto. Muchas herramientas están disponibles para ayudar a los equipos a través de los pasos del diseño de sistemas. La mayoría de estas herramientas también pueden usarse durante de la fase de desarrollo, o, incluso, durante el análisis. Por ejemplo, muchos equipos usan modelos de funcionamiento llamados Prototipos para explorar la vista y percepción de las pantallas en relación con los usuarios. También usan aplicaciones de software especiales para crear esos prototipos rápidamente, así como para crear diagramas, escribir código y administrar el esfuerzo de desarrollo. Estas aplicaciones entran en la categoría de herramientas de ingeniería de software asistidas por computadora (CASE). En otras palabras, el software de cómputo está usándose para desarrollar otro software de cómputo más confiable y rápidamente.

Fase 5: Desarrollo del Software Durante la fase de Desarrollo, los programadores juegan el papel clave, al crear o personalizar el software para todas las varias partes del sistema. Normalmente, los programadores del equipo son asignados a componentes específicos del sistema general. Si un componente está creándose, los programadores escriben el código necesario o usan herramientas CASE (Si es posible) para acelerar el proceso de desarrollo. Para los componentes comprados, los programadores deben personalizar el código según sea necesario para hacer que el componente encaje dentro del nuevo sistema. Hay dos rutas alternativas a través de la fase 5: La ruta de la adquisición o la ruta del desarrollo local. Tan temprano como la fase 1, investigación preliminar, el equipo del proyecto podría darse cuenta de que algunos o todos los componentes necesarios del sistema están disponibles como hardware o software a nivel comercial, y deciden adquirirlos en vez de dedicarse a desarrollarlos. Adquirirlos componentes comerciales significa que el sistema puede construirse más rápido y barato que si cada componente debe desarrollarse desde el principio. Otra ventaja de los componentes adquiridos es que ya se han puesto a prueba y se ha demostrado que son confiables, a pesar de que podrían necesitar ser personalizados para encajar dentro del sistema general de información. En muchos casos, el equipo del proyecto de sistema compra (o adquieren) algunos componentes y construyen (o desarrollan) otros. Por lo tanto, siguen las rutas tanto de adquisición como de desarrollo local a través del CVDS al mismo tiempo. Los redactores técnicos trabajan con los programadores para producir la documentación técnica para el sistema. La documentación técnica es sumamente distinta de la documentación para el usuario, en ella se describe a los usuarios finales cómo usar el sistema; en cambio, la documentación técnica incluye información acerca de las características técnicas del software y de la programación, acerca del flujo de información y del procesamiento a través del sistema, y acerca del diseño y disposición del hardware necesario. Estos materiales proporcionan una vista general del sistema y, por lo tanto, sirven como una referencia para los miembros del equipo enfocados en los componentes individuales. Además, la documentación técnica es vital para dar apoyo al personal y a los programadores a cargo del sistema durante la fase de mantenimiento. Otros redactores comienzan a trabajar con la documentación para el usuario, y los arquitectos de asistencia al usuario comienzan a plantear la arquitectura del sistema de ayuda en línea. Estos esfuerzos normalmente no son terminados hasta llegar a las primeras etapas de la fase de puesta en práctica. Poner a prueba es una parte integral de las fases 4 y 5 (Desarrollo y puesta en práctica). El enfoque típico de poner a prueba es ir del componente individual hasta el sistema como un todo. El equipo de desarrollo del proyecto prueba cada componente por separado (prueba de unidades) y entonces se ponen a prueba los 15 componentes del sistema con cada uno de los otros (Prueba del sistema). Los errores se corrigen, se hacen, los cambios necesarios y las pruebas se llevan a cabo de nuevo. En seguida viene la prueba de la instalación, esto es, cuando el sistema es instalado en un ambiente de prueba y probado con otras aplicaciones que use el negocio. Finalmente, se lleva a cabo una prueba de aceptación, donde los usuarios finales prueban el sistema instalado para asegurarse de que encaja con sus criterios. Con frecuencia, los equipos de desarrollo del proyecto ponen a prueba sistemas o componentes de sistemas con transacciones reales –algunas veces llamados “información viva”-. Esto ayuda a asegurase de que el sistema puede manejar el flujo de información esperado sobre una base diaria después que le sistema se pone en línea. Sin embargo, los programadores también debieran probar el sistema con datos inválidos o condiciones de excepción

...