Diagrama Modelo en Cascada

Modelo en cascada

Para realizar un proyecto se debe hacer una planeación del mismo. Teniendo en cuenta costos, tiempos, recursos humanos, recurso físicos, Recursos técnicos. Para ello se debe tomar el tiempo necesario para su estudio y análisis.

Como hacer el análisis.


En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.
Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.


Una ves hecho el análisis del requerimiento del nuevo sistema y teniendo todo el conocimiento del mismo se hace el estudio de si el sistema es factible o no para ello es hace un estudio de factibilidad.

En estudio de factibilidad se debe tener en cuenta lo siguiente:

La investigación de factibilidad en un proyecto consiste en descubrir cuales son los objetivos de la organización, luego determinar si el proyecto es útil para que la empresa logre sus objetivos.La búsqueda de estos objetivos debe contemplar los recursos disponibles o aquellos que la empresa puede proporcionar, nunca deben definirse con recursos que la empresa no es capaz de dar.En las empresas se cuenta con una serie de objetivos que determinan la posibilidad de factibilidad de un proyecto sin ser limitativos.Estos objetivos son los siguientes:Reducción de errores y mayor precisión en los procesos.Reducción de costos mediante la optimización o eliminación de recursos no necesarios.Integración de todas la áreas y subsistemas de la empresa.Actualización y mejoramiento de los servicios a clientes o usuarios.Aceleración en la recopilación de datos.Reducción en el tiempo de procesamiento y ejecución de tareas.Automatización optima de procedimientos manuales.Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados, la factibilidad se apoya en 3 aspectos básicos:Operativo.Técnico.Económico.
El éxito de un proyecto esta determinado por el grado de factibilidad que se presente en cada una de los tres aspectos anteriores.Estudio de Factibilidad.Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisión, si procede su estudio, desarrollo o implementación.Objetivo de un Estudio de Factibilidad.1.- Auxiliar a una organización a lograr sus objetivos.2.- Cubrir la metas con los recursos actuales en las siguientes areas.a). Factibilidad Técnica.- Mejora del sistema actual.- Disponibilidad de tecnología que satisfaga las necesidades.b).- Factibilidad Económica.- Tiempo del analista.- Costo de estudio.- Costo del tiempo del personal.- Costo del tiempo.- Costo del desarrollo / adquisición.c).- Factibilidad Operativa.- Operación garantizada.- Uso garantizado.




ANALISIS DE REQUERIMIENTOS.

El análisis de requerimientos consiste brevemente en los siguientes pasos:
Obtener información acerca de lo que los usuarios desean
Clasificar esos deseos para comenzar a estructurar requerimientos
Identificar los niveles de jerarquía del sistema y empezar a alojar los ya clasificados requerimientos en cada nivel.
Especificar formalmente los requerimientos de acuerdo al nivel de audiencia que se desea.

Diseño Global Y Detallado (Carlos)

DISENO GLOBAL O ARQUITECTONICO Y DISENO DETALLADO. Introducción Algunos autores dividen la fase del diseño en dos partes: Diseño global o arquitectónico y diseño detallado. En el primero se transforman los requisitos en una arquitectura de alto nivel, se definen las pruebas que debe satisfacer el sistema en su conjunto, se esboza la documentación y se planifica la integración. En el detallado para cada módulo se refina el diseño, se definen los requisitos del módulo y su documentación. Las formas de organizar y estructurar la secuencia de ejecución de las tareas en las diferentes fases de cada uno de los métodos pueden dar lugar a un tipo de ciclo de vida diferente. El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice. Una vez que se analizan y se especifican los requisitos del software, el diseño del software es la primera de las tres actividades técnicas – diseño, generación de código y pruebas – que se requieren para construir y verificar el software. Cada actividad transforma la información de manera que dé lugar por último a un software de computadora válido. El diseño de software es una parte fundamental en la ingeniería de software, primero que nada se analizan y especifican los requerimientos del software, después se procede con las tres actividades técnicas que se requieren para verificar y construir el software, que son: diseño, generación de código y pruebas. Mediante uno de los muchos métodos de diseño, la tarea produce un diseño de datos, un diseño arquitectónico, un diseño de interfaz y un diseño de componentes. El diseño de datos transforma el modelo del dominio de información que se crea durante el análisis en las estructuras de datos que se necesitaran para la implementación del software. Los objetos de datos y las relaciones definidas en el diagrama relación entidad es el contenido de datos detallado que se representa en el diccionario que se datos proporcionan la base de la actividad del diseño de datos. Principios del diseño. • Evaluación de alternativas. • Podrá rastrearse hasta el análisis. • No reinventar la rueda. • Minimizar la distancia entre el software y el problema. • Uniformidad e integración. • Posibilidad de admitir cambios. • Degradación paulatina. • El diseño no es escribir código y escribir código no es diseñar. • El diseño se evalúa durante la creación y no al final. • El diseño debe revisarse para minimizar errores. El diseño arquitectónico define la relación entre los elementos estructurales principales del software, los patrones de diseño que se puedan utilizar para lograr los requisitos que se han definido para el sistema, y las restricciones que afectan a la manera en que se pueden aplicar los patrones de diseño arquitectónico. La representación de diseño del diseño arquitectónico- el marco de trabajo de un sistema basado en computadora - puede derivarse de la especificación del sistema, del modelo de análisis y de la interacción del subsistema definido dentro del modelo de análisis El objetivo primario del diseño arquitectónico es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos, combina la estructura del programa y de las estructuras de datos, a través del programa. La arquitectura de software de un sistema de programa o computación es la estructura de las estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos componentes visibles externamente, y las relaciones entre ellos. La arquitectura del software nos proporciona una visión global del sistema a construir. Describe la estructura y la organización de los componentes del software, sus propiedades y la relaciones entre ellos, los componentes del software incluyen módulos de programas y varias representaciones que son manipulados por el programa. Además, el diseño de datos es una parte integral para la derivación de la arquitectura del software. La arquitectura marca las decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas. Este parte de diseño es una parte fundamental en el desarrollo de software ya que en ella estableceremos como es que el sistema va a estar organizado El ingeniero de sistemas puede crear un modelo que represente las interrelaciones entre los distintos elementos del sistema y establezca una base para los posteriores pasos de análisis de requisitos y de diseño. Para desarrollar el modelo del sistema se utiliza una plantilla de arquitectura. El ingeniero de sistemas asigna elementos del sistema a cada una de las cinco regiones de procesamiento dentro de la plantilla: (1) interfaz de usuario, (2) entrada, (3) función y control del sistema, (4) salida y (5) mantenimiento y autocomprobación. Utilizar el modelo de plantilla es una técnica que permite crear una jerarquía, en el nivel superior de la jerarquía está el diagrama de contexto de la jerarquía. El diseño de datos crea un modelo de datos e información que se representa con un alto nivel de abstracción (la visión de datos del cliente/usuario). Principios para la especificación de datos. 1. Principios sistemáticos. 2. Identificar las estructuras de datos y las operaciones a realizar sobre ellas. 3. Uso del diccionario de datos. 4. Las decisiones de diseño de datos de bajo nivel deberían dejarse parael final del proceso de diseño. 5. La representación de las estructuras de datos deberían conocerla sólo aquellos módulos que deban hacer uso directo de los datos contenidos dentrode la estructura. 6. Debería desarrollarse una biblioteca de estructuras de datos útiles y de las operaciones que se les pueden aplicar. Modelos arquitectónicos • Modelo de depósitos. • Modelo cliente-servidor. • Modelo de máquina abstracta. Modelos de control. Control centralizado. Modelo de llamada-retorno. Modularidad La arquitectura del software involucra a la modularidad, es decir, dividir el software en componentes identificables y tratables por separado, llamados módulos. La modularidad es importante porque un software monolítico, es decir, compuesto de un solo modulo no puede ser entendido fácilmente por el usuario. La modularidad se basa en al lema de “divide y vencerás”: es más fácil resolver un problema complejo cuando se divide en partes manejables, esto nos haría pensar que si dividiéramos el software indefinidamente, el esfuerzo requerido para desarrollarlo sería mínimo, lo cual no es cierto, en la siguiente figura tomada del libro “Ingeniería del Software. Un enfoque práctico” de Robert Pressman Se ejemplifica gráficamente la relación entre y el numero de módulos y el esfuerzo y costo de hacerlos Como se muestra, el esfuerzo para desarrollar un modulo de software disminuye a medida que crece el número total de módulos. Resulta obvio que mientras mas dividido esté el software, cada parte resultante de ésta división será más pequeña, sin embargo, el esfuerzo derivado de la integración de módulos también crece. Son varios los aspectos que se deben de considerar a la hora de aplicar la modularidad en nuestro sistema, por eso debemos de tomar en cuenta 5 criterios. Los cuales son: Capacidad de descomposición modular. Lo importante aquí es tener un método sistemático que nos permita la descomposición del problema en subproblemas para así obtener una solución modular eficaz. Capacidad de empleo de componentes modulares. Lo que nos interesa es que podamos ensamblar los componentes de diseño existentes (reutilizables) en un sistema nuevo, no se trata de volver a inventar la rueda sino de utilizar lo que ya teníamos y que nos pueda volver a servir. Capacidad de comprensión modular. Es importante que un modulo se pueda entender como una unidad por si sola, que no haya que hacer referencia a otros módulos, así nos será más fácil su utilización. Continuidad modular. Si al hacer cambios en los requisitos del sistema, éstos deben provocar cambios en los módulos y no en todo el sistema, de ésta manera se minimiza el impacto de efectos colaterales que puedan producir dichos cambios. Protección modular. Si un módulo produce un error, éste error debe restringirse única y exclusivamente a dicho módulo, sin afectar a los demás, de ésta manera se minimiza el impacto de los errores. Estructura del programa Representa la organización de componentes del programa (módulos) e implica una jerarquía de control. La relación entre los componentes del sistema se clasifica según la relación de control que haya entre ellos, si un modulo controla a otro módulo se dice que es superior él; de manera inversa, si un modulo es controlado por otro se dice que es subordinado de aquel que ejerce control sobre éste. La estructura de control también representa dos características que son visibilidad y conectividad, la primera indica los módulos que pueden ser utilizados o los datos que contiene por un componente dado, aun cuando sea de manera indirecta. La conectividad indica el de componentes que son invocados o son usados sus datos por un componente dado. La estructura del programa define la jerarquía de control sin tener en cuenta la secuencia de procesamiento y las decisiones. El procedimiento del software se centra en los detalles de procesamiento de cada modulo individualmente. Por ésta razón es importante tomar en cuenta el procedimiento del software que debe proporcionar una especificación exacta del procesamiento. Ocultamiento de la información Éste concepto indica que los módulos deben de especificarse y diseñarse para que la información contenida dentro de éste sea inaccesible por otros módulos que no necesiten ésta información. El ocultamiento de la información es conveniente cuando se requieren modificaciones durante las pruebas o después, durante el mantenimiento del software, dado que los datos y procedimientos están ocultos en otras partes del software, los errores introducidos durante las modificaciones son más difíciles de propagar a otros lugares del software. El procedimiento se distribuye en capas como lo podemos observar en ésta figura tomada del libro Ingeniería del Software, un enfoque práctico Conceptos fundamentales del diseño modular. Independencia Funcional La independencia funcional se logra desarrollando módulos con una función única y evitando la excesiva interacción con otros módulos. Los módulos independientes son más fáciles de mantener porque los efectos secundarios causados por la modificación están limitados y se pueden utilizar módulos reutilizados. La independencia se mide a su vez en dos criterios distintos; la cohesión y el acoplamiento. Cohesión Un módulo con cohesión tiene una sola función dentro del software, de ésta manera se requiere poca interacción con otros módulos. La cohesión es algo buscado, siempre es deseado tener una cohesión alta, aunque una cohesión media resulta buena, pero una cohesión baja siempre debe ser evitada. Un módulo que realiza un conjunto de tareas relacionadas las unas con las otras, si es que tienen algo que ver, se denomina coincidentalmente cohesivo. Un módulo que realiza tareas relacionadas lógicamente es de cohesión lógica. Cuando un módulo contiene tareas relacionadas por el hecho de que todas den hacerse en el mismo intervalo de tiempo, éste módulo presenta cohesión temporal Acoplamiento El acoplamiento es una medida de la interconexión entre los módulos, éste depende de la complejidad de la interfaz entre los módulos. En el diseño del software se desea tener el acoplamiento mas bajo, ya que de ésta manera el software es más fácil de entender y menos dado al llamado “efecto ola” que ocurre cuando los errores se propagan a través del sistema. Los tipos de acoplamiento son: Normal: Por datos, por estampado, por control Común (o global) Por contenidoPROGRAMACION DE LIBRERIAS Y HERRAMIENTAS Herramientas Para programar tanto en C, como en C++, Java o cualquier otro lenguaje de programación, necesitamos contar con aplicaciones o herramientas que nos permitan poner en funcionamiento nuestro programa. El lenguaje de programación C es compilado, así que en este caso necesitaremos un compilador, que será el encargado de transformar nuestro código fuente en código que la computadora pueda ejecutar. Además, para facilitar la tarea de los programadores existen los denominados Entorno de desarrollo integrado (IDE). En muchos casos, estos entornos incluyen un compilador, un depurador, y otras herramientas. Las herramientas a instalar dependerán del sistema operativo utilizado. A continuación se listan algunas posibilidades para el sistema operativo Windows o GNU/Linux, no es imprescindible utilizar estas herramientas en particular, cualquier compilador puede servir.

DISENO GLOBAL O ARQUITECTONICO Y DISENO DETALLADO. Introducción Algunos autores dividen la fase del diseño en dos partes: Diseño global o arquitectónico y diseño detallado. En el primero se transforman los requisitos en una arquitectura de alto nivel, se definen las pruebas que debe satisfacer el sistema en su conjunto, se esboza la documentación y se planifica la integración. En el detallado para cada módulo se refina el diseño, se definen los requisitos del módulo y su documentación. Las formas de organizar y estructurar la secuencia de ejecución de las tareas en las diferentes fases de cada uno de los métodos pueden dar lugar a un tipo de ciclo de vida diferente. El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice. Una vez que se analizan y se especifican los requisitos del software, el diseño del software es la primera de las tres actividades técnicas – diseño, generación de código y pruebas – que se requieren para construir y verificar el software. Cada actividad transforma la información de manera que dé lugar por último a un software de computadora válido. El diseño de software es una parte fundamental en la ingeniería de software, primero que nada se analizan y especifican los requerimientos del software, después se procede con las tres actividades técnicas que se requieren para verificar y construir el software, que son: diseño, generación de código y pruebas. Mediante uno de los muchos métodos de diseño, la tarea produce un diseño de datos, un diseño arquitectónico, un diseño de interfaz y un diseño de componentes. El diseño de datos transforma el modelo del dominio de información que se crea durante el análisis en las estructuras de datos que se necesitaran para la implementación del software. Los objetos de datos y las relaciones definidas en el diagrama relación entidad es el contenido de datos detallado que se representa en el diccionario que se datos proporcionan la base de la actividad del diseño de datos. Principios del diseño. • Evaluación de alternativas. • Podrá rastrearse hasta el análisis. • No reinventar la rueda. • Minimizar la distancia entre el software y el problema. • Uniformidad e integración. • Posibilidad de admitir cambios. • Degradación paulatina. • El diseño no es escribir código y escribir código no es diseñar. • El diseño se evalúa durante la creación y no al final. • El diseño debe revisarse para minimizar errores. El diseño arquitectónico define la relación entre los elementos estructurales principales del software, los patrones de diseño que se puedan utilizar para lograr los requisitos que se han definido para el sistema, y las restricciones que afectan a la manera en que se pueden aplicar los patrones de diseño arquitectónico. La representación de diseño del diseño arquitectónico- el marco de trabajo de un sistema basado en computadora - puede derivarse de la especificación del sistema, del modelo de análisis y de la interacción del subsistema definido dentro del modelo de análisis El objetivo primario del diseño arquitectónico es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos, combina la estructura del programa y de las estructuras de datos, a través del programa. La arquitectura de software de un sistema de programa o computación es la estructura de las estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos componentes visibles externamente, y las relaciones entre ellos. La arquitectura del software nos proporciona una visión global del sistema a construir. Describe la estructura y la organización de los componentes del software, sus propiedades y la relaciones entre ellos, los componentes del software incluyen módulos de programas y varias representaciones que son manipulados por el programa. Además, el diseño de datos es una parte integral para la derivación de la arquitectura del software. La arquitectura marca las decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas. Este parte de diseño es una parte fundamental en el desarrollo de software ya que en ella estableceremos como es que el sistema va a estar organizado El ingeniero de sistemas puede crear un modelo que represente las interrelaciones entre los distintos elementos del sistema y establezca una base para los posteriores pasos de análisis de requisitos y de diseño. Para desarrollar el modelo del sistema se utiliza una plantilla de arquitectura. El ingeniero de sistemas asigna elementos del sistema a cada una de las cinco regiones de procesamiento dentro de la plantilla: (1) interfaz de usuario, (2) entrada, (3) función y control del sistema, (4) salida y (5) mantenimiento y autocomprobación. Utilizar el modelo de plantilla es una técnica que permite crear una jerarquía, en el nivel superior de la jerarquía está el diagrama de contexto de la jerarquía. El diseño de datos crea un modelo de datos e información que se representa con un alto nivel de abstracción (la visión de datos del cliente/usuario). Principios para la especificación de datos. 1. Principios sistemáticos. 2. Identificar las estructuras de datos y las operaciones a realizar sobre ellas. 3. Uso del diccionario de datos. 4. Las decisiones de diseño de datos de bajo nivel deberían dejarse parael final del proceso de diseño. 5. La representación de las estructuras de datos deberían conocerla sólo aquellos módulos que deban hacer uso directo de los datos contenidos dentrode la estructura. 6. Debería desarrollarse una biblioteca de estructuras de datos útiles y de las operaciones que se les pueden aplicar. Modelos arquitectónicos • Modelo de depósitos. • Modelo cliente-servidor. • Modelo de máquina abstracta.
Modelos de control. Control centralizado. Modelo de llamada-retorno. Modularidad La arquitectura del software involucra a la modularidad, es decir, dividir el software en componentes identificables y tratables por separado, llamados módulos. La modularidad es importante porque un software monolítico, es decir, compuesto de un solo modulo no puede ser entendido fácilmente por el usuario. La modularidad se basa en al lema de “divide y vencerás”: es más fácil resolver un problema complejo cuando se divide en partes manejables, esto nos haría pensar que si dividiéramos el software indefinidamente, el esfuerzo requerido para desarrollarlo sería mínimo, lo cual no es cierto, en la siguiente figura tomada del libro “Ingeniería del Software. Un enfoque práctico” de Robert Pressman Se ejemplifica gráficamente la relación entre y el numero de módulos y el esfuerzo y costo de hacerlos Como se muestra, el esfuerzo para desarrollar un modulo de software disminuye a medida que crece el número total de módulos. Resulta obvio que mientras mas dividido esté el software, cada parte resultante de ésta división será más pequeña, sin embargo, el esfuerzo derivado de la integración de módulos también crece. Son varios los aspectos que se deben de considerar a la hora de aplicar la modularidad en nuestro sistema, por eso debemos de tomar en cuenta 5 criterios. Los cuales son: Capacidad de descomposición modular. Lo importante aquí es tener un método sistemático que nos permita la descomposición del problema en subproblemas para así obtener una solución modular eficaz. Capacidad de empleo de componentes modulares. Lo que nos interesa es que podamos ensamblar los componentes de diseño existentes (reutilizables) en un sistema nuevo, no se trata de volver a inventar la rueda sino de utilizar lo que ya teníamos y que nos pueda volver a servir. Capacidad de comprensión modular. Es importante que un modulo se pueda entender como una unidad por si sola, que no haya que hacer referencia a otros módulos, así nos será más fácil su utilización. Continuidad modular. Si al hacer cambios en los requisitos del sistema, éstos deben provocar cambios en los módulos y no en todo el sistema, de ésta manera se minimiza el impacto de efectos colaterales que puedan producir dichos cambios. Protección modular. Si un módulo produce un error, éste error debe restringirse única y exclusivamente a dicho módulo, sin afectar a los demás, de ésta manera se minimiza el impacto de los errores. Estructura del programa Representa la organización de componentes del programa (módulos) e implica una jerarquía de control. La relación entre los componentes del sistema se clasifica según la relación de control que haya entre ellos, si un modulo controla a otro módulo se dice que es superior él; de manera inversa, si un modulo es controlado por otro se dice que es subordinado de aquel que ejerce control sobre éste. La estructura de control también representa dos características que son visibilidad y conectividad, la primera indica los módulos que pueden ser utilizados o los datos que contiene por un componente dado, aun cuando sea de manera indirecta. La conectividad indica el de componentes que son invocados o son usados sus datos por un componente dado. La estructura del programa define la jerarquía de control sin tener en cuenta la secuencia de procesamiento y las decisiones. El procedimiento del software se centra en los detalles de procesamiento de cada modulo individualmente. Por ésta razón es importante tomar en cuenta el procedimiento del software que debe proporcionar una especificación exacta del procesamiento. Ocultamiento de la información Éste concepto indica que los módulos deben de especificarse y diseñarse para que la información contenida dentro de éste sea inaccesible por otros módulos que no necesiten ésta información. El ocultamiento de la información es conveniente cuando se requieren modificaciones durante las pruebas o después, durante el mantenimiento del software, dado que los datos y procedimientos están ocultos en otras partes del software, los errores introducidos durante las modificaciones son más difíciles de propagar a otros lugares del software. El procedimiento se distribuye en capas como lo podemos observar en ésta figura tomada del libro Ingeniería del Software, un enfoque práctico Conceptos fundamentales del diseño modular. Independencia Funcional La independencia funcional se logra desarrollando módulos con una función única y evitando la excesiva interacción con otros módulos. Los módulos independientes son más fáciles de mantener porque los efectos secundarios causados por la modificación están limitados y se pueden utilizar módulos reutilizados. La independencia se mide a su vez en dos criterios distintos; la cohesión y el acoplamiento. Cohesión Un módulo con cohesión tiene una sola función dentro del software, de ésta manera se requiere poca interacción con otros módulos. La cohesión es algo buscado, siempre es deseado tener una cohesión alta, aunque una cohesión media resulta buena, pero una cohesión baja siempre debe ser evitada. Un módulo que realiza un conjunto de tareas relacionadas las unas con las otras, si es que tienen algo que ver, se denomina coincidentalmente cohesivo. Un módulo que realiza tareas relacionadas lógicamente es de cohesión lógica. Cuando un módulo contiene tareas relacionadas por el hecho de que todas den hacerse en el mismo intervalo de tiempo, éste módulo presenta cohesión temporal Acoplamiento El acoplamiento es una medida de la interconexión entre los módulos, éste depende de la complejidad de la interfaz entre los módulos. En el diseño del software se desea tener el acoplamiento mas bajo, ya que de ésta manera el software es más fácil de entender y menos dado al llamado “efecto ola” que ocurre cuando los errores se propagan a través del sistema. Los tipos de acoplamiento son: Normal: Por datos, por estampado, por control Común (o global) Por contenido
PROGRAMACION DE LIBRERIAS Y HERRAMIENTAS Herramientas Para programar tanto en C, como en C++, Java o cualquier otro lenguaje de programación, necesitamos contar con aplicaciones o herramientas que nos permitan poner en funcionamiento nuestro programa. El lenguaje de programación C es compilado, así que en este caso necesitaremos un compilador, que será el encargado de transformar nuestro código fuente en código que la computadora pueda ejecutar. Además, para facilitar la tarea de los programadores existen los denominados Entorno de desarrollo integrado (IDE). En muchos casos, estos entornos incluyen un compilador, un depurador, y otras herramientas. Las herramientas a instalar dependerán del sistema operativo utilizado. A continuación se listan algunas posibilidades para el sistema operativo Windows o GNU/Linux, no es imprescindible utilizar estas herramientas en particular, cualquier compilador puede servir.

PROGRAMACION Y APLICACION

PROGRAMACION Y APLICACION
La programación es la transformación de un análisis en un lenguaje que es capaz de entender el ordenador. Una vez se obtiene un análisis completo de una solución, se procede con la fase de programación que consistirá en ir construyendo y elaborando un programa informático con una interfaz sencilla para el usuario pero que esconde arduos y laboriosos procesos. Podríamos comparar la fase de programación con la de construcción del edificio basándose en sus planos.
Esta es la fase de ejecución en la elaboración de un software a medida, por ello determinará en gran medida muchas características de nuestro programa a medida. Una programación metódica y minuciosa brindará de robustez, mantenibilidad y eficiencia a nuestra solución.


PRUEBAS DE INTEGRACION

Las pruebas de integración en los proyectos de desarrollo de software, no solo se presentan en la integración entre módulos de un mismo producto sino que se están planteando proyectos que ofrecen soluciones conformadas por varios productos de software, lo cual le da una nueva dimensión al proceso de pruebas de integración. Estas corresponden a las pruebas de integración entre productos, en el cual podríamos considerar los productos como componentes más grandes, sin embargo existen características que las hacen particulares considerando que son productos construidos por empresas diferentes y que obedecen a estándares de construcción diferentes, en las más diversas plataformas (Figura 1). Para el proceso de pruebas de integración se han establecido los siguientes aspectos:


1. Identificar las aplicaciones que forman parte de la solución y su participación en el proceso, es decir la función de la aplicación dentro de la solución. Cada una de las aplicaciones debe estar certificada funcionalmente, es decir haber concluido los procesos de pruebas funcionales. Es requisito que las aplicaciones hayan finalizado su proceso de pruebas funcionales o al menos hayan logrado un alto nivel de estabilidad ya que si esto no se cumple, durante la ejecución de las pruebas de integración es más difícil establecer la procedencia de las no conformidades identificadas lo que ocasiona desperdicio de tiempo del equipo de trabajo intentando localizar su procedencia.

2. Identificar la forma de acceso e invocación de cada una de las aplicaciones o componentes de la solución, para esto se definen estándares que describen la manera de acceder a las aplicaciones y la ubicación dentro de la pantalla de los puntos de acceso.

3. Validar los estándares de presentación de la solución. Cada una de las aplicaciones debe cumplir con estos estándares, los cuales son definidos por el cliente y normalmente corresponden a la imagen que quiere proyectar. Estos estándares son variables de acuerdo con el cliente, si bien son aspectos que se validan en las pruebas de unidad, como se plantean para un proyecto de integración que varía de cliente en cliente y para un producto terminado estas pruebas se ejecutan como parte de las pruebas de integración.

4. Identificar la interacción entre las aplicaciones, es decir cuales aplicaciones requieren interacción y que mecanismo usará para hacerla. Está interacción se define desde dos puntos de vista:

- Sincronización de Datos
- Integración Funcional


Para llevar a cabo adecuadamente estos procesos se requiere:

- Especificar si en la integración se construirá un repositorio central de datos.
- Especificar los mecanismos de comunicación entre las aplicaciones.


En lo posible no se debe realizar interacción directa entre cada par de aplicaciones ya que dependiendo del número de productos que participen, aumenta la complejidad del mantenimiento de la solución. Es recomendable el uso de uno o más mediadores que permita estandarizar el mecanismo de integración.

5. Identificar el mecanismo de autenticación en las aplicaciones. Debe ser un mecanismo unificado para la solución. A pesar de que son varias aplicaciones, la autenticación de usuarios debe realizarse una vez.

6. La administración de usuarios debe realizarse desde una de las aplicaciones y debe ser replicado en forma automática en las demás aplicaciones.

7. Para facilitar el proceso de integración se usa un repositorio central de datos que comparte información entre diferentes aplicaciones. El repositorio central de datos debe validarse de acuerdo con la estructura de las fuentes que lo alimentan.

8. Se debe disponer de una herramienta que permita realizar consultas y reportes sobre el repositorio central.

9. En caso que existan aplicaciones con buscador, este se debe centralizar, es decir definir un buscador sobre el cual se registran los demás buscadores existentes de la aplicación.

10. Validación del cumplimiento de los requerimientos del ambiente de pruebas Integrado. Las versiones del software base de las aplicaciones puede ser muy variado. El ambiente de pruebas debe corresponder al definido por el arquitecto de la solución y se debe verificar que no existan conflictos entre los productos y versiones requeridos para el funcionamiento de cada uno de los productos que integra la solución.

11. Establecer si la solución incluye un instalador único o múltiples instaladores, dependiendo de la complejidad de la solución y del número de aplicaciones que componen la solución, así como la diversidad de software base.