Egal-Isoft B - Desarrollo E Implantación De Aplicaciones

Inicio

Introducción

Instrucciones (programas de cómputo) que cuando se ejecutan proporcionan las características, función y desempeño buscados.

Estructuras de datos que permiten que los programas manipulen en forma adecuada la información.

Información descriptiva tanto en papel como en formas virtuales que describen la operación y uso de los programas.

El software se desarrolla o modifica, no se manufactura; no se desgasta; la mayor parte se construye para uso individual.

Inicio

1) Mantenimiento, 2) Confiabilidad/seguridad, 3) Eficiencia y 4) Aceptabilidad.

El software debe escribirse de tal forma que pueda evolucionar para satisfacer las necesidades cambiantes de los clientes.

Incluye un rango de características que abarcan fiabilidad, seguridad y protección

Incluye capacidad de respuesta, tiempo de procesamiento, utilización de memoria, etc.

Debe ser aceptable al tipo de usuarios para quienes se diseña. Esto significa que necesita ser comprensible, utilizable y compatible con otros sistemas que ellos usan.

Secuencia de actividades que conducen a la elaboración de un producto de software

Especificación, Desarrollo, Validación y Evolución

En esta actividad los clientes e ingenieros definen el software que se producirá y las restricciones en su operación.

También llamada ingeniería de requerimientos consisten en el proceso de comprender y definir qué servicios se requieren del sistema, así como la identificación de las restricciones sobre la operación y el desarrollo del sistema.

1) Estudio de factibilidad, 2) Obtención y análisis de requerimientos, 3) Especificación de requerimientos y 4) Validación de requerimientos.

En esta actividad se diseña y programa el software. Corresponde al proceso de convertir una especificación del sistema en un sistema ejecutable.

Un diseño de software se entiende como una descripción de la estructura del software que se va a implementar, los modelos y las estructuras de datos utilizados por el sistema, las interfaces entre componentes del sistema y, en ocasiones, los algoritmos usados.

Diseño arquitectónico, Diseño de Interfaz, Diseño de Componentes, Diseño de Base de Datos, etc.

Es la actividad en la cual se verifica el software para asegurar que sea lo que el cliente requiere.

Las pruebas del programa, donde el sistema se ejecuta a través de datos de prueba simulados, son la principal técnica de validación. Esta última también puede incluir procesos de comprobación, como inspecciones y revisiones en cada etapa del proceso de software, desde la definición de requerimientos del usuario hasta el desarrollo del programa.

Prueba de desarrollo, Pruebas del sistema y Pruebas de aceptación.

En esta actividad se modifica el software para reflejar los requerimientos cambiantes del cliente y del mercado.

C++\nObjective C\nJava\nSmalltalk\nEiffel\nLexico (en castellano)\nRuby\nPython\nSDK\nOCAML\nObject Pascal\nCLIPS\nActionscript\nCOBOL\nPauscal [En español]\nPerl\nC#\nVisual Basic.NET\nPHP\nSimula\nDelphi\nPowerBuilder\nMaya\nPython

Conjunto de programas escritos para dar servicio a otros programas. (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.

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.

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.

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).

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).

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.

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.

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.

Uso intensivo de redes, Concurrencia, Carga impredecible, Rendimiento, Disponibilidad, Orientadas a los datos, Contenido sensible, Evolución continua, Inmediatez, Seguridad,Estética.

Comunicación.
Planeación.
Modelado.
Construcción.
Despliegue.

Son actividades complementarias tales como: 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.

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.

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).

Proporciona un modelo de cinco fases para evaluar el proceso: Inicio, Diagnóstico, Establecimiento, Actuación y Aprendizaje.

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.

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.

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.

Modelos de Proceso

Es una descripción simplificada de un proceso de software que presenta una visión de ese proceso.

1) Modelo de Flujo de Trabajo, 2) Modelo de flujo de Datos, 3) Modelo de Rollación.

Muestra la secuencia de actividades en el proceso junto con sus entradas, salidas y dependencias.

Representa el proceso como un conjunto de actividades, cada una de las cuales realiza alguna transformación en los datos.

Representa los roles de las personas involucradas en el proceso del software y las actividades de las que son responsables.

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. //mmz-study.netdna-ssl.com/2/images/upload-flashcards/52/66/86/15526686_m.jpg

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.

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.

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 //mmz-study.netdna-ssl.com/2/images/upload-flashcards/52/69/65/15526965_m.jpg

Desarrollo basado en componentes, métodos formales, Desarrollo de software orientado a aspectos.

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.

Planeación.
Diseño de alto nivel.
Revisión del diseño de alto nivel.
Desarrollo.
Post mórtem.

Formar equipos auto-dirigidos 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.

Inicio del proyecto.
Diseño de alto nivel.
Implementación.
Integración.
Pruebas.
Post mórtem.

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.

Competencia.
Enfoque común.
Colaboración.
Habilidad para tomar decisiones.
Capacidad para resolver problemas difusos. Confianza y respeto mutuos.
Organización propia.

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.

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.

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.

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).

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”

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). //mmz-study.netdna-ssl.com/2/images/upload-flashcards/69/61/79/16696179_m.png

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.

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.

Adopta una filosofía “en serie para lo grande” e “iterativa para lo pequeño” a fin de construir sistemas basados en computadora.

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.

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.

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.

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.

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.

–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

Pproporciona formatos y mecanismos automatizados para evaluar la claridad y consistencia.

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/30/73/16703073_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/30/85/16703085_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/31/03/16703103_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/31/33/16703133_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/31/63/16703163_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/31/93/16703193_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/31/96/16703196_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/32/26/16703226_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/32/35/16703235_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/32/47/16703247_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/33/97/16703397_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/34/48/16703448_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/35/02/16703502_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/35/29/16703529_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/35/38/16703538_m.png

//mmz-study.netdna-ssl.com/2/images/upload-flashcards/70/35/98/16703598_m.png

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.

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.

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.

Sugiere que cualquier problema complejo puede manejarse con más facilidad si se subdivide en elementos susceptibles de resolverse u optimizarse de manera independiente.

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.

Es resultado directo de la separación de problemas y de los conceptos de abstracción y ocultamiento de información.

Implica que la modularidad efectiva 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.

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.

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.

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.”

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

Dan la visión general del software. El diseño de la arquitectura del software es el equivalente del plano de una casa

Los elementos de diseño de la interfaz del software permiten que la información fluya hacia adentro y afuera del sistema, y cómo están comunicados los componentes que son parte de la arquitectura. Es análogo al conjunto de trazos (y especificaciones) detalladas para las puertas, ventanas e instalaciones de una casa.

Describe por completo los detalles internos de cada componente. Es el equivalente de los planos (y especificaciones) detallados de cada habitación de la casa.

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á.

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.

– Corrección.
- Confiabilidad.
– Eficiencia.
– Integridad.
– Usabilidad.
– Facilidad de recibir mantenimiento.
– Flexibilidad.
– Portabilidad.
– Reusabilidad.
– Interoperabilidad.

– Funcionalidad.
– Confiabilidad.
– Usabilidad.
– Eficiencia.
– Facilidad de recibir mantenimiento.
– Portabilidad.

– Intuitiva.
– Eficiencia
– Robustez.
– Riqueza.

– Métodos de la ingeniería de software
– Técnicas de administración de proyectos
– Control de calidad
– Aseguramiento de la calidad

– 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.

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.

– 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.

Si se considera un sistema basado en computadora, una medida sencilla es el tiempo medio entre fallas (TMEF):\nTMEF = TMPF + TMPR\ndonde las siglas TMPF y TMPR significan tiempo medio para la falla y tiempo medio para la reparación.

(TMPF/(TMPF + TMPR)) * 100%

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.

Arquitectura del Software

Se interesa por entender cómo debe organizarse un sistema y cómo tiene que diseñarse la estructura global de ese sistema. Es la primera etapa en el proceso de diseño del software.

Es el enlace crucial entre el diseño y la ingeniería de requerimientos, ya que identifica los principales componentes estructurales en un sistema y la relación entre ellos.

Describe la forma en que se organiza el sistema como un conjunto de componentes en comunicación.

Es importante porque afecta el desempeño y la potencia, así como la capacidad de distribución y mantenimiento de un sistema.

1) Comunicación con los participantes 2) Análisis del sistema y 3) Reutilización a gran escala

Es una descripción corta y manejable de cómo se organiza un sistema y cómo interoperan sus componentes. Las arquitecturas de sistemas se modelan con frecuencia usando diagramas de bloques Simples. Cada recuadro en el diagrama representa un componente.

Debido a la estrecha relación entre los requerimientos no funcionales y la arquitectura de software, el estilo y la estructura arquitectónicos particulares que se elijan para un sistema dependerán de los requerimientos de sistema no funcionales.

Sugiere que deben existir cuatro vistas (lógica, de proceso, de desarrollo y física) arquitectónicas fundamentales, que se relacionan usando casos de uso o escenarios.

Indica las abstracciones clave en el sistema como objetos o clases de objeto. En este tipo de vista se tienen que relacionar los requerimientos del sistema con entidades.

Muestra cómo, en el tiempo de operación, el sistema está compuesto de procesos en interacción. Esta vista es útil para hacer juicios acerca de las características no funcionales del sistema, como el rendimiento y la disponibilidad.

Muestra cómo el software está descompuesto para su desarrollo, esto es, indica la descomposición del software en elementos que se implementen mediante un solo desarrollador o equipo de desarrollo. Esta vista es útil para administradores y programadores de software.

Expone el hardware del sistema y cómo los componentes de software se distribuyen a través de los procesadores en el sistema. Esta vista es útil para los ingenieros de sistemas que planean una implementación de sistema.

Se puede considerar como una descripción abstracta estilizada de buena práctica, que se ensayó y puso a prueba en diferentes sistemas y entornos. Captan la esencia de una arquitectura que se usó en diferentes sistemas de software.

Incluyen el modelo de vista del controlador (MVC), arquitectura en capas, repositorio, cliente-servidor y tubería y filtro.

Organiza el sistema en capas con funcionalidad relacionada con cada capa. Una capa da servicios a la capa de encima, de modo que las capas de nivel inferior representan servicios núcleo que es probable se utilicen a lo largo de todo el sistema.

Se usa al construirse nuevas facilidades encima de los sistemas existentes; cuando el desarrollo se dispersa a través de varios equipos de trabajo, y cada uno es responsable de una capa de funcionalidad; cuando exista un requerimiento para seguridad multinivel.

Permite la sustitución de capas completas en tanto se conserve la interfaz. Para aumentar la confiabilidad del sistema, en cada capa pueden incluirse facilidades redundantes (por ejemplo, autenticación).

En la práctica, suele ser difícil ofrecer una separación limpia entre capas, y es posible que una capa de nivel superior deba interactuar directamente con capas de nivel inferior, en vez de que sea a través de la capa inmediatamente abajo de ella. El rendimiento suele ser un problema, debido a múltiples niveles de interpretación de una solicitud de servicio mientras se procesa en cada capa.

Todos los datos en un sistema se gestionan en un repositorio central, accesible a todos los componentes del sistema. Los componentes no interactúan directamente, sino tan sólo a través del repositorio.

La funcionalidad del sistema se organiza en servicios, y cada servicio lo entrega un servidor independiente. Los clientes son usuarios de dichos servicios y para utilizarlos ingresan a los servidores.

Se usa cuando, desde varias ubicaciones, se tiene que ingresar a los datos en una base de datos compartida. Como los servidores se pueden replicar, también se usan cuando la carga de un sistema es variable.

La principal ventaja de este modelo es que los servidores se pueden distribuir a través de una red. La funcionalidad general (por ejemplo, un servicio de impresión) estaría disponible a todos los clientes, así que no necesita implementarse en todos los servicios.

Cada servicio es un solo punto de falla, de modo que es susceptible a ataques de rechazo de servicio o a fallas del servidor. El rendimiento resultará impredecible porque depende de la red, así como del sistema. Quizás haya problemas administrativos cuando los servidores sean propiedad de diferentes organizaciones.

Éste es un modelo de la organización en tiempo de operación de un sistema, donde las transformaciones funcionales procesan sus entradas y producen salidas. Los datos fluyen de uno a otro y se transforman conforme se desplazan a través de la secuencia. Cada paso de procesamiento se implementa como un transformador. Los datos de entrada fluyen por medio de dichos transformadores hasta que se convierten en salida.

Factores en común condujeron al desarrollo de arquitecturas de software que describen la estructura y la organización de tipos particulares de sistemas de software.

(TP = Transaction Processing ) Están diseñados para procesar peticiones del usuario mediante la información de una base de datos, o los requerimientos para actualizar una base de datos.

Es una secuencia de operaciones que se trata como una sola unidad (una unidad atómica). Todas las operaciones en una transacción tienen que completarse antes de que sean permanentes los cambios en la base de datos. Esto garantiza que la falla en las operaciones dentro de la transacción no conduzca a inconsistencias en la base de datos.

Modelado de Datos

Es parte del modelado general de los requerimientos. El modelado de datos se utiliza para describir el espacio de información que será construido o manipulado por el software.

El modelado de datos comienza con la representación de los objetos de datos —información compuesta que debe ser entendida por el software—. Se identifican los atributos de cada objeto de datos y se describen las relaciones entre estos objetos.

Es una representación de información compuesta que debe ser entendida por el software. Un objeto de datos puede ser una entidad externa (por ejemplo, cualquier cosa que produzca o consuma información), una cosa (por ejemplo, un informe o pantalla), una ocurrencia (como una llamada telefónica) o evento (por ejemplo, una alarma), un rol (un vendedor), una unidad organizacional (por ejemplo, el departamento de contabilidad), un lugar (como una bodega) o estructura (como un archivo).

Contiene sólo datos —dentro de él no hay referencia a las operaciones que se apliquen sobre los datos—. Entonces, el objeto de datos puede representarse en forma de tabla.

Definen las propiedades de un objeto de datos y tienen una de tres diferentes características. Se usan para 1) nombrar una instancia del objeto de datos, 2) describir la instancia o 3) hacer referencia a otra instancia en otra tabla.

Es un identificador de uno o más de los atributos —es decir, se convierte en una “llave” cuando se desea encontrar una instancia del objeto de datos—.

Los objetos de datos están conectados entre sí de diferentes maneras. Considere dos objetos de datos, persona y auto. Se establece una conexión entre persona y auto porque ambos objetos están relacionados.

La pareja objeto-relación es la piedra angular del modelo de datos. Estas parejas se representan gráficamente con el uso del diagrama entidad-relación (DER).

El propósito principal del DER es representar objetos de datos y sus Relaciones.

Se caracteriza con frecuencia dentro del contexto de la ingeniería de software orientada a objetos. Los pasos de este proceso se definen como sigue:
1. Definir el dominio que se va a investigar.
2. Clasificar los aspectos extraídos del dominio.
3. Reunir una muestra representativa de aplicaciones en el dominio.
4. Analizar cada aplicación en la muestra y definir clases de análisis.
5. Desarrollar un modelo de los requerimientos para las clases.

Es la identificación, análisis y especificación de los requerimientos comunes, a partir de un dominio de aplicación específica, normalmente para usarlo varias veces en múltiples proyectos dentro del dominio de la aplicación

Representa los objetos que manipulará el sistema, las operaciones (también llamadas métodos o servicios) que se aplicarán a los objetos para efectuar la manipulación, las relaciones (algunas de ellas jerárquicas) entre los objetos y las colaboraciones que tienen lugar entre las clases definidas.

Herramientas de Desarrollo, Codificación del sistema, Probar la Solución Tecnológica y Adecuar el Modelo

La actividad de construcción incluye un conjunto de tareas de codificación y pruebas que lleva a un software operativo listo para entregarse al cliente o usuario final.

1) La creación directa de lenguaje de programación en código fuente (por ejemplo, Java), 2) la generación automática de código fuente que usa una representación intermedia parecida al diseño del componente que se va a construir o 3) la generación automática de código ejecutable que utiliza un “lenguaje de programación de cuarta generación” (por ejemplo, Visual C++).

Se relacionan de cerca con el estilo, lenguajes y métodos de programación. Sin embargo, puede enunciarse cierto número de principios fundamentales: Principios de Preparación y Principios de Programación.

Antes de escribir una sola línea de código, asegúrese de:
• Entender el problema que se trata de resolver.
• Comprender los principios y conceptos básicos del diseño.
• Elegir un lenguaje de programación que satisfaga las necesidades del software que se va a elaborar y el ambiente en el que operará.
• Seleccionar un ambiente de programación que disponga de herramientas que hagan más fácil su trabajo.
• Crear un conjunto de pruebas unitarias que se aplicarán una vez que se haya terminado el componente a codificar.

Cuando comience a escribir código, asegúrese de:
• Restringir sus algoritmos por medio del uso de programación estructurada.
• Tomar en consideración el uso de programación por parejas.
• Seleccionar estructuras de datos que satisfagan las necesidades del diseño.
• Entender la arquitectura del software y crear interfaces que son congruentes con ella.

• Mantener la lógica condicional tan sencilla como sea posible.
• Crear lazos anidados en forma tal que se puedan probar con facilidad.
• Seleccionar nombres significativos para las variables y seguir otros estándares locales de codificación.
• Escribir código que se documente a sí mismo.
. Crear una imagen visual (por ejemplo, líneas con sangría y en blanco) que ayude a entender.

Aquellos que desean un software en verdad confiable descubrirán que deben encontrar un medio para evitar de inicio la mayoría de los posibles errores; como resultado, el proceso de programación se hace más barato [...] los programadores eficaces no tienen que perder su tiempo depurando errores: no deben introducirlos al arrancar.

Validación de la solución tecnológica.

Las pruebas intentan demostrar que un programa hace lo que se intenta que haga, así como descubrir defectos en el programa antes de usarlo. Al probar el software, se ejecuta un programa con datos artificiales.

1. Demostrar al desarrollador y al cliente que el software cumple con los requerimientos y 2. Encontrar situaciones donde el comportamiento del software sea incorrecto, indeseable o no esté de acuerdo con su especificación.

Para el software personalizado, esto significa que en el documento de requerimientos debe haber, por lo menos, una prueba por cada requerimiento. Para los productos de software genérico, esto quiere decir que tiene que haber pruebas para todas las características del sistema, junto con combinaciones de dichas características que se incorporarán en la liberación del producto.

Tales situaciones son consecuencia de defectos del software. La prueba de defectos tiene la finalidad de erradicar el comportamiento indeseable del sistema, como caídas del sistema, interacciones indeseadas con otros sistemas, cálculos incorrectos y corrupción de datos.

La primera meta conduce a la prueba de validación; en ella, se espera que el sistema se desempeñe de manera correcta mediante un conjunto dado de casos de prueba, que refleje el uso previsto del sistema.

La segunda meta se orienta a pruebas de defectos, donde los casos de prueba se diseñan para presentar los defectos.

Edsger Dijkstra, uno de los primeros contribuyentes al desarrollo de la ingeniería de software dijo que: “ Las pruebas pueden mostrar sólo la presencia de errores, mas no su ausencia”.

Las pruebas se consideran parte de un proceso más amplio de verificación y validación (V&V) del software.

¿Construimos el producto correcto?

¿Construimos bien el producto?

Comprobar que el software cumpla con su funcionalidad y con los requerimientos no funcionales establecidos.

Garantizar que el software cumpla con las expectativas del cliente. Va más allá del simple hecho de comprobar la conformidad con la especificación, para demostrar que el software hace lo que el cliente espera que haga.

Se enfocan principalmente en el código fuente de un sistema, aun cuando cualquier representación legible del software, como sus requerimientos o modelo de diseño, logre inspeccionarse. Son una idea antigua y la mayoría de estudios y experimentos indican que las inspecciones son más efectivas para el descubrimiento de defectos, que para las pruebas del programa.

Por lo general, un sistema de software comercial debe pasar por tres etapas de pruebas: 1. Pruebas de desarrollo, 2. Versiones de prueba y 3. Pruebas de usuario.

Consiste en que el sistema se pone a prueba durante el proceso para descubrir errores (bugs) y defectos. Es probable que en el desarrollo de prueba intervengan diseñadores y programadores del sistema.

En ésta un equipo de prueba por separado experimenta una versión completa del sistema, antes de presentarlo a los usuarios. La meta de la prueba de versión es comprobar que el sistema cumpla con los requerimientos de los participantes del sistema.

Los usuarios reales o potenciales de un sistema prueban el sistema en su propio entorno.

Durante el desarrollo, las pruebas se realizan en tres niveles de granulación: 1. Pruebas de unidad, 2. Pruebas del componente y 3. Pruebas del sistema.

Donde se ponen a prueba unidades de programa o clases de objetos individuales. Las pruebas de unidad deben enfocarse en comprobar la funcionalidad de objetos o métodos.

Pruebas donde muchas unidades individuales se integran para crear componentes compuestos. La prueba de componentes debe enfocarse en probar interfaces del componente.

Pruebas donde algunos o todos los componentes en un sistema se integran y el sistema se prueba como un todo. Las pruebas del sistema deben enfocarse en poner a prueba las interacciones de los componentes.

Ajuste del producto de software desarrollado.

El desarrollo del software no se detiene cuando un sistema se entrega, sino que continúa a lo largo de la vida de éste. Después de distribuir un sistema, inevitablemente debe modificarse, con la finalidad de mantenerlo útil.

Tanto los cambios empresariales como los de las expectativas del usuario generan nuevos requerimientos para el software existente. Es posible que tengan que modificarse partes del software para corregir errores encontrados durante su operación, para adaptarlo a los cambios en su plataforma de software y hardware, y para mejorar su rendimiento u otras características no funcionales.

La evolución del software es importante porque las organizaciones invierten grandes cantidades de dinero en él y en la actualidad son completamente dependientes de dichos sistemas. Por consiguiente, la evolución de un sistema rara vez puede considerarse en aislamiento.

Además de comprender y analizar el impacto de un cambio propuesto sobre el sistema en sí, también es probable que se deba valorar cómo esto afectaría a otros sistemas en el entorno operacional.

La ingeniería de software se debe considerar como un proceso en espiral, con requerimientos, diseño, implementación y pruebas continuas, a lo largo de la vida del sistema porque, evidentemente los requerimientos de los sistemas instalados cambian conforme lo hacen el negocio y su entorno. Por consiguiente, se crean a intervalos regulares nuevas versiones de los sistemas, las cuales incorporan cambios y actualizaciones.

Implica que una sola organización es responsable tanto del desarrollo del software inicial como de la evolución del software. La mayoría de los productos de software empacados se desarrollan siguiendo este enfoque.

Por lo general se utiliza un enfoque diferente. Una compañía de software lo desarrolla para un cliente y, luego, el personal de desarrollo del propio cliente se hace cargo del sistema. Ellos son los responsables de la evolución del software.

Cuando la transición del desarrollo a la evolución no es uniforme, el proceso de cambiar el software después de la entrega se conoce como “mantenimiento de software”.

Desarrollo inicial -> Evolución -> Servicio -> Retiro gradual.

Los procesos de identificación de cambios y evolución del sistema son cíclicos y continúan a lo largo de la vida de un sistema

Peticiones de cambio -> Análisis del impacto -> Planeación de la versión -> Cambio de implementación -> Liberación del sistema.

Incluye actividades fundamentales de análisis del cambio, planeación de la versión, implementación del sistema y su liberación a los clientes.

La necesidad de realizar el cambio rápidamente significa que quizá no pueda seguir el proceso formal de análisis de cambio. En vez de modificar los requerimientos y el diseño, se puede hacer una reparación de emergencia al programa para resolver el problema de inmediato. Sin embargo, el riesgo es que los requerimientos, el diseño del software y el código se vuelvan inconsistentes.

Es posible que surjan problemas en situaciones donde haya transferencia de un equipo de desarrollo a un equipo separado responsable de la evolución. Existen dos situaciones potencialmente problemáticas:

Ocurre cuando el equipo de desarrollo haya usado un enfoque ágil, pero el equipo de evolución no esté familiarizado con los métodos ágiles y prefiera un enfoque basado en un plan.

Ocurre cuando se haya usado un enfoque basado en un plan para el desarrollo, pero el equipo de evolución prefiera usar métodos ágiles.

La dinámica de evolución del programa es el estudio del cambio al sistema.

Son enunciados relacionados al cambio del sistema que afirman que dichas “leyes” suelen ser verdaderas para todos los tipos de sistemas de software organizacional grandes (los llamados sistemas tipo E).

Un programa usado en un entorno real debe cambiar; de otro modo, en dicho entorno se volvería progresivamente inútil.

A medida que cambia un programa en evolución, su estructura tiende a volverse más compleja. Deben dedicarse recursos adicionales para conservar y simplificar su estructura.

La evolución del programa es un proceso auto-regulador. Los atributos del sistema, como tamaño, tiempo entre versiones y número de errores reportados, son casi invariantes para cada versión del sistema.

Durante la vida de un programa, su tasa de desarrollo es aproximadamente constante e independiente de los recursos dedicados al desarrollo del sistema.

A lo largo de la existencia de un sistema, el cambio incremental en cada liberación es casi constante.

La funcionalidad ofrecida por los sistemas tiene que aumentar continuamente para mantener la satisfacción del usuario.

La calidad de los sistemas declinará, a menos que se modifiquen para reflejar los cambios en su entorno operacional.

Los procesos de evolución incorporan sistemas de retroalimentación multiagente y multiciclo. Además, deben tratarse como sistemas de retroalimentación para lograr una mejora significativa del producto.

Es el proceso general de cambiar un sistema después de que éste se entregó. El término usualmente se aplica a software personalizado, en el que grupos de desarrollo separados intervienen antes y después de la entrega.

1) Reparaciones de fallas, 2) Adaptación ambiental y 3) Adición de funcionalidad.

De manera universal se usa el término “mantenimiento correctivo” para referirse al mantenimiento para reparación de fallas de desarrollo.

Algunas veces significa adaptarse a un nuevo entorno y otras veces significa adaptar el software a nuevos requerimientos.

A veces significa perfeccionar el software al implementar nuevos requerimientos;

Los estudios concuerdan ampliamente en que el mantenimiento del software toma una proporción más alta de presupuestos de TI que el nuevo desarrollo (casi dos tercios en mantenimiento y un tercio en desarrollo).

La reingeniería puede implicar volver a documentar el sistema, refactorizar su arquitectura, traducir los programas a un lenguaje de programación moderno, y modificar y actualizar la estructura y los valores de los datos del sistema.

Hay dos beneficios importantes de la reingeniería respecto de la sustitución: 1. Reducción del riesgo y 2. Reducción de costos

1. Traducción del código fuente, 2. Ingeniería inversa, 3. Mejoramiento de la estructura del programa, 4. Modularización del programa, 5. Reingeniería de datos.

Para hacer que el sistema con reingeniería interopere con el nuevo software, tal vez se tengan que desarrollar servicios adaptadores.

Existen límites prácticos en cuánto a mejorar un sistema gracias a la reingeniería. No es posible, por ejemplo, convertir un sistema escrito con un enfoque funcional, a un sistema orientado a objetos.

La refactorización es el proceso de hacer mejoras a un programa para frenar la degradación mediante el cambio. Ello significa modificar un programa para mejorar su estructura, reducir su complejidad o hacerlo más fácil de entender.

Aunque la reingeniería y la refactorización tienen la intención de hacer el software más fácil de entender y cambiar, no son lo mismo.

Se lleva a cabo después de haber mantenido un sistema durante cierto tiempo y, por consiguiente, los costos de mantenimiento aumentan. Se usan herramientas automatizadas para procesar y someter a reingeniería un sistema heredado y así crear un nuevo sistema que sea más mantenible.

Es un proceso continuo de mejoramiento debido al proceso de desarrollo y evolución. Tiene la intención de evitar la degradación de la estructura y el código que aumentan los costos y las dificultades por mantener un sistema.

Son situaciones estereotípicas (llamadas “malos olores”), en las cuales el código de un programa es susceptible de mejorarse, tales cómo: 1. Código duplicado, 2. Métodos largos, 3. Enunciados de switch (case), 4. Aglomeración de datos y 5. Generalidad especulativa.

Son sistemas empresariales críticos. Éstos tienen que extenderse y adaptarse a las cambiantes prácticas del comercio electrónico.

Esto requiere hacer una valoración realista de sus sistemas heredados y, luego, decidir acerca de la estrategia más adecuada para hacer evolucionar dichos sistemas: 1. Desechar completamente el sistema, 2. Dejar sin cambios el sistema y continuar el mantenimiento regular, 3. Someter el sistema a reingeniería para mejorar su mantenibilidad, 4. Sustituir todo o parte del sistema con un nuevo sistema.

Mantener estos sistemas en operación será costoso y la tasa de retorno para la empresa será bastante pequeña. Estos sistemas deben descartarse.

Estos sistemas realizan una importante aportación empresarial, de modo que no se pueden desechar. Sin embargo, su baja calidad significa que su mantenimiento resulta costoso. Dichos sistemas tienen que someterse a reingeniería para mejorar su calidad. Pueden sustituirse, si está disponible un sistema comercial adecuado.

Estos sistemas no aportan mucho a la empresa, pero su mantenimiento quizá no sea muy costoso. No vale la pena sustituir tales sistemas, así que puede continuarse el mantenimiento normal del sistema, si no se requieren cambios costosos y el hardware del sistema sigue en uso. Si los cambios costosos son necesarios, entonces el software puede desecharse.

Estos sistemas deben mantenerse en operación. Sin embargo, su alta calidad significa que no se tiene que invertir en transformación ni sustitución del sistema. Hay que continuar con el mantenimiento normal del sistema.