Cap 2: Ingeniería De Software, Sommerville

2.1. En la introducción de este capítulo, Baetjer afirma que: “El proceso genera interacción entre usuarios y diseñadores, entre usuarios y herramientas cambiantes [tecnología].”. Enliste cinco preguntas que:

a) los diseñadores deben responder a los usuarios:

 ¿Qué tan factible y seguro será el sistema en lo que se refiere al tratamiento de la información de su empresa?

 ¿En qué le será útil esta herramienta?

 ¿Podré entender el programa?

b) los usuarios deben plantear a los diseñadores,

 ¿Después de haber instalado el sistema en mi empresa, se harán los respectivos mantenimientos al mismo y en qué tiempo se efectuarán?

 ¿Me será útil el software a implementarse en la empresa?

 ¿Habrá como realizar todas las funciones a mi encargada?

c) los usuarios deben hacerse a sí mismos sobre el producto de software que ha de elaborarse,

 ¿Habrá un encargado de la empresa desarrolladora, que capacite constantemente por un cierto periodo de tiempo a mis empleados?

 ¿El sistema que me van a realizar, podrá aumentar la competitividad y el nivel financiero de mi empresa?

d) los diseñadores deben plantearse acerca del producto de software que va a construirse y del proceso que se usará para ello.

 ¿Los requisitos son estables?

 ¿Existe la posibilidad de que con el tiempo alguno de éstos cambie y afecte el diseño del sistema?

 ¿El cliente y/o usuario me ha dicho todo lo que necesito saber?

2.2. Trate de desarrollar un conjunto de acciones para la actividad de comunicación. Seleccione una acción y defina un conjunto de tareas para ella.

Utilizando el modelo en cascada: Entrevista con un cliente:

En la primera cita presentarme de manera sencilla y platicar ampliamente con el cliente sobre:

o Cuál es el producto que en realidad quiere

o Como lo desea

o Cuál va a ser la función del software en la organización.

En la siguiente cita se trataran temas sobre los costos, el tiempo, requisitos que necesito para desarrollar el software.

Sera necesario presentarle al cliente por fases o etapas como está quedando el proyecto para así saber si el desea cambios y evitar que hallan problemas al finalizar el proyecto.

2.3. Un problema común durante la comunicación ocurre cuando se encuentra a dos participantes que tienen ideas en conflicto sobre lo que debe ser el software, es decir, que tienen requerimientos mutuamente conflictivos. Desarrolle un patrón del proceso (esto sería un patrón de la etapa) con el empleo de la plantilla presentada en la sección 2.1.3 que aborda este problema y sugiera un enfoque eficaz para él.

Nombre del patrón: ConflictoFunciónSoftware.

Intención: debido a que este patrón está enfocado en establecer la comunicación y recabar requerimientos, es necesario identificar de manera clara los requerimientos del software.

Tipo: Patrón de etapa.

Contexto inicial:

 Establecer comunicación entre los clientes e ingenieros de software.

 Conocer el alcance del proyecto, requerimientos básicos y restricciones del proyecto.

Problema: No hay claridad en cuanto al funcionamiento del software, por lo cual hay conflictos en los requerimientos

Solución: establecer comunicación con los clientes o realizar reuniones con ellos para tener claro el funcionamiento del software y así no tener conflictos en la obtención de requerimientos.

Contexto resultante: Los participante aprueban los requerimientos del software. Después de esto: 1) El proyecto evolucionara para convertirse en software de producción. 2) Quizá sea necesario el uso de otro proceso de patrón.

Patrones relacionados: EquipoDelProyecto, LineamientosDeColaboración, DefiniciónDeAlcances, RecabarRequerimientos, DescripciónDeRestricciones y CreaciónDeEscenarios.

Usos y ejemplos conocidos: cuando los requerimientos sean confusos o haya conflictos.

2.4. Investigue un poco sobre el PPS y haga una breve presentación que describa los tipos de mediciones que se pide hacer a un ingeniero individual de software y la forma en la que pueden usarse para mejorar la eficacia personal.

MODELOS DE PROCESO PERSONAL Y DEL EQUIPO

El modelo del proceso de software se ha desarrollado en un nivel corporativo u organizacional, será eficaz solo si acepta una adaptación significativa para que cubra las necesidades del equipo del proyecto que en realidad hace el trabajo de ingeniería del software.

PROCESO PERSONAL DEL SOFTWARE

Todo desarrollador de software utiliza algún proceso para elaborar software de cómputo. El proceso puede ser caprichoso Pero el desarrollador tiene que realizar varias actividades como:

1. Planeación: todas las mediciones se registran en hojas de trabajo o plantillas, se identifica las tareas de desarrollo y se crea un programa para un proyecto.

2. Diseño de alto nivel: Se desarrolla las especificaciones externas mientras se crea el diseño de componentes.

3. Revisión del diseño de alto nivel: Se descubren errores en el diseño, se mantiene las mediciones para todas las tareas y resultados del trabajo importantes.

4. Desarrollo: Se mejora y revisa el diseño se mantiene errores en el diseño de componente, genera, revisa, compila y comprueba.

5. Post mortem: Se determina la eficacia del proceso por medio de medidas y mediciones obtenidas EL PPS: enfatiza las necesidades de detectar los errores. Se logra con una actividad de evaluación rigurosa. Representa un enfoque disciplinario en la ingeniería del Software El PPS no ha sido adoptado con amplitud por la industria, tiene debilidades y fortalezas.

PROCESO DEL EQUIPO DEL SOFTWARE

Este es elaborado en equipo de trabajo que sea auto dirigido para el proyecto y producir software de alta calidad.

Mostrar a los representantes como dirigir y motivar para que mantengan un buen rendimiento, acelerar la mejora de procesos de software.

2.5. El uso de scripts (mecanismo requerido en el PES) no es apreciado de manera universal en la comunidad del software. Haga una lista de pros y contras en relación con los scripts y sugiera al menos dos situaciones en las que serían útiles, y otras dos en las que generarían menos beneficios.

Pros:

 Son un guía para los miembros de equipo de trabajo.

 Permiten definir actividades específicas del proceso.

 Ayudan a que los procesos se realicen de mejor manera.

Contras:

 No habría sincronización en las actividades o procesos.

 No existe modelos o estándares a seguir.

 No existiría un control de la programación de las actividades a realizar.

Situaciones en la que es útil los scripts:

 Proyectos industriales.

 Proyectos que son de alta calidad.

Situaciones en las que no generan mucho beneficio:

 Proyectos no muy grandes.

 Proyectos en los que no es muy importante la calidad sino que estén realizados a tiempo.

2.6. Lea a [Nog00] y escriba un ensayo de dos o tres páginas donde analice el efecto que tiene el “caos” en la ingeniería de software.

ENSAYO Nº 1

1. TEMA

Nog00

2. ANTECEDENTES:

El presente trabajo es con la finalidad de conocer Nog00, donde analiza el efecto que tiene el caos en la ingeniería de software, en qué forma se presenta.

3. DESCRIPCIÓN:

En 1994 apareció la primera edición del informe CHAOS del Standish Group sobre le eficiencia en la fabricación de software, en esta edición los costos en la construcción del software era de 189%, en el 2014 mejoraron aunque se mantenían pobres. Por ejemplo sólo un 29% de proyectos concluyeron satisfactoriamente, 53% no cumplieron con las expectativas de los usuarios y un 18% que definitivamente fueron suspendidos.

Independientemente de los resultados, no se generaliza que los actuales procesos de construcción del software, instaurados principalmente en las grandes compañías, resultan ineficientes. Muchos de estos proyectos acaban siendo suspendidos por no poder soportar los sobre costos o el rate-off derivado de los retrasos y la mala gestión. Otros, aun siendo finalizados, acaban en un cajón por no responder a las expectativas de los usuarios finales, generando insatisfacción y desconfianza en los propios procesos de desarrollo.

Como conclusión, el Standish Group propone las siguientes 10 claves para el éxito en el desarrollo de software:

Involucración de los usuarios.

Soporte de gestión ejecutiva.

Objetivos de negocio claros.

Enfoque a la optimización.

Proceso ágil.

Gestión de proyectos.

Gestión financiera.

Recursos humanos preparados.

Metodología formal.

Herramientas e infraestructuras estándar.

NOTA: “El caos en la ingeniería del software se presenta cuando se forma un desorden en la ruta de actividades que se debe seguir para la construcción del software generando de esta manera incumplimiento en el objetivo propuesto.”

Un botón más en el formulario

Ya que la mayoría de organizaciones disponen de un área de TI, han abordado de una u otra manera el problema de la eficiencia en el proceso de desarrollo de software. En este sentido, las líneas de trabajo fundamentales han sido:

Definición e implantación de metodologías.

Organización y despliegue

...