1. MODELOS DEL PROCESO
1.1. Un modelo de proceso de software define cómo solucionar la problemática del desarrollo de sistemas de software. Para desarrollar el software se requiere resolver ciertas fases de su proceso, las cuales se conocen en su conjunto como el ciclo de vida
1.1.1. PROCESO DEL MODELO DEPENDIENDO EL TIPO PARTICULAR DEL PROYECTO
1.1.1.1. Primer proyecto de su tipo.
1.1.1.1.1. Se crea la mayoría del software desde cero.
1.1.1.2. Segundo proyecto de su tipo.
1.1.1.2.1. Se busca agregar una nueva funcionalidad a un proyecto conocido.
1.1.1.3. Variación de un proyecto.
1.1.1.3.1. Se extiende un sistema ya existente, lo cual involucra introducir componentes de software reutilizables como un marco de trabajo (framework), crear nuevos componentes o simplemente extender la aplicación existente mediante nueva funcionalidad.
1.1.1.4. Proyecto de reescritura de legado
1.1.1.4.1. Se busca transformar o hacer una “reingeniería” de un sistema ya existente, desarrollado bajo tecnologías anteriores, a un sistema desarrollado bajo nuevas tecnologías, tales como las orientadas a objetos.
1.1.1.5. Proyecto de creación de software reutilizable.
1.1.1.5.1. Se busca crear uno o más componentes de software reutilizables. Este tipo de proyecto es muy similar a otros proyectos de desarrollo de software, donde es necesario incluir los requisitos y desarrollar el diseño completo del componente.
1.1.1.6. Proyecto de mejora de sistema o mantenimiento
1.1.1.6.1. Se busca modificar los componentes básicos de un sistema para apoyar una nueva funcionalidad. Estos proyectos a menudo son relativamente pequeños, y afectan sólo parte del sistema.
2. ARQUITECTURA
2.1. Una arquitectura de software define la estructura general de un sistema y varía de acuerdo con el tipo de sistema a desarrollarse.
2.1.1. Transformación en lote (batch).
2.1.1.1. Son sistemas de transformación sobre un conjunto de entradas de valor constante, para generar un conjunto de salidas. Un ejemplo de un sistema de este tipo es un compilador.
2.1.2. Transformación continua.
2.1.2.1. Son sistemas de transformación sobre un conjunto de entradas de valor variable, que genera un conjunto de salidas que difieren en el tiempo. Ejemplos de éstos son los sistemas de control de señales.
2.1.3. Sistemas interactivos.
2.1.3.1. Son sistemas regidos por interacciones externas, por lo general, con un usuario. Estos sistemas son controlados por manejadores de eventos, encargados de procesar acontecimientos generados por el usuario, como un click del ratón o la presión de una tecla.
2.1.4. Simulación dinámica.
2.1.4.1. Son sistemas que simulan entidades del mundo real y evolucionan con el tiempo. Ejemplos de estos sistemas son simuladores de sistemas financieros, redes neuronales, etcétera.
2.1.5. Sistemas de tiempo real.
2.1.5.1. Son sistemas regidos por restricciones estrictas en el tiempo, que requieren garantías en el tiempo de respuesta. Ejemplos de estos sistemas son los controladores de procesos industriales y dispositivos de comunicación.
2.1.6. Administración de transacción.
2.1.6.1. Son sistemas para interactuar con bases de datos y que incluyen, por lo general, acceso concurrente y distribuido de múltiples usuarios. Ejemplos de estos sistemas son los de reservaciones de vuelos y los de control de inventario.
3. ACTIVIDAD
3.1. Una actividad es una unidad o paso básico de un proceso. En el proceso de software las actividades definen los pasos necesarios para lograr las metas y los objetivos; por ejemplo, especificar los requisitos del sistema.
3.1.1. ACTIVIDADES BASICAS EN EL PROCESO DE DESARROLLO DE SOFTWARE
3.1.1.1. requisitos
3.1.1.1.1. Se especifican las necesidades del sistema a desarrollar. La especificación de requisitos sirve como base para la negociación entre los desarrolladores y clientes del sistema, y también para planear y controlar el proceso de desarrollo.
3.1.1.2. analisis
3.1.1.2.1. Se busca comprender los requisitos del sistema con el propósito de estructurar la arquitectura del sistema.
3.1.1.3. Diseño
3.1.1.3.1. Se transforma la arquitectura obtenida durante el análisis en una arquitectura especializada, donde se considera el ambiente de implantación particular del sistema. Obedece al “cómo” del sistema.
3.1.1.4. Implementacion
3.1.1.4.1. e expresa la arquitectura del sistema en una forma aceptable para la computadora, o sea, el código.
3.1.1.5. Integracion
3.1.1.5.1. Se combinan los componentes creados de manera independiente para formar el sistema completo.
3.1.1.6. Pruebas
3.1.1.6.1. Se verifica y valida el sistema a nivel de componentes individuales y su integración. Este es uno de los aspectos más críticos del desarrollo y debe desarrollarse de manera concurrente al resto de las actividades. Se busca descubrir cualquier defecto en los requisitos, análisis, diseño, implementación e integración. Las pruebas se hacen a varios niveles, desde funciones sencillas hasta el sistema completo.
3.1.1.7. Documentacion
3.1.1.7.1. Se describen los aspectos sobresalientes de los requisitos, análisis, diseño, implementación, integración y pruebas. Esto servirá para usuarios externos e internos, aquellos encargados de mantener el sistema y extenderlo.
3.1.1.8. Mantenimiento
3.1.1.8.1. Se corrigen errores no encontrados durante el desarrollo y las pruebas originales del sistema. Se extiende el sistema si surgen nuevas necesidades.
4. METODOS Y METODOLOGIAS
4.1. Los métodos definen las reglas para las transformaciones internas de las actividades, mientras que las metodologías definen el conjunto de métodos.
4.1.1. ORIENTADAS A OBJETOS
4.1.1.1. Las metodologías orientadas a objetos se enfocan principalmente en el modelado de un sistema en términos de objetos.
5. ESTRUCTURAS
5.1. Las metodologías tradicionales o estructuradas se enfocan principalmente en la descomposición funcional de un sistema. El objetivo es lograr una definición completa del sistema en términos de funciones, estableciendo los datos de entrada y salida correspondientes.
5.1.1. HERRAMIENTAS DE MODELADO
5.1.1.1. Diagramas de flujo de datos.
5.1.1.1.1. Sirven para modelar la transformación de datos entre funciones del sistema. Un diagrama de flujo de datos se compone de procesos, flujo de datos, actores (entidades externas) y almacenamiento de datos.
5.1.1.2. Diagramas de transición de estados.
5.1.1.2.1. Sirven para modelar el comportamiento en el tiempo. Los diagramas de transición describen el efecto de eventos externos en los procesos y funciones.
5.1.1.3. Diagramas de entidad-relación.
5.1.1.3.1. Sirven para modelar un almacenamiento de datos.
5.1.1.4. Diagramas de clases.
5.1.1.4.1. Sirven para describir los componentes esenciales de la arquitectura de un sistema. A diferencia de los diagramas de flujo de datos, los diagramas de clases muestran relaciones de asociación entre clases y no flujo de datos entre ellas.
5.1.1.5. Diagramas de casos de uso.
5.1.1.5.1. Especifican un sistema en término de su funcionalidad. A diferencia de las metodologías estructuradas, los diagramas de casos de uso no son descompuestos en funciones de programación.
5.1.1.6. Diagramas de secuencia.
5.1.1.6.1. Sirven para describir los aspectos dinámicos del sistema, mostrando el flujo de eventos entre objetos en el tiempo.
5.1.1.7. Diagramas de colaboración.
5.1.1.7.1. Se utilizan para describir la comunicación entre objetos de un sistema.
5.1.1.8. Diagramas de subsistemas.
5.1.1.8.1. Se usan para describir agrupaciones de clases en un sistema.
6. COSTOS
6.1. DIRECTOS
6.1.1. El cual incluye el software empacado, sepuede adquirir en un negocio decomputación o por Internet; y elsoftware a la medida, que requiere un desarrollo especializado y adaptado a las necesidades particulares de una empresa.
6.2. INDIRECTOS
6.2.1. incluye aspectos como la capacitación, instalación, soporte técnico, así como otros costos que por lo general se pueden conocer de antemano.
6.3. OCULTOS
6.3.1. El costo oculto ocasionado principalmente por las fallas del software. A diferencia de los costos directos e indirectos, los cuales son previsibles, los costos ocultos por definición son difíciles de prever.
6.3.1.1. CONSCUENCIAS POR FALLAS DEL SOFWARE
6.3.1.1.1. Consecuencias inmediatas y efectos directos.
6.3.1.1.2. Consecuencias a mediano y largo plazo y efectos indirectos.
7. FACTORES EN LA COMPLEJIDAD DEL DESARROLLO DE SOFTWARE Y HARDWARE
7.1. La complejidad del problema: tiene que ver con la funcionalidad que el sistema debe brindar. Cuanto mayor sea el número de requerimientos o funcionalidad ofrecida por una aplicación, mayor será el tamaño del sistema, creando sistemas más difíciles de comprender y desarrollar. La complejidad radica en los aspectos intrínsecos del problema, o sea, sus requerimientos funcionales. Para reducir la complejidad habría que reducir la funcionalidad que el sistema deba
7.2. La complejidad de la solución: tiene que ver con el diseño del sistema, el cual debe satisfacer la funcionalidad del problema. Cuando la complejidad del problema es bastante grande y difícil de reducir, es muy importante reducir la otra fuente de complejidad: el de la solución, o sea, el software. Éste será el objetivo a lograr en este libro, reducir la complejidad del sistema de software.
7.3. El factor estático: corresponde a la funcionalidad que un sistema de software debe ofrecer al ser inicialmente desarrollado.
7.4. El factor dinámico: corresponde a la funcionalidad que varía con el tiempo, en otras palabras, con los posibles cambios en el sistema. Estos cambios pueden ser considerables y, en muchos casos, son la causa de los retrasos y cancelaciones de los proyectos. Es muy común que los requisitos de un sistema se modifiquen, incluso antes de completarlos.
8. PROGRAMACION Y LENGUAJES ORIENTADOS A OBJETOS
8.1. La programación orientada a objetos va más allá de los aspectos discutidos hasta el momento. En esta sección se describen aspectos adicionales de la programación orientada a objetos: a) Los aspectos que mejoran la calidad de los sistemas. b) Las características esenciales para que un lenguaje se considere orientado a objetos.
8.1.1. ASPECTOS QUE MEJORAN LA CALIDAD DE LOS SISTEMAS
8.1.1.1. ABSTRACCCION
8.1.1.1.1. la cual consiste en elevar el nivel de las representaciones necesarias para un sistema de software, de manera que se reduzcan los detalles.
8.1.1.2. MODULARIDAD
8.1.1.2.1. la cual permite dividir un sistema en componentes separados. Al contar con abstracciones de más alto nivel, la modularidad de un sistema se logra con base en componentes, también de más alto nivel. Esto reduce el número final de componentes en un sistema y, a su vez, facilita su operación y mantenimiento.
8.1.1.3. EXTENSIBILIDAD
8.1.1.3.1. la cual corresponde a la facilidad en modificar un sistema durante el transcurso de su vida.
8.1.1.4. REUTILIZACION
8.1.1.4.1. La reutilización o reúso de componentes es otro de los mecanismos importantes para administrar la complejidad del software. La reutilización reduce el tiempo de diseño, codificación y costo del sistema al amortizar el esfuerzo sobre varios desarrollos
9. CARACTERISTICAS ESENCIALES DE LOS LEGUAJES ORIENTADOS A OBJETOS
9.1. En esta sección describimos los conceptos básicos que hacen que un lenguaje sea considerado efectivamente orientado a objetos
9.1.1. ENCAPSULACION
9.1.1.1. El encapsulamiento es el mecanismo básico de la programación orientada a objetos para ocultar los detalles internos del objeto de los demás objetos.
9.1.2. CLASIFICACION
9.1.2.1. la clasificación permite organizar objetos de acuerdo con estructuras comunes. Los objetos con datos y funciones similares se clasifican como si fueran de una misma clase.Éstos podrán tener datos con valores distintos.
9.1.3. GENERALIZACION
9.1.3.1. Así como los objetos pueden organizarse como miembros de una misma clase, podemos también organizar a las propias clases de los objetos de acuerdo con sus datos y funciones comunes. Estas organizaciones se conocen como de generalización o especialización.
9.1.4. POLIMORFISMO
9.1.4.1. El polimorfismo es posiblemente el concepto más poderoso de la programación orientada a objetos, aunque también el más complicado. Mediante el polimorfismo se definen múltiples funciones con nombres e interfaces similares sólo que en distintas clases. Las funciones son implementadas de manera diferente en las clases.
10. MODELOS PARA UN PRODESO DE SOFTWARE
10.1. CLASICOS
10.1.1. Cascada
10.1.2. Incremental
10.1.3. Evolucionarlo
10.1.4. espiral
10.2. RECIENTES
10.2.1. Ganar-Ganar
10.2.2. programacion extrema XP
10.2.3. Proceso unificado UP
11. CALIDAD DE SOFTWARE Y MODELOS DE MADUREZDEL PROCESO.
11.1. Factores para una exelente calidad
11.1.1. El cliente o usuario es el participante primordial en el proceso de desarrollo del producto y responsable de definir los requisitos del producto final.
11.1.2. El desarrollador es responsable del proceso de producción y de asegurar la calidad del producto.
11.1.3. El proceso seguido para el desarrollo del producto final.
11.1.4. El producto correspondiente al sistema a ser desarrollado.