Niveles CMM - CMMI
Los niveles CMM - CMMI son 5:
Inicial o Nivel 1 CMM - CMMI. Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.Es el típico proyecto en el que se da la siguiente situación:
¿Cómo va el proyecto?- Bien, bien. Dos semanas después…-
¿Cómo va el proyecto?- Bien, bien. Tres semanas después…-
El lunes hay que entregar el proyecto.- No se por qué pero los proyectos se entregan los lunes.- El lunes !!?. Todavía falta mucho!!- ¿Cómo? Me dijiste que el proyecto iba bien!! Arréglatelas como quieras, pero el proyecto tiene que estar terminado para el lunes.
Si no sabes el tamaño del proyecto y no sabes cuanto llevas hecho, nunca sabrás cuando vas a terminar.
Repetible o Nivel 2 CMM-CMMI. Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.Los procesos que hay que implantar para alcanzar este nivel son:
Gestión de requisitos
Planificación de proyectos
Seguimiento y control de proyectos
Gestión de proveedores
Aseguramiento de la calidad
Gestión de la configuración
Definido o Nivel 3 CMM - CMMI. Resumiéndolo mucho, este alcanzar este nivel significa que la forma de desarrollar proyectos (gestión e ingeniería) esta definida, por definida quiere decir que esta establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.Los procesos que hay que implantar para alcanzar este nivel son:
Desarrollo de requisitos
Solución Técnica
Integración del producto
Verificación
Validación
Desarrollo y mejora de los procesos de la organización
Definición de los procesos de la organización
Planificación de la formación
Gestión de riesgos
Análisis y resolución de toma de decisiones
La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades.
Cuantitativamente Gestionado o Nivel 4 CMM - CMMI. Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.Los procesos que hay que implantar para alcanzar este nivel son:
Gestión cuantitativa de proyectos
Mejora de los procesos de la organización
Optimizado o Nivel 5 CMM - CMMI. Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica.Los procesos que hay que implantar para alcanzar este nivel son:
Innovación organizacional
Análisis y resolución de las causasNormalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultáneamente ya que están muy relacionados.
Inicial o Nivel 1 CMM - CMMI. Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.Es el típico proyecto en el que se da la siguiente situación:
¿Cómo va el proyecto?- Bien, bien. Dos semanas después…-
¿Cómo va el proyecto?- Bien, bien. Tres semanas después…-
El lunes hay que entregar el proyecto.- No se por qué pero los proyectos se entregan los lunes.- El lunes !!?. Todavía falta mucho!!- ¿Cómo? Me dijiste que el proyecto iba bien!! Arréglatelas como quieras, pero el proyecto tiene que estar terminado para el lunes.
Si no sabes el tamaño del proyecto y no sabes cuanto llevas hecho, nunca sabrás cuando vas a terminar.
Repetible o Nivel 2 CMM-CMMI. Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.Los procesos que hay que implantar para alcanzar este nivel son:
Gestión de requisitos
Planificación de proyectos
Seguimiento y control de proyectos
Gestión de proveedores
Aseguramiento de la calidad
Gestión de la configuración
Definido o Nivel 3 CMM - CMMI. Resumiéndolo mucho, este alcanzar este nivel significa que la forma de desarrollar proyectos (gestión e ingeniería) esta definida, por definida quiere decir que esta establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.Los procesos que hay que implantar para alcanzar este nivel son:
Desarrollo de requisitos
Solución Técnica
Integración del producto
Verificación
Validación
Desarrollo y mejora de los procesos de la organización
Definición de los procesos de la organización
Planificación de la formación
Gestión de riesgos
Análisis y resolución de toma de decisiones
La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades.
Cuantitativamente Gestionado o Nivel 4 CMM - CMMI. Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.Los procesos que hay que implantar para alcanzar este nivel son:
Gestión cuantitativa de proyectos
Mejora de los procesos de la organización
Optimizado o Nivel 5 CMM - CMMI. Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica.Los procesos que hay que implantar para alcanzar este nivel son:
Innovación organizacional
Análisis y resolución de las causasNormalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultáneamente ya que están muy relacionados.
¿Qué es el CMM - CMMI?
El CMM - CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.
El nacimiento de CMM - CMMI
El departamento de defensa de los estados unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas, los presupuestos se disparaban, las fechas alargaban más y más. ¿Quién no se ha encontrado con este tipo de problemas si ha trabajado con una empresa de software?
Como esta situación les parecía intolerable convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa".
Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos 4 problemas", se presentaron diversos estamentos y la Universidad Carnegie Mellon ganó el concurso en 1985, creando el SEI.
El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM - CMMI
Como esta situación les parecía intolerable convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa".
Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos 4 problemas", se presentaron diversos estamentos y la Universidad Carnegie Mellon ganó el concurso en 1985, creando el SEI.
El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM - CMMI
FDD – Feature Driven Development
Peter Coad es considerado uno de los referentes más importantes dentro de la ingeniería de software. Coad ha sido uno de los principales pioneros detrás del movimiento de la orientación a objetos y empezó a trabajar con Ed Yourdon (uno de los creadores del Análisis Estructurado) a principios de los noventa, cuando este último pidió ayuda a alguien de la comunidad de objetos para desarrollar una nueva metodología, basada en el paradigma de OO. Posteriormente, Coad junto con Jeff De Luca y otros, participaría en la creación de FDD, una metodología desarrollada alrededor del año 1998 que presenta las características de un proceso ágil [Coad, 1998].
La misma derivó del trabajo de Coad sobre las Feature Lists (Listas de Funcionalidades).FDD se estructura alrededor de la definición de features que representan la funcionalidad que debe contener el sistema, y tienen un alcance lo suficientemente corto como para ser implementadas en un par de semanas. FDD posee también una jerarquía de features, siendo el eslabón superior el de feature set que agrupa un conjunto de features relacionadas con aspectos en común del negocio. Por último, establece el major feature set como el más alto nivel de agrupación de funcionalidad que abarca diferentes feature sets que contribuyen a proveer valor al cliente en relación a un subdominio dentro del dominio completo de la aplicación. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario común que fomente que los desarrolladores tengan un diálogo fluido con los clientes, desarrollando entre ambos un modelo común del negocio. Este tema será tratado más adelante en relación al enfoque de las metodologías ágiles en los productos entregados.
La misma derivó del trabajo de Coad sobre las Feature Lists (Listas de Funcionalidades).FDD se estructura alrededor de la definición de features que representan la funcionalidad que debe contener el sistema, y tienen un alcance lo suficientemente corto como para ser implementadas en un par de semanas. FDD posee también una jerarquía de features, siendo el eslabón superior el de feature set que agrupa un conjunto de features relacionadas con aspectos en común del negocio. Por último, establece el major feature set como el más alto nivel de agrupación de funcionalidad que abarca diferentes feature sets que contribuyen a proveer valor al cliente en relación a un subdominio dentro del dominio completo de la aplicación. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario común que fomente que los desarrolladores tengan un diálogo fluido con los clientes, desarrollando entre ambos un modelo común del negocio. Este tema será tratado más adelante en relación al enfoque de las metodologías ágiles en los productos entregados.
DSDM – Dynamic Systems Development Method
DSDM es la única de las metodologías aquí planteadas surgida de un Consorcio, formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo del Consorcio era producir una metodología de dominio público que fuera independiente de las herramientas y que pudiera ser utilizado en proyectos de tipo RAD (Rapid Application Development). El Consorcio, tomando las best practices que se conocían en la industria y la experiencia traída por sus fundadores, liberó la primera versión de DSDM a principios de 1995. A partir de ese momento el método fue bien acogido por la industria, que empezó a utilizarlo y a capacitar a su personal en las prácticas y valores de DSDM. Debido a este éxito, el Consorcio comisionó al Presidente del Comité Técnico, Jennifer Stapleton, la creación de un libro que explorara la realidad de implementar el método. Dicho libro [Stapleton, 1997] es tomado como guía para el análisis posterior de DSDM.
DSDM incluye roles claves en relación al management del proyecto. Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que equivaldría al on-site customer de XP, que brinda el conocimiento del negocio y define los requerimientos del software; el coordinador técnico que es la persona encargada de mantener la arquitectura y verificar la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estándares técnicos.
DSDM incluye roles claves en relación al management del proyecto. Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que equivaldría al on-site customer de XP, que brinda el conocimiento del negocio y define los requerimientos del software; el coordinador técnico que es la persona encargada de mantener la arquitectura y verificar la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estándares técnicos.
SCRUM
Scrum es un proceso ágil de administración de proyectos. Por su naturaleza es iterativo y pretende tener un producto listo al final de cada iteración. Toma su nombre de una jugada de rugby, y que Ken Schwaber, uno de los padres del método, describe como “caos controlado”.
Scrum es un proceso ágil y liviano que sirve para administrar y controlar el desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una iteración es un ciclo corto de construcción repetitivo). Cada ciclo o iteración termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general tienen una duración entre 2 y 4 semanas. Scrum se utiliza como marco para otras prácticas de ingeniería de software como RUP o Extreme Programming.
Scrum se focaliza en priorizar el trabajo en función del valor que tenga para el negocio, maximizando la utilidad de lo que se construye y el retorno de inversión.
Está diseñado especialmente para adaptarse a los cambios en los requerimientos, por ejemplo en un mercado de alta competitividad. Los requerimientos y las prioridades se revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. De esta forma se puede adaptar en tiempo real el producto que se está construyendo a las necesidades del cliente. Se busca entregar software que realmente resuelva las necesidades, aumentando la satisfacción del cliente.
En Scrum, el equipo se focaliza en una única cosa: construir software de calidad. Por el otro lado, la gestión de un proyecto Scrum se focaliza en definir cuales son las características que debe tener el producto a construir (qué construir, qué no y en qué orden) y en remover cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo. Se busca que los equipos sean lo más efectivos y productivos que sea posible.
Scrum tiene un conjunto de reglas muy pequeño y muy simple y está basado en los principios de inspección continua, adaptación, auto-gestión e innovación. El cliente se entusiasma y se compromete con el proyecto dado que ve crecer el producto iteración a iteración y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa. Por otro lado, los desarrolladores encuentran un ámbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivación de los integrantes del equipo.
Scrum es un proceso ágil y liviano que sirve para administrar y controlar el desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una iteración es un ciclo corto de construcción repetitivo). Cada ciclo o iteración termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general tienen una duración entre 2 y 4 semanas. Scrum se utiliza como marco para otras prácticas de ingeniería de software como RUP o Extreme Programming.
Scrum se focaliza en priorizar el trabajo en función del valor que tenga para el negocio, maximizando la utilidad de lo que se construye y el retorno de inversión.
Está diseñado especialmente para adaptarse a los cambios en los requerimientos, por ejemplo en un mercado de alta competitividad. Los requerimientos y las prioridades se revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. De esta forma se puede adaptar en tiempo real el producto que se está construyendo a las necesidades del cliente. Se busca entregar software que realmente resuelva las necesidades, aumentando la satisfacción del cliente.
En Scrum, el equipo se focaliza en una única cosa: construir software de calidad. Por el otro lado, la gestión de un proyecto Scrum se focaliza en definir cuales son las características que debe tener el producto a construir (qué construir, qué no y en qué orden) y en remover cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo. Se busca que los equipos sean lo más efectivos y productivos que sea posible.
Scrum tiene un conjunto de reglas muy pequeño y muy simple y está basado en los principios de inspección continua, adaptación, auto-gestión e innovación. El cliente se entusiasma y se compromete con el proyecto dado que ve crecer el producto iteración a iteración y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa. Por otro lado, los desarrolladores encuentran un ámbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivación de los integrantes del equipo.
eXtreme Programming o XP
La Programación Extrema es una metodología ligera de desarrollo de software que se basa en la simplicidad, la comunicación y la realimentación o reutilización del código desarrollado.
Métrica 3
Es una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información.
Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual: el Ministerio de Administraciones Públicas. Este Ministerio, desde el Consejo Superior de Informática, ofrece así un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software en el desarrollo de Sistemas de Información. Su aplicación pretende los siguientes objetivos:
Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.
Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.
Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.
Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.Facilitar la operación, mantenimiento y uso de los productos software obtenido.
Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual: el Ministerio de Administraciones Públicas. Este Ministerio, desde el Consejo Superior de Informática, ofrece así un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software en el desarrollo de Sistemas de Información. Su aplicación pretende los siguientes objetivos:
Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.
Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.
Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.
Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.Facilitar la operación, mantenimiento y uso de los productos software obtenido.
¿Como controlar la calidad del Software?
Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo que no se puede medir".
Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de métricas: de complejidad de programa o código, y de complejidad de sistema o estructura.
Todos los autores coinciden en que el software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.
Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos:
Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.
Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes.
Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo.
Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un proyecto para el Aseguramiento de la Calidad del Software (ACS), válido para cualquier entidad que se dedique a la investigación, producción y comercialización del software, el cual incluye la elaboración de un Sistema de Indicadores de la Calidad del Software, la confección de una Metodología para el Aseguramiento de la Calidad del Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la aplicación de las técnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de Aseguramiento de la Calidad del Software.
Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de métricas: de complejidad de programa o código, y de complejidad de sistema o estructura.
Todos los autores coinciden en que el software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.
Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos:
Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.
Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes.
Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo.
Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un proyecto para el Aseguramiento de la Calidad del Software (ACS), válido para cualquier entidad que se dedique a la investigación, producción y comercialización del software, el cual incluye la elaboración de un Sistema de Indicadores de la Calidad del Software, la confección de una Metodología para el Aseguramiento de la Calidad del Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la aplicación de las técnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de Aseguramiento de la Calidad del Software.
¿Qué es la calidad del software?
Es el desarrollo de software basado en estándares con la funcionalidad y rendimiento total que satisfacen los requerimientos del cliente.
Procesos de desarrollo, artifacts, gestión de proyectos, análisis y diseño, especificación de requerimientos, arquitectura, son solo algunos de los componentes que se aglomeran para conformar la ingeniería de software (IS) como disciplina para la creación y mantenimiento de software. Dentro de ésta, existe un subconjunto de teorías, herramientas y métodos orientados a lo que se denomina la calidad del software. Para resumir de alguna manera la amplitud de este concepto, se puede decir que la calidad de software ha sido usada desde un simple argumento de venta, hasta verdaderos estudios formales y usos de métricas para el desarrollo de software. Extrañamente dentro de la IS, la calidad del software es muy complicada de definir y de enmarcar en un simple concepto teórico. Una idea general sobre un software de calidad es aquel que debiera cumplir con los requerimientos funcionales y de performance además de ser mantenible, confiable y aceptable. Veamos cada uno de las principales características que hacen a un software de calidad.
Mantenibilidad: el software debe ser diseñado de tal manera, que permita ajustarlo a los cambios en los requerimientos del cliente. Esta característica es crucial, debido al inevitable cambio del contexto en el que se desempeña un software. Confiabilidad: incluye varias características además de la confiabilidad, como la seguridad, control de fallos, etc. Eficiencia: tiene que ver con el uso eficiente de los recursos que necesita un sistema para su funcionamiento.
Usabilidad: el software debiera ser utilizado sin un gran esfuerzo por los usuarios para los que fue diseñado, documentado, etc. Como puede observarse, las diversas características con las que se desea que cumpla un software de calidad varían ampliamente. Algunas tienen que ver con el usuario que interactúa con el sistema, otras con el líder de proyecto y diseñadores, otras características parecen muy abstractas y hasta indefinidas, etc. Para ordenar este aparente caos de indefiniciones y características abstractas, con el fin de poder medirlas, estimarlas e implementarlas, la IS ha desarrollado desde los primeros días de su existencia, diferentes procesos de desarrollo.
Procesos de desarrollo, artifacts, gestión de proyectos, análisis y diseño, especificación de requerimientos, arquitectura, son solo algunos de los componentes que se aglomeran para conformar la ingeniería de software (IS) como disciplina para la creación y mantenimiento de software. Dentro de ésta, existe un subconjunto de teorías, herramientas y métodos orientados a lo que se denomina la calidad del software. Para resumir de alguna manera la amplitud de este concepto, se puede decir que la calidad de software ha sido usada desde un simple argumento de venta, hasta verdaderos estudios formales y usos de métricas para el desarrollo de software. Extrañamente dentro de la IS, la calidad del software es muy complicada de definir y de enmarcar en un simple concepto teórico. Una idea general sobre un software de calidad es aquel que debiera cumplir con los requerimientos funcionales y de performance además de ser mantenible, confiable y aceptable. Veamos cada uno de las principales características que hacen a un software de calidad.
Mantenibilidad: el software debe ser diseñado de tal manera, que permita ajustarlo a los cambios en los requerimientos del cliente. Esta característica es crucial, debido al inevitable cambio del contexto en el que se desempeña un software. Confiabilidad: incluye varias características además de la confiabilidad, como la seguridad, control de fallos, etc. Eficiencia: tiene que ver con el uso eficiente de los recursos que necesita un sistema para su funcionamiento.
Usabilidad: el software debiera ser utilizado sin un gran esfuerzo por los usuarios para los que fue diseñado, documentado, etc. Como puede observarse, las diversas características con las que se desea que cumpla un software de calidad varían ampliamente. Algunas tienen que ver con el usuario que interactúa con el sistema, otras con el líder de proyecto y diseñadores, otras características parecen muy abstractas y hasta indefinidas, etc. Para ordenar este aparente caos de indefiniciones y características abstractas, con el fin de poder medirlas, estimarlas e implementarlas, la IS ha desarrollado desde los primeros días de su existencia, diferentes procesos de desarrollo.
Modelo de Construcción.
Arquitectura Cliente/Servidor:
Una arquitectura es un conjunto de reglas, definiciones, términos y modelos que se emplean para producir un producto. La arquitectura Cliente/Servidor agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo.
Una arquitectura es un conjunto de reglas, definiciones, términos y modelos que se emplean para producir un producto. La arquitectura Cliente/Servidor agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo.
Beneficios:
- Mejor aprovechamiento de la potencia de cómputo (Reparte el trabajo).
- Reduce el tráfico en la Red. (Viajan requerimientos).
- Opera bajo sistemas abiertos.
- Permite el uso de interfaces gráficas variadas y versátiles.
Cliente
- Conjunto de Software y Hardware que invoca los servicios de uno o varios servidores
Características:
- El Cliente oculta al Servidor y la Red.
- Detecta e intercepta peticiones de otras aplicaciones y puede redireccionarlas.
- Dedicado a la cesión del usuario ( Inicia...Termina ).
- El método más común por el que se solicitan los servicios es a través de RPC (Remote Procedure Calls).
Funciones Comunes del Cliente:
- Mantener y procesar todo el dialogo con el usuario.
- Manejo de pantallas.
- Menús e interpretación de comandos.
- Entrada de datos y validación.
- Procesamiento de ayudas.
- Recuperación de errores.
Servidor
- Conjunto de Hardware y Software que responde a los requerimientos de un cliente.
Tipos Comunes de Servidores:
- Servidor de Archivos (FTP, Novell).
- Servidor de Bases de Datos (SQL, CBASE, ORACLE, INFORMIX).
- Servidor de Comunicaciones
- Servidor de Impresión.
- Servidor de Terminal.
- Servidor de Aplicaciones (Windows NT, Novell).
Funciones Comunes del Servidor:
- Acceso, almacenamiento y organización de datos.
- Actualización de datos almacenados.
- Administración de recursos compartidos.
- Ejecución de toda la lógica para procesar una transacción.
- Procesamiento común de elementos del servidor.
Ventajas y Desventajas de los Sistemas Distribuidos
Ventajas:
Procesadores más poderosos y a menos costos
- Desarrollo de Estaciones con más capacidades
- Las estaciones satisfacen las necesidades de los usuarios.
- Uso de nuevas interfaces.
Avances en la Tecnología de Comunicaciones.
- Disponibilidad de elementos de Comunicación.
- Desarrollo de nuevas técnicas.
Compartición de Recursos.
- Dispositivos (Hardware).
- Programas (Software).
Eficiencia y Flexibilidad.
- Respuesta Rápida.
- Ejecución Concurrente de procesos (En varias computadoras).
- Empleo de técnicas de procesamiento distribuido.
Disponibilidad y Confiabilidad.
- Sistema poco propenso a fallas (Si un componente no afecta a la disponibilidad del sistema).
- Mayores servicios que elevan la funcionalidad ( Monitoreo, Telecontrol, Correo Eléctrico, Etc.).
Crecimiento Modular.
- Es inherente al crecimiento.
- Inclusión rápida de nuevos recursos.
- Los recursos actuales no afectan.
Desventajas:
- Requerimientos de mayores controles de procesamiento.
- Velocidad de propagación de información ( Muy lenta a veces).
- Servicios de replicación de datos y servicios con posibilidades de fallas.
- Mayores controles de acceso y proceso ( Commit ).
- Administración más compleja.
- Costos.
Factores que han afectado el desarrollo de los Sistemas Distribuidos.
- Avances Tecnológicos.
- Nuevos requerimientos.
- Globalización.
- Aspectos Externos ( Culturales, Políticos, Económicos ).
- Integración.
Características de los Sistemas Distribuidos
- Cada elemento de computo tiene su propia memoria y su propio Sistema Operativo.
- Control de recursos locales y remotos.
- Sistemas Abiertos (Facilidades de cambio y crecimiento).
- Plataforma no standard ( Unix, NT, Intel, RISC, Etc.).
- Medios de comunicación ( Redes, Protocolos, Dispositivos, Etc.).
- Capacidad de Procesamiento en paralelo.
- Dispersión y parcialidad.
Sistemas Distribuidos
Es un concepto poco claro de definir. Colección de elementos de cómputo autónomo que se encuentran físicamente separados y no comparten una memoria común, se comunican entre sí a través del intercambio de mensajes utilizando un medio de comunicación. Los sistemas autónomos pueden tener características no homogéneas.
Suscribirse a:
Entradas (Atom)
