HERRAMIENTAS CASE

 HERRAMIENTAS CASE

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras, que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

 ALGUNAS HERRAMIENTAS CASE

No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a:

- Las plataformas que soportan.

- Las fases del ciclo de vida del desarrollo de sistemas que cubren.

- La arquitectura de las aplicaciones que producen.

- Su funcionalidad.

CASE es una combinación de herramientas software (aplicaciones) y de metodologías de desarrollo:

1. Las herramientas permiten automatizar el proceso de desarrollo del software.

2. Las metodologías definen los procesos automatizar.

Una primera clasificación del CASE es considerando su amplitud:

TOOLKIT: es una colección de herramientas integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informático: Planificación estratégica, Análisis, Diseño, Generación de programas.

WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatización del proceso completo de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en código ejecutable y su documentación.

Una segunda clasificación es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan:

UPPER CASE: Planificación estratégica, Requerimientos de Desarrollo Funcional de Planes Corporativos.

MIDDLE CASE: Análisis y Diseño.

LOWER CASE: Generación de código, test e implantación.

INTRODUCCIÓN AL MODELADO

 INTRODUCCIÓN AL MODELADO

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

 CARACTERÍSTICAS DE LOS LENGUAJES DEL MODELADO

Clasificación: es la organización de métodos y datos de la misma estructura, además de su comportamiento. En éste caso se puede ver que una capa se encuentra compuesto por tipos como son punto, líneas, polilíneas y polígonos estos a su vez manejan atributos y métodos.

Generalización: es la capacidad que permite que un objeto especializado pueda ser substituido por un elemento de su super-clase. En este caso la sub-clase comparte la estructura y el comportamiento de la super-clase.

Asociación: Es un enlace que existe entre una clase y otra. Este enlace permite hacer una referencia hacia otras clases.

Agregación: es una propiedad que permite que se manejan objetos compuestos, los cuales a su vez son otros objetos. Es una relación parte-de donde al unirse forman el ensamblaje completo.

DIAGRAMAS

Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a mode-lar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. UML incluye los siguientes diagramas:

• Diagrama de casos de uso.
• Diagrama de clases.
• Diagrama de objetos.
• Diagrama de secuencia.

SÍMBOLOS O ELEMENTOS DE MODELO

Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

INTRODUCCION Y FUNDAMENTO DE LOS PROCESOS ÁGILES DE DESARROLLO

 INTRODUCCIÓN A LOS PROCESOS ÁGILES DE DESARROLLO

El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto. Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

 FUNDAMENTOS DE LOS PROCESOS ÁGILES DE DESARROLLO

El auge de la tecnología, y el objetivo de agilizar y automatizar los procesos en el desarrollo de software, llevan a la necesidad de implantar Metodologías de Desarrollo de Software que ayuden a entregar un producto de calidad en tiempo y costo estimados, las metodologías ágiles de desarrollo de software han despertado interés gracias a que proponen simplicidad y velocidad para crear sistemas.

Proceso Unificado de Desarrollo (UP del inglés UnifiedProcess) Fases de desarrollo. Disciplinas.

Proceso Unificado de Desarrollo (UP del inglés UnifiedProcess) Fases de desarrollo. Disciplinas.

 El Proceso Unificado:  es dirigido por casos de uso. 

    

Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios prospectos.

El término usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el término usuario representa algo o alguien que interactúa con el sistema por desarrollar.

Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificación funcional del sistema.

Una especificación funcional tradicional se concentra en responder la pregunta: ¿Qué se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: ¿por cada usuario? Estas tres palabras tienen una implicación importante, nos fuerzan a pensar en términos del valor a los usuarios y no solamente en términos de las funciones que sería bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen el proceso de desarrollo.

Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.

El Proceso Unificado: está centrado en la arquitectura

El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempeña en la construcción de edificios. El edificio se mira desde diferentes puntos de vista: estructura, servicios, plomería, electricidad, etc. Esto le permite al constructor ver una radiografía completa antes de empezar a construir. Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que está siendo construido.

El concepto de arquitectura de software involucra los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como están reflejadas en los casos de uso. Sin embargo, también está influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutará, la disponiblidad de componentes reutilizables, consideraciones de instalación, sistemas legados, requerimientos no funcionales (ej. desempeño, confiabilidad). La arquitectura es la vista del diseño completo con las características más importantes hechas más visibles y dejando los detalles de lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en los cambios futuros (resilience) y reuso.

¿Cómo se relacionan los casos de uso con la arquitectura? Cada producto tiene función y forma. Uno sólo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso función corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un problema del “huevo y la gallina”. Por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realización de todos los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo.

El Proceso Unificado: es Iterativo e Incremental

Desarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o años. Es práctico dividir el trabajo en pequeños pedazos o mini-proyectos. Cada mini-proyecto es una iteración que finaliza en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto. Para ser más efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada.

Los desarrolladores basan su selección de qué van a implementar en una iteración en dos factores. Primero, la iteración trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto. Segundo, la iteración trata con los riesgos más importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteración anterior.

En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso. Si una iteración cumple sus metas – y usualmente lo hace – el desarrollo continúa con la siguiente iteración. Cuando la iteración no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.

FUNDAMENTOS DEL ENFOQUE ORIENTADO A OBJETOS

 PROCESO DE DESARROLLO DE SOFTWARE

Un proceso, se define como una serie de operaciones usadas en la creación de un producto. Un proceso de software se puede definir de las siguientes formas:

Un proceso de software define el conjunto de tareas, que tienen que ser realizadas para producir un producto de software de alta calidad. En otras palabras, este es el enfoque que se toma para el desarrollo del software.

Es el proceso que se sigue para construir el producto de software desde la concepción de una idea, hasta la entrega y el retiro final del sistema.

 FUNDAMENTOS DEL ENFOQUE ORIENTADO A OBJETOS Y CARACTERÍSTICAS

La orientación a objetos ofrece una solución que ayuda a los desarrolladores a hacer corresponder el mundo real tan cerca como sea posible al dominio de la solución. Cabe mencionar que existen muchas metodologías que permiten soluciones para problemas complejos. En la orientada a objetos se basa en modelar el mundo real y ha ganado importancia significativa en los últimos tiempos. En la orientación a objetos se trabaja con objetos en el sistema que interactúan unos con otros a través de mensajes. La orientación a objetos proporciona los recursos para ocuparse de los objetos de un sistema complejo. El análisis y diseño de un sistema desde una perspectiva orientada a objetos forma el núcleo de un sistema.

Características

• Modelado del mundo real
• Datos Abstractos
• Abstracción de datos
• Encapsulamiento
• Ocultamiento de la información
• Clase
• Objeto
• Interfaz e Implementación
• Métodos
• Mensajes
• Herencia
• Agregación
• Polimorfismo
• Tipo
• Rol
• Paquete

APLICABILIDAD DEL ENFOQUE ORIENTADO A OBJETOS

Claridad

Al ligar de forma evidente la estructura de la información con los procedimientos que la manipulan, los programas ganan en claridad a la hora de desarrollarlos y mantenerlos.

Complejidad

Cuando la complejidad de un problema es abarcable por una sola persona, resolverlo con una herramienta u otra no aporta grandes ventajas. Pero cuando este desarrollo la tiene que realizar un equipo grande, debe existir una forma para aislar partes de problema.

Tamaño

Las aplicaciones orientadas a objetos son ideales para la realización de programas de gran tamaño. Las facilidades de encapsulación y asociación de las funciones a los datos que manipulan, simplifican el proceso de desarrollo.

Relación entre Datos

Este tipo de complejidad permite la utilización de todas las ventajas de los lenguajes de programación orientados a objetos. Propiedades como la herencia (donde los objetos pueden heredar estructura y operaciones de objetos predecesores), la encapsulación, etc. Muestran en este tipo de programas todas sus ventajas.

Rapidez

En este aspecto, los lenguajes orientados a objetos muestran una clara desventaja frente a otros lenguajes que se acercan más a las especificaciones de la máquina. Si la rapidez es crítica, puede elegir un lenguaje de programación como C++, que aporta toda la funcionalidad de los lenguajes orientados a objetos con la rapidez y la compatibilidad de C.

Gestión de recursos

Las aplicaciones orientadas a objetos demandan normalmente más recursos del sistema que las aplicaciones procedurales. La creación dinámica de objetos, que ocupa un lugar en la memoria del ordenador, puede acarrear graves problemas. Una de las soluciones, que incluye alguno de los lenguajes OOP, es liberar a menudo el espacio que los objetos dejan de utilizar.

Interfaces de usuario.

Es uno de los aspectos más importantes en la programación actual. La aparición de sistemas de explotación que soportan un interface gráfico de usuario como Windows, X-Windows o Presentation Manager hace que la mayoría de los usuarios prefieran que sus programas corran bajo este tipo de interface. Este es uno de los puntos fuertes para la elección de un lenguaje OOP. La mayoría de los interfaces gráficos actuales han sido diseñados o rediseñados en base a la OOP.

 DESARROLLO DE COMPONENTES

Es una unidad autocontenida que encapsula el estado y el comportamiento de varios clasificadores. También se podría decir que es un tipo clasificador con la diferencia de que no tiene características propias, pero contiene las clases que definen las características. Un componente proporciona una vista encapsulada de la funcionalidad definida por las clases contenidas. Un componente es una parte física del sistema. Cada componente tiene un nombre, el cual puede ser un nombre simple o un nombre de ruta.

 TIPOS DE COMPONENTES Y CARACTERÍSTICAS

• Componentes de despliegue o distribución (Deployment)

Estos componentes se usan para formar un sistema ejecutable. Un ejemplo de tal componente es la librería de enlace dinámico y los archivos ejecutables. Otros ejemplos son los componentes COM+, Enterprise Java Beans, componentes CORBA y objetos de base de datos.

• Componentes de Producto de Trabajo

Estos componentes son parte del proceso de desarrollo que es esencial para el sistema. Algunos ejemplos de componentes de producto de trabajo son los archivos fuente, archivos de datos y tablas. Ellos son los archivos fuente y archivos de datos que se usan para crear los componentes de distribución como Agente Analizado. Java y AnalizadorDatos.txt.

• Componentes de Ejecución

Estos componentes son el resultado de un sistema que se está ejecutando. Cuando un DLL es instanciado como un componente COM+, es un ejemplo de un componente de ejecución.

Características

• La característica fundamental de un componente es la habilidad de definir interfaces.

• Es una unidad ejecutable que puede ser implantada independientemente.

• Puede ser sujeto de composición por terceras partes, es decir, una compañía o un desarrollador puede llegar y tomar el componente y agregarlo a lo que esté haciendo, o sea haría una composición de componentes.

• Un componente no tiene estado.

• Se puede tomar a los componentes de software como una analogía a los componentes electrónicos.

 REUSABILIDAD DE COMPONENTES

Una vez que una clase ha sido escrita, creada y depurada, se puede distribuir a otros programadores para utilizar en sus propios programas. Esta propiedad se llama reusabilidad  o reutilización. Su concepto es similar a las funciones incluidas en las bibliotecas de funciones de un lenguaje procedimental como C que se pueden incorporar en diferentes programas. En C++, el concepto de herencia proporciona una extensión o ampliación al concepto de reusabilidad.

 ESTÁNDARES EN EL PROCESO DE DESARROLLO DEL SOFTWARE

Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción.

 DOCUMENTACIÓN Y ARTEFACTOS

La documentación no es más que la debilidad más frecuente en productos e instalaciones informáticos. Cabe mencionar que los actores que intervienen en el ciclo de vida del software desempeñan diversos roles. Arquitectos, diseñadores, analistas, programadores, implementadores, administradores o auditores son quienes explicitan distintos aspectos de los productos y procesos.

Un artefacto es una pieza de información que es producida o utilizada por procesos. Los artefactos son los elementos son los elementos tangibles de un proyecto, elementos que el proyecto produce o usa mientras se trabaja en busca del producto final. Éstos, pueden tomar varias formas y formatos, como por ejemplo:

Un documento, tal como la visión o la lista de riesgos.

Un modelo, por ejemplo un diagrama de casos de uso o el modelo de diseño.

Un elemento dentro de un modelo, tal como una clase, un caso de uso o un subsistema.

Ejecutables, por ejemplo el ejecutable del prototipo.

Código fuente.

METODOLOGÍAS EMPLEADAS

La metodología de desarrollo de software orientada a objetos es cada día más usada, pues permite desarrollar software fácilmente extensible y reusable. Esto último es sólo posible si los desarrolladores conocen muy bien los fundamentos que esté basada esta metodología. Por eso, este curso revisa los conceptos más importantes que se encuentran en las distintas etapas del desarrollo de software orientado a objetos.

VISIÓN GENERAL DEL PROCESO DE DESARROLLO DE SOFTWARE

VISIÓN GENERAL DEL PROCESO DE DESARROLLO DE SOFTWARE

Es proceso es afectado por la creatividad y juicio de las personas  involucradas. En el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente.

Es actividades requeridas para desarrollar un sistema de software de alta calidad y proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software. Actividades: Diseño, validación, evolución, especificación.

EL PAPEL DEL USUARIO DENTRO DEL PROCESO DE DESARROLLO DE SOFTWARE

Todos sabemos que cuanto mayor sea la ayuda de los usuarios en un proyecto de desarrollo de software, mayores serán las probabilidades de éxito que tenga el mismo.

No obstante es importante hacer algunas matizaciones:

1) El proyecto no se hace sólo, porque incluso existiendo una gran ayuda por parte de los usuarios, si no se consigue interpretar con precisión lo que quieren y no se dinamiza un feedback continuo de los mismos durante todo el proceso de desarrollo, se incrementarán las posibilidades de que algún requisito funcional no se haya recogido adecuadamente o de que se haya realizado un software con una usabilidad incómoda para los usuarios.

Estas circunstancias son fuente de innumerables problemas en las fases finales del proyecto y provocan retrasos, sobrecostes y grandes dificultades para cerrar el proyecto, además de crear conflictos con el cliente que pueden perjudicar las relaciones futuras con el mismo. Esto hace que sea fundamental el papel que desempeñan tanto el jefe de proyectos, como el equipo de analistas funcionales y analistas programadores.

2) Es importante que entre el grupo usuarios asignados al proyecto haya usuarios que vayan a estar implicados en el futuro uso del sistema de información, es decir, no es suficiente que el equipo de usuarios esté formado por “ideólogos” o “teóricos” que se nutrirán del resultado del trabajo de la herramienta, sino que es fundamental que participen usuarios que después se tengan que poner el mono de trabajo y vayan a trabajar con el software. Es importante conseguir la combinación de ambos tipos de usuarios (tampoco es positivo que en el grupo de usuarios no participen usuarios directores, ya que pueden existir conflictos entre usuarios que éstos deben solucionar y también es recomendable que el software no sólo se diseñe para el corto plazo, sino que sirva para tareas de gestión, planificación, etc… y esta visión la proporcionan principalmente los usuarios directores), por lo que el jefe de proyectos debe poner en conocimiento del cliente esta necesidad, como es lógico explicando los riesgos de que no se aplique esta estrategia.

3) Los analistas están para ayudar y para colaborar con los usuarios en la especificación y diseño de la solución, pero no están para “dar lecciones” a los usuarios y enseñarle cómo deben hacer su trabajo. Si los usuarios hacen su trabajo de una determinada manera, aunque no sea la más ortodoxa, siempre tendrá una justificación que sólo se entendería si realmente estuviéramos haciendo su trabajo durante un tiempo y viéramos los problemas con los que se enfrentan cotidianamente. La clave por tanto está en la colaboración y en el diálogo, es decir, se pueden proponer cosas al usuario, se le pueden dar ideas, pero no se le puede dar una vuelta al calcetín de cómo hacen sus tareas, salvo que ellos mismos lo soliciten y procurando en estos casos y en consenso con los usuarios que los cambios sean tranquilos.

4) Es fundamental documentar el proyecto, en primer lugar con la documentación que se especifique en las normativas de desarrollo de la organización para la que se realiza el servicio, con las matizaciones que indique el Director del Proyecto, en segundo lugar con la documentación que establezcan las normativas internas de calidad de tu organización (no requerirá un sobreesfuerzo, ya que en la mayor parte de los casos coincidirá) y a todo lo anterior sumarle toda la documentación de trabajo que sea necesaria para trabajar con los usuarios, que no tienen por qué entender de modelos de datos, de diagramas de casos de uso, etc…, es más, es un error trabajar con los usuarios utilizando dichas herramientas, ya que estas son de utilidad técnica y no hablan el mismo lenguaje de los usuarios. Este tipo documentación, por tanto, no tiene por qué tener los formalismos de la técnica y tiene como objetivo que el usuario capte lo que el analista está interpretando y se pueda ir perfilando a partir de esto, tanto requisitos, como casos de uso, interfaces, etc… Es muy importante trabajar todo esto, ya que comenzar demasiado pronto con la construcción, es algo muy arriesgado, ya que los costes de modificar algo en las distintas fases de la construcción pueden ser muy importantes y provocar que se tengan que reconstruir varias veces distintas funcionalidades de la aplicación.

RESPONSABILIDAD PROFESIONAL Y ÉTICA

La ingeniería del software se lleva a cabo dentro de un marco legal y social que limita la libertad de los ingenieros. Los ISW deben aceptar que su trabajo comprende responsabilidades más amplias que simplemente la aplicación de habilidades técnicas. Deben comportarse de una forma ética y moral responsable, no basta con poseer estándares normales de honestidad e integridad. No debería utilizar su capacidad y sus habilidades para comportarse de forma deshonesta o de forma que deshonre la profesión de la ingeniería del software.

Existen áreas donde los estándares de comportamiento aceptable no están acotados por las leyes, sino por la responsabilidad profesional, algunas de estas son:

• Confidencialidad. Respetar la confidencialidad de sus empleadores o clientes, independientemente de que se haya firmado un acuerdo formal de confidencialidad.

• Competencia. No debe falsificar su nivel de competencia, ni aceptar conscientemente trabajos que están fuera de su capacidad.

• Derechos de propiedad intelectual. Debe ser consciente de las leyes locales que gobiernan el uso de la propiedad intelectual, como las patentes el el copyright. Debe asegurarse de que la propiedad intelectual de los empleadores y clientes está protegida.

Uso inapropiado de las computadoras. No debe emplear sus habilidades técnicas para utilizar de forma inapropiada las computadoras de otras personas. Desde los relativamente triviales (utilizar juegos en las maquina de un empleado, por ejemplo) hasta los extremadamente serios (difusión de virus).

CÓDIGO DE ÉTICA (ACM/IEEE)

Los ingenieros de software deberán comprometerse consigo mismo en convertir el análisis, especificación, diseño, desarrollo, prueba y mantenimiento de software en una profesión respetable y beneficiosa. De acuerdo con su compromiso con la salud, seguridad y bienestar del público, los ingenieros de software deberán apegarse a ocho principios.

CICLO DE VIDA DEL SOFTWARE

Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado, se identifican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en función de cuales sean las características del proyecto, se configurará el ciclo de vida de forma diferente. Usualmente se consideran las etapas: especificación y análisis de requisitos, diseño del sistema, implementación del software, aplicación y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareas del desarrollo del software es la documentación de todos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estará influida por la fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su importancia en el conjunto del desarrollo del software.

Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo de vida son:

Análisis: Construye un modelo de los requisitos

Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario.

Codificación: Construye el sistema. La salida de esta fase es código ejecutable.

Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.

Validación: es el proceso de comprobar que lo que se ha especificado es lo que el usuario realmente quería.

Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el sistema siga funcionando y adaptándose a nuevos requisitos.

PRINCIPIOS DEL CÓDIGO

Público: Los ingenieros de software deberán actuar consistentemente con el interés público.

Cliente y Empleador: Los ingenieros de software deberán actuar de una forma determinada que esté en los mejores intereses de su cliente y empleador consistente con el interés público

.

Producto: Los ingenieros de software deberán asegurar que sus productos y modificaciones relacionadas logren el más alto estándar profesional posible.

Juicio: Los ingenieros de software deberán mantener integridad e independencia al emitir su juicio profesional.

Gerencia: Los gerentes y lideres de ingeniería de software deberán suscribirse y promocionar un enfoque ético para la gerencia de desarrollo y mantenimiento del software.

Profesión: Los ingenieros de software deberán fomentar la integridad y reputación de la profesión consistente con el interés público

.

Colegas: Los ingenieros de software deberán ser justos y comprensivos con sus colegas.

Interés Propio: Los ingenieros de software deberán participar en el aprendizaje de por vida del ejercicio de su profesión y deberán promover un enfoque ético para el ejercicio de la misma.

MODELOS DE DESARROLLO DE SOFTWARE

Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado para sus necesidades. En ocasiones puede que una combinación de varios modelos sea apropiado.

Modelo de cascada

El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes fases de forma sucesiva:

Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.

Modelo de espiral

La principal características del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.

La espiral se visualiza como un proceso que pasa a través de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:

crear planes con el propósito de identificar los objetivos del software,seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;

Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo; la implementación del proyecto: implementación del desarrollo del software y su pertinente verificación; Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la reutilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:

El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes que acepten este análisis y actúen en consecuencia. Para ello es necesaria confianza en los desarrolladores así como la predisposición a gastar más para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.

Si la implementación del riesgo de análisis afectará de forma esencial los beneficios del proyecto, no debería utilizarse este modelo.

Los desarrolladores de software han de buscar de forma explícita riesgos y analizarlos de forma exhaustiva para que este modelo funcione.

La primera fase es la búsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por último, se evalúan los resultados y se inicia el diseño de la siguiente fase.

MÉTODOS  EN EL PROCESO DE DESARROLLO DE UN SOFTWARE.

Los métodos formales son soluciones matemáticas para resolver problemas de software y hardware a nivel de requisitos, especificación y diseño. Ejemplos de métodos formales incluyen el Método B, la red de Petri, la demostración automática de teoremas, RAISE y el VDM. Hay varias notaciones de especificaciones formales, tales como el lenguaje Z. Más generalmente, se puede utilizar la teoría de autómatas para aumentar y validar el comportamiento de la aplicación diseñando un sistema de autómata finito.

METODOLOGÍAS PARA EL DESARROLLO DEL SOFTWARE

Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso.

ACTIVIDADES EN EL PROCESO DEL DESARROLLO DEL SOFTWARE

• Planificación.
• Implementación.
• Pruebas del software.
• Documentación.
• Entrenamiento.
• Despliegue
• Mantenimiento del software.

HERRAMIENTAS PARA EL DESARROLLO DE SOFTWARE

Las Herramientas de Ayuda al Desarrollo de Sistemas de Información, surgieron para intentar dar solución a los problemas inherentes a los proyectos de generación de aplicaciones informáticas: plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y baja calidad de los desarrollos. Algunas de estas herramientas se dirigen principalmente a mejorar la calidad, como es el caso de las herramientas CASE (Computer Aided Software Engineering-Ingeniería de Software Asistida por Ordenador). Otras van dirigidas a mejorar la productividad durante la fase de construcción, como es el caso de los lenguajes de cuarta generación (4GL-Fourth Generation Language).

TÉCNICAS PARA EL DESARROLLO DE SOFTWARE

• La recolección de datos es una técnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de información, los cuales pueden ser la entrevistas, la encuesta, el cuestionario, la observación, el diagrama de flujo y el diccionario de datos.

• El análisis de costo-beneficio es una técnica analítica que enumera y compara el costo neto de una intervención con los beneficios que surgen como consecuencia de aplicar dicha intervención. Para esta técnica, los costos y los beneficios de la intervención se expresan en unidades monetarias.

SELECCIÓN DEL MODELO APROPIADO SEGÚN LAS CARACTERÍSTICAS DE LOS PROYECTOS DE SOFTWARE

Cuando se gestiona un proyecto exitoso, es necesario entender que este puede llegar a fracasar. Según John Reel, existen 10 razones por las cuales un proyecto puede fracasar:

1. El personal de software no entiende las necesidades del los clientes.
2. El ámbito del producto está mal definido.
3. Los cambios se gestionan mal.
4. La tecnología elegida cambia.
5. Las necesidades comerciales cambian.
6. Los plazos de entrega no son realistas.
7. Los usuarios se resisten a la utilización del software.
8. Se pierde el patrocinio.
9. El equipo del proyecto carece de personal con las habilidades apropiadas.
10. Los gestores evitan las mejores prácticas y las lecciones aprendidas.

Para tener éxito en la consecución de un proyecto es necesario comenzar con pie derecho, esto se lo logra trabajando duro para entender el problema y dar una solución adecuada. Se debe rastrear el proyecto conforme se elabora el producto y se aprueba por parte del grupo de control de calidad. Es importante que el gestor del proyecto tome decisiones inteligentes para no poner en riesgo el desarrollo de la solución. Por último, se debe analizar los resultados obtenidos para obtener la experiencia necesaria en la construcción de otros proyectos.

EL SOFTWARE

FUNDAMENTOS DE LA INGENIERÍA DEL SOFTWARE

El Software

         El software no es sólo código, sino también las especificaciones del diseño, los datos tratados y la documentación que permite el desarrollo, instalación y mantenimiento.

Estrictamente, se puede definir como:

         1) Instrucciones que, cuando se ejecutan, proporcionan la funcionalidad deseada.

         2) Estructuras de datos que facilitan a las instrucciones manipular adecuadamente la información.

         3) Documentos que describen el desarrollo, uso, instalación y mantenimiento de los programas.

Cualidades del Software

• Correcto
• Confiable
• Robusto
• Eficiente
• Amigable
• Verificable
• Reusable
• Portable
• Interoperable
• Productivo
• A Tiempo
• Visible
• Coheso
• Desacoplado
• Comprensible
• Mantenible

Calidad del software

La calidad del software es, según Pressman, la “concordancia con los requisitos funcionales y de rendimiento, con los estándares de desarrollo y con las características implícitas que se espera del software desarrollado profesionalmente”

No existe una definición única de calidad, ya que:

• Es un concepto relativo (es una compleja mezcla de factores que varía para las diferentes aplicaciones y los clientes que las solicitan).

• Es un concepto multidimensional, referido a muchas cualidades.

• Está ligada a restricciones (por ejemplo, el presupuesto).

• Está ligada a compromisos aceptables (por ejemplo, plazos de fabricación).

• No es ni totalmente subjetiva ni objetiva.

Puede resultar transparente cuando está presente y reconocible cuando está ausente.

Actualmente, la calidad del SW debe tenerse en cuenta a dos niveles:

• A nivel de empresa: para conseguir software de calidad, las organizaciones deben tener una estructura organizativa apropiada para fomentar el trabajo por la calidad de todas las personas y departamentos de la empresa, además de fomentar procesos específicos para asegurar la calidad.

• A nivel de proyecto: se trata de llevar a la práctica en las actividades cotidianas las disposiciones fijadas en el sistema de calidad. Se aplica durante todo el proceso de ingeniería del software, es decir, en Análisis, Diseño, Codificación y Prueba

Ingeniería Del Software

La Ingeniería del Software es una disciplina que integra métodos, técnicas y herramientas para el desarrollo de software de computadora.

Rol del Analista de Sistemas.

ROL DEL ANALISTA DE SISTEMA

PRINCIPIOS DEONTOLOGICOS DEL ANALISTA.

El Código contiene ocho Principios clave, relacionados con el comportamiento y las decisiones tomadas por los ingenieros del software profesionales, tanto si son profesionales en ejercicio, educadores, gestores, directivos y responsables, como si se trata de educandos y estudiantes. Los Principios identifican las diferentes relaciones en las que los individuos, grupos y organizaciones participan, y las principales obligaciones de tales relaciones. Las Cláusulas de cada Principio son la imagen de los diferentes niveles de obligación incluidos en esas relaciones. Estas obligaciones se fundamentan en las características humanas del ingeniero del software, en el especial cuidado al que está obligado con las personas que se ven afectadas por su trabajo y en los elementos peculiares de la práctica de la ingeniería del software. El Código prescribe estas exigencias como obligaciones de cualquiera que se identifique como ingeniero del software o que aspire a serlo.

Citando el código ético se tendría que:

1. Los Analistas actuarán en armonía con el interés público.

Este principio, referente a la calidad de vida de todas las personas, declara una obligación para proteger los derechos humanos fundamentales y respetar la diversidad de todas las culturas. Un objetivo esencial de los profesionales de la informática es minimizar las consecuencias negativas de los sistemas informáticos, incluyendo las amenazas a la salud y a la seguridad. Cuando se diseñen o instalen sistemas, los profesionales de la informática deben intentar garantizar que los productos de sus esfuerzos se utilizarán de modos socialmente responsables, recogerán las necesidades sociales y evitarán efectos perjudiciales a la salud y al bienestar.

2. Los Analistas desarrollarán sus actividades de la mejor forma que les permita conseguir que los intereses de sus Clientes, Empresas y Organizaciones que les emplean, estén en armonía con el interés público.

La excelencia es quizá la obligación más importante de un profesional. El profesional de la informática debe esforzarse para conseguir calidad y ser consciente de las graves consecuencias negativas que pueden resultar de la pobre calidad de un sistema.

3. Los Analistas garantizarán que sus análisis y las modificaciones que precisen los llevan a cabo utilizando los estándares de su profesión con la mayor amplitud.

La honestidad es un componente esencial de la confianza. Sin confianza una organización no puede funcionar con efectividad. El informático honesto no hará falsas o engañosas declaraciones acerca de un sistema o diseño de sistema, sino que, por el contrario, proporcionará una completa exposición de todas las limitaciones y problemas pertinentes del sistema.

Un profesional informático tiene la obligación de ser honesto acerca de sus propias cualificaciones, y acerca de cualquier otra circunstancia que pueda generar conflictos de interés.

El trabajo profesional de calidad, especialmente en informática, depende de la crítica y revisión profesional. Siempre que sea adecuado, se debe buscar y utilizar revisiones detalladas, así como proporcionar revisiones críticas del trabajo de otros.

4. Los Analistas mantendrán su integridad e independencia en sus juicios y dictámenes profesionales.

Los valores de igualdad, tolerancia, respeto a los demás y los principios justicia equitativa gobiernan este mandato. La discriminación basada en la raza, sexo, religión, edad, discapacidad, nacionalidad, u otros factores es una violación expresa de la política de la ACM y no se tolerará.

Las desigualdades entre diferentes grupos de personas pueden ser resultado del buen o mal uso de la información y de la tecnología. En una sociedad justa, todos los individuos tienen igual derecho a participar o beneficiarse del uso de los recursos informáticos sin distinción de raza, sexo, religión, edad, discapacidad, nacionalidad u otros factores similares. Sin embargo, estos ideales no justifican el uso no autorizado de recursos informáticos ni proporcionan una base adecuada para trasgredir cualquier otro mandato ético de este código.

5. Los Analistas que además desempeñan actividades como gestores ó líderes, promoverán y garantizarán que en la gestión del desarrollo y mantenimiento del software que lideran se siguen criterios éticos.

Los profesionales de la informática deben esforzarse en ser perceptivos, meticulosos y objetivos cuando evalúen, recomienden y presenten descripciones de sistemas y sus alternativas. Los informáticos están en una posición de especial relevancia, y tienen, por tanto, la responsabilidad especial de proporcionar evaluaciones objetivas y creíbles a los superiores, clientes, usuarios y público en general. Cuando se hagan evaluaciones se deben identificar los posibles conflictos de interés.

La dirección de la organización es responsable de garantizar que los sistemas informáticos mejoran, no degradan, la calidad de la vida laboral. Cuando se instale un sistema informático, las organizaciones deben considerar el desarrollo personal y profesional, la seguridad física y la dignidad humana de todos los trabajadores. En el diseño del sistema y del lugar de trabajo deben tenerse en cuenta los estándares apropiados de ergonomía persona-ordenador.

Las oportunidades educativas son esenciales para facilitar la óptima participación de todos los miembros de la organización. Las oportunidades deben estar abiertas a todos los miembros para ayudarles a mejorar su conocimiento y capacidades en informática, incluyendo cursos que los familiaricen con las consecuencias y limitaciones de sistemas concretos. En particular, los profesionales deben ser conscientes de los peligros de la construir sistemas mediante modelos demasiado simplificados, la incertidumbre de anticipar y de diseñar para cada condición de operación posible, y otros temas relacionados con la complejidad de esta profesión.

6. Los Analistas mantendrán en todas sus actuaciones profesionales la integridad y reputación de la profesión, cumpliendo las normas de los acuerdos internacionales y leyes informáticas que afectan al ejercicio de su profesión y garantizan el interés público.

Respetar las obligaciones contraídas es una cuestión de integridad y honestidad. Para el informático esto incluye garantizar que los elementos del sistema funcionan tal como se esperaba. También cuando se trabaja como subcontrata se está obligado a informar al contratante sobre el estado del trabajo.

Un profesional de la informática tiene la responsabilidad de solicitar un cambio en cualquier asignación que prevea no poder terminar tal como se había definido. Sólo debe aceptarse una tarea después de una cuidadosa consideración y un completo examen de los riesgos y peligros para el contratante o cliente. El primer principio subyacente en este caso es la obligación de aceptar una responsabilidad personal por un trabajo profesional. En algunas ocasiones otros principios éticos pueden tener mayor prioridad.

Puede no aceptarse un juicio de valor sobre si una tarea concreta no debe realizarse. Después de haber identificado las razones para tal opinión, pero sin poder efectuar cambios en la tarea asignada, uno puede estar obligado por contrato o por ley a continuar el trabajo como se había indicado. El criterio ético del profesional es la guía final para decidir si continuar o no. Cualquiera que sea la decisión uno debe aceptar la responsabilidad de las consecuencias. Sin embargo, realizar tareas "en contra de la opinión personal" no excusa al profesional de la responsabilidad de cualquier efecto negativo.

7. Los Analistas actuarán con lealtad y defenderán a sus compañeros profesionales.

La adhesión de los profesionales a un código de ética es principalmente una cuestión voluntaria.

El futuro de la profesión informática depende de la excelencia técnica y ética.

8. Durante el desarrollo de su vida profesional, los Analistas se preocuparán por mantener actualizados sus conocimientos y prácticas profesionales y promoverán la actuación ética en la práctica de la profesión.

La excelencia depende de los individuos que asumen la responsabilidad de conseguir y mantener su competencia profesional. Un/a profesional debe participar en la definición de los estándares para los diferentes niveles de capacitación, y debe esforzarse para alcanzarlos. La actualización del conocimiento técnico y la aptitud profesional se pueden conseguir de diferentes maneras: mediante estudio individual, asistiendo a seminarios, conferencias o cursos, e involucrándose en organizaciones profesionales

Introducción al Ciclo de Vida de Sistemas

INTRODUCCIÓN AL CICLO DE VIDA DE SISTEMAS.

FASES DEL CICLO DE VIDA

Planeación: La función de la planeación “pretende señalar y establecer prioridades sobre aquellas tecnologías y aplicaciones que producirán un máximo beneficio para la organización” (Whitten; Benthley y Barlow, 1996).El objetivo de esta fase consiste en la elaborar junto con el equipo humano de la organización donde se va a implementar el sistema, los objetivos generales, específicos y los esquemas generales de la manera más clara y precisa. En esta fase se debe responder a preguntas como: Cuáles son los objetivos que deberá cumplir en SIG?; Cuáles son las necesidades de la organización que deben resolverse? .

Se debe realizar un levantamiento completo de requerimientos teniendo en cuenta el Flujo de la Información con que se trabaja en la organización o las áreas que se desea sistematizar mediante un SIG. Se debe documentar el proceso mediante Diagrama de Flujo de Datos. Quienes son los usuarios del sistema y sus necesidades? Se debe identificar los usuarios internos y potenciales de la información institucional, empresarial o del proyecto; que gestionará el sistema. Cuál es la información y los datos que usan y generan en la organización para desarrollar sus funciones? Cuáles son los productos esperados del sistema? Se debe conocer cuáles son los productos esperados del sistema dependiendo del tipo de usuario. Se deben establecer prioridades respecto a los productos. Cuál es el alcance del sistema? Se debe identificar si el alcance es local, regional, nacional o global. El nivel define la escala o resolución de los datos necesarios para alimentar el sistema.

Análisis: El Analista de Sistemas es imprescindible en cualquier organización, debido al abanico de destrezas que éste posee y los beneficios que le produce. Se encarga no sólo estudiar la organización y desarrollar un sistema automatizado, es más que eso, la labor del analista de sistemas es también la de asesorar, supervisar, recomendar y modificar procesos internos y algunas veces de modificar la estructura misma de la empresa, con el propósito de lograr los objetivos que se proponen. Todo desarrollo líderizado o no por un analista de sistemas posee fases que pueden dividirse lógica en elementos discretos pero, que innegablemente son continuos, de alguna manera cíclica. Este conjunto de fases son conocidas como el Ciclo de Vida de Desarrollo de Sistemas, herramienta fundamental para el desempeño de un analista de sistemas.

El análisis y diseño de sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de manejarla con métodos y procedimientos más adecuados." (Senn, 1992, p.11). Se puede dividir en dos: el análisis de sistemas que comprende la planificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema; y el diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable. En pocas palabras; "El análisis especifica qué es lo que el sistema debe hacer. El diseño establece cómo alcanzar el objetivo" (op. cit., p.13) Ciertamente, todo sistema de información debe presentar salidas en base a entradas de datos y procesos, lo que nos dice que si deseamos entender todo lo que le ocurre a los datos antes de llegar al usuario como información –Es decir antes de ser interpretado por el usuario final- debemos utilizar metodologías que permiten ver los sistemas en base a sus procesos, por lo menos en sistemas de procesado por lotes o secuencial. Un ejemplo de ello es la metodología estructurada. Existen muchas metodologías pero esta es la más arraigada debido a su antigüedad. Recordemos que hace apenas dos décadas los computadores no soportaban el multitas King (procesamiento multitarea), lo que limitaba a procesar una pantalla a la vez, esto sólo permitía sistemas secuenciales donde cada tarea en procesamiento comenzaba cuando la anterior ya había terminado por completo. Diseño “Evalúa las soluciones alternativas y específica una solución detallada de tipo informático” (Whitten; Benthley y Barlow, 1996). Fases del Diseño (Whitten; Benthley y Barlow, 1996): Elección de una solución de diseño entre las soluciones candidatas. Estas soluciones se evalúan con los siguientes criterios: Viabilidad técnica, operativa, económica, en tiempo. Evaluación del hardware y software requeridos Diseño e Integración del nuevo sistema. Diseño General. El método comúnmente utilizado es la modelización (acto de elaborar una o más representaciones gráficas del sistema).

Los modelos de diseño general describen:

La estructura de los archivos y las bases de datos (diagrama de estructuras de datos)- Los métodos y procedimientos de proceso (diagrama de flujo)- La estructura de la red informática (diagrama de flujo) Diseño Detallado. Se divide en:

Diseño Externo. (Conjunto de especificaciones de la interfaz del sistema con sus usuarios incluyen entradas, consultas, salidas, diseño de ventanas y transición entre ventanas.

Diseño Interno. Especificaciones de aplicación del sistema, los archivos, diseño de la base de datos. “En esta etapa es necesario elaborar un modelo de datos que estructure el SIG, definir la verificación y control de calidad de los datos, seleccionar las capas de información por áreas de trabajo, estructurar la base de datos espacial y temática y concretar todos los procesos que soportará el SIG. Igualmente en ésta etapa se definen los programas y equipos para el SIG, de tal manera que satisfagan los requerimientos”.

Implantación. Es la construcción del nuevo sistema y el paso de dicho sistema a “producción” (funcionamiento diario)”. (Whitten; Benthley y Barlow, 1996). Se le conoce también como desarrollo pero se confunde con el ciclo de vida completo del sistema de información.

Fases de Implantación:

-. Probar las redes y las bases de datos

.-Construcción y prueba de las aplicaciones

.- Instalación y prueba del nuevo sistema

.- Entrega del sistema para puesta en funcionamiento

Pruebas. A través de esta fase se conoce en realidad los resultados del sistema. Los criterios de evaluación son la precisión, la calidad y los productos esperados. Las pruebas son un proceso cíclico que debe dar como resultado el cumplimiento de los objetivos propuestos.

PARADIGMAS DEL CICLO DE VIDA

El ciclo de vida clásico es el más viejo y más ampliamente usado paradigma en la ingeniería de software. Sin embargo con el paso de unos cuantos años se han producido criticas al paradigma, incluso por seguidores activos que cuestionan su aplicabilidad a todas las situaciones. Entre los problemas que se presentan algunas veces cuando se aplica este paradigma se encuentran:

1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre ocurre iteraciones y se crea problemas en la aplicación del paradigma.

2. Normalmente es difícil para el cliente establecer explícitamente el principio todos los requerimientos del sistema. El ciclo de vida clásico requiere esto y tiene dificultades para acomodar posibles incertidumbres que puedan existir al comienzo de dichos proyectos.

3. El cliente debe tener paciencia. Una versión funcional del programa no está disponible hasta las etapas finales del desarrollo del proyecto. Un error importante no detectado hasta que el programa esté en funcionamiento puede ser desastroso.

4. Los responsables del desarrollo se retrasan innecesariamente.

TÉCNICAS DEL CICLO DE VIDA

Es un procedimiento para realizar alguna parte significativa del Ciclo de  Vida  de  Desarrollo  de  Sistemas.  Se  han  desarrollado  muchas Técnicas,  por  ejemplo  para  la  definición  de requerimientos, para diseño de BD, para diseño computacional de aplicaciones,  para  diseño de  programas,  para  desarrollo  de  pruebas  de  implantación,  para Prototipos, y muchas más.

Para  Edward  Yourdon, las técnicas son procedimientos similares a las recetas de un "Libro de Cocina" que ayudan a los  profesionales  a  ir desde  una  hoja  de  papel  (pantalla), a un bien organizado modelo o diseño relacionado a un sistema o componente del mismo

HERRAMIENTAS DEL CICLO DE VIDA

Las  técnicas  utilizan  a  menudo una variedad de herramientas que se desarrollan para tal fin;  es  decir,  una  herramienta  es  cualquier recurso  particular  a disposición de la metodología para realizar las operaciones que en ella se prevea. Estas generalmente están orientadas a:

Diagramas, como expresiones gráficas para modelar los requerimientos y la  arquitectura  del  sistema  de información o componente del mismo. Entre los más usados tenemos:

   

-   Diagrama de Flujo de Datos (Data Flow Diagram)

-   Diagrama de Entidad Relación (Entity Relation Diagram)

-   Diagrama  de  Descomposición  Funcional (Functional Decomposition Diagram)

-   Diagramas para O-O (de clases, de objetos, etc.)

   

Formatos, que corresponden a documentos estandarizados para  facilitar la documentación y comunicación.

Sistemas de Información

SISTEMAS DE INFORMACIÓN

INFORMACIÓN: 

     Es un conjunto organizado de datos procesados, que constituyen un mensaje que cambia el estado de conocimiento del sujeto o sistema que recibe dicho mensaje.

CONCEPTUALIZACIÓN DE  SISTEMA DE INFORMACIÓN (S.I.): 

     Un sistema de información es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo. Dichos elementos formarán parte de alguna de las siguientes categorías:

• Personas

• Datos

• Actividades o técnicas de trabajo

• Recursos materiales en general (generalmente recursos informáticos y de comunicación, aunque no necesariamente).

Todos estos elementos interactúan para procesar los datos (incluidos los procesos manuales y automáticos) y dan lugar a información más elaborada, que se distribuye de la manera más adecuada posible en una determinada organización, en función de sus objetivos.

Habitualmente el término se usa de manera errónea como sinónimo de sistema de información informático, en parte porque en la mayoría de los casos los recursos materiales de un sistema de información están constituidos casi en su totalidad por sistemas informáticos. Estrictamente hablando, un sistema de información no tiene por qué disponer de dichos recursos (aunque en la práctica esto no suela ocurrir). Se podría decir entonces que los sistemas de información informáticos son una subclase o un subconjunto de los sistemas de información en general.

ACTIVIDADES DE SISTEMA DE INFORMACIÓN (S.I.)

Entradas:
• Datos generales del cliente: nombre, dirección, tipo de cliente, etc.
• Políticas de créditos: límite de crédito, plazo de pago, etc.
• Facturas (interfaces automático).
• Pagos, depuraciones, etc.
Proceso:
• Cálculo de antigüedad de saldos.
• Cálculo de intereses moratorios.
• Cálculo del saldo de un cliente.
Almacenamiento:
• Movimientos del mes (pagos, depuraciones).
• Catálogo de clientes.
• Facturas.
Salidas:
• Reporte de pagos.
• Estados de cuenta.
• Pólizas contables (interfaces automática)
• Consultas de saldos en pantalla de una terminal

ELEMENTOS DE LOS SISTEMAS DE INFORMACIÓN

Los componentes más importantes de un sistema de información son los siguientes:

• Financieros. Es el aspecto económico que permite la adquisición, contratación y mantenimiento de los demás recursos que integran un sistema de información.

• Administrativos. Es la estructura orgánica de objetivos, lineamientos, funciones, procedimientos, departamentalización, dirección y control de las actividades; que sustenta la creación y uso de los sistemas.

• Humanos. Está compuesto por dos grupos:

1. El técnico, que posee los conocimientos especializados en el desarrollo de sistemas, siendo estos los: Administradores, Líderes de Proyecto, Analistas, Programadores, Operadores y Capturistas.

2. El usuario, representado por las personas interesadas en el manejo de información vía cómputo, como apoyo al mejor desempeño de sus actividades, siendo estos los: Funcionarios, Contadores, Ingenieros, Empleados, Público, etc.

• Materiales. Son aquellos elementos físicos que soportan el funcionamiento de un sistema de información, por ejemplo: local de trabajo, instalaciones eléctricas y de aire acondicionado, medios de comunicación, mobiliario, maquinaria, papelería, etc.

• Tecnológicos. Es el conjunto de conocimientos, experiencias, metodologías y técnicas; que orientan la creación, operación y mantenimiento de un sistema.

DIFERENTES TIPOS DE SISTEMAS DE INFORMACIÓN:

• Procesamiento de transacciones: Un sistema de procesamiento de transacciones (TPS por sus siglas en inglés) es un tipo de sistema de información que recolecta, almacena, modifica y recupera toda la información generada por las transacciones producidas en una organización. Una transacción es un evento que genera o modifica los datos que se encuentran eventualmente almacenados en un sistema de información. Para que un sistema informático pueda ser considerado como un TPS, este debe superar el test ACID.

• Automatización de oficinas: Los sistemas de automatización de oficinas, también llamados OAS por sus siglas en inglés (Office Automation Systems) consisten en aplicaciones destinadas a ayudar al trabajo diario del administrativo de una organización, forman parte de este tipo de software los procesadores de textos, las hojas de cálculo, los editores de presentaciones, los clientes de correo  electrónico, etc. Cuando varias de estas aplicaciones se agrupan en un mismo paquete de software para facilitar su distribución e instalación, al conjunto se le conoce con el nombre de suite ofimática.

• Soporte gerencial: Estos sistemas son el resultado de interacción colaborativa entre personas, tecnologías y procedimientos -colectivamente llamados sistemas de información- orientados a solucionar problemas empresariales. Los SIG o MIS (también denominados así por sus siglas en inglés) se diferencian de los sistemas de información comunes en que para analizar la información utilizan otros sistemas que se usan en las actividades operacionales de la organización. Académicamente, el término es comúnmente utilizado para referirse al conjunto de los métodos de gestión de la información vinculada a la automatización o apoyo humano de la toma de decisiones (por ejemplo: Sistemas de apoyo a la decisión, Sistemas expertos y Sistemas de información para ejecutivos).

• Sistemas en línea: Un sistema en línea es aquel que siempre debe estar encendido, disponible y generalmente conectado a una red de computadoras y depende de la capacidad del hardware para atender peticiones de servicio y en ningún momento está en sincronía con el mundo real ni tiene restricciones temporales. En adición a esto, un sistema fuera de línea es aquel que no siempre está disponible para recibir y enviar información y que depende de una base de datos previamente establecida para ejecutar su cometido. Como ejemplos de sistemas en línea se tienen las aplicaciones de Internet como los navegadores web o la adquisición de datos a través de una tarjeta especializada en un ambiente de tiempo compartido como Windows.

• Sistemas Expertos o de inteligencia artificial: Los sistemas expertos utilizados en inteligencia artificial son software que emula el comportamiento de un experto humano en la solución de un problema. Los sistemas expertos funcionan de manera que almacenan conocimientos concretos para un campo determinado y solucionan los problemas, utilizando esos conocimientos, mediante deducción lógica de conclusiones. Con ellos se busca una mejora en calidad y rapidez de respuestas dando así lugar a una mejora de la productividad del experto.

• Sistemas colaborativos: Son sistemas basados en computadoras que soportan grupos de personas involucradas en una tarea común (u objetivo) y que proveen una interfaz a un ambiente compartido. Los sistemas colaborativos, desde este punto de vista, se validan las interacciones sociales, como también la visión de que el aporte de dos o más individuos que trabajan en función de una meta común, puede tener como resultado un producto más enriquecido y acabado que la propuesta de uno sólo, esto motivado por las interacciones, negociaciones y diálogos que dan origen al nuevo conocimiento. Vemos también que el aprender es un proceso dialéctico y dialógico en el que un individuo contrasta su punto de vista personal con el de otro hasta llegar a un acuerdo. Ese otro, también puede ser un “sí mismo”, de esta forma incluimos el Dialogo íntimo y personal con uno mismo, esto se debe incluir en este teme por la importancia que lleva a cabo en la colaboración.

• Agentes inteligentes: Un agente inteligente, es una entidad capaz de percibir su entorno, procesar tales percepciones y responder o actuar en su entorno de manera racional, es decir, de manera correcta y tendiendo a maximizar un resultado esperado. En este contexto la racionalidad es la característica que posee una elección de ser correcta, más específicamente, de tender a maximizar un resultado esperado. Este concepto de racionalidad es más general y por ello más adecuado que inteligencia (la cual sugiere entendimiento) para describir el comportamiento de los agentes inteligentes. Por este motivo es mayor el consenso en llamarlos agentes racionales.

• Sistemas multimedia: En un soporte exterior anti vandálico, que crea una zona de cobertura generada por un sistema informático que permite el envío gratuito de mensajes a móviles equipados con sistema bluetooth (99% de los dispositivos actuales). Estos mensajes pueden ser multimedia, con la información solicitada por el usuario. Los usuarios pueden recibir información sobre rutas, destinos, ofertas, ferias, noticias, novedades, promociones, horarios, concursos, eventos, etc. A una distancia que oscila entre los 10 y 100 m de alcance desde el centro emisor. Los mensajes se emiten de forma automática los 365 días y las 24 horas programadas y convierten a sus receptores en centros emisores que a su vez pueden intercambiarlos con otros usuarios que no están físicamente dentro de la zona de cobertura y ser empleados por varios usuarios al mismo tiempo.

• Sistemas geográficos: Un sistema de información geográfico (sig) particulariza un conjunto de procedimientos sobre una base de datos no gráfica o descriptiva de objetos del mundo real que tienen una representación gráfica y que son susceptibles de algún tipo de medición respecto a su tamaño y dimensión relativa a la superficie de la tierra. A parte de la especificación no gráfica el sig cuenta también con una base de datos gráfica con información geo referenciada o de tipo espacial y de alguna forma ligada a la base de datos descriptiva. La información es considerada geográfica si es mesurable y tiene localización.

IMPORTANCIA DE LOS SISTEMAS DE INFORMACIÓN S.I

Cuando muchas personas se preguntan por qué estudiar sobre los sistemas de información, es lo mismo que preguntar por qué debería estudiar alguien contabilidad, finanzas, gestión de operaciones, marketing, administración de recursos humanos o cualquier otra función empresarial importante. Lo que si les puedo asegurar es que muchas empresas y organizaciones tienen éxitos en sus objetivos por la implantación y uso de los sistemas de información. De esta forma, constituyen un campo esencial de estudio en administración y gerencia de empresas. Es por esta razón que todos los profesionales en el área de administración de empresas deberían o más bien deben, tomar un curso de sistemas de información. Por otro lado es importante tener una comprensión básica de los sistemas de información para entender cualquier otra área funcional en la empresa, por eso es importante también, tener una cultura informática en nuestras organizaciones que permitan y den las condiciones necesarias para que los sistemas de información logren los objetivos citados anteriormente. Muchas veces las organizaciones no han entrado en la etapa de cambio hacía la era de la información sin saber que es un riesgo muy grande de fracaso debido a las amenazas del mercado y su incapacidad de competir, por ejemplo, las ti que se basan en internet se están convirtiendo rápidamente en un ingrediente necesario para el éxito empresarial en el entorno global y dinámico de hoy. Roles del analista de sistemas: El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio mediante el examen de la entrada y el procesamiento de datos y su consiguiente producción de información, con el propósito de mejorar los procesos de una organización. Muchas mejoras incluyen un mejor apoyo a las funciones de negocios a través del uso de sistemas de información computarizados. Esta definición pone énfasis en un enfoque sistemático y metódico para analizar- y en consecuencia mejorar- lo que sucede en el contexto específico creado por un negocio. Nuestra definición de analista de sistema es amplia. El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadora. El analista desempeña diversos roles, en ocasiones varios de ellos al mismo tiempo. Los tres roles principales del analista de sistemas son el de consultor, experto en soporte técnico y agente de cambio.

APLICACIONES DE LAS TECNOLOGÍAS DE LA INFORMACIÓN A LOS SISTEMAS DE INFORMACIÓN S.I

El Sistema de información (SI), se empareja con las tecnologías de la información (TI) pos ser un sistema dinámico. Las TI nos sirven para construir los SI y son la herramienta básica para diseñar los SI.

El SI es un proceso de planificación diseño y análisis y control de los datos, que afecta a todo el núcleo de la actividad empresarial y es el encargado de coordinar los flujos y registros de la información tanto internas, como la proveniente del entorno, que son necesarias para realizar las operaciones básicas y toma de decisiones para conseguir los objetivos de la empresa. Este proceso de actividades propias de la empresa y sirve de apoyo a las decisiones de planificación, diseño, ejecución y control que realiza.