Pressman 1 A

UNIVERSIDAD T ÉCNICA DE AMBATO MAESTRÍA EN GESTIÓN DE BASE DE DATOS

FACULTAD DE I NGENIERÍA EN SISTEMAS ELECTRÓNICA E I NDUSTRIAL Materia: INGENIERÍA

DEL SOFTWARE

Profesor: ING. MS. FRANKLIN MAYORGA Preparado por:

ING. K. RENATO URVINA B. ING. DANIEL ORITZ M. ING. MAURICIO VILLACIS.

 Texto: Ingeniería del del Software – Pressman, Pressman, 6ta. Edición. Problemas y Puntos Puntos a Considerar: Considerar: Capítulos: 1 y 2 Ambato, 31 de Enero del 2009

CAPITULO 1. 1.1. Encontrar al menos cinco ejemplos adicionales de la manera en que la ley de las consecuencias imprevistas se aplica al software de computadora.

Estos son algunos ejemplos positivos y negativos que se aplican no solo en el mundo, sino que también han llegado a afectar la vida y cotidianidad en nuestro país:

1. Redes sociales como YouTube, myspace, facebook , etc. Afectan ya a la vida cotidiana, sobre todo de las personas jóvenes, quienes las sienten como herramientas naturales de su diario vivir, con las mismas se facilita el intercambio y publicación de ideas. Los weblogs permiten el intercambio de ideas en cuanto a temas variados y específicos, volviendo aún más abundante la cantidad de información disponible en la red. Enciclopedias abiertas como Wikipedia, la cual a más de ser fuente de información se puede agregar ó editar la información allí contenida. 2. Cada día más artefactos, dispositivos y cosas que se utilizan cotidianamente incluyen software, se vuelven más funcionales y útiles por ejm. Los automóviles modernos llevan computador a bordo que permite al usuario saber si existe alguna falla en el automotor o saber cuántos kilómetros puede recorrer con el combustible en tanque, ó la temperatura ambiental, etc. Los edificios inteligentes, los iphone, hasta un microondas funcionan de acuerdo al software instalado. 3. La aplicación de los GIS se ha convertido en herramienta indispensable para localizar yacimientos, levantar mapas, realizar monitoreo, etc. Afectando de forma positiva a distintas áreas de aplicación como Geología, Topología, Oceanografía, Geografía, Minería, Petróleos, Urbanismo, Localización de personas y objetos, etc. 4. En nuestro país, el cercano fin (si no lo es ya) de la presentación de impuestos en formularios llenados manualmente. Así como la presentación obligatoria de anexos de quienes están obligados a presentar contabilidad. Han afectado la cultura tributaria y los profesionales de Contabilidad deben estar al día con relación a estas nuevas herramientas. 5. La piratería de software ha proliferado mucho en nuestro país. Convertido en un negocio que aunque ilícito, ha permitido hacer accesibles a programas que por su costo para nuestro medio sería muy difícil poder acceder de manera legal. Junto con esta clase de piratería se asocia también la piratería de otros trabajos como música ó videos, causando pérdidas para sus creadores. 6. Junto con la aplicación de las nuevas tecnologías con los servicios y seguridades que la misma brinda, han aparecido nuevas formas de delito

como hacking, robo de claves; que en función del hacker puede causar mucho daño ó solamente demostrar su habilidad para introducirse en redes ajenas. 7. La aplicación del software en la mayoría de las áreas ocupacionales ha obligado que los profesionales medios y superiores se vean en la obligación de aprender el uso de estas herramientas para no quedar obsoletos en sus distintas profesiones. 8. La proliferación de virus, gusanos y demás causados por el uso de las herramientas como mails, ó memorias infectadas causan pérdidas de tiempo incuantificables, con la correspondiente pérdida económica hasta que se pongan en funcionamiento. 9. La falta de regulaciones claras a la ley de propiedad intelectual y profesionales de leyes que sepan su correcta aplicación crea un vacío grande para quienes nos dedicamos al desarrollo de software. Adicionalmente las agremiaciones profesionales poco o nada han podido hacer al respecto, ahondando más los problemas para los desarrolladores independientes. 1.2. Encontrar algunos ejemplos (positivos y negativos) que indiquen el impacto del software en la sociedad actual. Revisar una de las referencias anteriores a 1990 en la sección 1.1, e indicar las predicciones del autor que resultaron correctas, así como las que fueron erróneas.

EJEMPLOS POSITIVOS BANCA ELECTRÓNICA, Transacciones rápidas y sin necesidad de ir al banco, permiten ahorrar tiempo a los usuarios de la misma. DECLARACION DE IMPUESTOS, De forma más rápida y correcta, se puede presentar los impuestos en el mismo lugar de trabajo. BLOGS Y REDES SOCIALES, Libertad de expresión, intercambio de información. FINANZAS Y CONTABILIDAD, Rapidez en la ejecución y registro de datos. Obtención de información confiable. SISTEMAS DE INFORMACION GEOGRAFICA, Ubicación exacta y levantamientos de áreas geográficas, con información variada para diferentes áreas como la geología, minería, petrolera, hidrografía, meteorología, urbanística, etc. COMPUTACION MOVIL, Las características añadidas a los celulares actúales, hace que puedan interactuar con los PC de escritorio ó laptops, sincronizando transferencias de datos entre ellos, dando movilidad a los usuarios. GOBIERNO ELECTRONICO (e goverment), como por ejemplo el uso de www.compraspublicas.gov.ec, cuya transparencia permite bajar los niveles de corrupción en los contratos públicos.

En forma general todo individuo que aprenda el uso de las herramientas de software mejora su calidad de vida al disminuir el estrés del esfuerzo de obtener información útil para sí mismo. EJEMPLOS NEGATIVOS Riesgos consecuentes del uso de nuevas tecnologías como robo de claves y códigos de accesos, y con los mismos acceder a cuentas bancarias e información privadas. En nuestro medio (Ambato y provincias) la obtención de software sin ningún costo (piratería), ha hecho que el trabajo de desarrollo de software no se valore en su real dimensión. Disponibilidad de información ó imágenes dañinas para los niños, sin restricción, introducción de pederastas y nuevas formas de delitos. En los sistemas financieros, se corre el peligro de la dependencia de los programadores si existe alguna falla en el software, ó limitación de licencias. Dependencia total del software en cuanto al funcionamiento de áreas críticas como los servicios básicos (comunicaciones, electricidad, agua), puertos, aeropuertos, hospitales, etc. Lamentablemente si una persona no aprende el uso de las nuevas tecnologías, corre el riesgo de quedarse obsoleto con los conocimientos y por consecuencia natural su trabajo puede perderse. Adicciones al uso de los videojuegos, mensajes escritos, chats hace que el usuario pierda la noción del mundo real; y puede ser que el daño sea primero a nivel psicológico llegando hasta el nivel físico poniendo en riesgo su propia vida y la de los demás. Al existir una menor necesidad de esfuerzo físico el sedentarismo es un mal que se está extendiendo con fuerza en todos los niveles de usuarios de software. REVISION ANTERIORES A 1990

Entre los libros publicados referenciados en el texto (Ing. del Software – 6ta ed. Pressman) en la sección 1.1. pág. 3, destaca STOLL 1989; quién “argumentó que la “comunidad electrónica” creada por redes y software era la clave del intercambio de conocimiento alrededor del mundo”.

Es evidente que hoy 20 años después, el intercambio de información por medio del uso de internet (tanto web 1.0, como web 2.0 y futuras versiones del web), ha permitido la difusión de investigación y conocimiento sin precedentes. Narrada en forma de novela, el « The Cuckoo's Egg» cuenta la historia de Clifford Stoll, un astrónomo e informático que, comprobando sus sistemas, descubre una diferencia de 75 centavos en la contabilidad. Este pequeño detalle le lleva a darse cuenta de que los ordenadores de su red están siendo atacados por crackers desde el extranjero, y con ello comienza su particular carrera de persecución hasta dar con ellos. Describe la forma en que los crackers se introducen en los ordenadores y la forma en que pueden ser detectados.

 The Cuckoo's Egg (book). (2008, December 3). In Wikipedia, The Free Encyclopedia . Retrieved 22:07,  January 25, 2009, from http://en.wikipedia.org/w/index.php?title=The_Cuckoo %27s_Egg_(book)&oldid=255637764

Extracto del libro “The Cuckoo’s Egg” Cap. 13, pág. 50 Una sola computadora aislada, fuera de comunicación con el mundo, es inmune a los ataques. Pero una computadora aislada ha limitado su valor; no puede mantenerse al ritmo de lo que está pasando alrededor. Las computadoras son de gran uso cuando ellas actúan recíprocamente con las personas, mecanismos, y otras computadoras. Las redes  permitieron a las personas compartir datos, los programas, y correo electrónico. La mayoría las computadoras personales satisfacen las necesidades de sus dueños, y no necesita hablar a otros sistemas. Para el proceso de palabras, hojas de cálculo de contabilidad, y juegos, usted realmente no necesite ninguna otra computadora. Pero conecte un módem a su computadora, y su teléfono informará lo último de la bolsa de valores, los precios del mercado, rumores. Conectando a otra computadora le da una manera poderosa de ponerse a punto en las últimas noticias.

Fue muy acertado en la precisión de que se usaría el internet como medio de comunicación y para la construcción de comunidades de información como si fuesen ciudades; tanto militares, universidades y comercios todos interconectados. Si tal vez existe alguna predicción errada, la misma no es por equivocación sino porque aún no se creaban los buscadores como google ó yahoo. Y es por la forma de buscar información en aquellos años: conectándose al directorio del NIC (Network Information Center in Menlo Park, California, USA.) en la cual si se busca a alguien se debe hacer con comandos telnet /unix, mediante la cual nos devuelve la IP de quien se busque, sin embargo de lo cual esta forma de búsqueda sigue vigente y válida. Adicionalmente, la forma de trabajo de procesadores de palabras y hojas de cálculo ha evolucionado para poder trabajar en forma conjunta (red), en dispositivos móviles (smart phones) y desde la web (google docs), al igual que los  juegos; sin embargo no pierde vigencia al decir que realmente no necesite otra computadora para hacer este trabajo. 1.3. Desarrollar sus propias respuestas a las preguntas formuladas en la sección 1.1. Debátanse con los compañeros de clase . ¿Por qué tarda tanto la obtención del software terminado?

Fallas en etapa de análisis, porque luego de esta fase, no se ha especificado de forma correcta el alcance y los requerimientos de los usuarios. Adicionalmente al diseñar los sistemas no se piensa en la flexibilidad y la evolución natural de las empresas y por ende de los requerimientos; así  como de los cambios exógenos como hardware, entorno y políticas gubernamentales inclusive.

¿Por qué son tan altos los costos de desarrollo de software?

Errores de estimación, porque al no poder entregar a tiempo los sistemas los recursos estimados no son suficientes, y si además agregamos fallas en la etapa de análisis los costos se disparan y no habrá presupuesto del cliente, ni disponibilidad del desarrollador para terminar los mismos. A pesar de que se encuentran herramientas de estimación (Ej. COCOMO y COCOMO II), el desarrollo de software depende del factor humano y por ende es impredecible.

¿Por qué es imposible encontrar todos los errores en el software antes de entregarlo a los clientes?

Fallas en la etapa de diseño, se debe tener en cuenta no solo los posibles datos que se transformarán en información, sino también el entorno operativo (hardware + redes + sistema base + SGBD + usuarios), capacidad de almacenamiento y proceso en fases críticas como tablas con más de 100 mil registros, caídas de energía, y servidores mal configurados. Fallas en la etapa de pruebas, falta de personal que pruebe sin el menor conocimiento de las restricciones de datos que pueda aceptar el sistema, e incluso que no sepa cómo se elaboró el sistema.

¿Por qué se gastan tanto tiempo y esfuerzo en el mantenimiento de los programas existentes?

Fallas en la fase de diseño, al no realizar un diseño que asegure la calidad del software, el mismo se volverá difícil de mantener; llegando incluso a proponer nuevos sistemas. Adicionalmente esto se da por lo general en el software heredado, el cual no por culpa de quienes lo hicieron, sino porque no se disponía de las herramientas, modelos y estándares que se disponen hoy.

¿Por qué es difícil medir el progreso al desarrollar y darle mantenimiento al software?

Porque a pesar de existir modelos, métricas y estándares, introducidos por la ingeniería del software; el desarrollo de software por sí mismo no deja de ser un arte todavía, dependiendo totalmente del factor humano en su etapa

de desarrollo. A pesar de esto también se produce por la incorrecta aplicación de los estándares y modelos que se pueden seguir, y al no asegurar la calidad del software el mantenimiento se vuelve difícil desde que sale a la luz la primera versión de un software. 1.4. ¿La definición de software que se presenta en la sección 1.2. se aplica a los sitios Web? Si la respuesta es afirmativa, indicar la sutil diferencia entre un sitio Web y el software convencional.

Si se aplica, al tener los mismos elementos mencionados en la definición. Sin embargo la sutil diferencia puede radicar en que un sitio web necesita un browser (ejm. Internet explorer, firefox, opera, etc.), que interpreten el código html generado por la aplicación. En cambio el software convencional, puede estar escrito para ejecutarse (en una plataforma ó sistema operativo determinado), de forma directa pues al ser un código compilado no depende de browsers que interpreten el código su carga es más rápida.

1.5. Muchas aplicaciones modernas cambian frecuentemente (antes de presentarlas al usuario final y después de que se empieza a utilizar la primera versión). Sugiéranse algunas formas de construir software para detener el deterioro debido al cambio.

Aplicar estándares de ingeniería de software y ejecutarlas, un claro ejemplo de estos métodos son ISO 12207, ó el modelo CMM. Sin embargo aplicarlas al pie de la letra es difícil, por lo tanto cada empresa (desarrollador) de software debería llegar a establecer su propio estándar basado en los mencionados y aplicarlo a su empresa. Una vez desarrollado ó resumido su estándar de desarrollo; se sugiere cuidar mucho los siguientes aspectos en cada fase del desarrollo: FASE: ANALISIS -

Alcances del sistema.

-

Identificar en lo posible todos los requerimientos del usuario final.

FASE: DISEÑO -

Diseñar al sistema con enfoques de calidad, para facilitar el mantenimiento posterior;

-

Diseñar el sistema lo suficientemente flexible para que se adapte a los cambios naturales que puedan suceder.

-

Diseñar por ende sistemas con suficientes parámetros, y configuraciones para que el mismo no dependa del desarrollador sino que sea flexible y parametrizable por el usuario final ó administrador del sistema.

-

Tomar muy en cuenta los presupuestos que el cliente tenga previstos para tecnología de hardware, para diseño de interfaces, bases de datos y tecnología a utilizar.

FASE: DESARROLLO -

Utilizar componentes reutilizables ya desarrollados en lo posible.

-

Desarrollar componentes ó librerías estándar que puedan ser reutilizados en el futuro.

-

Utilizar tecnología y métodos de desarrollo que permitan introducir cambios posteriores a las versiones que se entreguen al usuario.

-

Desarrollar “pruebas de escritorio” ó interpretación del código por parte de los desarrolladores, antes de entrar a la fase de pruebas.

FASE: PRUEBAS -

Utilizar datos de prueba reales, y en lo posible datos de entorno crítico; como por ejm. Poblar las tablas con miles de filas y medir su reacción en el hardware a utilizar.

-

Probar el sistema en entornos críticos como caídas de energía, fallos en red, etc.

-

Desarrollar manuales ó instructivos.

-

Hacer las aproximaciones e indicaciones al usuario final y realimentar al modelo.

FASE: IMPLANTACION -

Capacitar al usuario, y entregar los manuales ó instructivos disponibles.

-

Utilizar estándares de solicitudes de cambios y nuevos requerimientos posteriores a la implantación de un sistema.

-

Por último se sugiere hacer un control de entrega de versiones y de erratas.

1.6. Considérense las siete categorías presentadas en la sección 1.3. ¿Es posible aplicar el mismo enfoque de la ingeniería del software a cada una de ellas? Explicar la respuesta.

“La ingeniería del software es el establecimiento y uso de principios sólidos de la ingeniería para obtener económicamente un software confiable y que funcione de modo eficiente en máquinas reales” Ingeniería del Software - Pressman – 6ta edición. Pág. 23

Si se puede aplicar a estas categorías. Pero como un enfoque genérico, puesto que los productos software de cada una de estas categorías cumplen con el ciclo del software, independientemente de cómo fue desarrollado ó implementado.

1.7. Seleccionar alguno de los nuevos retos mencionados en la sección 1.3. (o algún desafío aún más nuevo que pudiera haber surgido desde la impresión de este texto) y escribir un documento de una cuartilla que describa la tecnología y los retos que representa para los ingenieros de software.

En el texto de Pressman, en los nuevos retos hemos seleccionado Fuente Abierta. “Uno de los grandes problemas de la ingeniería del software ha sido y es que no ha sabido adaptarse consecuentemente a su propia definición. Esto es algo que se puede considerar como una especie de traición a sí misma, a sus propios fundamentos. El enfoque sistemático y cuantificable ha tenido siempre como barreras las propias de las formas en las que el software se ha desarrollado y distribuido. El formato binario del software, la opacidad en los modelos de negocios, los secretos y barreras comerciales se encuentran entre las principales causas que han imposibilitado estudios cuantitativos y cualitativos a gran escala del software cuyos resultados pudieran ser  verificados sistemáticamente por equipos de investigación independientes. Las "verdades" que han sido enunciadas son, con frecuencia, experiencias puntuales que han sido generalizadas y dadas por válidas ante la falta de alternativas. La propia forma de desarrollar, distribuir y comercializar software ha sido la que ha llevado a la ingeniería del software a la crisis.” 

Ingeniería del Software Libre. Una visión alternativa a la ingeniería del software tradicional – Gregorio Robles - 2002 Revisión 0.94 - versión V congreso HispaLinux - 10 de octubre de 2002

Desde hace más de una década, el software libre ha venido experimentando un gran auge en cuanto a uso, aceptación y, desarrollo. La implantación de Internet junto con las características de las licencias abiertas que "invitan" a todo el mundo a formar parte del equipo de desarrollo, han propiciado que a día de hoy no sólo podamos contar con el código fuente (un gran avance para su estudio en contraposición al del software propietario), sino tomar medidas de los archivos de las listas de correo donde viene plasmada la comunicación del proyecto, los repositorios de versiones gracias a los cuales podemos ver la evolución, etc. De todas estas fuentes se puede extraer una gran cantidad de información de interés, en la mayoría de casos incluso de manera automática. Por tanto, el software libre ofrece la oportunidad de conocer más a fondo el proceso de concepción de software, aportándonos nuevas evidencias y experiencias. Los nuevos retos con respecto al código abierto no solamente se basa en codificar de manera clara y establecer con comentarios ó con documentos asociados lo que hace cada función ó cada parte del código, con lo cual se puede aceptar código de otros desarrolladores incrementando la calidad del producto. Sino que también se basa en la parte económica; puesto que en nuestra área de desarrollo ya no se enfoca al cobro de licencia, o software propietario; debemos cambiar el enfoque económico, una alternativa puede ser concentrarnos en el cobro de servicios. Es un tema que queda aún con más inquietudes que posiblemente se vayan dilucidando desarrollando en el transcurso del tiempo. 1.8. Describir con palabras propias la ley de la conservación de la estabilidad organizacional (sección 1.4.2).

Los alcances y metas que se definen en un sistema desde su inicio no disminuyen, por consecuencia si se realizó un buen análisis inicial, su alcance no sobrepasará al hecho en el análisis inicial; caso contrario se está tratando de otro(s) sistemas. Al entender esto nos damos cuenta que la actividad ó rendimiento de un sistema aunque evolucione, mantendrá un promedio de actividad efectiva; hasta que el mismo se quede obsoleto por la evolución natural de los requerimientos y el entorno del sistema.

1.9. Describir con palabras propias la ley de la conservación de la familiaridad (sección 1.4.2).

Los involucrados en el desarrollo de un sistema, quienes participan de forma directa ó indirecta se mantienen incluso después de la entrega del producto final. Aunque el sistema evolucione, el personal involucrado se sigue

manteniendo aunque sean otras personas. Esto provoca que el sistema crezca de forma sostenida manteniendo su promedio de meta de usuario. Aquí cabe aclarar que el número de usuarios finales directos ó indirectos no es el mismo que el número de personas involucradas en el desarrollo.

1.10. Describir con palabras propias la ley de la calidad decreciente (sección 1.4.2).

Debido a la evolución natural del entorno los requerimientos y funcionalidades de una organización ó población, se debe entender que los sistemas deben evolucionar junto con su entorno; caso contrario quedarán obsoletos y por ende su calidad disminuirá dramáticamente hasta quedar en desuso. En el caso de sistemas críticos los mismos deben evolucionar y transformarse en software heredado.

1.11. A medida que la presencia del software se vuelve más generalizada, los riesgos al público (debido a las fallas en los programas) representan una preocupación significativa y creciente. Desarrollar un escenario catastrófico realista en el que la falla de un programa de computadora podría producir un gran daño (ya sea económico o humano). La mayor parte de los expertos coinciden en señalar que “la manera más probable de destruir el mundo es por accidente”. Y aquí es donde entramos en juego nosotros, los profesionales de la informática: “nosotros somos los que provocamos los accidentes".

http://mit.ocw.universia.net/6.170/6.170/f01/pdf/lecture-01.pdf 

Se utiliza un software que controle la apertura y cierre de las compuertas de una central hidroeléctrica, pero el algoritmo que analiza los datos de ingreso de caudal por un error de digitación del programador pronostica que el caudal probable va a ser mucho mayor que la cantidad real que ingresa, cerrando las compuertas por un lapso de tiempo en el cual no se puede retornar a abrirlas inmediatamente. Esto causará que las turbinas se queden sin agua y por lo tanto deberán hacer un enlace a la red nacional interconectada; pero esa operación toma al menos diez minutos, dejando a las ciudades sin energía eléctrica, con consecuencias imprevisibles para los usuarios de hospitales, clínicas, aeropuertos, etc.

El software en un automóvil, interpreta las señales enviadas por los sensores en los frenos al girar una curva a alta velocidad o frenados intempestivos en ese caso activa el sistema de frenado ABS; si hubiera una falla en los sensores ó en el algoritmo de activación del frenado las consecuencias pueden ser mortales para los ocupantes del mismo.

1.12. Examinar con atención al grupo de noticias de internet comp.risk y preparar un resumen de los riesgos al público que se han discutido recientemente. Fuente alternativa Sofwtare Engineering Note publicada por la ACM.

•

Los computadores del sistema alemán de trenes cayeron por horas. Debora Weber-Wulff . El 14 de enero de 2009 a las 14:03, hubo un fallo de energía, causado por un mal mantenimiento de los sistemas de respaldo “UPS”. Tomo horas restablecer el sistema.

•

Sin embargo, otra razón para no usar Windows para dispositivos médicos.  Jeremy Epstein. Miércoles, 21 Jan 2009

El registro reporta un arduo trabajo por parte del personal de los hospitales luchando contra un gusano computacional, en una red de 8000 PC’s; luego de que más de 800 PC’s aparecieron infectados con el gusano conficker  el cual se autopropaga. Esto se dio por cuanto se desactivaron las actualizaciones automáticas de seguridad de Windows, en la semana de navidad del 2008; y se descubrió cuando en medio de una intervención quirúrgica el PC se reinicio. Incluso Microsoft toma nota del acuerdo de licencia que no debe usar su software para los sistemas críticos para la vida (entre otras cosas). Tal vez eso es sólo una cosa, pero espero que haya consideración de los riesgos antes de hacer caso omiso de esos términos.

•

Riesgos de Avis insuficiente control de los datos de los clientes. Chris Warwick Chris Warwick .

En este caso el código del cliente fue asignado a otro, y los datos del cliente original fueron entregados al otro, quien sin esperar los confirmó y utilizó los servicios de la agencia cargándolos a la cuenta del cliente original.

Al revisar los riesgos probables por el mal uso del software, ó la mala programación causa estragos y eventualmente puede provocar la muerte; nos da un indicativo que el software es una ciencia y un arte que debe ser tratado con todo el rigor posible, siguiendo estándares, pruebas, no solamente en la ejecución de los algoritmos que forman el sistema sino que también debe tomarse en cuenta los entornos naturales y operativos de los sistemas.

CAPITULO 2 2.1. En la introducción a este capítulo, Baetjer puntualiza: “El proceso ofrece una interacción entre usuarios y diseñadores, entre usuarios y herramientas en evolución, entre diseñadores y herramientas en evolución [tecnología]”. Háganse cinco preguntas al respecto a a) lo que los diseñadores deben preguntar a los usuarios; b) los usuarios deben preguntar a los diseñadores; c) lo que los usuarios deben preguntarse a sí mismos sobre el producto de software que se construirá; y d) lo que los diseñadores deben preguntarse a sí mismos sobre el producto de software que se construirá y el proceso que se utilizará para hacerlo.

a) Lo que los diseñadores deben preguntar a los usuarios. • • •

•

•

El conocimiento informático que disponen los usuarios. Experiencias anteriores en uso de sistemas relacionados. La predisposición al cambio, aprendizaje de nuevas tecnologías y voluntad de facilitar información al analista o diseñador. El conocimiento de los procesos y la gestión a automatizar; Identificación de las áreas y procesos críticos. Si tiene conocimiento de los datos que ingresarán al sistema y los datos que espera obtener al aplicar el sistema.

b) Los usuarios deben preguntar a los diseñadores. •

• •

•

• •

El tipo y tiempo capacitación, aprendizaje e implementación del sistema. La forma de soporte y mantenimiento a recibir posterior a la instalación. Conocimiento previo del área en cuestión. Que tan adaptable a nuevas políticas internas y externas, cambios tecnológicos será el sistema (parámetros, configuraciones y flexibilidad). Que tan factible es introducir un cambio luego de que se ha empezado a desarrollar el proyecto.  Tecnología (software y hardware) a implementar. Metodología de investigación y modelo de desarrollo a usar.

c) Lo que los usuarios deben preguntarse a sí mismos sobre el   producto de software que se construirá. •

•

Disponibilidad de tiempo y predisposición al esfuerzo en asimilar un nuevo proyecto. Capacidad de interactuar con el investigador.

•

•

•

 Tengo el conocimiento y la experiencia necesaria para aportar positivamente en el proyecto. Luego de haber interactuado con el nuevo producto seré capaz de heredarlo a otro usuario sin mayor esfuerzo. Que beneficios en tiempo de proceso, reportes, comunicación, almacenamiento, tendrá el nuevo software a construir.

d) Lo que los diseñadores deben preguntarse a si mismos sobre el   producto de software que se construirá y el proceso que se utilizará  para hacerlo. • • •

•

•

Estoy utilizando un modelo adecuado a la necesidad del nuevo proyecto. Conozco al máximo las herramientas y los recursos disponibles.  Tengo la información necesaria para el desarrollo del producto de software que se construirá. Estoy en la capacidad (experiencia y conocimientos) de realizar este proyecto o cuento con el personal adecuado para realizarlo. Satisface las necesidades, requerimientos y alcances del nuevo proyecto al presupuesto establecido.

2.2. En la figura 2.1. se colocan los tres estratos de ingeniería del software arriba de un estrato titulado “un enfoque en la calidad”. Esto implica un programa de calidad de una organización amplia como gestión de la calidad total. Realizar una pequeña investigación y desarrollar una guía de los principios clave de un programa de gestión de calidad total.

a) Consecución de la plena satisfacción de las necesidades y expectativas del usuario (interno y externo).  b) Desarrollo de un proceso de mejora continua en todas las actividades y procesos llevados a cabo en el desarrollo de software (implantar la mejora continua tiene un principio pero no un fin). c)  Total compromiso de la Dirección y un liderazgo activo de todo el equipo directivo. d) Participación de todos los miembros del grupo de desarrollo y fomento del trabajo en equipo hacia una Gestión de Calidad Total. e) Involucración del cliente en el sistema de Calidad Total de grupo de desarrollo, dado el fundamental papel de éste en la consecución de la Calidad en el producto final (software). f) Identificación y Gestión de los Procesos Clave de la organización, superando las barreras departamentales y estructurales que esconden dichos procesos. g) Toma de decisiones de gestión basada en datos y hechos objetivos sobre gestión basada en la intuición. Dominio del manejo de la información.

2.3. ¿Existe la posibilidad de que las actividades genéricas del proceso de ingeniería del software no se apliquen? Si es así, descríbase.

No existe la posibilidad de omitir actividades genéricas ya que son útiles tanto para pequeños sistemas como para grandes proyectos de software. Las actividades genéricas: Comunicación, Planeación, Modelado, Construcción y Despliegue. Estas cinco actividades genéricas son útiles durante el desarrollo de programas pequeños, grandes aplicaciones en red, y en la ingeniería de sistemas basados en computadoras grandes y complejas. Los detalles del proceso del software serán muy diferentes en cada caso, pero las actividades dentro del marco permanecerán iguales. 2.4. Las actividades de sombrilla ocurren a lo largo de todo el proceso del software. ¿Se aplican de modo uniforme a través del proceso o algunas están concentradas en una o más actividades del marco de trabajo?

Se aplican a lo largo del proceso de software, y no se pueden aplicar de manera uniforme a lo largo de todo el proceso del software. Las actividades sombrilla son actividades conjuntas (asociadas) al resto de actividades genéricas, para asegurar que el proyecto cumpla con las metas establecidas en cada uno de los pasos. Aunque cada actividad de sombrilla es diferente, y depende de la actividad genérica a la que esté asociada, el esfuerzo ó trabajo necesario para aplicarlo es distinto al momento de evaluar cada situación. Sin embargo las actividades sombrilla de forma global se aplican de manera igual en todo el proceso del software.

2.5. Descríbase un marco de trabajo del proceso con palabras propias. Cuando se dice que las actividades del marco de trabajo son aplicables a todos los proyectos, ¿esto significa que las mismas tareas de trabajo se aplican a todos los proyectos, sin importar el tamaño y la complejidad? Explíquese la respuesta.

Un marco de trabajo en términos simplificados puede ser un mapa o plantilla a seguir en el que constan actividades útiles para el equipo de desarrollo. Las actividades genéricas: Comunicación, Planeación, Modelado, Construcción y Despliegue. Las actividades sombrilla: Seguimiento y control del proyecto de software, Gestión del riesgo, Aseguramiento de la calidad del software, Revisiones

técnicas formales, Medición, Gestión de configuración del software, Gestión de la reutilización, Preparación y producción del producto de trabajo. Estas cinco actividades genéricas junto con las actividades sombrilla son útiles durante el desarrollo de programas pequeños, grandes aplicaciones en red, y en la ingeniería de sistemas basados en computadoras grandes y complejas. Los detalles del proceso del software serán muy diferentes en cada caso, pero las actividades dentro del marco permanecerán iguales. Por lo tanto podemos decir que las mismas tareas de trabajo se pueden aplicar a todos los proyectos, sin importar el tamaño y la complejidad.

2.6. Intente establecer un conjunto de tareas para la actividad de comunicación.

a) presentación b) entrevistas previas c) definición de requerimientos d) elaboración de cuestionarios e) elaboración de encuestas f) entrevistas formales g) desarrollo de informes h) documentación de tareas realizadas i) seguimiento 2.7. Investigar un poco más acerca de la IMCM y discutir las ventajas y desventajas de los modelos IMCM continuo y discreto .

MODELO CMMI DISCRETO

VENTAJAS •

•

•

•

CMMI CONTINUO

•

Estrategia Incorporada Las áreas de proceso se basan en si mismas Mejores beneficios a largo plazo La mayor parte de los problemas de calidad son planeados de esa forma Las áreas de proceso seleccionadas

DESVENTAJAS •

•

•

•

•

•

Mayor inversión al inicio. Los resultados que se pueden medir, pueden tomar más tiempo. Puede ser mas dificil de convencer a la alta gerencia Puede ser mas dificil de implementar Las evaluaciones son mas caras Los problemas sistemáticos de

•

•

pueden cumplir con los objetivos de negocio directamente Se pueden conseguir resultados más rápido Se requiere una inversión inicial menor

•

•

•

calidad pueden no ser tomados en cuenta Puede que no se tengan beneficios a largo plazo Falta de estrategia incorporada Se puede implementar los procesos en el orden equivocado

2.8. Desplegar la documentación de la IMCM del sitio de la red del SEI y seleccionar un área del proceso que no sea la planeación del proyecto. Hacer una lista de las metas específicas (ME) y de las prácticas específicas (PE) asociadas que se definan mediante el área de trabajo que se haya elegido. AREA DE TRABAJO: Medición y Análisis

Meta Específica Prácticas Específicas SG1 Alinear las Actividades de Medición y Análisis Los objetivos y actividades de medición están alineados con las metas y necesidades de información identificadas. SP1.1 Establecer objetivos de medición SP1.2 Especificar mediciones SP1.3 Especificar procedimientos de recogida y almacenamiento de datos SP1.4 Especificar procedimientos de análisis SG2 Proporcionar Resultados de la Medición Los resultados de las mediciones, las cuales soportan las metas y necesidades de información, son  proporcionados. SP2.1 Recolectar datos para las mediciones SP2.2 Analizar datos de las mediciones SP2.3 Almacenar datos y resultados SP2.4 Comunicar resultados

2.9. Considerar la actividad de comunicación dentro del marco de trabajo. Desarrollar un patrón completo del proceso (podría ser un

patrón discreto) aprovechando los principios descritos en la sección 2.4. Nombre del patrón. Comunicación. Propósito. Llegar a establecer e implementar comunicación entre usuarios, cliente, y todo el personal implicado dentro del desarrollo del nuevo proyecto de software, utilizando técnicas y herramientas para la obtención de información. Tipo. Tarea. Contexto inicial . Para aplicar este patrón de proceso se deben de considerar las siguientes condiciones. 1. Tener viabilidad para el desarrollo de investigación. 2. Conocer el área física de investigación. 3. Identificar los clientes. 4. tener establecidas técnicas de investigación por parte del diseñador. Problema. la comunicación es una de las fases por no decir la fase mas importante dentro del proceso de desarrollo de software, lograr obtener la información deseada conlleva muchos riesgos, y muchas de las veces la información es interpretada de una manera distinta a la que el cliente quiso expresar. También existen clientes que se niegan a facilitar información.

Solucion. Al aplicar correctamente las técnicas de investigación se logra una eficiente comunicaron e interpretación de datos facilitados por el cliente, para llegar a establecer una sólida base para los siguientes fases de desarrollo.

Además crea un ambiente de confianza entra cliente y desarrollador.

Contexto resultante. la comunicación by direccional eficiente entre cliente y desarrollador tiene como consecuencia una recopilación eficiente y confiable de información para usos como. •

• •

En base a esta información se puede determinar el modelo de proceso que se utilizara en el desarrollo del proyecto. La información se la puede trasladar a un prototipo.  Tenemos ya la mesa servida para realizar el análisis de información.

Patrones relacionados. Los siguientes son los patrones relacionados • • • •

Reunión del equipo del proyecto. construcción de prototipos. Análisis de requerimientos. Evaluación del cliente.

2.10. ¿Cuál es el propósito de la evaluación del proceso? ¿Por qué el SPICE ha sido desarrollado como un estándar para la evaluación del proceso?

El objetivo de la evaluación de proceso es llegar a tener una ingeniería de software exitosa y con esta también se puede medir la capacidad del desarrollador y del proceso para poder mejorarlo. El SPICE se lo considera un estándar por que contiene un conjunto de requisitos que satisface las necesidades de evaluación del proceso de software en las organizaciones de desarrollo.

2.11. Investigar más sobre el PSP y preparar una breve presentación que indique los beneficios cuantitativos del proceso.

Medición de tiempo de proceso. El desarrollador llega a entender de manera personal como influye la cantidad de tiempo que se demora en realizar un proceso dentro del proyecto y con esto él puede determinar las areas donde tiene que enfatizar. Los defectos que entran y salen del proceso. Cuantificar la cantidad de errores cometidos en cada proceso. Los diferentes tamaños de los productos que se producen. Medir en términos de calidad y eficiencia los diferentes productos que se llegaron a obtener luego de haber puesto en marcha el proceso. 2.12. La utilización de “escritos” (un mecanismo requerido en el PSE) no goza de gran aceptación entre la comunidad del software. Hacer una lista de las ventajas y desventajas mientras se toman en cuenta los

escritos y sugerir al menos dos situaciones en que serían útiles y otras dos situaciones en donde no tendrían tantos beneficios.

Ventajas Estructura de pasos a seguir  Áreas de trabajo perfectamente definidas Busca la calidad desde el inicio del  proyecto Para cada actividad hay un formato de trabajo predefinido Situaciones favorables

Desventajas

•

•

•

•

•

•

•

Muy estricto en los pasos a seguir  Formatos de documentación demasiado complejos Se requiere documentar cada paso y acción que se tome

Cuando hay mucha rotación de personal es beneficioso ya que los escritos ayudan mucho a absorber los efectos de capacitar un nuevo personal En el caso de desarrollar algoritmos que ejecuten algún proceso complejo es muy beneficioso documentar con escritos dichos procesos y las consecuencias de los mismos Situaciones desfavorables •

•

•

•

Excesivas reuniones de trabajo para planeamiento y coordinación de tareas a ejecutarse Nivel de detalle de control de los proceso puede resultar muy burocrático dentro del grupo de trabajo.