PERFORMANCE

La performance es una característica importante de un sistema informático. En algunos casos pueden influir directamente sobre la usabilidad de los mismos mientras, en otros casos, pueden invalidar directamente la finalidad de un sistema. Las pruebas de performance buscan, con el menor costo posible, minimizar lo máximo posible esos problemas. 

 

Mediante un análisis del uso del sistema y la utilización de herramientas de generación de carga, se logra realizar una simulación del uso del mismo, el cual busca no sólo conocer los tiempos de respuesta, sino también la estabilidad y confiabilidad del mismo. En esta presentación, se verá la necesidad del uso de una metodología bien establecida junto con el uso de herramientas y experiencia, de manera de poder conseguir la máxima performance de nuestras pruebas.

La ingeniería de performance o rendimiento es parte integral del proceso creativo del diseño y arquitectura de aplicaciones de software. Como tal, puede ser descrita como la verificación y validación de las varias opciones que emergen durante el diseño de la aplicación, donde se hacen y prueban prototipos para tomar la decisión más apropiada basada en las prioridades y restricciones definidas para la aplicación. De esta manera se puede encontrar el balance ideal y el más alto rendimiento posible. 

S.M.A.R.T

S.M.A.R.T. son las siglas de Self Monitoring Analysis and Reporting Technology (Tecnología de análisis y reporte de auto-monitoreo). Se utiliza para realizar un rápido análisis del disco duro para detectar problemas durante el arranque del sistema. 
 

La tecnología SMART fue originalmente desarrollada y definida por el Comité SFF a mediados de los 90s. SMART tuvo varias evoluciones que a veces se denominaron SMART I, II y III. Con el paso de los años, el Comité T13 ha tomado la responsabilidad de SMART y actualmente forma parte de la especificación ATA. La especificación ATA no define a SMART I, II, III. WD considera a las siguientes como las definiciones:

SMART I: Definida por la especificación SFF-8035i v1.0 (May. de 1995). SMART se calcula a partir de la actividad en línea de la unidad de disco. En línea significa que el sistema huésped solicitó a la unidad de disco que ejecutara la acción (como una lectura o escritura).

SMART II: Definida por la especificación SFF-8035i v2.0 (Abr. de 1996). SMART se calcula a partir de la actividad en línea y fuera de línea de la unidad de disco. Durante los periodos de inactividad, puede realizarse una exploración fuera de línea para explorar la superficie completa del disco duro. Estas actividades fuera de línea afectan a SMART.

SMART III: Aún no está definida por ninguna especificación estándar de la industria. La exploración fuera de línea se expande para incluir la reparación de sectores.

Diagnóstico y corrección de un error de S.M.A.R.T.:
Si se detecta un problema, puede utilizar Data Lifeguard Diagnostic para DOS (flexible) o un Data Lifeguard Diagnostic para DOS (CD) para efectuar un análisis más detallado del disco duro. Todas las unidades de disco duro de Western Digital son compatibles con la versión III de S.M.A.R.T.

Las versiones antiguas de S.M.A.R.T. en el BIOS del sistema pueden causar problemas durante la exploración S.M.A.R.T. de su disco duro. Si el BIOS del sistema reporta un error S.M.A.R.T. y nuestro propio diagnóstico no reporta este error S.M.A.R.T., póngase en contacto con el fabricante del BIOS para obtener una versión actualizada del BIOS.
 

Puede utilizar SMART en dos modos diferentes: normales o genómica . La diferencia principal está en la base de datos subyacente proteína utilizada. En normal de SMART , la base de datos contiene Swiss-Prot, proteomas Ensembl SP-TrEMBL y estable. En Genómica de SMART , sólo los proteomas de genomas completamente secuenciados se utilizan; Ensembl para metazoos y Swiss-Prot para el resto. La lista completa de los genomas de Genómica de SMART .

La base de datos de proteínas en normal SMART tiene redundancia significativa, a pesar de que se eliminan proteínas idénticas. Si usa SMART para explorar arquitecturas de dominio, o quieres encontrar cantidades exactas de dominio en distintos genomas, considere cambiar a Genómica modo. Los números de las páginas de dominios de anotación será más preciso, y no habrá muchos fragmentos de proteínas correspondientes a los mismos genes en los resultados arquitectura de consultas. Recuerde que usted está explorando un conjunto limitado de los genomas, sin embargo.

FUENTES DE INFORMACIÓN:

QUÉ ES UNA INTERFAZ?

 
Es el punto en el que se establece una conexión entre dos elementos, que les permite trabajar juntos.

 La interfaz es el medio que permite la interacción entre esos elementos. En el campo de la informática se distinguen diversos tipos de interfaces que actúan a diversos niveles, desde las interfaces claramente visibles, que permiten a las personas comunicarse con los programas, hasta las imprescindibles interfaces hardware, a menudo invisibles, que conectan entre sí los dispositivos y componentes dentro de los ordenadores o computadoras.


 Las interfaces de usuario cuentan con el diseño gráfico, los comandos, mensajes y otros elementos que permiten a un usuario comunicarse con un programa. Las microcomputadoras disponen de tres tipos básicos de interfaces de usuario (que no necesariamente son excluyentes entre sí): la interfaz de línea de comandos, reconocible por los símbolos A o C del sistema MS-DOS, que responde a los comandos introducidos por el usuario; la interfaz controlada por menús utilizada en muchas aplicaciones (por ejemplo Lotus 1-2-3) ofrece al usuario una selección de comandos, permitiéndole elegir uno de ellos presionando la tecla de la letra correspondiente (o una combinación de teclas), desplazando el cursor con las teclas de dirección o apuntando con el mouse (ratón); y la interfaz gráfica de usuario, una característica de los equipos Apple Macintosh y de los programas basados en ventanas (como los del entorno Windows), representa visualmente los conceptos, por ejemplo un escritorio, y permite al usuario no sólo controlar las opciones de los menús, sino también el tamaño, la posición y el contenido de una o más ventanas o áreas de trabajo que aparezcan en pantalla.


FUENTE DE INFORMACIÓN:


PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE (ERP)







Los sistemas de planificación de recursos empresariales (ERP) son sistemas de información gerenciales que integran y manejan muchos de los negocios asociados con las operaciones de producción y de los aspectos de distribución de una compañía comprometida en la producción de bienes o servicios.

Los ERP están funcionando ampliamente en todo tipo de empresas modernas. Todos los departamentos funcionales que están involucrados en la operación o producción están integrados en un solo sistema. Además de la manufactura o producción, almacenamiento, logística e información tecnológica, incluyen además la contabilidad, y suelen incluir un recursos humanos, y herramientas de mercadotecnia y administración estratégica. 

 

La evolución de sistemas ERP 


La evolución de los sistemas de planificación de recursos empresariales (ERP) se remonta a la década de los 70, cuando se comienza a utilizar un software llamado MRP (Material Requirement Planning), cuyo objetivo era planificar las operaciones de producción dentro de las compañías.

Sin embargo, en la actualidad dentro de los sistemas de planificación de recursos empresariales (ERP) surgen productos que son enfocados específicamente de acuerdo a los negocios de cada compañía comprometidas ya sean en la producción de bienes o servicios. Por lo que un sistema de planificación de recursos empresariales constituye la base del desarrollo de los sistemas especializados de gestión.

Los objetivos principales de los sistemas ERP son:

  •  Optimización de los procesos empresariales. 
  •  Acceso a toda la información de forma confiable, precisa y oportuna (integridad de datos). 
  •  La posibilidad de compartir información entre todos los componentes de la organización. 
  •  Eliminación de datos y operaciones innecesarias de reingeniería. 

El propósito fundamental de un ERP es otorgar apoyo a los clientes del negocio, tiempos rápidos de respuesta a sus problemas, así como un eficiente manejo de información que permita la toma oportuna de decisiones y disminución de los costos totales de operación.




Características

Las características que distinguen a un ERP de cualquier otro software empresarial, es que deben de ser sistemas integrales, con modularidad y adaptables:

Integrales.
Porque permiten controlar los diferentes procesos de la compañía entendiendo que todos los departamentos de una empresa se relacionan entre sí, es decir, que el resultado de un proceso es punto de inicio del siguiente. Por ejemplo, en una compañía, el que un cliente haga un pedido representa que se cree una orden de venta que desencadena el proceso de producción, de control de inventarios, de planificación de distribución del producto, cobranza, y por supuesto sus respectivos movimientos contables. Si la empresa no usa un ERP, necesitará tener varios programas que controlen todos los procesos mencionados, con la desventaja de que al no estar integrados, la información se duplica, crece el margen de contaminación en la información (sobre todo por errores de captura) y se crea un escenario favorable para malversaciones. Con un ERP, el operador simplemente captura el pedido y el sistema se encarga de todo lo demás, por lo que la información no se manipula y se encuentra protegida.
 

 Ventajas

Un fabricante que no disponga de un ERP, en función de sus necesidades, puede encontrarse con muchas aplicaciones de software cerradas, que no se pueden personalizar, y no se optimizan para su negocio. Diseño de ingeniería para mejorar el producto, seguimiento del cliente desde la aceptación hasta la satisfacción completa, una compleja administración de interdependencias de los recibos de materiales, de los productos estructurados en el mundo real, de los cambios de la ingeniería y de la revisión y la mejora, y la necesidad de elaborar materiales substitutos, etc. La ventaja de tener un ERP es que todo esto, y más, esta integrado.

  • El cambio como un producto está hecho en los detalles de ingeniería, y es como ahora será hecho. La efectividad de datos puede usarse para el control cuando el cambio ocurra desde una versión anterior a la nueva, en ambos productos los datos van encaminados hacia la efectividad y algunos van a la suspensión del mismo. Parte del cambio puede incluir la etiqueta para identificar el número de la versión (código de barras). 
  • La seguridad de las computadoras esta incluida dentro del ERP, para proteger en contra de crímenes externos, tal como el espionaje industrial y crimen interno, tal como malversación. Una falsificación en el escenario de los datos puede involucrar terrorismo alterando el recibo de materiales como por ejemplo poner veneno en los productos alimenticios, u otro sabotaje. La seguridad del ERP ayuda a prevenir el abuso. 
  • Hay conceptos de mercadeo y ventas (los que incluyen CRM o la relación administrativa con los consumidores, back end (el trabajo interno de la compañía para satisfacer las necesidades de los consumidores) que incluye control de calidad, para asegurarse que no hay problemas no arreglados, en los productos finales; cadena de abastecimiento (interacción con los proveedores y la infraestructura). Todo esto puede ser integrado a través de la ERP, aunque algunos sistemas tengan espacios de menos comprensibilidad y efectividad. Sin un ERP que integre todo esto, puede ser complicado para la administración de la manufactura.


Desventajas

Muchos de los problemas que tienen las compañías con el ERP son debido a la inversión inadecuada para la educación continua del personal relevante, incluyendo los cambios de implementación y de prueba, y una falta de políticas corporativas que afectan a cómo se obtienen los datos del ERP y como se mantienen actualizados.

Limitaciones y obstáculos del ERP incluyen:

  •  El éxito depende en las habilidades y la experiencia de la fuerza de trabajo, incluyendo la educación y como hacer que el sistema trabaje correctamente. Muchas compañías reducen costos reduciendo entrenamientos. Los propietarios de pequeñas empresas están menos capacitados, lo que significa que el manejo del sistema ERP es operado por personal que no está capacitado para el manejo del mismo. 
  •  Cambio de personal, las compañías pueden emplear administradores que no están capacitados para el manejo del sistema ERP de la compañía empleadora, proponiendo cambios en las prácticas de los negocios que no están sincronizados con el sistema. 
  •  La instalación del sistema ERP es muy costosa. 
  •  Los vendedores del ERP pueden cargar sumas de dinero para la renovación de sus licencias anuales, que no está relacionado con el tamaño del ERP de la compañía o sus ganancias. 
  •  Los ERP son vistos como sistemas muy rígidos, y difíciles de adaptarse al flujo específico de los trabajadores y el proceso de negocios de algunas compañías, este punto se cita como una de las principales causas de falla. 
  •  Los sistemas pueden ser difíciles de usarse. 
  •  Los sistemas pueden sufrir problemas de "el eslabón más débil": la ineficiencia en uno de los departamentos o en uno de los empleados puede afectar a otros participantes. 
  •  Muchos de los eslabones integrados necesitan exactitud en otras aplicaciones para trabajar efectivamente. Una compañía puede lograr estándares mínimos, y luego de un tiempo los "datos sucios" (datos inexactos o no verificados) reducirán la confiabilidad de algunas aplicaciones. 
  •  Una vez que el sistema esté establecido, los costos de los cambios son muy altos (reduciendo la flexibilidad y las estrategias de control). 
  •  La mala imagen de unión de la compañía puede causar problemas en su contabilidad, la moral de sus empleados y las líneas de responsabilidad. 
  •  La resistencia en compartir la información interna entre departamentos puede reducir la eficiencia del software. 
  •  Hay problemas frecuentes de compatibilidad con algunos de los sistemas legales de los socios. 
  •  Los sistemas pueden tener excesiva ingeniería respecto a las necesidades reales del consumidor.


FUENTE DE INFORMACIÓN:



Sistemas, Aplicaciones y Productos para Procesamiento de Datos (SAP)

El nombre de SAP proviene de: Sistemas, Aplicaciones y Productos en Procesamiento de datos. EL nombre SAP es al mismo tiempo el nombre de una empresa y el de un sistema informático. Este sistema comprende muchos módulos completamente integrados, que abarca prácticamente todos los aspectos de la administración empresarial. Cada módulo realiza una función diferente, pero esta diseñado para trabajar con otros módulos. 
La integración total de los módulos ofrece real compatibilidad a lo largo de las funciones de una empresa. Esta es la característica más importante del sistema SAP y significa que la información se comparte entre todos los módulos que la necesiten y que pueden tener acceso a ella. La información se comparte, tanto entre módulos, como entre todas las áreas.

SAP establece e integra el sistema productivo de las empresas. Se constituye con herramientas ideales para cubrir todas las necesidades de la gestión empresarial -sean grandes o pequeñas- en torno a: administración de negocios, sistemas contables, manejo de finanzas, contabilidad, administración de operaciones y planes de mercadotecnia, logística, etc. SAP proporciona productos y servicios de software para solucionar problemas en las empresas que surgen del entorno competitivo mundial, los desarrollos de estrategias de satisfacción al cliente, las necesidades de innovación tecnológica, procesos de calidad y mejoras continuas, así como, el cumplimiento de normatividad legal impuesta por las instituciones gubernamentales.


En la actualidad SAP AG se encuentra en más de 50 países cuya sede central está ubicada en Walldorf, Alemania. SAP, como software para la administración empresarial, el cual abarca diferentes módulos, los cuales integran las diferentes áreas de la empresa en una escala global (contable, comercial, logística, entre otras) en un solo sistema. Estos módulos sustituyen la gran variedad de sistemas independientes con los cuales muchas empresas / organizaciones suelen trabajar, creando un solo patrón y compatibilidad a lo largo de las diferentes funciones, obteniendo un control total sobre la compañía. Actualmente SAP comercializa sus productos en todo el mundo en las diferentes áreas del mercado: Materias primas, combustibles (gas, petróleo, entre otros), metalurgia, química, farmacéutica, construcción, consultoría, asesorías, área de la salud, autopartes, productos para el hogar, sector público, consumo masivo, educación, tecnología e informática, entre otras.

Lenguaje de Modelado Unificado (UML)

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 y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.   

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. 
 

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.


¿Por qué Utilizar el UML?
Como la estrategia de evaluación incrementa en muchas compañías, las industrias la observa como técnicas de automatización la producción del Software y para mejorar la calidad y reducir los costos y el tiempo del mercado. Éstas técnicas incluyen el componente tecnológico, la programación visual, modelos y sistemas. Los negocios también observan técnicas para manejar la complexión de sistemas, así ellos aumentan en ámbito y en escala.

En particular, ellos reconocen la necesidad de resolver problemas que ocurran en la arquitectura, tales como la distribución física, concurrencia, réplicas, seguridad, carga balanceada y tolerancia de culpa. Adicionalmente, el desarrollo de la World Wide Web (Mundo de la Ancha Telaraña), mientras se hacen algunas cosas simples, tiene exacerbada ese problema de arquitectura.
 

VENTAJAS

  • Expresar la intención que tiene el actor (usuario)
  • Extraer los requerimientos del usuario y del sistema
  • Centrar al analista en las tareas principales de usuario (describiendo los casos de mayor importancia).
  • Tener en cuenta todos los usuarios evitando que las personas especializadas en informática dirijan la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos. 

Desventajas

  • No establecen los requisitos funcionales.
  • Tampoco permiten establecer los requisitos no funcionales.
  •  Los casos de uso deben complementarse con información adicional como:
  1.  Reglas de negocio
  2.  Requisitos no funcionales
  3.  Diccionario de datos que complementen los requerimientos del sistema.Cada caso crítico del uso debe tener un requisito no funcional centrado en el funcionamiento asociado. 

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelos (los símbolos utilizados en los modelos) y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas.


VISTAS: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo.


DIAGRAMAS: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.


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.


REGLAS O MECANISMOS GENERALES: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

METODOLOGÍA RUP

El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas RUP, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de metodologías adaptables al contexto y necesidades de cada organización, donde el software es organizado como una colección de unidades atómicas llamados objetos, constituidos por datos y funciones, que interactúan entre sí.

RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto


 

 

RUP como proceso de desarrollo

• RUP es explícito en la definición de software y su trazabilidad, es decir, contempla en relación causal de los programas creados desde los requerimientos hasta la implementación y pruebas.

• RUP identifica claramente a los profesionales (actores) involucrados en el desarrollo del software y sus responsabilidades en cada una de las actividades.


Fases de desarrollo del software

  •  Inicio
  •  Elaboración
  •  Construcción
  • Transición
 
Ciclo de vida
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. 

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.


En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.


Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
 
RUP para el desarrollo de software moderno que junto con UML trata de mejorar el desarrollo de software no solo con una serie de pasos establecidos si no combinando varios modelos, esto dependiendo de las necesidades de la empresa que lo solicite.

FUENTE DE INFORMACIÓN:



Modelo en Flor

Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre
la idea inicial y el producto final. 
 

Un modelo de desarrollo establece el orden en el que se harán los procedimientos para la elaboración del producto y tener a si una mejor perspectiva de lo que se realizara.

Si hablamos específicamente del modelo en flor básicamente se basa en la estructura de una flor el cual todos los pétalos u hojas que contenga dicha estructura sera una etapa a realizar.
Sin embargo todas las etapas se deben de desarrollar al mismo tiempo para a si lograr que el procedimiento llegue a obtener un producto final.
Para lograr entender algunas etapas especificas que debe tener este modelo, mencionare solo algunas:

  • ANÁLISIS
  • DISEÑO
  • INICIO
  • CÓDIGO 
  • IMPLEMENTACIÓN 
  • PRUEBAS 

Si en dado caso nuestra opción para realizar un software es la de el modelo en flor recomendare algunos puntos importantes que no debemos de olvidar. 

  1. -El proceso del desarrollo de software es el de desarrollar un producto de software.
  2. -Los equipos no deben de estar preocupados por el proceso de desarrollo mismo.
  3. -Deben de desarrollarse todas las etapas al mismo tiempo hasta que el producto final es alcanzado.

VENTAJAS

  • Al terminar el modelo  tendrás el producto de software libre de errores.
  • Podrás realizar las pruebas durante el proceso para lograr detectar problemas inmediatamente. 
  • Involucración del usuario en todas las etapas del modelo. 


Desventajas

  • Demasiada carga de trabajo. 
  • Los involucrados en el software tendrán que tener mucha paciencia y minuciosa concentración.
  • Si se detecta un error en cualquier etapa tendrán que repararlo inmediatamente de lo contrario no funcionara ninguna etapa y no obtendrán un satisfactorio producto. 



Modelo en V


El modelo-V deriva directamente del modelo en cascada (Waterfall model), y se usa como base de procesos dentro del ciclo de vida de software. El modelo considera el testing como una actividad paralela al SDLC (Sofware development Life Cycle) y no como una actividad aislada que se realiza al final del desarrollo. Fue desarrollado en Alemania por el Ministerio de Defensa.
La siguiente figura muestra como cada fase de desarrollo (a la izquierda de la imagen) se alinean con las fases de testing.
Esta es la representación más simple del modelo en V, en muchos casos las organizaciones crean sus propios modelos usando este como base. El modelo puedes llegar a ser tan complejo como uno quiera.
La ventaja principal con respecto al modelo en cascada es simple, ya que este modelo involucra chequeos de cada una de las etapas del modelo de cascada. Los requisitos se validan con las pruebas de “User Acceptance Test”, Análisis y deseño de arquitectura con las pruebas de IST (integration & system test), mientras que las pruebas a nivel de componentes y a más bajo nivel se realizan en las fases de pruebas de “Assembly” y “Unit Test” respectivamente.

¿Cuales son los objetivos del modelo en V?

  • Minimizar los riesgos del proyecto.
  • Mejorar y garantizar la calidad del proyecto.
  • Reducir los costes totales a lo largo del ciclo de vida del proyecto.
  • Mejorar la comunicación entre los Stakeholders.

En definitiva se trata de un modelo más robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada (todo depende de la empresa y el secto).

Ventajas:

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario


FUENTES DE INFORMACIÓN:



















Análisis del Modelo V

Este modelo es una versión mejorada del modelo cascada, incorpora o se enfoca, de mejor manera al control de calidad, este modelo también muestra la relación iterativa entre las distintas fases en el proceso de desarrollo de software y añade dos partes que son:
La VERIFICACIÓN: que tiene relación con la pregunta ¿ Se está haciendo correctamente el producto?
La VALIDACIÓNque tiene relación con la pregunta ¿ Se está haciendo el producto , es decir, la demostración de que el software cumple con exactitud la finalidad pretendida.
En el modelo V podemos ver las mismas fases del modelo cascada pero con una mejor relación entre ellas.


¿Qué es un Cibernauta y un Nativo Digital?


Cibernauta es aquella persona que navega por Internet.

En principio es un término aplicable a cualquier persona que utiliza un navegador web y visita sitios web; pero suele utilizarse especialmente para aquellas personas que son expertos navegantes de la WWW, incluso sin saber demasiado sobre computación.

 
Sociabilidad de los cibernautas
La idea social más generalizada, es que los cibernautas son personas poco sociables e introvertidas. Pero un estudio realizado por expertos de la Universidad de Cataluña, concluyó que las personas que utilizan Internet son más sociables, se interesan más en la política y tienen relaciones de amistad y familiares más intensas.

Nativo digital

La Red contiene mucha información sobre los conceptos de nativo digital e inmigrante digital. Según la definición propuesta por Marc Prensky, los nativos digitales son aquellas personas que han crecido, se han desarrollado y han adquirido todo su bagaje sociocultural y cognitivo en un vínculo más que estrecho con Internet y las tecnologías en general: teléfonos celulares, videojuegos, televisión, etc. Por contraposición, los inmigrantes digitales se relacionan tardíamente con las TIC y nunca llegan a hacerlo como los nativos, ya que lo hacen desde otro modo de apropiación y utilización del conocimiento y la información en general.

¿Qué es la cibernética?

La palabra cibernética en griego se refiere a mecanismos precisos de gobierno y control, con Platón y Ampere es usada siempre en su sentido político - social, pero es utilizada por primera vez en referencia a la ingeniería humana por Norbert Wiener.

La cibernética es una disciplina íntimamente vinculada con la teoría general de sistemas, al grado en que muchos la consideran inseparable de esta, y se ocupa del estudio de: el mando, el control, las regulaciones y el gobierno de los sistemas. El propósito de la cibernética es desarrollar un lenguaje y técnicas que nos permitan atacar los problemas de control y comunicación en general.

Lo que estabiliza y coordina el funcionamiento de los sistemas complejos como los seres vivos o las sociedades y les permite hacer frente a las variaciones del ambiente y presentar un comportamiento más o menos complejo es el control, que le permite al sistema seleccionar los ingresos (inputs) para obtener ciertos egresos (outputs) predefinidos. La regulación esta constituida por los mecanismos que permiten al sistema mantener su equilibrio dinámico y alcanzar o mantener un estado.

Un concepto muy importante o casi fundamental en cibernética es el de la retroalimentación. La retroalimentación parte del principio de que todos los elementos de una totalidad de un sistema deben comunicarse entre sí para poder desarrollar interrelaciones coherentes. Sin comunicación no hay orden y sin orden no hay totalidad, lo que rige tanto para los sistemas físicos como para los biológicos y los sociológicos.

La retroalimentación puede ser positiva, negativa o compensada. La retroalimentación es negativa cuando su función consiste en contener o regular el cambio, es positiva si amplifica o multiplica el cambio en una dirección determinada y se dice que es compensada cuando un regulador ejerce alternadamente retroalimentaciones positivas y negativas, según las necesidades del mantenimiento de la estabilidad del sistema regulado. (ejemplo Refrigerador, Temperatura Humana).

¿Que son las heuristicas?


Se puede definir Heurística como un arte, técnica o procedimiento práctico o informal para resolver problemas. Alternativamente, se puede definir como un conjunto de reglas, metodológicas no necesariamente formalizadas, positivas y negativas, que sugieren o   establecen cómo proceder y problemas a evitar en la solución de problemas y elaboración de hipótesis.

Es generalmente considerado que la capacidad heurística es un rasgo característico de los humanos desde cuyo punto de vista puede describirse como el arte y la ciencia del descubrimiento y de la invención o de resolver problemas mediante la creatividad y el pensamiento lateral o pensamiento divergente. Según el matemático George Pólya4 la base de la heurística está en la experiencia de resolver problemas y en ver cómo otros lo hacen. Consecuentemente se dice que hay búsquedas ciegas, búsquedas heurísticas (basadas en la experiencia) y búsquedas racionales.
 
La popularización del concepto se debe a Pólya, con su libro Cómo resolverlo (How to solve it). Habiendo estudiado tantas pruebas matemáticas desde su juventud, quería saber cómo los matemáticos llegan a ellas. El libro contiene la clase de recetas heurísticas que trataba de enseñar a sus alumnos de matemáticas. Cuatro ejemplos extraídos de él ilustran el concepto mejor que ninguna definición:
  • Si no consigues entender un problema, dibuja un esquema.
  • Si no encuentras la solución, haz como si ya la tuvieras y mira qué puedes deducir de ella (razonando a la inversa).
  • Si el problema es abstracto, prueba a examinar un ejemplo concreto.
  • Intenta abordar primero un problema más general (es la “paradoja del inventor”: el propósito más ambicioso es el que tiene más posibilidades de éxito).

En Ingeniería:

En ingeniería, una heurística es un método basado en la experiencia que puede utilizarse como ayuda para resolver problemas de diseño, desde calcular los recursos necesarios hasta en planear las condiciones de operación de los sistemas. Mediante el uso de heurísticas, es posible resolver más rápidamente problemas conocidos o similares a otros conocidos. Existen varios métodos heurísticos disponibles para los ingenieros como, por ejemplo, el Análisis modal de fallos y efectos y los árboles de fallo. En el primero se depende de un grupo de ingenieros experimentados que evalúan los problemas y fallos, los ordenan según su importancia y recomiendan soluciones.
 
Otros, como los métodos de ingeniería forense, son una amplia fuente de información para la investigación de problemas y responsables, y se basan en la heurística del eslabón más débil y en la eliminación de causas improbables. El conocimiento de qué causas son probables y cuáles no, forma una heurística aprendida por la profesión durante muchos años, más que un conocimiento científico aplicado.
Dado que las heurísticas pueden equivocarse, es fundamental conocer los casos en los que son aplicables y los límites a su uso. En general, en la ingeniería deben considerarse como ayudas o apoyos para hacer estimaciones rápidas y diseños preliminares, pero no como justificaciones finales de un diseño o proyecto u otros.

FUENTE DE INFORMACIÓN:

¿Que es? SEI?, ISO?, IEE ? Servira de algo?


 
SEI = 'Software Engineering Institute de la Carnegie-Mellon University, iniciado por el Departamento de Defensa de EE.UU. para ayudar a mejorar los procesos de desarrollo de software.
 


ISO = "Organización Internacional de Normalización"
 
La norma ISO 9001, 9002 y 9003 se refieren a las normas de sistemas de calidad que son evaluados por los auditores externos, y se aplican a muchos tipos de organizaciones de producción y fabricación, no sólo de software. El más completo es el 9001, y este es el más utilizado por las organizaciones de desarrollo de software. Cubre documentación, diseño, desarrollo, producción, pruebas, procesos de instalación, mantenimiento, y otros. ISO 9000-3 (no es igual que 9003) es una guía para la aplicación de la norma ISO 9001 a las organizaciones de desarrollo de software. La versión de EE.UU. de las normas de la serie ISO 9000 es exactamente la misma que la versión internacional, y se llama la norma ANSI / ASQ Q9000 serie. La versión de EE.UU. se pueden comprar directamente de la ASQ (American Society for Quality) o las organizaciones ANSI. Para ser ISO 9001, un auditor de tercera parte evalúa una organización, y la certificación suele ser bueno para unos 3 años, después de que una re evaluación completa es necesario. Tenga en cuenta que la certificación ISO 9000 no indica necesariamente que los productos de calidad - que sólo indica que los procesos documentados se siguen.

Principales normas ISO
Algunos estándares son los siguientes:

ISO 16:1975 — Frecuencia de afinación estandar: 440 Hz
ISO 216 — Medidas de papel: p.e. ISO A4
ISO 639 — Nombres de lenguas
ISO 690:1987 — Regula las citas bibliográficas (corresponde a la norma UNE 50104:1994)
ISO 690-2:1997 — Regula las citas bibliográficas de documentos electrónicos
ISO 732 — Formato de carrete de 120
ISO 838 — Estándar para perforadoras de papel (contando medidas y navajas)
ISO 1007 — Formato de carrete de 135
ISO 1171-Estándar de tamices
ISO/IEC 1539-1 — Lenguaje de programación Fortran
ISO 3029 — Formato carrete de 126
ISO 3166 — Códigos de países
ISO 4217 — Códigos de divisas
ISO 7811 — Técnica de grabación en tarjetas de identificación
ISO 8601 — Representación del tiempo y la fecha. Adoptado en Internet mediante el Date and Time Formats de W3C que utiliza UTC
ISO/IEC 8652:1995 — Lenguaje de programación Ada
ISO 8859 — Codificaciones de caracteres que incluye ASCII como un subconjunto (Uno de ellos es el ISO 8859-1, que permite codificar las lenguas originales de Europa occidental, como el español)
ISO 9000 — Sistemas de Gestión de la Calidad – Fundamentos y vocabulario
ISO 9001 — Sistemas de Gestión de la Calidad – Requisitos
ISO 9004 — Sistemas de Gestión de la Calidad – Directrices para la mejora del desempeño
ISO/IEC 9126 — Factores de Calidad del Software
ISO 9660 — Sistema de archivos de CD-ROM
ISO 9899 — Lenguaje de programación C
ISO 10279 — Lenguaje de programación BASIC
ISO 10646 — Universal Character Set
ISO/IEC 11172 — MPEG-1
ISO/IEC 11801 — Sistemas de cableado para telecomunicación de multipropósito
ISO/IEC 12207 — Tecnología de la información / Ciclo de vida del software
ISO 13450 — Formato de carrete de 110
ISO 13485 — Productos sanitarios. Sistemas de Gestión de la Calidad. Requisitos para fines reglamentarios
ISO/IEC 13818 — MPEG-2
ISO 14000 — Estándares de Gestión Medioambiental en entornos de producción
ISO/IEC 14496 — MPEG-4
ISO 14971 — Productos sanitarios. Aplicación de la gestión de riesgos a los productos sanitarios
ISO/IEC 15444 — JPEG 2000
ISO/IEC 15504 — Mejora y evaluación de procesos de desarrollo de software
ISO 15693 — Estándar para «tarjetas de vecindad»
ISO/IEC 17025 — Requisitos generales relativos a la competencia de los laboratorios de ensayo y calibración
ISO/IEC 20000 — Tecnología de la información. Gestión del servicio
ISO 22000 — Inocuidad en alimentos
ISO 17025 - Requisitos generales para la competencia de los laboratorios de ensayo y calibración
ISO 26300 — OpenDocument
ISO/IEC 26300 — OpenDocument Format (.odf)
ISO/IEC 27001 — Sistema de Gestión de Seguridad de la Información
ISO/IEC 29110 — Software engineering — Lifecycle profiles for Very Small Entities (VSEs) (MoProsoft)
ISO/IEC 29119 — Pruebas de Software
ISO 32000 — Formato de Documento Portátil (.pdf)
ISO 5218 - Representación de los sexos humanos.
ISO 50001 - Sistema de gestión de la energía y agua potable.



IEEE = 'Instituto de Ingenieros Eléctricos y Electrónicos "- entre otras cosas, crea estándares tales como" Norma IEEE para la Documentación de Software Test' (IEEE / ANSI 829), "Norma IEEE Unidad de Pruebas de Software (IEEE / ANSI 1008) , "Norma IEEE para Planes de Aseguramiento de la Calidad de Software" (IEEE / ANSI 730), y otros.


Estándares para la Ingeniería del Software


IEEE ha desarrollado estándares para todas las áreas de Ingeniería del Software.
Algunos de ellos, correspondientes a las principales áreas específicas de la Ingeniería del
Software son:
 
  • IEEE Std. 830 Prácticas recomendadas para las especificaciones de software. 
  • IEEE Std. 1362 Guía para la especificación del documento de requisitos “ConOps” 
  • IEEE Std. 1063 Estándar para la documentación de usuario de software. 
  • IEEE Std. 1012 Estándar para la verificación y validación de software. 
  • IEEE Std. 1219 Estándar para el mantenimiento del software 
COMENTARIO:
Gracias a la recopilación de diferente información podre ejercer algunas normas que implementare en mi proyecto final, las cuales son:

  1. ISO/IEC 9126 — Factores de Calidad del Software 
  2. ISO/IEC 12207 — Tecnología de la información / Ciclo de vida del software 
  3. ISO/IEC 29119 — Pruebas de Software 
  4. IEEE Std. 1063 Estándar para la documentación de usuario de software. 
  5. IEEE Std. 1012 Estándar para la verificación y validación de software. 
  6. IEEE Std. 1219 Estándar para el mantenimiento del software 

FUENTES DE INFORMACIÓN: 

http://es.wikipedia.org/wiki/Organizaci%C3%B3n_Internacional_de_Normalizaci%C3%B3n


http://www.softwaretestinghelp.com/what-is-sei-cmm-iso-ieee-ansi-will-it-help/

No Silver Bullet


 "No Silver Bullet - Esencia y accidentes de la Ingeniería de Software" es un documento ampliamente discutido en la ingeniería de software escrito por Fred Brooks en 1986. Brooks argumenta que "no hay desarrollo individual, en cualquiera de las técnicas o la gestión de la tecnología, que por sí misma promete incluso un orden de magnitud mejora dentro de una década en la productividad, la fiabilidad, la sencillez ". También afirma que "no podemos esperar a ver alguna vez de dos veces las ganancias cada dos años" en el desarrollo de software, como hay en el desarrollo de hardware.
 

Brooks hace una distinción entre complejidad accidental y complejidad esencial , y afirma que la mayor parte de lo que los ingenieros de software ahora se está dedicado a lo esencial, por lo que la reducción de todas las actividades accidentales a cero no da una mejora de un orden de magnitud. Brooks defiende frente a las partes esenciales del proceso de software. Aunque Brooks insiste en que no hay una bala de plata , cree que una serie de innovaciones que atacan complejidad esencial podría tener importantes (quizás más de diez veces en un período de diez años) mejoras.

EL ARGUMENTO

En el centro de la discusión es la distinción entre complejidad accidental y complejidad esencial . complejidad accidental se refiere a los problemas que creamos por nuestra cuenta y que puede ser fijo, por ejemplo, los detalles de la escritura y la optimización de montaje código o retrasos causados ​​por los lotes procesamiento. complejidad esencial es causado por el problema que hay que resolver, y nada lo puede quitar, si los usuarios quieren un programa para hacer 30 cosas diferentes, entonces esas 30 cosas son esenciales y el programa debe hacer esas 30 cosas diferentes.
 

Brooks afirma que hemos limpiado gran parte de la complejidad accidental, y los programadores de hoy en día pasan la mayor parte de su tiempo frente a la complejidad esencial.Una tecnología, que se había hecho una mejora significativa en el área de la complejidad accidental fue la invención de lenguajes de alto nivel de programación , tales como Fortranen ese momento. Lenguas actuales, tales como C , C + + , C # y Java , se consideran mejoras, pero no del mismo orden de magnitud.

Brooks aboga por la "creciente" software orgánicamente a través del desarrollo incremental. Se sugiere la elaboración y aplicación de las principales y subprogramas desde el principio, completando el trabajo sub-secciones posteriores. Él cree que la programación de esta manera excita los ingenieros y proporciona un sistema de trabajo en cada etapa de desarrollo.
Brooks continúa argumentando que hay una diferencia entre "buenos" los diseñadores y los diseñadores de "grandes". Se postula que la programación es un proceso creativo, algunos diseñadores son intrínsecamente mejores que otros. Él sugiere que no es tanto como una diferencia de diez veces entre un diseñador común y un gran uno. A continuación, los defensores de diseñadores estrella tratar igualmente bien como gestores estrella, proporcionándoles no sólo con la igualdad de remuneración , sino también todas las ventajas de un estatus superior: gran oficina, personal, fondos para viajes, etc

FUENTE DE INFORMACIÓN:


Sam vocabular

Tequilas Flamejantes

Lorem Ipsum

Con la tecnología de Blogger.

Ads 468x60px

Social Icons

About

Followers

Popular Posts

Popular Posts

Popular Posts

Featured Posts

 
INGENIERÍA DE SOFTWARE © 2012 | Designed by Cheap TVS, in collaboration with Vegan Breakfast, Royalty Free Images and Live Cricket Score