1. Introducción a la Ingeniería de Software

Ingeniería de SW Dr. Mario Rossainz López

1

1. Introducción a la Ingeniería de Software

1.1. INTRODUCCIÓN Se puede decir que un PROYECTO es un conjunto de etapas, actividades y tareas que se realizan para alcanzar un objetivo que implica un trabajo no inmediato a un plazo relativamente largo. Precisamente es la división en trabajos más sencillos lo que permite al personal del proyecto dominar la complejidad, en este caso, del software que se ha de desarrollar [PIA00]. La gestión de proyectos de software se desarrolla a través de sus distintos aspectos: planificación, dirección, organización y control. Esta misma gestión se enfoca sobre el personal, el producto, el proceso y el proyecto (en ese orden).

EL PERSONAL o “factor humano” es tan importante que el Software Engineering Institute ha desarrollado un modelo de madurez de la capacidad de gestión de personal (MMCGP) para “aumentar la rapidez con la cual las organizaciones de software acometen las aplicaciones”. El modelo de madurez de gestión de personal define áreas prácticas para el personal de software tales como: reclutamiento, selección, gestión del desempeño, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y el trabajo y desarrollo de la cultura en equipo. EL PRODUCTO: Antes de planear un proyecto se deben establecer los objetivos y el ámbito del producto a generar. Se deben considerar soluciones alternativas e identificar restricciones técnicas y de gestión. Sin esta información difícilmente se podrían estimar costos y riesgos del proyecto, así como lograr la división de tareas o la calendarización de éste. Los objetivos identifican las metas globales del producto mientras que el ámbito identifica los datos iniciales y las funciones que caracterizan al producto.

Personal

Problema

Proceso

Esfuerzo Humano

Comunicación

Con el cliente

Administrador

Métodos técnicos

Herramientas


2

EL PROCESO: Un proceso de software proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo de software. Algunos conjuntos de tareas diferentes tales como hitos, productos de trabajo y puntos de control de la calidad permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software. Por otro lado las actividades protectoras como el control de la calidad del software, la medición del software y configuración de éste, cubren el modelo del proceso. EL PROYECTO: Los proyectos de software se realizan de manera planificada y controlada porque es la única forma que se conoce para gestionar la complejidad. Para evitar el fracaso de un proyecto, el gestor del mismo y los ingenieros de software que constituyen el producto deben eludir un conjunto de señales de advertencia comunes, comprender los factores de éxito críticos y desarrollar un enfoque de sentido común que planifique, supervise y controle el proyecto.

1.2. EL PERSONAL El Proceso de desarrollo de software y cualquier proyecto de software lo integran personas que se pueden clasificar dentro de alguna de las siguientes categorías: 1. Gestores Ejecutivos: que definen los aspectos del negocio que usualmente tienen una influencia

significativa en el proyecto. 2. Gestores (técnicos) del proyecto: quienes planifican, motivan, organizan y controlan a los

profesionales que realizan el trabajo de software. 3. Profesionales: quienes proporcionan las habilidades técnicas necesarias para realizar la

ingeniería de un producto o aplicación. 4. Clientes: quienes especifican los requisitos para la ingeniería del software. 5. Usuarios finales: quienes interactúan con el software una vez que se libera para su uso

productivo. Todo proyecto de software lo integran personas que caen en la anterior clasificación y para ser eficaz, el equipo del proyecto debe estar organizado de forma que maximice las capacidades y habilidades de cada persona. Esta es la labor del líder o Jefe del equipo.

1.2.1. EL LÍDER DEL EQUIPO Jerry Weinberg sugiere un Modelo de Gestión de Liderazgo (MOI) formado por tres partes:

• La motivación: Que es la habilidad para alentar (mediante empuje o jalón) al personal técnico para que produzca según su mejor capacidad.

• La Organización: Que es la habilidad para adecuar los procesos existentes (o inventar nuevos) que permitirán que el concepto inicial sea introducido en un producto final.

• Las Ideas o Innovación: Que es la habilidad para alentar a la gente a crear y sentir creativamente, incluso cuando deben trabajar dentro de los límites establecidos por un producto o aplicación de software particular.

Otro punto de vista de las características que definen a un líder de equipo eficiente, propone cuatros rasgos clave:

• Resolución de Problemas: Un líder de equipo o gestor de software eficiente puede diagnosticar los conflictos técnicos y organizativos más relevantes, estructurar una solución o motivar a


3

otros profesionales para desarrollar la solución, aplicar en las nuevas situaciones las lecciones aprendidas en proyectos pasados, y mantenerse lo suficientemente flexible como para cambiar de dirección si los intentos iniciales en la solución del problema son infructuosos.

• Dotes de Gestión: Un buen líder de proyecto debe encabezarlo y dirigirlo. Debe tener la confianza de asumir el control cuando es necesario y la seguridad para permitir que los buenos profesionales sigan sus instintos.

• Incentivos: Un líder de proyecto debe recompensar la iniciativa y los logros, para optimizar la productividad de un equipo de trabajo, y demostrar además con sus propias acciones que la toma de riesgos controlada no será penalizada.

• Influencia y fomento de la cultura de equipo: Un líder de proyecto eficaz debe ser capaz de “leer” a la gente; de entender las señales verbales y no verbales y reaccionar ante ello. El líder debe mantener el control en situaciones de alta presión.

Existen tantas estructuras organizaciones de profesionales para el desarrollo de software como organizaciones que tienen el mismo fin. La mejor estructura de equipo depende del estilo de gestión de una organización, el número de personas que compondrá el equipo, sus niveles de preparación y la dificultad general del problema. Según Mantei, existen 3 organigramas de equipos de trabajo genéricos: Descentralizado Democrático (DD): En donde no hay un jefe permanente. Más bien se nombran coordinadores de tarea a corto plazo y se sustituyen por otros para diferentes tareas. Las decisiones sobre problemas y los enfoques se hacen por consenso del grupo. La comunicación entre los miembros del equipo es horizontal.

Descentralizado Controlado (DC): Este equipo de Ingeniería de Software tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades sobre subtareas. La resolución de problemas sigue siendo una actividad del grupo, pero la implementación de soluciones se reparte entre sub-grupos por el jefe del equipo. La comunicación entre subgrupos e individuos es horizontal.

Desentralizado Democrático (DD): ⚫No tiene un jefe permanente. ⚫Se nombran coordinadores de tareas a corto plazo. ⚫Las decisiones y enfoques adoptados se hacen por consenso del grupo. ⚫La comunicación entre los miembros del equipo es horizontal

Estructura

Trayectorias de Comunicación


4

Centralizado Controlado (CC): El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el jefe y los miembros del equipo es vertical. Mantei describe también siete factores de proyecto que deberían considerarse cuando se planifica la estructura de los equipos de Ingeniería de Software: 1. La dificultad del problema que se resolverá 2. El tamaño del programa(s) resultante(s) en líneas de código o puntos de función 3. El tiempo que el equipo estará junto (vida del equipo) 4. El grado en el que el problema puede separarse en módulos 5. La calidad y confiabilidad requeridas del sistema que se construirá 6. La rigidez de la fecha de entrega 7. El grado de sociabilidad (comunicación que requiere el proyecto)

Desentralizado Controlado (DC):

⚫Tiene un jefe que coordina tareas específicas y jefes secundarios para subtareas.

⚫La resolución de tareas es una actividad de grupo pero la implementación de soluciones se reparte entre subgrupos.

⚫Las decisiones y enfoques adoptados se hacen por consenso del grupo.

⚫La comunicación entre los miembros del equipo y subgrupos es horizontal y vertical

Estructura

Trayectorias de

Comunicación

Centralizado Controlado (CC): ⚫Tiene un jefe de equipo que resuelve problemas de alto nivel y coordina el equipo ⚫La comunicación entre los miembros del equipo es vertical

Estructura

Trayectorias de Comunicación


5

Las siguientes tablas resumen el impacto de las características del proyecto en la organización del equipo.

TIPO DE EQUIPO DD DC CC

DIFICULTAD

Alta

Pequeña

TAMAÑO

Grande

Pequeño


DURACION DEL EQUIPO

Corto

Largo

MODULARIDAD

Alta

Baja


FIABILIDAD

Corto

Largo

FECHA DE ENTREGA

Alta

Baja

COMUNICACION

Alta

Pequeña

Constantine sugiere cuatro paradigmas organizacionales para los equipos de Ingeniería de Software:


6

1. Un paradigma cerrado estructura a un equipo a lo largo de una jerarquía tradicional de autoridad. Estos equipos suelen trabajar mejor cuando producen software muy similar a proyectos anteriores, pero será menos probable que sean innovadores.

2. Un paradigma aleatorio estructura un equipo libremente y depende de la iniciativa individual de los miembros del equipo. Cuando se requieren adelantos tecnológicos o innovación, estos equipos son excelentes, sin embargo, suelen tener problemas cuando se requiere de un desempeño ordenado.

3. Un paradigma abierto intenta estructurar un equipo mezclando los elementos del paradigma cerrado con los elementos del paradigma aleatorio. El trabajo se desarrolla en colaboración. Es característico de estos equipos la sólida comunicación y la toma de decisiones basada en consenso.

4. Un paradigma sincrónico se apoya en la compartí mentalización natural de un problema y organiza a los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.

1.2.2. CONFLICTOS DE COORDINACIÓN Y COMUNICACIÓN Existen muchas razones por las cuales los proyectos software se vuelven problemáticos. La escala de muchos esfuerzos de desarrollo es grande, lo que conduce a complejidad, confusión y dificultades significativas en la coordinación de los miembros del equipo. La incertidumbre es común, lo que genera una corriente continua de cambios que mueve gradualmente en una sola dirección al equipo del proyecto. La interoperabilidad se ha convertido en una característica clave de muchos sistemas. El nuevo software debe comunicarse con el anterior y adecuarse a las restricciones predefinidas que impone el sistema operativo.

Para enfrentarse a estas características del software moderno (escala, incertidumbre e interoperabilidad), un equipo de ingeniería de software debe establecer métodos efectivos para coordinar a la gente que realiza el trabajo. Para lograrlo se deben establecer mecanismos para la comunicación formal e informal entre los miembros del equipo y entre múltiples equipos. La comunicación formal se logra por medio de “escritos, reuniones estructuradas y otros canales de comunicación no interactivos e impersonales”. La comunicación informal es más personal. Los miembros de un equipo de software comparten ideas sobre una base ad hoc, piden ayuda cuando surgen problemas e interactúan unos con otros diariamente.

Tamaño o Escala

Incertidumbre

Interoperabilidad

Métodos efectivos

de coordinación de personal

Software


7

Kraul y Streeter proponen una colección de técnicas de coordinación de proyectos categorizados de la siguiente manera:

• Formal, enfoque Impersonal. Incluyen documentos de ingeniería de software y entregas (por ejemplo: código fuente), memorandos técnicos, hitos del proyecto, planificaciones del programa y herramientas de control del proyecto, peticiones de cambios y documentación relativa, informes de seguimiento de errores e información almacenada.

• Formal, procedimientos interpersonales. Se concentra en las actividades de garantía de calidad aplicada a productos de ingeniería de software. Estos incluyen reuniones de revisión de estado e inspecciones de diseño y de código.

• Informal, procedimientos interpersonales. Incluyen reuniones de grupo para la divulgación de información y resolución de problemas así como “definición de requisitos y del personal de desarrollo”.

• Comunicación Electrónica. Agrupa correo electrónico, boletines electrónicos de noticias, páginas Web y sistemas de video conferencia.

• Red Interpersonal. Discusiones informales con personas que no están en el proyecto pero que pueden tener experiencia o una profunda visión que puede ayudar a los miembros del equipo.

1.3. EL PRODUCTO El gestor de un proyecto de software se enfrenta con el dilema de requerir estimaciones cuantitativas y un plan organizado, pero no se dispone de información sólida. Un análisis detallado de los requisitos de software proporcionaría la información necesaria para las estimaciones, pero, con frecuencia, el análisis toma semanas o meses en completarse. Peor aun, los requisitos pueden ser fluidos y cambiar regularmente conforme el proyecto avanza.

Proyecto SW

inicio

Estimaciones Cuantitativas

Plan Organizado

Análisis de Requerimientos

Un análisis de Requerimientos A menudo lleva

Semanas o meses


8

En consecuencia, se deben examinar el producto y el problema que se intenta resolver al inicio del proyecto. Como mínimo, se debe establecer y acotar el ámbito del producto.

1.3.1. AMBITO DEL SOFTWARE La primera actividad de la gestión de un proyecto de software es la determinación del ámbito del software. El ámbito se define al responder las siguientes preguntas:

• Contexto: ¿Cómo encaja el software que se desarrollará en un sistema más grande, producto o contexto de negocios, y qué restricciones se imponen como resultado del contexto?.

• Objetivos de Información: ¿Qué objetos de datos visibles al usuario se producen como resultado del software?, ¿Qué objetos de datos se requieren de entrada?

• Función y Desempeño: ¿Qué funciones realiza el software para transformar los datos de entrada en salida?, ¿Existen algunas características de desempeño especiales que deban abordarse?

El ámbito del proyecto de software no debe ser ambiguo ni incomprensible a niveles de gestión y técnico. Se debe acotar un enunciado del ámbito del software. Esto es, se establecen de manera explícita los datos cuantitativos, por ejemplo: número de usuarios simultáneos, tamaño de la lista de correo, tiempo de respuesta máximo permitido, etc.; se anotan las restricciones o limitaciones, por ejemplo, el costo del producto restringe el tamaño de la memoria, etc.; y se describen los factores que reducen riesgos, por ejemplo: los algoritmos deseados se comprenden bien si están disponibles en C++.

1.3.2. DESCOMPOSICIÓN DEL PROBLEMA La descomposición del problema es una actividad que se asienta en el núcleo del análisis de requisitos de software. Durante la actividad de fijación del ámbito no se realiza intento alguno por descomponer completamente el problema. Más bien la descomposición se aplica a dos grandes áreas: 1. La funcionalidad que debe entregarse 2. El proceso que se empleará para entregarla

Proyecto SW

inicio

Antes de llevar a cabo las Estimaciones cuantitativas y

el Plan Organizado, habrá que examinar el problema:

-Definir su ámbito

- Delimitarlo


9

Las funciones de software, descritas al enunciar el ámbito, se evalúan y refinan para proporcionar más detalles antes del comienzo de la estimación. Puesto que las estimaciones de costo y planificación temporal están funcionalmente orientadas, con frecuencia es útil un cierto grado de descomposición. Por ejemplo, considérese un proyecto que construirá un nuevo procesador de textos. Entre las características únicas del producto están:

• La entrada continua mediante voz

• La entrada continua mediante teclado

• Funciones sofisticadas de edición automática de copia, capacidad de diseño de página, índice y tabla de contenidos automáticos

• Otras El gestor del proyecto debe establecer primero un enunciado del ámbito que acote estas características. Por ejemplo, ¿la entrada continua de voz requiere que el usuario del producto lo entrene?, ¿Qué capacidades proporcionará la característica de edición de copia?, ¿Cuán sofisticada será la capacidad de diseño de página? Conforme evoluciona el enunciado del ámbito ocurre naturalmente un primer nivel de partición. El equipo del proyecto aprende que el departamento de mercadotecnia ha hablado con los clientes potenciales y encontró que las siguientes funciones deben integrarse a la función automática de copia:

1. Comprobación ortográfica 2. Comprobación gramatical 3. Comprobación de referencias para documentos grandes (por ejemplo, ¿la referencia a una

entrada bibliográfica se encuentra en la lista de entradas en la bibliografía) 4. Validación de referencias de sección y capítulo para documentos grandes.

Cada una de estas características representa una subfunción que debe implementarse en el software. Cada una todavía puede refinarse más si la descomposición simplifica la planificación.

1.4. EL PROCESO Un Proceso de Desarrollo de Software es un conjunto de actividades técnicas y administrativas realizadas durante la adquisición, desarrollo, mantenimiento y retiro de software.

Análisis de requisitos

Descomposición del problema

Funcionalidad que debe entregarse

Proceso que se empleará Para entregarlo


10

Las fases genéricas que caracterizan a un proceso de desarrollo de software son: la definición, el desarrollo y el mantenimiento. El problema es entonces seleccionar el modelo de proceso apropiado para la ingeniería del software que debe aplicar el equipo del proyecto. Existe una gran gama de paradigmas o modelos de ciclo de vida de la ingeniería de software:

• El modelo secuencial lineal

• El modelo de Prototipos

• El modelo RAD

• El modelo incremental

• El modelo en espiral

• El modelo de ensamble de componentes

• El modelo de métodos formales

• El modelo de técnicas de cuarta generación

• Etc. Se muestran la mayoría de estos modelos a continuación:

Proceso

Producto

Cliente/Usuario

Desarrollador


11

El Modelo Secuencial Lineal: El modelo de Cascada: El modelo de Prototipo:


12

El Modelo RAD: El Modelo Incremental: El modelo en Espiral:


13

El modelo de Componentes: El modelo de Métodos Formales:

Finalmente, las actividades estructurales que maduran el proceso de desarrollo de software son: 1. Comunicación con el cliente: tareas de comunicación entre desarrollador Cliente. 2. Planificación: Tareas para definir recursos y planificación temporal del proyecto 3. Análisis del riesgo: Tareas para valorar los riesgos técnicos y de gestión. 4. Ingeniería: Tareas de construcción de representaciones de la aplicación 5. Construcción y Entrega: Tareas para construir, probar, instalar y dar asistencia al usuario 6. Evaluación del Cliente: Tareas para obtener la opinión del cliente basada en la evaluación del

software.

Requirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing

R2Formal

specificationR3

Executableprogram

P2 P3 P4

T1 T2 T3 T4

Proofs of transformation correctness

Formal transformations

R1

P1


14

1.5. EL PROYECTO La gestión de un proyecto de software exitoso requiere entender qué puede salir mal, de forma que sea factible evitar los problemas. John Reel define 10 señales que indican cuando un proyecto de software está en peligro: 1. El personal del software no entiende las necesidades de sus clientes 2. El ámbito del producto está mal definido 3. Los cambios se gestionan mal 4. La tecnología elegida cambia 5. Las necesidades comerciales cambian 6. Los plazos de entrega no son realistas 7. Los usuarios se resisten 8. Se pierde el patrocinio 9. El equipo del proyecto carece de personal con las habilidades apropiadas 10. Los gestores y los profesionales evitan las mejores prácticas y las lecciones aprendidas Reel mismo, sugiere que para evitar los problemas anteriormente citados se utilice un enfoque de sentido común que consta de cinco partes para proyectos de software: 1. Comience con el pie derecho 2. Mantenga el ímpetu 3. Rastree el progreso 4. Tome decisiones inteligentes 5. Realice un análisis de resultados

1.6. INGENIERIA DE PRODUCTOS La Ingeniería de Productos es aquella actividad de resolución de problemas donde se localiza, analiza y asigna información, función y comportamiento del producto deseado a componentes individuales de la ingeniería como son: ⚫ Hardware ⚫ Software ⚫ Datos ⚫ Personas Existen varios criterios comparativos que rigen la selección de la configuración de un producto. A saber son: 1. Consideraciones del Proyecto: Se toman en cuenta estimaciones de costos y de planificación

temporal de la configuración, así como los riesgos asociados con esas estimaciones. 2. Consideraciones de Negocio: Soluciones ventajosas, venta exitosa en el mercado, beneficios

del riesgo de desarrollo, etc. 3. Análisis Técnico: Se toma en cuenta la tecnología disponible, garantías de funcionamiento y

rendimiento, recursos técnicos y riesgos asociados a la tecnología. 4. Evaluación de Fabricación: Se toman en cuenta instalaciones y equipos de fabricación

disponible, escasez de componentes necesarios y garantía de calidad.


15

5. Aspectos Humanos: Se considera personal entrenado para desarrollo, personal entrenado para fabricación, se toman en cuenta la existencia de problemas políticos y si el cliente entiende lo que debe hacer el sistema

6. Interfaces del entorno: Interfaces apropiadas con el entorno exterior, manejo de la comunicación entre máquinas, manejo de la comunicación entre humanos y máquinas.

7. Consideraciones Legales: Donde se incluyen riesgos de obligaciones legales, protección de los aspectos de propiedad, posibles infracciones, etc.

8. Otras consideraciones: Sistemas o productos similares, compra a terceros de partes principales de alguna opción.

1.6.1. ANALISIS DEL SISTEMA Parte importante de una Ingeniería del Producto es el Análisis del Sistema el cual se constituye de 6 fases: Fase 1: Identificar las necesidades del cliente: El ingeniero de sistemas o Analista es responsable de identificar las necesidades del cliente, es decir, los requisitos del sistema; para ello realiza reuniones tanto con los clientes como con los usuarios finales valiéndose de instrumentos (tales como cuestionarios) para la captura de esas necesidades.

Fase 2: Establecer la viabilidad del Sistema: Se debe llevar a cabo un estudio de la viabilidad del sistema, es decir, qué tan factible resulta ser la implementación del sistema que se pide. Este estudio se hace en tres aspectos, el económico, el técnico y el legal. Estudio de la viabilidad Económica: Se hace un estudio de la evaluación del costo de desarrollo del producto contra los ingresos netos y beneficios obtenidos del producto desarrollado.

Ingeniero en Sistemas (Analista del Sistema)

Cliente

Usuario Final

Se reúne con:

Entender objetivos y definir metas


16

Estudio de la viabilidad técnica: Se lleva a cabo un estudio de la función, rendimiento y restricciones que puedan afectar a la consecución de un sistema aceptable.

Estudio de la viabilidad legal: Se lleva a cabo un análisis de cualquier infracción, violación o responsabilidad legal en que se pudiera incurrir en el desarrollo del producto o sistema.

Opcionalmente se podría hacer la evaluación de enfoques alternativos al desarrollo del sistema para completar la viabilidad de desarrollo del mismo. Por otro lado, diremos que un estudio de viabilidad no es necesario llevarlo a cabo cuando:

Análisis del Sistema (Estudio de la Viabilidad)

Viabilidad Económica

Evaluación del Costo de desarrollo del producto

Ingresos netos o beneficios Obtenidos del producto desarrollado

VS

Análisis del Sistema ( Estudio de la Viabilidad)

Viabilidad Técnica

Estudio de Función, Rendimiento y Restricciones que puedan afectar a la consecución de un sistema aceptable

Análisis del Sistema ( Estudio de la Viabilidad)

Viabilidad Legal

Determinar cualquier infracción, violación o responsabilidad legal en que se podría incurrir por el desarrollo del producto o sistema


17

Fase 3: Realizar un análisis Técnico y Económico del sistema a realizar El análisis técnico económico tiene que ver con el llevar a cabo un estudio del costo/beneficio que se obtiene al implementar un producto de software. El análisis de Costo/Beneficio es una valoración de la justificación económica para un proyecto de sistema basado en computadora. Determina los costos para el desarrollo del proyecto y los pondera con los beneficios tangibles (por ejemplo: medible directamente en dinero) y beneficios intangibles (mejor calidad del diseño, mayor satisfacción del cliente, mejores decisiones de negocios) del sistema. Fase 4: Asignar funciones de Hardware, Software, Personal, de Bases de Datos, etc. Fase 5: Establecer restricciones de presupuesto y planificación temporal Fase 6: Definir el Sistema

La justificación económica es obvia

El riesgo técnico es bajo

Se esperan pocos problemas legales

No existe ninguna alternativa razonable

1. Introducción a la Ingeniería de Software

Documents

Transcript of 1. Introducción a la Ingeniería de Software