DIAGRAMA DE CLASES

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

• Clases: Patrón o modelo a crear objetos
• Atributos: Características de la clase
• Visibilidad: Publica (+), Privada (-), Protegida (#), Paquete (~)
• Interfaz: clases que definen un juego de operaciones externas accesibles pero sin métodos. 
   

Herencia: permite organizar las definiciones de la clase para simplificar y facilitar su implementación.

Asociación: es un término formal para un tipo de relación.

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

Actor: Algo con comportamiento, como una persona, un sistema de computo , una organización, etc. Ej.: Un cajero

Escenario: Una secuencia dada de acciones e interacciones entre actores y el sistema involucrado. Ej.. Retiro exitoso de un cajero automática.

Casos de uso: Un conjunto compuesto de escenarios exitosos y fallidos que están interrelacionados entre si, y describen el uso que los actores le  dan a un sistema para lograr una meta. Exite 3 tipos, estos son:

• Resumidos: Normalmente de un párrafo y solo contienen el escenario principal
• Casuales: Uno o pocos párrafos escritos  de forma informal
• Completos: Son mas  elaborados. Todos los pasos y sus variantes son detalladas

Diagramas de Casos de Uso: El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Relaciones del diagrama de casos de uso:

• Arco de comunicación – Asociación: camino de comunicación entre un actor y un caso de uso.
• Incluye: Indica que un caso de uso es incluido en otro. Normalmente ocurre cuando unos casos de uso comparten unos pasos comunes. El caso de uso incluido es el factor común del comportamiento compartido.
• Generalización: Indica que un caso de uso es una variante de otro. El caso de uso especializado puede variar cualquier aspecto del caso de uso base.
• Extiende: El caso de uso base declara un conjunto de puntos de extensión. El caso de uso especializado solo puede alterar el comportamiento de los puntos de extensión marcados.

PROCESO UNIFICADO

Unificación de tres metodologías de desarrollo basadas en el paradigma orientado a objetos. Es un conjunto de actividades para transformar los requisitos de usuario en un sistema software, Basado en componentes interconectados a través de interfaces.

Características:

• Dirigido por casos de uso: Conducen el proceso de desarrollo, los desarrolladores crean modelos de diseño e implementación que realizan los casos de uso 

• Centrado en la arquitectura: Es una vista del diseño completo que hace visibles las características principales. En este se crear una arquitectura inicial donde no específica de los casos de uso.

• Iterativo e incremental: Una iteración produce un incremento donde cada fase e iteración se centra en disminuir algún riesgo y concluye con un hito bien definido, todas las iteraciones son planificadas y controladas.

Ideas: Cualquier interacción del sistema con el usuario es un caso de uso

Actor: alguien o algo

Caso de uso: Es una función del sistema que da al usuario un resultado útil, es este el que captura los requisitos funcionales.

Las 4 "P"

• Proyecto: Elemento organizativo a través del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versión de un producto.
• Proceso:  Un proceso de ingeniería de software es una definición del conjunto de actividades necesarias para transformar los requisitos de usuario en un producto.  Un proceso es una plantilla para crear proyectos.
• Producto: Artefactos que se crean durante la vida del proyecto, como los modelos, código fuente, ejecutables, y documentación.  El resultado de llevar a cabo un proceso software dentro de un proyecto concreto.
• Personas: Los principales autores de un proyecto de software son loas arquitectos, desarrolladores, ingenieros de prueba y el personal de gestión que les da soporte, además de los usuarios, clientes, y otros interesados. Las personas son realmente seres humanos, a diferencia del termino abstracto “trabajadores” 

Estructura del PU : Fases e iteraciones

Fase: intervalo de tiempo entre dos hitos importantes del proceso durante el cual se cumple un conjunto bien definido de objetivos, se completan artefactos y se toman 

decisiones sobre si pasar a la siguiente fase. 

4 fases: 

•  Iniciación (inception): Establecer la visión, el alcance y el plan inicial del proyecto. 
•  Elaboración (elaboration): Diseñar, implementar y probar una arquitectura correcta, y completar el plan del proyecto. 
•  Construcción (construction): Desarrollar el sistema (construir la primera versión operativa). 
•  Transición (transition): Proporcionar el sistema a sus usuarios finales. 

Iteración: representa un ciclo de desarrollo completo, desde la captura de requisitos en el análisis hasta la implementación y pruebas, que produce una versión (interna o externa) de un 

producto ejecutable, que constituye un subconjunto del producto final en desarrollo. 

Iteración genérica (similar al modelo en cascada): 

•  Planificación
•  Flujos de trabajo fundamentales: requisitos, análisis, diseño, implementación y pruebas
•  Evaluación 

FASES GENERICAS DEL CICLO DE VIDA DEL SOFTWARE 

• Analisis
• Diseño
• Codificacion
• Pruebas
• Puesta marcha
• Mantenimiento

"INGENIERÍA DE REQUISITOS"

1. Reconocimiento de los requisitos o levantamiento

• Entrevistas (abiertas, cerradas)
• Lluvia de ideas
• Delphi

2. Documentos especificos

• Validar (cliente)

REQUERIMIENTOS FUNCIONALES

Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer.

Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización al redactar requerimientos.

REQUERIMIENTOS NO FUNCIONALES

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema. Como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema.

ATRIBUTOS DE LA CALIDAD

• Disponibilidad: hace referencia a la posibilidad de que algo, un producto o un fenómeno, esté disponible de ser realizado, encontrado o utilizado.

• Confiabilidad: se puede definir como la probabilidad en que un producto realizará su función prevista sin incidentes por un período de tiempo especificado y bajo condiciones indicadas.

• Escalabilidad: La escalabilidad es la capacidad de mejorar recursos para ofrecer una mejora (idealmente) lineal en la capacidad de servicio. La característica clave de una aplicación es que la carga adicional sólo requiere recursos adicionales en lugar de una modificación extensiva de la aplicación en sí.

• Seguridad: Propiedad de un sistema contra el acceso, modificación o destrucción no autorizada de información.

• Seguro: Grado de confianza con el que un sistema es utilizado sin que ocasione accidentes.

• Mantenibilidad: Aptitud para permitir reparaciones y evolución. La facilidad con la que un sistema o componente software puede ser modificado para corregir fallos, mejorar su funcionamiento u otros atributos o adaptarse a cambios en el entorno.

• Usabilidad: Está vinculada, a la simpleza, la facilidad, la comodidad y la practicidad. En otras palabras, la noción tiene relación con la eficacia percibida de un objeto y la posibilidad de aprovechar todo su potencial.

• Potabilidad: Habilidad del software para adaptarse a cambios en el ambiente o los requerimientos.

• Modificabilidad: Se refiere al desarrollo de software flexible para adecuarse a cambios para extender, cambiar o eliminar funcionalidades del sistema.

• Rendimiento: Se refiere a la proporción que surge entre los medios empleados para obtener algo y el resultado que se consigue.

• Desempeño: Grado en el cual un sistema o componente cumple sus funciones dentro de restricciones dadas tales como velocidad, exactitud, o uso de memoria. Tiempo requerido para responder a un evento específico.

• Eficiencia: Utilización de recursos del sistema para cumplir con su funcionalidad.

Crisis del Software:

Se fundamentó en el tiempo de creación de software, ya que en la creación del mismo no se obtenían los resultados deseados, además de un gran costo y poca flexibilidad.

Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas son, entre otras, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios.

Ciclos de Vida del Software:

Describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

• Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
• Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
• Diseño general: requisitos generales de la arquitectura de la aplicación.
• Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
• Programación (programación e Implementación): es la Implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
• Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
• Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
• Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
• Implementación
• Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

Modelo en cascada:

El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:

Ventajas del modelo cascada:

1. Modelo y planificación fácil y sencillos.

2. Sus fases son conocidas por los desarrolladores.

3. Los usuarios lo pueden comprender fácilmente.

Desventajas del modelo cascada:

1. Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño.

2. Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida.

Modelo Espiral:

Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.

El modelo en espiral fue desarrollado por Boehm, quien lo describe así:

El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.

Se caracteriza principalmente por:

• Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
• Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

El modelo espiral captura algunos principios básicos:

•  Decidir qué problema se quiere resolver antes de viajar a resolverlo.
•  Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
•  Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
•  No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
• Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.

Método:

• Proceso o camino sistemático establecido para realizar una tarea o trabajo con el fin de alcanzar un objetivo predeterminado.
•  Modo de decir o hacer algo con orden.  Procedimiento científico seguido en la ciencia para hallar la verdad.
•  Un  procedimiento que se usa para realizar una tarea específica en la clase o módulo.
• Procedimiento para alcanzar algo que se adopta para enseñar o educar.

Procedimiento:

• Sucesión cronológica de operaciones concatenadas entre sí, que se constituyen en una unidad de función para la realización de una actividad o tarea específica dentro de un ámbito predeterminado de aplicación. 
• Todo procedimiento involucra actividades y tareas del personal, determinación de tiempos de métodos de trabajo y de control para lograr el cabal, oportuno y eficiente desarrollo de las operaciones.
• Un método, función o propiedad de una clase o módulo.

Herramienta:

Subprograma o módulo encargado de funciones específicas y afines entre sí para realizar una tarea.

Framework  :

(plataforma, entorno, marco de trabajo) Es  un framework es una estructura de soporte definida, en la cual otro proyecto de software puede ser organizado y desarrollado.

Los frameworks suelen incluir:

• Soporte de programas.
• Bibliotecas.
• Lenguaje de scripting.
• Software para desarrollar y unir diferentes componentes de un proyecto de desarrollo de programas.

Los frameworks permiten:

• Facilitar el desarrollo de software.
• Evitar los detalles de bajo nivel, permitiendo concentrar más esfuerzo y tiempo en identificar los requerimientos de software.

Herramientas CASE de Cuarta Generación

Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. Como es sabido, los estados en el Ciclo de Vida de desarrollo de un Software son: Investigación Preliminar, Análisis, Diseño, Implementación e Instalación.

Lenguajes de Cuarta Generación (4GL):

Los lenguajes de cuarta generación son entornos de desarrollo de aplicaciones constituidos por herramientas, tales como compiladores, editores, sistemas  de acceso a bases de datos, etc. Por lo general, estas herramientas funcionan sobre sistemas gestores de bases de datos específicos, aunque cabe resaltar, que las capacidades otorgadas por las herramientas 4GL son mucho mejores que las facilidades que nos ofrecen los SGBD, con lo que podemos desarrollar potentes y eficientes entornos de desarrollo de aplicaciones.

Los principales objetivos de los 4GL son:

1. Acelerar el proceso de construcción de aplicaciones.

2. Crear aplicaciones fáciles y rápidas de mantener, reduciendo así el costo de mantenimiento.

3. Minimizar los problemas de depuración.

4. Capaz de generar código “libre de errores” a partir de expresiones de alto nivel de requerimientos.

5. Crear lenguajes fáciles de usar por el usuario.

Tipos de Lenguajes de Cuarta Generación:

Dentro los lenguajes de cuarta generación existen diferentes tipos, cada uno con una función en particular, esos tipos son:

1. Generadores de informes

2. Generadores de formularios

3. Ambientes de cuarta generación

4.  Administradores de datos

5.  Generadores de aplicaciones

Ventajas y desventajas de los lenguajes de cuarta generación:

·         Ventajas:

1.    Permiten elaborar programas en menor tiempo, lo que conlleva a un aumento de la productividad.

2.    El personal que elabora software sufre menos agotamiento, ya que generalmente requiere escribir menos.

3.    El nivel de concentración que se requiere es menor, ya que algunas instrucciones, que le son dadas a las herramientas, a su vez, engloban secuencias de instrucciones a otro nivel dentro de la herramienta.

4.    Cuando hay que dar mantenimiento a los programas previamente elaborados, es menos complicado por requerir menor nivel de concentración.

     Desventajas:

1.    Las herramientas prefabricadas generalmente son menos flexibles que los lenguaje de alto nivel

2.    Se crea dependencia de uno o varios proveedores externos, lo que se traduce en pérdida de autonomía. A menudo las herramientas prefabricadas contienen librerías de otros proveedores, que conlleva a instalar opciones adicionales que son consideradas opcionales. Los programas que se elaboran generalmente se ejecutan sólo con la herramienta que lo creó (a menos que existan acuerdos con otros proveedores).

3.    A menudo no cumplen con estándares internacionales ISO ANSI. Por este motivo invertir tiempo y dinero es un riesgo a futuro, porque no se sabe a ciencia cierta cuanto tiempo permanecerá la herramienta y su fabricante en el mercado.

Fuente: http://formacion.desarrollando.net/cursosFiles/Formacion/Curso_370/AdBD-05-03.pdf
              http://www.ongei.gob.pe/publica/metodologias/Lib5083/cap2041.HTM                             
              http://en.wikipedia.org/wiki/Fourth-generation_programming_language

Puntos de vista de Software

• Se denomina software (palabra de origen ánglico, pronunciada "sófuer"), programática, equipamiento lógico o soporte lógico a todos los componentes intangibles de una computadora, es decir, al conjunto de programas y procedimientos necesarios para hacer posible la realización de una tarea específica, en contraposición a los componentes físicos del sistema (hardware). Esto incluye aplicaciones informáticas tales como un procesador de textos, que permite al usuario realizar una tarea, y software de sistema como un sistema operativo, que permite al resto de programas funcionar adecuadamente, facilitando la interacción con los componentes físicos y el resto de aplicaciones.

• Se conoce como software al equipamiento lógico o soporte lógico de un sistema informático, el que comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos que son llamados hardware.
  Los componentes lógicos incluyen, entre muchos otros, las aplicaciones informáticas; tales como el procesador de texto, que permite al usuario realizar todas las tareas concernientes a la edición de textos; el llamado software de sistema, tal como el sistema operativo, que básicamente permite al resto de los programas funcionar adecuadamente, facilitando también la interacción entre los componentes físicos y el resto de las aplicaciones, y proporcionando una interfaz con el usuario.

• Probablemente la definición más formal de software es la atribuida a la IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) en su estándar 729: «la suma total de los programas de cómputo, procedimientos, reglas documentación y datos asociados que forman parte de las operaciones de un sistema de cómputo». Bajo esta definición, el concepto de software va más allá de los programas de cómputo en sus distintas formas: código fuente, binario o ejecutable, además de su documentación: es decir, todo lo intangible.

Categorías de Software:

El software puede distinguirse en tres categorías: software de sistema, software de programación y aplicación de software. De todas maneras esta distinción es arbitraria y muchas veces un software puede caer en varias categorías.

• Software de sistema:  ayuda a funcionar al hardware y a la computadora. Incluye el sistema operativo, controladores de dispositivos, herramientas de diagnóstico, servidores, sistema de ventanas, utilidades y más. Su propósito es evitar lo más posible los detalles complejos de la computación, especialmente la memoria y el hardware.
• Software de programación: provee herramientas de asistencia al programador. Incluye editores de texto, compiladores, intérprete de instrucciones, enlazadores, debuggers, etc.
• Software de aplicación: permite a los usuarios finales hacer determinadas tareas. Algunos software de aplicación son los navegadores, editores de texto, editores gráficos, antivirus, mensajeros, etc.

Fuente: http://www.geocities.ws/newomich/info/informatica/word1.html
              http://karlospg1.blogspot.es/1192763280/
              http://es.wikipedia.org/wiki/Software

"Mitos del Software"

Los mitos del software tienen varios atributos que los hacen insidiosos; por ejemplo, aparecieron como declaraciones razonables de hechos (algunas veces conteniendo elementos verdaderos); tuvieron un sentido intuitivo y frecuentemente fueron promulgados por expertos que "estaban al día".

Los mitos del software son creencias que pueden arruinar el desarrollo de un proyecto software. Se pueden dividir en mitos de gestión, mitos de cliente y mitos de los programadores.

• MITOS DE GESTIÓN  Los gestores con responsabilidad sobre el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad.

MITO: Tenemos ya un libro que esta lleno de estándares y procedimientos para construir software ¿no le proporcionaron ya a mi gente todo lo que necesita saber?

REALIDAD: Esta muy bien que el libro exista, pero ¿Se usa? ¿Conocen los trabajadores su existencia? ¿Refleja las prácticas modernas del desarrollo de software?.

MITO: Mi gente dispone de las herramientas de desarrollo de software mas avanzadas, después de todo, les  compramos las computadoras mas modernas.

REALIDAD: Se necesita mucho mas que el ultimo modelo de computadora grande (o de PC) para hacer desarrollo de software de gran calidad , las herramientas de ingeniería de software asistida por computadora.)case aunque la mayoría todavía no se usen , son mas importantes que el hardware para conseguir buena calidad o productividad.

MITO: Si fallamos en la planificación podemos añadir más programadores y adelantar el tiempo perdido.

REALIDAD: El desarrollo de software no es un proceso mecánico como la fabricación. En palabras de Brooks <<añadir software a un producto de software retrasado lo retrasa aún más>>. A principio esta declaración puede ser un contrasentido. Sin embargo cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede hacer que se reduzca la cantidad de tiempo gastado en el desarrollo productivo.

MITO: Decidió subcontratar el proyecto de software a un tercero, puede relajarme y dejar que esa compañía lo construya.

REALIDAD: Si una organización no entiende como administrar y controlar internamente los proyectos de software, de manera invariable entrara en conflicto al subcontratar este tipo de proyectos.

MITO: Dispone de las herramientas de desarrollo de software más avanzadas

REALIDAD: No es suficiente tener el último modelo de computadoras para lograr desarrollar el software con gran calidad. Las herramientas de ingeniería de software asistida por computadora (CASE), son más importantes que el hardware para conseguir buena calidad y productividad.

• MITOS DEL CLIENTE: El cliente cree en los mitos que existen sobre software, debido a que los gestores y los trabajadores responsables hacen muy poco para corregir la mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y finalmente, quede insatisfecho con el que desarrolla el software.

MITO: Una declaración general de los objetivos es suficiente para comenzar a escribir los programas; podemos dar los detalles mas adelante.

REALIDAD: Una mala definición inicial es la principal causa del trabajo baldío en software. Es necesario una descripción formal y detallada del ámbito de la información, funciones, rendimiento, ligaduras de diseño y criterios de validación .Esas características pueden determinarse solo después de una exhaustiva comunicación entre el cliente y el analista.

MITO: Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible..

REALIDAD: Es verdad  que los requisitos del software cambian continuamente pero el impacto del cambio varia según el momento rn el que se introduzcan. Si se pone cuidado al dar la definición inicial  los cambios solicitados al principio pueden acomodarse fácilmente el cliente puede revisar los requisitos y recomendar modificaciones.

MITO: El cliente pone cierto plazo para la entrega de su proyecto.

REALIDAD: Algunas veces el cliente da un plazo para la entrega de su proyecto, pero no tiene en cuenta los improvisos que puedan presentarse.

MITO: Las empresas grandes serán las mejores

REALIDAD: No es tanto la empresa sino el conocimiento del desarrollador, el cliente tiene que ver los conocimientos de trabajadores no solo el estado social en el que se encuentra la empresa.

MITO: El cliente debe de ser certero en la propuesta de su proyecto

REALIDAD: El clientes debe de estar seguro de cómo va a ser su proyecto y tomar una decisión libre de ello.

• MITOS DEL PROGRAMADOR: Los mitos que aun subsisten entre los desarrolladores del software han permanecido a través de 50 años de cultura de programación. Durante, por ello, las viejas formas y actitudes son difíciles de eliminar. 

MITO: La ingeniería del software obligara a emprender la creación de una documentación voluminista e innecesaria y de manera infalible tornara mas lento el proceso.

REALIDAD: La ingeniería del software se refiere a la elaboración de documentos. Esta relacionada con la creación de calidad. Una mejor conduce a la reducción de los trabajadores redundantes. Y una mejor cantidad de trabajos redundantes resulta en menores tiempos de entrega.

MITO: Una vez que escribimos el programa y hacemos que funcione nuestro trabajo a terminado.

 REALIDAD: Alguien dijo una vez “cuanto mas pronto empiece a escribir el código mas se tardara en terminarlo. Los datos industriales indican que entre el 50 y 60 % de todo el esfuerzo dedicado a un programa se realizara después de que se haya entregado al cliente por primera vez.

MITO: Hasta que no tengo el programa ejecutándose realmente no tengo forma de comprobar su calidad.

REALIDAD: Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software “la revisión técnica formal”, la revisión del software es un “filtro de calidad” que se ha comprobado que es mas efectivo que la prueba para encontrar defectos en el software.

MITO: Lo único que se entrega al terminar el proyecto es el programa funcionando. 

REALIDAD: Un programa que  funciona es solo una parte de la configuración del software que incluye programas, documentos y datos. L a documentación es la base de un buen desarrollo y lo que es mas importante proporciona guías para la tarea de mantenimiento.

MITO: Mi manera de entender el programa será igual a la manera en que entenderán los usuarios finales.

REALIDAD: A veces a un desarrollador o programador se le hace fácil desarrollar el proyecto a como el lo entiende, a su manera, pero suelo no ser el entorno mas amigable para el cliente.

FUENTE:https://export.writer.zoho.com/public/wendolin/mitos-y-realidades-del-software/fullpage

Mitos de Ingeniería de Sistemas

En la vida actual existe  una alta demanda de Ingenieros de Sistemas. Sin embargo, el profesional de la Ingeniería se ha visto limitado en su Visión respecto a los campos de acción en los que puede desempeñarse. ¿A qué se debe esto? La razón obedece a una serie de  mitos  que han obstaculizado la promoción de cada una de sus labores. Incluso existe desconocimiento y mala información por parte de la sociedad, ya que tradicionalmente se ha creído que el Ingeniero de Sistemas es quien se dedica  a realizar mantenimientos de computadores, y/o desarrollar código para aplicaciones.

Unos de los mas frecuentes mitos o conceptos erroneos que le atribuyen al ingeniero de sistemas son los siguientes: 

• El ingeniero de sistemas trabaja con computadoras:

A pesar de que las computadoras son hoy el  principal componente de muchos sistemas informáticos, existen dispositivos nuevos que no pueden considerarse computadoras pero que igualmente cumplen funciones importantes en ellos: PDAs, dispositivos de red, scanners, impresoras autónomas, etc..

Pero la realidad es que pueden diseñarse sistemas informáticos sin componentes electrónicos, aunque no es muy común. Por ejemplo, muchísimas empresas (especialmente PYMEs) utilizan sistemas de facturación basados completamente en papel y todavía dependen de sistemas contables basados en libros y ajenos a toda automatización electrónica. Las desventajas de tales sistemas, especialmente cuando la empresa crece, son evidentes pero no por ello se desechan o dejan de ser funcionales.

Lo más común, aun en diseños realizados por profesionales, es una mezcla de dispositivos electrónicos y puntos de entrada tradicionales. Por ejemplo, el control de asistencia de una empresa puede manejarse en una computadora, pero la captura del dato sobre la asistencia del empleado puede hacerse en una tarjeta  convencional, porque lo central es la información y los procesos de manipulación de la misma, no la naturaleza de los canales y medios que se usen para obtenerla o llevarla de un lugar a otro.

• El ingeniero de sistemas es un hábil programador:

Programar es una habilidad importante para el ingeniero de sistemas – y no solo para él, en realidad para todos los profesionales [8], pero, dependiendo del campo en el que se desenvuelva, puede ser que ya no la realice o no la requiera. Seguramente existen profesionales hábiles para el diseño, la evaluación o para la construcción de sistemas que solo requieren integración de componentes, ellos no necesitan ser buenos programadores.

Tampoco es una habilidad indispensable (o requerida en alto grado) para quienes administran tecnologías de información o diseñan y construyen redes de datos, por poner un par de ejemplos.

• Los ingenieros de sistemas saben mucho de Windows:

O de Linux, o de Mac OS™, o de cualquier otro sistema operativo comercial. Usualmente suele ser cierto, pero no es necesario ni imprescindible sino puramente circunstancial.

Los sistemas pueden diseñarse con independencia de la plataforma (el sistema operativo o el hardware) que se vaya a utilizar, por lo que el ingeniero no necesita forzosamente saber mucho sobre un sistema particular.

El hecho de que algunas empresas requieran ingenieros especializados en un paquete de software particular (superusuarios), se  deriva de decisiones de diseño que luego comprometieron a la organización de esa forma, pero esa especialización en un producto no es inherente a la profesión.

• Todos los sistemas informáticos tienen que ver con contabilidad:

En cierto momento muchos sistemas puede convertirse en auxiliares contable, es decir, un registro que guarda datos que no necesariamente son la contabilidad pero que proporcionan reportes importantes para construirla, como el total de compras y ventas en un sistema de inventario, la ocupación mensual de un hotel, el consumo de cierto cliente, etc. Pero eso no significa que el objetivo primario de todo sistema informático sea alimentar la contabilidad.

Los objetivos de diseño e implementación de sistemas usualmente incluyen: el apoyo a la toma de decisiones (aumentar o disminuir una línea de producción en base a rendimiento, invertir en equipo para un departamento, etc.) aumentar la productividad, mejorar la competitividad, incrementar la seguridad, proveer herramientas especializadas, etc. 

FUENTE: http://www.tec.url.edu.gt/boletin/URL_03_SIS01.pdf