PROGRAMADORES
También reciben el nombre de desarrolladores de software, pero en realidad son sólo una pequeña parte del equipo de desarrollo.
Los programadores deben convertir la especificación del sistema en código fuente ejecutable utilizando uno o más lenguajes de programación, así como herramientas de software de apoyo a la programación.
Objetivos
Uno de los principales objetivos de los programadores es reducir la complejidad del software para disminuir la cantidad de problemas de testeo, aumentar la productividad de los programadores y la eficiencia en la manutención y modificación del programa.
Otros objetivos importantes son:
• Reducir el tiempo de codificación.
• Disminuir el número de errores que ocurren durante el proceso de desarrollo.
• Disminuir el esfuerzo de corregir errores en secciones del código que se encuentran deficientes, remplazando secciones cuando se descubren técnicas más confiables, funcionales o eficientes.
• Disminuir los costos del ciclo de vida del software.
Actividades y metas
Las principales actividades de los programadores y sus correspondientes metas a alcanzar son:
- Actividad
- meta
- Explorar los diferentes ambientes en que el sistema puede ser desarrollado.
- Determinar los lenguajes posibles de usar e identificar las posibles herramientas de desarrollo.
- Interactuar con los analistas y diseñadores.
- Seleccionar el ambiente apropiado.
- Explorar los diferentes lenguajes disponibles para el ambiente seleccionado.
- Seleccionar el lenguaje apropiado ya que esto afecta significativamente los costos, confiabilidad y rendimiento del sistema. Esta selección debe estar basada en la naturaleza de las aplicaciones (tiempo real, incrustada, basada en Web, etc.) y en la importancia de los indicadores de calidad (rendimiento vs confiabilidad).
- Interactuar con los diseñadores.
- Seleccionar el lenguaje apropiado y lenguaje de Programación.
- Explorar diferentes herramientas de desarrollo (compiladores, depuradores, etc.) disponibles para el lenguaje seleccionado.
- Seleccionar la herramienta de desarrollo apropiada.
- Explorar los distintos estilos de codificación que pueden ser utilizados en el lenguaje seleccionado.
- Escoger un estilo de codificación. Esto incluye los nombres de variables, la forma de hacer comentarios, el diseño y escritura de rutinas y módulos, la creación de tipos de datos, la selección y control de estructuras y la organización de bloques de instrucciones y se hace con el propósito de que todos los programadores puedan acceder fácilmente a todo el código.
- Realizar la codificación del sistema.
- Entregar el código ejecutable de acuerdo a las fechas presupuestadas
- Interactuar con los ingenieros de testeo.
- Determinar las formas de realizar el testeo
- Apoyar al ingeniero de testeo
- Realizar las actividades de testeo en forma rápida, eficiente, sistemática, exhaustiva y confiable, entregando un código utilizable y seguro
- Reunirse con otros miembros del equipo de programadores.
- Conocer el estatus de las actividades de programación, conocer la manera en que los demás abordaron alguna tarea en específico, revisando sus códigos y apoyando a sus colegas en caso de requerirlo.
- Realizar revisiones personales.
- Mantener el código eficiente y adaptable para ser unido con el código de otros programadores.
- Interactuar con el administrador de la configuración.
- Mantener al día el control de la configuración.
- Realizar los cambios solicitados al código.
- Mantener el software ejecutable eficiente. Esta modificaciones se hacen a petición del ingeniero de testeo o el administrador de configuración, y no directamente por una solicitud del cliente.
- Hacer la documentación del código.
- Entregar la documentación técnica del código fuente.
Relación con otros roles.
Los programadores deben relacionarse con otros miembros del equipo del proyecto para alcanzar los objetivos de la organización.
Administrador de proyecto: debe entregarle un reporte con los resultados de las actividades de programación cuando éste lo solicite, además de ayudarle en la estimación de tiempos y costos de las actividades de programación.
Analista: Deben interactuar para determinar el ambiente apropiado para el sistema.
Diseñador: El rol de programador depende mucho del rol de diseñador, debido a que debe utilizar herramientas adaptadas a la metodología utilizada en las actividades de diseño. El diseñador también le ayuda al programador a seleccionar el lenguaje de programación adecuado.
Téster: deben interactuar para determinar un forma apropiada de construir los tests y de testear los programas. El programador debe estar presente durante el testeo de código, cuando situaciones no esperadas suceden o es necesario realizar pequeñas modificaciones al código.
Administrador de configuración: debe entregarle la última versión del diseño y atender los diferentes pedidos de cambio del código. El programador puede solicitar cambios en otras partes del sistema a través del administrador de la configuración mediante el llenado del formulario correspondiente.
Ingeniero de manutención: el programador tiene mucha influencia en el rol de manutención, debido a que si el código está claro, será fácil de mantener. Dependiendo de las metodologías y herramientas empleadas, será más fácil o más difícil mantener los sistemas.
Asegurador de calidad: éste debe verificar la calidad del sistema construido y el programador le entrega su plan de trabajo.
Documentador: debe proveerle la documentación técnica del código.
Herramientas de trabajo
Existen muchas herramientas para ayudar al programador a desarrollar el sistema que consisten principalmente en ambientes de desarrollo integrados adaptados para un lenguaje de programación, los cuales pueden compilar y ejecutar un programa usando comandos para ello, la mayoría proveen herramientas para depurar el programa y algunos proveen herramientas de scheduling.
Perfil del Programador
- conocimiento de varios ambientes, para ayudar a los analistas y diseñadores a elegir el apropiado y experiencia en el desarrollo de aplicaciones en el ambiente seleccionado.
- conocer los diferentes lenguajes de programación disponibles para el ambiente seleccionado, y experiencia en el lenguaje de programación seleccionado, aprovechamiento de las herramientas utilitarias desarrolladas en proyectos previos y conocimientos en diferentes paradigmas de programación y estilos.
- conocer perfectamente las técnicas de diseño utilizadas por el diseñador y las metodologías de diseño.
- experiencia en bases de datos y en el tipo de proyecto que se desea realizar.
Plan de trabajo
- Explorar los diferentes ambientes de desarrollo.
- Explorar los diferentes lenguajes disponibles para el ambiente.
- Explorar las diferentes herramientas de desarrollo disponibles para el lenguaje seleccionado.
- Explorar sistemas ya construidos de los cuales, el nuevo sistema será parte.
- Elegir el estilo de programación.
- Programar las herramientas utilitarias y rutinas comunes.
- Codificar y depurar.
- Testear.
- Realizar revisiones personales y reuniones.
- Escribir la documentación técnica.
Software Analysis..
Introducción
Los lenguajes de programación han progresado tanto que el código va a expresar de manera inequívoca las intenciones del programador. En un futuro el análisis de código de todos los tipos se irá haciendo cada vez mas común.
Hasta ahora, investigación en cuanto a modelos abstractos y análisis de programas ha desunido empresas.
Este artículo estará dividido en tres partes: En las primeras dos partes discutimos el análisis de modelos y códigos abstractos respectivamente. En la tercera parte expandimos la posibilidad que recaen en la combinación de las dos, como el valor de los modelos puede ser realzado con el análisis del código, y como el análisis del código puede impulsar los modelos abstractos.
Otras formas de análisis importantes son:
- análisis de factores humanos
- análisis de propiedades sintácticas
- anáilisis en compiladores que permiten optimizaciones
1.1 Análisis vs Descripción
Los investigadores que trabajan en modelos abstractos pueden ser divididos en dos campos. Desarrolladores de Z, quienes se enfocan primeramente en la forma del modelo. Y los desarrolladores de checado de modelo simbólico, quienes se enfocan en el análisis.
Diseñar lenguaje sin un análisis en mente es como diseñar un lenguaje de programación que no puede ser compilado.
Diseñar un lenguaje de modelado sin semántica formal o por lo menos un fuerte sentido de que características serán probablemente problemáticas semánticamente, es por lo tanto una empresa peligrosa. Ya sea UML, un lenguaje de modelado sin complejidad precedente puede ser productivamente formalizado.
1.2 Modelos Globales Vs Locales
Los objetos modelo son estáticos y los diagramas de transición son dinámicos. Los modelos objeto son regularmente diagramas de clases, mostrando clases, sus campos, y las relaciones entre ellos. En comparación con los diagramas de transición que describen estados de tiempo. Un buen modelo de objeto es mucho más que un diagrama de clases: sus nodos representan sistemas de objetos, no clases, y estos pueden clasificar objetos dinámicamente.
Un objeto modelo es, por otra parte, un estado de máquina, sus estados son configuraciones de objetos.
Los desarrolladores seguido prestan menos atención a las transiciones a pesar de las notaciones que muchos métodos orientados a objetos ofrecen para describirlos.
Incluso si bien elaborados con transiciones, el modelo objeto describe cambios que ocurren menos seguido.
El modelo objeto describe la relación global entre los elementos del sistema.
El estado del diagrama de transición describe el estado de un objeto individual y el protocolo de interacción entre los objetos.
El estado global emerge de las definiciones de los estados locales.
Los mecanismos estructurados en un modelo global son orientados a especificaciones.
Los mecanismos estructurados en un modelo local son más orientados a implementaciones.
Por estas razones tiende a ser más útil para las etapas tempranas del desarrollo en las cuales caracterizar propiedades básicas y comportamientos globales esperados importa más.
Para los objetos modelo, su naturaleza global es la llave para su utilidad.
Las técnicas para checar un modelo no son fácilmente aplicables a los modelos globales.
1.3 Simulación vs Chequeo
La simulación es tremendamente útil. Cuando construyes un modelo incrementalmente, es fácil hacer errores que la simulación inmediatamente expone. Modelos animados generando estados de muestra y transiciones hace la experiencia de la construcción del modelo más obligada.
Los programadores tienen más confianza en su código cuando han realizado algunas ejecuciones de prueba.
Una de las razones por las que la simulación ha sido subestimada es que el checado hace mejores noticias.
La supremacía de la detección de errores sobre otro análisis es basada en cosas económicas que pueden no aplicar en el software.
La simulación del modelo permite al desarrollador experimentar con diferentes estructuras en adelantado, e investigar sus consecuencias.
1.4 Verificación vs Refutación
El checado es raramente automatizado, existen dos opciones: la verificación o la refutación.
La verificación, trata de analizar pruebas para la propiedad dada. Si no se encuentra ninguna prueba, la propiedad puede seguir siendo sostenida, pero dichos análisis rara vez fallan de tal forma que permiten al usuario determinar ya sea si es la estrategia de prueba o el modelo en si el que es un fallo.
La refutación, tiene el análisis de refutar la propiedad buscando un contraejemplo.
Algunas herramientas de análisis permiten al modelo ser descrito en una moda parametrizada, y la unión a ser impuesta como salida separada al analizador.
1.5 Declarativa vs Estilo Operacional
Descripciones operacionales corren el riesgo de las vías de implementación, pero los modelos locales rara vez sufren de eso.
Las descripciones declarativas, traen muchos beneficios a los modelos globales. 1º Es parcialidad: el modelo no necesita determinar el comportamiento del sistema completamente. Esta forma de no determinar es a veces vista como una deficiencia, pero en otros modelos es regularmente apropiada.
2º Es la incrementabilidad puede ser en realidad una conciencia de un soporte parcial. Un modelo declarativo puede ser entendido y evaluado en varias etapas.
3º La separación de ocupaciones: el modelo puede ser organizado para que distintas propiedades del diseño sean grabadas separadamente.
2. Análisis de código
Un diseñador o ingeniero que no puede confiar en el modelo para atinadamente reflejar el comportamiento actual del programa le será imposible usar el modelo para saber el comportamiento del sistema.
El desarrollo futuro de análisis de programas que garanticen la conformidad del software al modelo, incrementará la utilidad y así mismo la importancia del lenguaje de modelado durante todas las fases del desarrollo del programa.
Los análisis de programas serán utilizados en la construcción automática de modelos iniciales de la fuente del programa.
2.1 Estático vs Dinámico
Los análisis estáticos analizan el programa para obtener información que es válida para todas las posibles ejecuciones.
El análisis dinámico recolecta información del programa conforme esta va corriendo.
El análisis estático puede analizar el programa para encontrar todas las sentencias que potencialmente afectan a las variables globales, luego de analizar las sentencias para extraer información acerca de los valores asignados.
Otra ventaja significativa de las herramientas dinámicas es la precisión de la información que proveen.
Todos los análisis estáticos extraen propiedades que son sólo aproximaciones de las propiedades que actualmente sostiene el programa en ejecución. Esta imprecisión significa que el análisis estático puede proveer información que no es suficientemente acertada para ser útil.
2.2 Sonido vs Silencio
El análisis del sonido estático, produce información que esta garantizada para mantenerse durante todas las ejecuciones del programa.
Análisis del sonido dinámico, produce información que esta garantizada para mantenerse durante la ejecución analizada solamente.
Los análisis de silencio no hacen tales garantías. Un análisis de sonido para determinar los valores potenciales de variables globales, puede por ejemplo usar un análisis para asegurarse que modela correctamente el efecto de asignaciones indirectas que van a llevarse acabo vía pointers para variables globales.
Un análisis de silencio puede simplemente escanear el programa para localizar y enlizar sólo asignaciones que use la variable global directamente por nombre.
2.3 Velocidad vs Precisión
Los análisis estáticos típicamente exhiben la compensación entre tiempo de análisis y precisión.
El análisis del flujo sensible no toma el orden de las sentencias del programa en cuenta, y son incapaces de extraer cualquier propiedad que dependa de esa orden.
Los investigadores han desarrollado algoritmos de análisis de flujo insensible que han sido mostrados como escalas a programas que contienen miles de líneas de código.
Los ingenieros estarán interesados en propiedades que solo el análisis de flujo insensible puede extraer o checar.
2.4 Multiroscado vs Monoroscado
Muchas técnicas clásicas de análisis de programas fueron desarrollados para optimizar los compiladores para lenguajes secuenciales tales como Fortran. la meta era producir código eficiente para una maquina secuencial.
El análisis de los programas multiroscados se convertirá en un área activa de investigación. Los lenguajes de modelado jugarán un papel importante en este campo, y anticiparán el desarrollo de lenguajes diseñados para expresar propiedades importantes de programas multiroscados tales como: pólizas de sincronización y propiedades de compartimiento de objetos y datos.
2.5 Distribuido vs Localizado
Otra fuente importante de concurrencia existe entre componentes distribuidos ejecutándose en máquinas separadas.
Un interfaz mínimo es utilizado, apropiado e incluso necesario para sistemas en los que los componentes son desarrollados independientemente por diferentes organizaciones.
Existe otro tipo de sistema distribuidos que están más fuertemente acoplados, la prevalencia de dispositivos embebido hará dichos sistemas más comunes. En dichos sistemas, los componentes comúnmente tienen interacciones complicadas, deben ser diseñadas en una cerrada cooperación si el sistema completo esta hecho para confiar confiablemente.
3. Análisis del código del modelo manejado
Un prospecto particularmente emocionante es la explotación de modelos abstractos en el análisis estático de código. Hay una intrigante correspondencia entre objetos modelo y los gráficos de formas producidos por muchos análisis estáticos.
Los modelos pueden ayudar al análisis estático.
Hay un tercer elemento crucial en esta aproximación más allá del modelo y del análisis un mapeado para conectar a los dos.
3.1 Análisis modular por inducción
Nuestra perspectiva en los algoritmos de análisis de programas es que éstos descubren invariablemente que el programa se preserva.
Para descubrir un invariable, el análisis debe analizar todas las partes del programa que puedan afectar esa invariable.
Los lenguajes de modelado se han vuelto una forma popular entre los ingenieros para especificar las propiedades requeridas para el análisis modular.
3.2 Dándole control a los ingenieros
Los lenguajes de modelado ayudarán a direccionar una mayor debilidad en las aproximaciones a los análisis de programas actuales. Muchos análisis están desenfocados y toman lugar en la ausencia de cualquier indicación de las propiedades de interés para el consumidor de información de análisis.
CONCLUSIONES
EN LA ULTIMA DÉCADA, una apreciación para el costo-efectividad ha causado a los investigadores identificar más cuidadosamente la información que los ingenieros requieren, y encontrar la manera más efectiva de obtenerlo. Los análisis precisos y sonidos han pasado de moda.
En el futuro muchos factores traerán a la delantera de nuevo: la demanda de software confiable; la disponibilidad de bastos recursos computacionales; y, tal vez más significativamente la explotación de modelos abstractos, para enfocar el esfuerzo en donde la paga o la recompensa sea mayor.
Las personas en la metodología de la ingeniería del software
Con el paso del tiempo, el rol de las personas en las metodologías de la ingeniería del software ha ido variando desde que esta disciplina nació. Podemos encontrar diferentes grados de reemplazo de las personas, dependiendo del rol que lleven a cabo en el proyecto de desarrollo de software y del tiempo en que se ubicaron.
- Protoingeniería del software
Los protoingenieros del software fueron los primeros profesionales dedicados a la informática y se dice que estaban adelantados a su tiempo, ya que tenían características únicas e hicieron historia gracias a su trabajo y esfuerzo individual.. por lo que este tipo de personas las podemos ubicar en la categoría de irremplazables:
- Blas Pascal. Fue el inventor de la primera calculadora a los 19 años en 1642, y la llamó Pascalina.
- Charles Babbage. Diseñó su máquina analítica en 1830 y a su muerte, en 1971, dejó 36m2 de diseño. La máquina analítica era un “protoordenador” que podía ser programado para solucionar una amplia gama de problemas lógicos y computacionales. Nunca pudo completar su invento porque la piezas que necesitaba no estaban disponibles en es tiempo. El primer ordenador norteamericano(Mark I) se basó en las ideas de Babbage.
- John Von Newmann. Precursor de la separación etntre hardware y software e inventor del concepto “programa almacenado”, propuso al bit como unidad de información y resolvió el problema de la obtención de respuestas fiables con componentes no fuiables (bit paridad). También conocido como el padre de la vida artificial.
- Alan M. Turing. Creador de la máquina de Turing, que fue el antecedente teórico de la computadora moderna. Demostró que la base esencial de la informática podía modelarse con una máquina teórica muy simple, propuso un método para determinar si una máquina es inteligente (Test de Turing) y estableció las bases de la inteligencia artificial. Llegó a verse a sí mismo como un ordenador.
2. Metodologías “pesadas”
Estas metodologías aparecieron entre los años 70’s y 90’s, por la necesidad de controlar y normalizar el proceso de desarrollo de software y en las que las personas eran vistas como elementos fácilmente reemplazables ya que lo que importaba era el rol y no la persona.
2.1 Metodologías estructuradas clásicas
Se basaban en la estructuración y descomposición funcional de problemas en unidades más pequeñas interrelacionadas entre sí.
Surgidas de la mano de Yourdon y Myers, esteas metodologías se utilizan principalmente para implementar proyectos orientados a la manipulación de datos y gestión, ya que hacen una fuerte separación entre los datos y los procesos y producen una gran cantidad de modelos y documentación basados en el ciclo de vida en cascada.
2.2 Metodologías Orientadas a Objetos clásicas
Un ejemplo claro de éstas puede ser el RUP (Rational Unified Process), que es un conjunto de metodologías que priman las fases, actividades y tareas, antes que a las personas, es decir, es más importante el rol que juega la persona en el proceso de desarrollo.
El desarrollo de software es una actividad compleja que debe dividirse y llevarse a cabo en grupos, por ello, los roles son asignados de acuerdo a las características y capacidades de cada individuo, definiendo sus objetivos, actividades, interacción con otros roles, herramientas a utilizar, perfil y un plan de trabajo.
Una de las ventajas de este proceso es que el intercambio de recursos es relativamente fácil: entre más identificadas se tengan las tareas que realiza un rol, más fácil es formar a una persona en esas tareas específicas.
Aquí podemos ubicar a las personas en la categoría moderadamente reemplazables, ya que si bien es fácil reemplazar a una persona con otra, puede haber consecuencias inesperadas por ello.
3. Las personas en las metodologías ágiles.
Estas metodologías vuelven a dar a las personas el valor que realmente tienen en el desarrollo de software y su éxito se basa en la participación, preparación e involucramiento de las personas en el proceso, que debe ser conducido y llevado a cabo por personas con características muy especiales. El reemplazo de una persona en este tipo de metodologías podría afectar severamente el proceso, por lo que la ubicamos en la categoría difícil de reemplazar.
3.1 Proceso ágiles
Están basados en principios como la temprana y continua entrega de software de valor, la actitud positiva frente al cambio de requerimientos en función de las necesidades del cliente, la motivación individual de los integrantes del proyecto, la comunicación fluida entre el personal de desarrollo y de negocios, la excelencia técnica, la simplicidad, la comunicación personal, la emergencia y la autoorganización; que fueron extraídos del Manifiesto Ágil, un documento que surge de una reunión entre varios reconocidos ingenieros de software para crear un “llamado a las armas a favor de los métodos ágiles de desarrollo de software”.
3.2 Las metodologías ágiles más famosas
- Extreme Programming
- Cristal Clear
- SCRUM
- DSDM
- Highsmith’s Adaptative Softaware Development
en este enlace puedes encontrar algo de información acerca de éstas metodologías.
Administración de Punto de venta de Kiosko
Nosotros elegimos investigar sobre cómo es que se administra un punto de venta en los kioskos que se encuentran operando en la ciudad de Colima, es decir, las secciones o módulos que se necesitan en su funcionamiento diario.
El objetivo de la investigación es que al final de ella podamos hacer cambios o mejoras al sistema utilizado en la actualidad.
Punto de Venta Kiosko. Equipo 1 