Flashcards

Diseño y Gestión de Sistemas

Daniel Dominguez C Espanhol 93 flashcards

Flashcards do conjunto (93)

1Lenguaje orientado a objetosC++
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
2Software de sistemaConjunto 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.
3Software de aplicaciónProgramas 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.
4Software de ingeniería y cienciasSe 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.
5Software incrustadoReside 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).
6Software de línea de productosEs 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).
7Aplicaciones webEsta 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.
8Software de inteligencia artificialHace 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.
9Software heredadoFueron 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.
10Software heredadoFueron 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.
11La gran mayoría de webapps presenta los siguientes atributosUso intensivo de redes.
Concurrencia.
Carga impredecible.
Rendimiento.
Disponibilidad.
Orientadas a los datos.
Contenido sensible.
Evolución continua.
Inmediatez.
Seguridad.
Estética.
12Una estructura de proceso general para la ingeniería de software consta de cinco actividadesComunicación.
Planeación.
Modelado.
Construcción.
Despliegue.
13Las actividades estructurales del proceso de ingeniería de software son complementadas por cierto número de actividades sombrillaSeguimiento 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.
14Actividades sombrillaEn 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
15La esencia de la práctica de la ingeniería de softwareEntender 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).
16Flujo de proceso lineal
17Flujo de proceso iterativo
18Flujo de proceso evolutivo
19Flujo de proceso paralelo
20Método de evaluación del estándar CMMI para el proceso de mejoraProporciona un modelo de cinco fases para evaluar el proceso: inicio, diagnóstico, establecimiento, actuación y aprendizaje.
21Evaluación basada en CMM para la mejora del proceso internoProporciona 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.
22SPICE (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.
23ISO9001:2000 para softwareEstá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.
24Modelo de la cascadaSugiere 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
25Modelos de proceso incrementalSe 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.
26Modelos de proceso evolutivoEs 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.
27Modelos concurrentesPermite 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
28Modelos de proceso especializadosDesarrollo basado en componentes.
métodos formales.
Desarrollo de software orientado a aspectos.
29Fases del proceso unificadoEl 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).
30Proceso 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.
31El modelo del PPS define cinco actividades estructuralesPlaneación.
Diseño de alto nivel.
Revisión del diseño de alto nivel.
Desarrollo.
Post mortem.
32Proceso 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.
33El PES define las siguientes actividades estructuralesInicio del proyecto.
diseño de alto nivel.
implementación.
integración.
pruebas.
post mortem.
34Principios de agilidad1. 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.
35Características clave que debe compartir el equipo ágil como talCompetencia.
Enfoque común.
Colaboración.
Habilidad para tomar decisiones.
Capacidad para resolver problemas difusos.
Confianza y respeto mutuos.
Organización propia
36El proceso XPUsa 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
37Desarrollo 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.
38ScrumLos 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.
39Mé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).
40CristalFin 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”
41Desarrollo 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).
42Desarrollo 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.
43Modelado á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.
44El 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.
45Principios que guían el proceso1. 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.
46Principios que guían la práctica1. 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.
47Principios de comunicación1. 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.
48Principios de planeación1. 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.
49Principios de modelado1. 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.
50Despliegue 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
51Diagrama de caso de uso de UMLProporciona formatos y mecanismos automatizados para evaluar la claridad y consistencia.
52Diagramas de actividad del UML para indagar los requerimientosEl 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.
53Diagrama de clase
54Notación UML del diagrama de estado
55El modelo de requerimientosEl 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.
56Elementos del modelo de análisis
57Representación tabular de objetos de datos
58Relaciones entre objetos de datos
59Una clase agregada compuesta
60Multiplicidad
61Dependencias
62Paquetes
63Diagrama de estado
64Diagrama de secuencia
65Árbol de datos para el componente
66Diagrama de actividades
67Traducción del modelo de requerimientos al modelo de diseño
68AbstracciónEn 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.
69ArquitecturaEs 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.
70PatronesEl 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.
71División de problemasSugiere que cualquier problema complejo puede manejarse con más facilidad si se subdivide en elementos susceptibles de resolverse u optimizarse de manera independiente.
72ModularidadEs 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.
73Independencia funcionalEs resultado directo de la separación de problemas y de los conceptos de abstracción y ocultamiento de información.
74Ocultamiento de informaciónImplica 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.
75RefinamientoEs 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.
76AspectosSurge 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.
77RediseñoTé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.”
78Elementos del diseño de datosCrea 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
79Elementos del diseño arquitectónicoDan la visión general del software
80Elementos de diseño de la interfazDetalladas para las puertas, ventanas e instalaciones de una casa.
81Elementos del diseño en el nivel de los componentesEs el equivalente de los planos (y especificaciones) detallados de cada habitación de la casa.
82Elementos del diseño del despliegueIndican 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á.
83CALIDAD DEL SOFTWAREProceso 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.
84Factores de la calidad de McCall- Corrección.
- Confiabilidad.
- Eficiencia.
- Integridad.
- Usabilidad.
- Facilidad de recibir mantenimiento.
- Flexibilidad.
- Portabilidad.
- Reusabilidad.
- Interoperabilidad.
85Factores de la calidad ISO 9126- Funcionalidad.
- Confiabilidad.
- Usabilidad.
- Eficiencia.
- Facilidad de recibir mantenimiento.
- Portabilidad.
86Factores de calidad que se persiguen- Intuitiva.
- Eficiencia
- Robustez.
- Riqueza.
87LOGRAR 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
88ELEMENTOS 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.
89Tareas del ACSEs 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.
90Seis 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.
91Mediciones de la confiabilidadSi 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.
92La disponibilidad del software(TMPF/(TMPF + TMPR)) * 100%
93LAS NORMAS DE CALIDAD ISO 9000Un 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.