Diseño y Gestión de Sistemas

Question	Answer
Lenguaje orientado a objetos	C++ Objective C Java Smalltalk Eiffel Lexico (en castellano) Ruby Python SDK OCAML Object Pascal CLIPS Actionscript COBOL Pascal [En español] Perl C# Visual Basic.NET PHP Simula Delphi PowerBuilder Maya Python
Software de sistema	Conjunto de programas escritos para dar servicio a otros programas. (por ejemplo, compiladores, editores y herramientas para administrar archivos) procesa estructuras de información complejas pero deterministas. Otras aplicaciones de sistemas (por ejemplo, componentes de sistemas operativos, manejadores, software de redes, procesadores de telecomunicaciones) procesan sobre todo datos indeterminados.
Software de aplicación	Programas aislados que resuelven una necesidad específica de negocios. Las aplicaciones en esta área procesan datos comerciales o técnicos en una forma que facilita las operaciones de negocios o la toma de decisiones administrativas o técnicas.
Software de ingeniería y ciencias	Se ha caracterizado por algoritmos “devoradores de números”. Las aplicaciones van de la astronomía a la vulcanología, del análisis de tensiones en automóviles a la dinámica orbital del transbordador espacial, y de la biología molecular a la manufactura automatizada. Sin embargo, las aplicaciones modernas dentro del área de la ingeniería y las ciencias están abandonando los algoritmos numéricos convencionales.
Software incrustado	Reside dentro de un producto o sistema y se usa para implementar y controlar características y funciones para el usuario final y para el sistema en sí. Ejecuta funciones limitadas y particulares (por ejemplo, control del tablero de un horno de microondas) o provee una capacidad significativa de funcionamiento y control (funciones digitales en un automóvil, como el control del combustible, del tablero de control y de los sistemas de frenado).
Software de línea de productos	Es diseñado para proporcionar una capacidad específica para uso de muchos consumidores diferentes. Se centra en algún mercado limitado y particular (por ejemplo, control del inventario de productos) o se dirige a mercados masivos de consumidores (procesamiento de textos, hojas de cálculo, gráficas por computadora, multimedios, entretenimiento, administración de base de datos y aplicaciones para finanzas personales o de negocios).
Aplicaciones web	Esta categoría de software centrado en redes agrupa una amplia gama de aplicaciones. En su forma más sencilla, son poco más que un conjunto de archivos de hipertexto vinculados que presentan información con uso de texto y gráficas limitadas. Sin embargo, desde que surgió Web 2.0, las webapps están evolucionando hacia ambientes de cómputo sofisticados que no sólo proveen características aisladas, funciones de cómputo y contenido para el usuario final, sino que también están integradas con bases de datos corporativas y aplicaciones de negocios.
Software de inteligencia artificial	Hace uso de algoritmos no numéricos para resolver problemas complejos que no son fáciles de tratar computacionalmente o con el análisis directo. Las aplicaciones en esta área incluyen robótica, sistemas expertos, reconocimiento de patrones (imagen y voz), redes neurales artificiales, demostración de teoremas y juegos.
Software heredado	Fueron desarrollados hace varias décadas y han sido modificados de manera continua para que satisfagan los cambios en los requerimientos de los negocios y plataformas de computación. La proliferación de tales sistemas es causa de dolores de cabeza para las organizaciones grandes, a las que resulta costoso mantenerlos y riesgoso hacerlos evolucionar.
Software heredado	Fueron desarrollados hace varias décadas y han sido modificados de manera continua para que satisfagan los cambios en los requerimientos de los negocios y plataformas de computación. La proliferación de tales sistemas es causa de dolores de cabeza para las organizaciones grandes, a las que resulta costoso mantenerlos y riesgoso hacerlos evolucionar.
La gran mayoría de webapps presenta los siguientes atributos	Uso intensivo de redes. Concurrencia. Carga impredecible. Rendimiento. Disponibilidad. Orientadas a los datos. Contenido sensible. Evolución continua. Inmediatez. Seguridad. Estética.
Una estructura de proceso general para la ingeniería de software consta de cinco actividades	Comunicación. Planeación. Modelado. Construcción. Despliegue.
Las actividades estructurales del proceso de ingeniería de software son complementadas por cierto número de actividades sombrilla	Seguimiento y control del proyecto de software. Administración del riesgo. Aseguramiento de la calidad del software. Revisiones técnicas. Medición. Administración de la configuración del software. Administración de la reutilización. Preparación y producción del producto del trabajo.
Actividades sombrilla	En general, se aplican a lo largo de un proyecto de software y ayudan al equipo que lo lleva a cabo a administrar y controlar el avance, la calidad, el cambio y el riesgo
La esencia de la práctica de la ingeniería de software	Entender el problema (comunicación y análisis). Planear la solución (modelado y diseño del software). Ejecutar el plan (generación del código). Examinar la exactitud del resultado (probar y asegurar la calidad).
Flujo de proceso lineal	Image: A (binary/octet-stream)
Flujo de proceso iterativo	Image: B (binary/octet-stream)
Flujo de proceso evolutivo	Image: C (binary/octet-stream)
Flujo de proceso paralelo	Image: D (binary/octet-stream)
Método de evaluación del estándar CMMI para el proceso de mejora	Proporciona un modelo de cinco fases para evaluar el proceso: inicio, diagnóstico, establecimiento, actuación y aprendizaje.
Evaluación basada en CMM para la mejora del proceso interno	Proporciona una técnica de diagnóstico para evaluar la madurez relativa de una organización de software; usa el SEI CMM como la base de la evaluación.
SPICE (ISO/IEC 15504)	Estándar que define un conjunto de requerimientos para la evaluación del proceso del software. El objetivo del estándar es ayudar a las organizaciones a desarrollar una evaluación objetiva de cualquier proceso del software definido.
ISO9001:2000 para software	Estándar genérico que se aplica a cualquier organización que desee mejorar la calidad general de los productos, sistemas o servicios que proporciona. Por tanto, el estándar es directamente aplicable a las organizaciones y compañías de software.
Modelo de la cascada	Sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado Image: E (binary/octet-stream)
Modelos de proceso incremental	Se centra en que en cada incremento se entrega un producto que ya opera. Los primeros incrementos son versiones desnudas del producto final, pero proporcionan capacidad que sirve al usuario y también le dan una plataforma de evaluación. Image: F (binary/octet-stream)
Modelos de proceso evolutivo	Es iterativo y se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software. Los modelos más comunes son: Hacer Prototipos. El modelo espiral. Image: G (binary/octet-stream)
Modelos concurrentes	Permite que un equipo de software represente elementos iterativos y concurrentes de cualquiera de los modelos. Por ejemplo, la actividad de modelado definida para el modelo espiral se logra por medio de invocar una o más de las siguientes acciones de software: hacer prototipos, análisis y diseño Image: H (binary/octet-stream)
Modelos de proceso especializados	Desarrollo basado en componentes. métodos formales. Desarrollo de software orientado a aspectos.
Fases del proceso unificado	El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Image: I (binary/octet-stream)
Proceso personal del software (PPS)	Pone el énfasis en la medición personal tanto del producto del trabajo que se genera como de su calidad. Además, responsabiliza al profesional acerca de la planeación del proyecto (por ejemplo, estimación y programación de actividades) y delega en el practicante el poder de controlar la calidad de todos los productos del trabajo de software que se desarrollen.
El modelo del PPS define cinco actividades estructurales	Planeación. Diseño de alto nivel. Revisión del diseño de alto nivel. Desarrollo. Post mortem.
Proceso del equipo de software (PES)	Formar equipos autodirigidos que planeen y den seguimiento a su trabajo, que establezcan metas y que sean dueños de sus procesos y planes. Éstos pueden ser equipos de software puros o de productos integrados (EPI) constituidos por 3 a 20 ingenieros. Mostrar a los gerentes cómo dirigir y motivar a sus equipos y cómo ayudarlos a mantener un rendimiento máximo. Acelerar la mejora del proceso del software, haciendo del modelo de madurez de la capacidad, CMM,23 nivel 5, el comportamiento normal y esperado. Brindar a las organizaciones muy maduras una guía para la mejora. Facilitar la enseñanza universitaria de aptitudes de equipo con grado industrial.
El PES define las siguientes actividades estructurales	Inicio del proyecto. diseño de alto nivel. implementación. integración. pruebas. post mortem.
Principios de agilidad	1. La prioridad más alta es satisfacer al cliente a través de la entrega pronta y continua de software valioso. 2. Son bienvenidos los requerimientos cambiantes, aun en una etapa avanzada del desarrollo. Dominan el cambio para provecho de la ventaja competitiva del cliente. 3. Entregar con frecuencia software que funcione, de dos semanas a un par de meses, de preferencia lo más pronto que se pueda. 4. Las personas de negocios y los desarrolladores deben trabajar juntos, a diario y durante todo el proyecto. 5. Hay que desarrollar los proyectos con individuos motivados. Debe darse a éstos el ambiente y el apoyo que necesiten, y confiar en que harán el trabajo. 6. El método más eficiente y eficaz para transmitir información a los integrantes de un equipo de desarrollo, y entre éstos, es la conversación cara a cara. 8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante.
Características clave que debe compartir el equipo ágil como tal	Competencia. Enfoque común. Colaboración. Habilidad para tomar decisiones. Capacidad para resolver problemas difusos. Confianza y respeto mutuos. Organización propia
El proceso XP	Usa un enfoque orientado a objetos como paradigma preferido de desarrollo, y engloba un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades estructurales: planeación, diseño, codificación y pruebas Image: J (binary/octet-stream)
Desarrollo adaptativo de software (DAS)	Fue concebida como una técnica para elaborar software y sistemas complejos. Los fundamentos filosóficos se centran en la colaboración humana y en la organización propia del equipo. Image: K (binary/octet-stream)
Scrum	Los principios son congruentes con el manifiesto ágil y se utilizan para guiar actividades de desarrollo dentro de un proceso de análisis que incorpora las siguientes actividades estructurales: requerimientos, análisis, diseño, evolución y entrega. Dentro de cada actividad estructural, las tareas del trabajo ocurren con un patrón del proceso llamado sprint. Image: L (binary/octet-stream)
Método de desarrollo de sistemas dinámicos (MDSD)	Es un enfoque de desarrollo ágil de software que “proporciona una estructura para construir y dar mantenimiento a sistemas que cumplan restricciones apretadas de tiempo mediante la realización de prototipos incrementales en un ambiente controlado de proyectos”. La filosofía está tomada de una versión modificada de la regla de Pareto: 80 por ciento de una aplicación puede entregarse en 20 por ciento del tiempo que tomaría entregarla completa (100 por ciento).
Cristal	Fin de obtener un enfoque de desarrollo de software que premia la “maniobrabilidad” durante lo que se caracteriza como “un juego cooperativo con recursos limitados, de invención y comunicación, con el objetivo primario de entregar software útil que funcione y con la meta secundaria de plantear el siguiente juego”
Desarrollo impulsado por las características (DIC)	Pone el énfasis en las actividades de aseguramiento de la calidad del software mediante el estímulo de la estrategia de desarrollo incremental, el uso de inspecciones del diseño y del código, la aplicación de auditorías de aseguramiento de la calidad del software, el conjunto de mediciones y el uso de patrones (para el análisis, diseño y construcción). Image: M (binary/octet-stream)
Desarrollo esbelto de software (DES)	Los principios que inspiran al proceso DES se resumen como sigue: eliminar el desperdicio, generar calidad, crear conocimiento, aplazar el compromiso, entregar rápido, respetar a las personas y optimizar al todo.
Modelado ágil (MA)	Es una metodología basada en la práctica para modelar y documentar con eficacia los sistemas basados en software. En pocas palabras, es un conjunto de valores, principios y prácticas para hacer modelos de software aplicables de manera eficaz y ligera a un proyecto de desarrollo de software. Los modelos ágiles son más eficaces que los tradicionales porque son sólo buenos, sin pretender ser perfectos.
El proceso unificado ágil (PUA)	Adopta una filosofía “en serie para lo grande” e “iterativa para lo pequeño” a fin de construir sistemas basados en computadora.
Principios que guían el proceso	1. Ser ágil. 2. En cada etapa, centrarse en la calidad. 3. Estar listo para adaptar. 4. Formar un equipo eficaz. 5. Establecer mecanismos para la comunicación y coordinación. 6. Administrar el cambio 7. Evaluar el riesgo. 8. Crear productos del trabajo que agreguen valor para otros.
Principios que guían la práctica	1. Divide y vencerás. 2. Entender el uso de la abstracción. 3. Buscar la coherencia. 4. Centrarse en la transferencia de información. 5. Construir software que tenga modularidad eficaz. 6. Buscar patrones. 7. Cuando sea posible, representar el problema y su solución desde varias perspectivas diferentes. 8. Tener en mente que alguien dará mantenimiento al software.
Principios de comunicación	1. Escuchar. 2. Antes de comunicarse, prepararse. 3. Alguien debe facilitar la actividad. 4. Es mejor la comunicación cara a cara. 5. Tomar notas y documentar las decisiones. 6. Perseguir la colaboración. 7. Permanecer centrado; hacer módulos con la discusión. 8. Si algo no está claro, hacer un dibujo. 9. a) Una vez que se acuerde algo, avanzar. b) Si no es posible ponerse de acuerdo en algo, avanzar. c) Si una característica o función no está clara o no puede aclararse en el momento, avanzar. 10. La negociación no es un concurso o un juego. Funciona mejor cuando las dos partes ganan.
Principios de planeación	1. Entender el alcance del proyecto. 2. Involucrar en la actividad de planeación a los participantes del software. 3. Reconocer que la planeación es iterativa. 4. Estimar con base en lo que se sabe. 5. Al definir el plan, tomar en cuenta los riesgos. 6. Ser realista. 7. Ajustar la granularidad cuando se defina el plan. 8. Definir cómo se trata de asegurar la calidad. 9. Describir cómo se busca manejar el cambio. 10. Dar seguimiento al plan con frecuencia y hacer los ajustes que se requieran.
Principios de modelado	1. El equipo de software tiene como objetivo principal elaborar software, no crear modelos. 2. Viajar ligero, no crear más modelos de los necesarios. 3. Tratar de producir el modelo más sencillo que describa al problema o al software. 4. Construir modelos susceptibles al cambio. 5. Ser capaz de enunciar un propósito explícito para cada modelo que se cree. 6. Adaptar los modelos que se desarrollan al sistema en cuestión. 7. Tratar de construir modelos útiles, pero olvidarse de elaborar modelos perfectos. 8. No ser dogmático respecto de la sintaxis del modelo. Si se tiene éxito para comunicar contenido, la representación es secundaria. 9. Si su instinto dice que un modelo no es el correcto a pesar de que se vea bien en el papel, hay razones para estar preocupado. 10. Obtener retroalimentación tan pronto como sea posible.
Despliegue de la función de calidad	-Requerimientos normales. Objetivos y metas que se establecen para un producto o sistema durante las reuniones con el cliente. Si estos requerimientos están presentes, el cliente queda satisfecho. -Requerimientos esperados. Están implícitos en el producto o sistema y quizá sean tan importantes que el cliente no los mencione de manera explícita. Su ausencia causará mucha insatisfacción. -Requerimientos emocionantes. Estas características van más allá de las expectativas del cliente y son muy satisfactorias si están presentes
Diagrama de caso de uso de UML	Proporciona formatos y mecanismos automatizados para evaluar la claridad y consistencia. Image: N (binary/octet-stream)
Diagramas de actividad del UML para indagar los requerimientos	El análisis global de los requisitos de una aplicación es un proceso de conceptualización y formulación de los conceptos que involucra de forma concreta. Es una parte fundamental del proceso de desarrollo de una aplicación, la mayor parte de los defectos encontrados en el software entregado se originan en la fase de análisis de requisitos, y además son los mas caros de reparar. Image: O (binary/octet-stream)
Diagrama de clase	Image: P (binary/octet-stream)
Notación UML del diagrama de estado	Image: Q (binary/octet-stream)
El modelo de requerimientos	El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que ofrecerá desde la perspectiva del usuario. El modelo de requisitos es el primer modelo en desarrollarse y es la base para formar todos los demás modelos en el desarrollo de software.
Elementos del modelo de análisis	Image: R (binary/octet-stream)
Representación tabular de objetos de datos	Image: S (binary/octet-stream)
Relaciones entre objetos de datos	Image: T (binary/octet-stream)
Una clase agregada compuesta	Image: T (binary/octet-stream)
Multiplicidad	Image: U (binary/octet-stream)
Dependencias	Image: U2 (binary/octet-stream)
Paquetes	Image: U3 (binary/octet-stream)
Diagrama de estado	Image: U4 (binary/octet-stream)
Diagrama de secuencia	Image: U5 (binary/octet-stream)
Árbol de datos para el componente	Image: U6 (binary/octet-stream)
Diagrama de actividades	Image: U7 (binary/octet-stream)
Traducción del modelo de requerimientos al modelo de diseño	Image: U8 (binary/octet-stream)
Abstracción	En el más elevado se enuncia una solución en términos gruesos con el uso del lenguaje del ambiente del problema. En los niveles más bajos se da la descripción más detallada de la solución.
Arquitectura	Es la estructura de organización de los componentes de un programa (módulos), la forma en la que éstos interactúan y la estructura de datos que utilizan.
Patrones	El objetivo es proporcionar una descripción que permita a un diseñador determinar 1) si el patrón es aplicable al trabajo en cuestión, 2) si puede volverse a usar (con lo que se ahorra tiempo de diseño) y 3) si sirve como guía para desarrollar distintas funciones o estructura.
División de problemas	Sugiere que cualquier problema complejo puede manejarse con más facilidad si se subdivide en elementos susceptibles de resolverse u optimizarse de manera independiente.
Modularidad	Es la manifestación más común de la división de problemas. El software se divide en componentes con nombres distintos y abordables por separado, que se integran para satisfacer los requerimientos del problema.
Independencia funcional	Es resultado directo de la separación de problemas y de los conceptos de abstracción y ocultamiento de información.
Ocultamiento de información	Implica que el modularidad efectivo se logra definiendo un conjunto de módulos independientes que intercambien sólo aquella información necesaria para lograr la función del software. La abstracción ayuda a definir las entidades de procedimiento (o informativas) que constituyen el software. Define y hace cumplir las restricciones de acceso tanto a los detalles de procedimiento como a cualquier estructura de datos local que utilice el módulo.
Refinamiento	Es un proceso de elaboración. Se comienza con un enunciado de la función (o descripción de la información), definida en un nivel de abstracción alto. Es decir, el enunciado describe la función o información de manera conceptual, pero no dice nada sobre los trabajos internos de la función o de la estructura interna de la información.
Aspectos	Surge un conjunto de “preocupaciones” que “incluyen requerimientos, casos de uso, características, estructuras de datos, calidad del servicio, variantes, fronteras de las propiedades intelectuales, colaboraciones, patrones y contratos”. Idealmente, un modelo de requerimientos se organiza de manera que permita aislar cada preocupación (requerimiento) a fin de considerarla en forma independiente.
Rediseño	Técnica de reorganización que simplifica el diseño (o código) de un componente sin cambiar su función o comportamiento. “Es el proceso de cambiar un sistema de software en forma tal que no se altera el comportamiento externo del código, pero sí se mejora su estructura interna.”
Elementos del diseño de datos	Crea un modelo de datos o información que se representa en un nivel de abstracción elevado (el punto de vista del usuario de los datos). Este modelo de los datos se refina después en forma progresiva hacia representaciones más específicas de la implementación que puedan ser procesadas por el sistema basado en computadora
Elementos del diseño arquitectónico	Dan la visión general del software
Elementos de diseño de la interfaz	Detalladas para las puertas, ventanas e instalaciones de una casa.
Elementos del diseño en el nivel de los componentes	Es el equivalente de los planos (y especificaciones) detallados de cada habitación de la casa.
Elementos del diseño del despliegue	Indican la forma en la que se acomodarán la funcionalidad del software y los subsistemas dentro del ambiente físico de la computación que lo apoyará.
CALIDAD DEL SOFTWARE	Proceso eficaz de software que se aplica de manera que crea un producto útil que proporciona valor medible a quienes lo producen y a quienes lo utilizan.
Factores de la calidad de McCall	- Corrección. - Confiabilidad. - Eficiencia. - Integridad. - Usabilidad. - Facilidad de recibir mantenimiento. - Flexibilidad. - Portabilidad. - Reusabilidad. - Interoperabilidad.
Factores de la calidad ISO 9126	- Funcionalidad. - Confiabilidad. - Usabilidad. - Eficiencia. - Facilidad de recibir mantenimiento. - Portabilidad.
Factores de calidad que se persiguen	- Intuitiva. - Eficiencia - Robustez. - Riqueza.
LOGRAR LA CALIDAD DEL SOFTWARE	- Métodos de la ingeniería de software - Técnicas de administración de proyectos - Control de calidad - Aseguramiento de la calidad
ELEMENTOS DE ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE	- Estándares. - Revisiones y auditorías. - Pruebas. - Colección y análisis de los errores. - Administración del cambio. - Educación. - Administración de los proveedores. - Administración de la seguridad.
Tareas del ACS	Es auxiliar al equipo del software para lograr un producto final de alta calidad. El Instituto de Ingeniería de Software recomienda un conjunto de acciones que se dirigen a la planeación, supervisión, registro, análisis y elaboración de reportes para el aseguramiento de la calidad.
Seis Sigma ( DMAMC )	- Definir los requerimientos del cliente y los que se le entregan, así como las metas del proyecto a través de métodos bien definidos de comunicación con el cliente. - Medir el proceso existente y su resultado para determinar el desempeño actual de la calidad (recabar métricas para los defectos). - Analizar las métricas de los defectos y determinar las pocas causas vitales. Si se trata de un proceso de software existente que se requiere mejorar. - Mejorar el proceso, eliminando las causas originales de los defectos. - Controlar el proceso para asegurar que el trabajo futuro no vuelva a introducir las causas de los defectos.
Mediciones de la confiabilidad	Si se considera un sistema basado en computadora, una medida sencilla es el tiempo medio entre fallas (TMEF): TMEF = TMPF + TMPR donde las siglas TMPF y TMPR significan tiempo medio para la falla y tiempo medio para la reparación.
La disponibilidad del software	(TMPF/(TMPF + TMPR)) * 100%
LAS NORMAS DE CALIDAD ISO 9000	Un sistema de aseguramiento de la calidad se define como la estructura organizacional, responsabilidades, procedimientos, procesos y recursos necesarios para implementar la administración de la calidad.

Next up

Diseño y Gestión de Sistemas

Description

Resource summary

Similar

	Created by Daniel Dominguez C over 6 years ago