FILIAL CUSCO

CURSO: PROYECTOS DE SISTEMAS DE INFORMACION II

TEMA:
BASES PARA EL DESARROLLO DE SOFTWARE Y DESARROLLO RAPIDO

GRUPO DE TRABAJO: JEAN CARLOS MAYHUA QUISPE

CUSCO PER 2013

BASES PARA EL DESARROLLO DE SOFTWARE Y DESARROLLO RAPIDO DEFINICIN DE RAD Proceso de desarrollo de software que permite construir sistemas utilizables en poco tiempo, normalmente de 60 a 90 das, frecuentemente con algunas concesiones. PRINCIPIOS TRAS LA DEFINICIN En ciertas situaciones, una solucin utilizable al 80% puede producirse en el 20% de tiempo que se hubiera requerido para la solucin completa. En ciertas situaciones, los requisitos de negocio de un sistema pueden satisfacerse aun cuando algunos de sus requisitos operacionales no se satisfagan. En ciertas situaciones, la aceptabilidad de un sistema puede determinarse en base a un conjunto mnimo de requisitos consensados en lugar de la totalidad de los requisitos.

PROBLEMAS ATENDIDOS POR RAD Con los mtodos convencionales pasa un gran lapso de tiempo antes de que el cliente vea resultados.. Con los mtodos convencionales el desarrollo llega a tardar tanto que para cuando el sistema est listo para utilizarse los procesos del cliente han cambiado radicalmente. Con los mtodos convencionales no hay nada hasta que el 100% del proceso de desarrollo se ha realizado, entonces se entrega el 100% del software.

POR QU USAR RAD? Malas razones Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en manejo de costos). Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en manejo de tiempo).

Buenas razones Convergir tempranamente en un diseo aceptable para el cliente y posible para los desarrolladores. Limitar la exposicin del proyecto a las fuerzas de cambio. Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidad del producto.

CALENDARIO VS PRESUPUESTO VS CALIDAD Las concesiones determinan el ritmo de desarrollo. Negociar algo que no sea el calendario de trabajo. Una o ms metas pueden ser inalcanzables.

Caractersticas de RAD Equipos Hbridos

Proyectos De Sistemas de Informacin II

Pgina 1

Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema as como aquellas personas involucradas con los requisitos. Los desarrolladores de RAD deben ser "renacentistas": analistas, diseadores y programadores en uno.

Herramientas Especializadas Timeboxing Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario. Prototipos Iterativos y Evolucionarios Reunin JAD (Joint Application Development): Se renen los usuarios finales y los desarrolladores. Lluvia de ideas para obtener un borrador inicial de los requisitos. Desarrollo "visual" Creacin de prototipos falsos (simulacin pura) Creacin de prototipos funcionales Mltiples lenguajes Calendario grupal Herramientas colaborativas y de trabajo en equipo Componentes reusables Interfaces estndares (API) Control de versiones

Iterar hasta acabar: Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales. Los diseadores revisan el prototipo. Los clientes prueban el prototipo, depuran los requisitos. Los clientes y desarrolladores se renen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios. Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.

Notas: Cada iteracin dura entre un da y tres semanas. Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.

El Facilitador Mantiene al grupo enfocado: Tiene claras las metas sobre la informacin que se necesita recabar. Prepara una agenda de asuntos antes de la reunin. Asegura que la discusin adecuada cubra cada asunto. Asegura que todos participen.

Proyectos De Sistemas de Informacin II

Pgina 2

Escribe un reporte al final de la reunin.

Restricciones Importantes El "ajuste a un propsito de negocios" tiene que ser el criterio de aceptacin de los entregables. Todas las reas que pueden afectar los requisitos debe estar involucradas a lo largo del proceso. Clientes, desarrolladores y gerencia deben aceptar entregables informales: Prototipos en papel en lugar de sistemas a gran escala. Notas de las reuniones con usuarios en lugar de documentos de requisitos formales. Notas de las reuniones de los diseadores en lugar de documentos de diseo formales. Principio: crear el mnimo de documentacin necesaria para facilitar el desarrollo futuro y el mantenimiento. El equipo de desarrollo tiene que poder tomar decisiones tradicionalmente dejadas a la gerencia. La escala de tiempo de punta a punta tiene que ser de seis meses o menos. La iteracin debe usarse de manera que se converja a una solucin de negocio aceptable. Los prototipos tienen que incorporar rpidamente los requisitos en evolucin, en tiempo real, y lograr consenso pronto. Debe haber una tendencia a "comprar antes que construir".

RAD tiende a funcionar cuando: La aplicacin funcionar de manera independiente. Se pueden usar mayormente bibliotecas existentes. Desempeo no crtico. Distribucin limitada, interna o vertical. Alcance del proyecto limitado. Confiabilidad no crtica. El sistema puede dividirse en muchos mdulos independientes. El producto est dirigido a un mercado altamente especializado. El proyecto cuenta con fuertes limitantes de tiempos parciales (timeboxes). La tecnologa requerida tiene ms de un ao en el mercado.

RAD tiende a fallar cuando: La aplicacin debe interoperar con sistemas existentes. Existen pocos componentes reutilizables. Alto desempeo crtico. El desarrollo no puede aprovechar herramientas de alto nivel. Distribucin amplia, horizontal o masiva. RAD se convierta en QADAD (Quick And Dirty Application Development). Mtodos RAD para desarrollar sistemas operativos (confiabilidad demasiado alta) o juegos (desempeo demasiado alto). Riesgos tcnicos de tecnologa de punta. El producto pone en riesgo la misin o la vida. El producto no puede ser modularizado.

Proyectos De Sistemas de Informacin II

Pgina 3

Ventajas de RAD Comprar puede ahorrar dinero en comparacin con construir. Los entregables pueden ser fcilmente trasladados a otra plataforma. El desarrollo se realiza a un nivel de abstraccin mayor. Visibilidad temprana. Mayor flexibilidad. Menor codificacin manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Posiblemente menor costo. Ciclos de desarrollo ms pequeos. Interfaz grfica estndar.

Desventajas de RAD Comprar puede ser ms caro que construir. Costo de herramientas integradas y equipo necesario. Progreso ms difcil de medir. Menos eficiente. Menor precisin cientfica. Riesgo de revertirse a las prcticas sin control de antao. Ms fallas (por sndrome de "codificar a lo bestia"). Prototipos pueden no escalar, un problema maysculo. Funciones reducidas (por "timeboxing"). Dependencia en componentes de terceros: funcionalidad de ms o de menos, problemas legales. Requisitos que no convergen. Interfaz grfica estndar. Difcil de repetir experiencias exitosas. Funciones no deseadas.

BASES DEL DESARROLLO DE SOFTWARE El software es un elemento importante en la mayora de los proyectos informticos, si bien est la opcin de comprar uno ya hecho, tambin se puede usar uno a la medida. Por lo tanto es vital que nosotros como informticos conozcamos los aspectos que debemos tener en cuenta a la hora de desarrollar un software, y as identificar las bases para llevar a cabo este proceso. Segn la real academia espaola cuando hablamos de una base, en trminos generales es el Fundamento o apoyo principal de algo. Por lo tanto cuando hablamos de desarrollo de software, Cules son estas bases? Trataremos de dar una respuesta clara y entendible en el siguiente blog. Los proyectos de desarrollo de software se diferencian de los otros proyectos de ingeniera tradicional en la naturaleza lgica del producto software. Recordemos que el software se desarrolla, no se fabrica en un sentido clsico. En todos los proyectos de ingeniera la buena calidad se adquiere mediante un buen diseo, pero en el caso del software, la etapa de construccin incide pobremente en su calidad, no as en la

Proyectos De Sistemas de Informacin II

Pgina 4

construccin de hardware o de una obra civil. Otra diferencia es que el software no se estropea, el paso del tiempo o males del entorno no inciden en el aumento de la tasa de fallas. As, no se puede gestionar un proyecto de desarrollo de software como si se tratara de un proyecto de fabricacin. La gestin del proyecto de software es el primer nivel del proceso de ingeniera de software, porque cubre todo el proceso de desarrollo. Para conseguir un proyecto de software fructfero se debe comprender el mbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir.

Para lograr determinar claramente las bases, trataremos de analizar los pasos de una forma consecuente, que nos permita un mayor entendimiento del objeto de esta investigacin, iniciando con la determinacin de los requerimientos de unos sistemas, alcanzados mediante la interaccin con el usuario hasta la documentacin final e implementacin del mismo.

ANLISIS Y DETERMINACIN DE LOS REQUERIMIENTOS Es una de las etapas ms importantes a la hora de desarrollar software, pues en esta se definen las utilidades del software y se pretende identificar las necesidades del usuario, para de esta forma satisfacerlas. La tarea de obtener los requerimientos puede parecer bastante sencilla, sin embargo, la tarea de interactuar con el usuario, comprenderlo puede resultar bastante complejo, no entender exactamente lo que quiere un usuario puede llevarnos a fracasar en el proyecto. En esta etapa se realizan observaciones, entrevistas, y evaluaciones del sistema anterior. Para poder crear un software o un nuevo sistema, tenemos que conocer a cabalidad el sistema que se usa actualmente, tomando en cuenta todos los problemas que se dan y cules son las dificultades de este; para posteriormente presentar una idea que solucione todos los contratiempos que se dan actualmente. Por lo tanto, solamente vamos a poder desarrollar un producto de calidad, si conocemos el sistema con el que se viene trabajando hasta el momento. Reconocer los problemas y darles solucin. La IEEE separa el anlisis de los requerimientos en dos:

FUNCIONALES Son los requerimientos que van ligados a las funcionalidades del software, le dan la utilidad.

NO FUNCIONALES Son todos los requerimientos que no son cruciales para el funcionamiento del software, o pueden variar, generalmente son detalles como de interfaz. No significa que los requerimientos no funcionales no sea importantes, porque un programa con una mala interfaz no es bien aceptada por el cliente. Pero estos requerimientos no forman parte de las funciones del software. Por ejemplo, en un sistema contable, un requerimiento funcional sera registrar los asientos diarios, mientras que un requerimiento no funcional puede ser tener una barra de men para ver las opciones de forma ordenada.

Proyectos De Sistemas de Informacin II

Pgina 5

La labor de identificar los requerimientos debe estar muy ligada al usuario, y es un proceso en el cual se van refinando poco a poco, hasta poder tener una visin clara de las necesidades del cliente, as como lo que debemos hacer para desarrollar el software. Es importante que lo requerimientos y especificaciones tcnicas sean aprobadas por el usuario, de modo que estemos seguros de ir por buen camino. En esta etapa de anlisis se debe hacer todo lo posible por encontrar discrepancias con el usuario, como pantallazos sin funcionalidad y hasta manuales de usuario, para que este vea desde su perspectiva como funcionar el software, esto evitar que en una etapa avanzada del desarrollo nos demos cuenta de que eso no era lo que quera el usuario. PROCESO DE DIAGRAMACIN

Una vez, que hemos logrado obtener las necesidades reales del cliente o usuario, mediante la interaccin con el mismo o revisando la documentacin propia del negocio, procedemos a plasmarlo mediante diferentes diagramas que nos ayuden a comprender no solo la lgica del negocio sino como lo podemos convertir en un software.

DIAGRAMAS DE GESTIN DEL NEGOCIO Los diagramas de Gestin del Negocio son los que nos permiten abstraer el problema al cual deseemos desarrollar un software, al punto de una descomposicin total, con el objetivo comprender a cabalidad un sistema y as evitar posibles errores de interpretacin. Diagramas de Flujos de Datos Es una tcnica grfica mediante la cual describimos el flujo de la informacin y la transformacin de los datos. Los DFD son ideales para lograr una compresin esquematizada del funcionamiento del negocio, sin la necesidad de plantearlo como un sistema. Gracias a estos diagramas, logramos tener una mayor claridad de la lgica del negocio objeto del diseo de software, lo que a la larga nos puede significar evitarnos malas interpretaciones de la gestin del negocio y asi brindar un producto de software ideal y ajustado a las necesidades del cliente. En el ejemplo de abajo, podemos observar el DFD del proceso de una solicitud de compra hasta la aprobacin para poder iniciar el procedimiento en una seccin de proveedura:

Proyectos De Sistemas de Informacin II

Pgina 6

Diagrama de Mandala Son representaciones grficas en matrices de tres por tres, cuyo objetivo es abstraer diseos de sistemas y mostrarlos con una secuencia de importancia y orden. La idea de Mandala es organizar los procesos por importancia, por lo que en el cuadro central, colocaremos el proceso madre o que represente a todos los dems procesos que se ingresen en la matriz, de igual manera los procesos se puede descomponer en nuevas matrices. Para tener una mayor comprensin. Al igual que los DFD logramos tener una mayor claridad de la lgica del negocio objeto del diseo de software y asi optimizar nuestro diseo, gracias a la abstraccin que le dimos al problema. A continuacin podemos observar un ejemplo de cmo se estructuro el sistema de compras con los diagramas de Mandala.

Proyectos De Sistemas de Informacin II

Pgina 7

Casos de Uso Es una tcnica para plasmar requisitos potenciales de un sistema o una actualizacin de software. Dichos casos de usos surgen ante situaciones posibles y/o escenarios que indican cmo debera interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especfico. Los casos de usos se evita el empleo de jergas tcnicas, prefiriendo en su lugar un lenguaje ms cercano al usuario final. Se da con normalidad que se utilice a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. Importante es sealar que los casos de uso no deben representar relaciones entre dos usuarios sino la interaccin directa con el usuario. El ejemplo de abajo representa de manera muy sencilla para representar un posible caso de uso:

Proyectos De Sistemas de Informacin II

Pgina 8

Diagramas de Actividad Un diagrama de actividad es la representacin interna (mayor detalle) de un caso de uso, en el cual se trata de representar a detalle toda la actividad que comprende dicho caso de uso. Se debe usar diagrama de actividad en situaciones donde todos o la mayora de los eventos representan la finalizacin de acciones generadas internamente (esto es, flujo de control procedural). Este tipo de diagrama no es adecuado en situaciones donde ocurren eventos asincrnicos. El ejemplo de abajo podemos observar un ejemplo sencillo de un diagrama de actividad:

MODELOS DE BASES DE DATOS Los modelos de Bases de Datos son mtodos que describen en un lenguaje formal la forma en que se estructura la base de datos. En estos se aplican los modelos de bases de aplican los modelos de datos. Los modelos de bases de datos pueden ser representaciones fsicas o lgicas. Dos de los modelos ms usados son el modelo entidad relacin y el relacional. Modelo entidad Relacin Es una representacin lgica de la base de datos, nos muestra la forma en que se relacionan las diferentes entidades entre s, el diagrama entidad- relacin (E-R) nos sirve como un mapa para ver la forma en que estar estructurada nuestra base de datos.

Proyectos De Sistemas de Informacin II

Pgina 9

Modelo Relacional La construccin de este modelo puede tomar como referencia el modelo E-R, a diferencia del anterior donde solamente se muestra el desarrollo lgico de los datos el modelo relacional contiene los datos, y es el que se ingresa directamente en el Sistema Gestor de Base de Datos.

DIAGRAMAS DE DISEO Y/O CODIFICACIN Cuando hemos superado el proceso del modelado de la base de datos y los diagramas de gestin del negocio, asumimos que nuestra abstraccin y entendimiento del sistema actual esta lo ms claro posible, es ah cuando podemos pasar al nivel del diseo de la aplicacin, por lo que antes de empezar la codificacin se realizan diversos diagramas, con el fin de que el cdigo que se vaya a digitar, tenga un estructura lgica, coherente y fcil de comprender, lo que directamente facilitara el mantenimiento del sistema en un caso futuro. Diagramas de Clases Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Se implementan durante el proceso de desarrollo del software, con lo que se consigue de alguna forma, lograr una estructura comprensible del cdigo de programacin.

Proyectos De Sistemas de Informacin II

Pgina 10

Diagramas de Flujos Ayudan a representar algoritmos mediante diagramas, con lo que se logra descomponer una estructura del programa esquematizndola y obteniendo una mayor representacin de la solucin. Una caracterstica importante de los diagrama de Flujo, es que si est completo y correcto, el paso del mismo a un Lenguaje de Programacin es relativamente simple y directo.

ESTNDARES Y NORMAS DE PROGRAMACIN Antes de iniciar la codificacin del sistema, es necesario establecer estndares y normas para la programacin, ya que por lo general los sistemas nos los codifica una sola persona, obviamente dependiendo del tamao del software. Es por esta razn que se estable las estructuras bsicas de cmo se debe programar, por ejemplo:

Nombre de la entidad/tabla

Proyectos De Sistemas de Informacin II

Pgina 11

El NOMBRE_DE_ENTIDAD/TABLA tendr como mximo 30 caracteres, estar escrito en mayscula, no se utilizarn tildes, ni (si fuera necesario se debe reemplazar por una n o ni). Si el NOMBRE_DE_ENTIDAD/TABLA est compuesto por ms de una palabra se utilizar el carcter raya baja _ como separador de palabras.

Formato del nombre de la entidad/tabla El NOMBRE_DE_ENTIDAD/TABLA debe respetar el siguiente formato PREFIJO_NOMBRE: PREFIJO: Es el cdigo de aplicacin, segn el Catlogo de Aplicaciones, a la cual pertenece la entidad/tabla.

Nombre del atributo El NOMBRE_DEL_ATRIBUTO tendr como mximo 30 caracteres, no se utilizarn tildes, ni (si fuera necesario se debe reemplazar por n o ni). Si el NOMBRE_DEL_ATRIBUTO est compuesto por ms de una palabra se utilizar el carcter raya baja _ como separador de palabras.

CODIFICACIN Y/O DISEO DEL SISTEMA SISTEMA GESTOR DE BASE DE DATOS Los Sistemas Gestores de Base de Datos o SGBD, son aplicaciones muy especficas dedicadas al manejo y creacin de las bases de datos. Los diferentes SGBD nos ayudan en temas como seguridad, integridad y consultan. Algunos breves ejemplos de Gestores de Bases de Datos son: MySQL Es un SGBD desarrollado con software libre, pero si se quiere usar en productos privados se debe adquirir una licencias especial. Es compatible con muchos lenguajes de programacin. Es ideal para aplicaciones web, por ser muy gil en las consultas. Es multiplataforma y se dice que tiene conectividad muy segura. Oracle Es uno de las SGBD ms completos que existen, y hasta hace poco tiempo dominaba el mercado empresarial. Es escalable, multiplataforma, estable y soporta transacciones. Pero es uno de los SGBD ms caros del mercado. Microsoft Access Es una pequea aplicacin creada por Microsoft para entorno personal o de pequeas empresas. Es sencillo de usar, y puede ser consultada por otros programas. Permite crear relaciones de tablas, formularios, consultas e informes.

PLATAFORMAS DE PROGRAMACIN JAVA Es un lenguaje de programacin orientado a objetos, actualmente la mayora de su librera es software libre, cuenta con tres ediciones, la J2SE para uso estndar de pequeas aplicaciones, J2ME para aplicaciones mviles, y la J2EE versin para uso empresarial a gran escala. Se dice que es un lenguaje simple, multiplataforma, multihilos y seguro.

Proyectos De Sistemas de Informacin II

Pgina 12

C++: Es un lenguaje de programacin bastante conocido y empleado, existen muchos tutoriales en lnea para apoyarse a la hora de implementarlo. Pero es un lenguaje muy complejo y no es recomendando en ambiente web. Microsoft .NET: Solamente funciona en el sistema operativo de Microsoft Windows, y es de ambiente propietario, se pretende crear un lenguaje de programacin que sea rpido y fcil, pero tiene dependencia de la plataforma en la que trabaja.

ASPECTOS FINALES DEL SOFTWARE DOCUMENTACIN Es este campo, debemos documentar todo al propio desarrollo del software y de la gestin del proyecto, todas las modelaciones y/o diagramas que se hayan hecho, pruebas, manuales de usuario, manuales tcnicos, entre otros, todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

MANUALES DE USUARIO Es una parte clave del sistema, ya que si deseamos desligarnos del usuario, podemos hacerlo con manuales entendibles y que integren en un documento toda la funcionalidad de un sistema. Por su importancia, los manuales no son opcionales en un proyecto de software.

CAPACITACIN Este proceso, es uno de los ms importantes en la hora de la implementacin del sistema, ya que se le indicara a los usuarios del sistema la funcionalidad del sistema y como le deben sacar provecho al misma.

DESARROLLO DEL SOFTWARE. Parte de las bases del desarrollo de software, es realizar una gestin organizada e integra de los procesos que se vayan a ejecutar en el proyecto, ya que una administracin correcta de los recursos, tanto econmicos, equipo, personal y todos los dems, nos pueden llevar a una ejecucin eficiente y eficaz del software. Para comprender como funciona la gestin de proyectos en el diseo de software y el cual tambin es una base muy importante del mismo, se presenta un diagrama en el cual podemos apreciar cmo se ven inmersos directamente los procesos de la gestin de proyectos en el diseo del software. En el diagrama de abajo, podemos observar esquematizadamente todo lo que hemos descrito en el trabajo, solo que ahora se le incluyen los aspectos de la gestin de proyecto, en donde podemos apreciar la planeacin, direccin, control, desarrollo e implementacin del los procesos, todos, funciones de un administrador de proyectos, en los que se le hace mucho nfasis en la planeacin y control, ya que nos permitir darle un seguimiento con la oportunidad de corregir posibles errores antes de se hagan ms grandes y requieran ms trabajo.

Proyectos De Sistemas de Informacin II

Pgina 13

CONCLUSIN A nivel acadmico muchas veces dejamos de lado muchos aspectos importantes del desarrollo del software, y simplemente nos dedicamos a digitar cdigo. Los cierto es que a nivel profesional debemos tener en cuenta muchos aspectos para crear un sistema de calidad y que cumpla con las expectativas del usuario o cliente. Etapas tan bsicas como una correcta obtencin de requerimientos es fundamental, y es parte crucial en el desarrollo de cualquier sistema de informacin que desee implementar. Una vez cubierta esta etapa, la realizacin de diagramas nos brindan un panorama completo de la situacin y un plano claro de cmo comenzar a construir.

Proyectos De Sistemas de Informacin II

Pgina 14

Todo lo que inicia bien termina bien, si cumplimos fielmente todos los pasos necesarios para el desarrollo del software entonces tendremos un producto de calidad que se amolde a las necesidades y exigencias del mercado. Teniendo existo en nuestros proyectos de desarrollo.

Tabla de contenido BASES PARA EL DESARROLLO DE SOFTWARE Y DESARROLLO RAPIDO ............................ 0 DEFINICIN DE RAD ............................................................................................................................... 1 PRINCIPIOS TRAS LA DEFINICIN ................................................................................................. 1 PROBLEMAS ATENDIDOS POR RAD ............................................................................................. 1 POR QU USAR RAD? ..................................................................................................................... 1 Malas razones ................................................................................................................................... 1 Buenas razones ................................................................................................................................ 1 CALENDARIO VS PRESUPUESTO VS CALIDAD ......................................................................... 1 Caractersticas de RAD ........................................................................................................................ 1 Equipos Hbridos .................................................................................................................................. 1 Herramientas Especializadas ............................................................................................................... 2 Timeboxing .......................................................................................................................................... 2 Prototipos Iterativos y Evolucionarios ................................................................................................ 2 Reunin JAD (Joint Application Development): ........................................................................... 2 Iterar hasta acabar: ........................................................................................................................... 2 Notas:.................................................................................................................................................. 2 El Facilitador .......................................................................................................................................... 2 Restricciones Importantes.................................................................................................................... 3 RAD tiende a funcionar cuando: ......................................................................................................... 3 RAD tiende a fallar cuando: ................................................................................................................. 3 Ventajas de RAD ................................................................................................................................... 4 Desventajas de RAD............................................................................................................................. 4 BASES DEL DESARROLLO DE SOFTWARE ..................................................................................... 4 ANLISIS Y DETERMINACIN DE LOS REQUERIMIENTOS .................................................... 5 FUNCIONALES ................................................................................................................................. 5 NO FUNCIONALES .......................................................................................................................... 5 PROCESO DE DIAGRAMACIN ....................................................................................................... 6 DIAGRAMAS DE GESTIN DEL NEGOCIO ............................................................................... 6 MODELOS DE BASES DE DATOS ............................................................................................... 9 DIAGRAMAS DE DISEO Y/O CODIFICACIN ...................................................................... 10 ESTNDARES Y NORMAS DE PROGRAMACIN ..................................................................... 11 Nombre de la entidad/tabla ........................................................................................................... 11

Proyectos De Sistemas de Informacin II

Pgina 15

Formato del nombre de la entidad/tabla ...................................................................................... 12 Nombre del atributo ........................................................................................................................ 12 CODIFICACIN Y/O DISEO DEL SISTEMA ............................................................................... 12 SISTEMA GESTOR DE BASE DE DATOS ................................................................................ 12 PLATAFORMAS DE PROGRAMACIN ..................................................................................... 12 ASPECTOS FINALES DEL SOFTWARE ........................................................................................ 13 DOCUMENTACIN........................................................................................................................ 13 MANUALES DE USUARIO ........................................................................................................... 13 CAPACITACIN ............................................................................................................................. 13 DESARROLLO DEL SOFTWARE. ................................................................................................... 13 CONCLUSIN ..................................................................................................................................... 14

Proyectos De Sistemas de Informacin II

Pgina 16