Programaci贸n
Temario de Programación I. Programación Orientada a Objetos A. Origen B. Conceptos fundamentales 1. Clase 2. Herencia 3. Objeto 4. Método 5. Evento 6. Atributos 7. Propiedad o atributo 8. Mensaje 9. Componentes de un objeto 10. Identificación de un objeto C. Características de la POO 1. Abstracción 2. Encapsulamiento 3. Modularidad 4. Principio de ocultación 5. Polimorfismo 6. Herencia 7. Recolección de basura II. Arquitectura de Software A. Diagramas de Clases B. Diagramas de base de datos C. Diagramas de despliegue D. Diagramas de secuencia E. Ciclo de vida del software III. Fases del Desarrollo de Software A. Identificar mercado objetivo para una aplicación B. Determinar o fijar objetivos
1. Productos a obtener 2. Restricciones 3. Identificar riegos 4. Planificación del proyecto a. Cronograma de trabajo b. Costos de producción C. Diseño 1. Análisis de requisitos 2. Diseño del Sistema 3. Diseño del Programa 4. Elección del Lenguaje D. Programación 1. Flujogramas 2. Codificación E. Prueba 1. Corrección de errores de programación F. Verificación 1. Puesta de Produccion dinal G. Mantenimiento
I.
Programación Orientada a Objetos A. Origen
La programación orientada a objetos (POO) es una forma especial de programar, más cercana a como expresaríamos las cosas en la vida real. Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros programas en términos de objetos, propiedades, métodos y otras cosas. Durante años los programadores se han dedicado a crear aplicaciones muy parecidas que resolvían una y otra vez los mismos problemas. Para conseguir que los esfuerzos de los programadores sea utilizado por otras personas se creó la POO. Que es una serie de normas de realizar las cosas de manera que otras personas puedan utilizarlos y adelantar su trabajo.
B. Conceptos fundamentales 1. Origen: Los conceptos de programación orientada a objetos tienen origen en simula 67, en un lenguaje diseñado para hacer simulaciones. Los creadores de este programa fueron Ole-JobanDabl y Kristen Nygaard del centro de cómputo noruego en Oslo. 2. Clase: Es una construcción que permite crear tipos personalizados propios mediante la agrupación de variables de otros tipos, métodos y eventos. Una clase es como un plano define los datos y el comportamiento de un tipo. Si la clase no se declara como estática, el código de cliente puede utilizarla mediante la creación de objetos o instancias que se asignan a una variable. 3. Herencia: Es una propiedad que permite que los objetos sean creados a partir de otros ya existentes, obteniendo características (métodos y atributos) similares a los ya existentes. Es la relación entre una clase general y otra clase más específica. Es un mecanismo que nos permite crear clases derivadas a partir de
clase base, nos permite compartir automáticamente métodos y datos entre subclases y objetos. 4. Objeto: Las clases por sí mismas, no son más que modelos que nos servirán para crear objetos en concreto. Podemos decir que una clase es el razonamiento abstracto de un objeto. A la acción de crear objetos se le denomina instanciar una clase y dicha instancia consiste en asignar la clase como valor a una variable. 5. Evento: Los eventos son todas las acciones que el usuario inicia, dar clic sobre un botón, presionar las teclas del teclado, etc. Cada vez que se produce un evento, se crea un objeto. Cada lenguaje de programación tiene su propio modelo de eventos, en java se definen clases auxiliares llamadas escuchadores (listeners) que reciben eventos específicos. 6. Atributos: Los atributos son las características individuales que diferencian un objeto de otro y determinan su apariencia, estado u otras cualidades. Los atributos se guardan en variables denominadas de instancia, y cada objeto particular puede tener valores distintos para estas variables. 7. Propiedad o Atributo: Una propiedad es un atributo de un objeto que define una de las características del objeto, como tamaño, color, o ubicación en pantalla, o un aspecto de su comportamiento. 8. Mensaje: Un mensaje es simplemente una petición para que un objeto se comporte de una determinada manera, ejecutando una de sus funciones miembro. La técnica de enviar mensajes se conoce como paso de mensajes. Estructuralmente un objeto consta de tres partes: La identidad del objeto receptor La función miembro del receptor cuya ejecución se ha solicitado cualquier otra información adicional que el receptor pueda necesitar para ejecutar el método requerido. 9. Componentes de un objeto: Relaciones: Las relaciones permiten que el objeto se inserte en la organización y están formadas esencialmente por punteros a otros objetos. Propiedades: las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tienen valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización. Métodos: Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas
(código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia. 10. Identificación de un objeto: En ocasiones puede ser necesario identificar el tiempo de ejecución el tipo de objeto con el que estamos trabajando. Debido a las capacidades de polimorfismo de java, cuando tenemos una referencia a un objeto puede que solo sepamos que dicho objeto es una instancia de una clase o de cualquiera de sus derivadas. Y en ocasiones puede ser necesario saber de que clase específica es dicho objeto.
C. Características de la POO 1.Abstracción: Cada objeto en el sistema sirve como modelo de un “agente” abstracto que puede realizar trabajo, informar y cambiar su estado, y “comunicarse” con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. 2. Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente. 3. Modularidad: Concepto aplicado en el contexto de la informática, especialmente en la programación. Un módulo es un componente de un sistema más grande y opera dentro del sistema independientemente de las operaciones de otros componentes. La modularidad es una opción importante para la escalabilidad y comprensión de programas, además de ahorrar trabajo y tiempo en el desarrollo.
5. Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que específica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el
grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos. 6. Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en “tiempo de ejecución”, esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en “tiempo de compilación”) de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++. 7. Recolección de basura: En computación, la recolección de basura es una forma de administración automática de memoria, donde un recolector de basura intenta recuperar la memoria usada por objetos que nunca será accedidos o cambiados nuevamente por una aplicación. Es empleado principalmente en algunos lenguajes de programación. La recolección de basura es a menudo descrita como opuesta a la gestión manual de la memoria, en donde se requiere que el programador especifique qué objetos deben ser eliminados de la memoria y así devolverle la memoria al sistema. De todas maneras, muchos sistemas emplean una combinación de ambos
lll. Arquitectura de software A. Diagramas de clases Son diagramas de estructura estática que muestran las clases del sistema y sus interrelaciones, son utilizados tanto para mostrar lo que el sistema puede hacer “análisis”, como para mostrar cómo puede ser construido “diseño”. El diagrama de clases de más alto nivel, será lógicamente un dibujo de los paquetes que componen el sistema. Los diagramas de clase se usan en el diseño del modelo estático para ver un sistema. Para las demás partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones, o modelado de esquemas. Los diagramas de clase son también la base para un par de diagramas relacionados: diagramas de componente y diagramas de instalación.
La construcción de software tiene muchas características similares, excepto, que la calidad (fluidez) de software, uno tiene la habilidad de definir la construcción de bloques básicos para ir detallando (scratch). Elementos de los diagramas de clases Clases Es la unidad básica que encapsula toda la información de un objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una casa, un auto, una cuenta corriente, etc.). En uml (lenguaje unificado de modelado), una clase es representada por rectángulo que posee tres divisiones: En donde: Superior: contiene el nombre de la clase. Intermedio: contiene los atributos (o variables de instancia) que caracterizan a la clase (puede ser private, protected o public.) Inferior: contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public). Atributos: son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Tipos de atributos: Public indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. Private indica que el atributo sólo será accesible desde dentro de la clase.0. Protected indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven. Operaciones / métodos: son aquellas actividades o verbos que se pueden realizar con o para este objeto, como: cerrar, abrir, buscar, cancelar, confirmar, cargar. El nombre de una operación se escribe minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra,
cada palabra será unida a la anterior y comenzará en minúscula. Por ejemplo: cerrarpuerta, abrirpuerta, buscarpuerta, etc. En ¨, las clases están representadas por rectángulos, con el nombre de la clase y también pueden mostrar atributos y operaciones de la clase en otros dos – comportamientos- dentro del rectángulo. Plantillas: Un valor usado para una clase no especificada o un tipo. El tipo de la plantilla se especifica cuando se inicia una clase (es decir cuando se crea un objeto). Las plantillas existen en c++ y se introducirán en java 1.5 con el nombre de genéricos. Asociaciones de clases: Las clases se pueden estar relacionadas con otras de diferentes maneras: Generalización la herencia es uno de los conceptos fundamentales de la programación orientada a objetos, en la que una clase “recoge” todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y operaciones propias. En uml, una asociación de generalización entre dos clases, coloca a estas en una jerarquía que representa el concepto de herencia de una clase derivada de la clase base. En uml, las generalizaciones se representan por medio de una línea que conecta las dos clases, con una flecha en el lado de la clase base.
Asociación: Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de “conexiones” entre objetos. Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí. Describe la conexión entre diferentes clases (la conexión entre los objetos reales se denomina conexión de objetos o enlace).
Las asociaciones pueden tener un papel que especifica el propósito de la asociación y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario. En uml, las asociaciones se representan por medio de líneas que conectan las clases participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mín…máx] de valores no negativos, con un asterisco (*) representado el infinito en el lado máximo.
Acumulación Las acumulaciones son tipos especiales que asociaciones en las que las dos clases participantes no tienen un estado igual, pero constituyen una relación “completa”. Una acumulación describe cómo se compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las acumulaciones, la clase que actúa como completa, tiene una multiplicidad de uno. En uml, las acumulaciones están representadas por una asociación que muestra un rombo en uno de los lados de la clase completa.
Composición Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones también forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente existen como parte del conjunto, y si este es destruido las partes también lo son.
En uml, las composiciones están representadas por un rombo sólido al lado del conjunto.
Los diagramas de clases pueden contener más componentes aparte de clases: Interfaces: Son clases abstractas, lo que significa que no es posible crear instancias directamente a partir de ellas. Pueden contener operaciones, pero no atributos. Las clases pueden heredar de las interfaces (a través de una asociación de realización) y de estos diagramas sí es posible crear instancias. Tipo de datos: Son primitivas construidas normalmente en algunos lenguajes de programación. Algunos ejemplos comunes son los enteros y los booleanos. No pueden tener relación con clases, pero las clases sí pueden relacionarse con ellos. Enumeraciones: Son simples listas de valores, las opciones de numeración se llaman “literales de enumeración”. Al igual que los tipos de datos, no pueden relacionarse con las clases, pero las clases sí pueden hacerlo con ellos. Paquetes: Los paquetes, en lenguajes de programación, representan un espacio de nombres en un diagrama se emplean para representar partes del sistema que contienen más de una clase, incluso cientos de ellas.
B. Diagrama de base de datos El diagrama o esquema de una base de datos describe la estructura de una base de datos en un lenguaje formal soportando por un sistema de gestión de base de datos. El esquema es generalmente almacenado en un diccionario de datos. Aunque generalmente el esquema es definido en un lenguaje de base de datos. El diagrama de base de datos tiene los siguientes niveles: Esquema conceptual, un mapa de conceptos y sus relaciones Esquema lógico, un mapa de las entidades y sus atributos y las relaciones.
Esquema físico, una aplicación de un esquema lógico. Esquema objeto, base de datos oracle objeto
C. Diagramas de despliegue Los diagramas de despliegue muestran las relaciones físicas de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como un computador, un dispositivo o memoria. Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos. Las instancias de los nodos pueden contener instancias de ejecución. Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Los artefactos Representan elementos concretos en el mundo físico que son el resultado de un proceso de desarrollo. Destino de despliegue Está generalmente representado por un nodo que es o bien de los dispositivos de hardware o bien algún entorno de ejecución de software. Los nodos pueden ser conectados a través de vías de comunicación para crear sistemas en red de complejidad arbitraria. Los diagramas de despliegue pueden describir la arquitectura a nivel de especificación (también llamado nivel de tipo) o al nivel de instancia (de manera similar a los diagramas de clases y diagrama de objetos). Los diagramas de despliegue de nivel de especificación muestran una visión general del despliegue de los artefactos hacia los destinos de despliegue, sin hacer referencia a casos concretos de artefactos o nodos. Los diagramas de nivel de instancia muestran el despliegue de instancias de artefactos en instancias específicas de los destinos de despliegue. Se pueden utilizar por ejemplo para mostrar las diferencias existentes en nombres/identificaciones en ambientes de despliegue a desarrollo, de “staging” o
de producción, entre construcciones específicas o servidores de despliegue o dispositivos. D. Diagramas de secuencia Los diagramas de secuencia muestran el intercambio de mensajes en un momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos. En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y de los parámetros.
Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el método finalice, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada. Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.
E. Ciclo de vida del software Es la forma mediante la cual se describen los diferentes pasos que se deben seguir, partiendo desde una necesidad hasta llegar a la puesta en marcha de una solución y su apropiado mantenimiento. El ciclo de vida para un software comienza cuando se tiene la necesidad de resolver un problema, y termina cuando el programa que se desarrolló para cumplir con los requerimientos, deja de ser utilizado.
Representa todas las actividades y artefactos necesarios para desarrollar una aplicación. Existen varias versiones del ciclo de vida del software entre las cuales se destacan: el ciclo de vida clásico o en cascada, el modelo en espiral, el desarrollo de prototipos, el modelo por incrementos y el modelo extremo. Etapas del ciclo de vida del software El ciclo de vida del software siendo uno de los más utilizados tal como lo plantean diferentes autores, está conformado en su versión ampliada por siete etapas que se pueden representar mediante un modelo en cascada así:
Ingeniería de sistemas: En esta etapa el analista luego de un minucioso y detallado estudio de los sistemas de una organización, detecta un problema o una necesidad que para su solución y satisfacción es necesario realizar un desarrollo de software.
Análisis: En esta etapa se debe entender y comprender de forma detallada cual es la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal manera que se obtenga la información necesaria y suficiente para afrontar su respectiva solución. Esta etapa es conocida como la del qué se va a solucionar. Diseño: Una vez que se tiene la suficiente información del problema a solucionar, es importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa es conocida bajo el cómo se va a solucionar.
Implementación: Partiendo del análisis y diseño de la solución, en esta etapa se procede a desarrollar el correspondiente programa que solucione el problema mediante el uso de una herramienta computacional determinada. Pruebas: Los errores humanos dentro de la programación de los computadores son muchos y aumentan considerablemente con la complejidad del problema. Cuando se termina de escribir un programa de computadora, es necesario realizar las debidas pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor número de situaciones posibles a las que se pueda enfrentar. Documentación: Es la guía o comunicación escrita en sus diferentes formas, ya sea en enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un programa. La importancia de la documentación radica en que a menudo un programa escrito por una persona, es modificado por otra. Por ello la documentación sirve para ayudar a comprender o usar un programa o para facilitar futuras modificaciones. La documentación se compone de tres partes: Documentación interna: son los comentarios o mensajes que se añaden al código fuente para hacer más claro el entendimiento de los procesos que lo conforman, incluyendo las precondiciones y las poscondiciones de cada función. Documentación externa: se define en un documento escrito con los siguientes puntos: Descripción del problema Datos del autor Algoritmo Diccionario de datos Código fuente Manual de usuario: describe paso a paso la manera cómo funciona el programa, con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.
Mantenimiento: Una vez instalado un programa y puesto en marcha para realizar la solución del problema previamente planteado o satisfacer una determinada necesidad, es importante mantener una estructura de actualización, verificación y validación que permitan a dicho programa ser útil y mantenerse actualizado según las necesidades o requerimientos planteados durante su vida útil. Para realizar un adecuado mantenimiento, es necesario contar con una buena documentación del mismo. Para terminar de entender la problemática en la cual se desarrolla este libro es importante tener unos conceptos claros y precisos de lo que es el análisis y el diseño de algoritmos.
III. Fases del desarrollo de software A. Identificar mercado objetivo para una aplicación El primer paso del proceso es el análisis, es aquí donde el analista se pone en contacto con la empresa para ver cómo está formada, a que se dedica, saber todas las actividades que realiza en sí, conocer la empresa de manera general para posteriormente ver cuáles son sus necesidades o requerimientos que la empresa tiene en ese momento para poder realizar un análisis de la misma. Es importante saber cuáles son los requerimientos que la empresa tiene porque muchas veces los sistemas se desarrollan pero no pensando en el cliente y es ahí donde el sistema no cumple o no satisface las necesidades que existen en la empresa, según los requerimientos se empieza a realizar el diagrama relacional todo debe de B. Identificar o fijar objetivos Diseñar aplicaciones informáticas que se ajusten a las necesidades de las organizaciones. Dirigir y coordinar el desarrollo de aplicaciones complejas. Intervenir en todas las fases del ciclo de vida de un producto. Estimar los costes de un proyecto y determinar los tiempos de desarrollo. Hacer el seguimiento de costes y plazos. Dirigir equipos de trabajo de desarrollo software.
Organizar la realización de pruebas que verifiquen el correcto funcionamiento de los programas y que se ajustan a los requisitos de análisis y diseño. Diseñar, construir y administrar bases de datos. Dirigir y asesorar a aplicaciones.
los
programadores
durante el desarrollo de
Introducir procedimientos de calidad en los sistemas, evaluando métricas e indicadores y controlando la calidad del software producido. Organizar y supervisar el trabajo de su equipo de los técnicos de mantenimiento y los ingenieros de sistemas y redes. 1. Productos a obtener Ya que está identificado cual será el mercado objetivo e identificados y fijados lo objetivos, debe estar claro cuáles serán los productos que se obtendrán al finalizar el software. 2. Restricciones En muchos casos los usuarios empiezan a solicitar determinadas restricciones en el sistema que en la mayoría de los casos no están aplicando en la ejecución de los procesos que se informatizan y de las cuales, muchas de ellas, no son de aplicación en contexto actual de trabajo. Si a estas restricciones, se le añade las que de manera creativa propone el equipo de proyecto, más las que tienen determinados productos base que han podido ser utilizados en el proceso de desarrollo nos encontraremos con sistemas incómodos de utilizar que nos e adaptarán a muchas casuísticas (esas situaciones excepcionales que después no lo son tanto) y que dará lugar a que los usuarios tengan que “buscarle las vueltas” al sistema para poder dar solución a situaciones de bloqueo, lo que provocará además una reducción de la productividad de los usuarios en el uso de la herramienta, el correspondiente descontento (que irá más conforme pase el tiempo y no se den soluciones) y que los datos tengan cada vez una peor calidad. Cuando el usuario defina restricciones es conveniente en primer lugar preguntarle cómo se gestionan las mismas en el contexto actual de trabajo (hay que tener en cuenta que en muchos casos la persona o personas que realizan la especificación no son los que participan en el día a día del proceso o procesos que se
informatizan, por lo mismo tiene una visión muy idealizada de cómo se están haciendo las cosas), cuales son las situaciones excepcionales en las que hay que saltarse la restricción y cuál es la probabilidad de que se produzcan dichas excepciones. Si se hace reflexionar a un usuario sobre las restricciones que está solicitando y de las consecuencias que tiene su duplicación, es posible que muchas de esas restricciones que quieren que el sistema recoja cómo sería el proceso si este se realizase de manera ideal desaparecerán. Las restricciones del sistema deben ser las precisas para que el proceso no quede desvirtuado y para que los usuarios puedan realizar su trabajo de manera fluida. 3. Identificar riesgos Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir. Se evalúan alternativas. Se debe tener un prototipo antes de comenzar a desarrollar y probar. 4. Planificación del proyecto a. Cronograma de trabajo Una lista de todos los elementos terminales de un proyecto con sus fechas previstas de comienzo y final. Existen metodologías estándares que aportan cronogramas de trabajo preestablecidos, que pueden utilizarse como base para la generación del mapa de actividades definitivo de un proyecto determinado. El cronograma de trabajo constituye una guía, orientación y recomendación para el responsable del proyecto pero no es un catálogo que se deba complementar en forma obligatoria. Por el contrario, el responsable del proyecto puede no ajustarse a este cronograma si su sentido común o percepción de la realidad así lo indica. Por otro lado, si bien el cronograma recomienda las actividades que debería llevarse a cabo, no determina las literaciones o formas de abordar las mismas que el proceso de software implique de acuerdo a las particularidades del proyecto. La confección del mapa de actividades sólo tiene sentido luego de conocer las características específicas del mismo. Esto suele ser luego de la planificación inicial, no antes ya que en ese caso los datos disponibles son mínimos. Por otro lado, cabe aclarar que el cronograma de trabajo no es un documento estático sino que va evolucionando junto con el proyecto. A medida que se obtienen más datos del proyecto, el cronograma de actividades va consolidando o,
por el contrario, si las características específicas del proyecto cambien en forma notoria, el mapa de actividades debe reflejarse ese cambio.
b. Costos de producción Son los gastos necesarios para mantener un proyecto, línea de procesamiento o un equipo en funcionamiento. En una compañía estándar, la diferencia entre el ingreso (por ventas y otras entradas) y el costo de producción indica el beneficio bruto. Esto significa que el destino económico de una empresa está asociado con: el ingreso (por ej., los bienes vendidos en el mercado y el precio obtenido) y el costo de producción de los bienes vendidos. Mientras que el ingreso, particularmente el ingreso por ventas, está asociado al sector de comercialización de la empresa, el costo de producción está estrechamente relacionado con el sector tecnológico; en consecuencia, es esencial que el tecnólogo pesquero conozca de costos de producción. El costo de producción tiene dos características opuestas, que algunas veces no están bien entendidas en los países en vías de desarrollo. La primera es que para producir bienes uno debe gastar; esto significa generar un costo. La segunda característica es que los costos deberían ser mantenidos tan bajos como sea posible y eliminados los innecesarios. Esto no significa el corte o la eliminación de los costos indiscriminadamente. C. Diseño 1. Análisis de requisitos El proceso de reunión de requisitos se intensifica y se centra especialmente en el software. Dentro del proceso de análisis es fundamental que a través de una colección de requerimientos funcionales y no funcionales, el desarrollador o desarrolladores del software comprendan completamente la naturaleza de los
programas que deben construirse para desarrollar la aplicación, la función requerida, comportamiento, rendimiento e interconexión. 2. Diseño del sistema Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el sdd (documento de diseño del software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación. 3. Diseño del programa Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber qué herramientas usar en la etapa de codificación. 4. Elección del lenguaje Una vez superada la etapa de diseño y que haya sido evaluada, procederemos a realizar la selección de la plataforma o lenguaje de programación. Para seleccionar la plataforma para el desarrollo de la aplicación debemos tomar en cuenta las funciones que se van a realizar, equipo con el que contamos, sistema operativo, conectividad con la que se cuenta, plataformas de datos con las que cuentan los sistemas actuales, tomar en cuenta las bondades que ofrece el lenguaje de programación, en cuanto a manejo de datos, capacidad de ejecución de los programas, recordemos que estos lenguajes con ejecuciones de lado del servidor por lo que debemos tomar en cuenta el tiempo de respuesta para los usuarios, recordemos que en estos programas importa mucho la rapidez con la que realicemos un procesos, pues como bien se ha comentado atrás son aplicaciones diseñadas para tener mejores condiciones de mercadotecnia; aplicaciones para diseño de páginas web; en la actualidad hay muchas herramientas visuales que nos ayudan a la tarea de diseñar las páginas sin web hay también varios lenguajes, algunos muy conocidos como perl, php, vbscript, c#, java necesidad de escribir el código html, xml, shtml. En cuanto a lenguajes de programación para aplicaciones, que nos ayudan a estas tareas, son flexibles e interactúan con lenguajes como html para generar salida de datos y
darle el formato deseado y pueda ser visible al usuario, tienen la gran ventaja que son lenguajes muy ligeros al ejecutarse. D. Programación 1. Flujogramas Es también conocido como diagrama de flujo y en este sentido se representa de manera gráfica un proceso que puede responder a diferentes ámbitos de la programación informática, procesos dentro de una industria, psicología de la cognición o el conocimiento, económico entre muchos otros.
Tipos de flujogramas Formato vertical: en él el flujo o la secuencia de las operaciones, va de arriba hacia abajo. Es una lista ordenada de las operaciones de un proceso con toda la información que se considere necesaria, según su propósito. Formato horizontal: en él el flujo o la secuencia de las operaciones, va de izquierda a derecha. Formato panorámico: el proceso entero está representado en una sola carta y puede apreciarse de una sola mirada mucho más rápidamente que leyendo el texto, lo que facilita su comprensión, aun para personas no familiarizadas. Registra no solo en línea vertical, sino también horizontal, distintas acciones simultáneas y la participación de más de un puesto o departamento que el formato vertical no registra. Formato arquitectónico: describe el itinerario de ruta de una forma o persona sobre el plano arquitectónico del área de trabajo. El primero de los flujogramas es eminentemente descriptivo, mientras que los últimos son fundamentalmente representativos. 2. Codificación Es la conversión de un algoritmo en programa, utilizando un lenguaje de programación. Las instrucciones expresadas en lenguaje natural deben ser expresadas en lenguaje de programación correspondiente.
E. Documentación Determina qué información debe estar incluida. Los documentos de especificaciones de software sirven como manuales de consulta para los diseñadores de la interfaz de usuario, los programadores que escriben el código, y los ensayadores que verifican que el software funcione como es debido. 1. Diseño de manual de usuario El manual de usuario de un programa es tan importante como el programa mismo. El manual de usuario es vital para aprender tanto las técnicas básicas como las avanzadas de un programa o aplicación. Los manuales son generalmente cortos, pero si hacen falta más detalles pueden ser mucho más largos. El tamaño de un manual dependerá exclusivamente del tipo de programa y de cuánto detalle debe tener. Los usuarios apreciarán un manual con información que se pueda encontrar fácilmente y que sea concisa, con suficiente detalle como para evitar confusiones.
F. Verificación 1. Puesta de verificación final Se ocupa de controlar si el producto satisface los requerimientos del usuario. Construir el sistema correctamente Descubrir y corregir errores en el sistema Criterios a verificar Verificar que la información sea coherente Identifica desviaciones con estándares y requerimientos Recolecta datos para mejorar el proceso Verifica que el producto cumpla: o Cumplan con los requerimientos o Cumplan con los atributos de calidad o Se ajuste a las regulaciones, estándares y procedimientos definidos
G. Mantenimiento el servicio de mantenimiento de software es una de las actividades en la ingeniería de software y es el proceso de mejorar y optimizar el software desplegado (revisión del programa), así como también remediar los defectos. El mantenimiento de software es también una de las fases en el ciclo de vida de desarrollo de sistemas (sdlc ó system development life cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo.