IngSw//Sala Limpia

INGENIERIA DEL SOFTWARE

SALA LIMPIA

Definición 

La ingeniería del Software de sala limpia es un enfoque formal para el desarrollo del Software, que pueda dar lugar a un Software que posea una calidad notablemente alta. Emplea la especificación de estructura de cajas (o métodos formales) para el modelado de análisis y diseño, y hace hincapié en la verificación de la corrección, más que en la comprobación, como mecanismo fundamental para hallar y eliminar errores. Se aplica una comprobación estadística de utilización para desarrollar la información de tasa de fallos necesaria para certificar la fiabilidad del Software proporcionado.

La filosofía de sala limpia es un enfoque riguroso de la ingeniería del Software. Se trata de un modelo de proceso del Software que hace hincapié en la verificación matemática de la corrección, y en la certificación de la fiabilidad del Software. El resultado final son unas tasas de fallo extremadamente bajas, que sería difícil o imposible de conseguir empleando unos métodos menos formales.

Tareas de Sala Limpia

La sucesión de tareas de sala limpia para cada incremento, se manifiesta mediante unos requisitos globales del sistema o producto que se van desarrollando empleando los métodos de ingeniería de sistemas. Una vez que se han asignado una funcionalidad al elemento de Software del sistema el tubo de la sala limpia comienza sus incrementos y se producen las siguientes tareas.

- Planificación de Incrementos. La planificación incremental permite calidad temprana y continua interacción con el usuario. Facilita mejoras de proceso mientras el desarrollo progresa. El acercamiento incremental evita los riesgos inherentes integración tardía en el ciclo de desarrollo.

- Recolección de requisitos. El propósito del proceso del análisis de requisitos es 1) definir requisitos para el producto de software, incluyendo función, uso, ambiente, y funcionamiento, y 2) obtener un acuerdo con el cliente en los requisitos como la base para la función y especificación del uso.

- Especificación de la estructura de cajas. Tres tipos especiales de funciones matemáticas son importantes en el desarrollo a Sala limpia, debido a su correspondencia y correlación en el proceso de descomposición y verificación. Estas funciones son conocidas como la caja negra, la caja de estado y caja limpia. En la estructura de las cajas se pueden aplicar una variedad de estrategias de descomposición, además se puede incluir funcionabilidad y orientación a objeto.

- Diseño Formal. Mediante el uso del enfoque de estructura de cajas, el diseño de sala limpia es una extensión natural y sin discontinuidades de la especificación. Dan los objetivos, los participantes, los criterios de entrada, las tareas, la verificación, las medidas y los criterios comunes de la salida en los procesos, así como elementos de proceso común.

- Verificación de Corrección. El equipo de sala limpia lleva a cabo una serie de rigurosas actividades de verificación de corrección aplicadas primero al diseño y después al código. El propósito del proceso de la verificación de la corrección, es verificar la corrección del incremento del software usando técnicas matemáticas.

- Generación de Código, inspección y verificación. Las especificaciones de estructura de caja que se representan mediante un lenguaje especializado se traducen la lengua de programación mas adecuado. 

- Planificación de la comprobación estadística, Comprobación estadística de utilización y Certificación. El propósito del proceso estadístico de prueba y de certificación es demostrar la aptitud del software para el uso en un experimento estadístico formal. La "aptitud para el uso" se define con respecto a los modelos de uso y a las metas de la certificación empleados en el proceso de prueba. Las metas de certificación, primero establecidas en el plan de medida y refinadas en el plan de prueba de incremento, se pueden expresar en términos tales como índice de confiabilidad del software.

Cajas de Sala Limpia 

Una caja encapsula el sistema con un cierto grado de detalle. Mediante un proceso de refinamiento progresivo, se van refinando las cajas para formar una jerarquía en la cual cada caja tiene una transferencia. Para esto se utilizan tres tipos de cajas:

- Caja Negra. Especifica el comportamiento del sistema, o de una parte de un sistema.

- Caja de Estado. Esta caja encapsula los datos de estados y de servicios (operaciones) de forma análoga a los objetos. En esta vista de especificación, se representan las entradas de la caja de estados y sus salidas.

- Caja Transparente. Las funciones de transición que están implicadas en la caja de estados se definen en la caja transparente.

 Verificación de diseño 

El diseño que se utiliza en la ingeniería del Software de sala limpia hace mucho uso de la filosofía de programación estructurada. Son realmente las funciones básicas de procesamiento, se refinan ahora utilizando una expansión progresiva de funciones matemáticas en estructuras de conectivas lógicas.

 Comprobación de la sala limpia 

La técnica y estrategia de la comprobación de la sala limpia es algún fundamentalmente distinto de los enfoques convencionales de comprobación. Los métodos convencionales derivan de un conjunto de casos de prueba para descubrir errores de diseño y codificación.

 Diferenciar de Sala Limpia 

Existen diversos métodos o paradigmas que nos reflejan la diferencia notoria de que sea sala limpia. 

- Hace uso explícito del control estadístico de calidad.

- Verifica la especificación del diseño empleando una demostración de corrección basada en las matemáticas. 

- Hace mucho uso de la comprobación estadística de utilización para descubrir errores de especial incidencia.

INGENIERIA DEL SOFTWARE

INGENIERIA EN SISTEMAS

Cuestionario:

1.   ¿Cuál es el origen de la ingeniería de sistemas?

2.   ¿En qué consiste cada elemento del sistema basado en computadoras?

3.   Explique cada una de las restricciones que el equipo de trabajo puede encontrar para construir un modelo de sistemas

4.   ¿En qué consiste la ingeniería de procesos de negocios?

5.   ¿En qué consiste la ingeniería de negocios?

Respuestas

1.   Hace casi 500 años, Maquiavelo dijo: c... no hay nada más difícil de llevar a cabo, más peligroso de realizar o de éxito más incierto que tomar el liderazgo en la introducción de un nuevo orden de cosas». Durante los Últimos 50 años, los sistemas basados en computadora han introducido un nuevo orden. Aunque la tecnología ha conseguido grandes avances desde que habló Maquiavelo, sus palabras siguen sonando a verdad

La ingeniería del software aparece como consecuencia de un proceso denominado ingeniería de sistemas. En lugar de centrarse únicamente en el software, la ingeniería de sistemas se centra en diversos elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información.

2.      Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema:

·         Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido.

·         Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo y dispositivos electromecánicos (p.ej.: sensores, motores, bombas) que proporcionan una función externa.

·         Personas. Usuarios y operadores del hardware y software.

·         Bases de Datos. Una gran colección de información organizada a la que se accede por medio del software.

·         Documentación. Manuales, formularios y otra información descriptiva que retrata el empleo y/o operación del sistema.

·         Procedimientos. Los pasos que definen el empleo especifico de cada elemento del sistema o el contexto procedimental en que reside el sistema. 

3.   Para construir un modelo de sistema, el ingeniero debería considerar algunas                                                             restricciones:

o   Supuestos que reducen el número de permutaciones y variaciones posibles, permitiendo así al modelo reflejar el problema de manera razonable. Por ejemplo, considere un producto de representación en tres dimensiones usado por la industria de entretenimiento para crear animaciones realistas. Un dominio del producto permite la representación de formas humanas en 3D. Las entradas a este dominio comprenden la habilidad de introducir movimiento de un "actor" humano vivo, desde vídeo o creando modelos gráficos. El ingeniero de sistemas hace ciertos supuestos sobre el rango de movimientos humanos permitidos (p.ej.: las piernas no pueden enrollarse alrededor del tronco) de manera que puede limitarse el proceso y el rango de entradas.

o    Simplificaciones que permiten crear el modelo a tiempo. Para ilustrarlo, considere una compañía de productos de oficina que vende y suministra una amplia variedad de fotocopiadoras, faxes y equipos similares. El ingeniero de sistemas está modelando las necesidades de la organización suministradora y está trabajando para entender el flujo de información que engendra una orden de suministro. Aunque una orden de suministro puede generarse desde muchos orígenes, el ingeniero categoriza solamente dos fuentes: demanda interna o petición externa. Esto permite una partición simplificada de entradas necesaria para generar una orden de trabajo.

o   Limitaciones que ayudan a delimitar el sistema. Por ejemplo, se está modelando un sistema de aviónica para un avión de próxima generación. Como el avión tendrá un diseño de dos motores, todos los dominios de supervisión de la propulsión se modelarán para albergar un máximo de dos motores y sus sistemas redundantes asociados.

o   Restricciones que guían la manera de crear el modelo y el enfoque que se toma al implementar el modelo. Por ejemplo, la infraestructura tecnológica para el sistema de representación en tres dimensiones descrita anteriormente es un solo procesador basado en un Power-PC. La complejidad de cálculo de los problemas deben restringirse para encajar en los límites de proceso impuestos por el procesador.

o   Preferencias que indican la arquitectura preferida para toda la información, funciones y tecnología. La solución preferida entra a veces en conflicto con otros factores restrictivos. Aunque, la satisfacción del cliente es a menudo tomada en cuenta hasta el punto de realizar su enfoque preferido. 

Los procesos de negocio pueden ser controlados y administrados de forma manual o por un sistema de software, la Ingeniería de Procesos (conocida también como Automatización de Procesos), es la práctica de analizar el flujo operativo y/o administrativo de una compañía para descubrir elementos que pueden optimizarse, a fin de implementar la mejor manera de llevar a cabo dicho flujo o proceso.

4.   INGENIERIA DEL PRODUCTO

El objetivo de producto es traducir el deseo del cliente de un conjunto de capacidades a un producto operativo.

Se establece una infraestructura se soporte e incluye la tecnología requerida

Esta ingeniería debe crear una arquitectura y una infraestructura

La visión global se consigue a través de la ingeniería de requisitos

Los requisitos generales del producto se obtienen del cliente

Luego de conocido los requisitos, la misión del análisis de sistemas es asignar funcionalidad y comportamiento de cada uno de los cuatro elementos.

INGENIERÍA DEL SOFTWARE

2DO CUESTIONARIO

1. Realizar un pequeño mural con recortes periodísticos acerca de lo que las empresas están requiriendo en el área de la informática.

 2. Análisis y Diseño estructurado de nuestro proyecto

D.E.R

DIAGRAMA DE COMPONENTES

DIAGRAMA DE CLASES

DIAGRAMAS DE CASOS DE USOS

DIAGRAMA DE ESTADO

3. Calcule las métricas orientadas al tamaño, punto de función y ampliadas, así como las métricas de calidad.

PSEUDOCODIGO FARMACIA JERUSALÉN

Main()

{

Int opción;

Do{

Print(“MENU”);

Print(“1. Ingresar producto”);

Print(“2. Ingresar Proveedor”);

Print(“3. Devolución Producto”);

Print(“4. Salir);

read(opción);

switch(opcion)

{

Case 1:IngresarProducto();

             Break;

Case 2:IngresarProveedor();

             Break;

Case 3:devolucion();

             Break;

Default: print(“OPCION INVALIDA”);

             Break;

}

While(opcion !=4);

}

IngresarProducto() {

Int id,cantidad;

String nombre;

Print (“ID Producto:”);

Read (id);

Print (“Nombre del producto:”);

Read (nombre);

Print (“Cantidad:”);

Read (cantidad);

Guardar(id,nombre,cantidad);

}

IngresarProveedor()

{

Int id;

String nombre;

String dirección;

String  telefono;

Print (“id de Proveedor:”);

Read (id);

Print (“Nombre:”);

Read (nombre);

Print (“Direccion:”);

Read (direccion);

Print (“Telefono:”);

Read (telefono);

Guardar(id,nombre,dirección,telefono);

}

Devolucion()

{

Int idprod, idprv , cantidad;

Time fecha;

Print (“ID Producto:”);

Read (idprod);

Print (“ID Proveedor:”);

Read (idprv);

Print (“Cantidad devuelta:”);

Read (cantidad);

Print (“Fecha de devolucion:”);

Read (fecha);

Guardar(id,nombre,cantidad);

}

 POSIBLES RIESGOS DEL SW GENERICOS

4. Preparar material Didáctico acerca de la garantía de calidad y gestión de configuración del software.

GARANTIA DE CALIDAD DEL SOFTWARE (SQA/GCS)

La tendencia de la calidad

La tendencia de la calidad se ha utilizado desde los años cuarenta con el objetivo de obtener una alta calidad del producto tanto en ahorro de costes y en una mejora general, para ello se basa en la terminología de GTC (gestión de calidad total) normalmente se encuentra una progresión básica de cuatro pasos que constituye el fundamento de cualquier programa de GTC.

Los dos primeros pasos se centran en la mejora del proceso, el tercer paso se centra en el usuario del producto y finalmente el cuarto paso va más allá del producto se centra en la utilización del producto en el mercado.

Garantía de calidad del software

Para tener una garantía de calidad del software debe existir una concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo claramente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente.

Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.

Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.

Muchas de las veces existe un conjunto de requisitos implícitos que a menudo no se mencionan por ejemplo: el deseo por facilitar el uso y un buen mantenimiento. Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software no se logra.

Puntos importantes:

1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.

2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.

3.Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.

Problemas de fondo

La historia de la garantía de calidad en el desarrollo de software es paralela a la historia de la calidad en la creación de hardware. Durante los primeros años de la informática (los años cincuenta y sesenta), la calidad era responsabilidad únicamente del programador. Durante los años setenta se introdujeron estándares de garantía de calidad para el software en los contratos militares para desarrollo de software y se han extendido rápidamente a los desarrollos de software en el mundo comercial

Ampliando la definición presentada anteriormente, la garantía de calidad del software (SQA) es un «patrón de acciones planificado y sistemático» que se requiere para asegurar la calidad del software.

El grupo de SQA sirve como representación del cliente en casa. Es decir, la gente que lleva a cabo la SQA debe mirar el software desde el punto de vista del cliente.

Actividades de SQA

La garantía de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes los ingenieros de software que realizan trabajo técnico y un grupo de SQA que tiene la responsabilidad de la Planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes-.

Los ingenieros de software afrontan la calidad (y realizan garantía de calidad) aplicando métodos técnicos sólidos y medidas, realizando revisiones técnicas formales y llevando a cabo pruebas de software bien planificadas.

Las reglas del grupo de SQA tratan de ayudar al equipo de ingeniería del software en la consecución de un producto final de alta calidad. El Instituto de Ingeniería del Software recomienda un conjunto de actividades de SQA que se enfrentan con la planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes. Éstas son las actividades que realizan(o facilitan) un grupo independiente de SQA:

Establecimiento de un plan de SQA para un proyecto.

El plan se desarrolla durante la planificación del proyecto y es revisado por todas las partes interesadas. Las actividades de garantía de calidad realizadas por el equipo de ingeniería del software y el grupo SQA son gobernadas por el plan. El plan identifica:

evaluaciones a realizar,

auditorias y revisiones a realizar,

estándares que se pueden aplicar al proyecto,

procedimientos para información y seguimiento de errores

documentos producidos por el grupo SQA,

realimentación de información proporcionada al equipo de proyecto del software.

Cuál es el papel de un grupo de SQA

Participación en el desarrollo de la descripción del proceso de software del proyecto. El equipo de ingeniería del software selecciona un proceso para el trabajo que se va a realizar. El grupo de SQA revisa la descripción del proceso para ajustarse a la política de la empresa, los estándares internos del software, los estándares impuestos externamente (por ejemplo: 1SO 9001), y a otras partes del plan de proyecto del software.

Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido. El grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y verifica que se han hecho las correcciones.

Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software. El grupo de SQA revisa los productos seleccionados; identifica, documenta y sigue la pista de las desviaciones; verifica que se han hecho las correcciones, e informa periódicamente de los resultados de su trabajo al gestor del proyecto.

Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripción del proceso, en los estándares aplicables o en los productos técnicos.

Registrar lo que no se ajuste a los requisitos e informar a sus superiores. Los elementos que no se ajustan a los requisitos están bajo seguimiento hasta que se resuelven.

GESTION DE LA CONFIGURACION DEL SOFTWARE (GCS/SCM)

LINEA BASE.

•          Especificación o producto que se ha revisado “formalmente” y sobre la que se ha llegado a un acuerdo y, que de ahí en adelante, sirve como base para un desarrollo posterior y que puede cambiarse sólo a través de procedimientos formales de control de cambios.

Elementos de configuración del software

• Es un documento completo de casos de prueba o un componente de un programa dado.
• Estos se organizan como objetos de configuración.
• Especificacion de diseño.
• Diseño arquitectonico.
• Diseño de datos.
• Diseño de modulos.

Diseño de interfaces

El proceso de GCS.

• Garantiza la calidad del software, su responsabilidad principal es el control de cambios.
• También es importante de las distintas versiones del software, de las auditorias de la configuración  del software para asegurar que se desarrollen adecuadamente y de la generación de informe sobre los cambios realizados en la configuración.

La GCS llevan a la definición de 5 preguntas

(1). Identificación de objetos en la configuración del software

• Se identifican 2 tipos de objetos.
• Objeto básico.

Es una unidad de texto creada por el ingeniero de software durante el análisis, diseño, codificación o pruebas.

• Objeto compuesto.

Es una colección de objetos básicos.

(2). Control de versiones.

• Combina procedimientos y herramientos para gestionar las versiones de los objetos de configuración creados durante el proceso del software.

(3). Control de cambios.

• Para cada cambio aprobado se genera una orden de cambio de ingenieria (OCI), que describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisión y de auditoria.

(4). Auditoria de la configuración.

• La identificación, el control de versiones y el control de cambios ayudan al equipo de desarrollo de software a mantener un orden.
• Se plantea las siguientes preguntas.

Ø  Se ha hecho el cambio especificado en la OCI?

Ø  Se han especificado la fecha del cambio y el autor?

Ø  Se han seguido procedimientos de GCS para señalar el cambio, registrarlo y divulgarlo?

Ø  Se han actualizados adecuadamente todos los ECS relacionados?

(5). Informe de estado.

• Llamada también contabilidad de estado.
• Que pasó?
• Quién lo hizo?
• Cuándo pasó?
• Qué mas se vio afectado?

Resumen.

La GCS es una actividad de protección que se aplica a lo largo de todo el proceso del software. Una vez se ha desarrollado y revisado un objeto de configuración, se convierte en una línea base. El control de versiones es un conjunto de procedimientos y herramientas que se usan para gestionar el uso de los objetos. El control de cambios es una actividad procedimental que aseguran la calidad y la consistencia a medida que se realizan cambios en los objetos de la configuración.

INGENIERÍA DEL SOFTWARE

(1er Cuestionario en conjunto con el 1er Sistemático)

1.Explicación de las características del Software.

2.Ejemplos en donde se aplica las características del Software.

3.Explicación de las capas de desarrollo del Software.

4. Explicación mediante un paquín de los diferentes mitos y realidades en el desarrollo del Software

5.Explicación de los modelos de desarrollo del Software

                                                                         

       Explicación de las características del SW

El software no se fabrica, se desarrolla

Los software son desarrollados o construidos mediante la intervención de un grupo de personas trabajando en  conjunto de acuerdo a algún estudio previo del problema presente en cierta entidad que requiera de un sw. Y se dice que no se fabrica porque  no se hace a partir de sus componentes o a través de maquinas.

El software no se estropea, se desactualiza

Básicamente lo que le sucede a los sw con el tiempo es la desactualización quedando estos obsoletos o estropeados para los ojos de los usuarios finales. Pero esto no quiere decir que no se le pueda dar el debido mantenimiento para dichas actualizaciones acordes a las nuevas necesidades del cliente.

El sw no se ensambla se construye a medida

Respecto a la creación de los software se tienen que crear  como ya habíamos expuesto anteriormente, mediante algún estudio previo del problema presente en cierta entidad. Y no siempre es funcional ensamblar cierto sw creado para determinada empresa en otra a la que los requisitos sean aparentemente los mismo, hablando acorde al desarrollo funcional de está con la otra.

        Ejemplos de la aplicación del Software.

    

      Explicación de las capas del desarrollo del sw.

Calidad: en esta etapa se abordan afondo los requisitos que necesita  nuestro software (¿Qué es lo que necesita nuestro sw para ser funcional?), se realizan una cierta cantidad de pruebas para ver la funcionalidad del sw y entregar al final que se ajuste a las necesidades del cliente.

Procesos: en esta etapa se define el ¿Cómo realizaremos, nuestro software? basándonos en el estudio ya analizado en la primer etapa. Se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

Métodos: Nos indican como construiremos nuestro software, apartir del análisis de requisitos, diseño, pruebas y mantenimiento incluyendo las actividades de modelado definiendo el ¿A través de que, realizaremos nuestro sw?

Herramientas: definimos el ¿Con qué desarrollaremos nuestro sw? Luego de haber pasado cada una de las etapas ya anteriores, auxiliándonos de las herramientas CASE para dicho desarrollo.

ESCENARIOS EN DONDE SE REFLEJA LOS MITOS Y REALIDADES DEL SW. EN CUANTO A GESTON, CLIENTE Y EQUIPO DESARROLLADOR.

   

APLICACIÓN DE LOS MODELOS DE DESARROLLO

Modelo lineal: la aplicación del modelo lineal la apreciamos en todo en transcurso del desarrollo del software ya que este modelo está basado en la creación progresiva del software.

Modelo de desarrollo Rápido: al igual que el modelo lineal el modelo de desarrollo está implícito en todo el desarrollo del sw, a diferencia que este está enfocado en el trabajo interno del grupo desarrollador del sw. Ej.: La planeación del buen desempeño de un software realizado por el grupo desarrollador.

Modelo de incremental: Si bien este modelo está basado en la corrección del sw. A medida de que vamos desarrollando nuestro software se nos presentaran una serie de errores que tenemos que corregir es ahí donde se hace presente el modelo incremental el cual nos permite ir avanzado progresivamente en la creación de nuestro sw, ya que este es flexible.

Modelo Espiral: Este modelo es aquel que nos permite darle mantenimiento y/o actualización a nuestro sw basado en las nuevas necesidades del cliente para éste.

Modelo de Desarrollo Concurrente: este modelo lo aplicamos mucho antes de empezar a crear nuestro sw, ya que este nos define los requisitos que necesita nuestro sistema para ser funcional, en este modelo es donde se realiza el análisis de requisitos.

Primer Sistemático

Sabiendo las características de los sw, ¿cómo se aplicarían a un sw contable?

“El Software no se implementa, se construye a medida”,  planteo esta característica ya que cierto software creado para “x” entidad financiera puede no suplir las necesidades de la otra entidad a la cuales los requisitos son aparentemente los mismos, por eso decimos que un software se tiene que construir a medida.

Mencione las diferencias entre un tipo de aplicación de sw y otro

Véase en los ejemplos de la aplicación del software, al principio del capítulo

Realice un paquín Ilustrado, Explicando gráficamente los mitos y realidades de la Ing. del SW

Véase en los ESCENARIOS EN DONDE SE REFLEJA LOS MITOS Y REALIDADES DEL SW. EN CUANTO A GESTON, CLIENTE Y EQUIPO DESARROLLADOR, al principio del capítulo

Explicación del grafico del pastel

Véase en la Explicación de las capas del desarrollo del sw, al principio del capítulo

Elabore un cuadro sinóptico con las fases genéricas que se practican durante el proceso del sw

 Proponga una situación en donde usted tenga que hacer uso del hito que se expresa en el marco del trabajo común de la Ing. del sw

Los Hitos se refieren a la toma de decisiones para llevar a cabo determinada tarea.

Ej.:

Cuando vamos a desarrollar un sistema, luego de haber concluido el análisis del sistema, tenemos que tomar los caminos más viables para llevar a cabo dicho desarrollo en donde  incluyamos costos económicos, recursos disponibles, cantidad de personas en el equipo desarrollador, etc.