domingo, 23 de octubre de 2011

Sobre Diseño y desarrollo de Software

1. ¿Qué relación hay entre Correctitud, Confiabilidad (Reliability) y Robustez?.

R/: Estos son factores importantes en la Ingeniera del Software a la hora de realizar un producto de Alta calidad, teniendo estos podremos presentar un producto de mayor calidad a la vez que podremos medir y comparar con otros semejantes.

2. Clasifique los siguientes factores de calidad como internos, externos, del producto y del proceso: Correctitud, Confiabilidad, Robustez, Mantenibilidad, Portabilidad, Interoperabilidad, Visibilidad.

R/: Interno: Correctitud, confiabilidad.

Externos: Robustez, portabilidad, interoperabilidad, mantenibilidad, visibilidad.

3. Discuta la importancia relativa de las cualidades "robustez", "amigabilidad de la interfaz con el usuario", "desempeño" para cada una de las áreas de aplicación siguientes:

a) juego: En un juego los factores más importantes los cuales debemos tener en cuenta son Robustez, y un buen desempeño ya que una aplicación de juegos requiere en su gran mayoría una maquina con unos recursos físicos grandes (memoria ram, tarjeta de video, etc.) y también requiere un procesador de altas características.

b) cajero automático: Fundamentalmente un software que controle un cajero automático requiere las tres características mencionadas, porque si en caso de un error en el sistema, por ejemplo a la hora de una transacción en línea o retiro de dinero sería algo demasiado grave ya que el perjudicado podría ser el usuario o la entidad prestadora del servicio, por lo que el software debe funcionar de la mejor forma posible además de presentar de forma intuitiva y fácil al usuario la representación como se puede utilizar este producto. También hay que tener en cuenta el tráfico de usuarios que acceden a sistema por lo que también tiene que ser robusto, esto significa que su carga crezca sin que el software se cuelgue.

c) facturación de una empresa de distribución de electricidad: la cualidad más importante sería el desempeño a la hora de generar reportes los fines de mes ya que sería catastrófico un error como por ejemplo en el estrato o en el registro del contador Y el numero de empleado realizando peticiones al servidor genera un alto uso de la banda ancha y un bajo consumo del rendimiento del PC, para esto el ingeniero de software debe haber ya planificado y creado un producto robusto que se comprometa a realizar los objetivos que se plantearon a la hora de que la empresa compro el producto. La parte de la interfaz amigable seria lo de menos ya que una empresa tan grande como la del sector de electricidad antes le explica al usuario como usarlo.

4. Explique la diferencia entre error, falta y falla. Dé ejemplos de errores que dan origen respectivamente a una falta en los requerimientos, el diseño, el código. Dé ejemplos de:

R/: error es UNA falla en el sistema que no se tenía prevista o que sucede inesperadamente, y una falla es la falta de algún proceso, mecanismo o cosa que permita el correcto funcionamiento del sistema o software, pero que se puede sobrellevar o corregir La falta es la ausencia de algún objeto, que causa una falla.

a) una falta en los requerimientos que da origen a una falla:
un ejemplo en este caso seria, la incorrecta planeación de requerimientos en hardware, en un software que requiriera un alto consumo de recursos, lo que generaría un error general en el funcionamiento del producto.

b) una falta en el diseño que origina una falla:
La inadecuada planeación en el sistema: la formulación, y recolección de los datos en un software que reciba una gran afluencia de ellos, causaría el desbordamiento del programa y posterior bloqueo.

c) una falta en los datos de prueba que origina una falla.
En este caso podría ocurrir que un sistema de software de digitaciones por razones de confiabilidad u simple falta de tiempo, no probara un modulo de búsqueda según una determinada información, no funcionase bien y por consiguiente no cumpliese a cabalidad con todo lo planeado, este es un error que se pudiese resolver con una adecuada revisión antes de poner a producción

5. ¿Por qué la cuenta de faltas identificadas durante el desarrollo de un producto de software puede resultar un indicador inadecuado de la calidad de un producto?

R/: porque a la hora de entregar un producto software hay que tener claro paso por paso los factores para realizar un buen software, y en la ingeniera del software si no hay claro esto, hay que comenzar a realizar de nuevo nuestro producto, muchas veces las limitaciones en la confiabilidad generan graves fallas ya que pensamos que este se encuentra en perfecto funcionamiento y no procuramos realizar un buen chequeo de una buena funcionalidad del producto.

6. Muchas organizaciones compran software comercial (COTS – Commercial Off The Shelf) pensando que es más barato que desarrollar y mantener software en casa. Describa las ventajas y desventajas de utilizar COTS. Por ejemplo ¿qué pasa si el vendedor nos brinda más soporte de un producto COTS? ¿Qué deben anticipar el cliente, usuario y desarrollador al diseñar un sistema importante que incluye COTS?

R/: Al evaluar un software COTS vs Un software privativo diseñado por y para una empresa especifica, tiene unas ventajas y desventajas como son:
Un software COTS es mucho mas barato dependiendo el caso o en la mayoría de veces que mandarlo a desarrollar específicamente, ya que hay factores, que influyen en la finalización terminación y correcto funcionamiento, entre mas tiempo se demore el software mas costoso se hace.

Un software COTS al ser mas general, y desarrollado organizadamente por una empresa es mas confiable, robusto y eficaz, ya que los bug o errores se conocen directamente y son solucionados mas rápidamente, y por consiguiente el soporte técnico es mucho más eficaz, solucionando los problemas.

Como desventajas tenemos:
Al no poseer el código fuente, no se pueden hacer modificaciones posteriores por parte del el usuario, acarreando gastos adicionales con software que suplan estas falencias.
Dependencia en los cambios y modificaciones, por lo que genera monopolios en la tecnología.
Comparado con el software libre el COST , este genera unos costos enormes por las licencias de estos software

7. ¿Cuáles son las implicancias legales y éticas de utilizar software COTS? ¿Y de que la organización encargada del desarrollo subcontrate parte de este? Por ejemplo ¿quién es responsable por corregir el problema cuando el sistema del que forma parte un COTS falla debido a una falla en ese componente? ¿Quién es el responsable cuando esa falla causa daño a usuarios (tanto directo como indirecto)?. ¿Qué controles y evaluaciones se precisan para asegurar la calidad de un COTS antes de integrarlo en un sistema mayor?

R/: Implicaciones Legales y Éticas: posee una licencia, la cual acompaña al producto y que básicamente dice que se te otorga el derecho de usar el software que estás pagando, más no lo posees. No puedes hacerle modificaciones, redistribuirlo ni nada similar.

Responsable para corregir el problema cuando el sistema falla: Directamente la empresa u organización que vendió el software es la encargada de responderle al usuario por una mejora en una falla, por eso el usuario paga una licencia para recibir actualizaciones que producen mejoras durante un tiempo determinado, dependiendo del contrato.

Controles y Evaluaciones para asegurar la calidad de un software Cost: en el caso de Microsoft una empresa famosa por su sistema operativo Windows, constantemente está realizando parches o actualizaciones para mejorar el sistema de errores o fallos de seguridad.

1. ¿Cuáles son las ventajas y desventajas de la utilizar cada uno de los modelos de ciclo de vida siguientes:

Cascada

Ventajas:

Se tiene todo bien organizado y no se mezclan las fases.

Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar

Desventajas: En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.

El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera.

Cascada con Prototipación

Ventajas: Entre las ventajas tenemos la organización que da el modelo en cascada combinando aun mas con los diferentes prototipos, lo que hace que en la fase de prueba se diciminulan los riegos de un error. Además reducciones en la incertidumbre y del riesgo, reducción del tiempo y de costos e incremento en la aceptación del sistema

Desventajas: al participar prototipos en la creación de software, el usuario puede llegar a pensar que este es el programa terminado, y llevarse una desilusión si este no funciona adecuadamente, necesita una participación mas directa y continua del usuario

Prototipación

Existen ventajas relevantes en el uso del Prototipo:

* Modificación del Sistema en Etapas tempranas de su desarrollo: El éxito del uso del prototipo depende de qué tan pronto y con que frecuencia se reciba la retroalimentación del usuario para hacer cambios y adecuarlos a las necesidades actuales. Los cambios iniciales durante el desarrollo de un proyecto son menos costosos que si se realizan en etapas tardías, como el prototipo puede cambiar varias veces la flexibilidad y adaptabilidad son su esencia, la pauta del cambio la da la retroalimentación, la cual nos permite conocer la opinión del usuario sobre cambios a la entrada o salida de un proceso, que al evaluarla nos permite obtener los requerimientos y mejorar el sistema.

El desarrollo de prototipos implica una inversión en tiempo y en dinero, siempre pero siempre es menor a la del sistema completo. Los problemas y descuidos de sistemas son más fáciles de detectar en un prototipo.

* Eliminación de sistemas indeseables: Por permitir recopilar información nos permite eliminar un sistema que no llegó a ser lo que esperaban de él los usuarios. La inversión de tiempo y dinero se destaca pero es menor que la del sistema completo. Se toma esta decisión cuando el sistema no es útil o no satisface los objetivos que se propuso el equipo de desarrollo, es una decisión difícil pero evita seguir gastando dinero y tiempo en un proyecto inservible.

* Diseño de Sistemas acorde a las necesidades y expectativas de los usuarios: El uso del prototipo hace que los sistemas se ajusten a las necesidades de los usuarios. Se reduce el intervalo de tiempo desde que se relevan los requerimientos y el sistema concluido. Permite que los usuarios se involucren desde el principio y lo hace participar en forma activa, de esta forma hacen suyo el proyecto, siendo los principales promotores del éxito.

El prototipo cuenta con las siguientes desventajas:

* Administración difícil: Dicha dificultad radica en manejar el prototipo como un proyecto dentro del Ciclo de Desarrollo de Sistema sin perder de vista cual era su propósito.
* Adoptarlo como el sistema final: Los usuarios y profesionales de sistemas pueden considerar al prototipo como el sistema final cuando aún es incompleto e inadecuado.

Espiral

Ventajas:

* El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.

* Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.

* El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.

* El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.

* En la utilización de grandes sistemas a doblado la productividad.

Desventajas:

*Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

* Es nuevo (1988) y no se ha utilizado tanto como otros modelos de ciclo de vida.

* Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.

* Requiere una gestión concienzuda, atenta y que exige conocimientos profundos.

2. Para cada uno de los modelos anteriores, ¿cómo maneja el modelo un cambio significativo y tardío en los requerimientos?

R/: Cada modelo de ciclo de vida maneja de diferente formas un cambio tardío en los requerimientos por estos algunos están mejor diseñados, para estos cambios, por ejemplo en un sistema lineal un cambio tardío en los requerimientos seria considerado como un error ,pues se debiese comenzar a plantear ese problema casi desde el principio, ya que en este modelo, es muy importante analizar y tomar en cuenta todos los requerimientos desde un principio, en cambio desde un modelo en espiral, dependiendo de una actividad que se tomo desde un principio, se puede virar mas fácil en una solución para el nuevo requerimiento.

3. Un constructor de computadoras decide desarrollar un nuevo sistema operativo para su línea de equipos para enfrentar con mejores posibilidades la competencia. ¿Cuáles considera que son los principales riesgos? ¿Qué modelo de ciclo de vida le parece más adecuado para el proyecto? ¿Por qué?


R/: Entrar a desarrollar un nuevo sistema operativo implica muchos riesgos ya que en el mercado encontramos muchos sistemas operativos de excelente calidad y posicionados, además de que entre estos, se encuentran los de código libre con licencia GNU la cual permite utilizarlo sin necesidad de pagar por ellos, haciéndolos una opción muy tentadora, lo cual implicaría que el nuevo SO tendría que ser mucho mas costoso y para llegar al nivel de funcionalidad de los actuales necesitaría mucho tiempo de desarrollo y muchos programadores a su cargo.

Es muy complicado sugerir un modelo de ciclo de vida para este software en las condiciones que se encuentra, pero según sus características el mejor ciclo de vida seria en espiral, pues este necesita mucho tiempo y esfuerzo para realizar el proyecto, pero es mas seguro a la hora de mostrar el resultado final, además de que este software necesita calidad, mas no rapidez para poder salir a competir con los demás SO.

4. ¿Cómo se relaciona la descripción de un sistema con la noción de modelos de proceso? Por ejemplo, ¿cómo decidir cuál debe ser el límite para el sistema descrito por un modelo de proceso?


R/: Dependiendo del modelo que se le aplique al sistema, ya que hay modelos que permiten seguir incrementando o desarrollando ya que trabajan por fases (versiones) mientras que los que no trabajen de esta forma no va a permitir el crecimiento del sistema, por ende solo se podrá desarrollar lo que se tiene planteado y no se podrán formular nuevos requerimientos.

6. Discuta las ventajas y desventajas que puede traer a una organización de desarrollo el adoptar un único modelo de proceso para todos sus proyectos.

R/: Según lo aprendido el adoptar un único modelo de proceso en una empresa de desarrollo para todos los proyectos no es la mejor opción ya que habrán proyectos que requieran un modelo de desarrollo especifico y otros proyectos requerirán otro es tarea de los desarrolladores elegir el modelo que mas se adapte a sus necesidades y del cual también tengan algún conocimiento ya que es esencial que los desarrolladores conozcan bien el modelo que están implementando

7. Suponga que un contrato con un cliente especifica que debe usar un proceso de desarrollo particular. ¿Cómo se debiera controlar el trabajo para fomentar el uso de ese proceso?

R/En la practica cunado se lleva a cabo un software, es muy complicado llevarse al pie de la letra de un ciclo de vida, y aun mas a veces se combinan algunos de ellos, pero para fomentar un uso especifico de un proceso de ciclo de vida es necesario mirar bien los requisitos y los planteamientos del problema, para encontrar el ciclo de vida que se ajuste bien a estos requerimientos y por consiguiente llevar un trabajo organizado y planificado por los pasos que cada uno de ellos dictan.

8. Suponga que una empresa requiere a su organización que utilice un modelo de proceso específico al contratarla para construir un sistema. Su organización construye el software utilizando los recursos, actividades y restricciones prescritos. Cuando el software se instala y pone en marcha experimenta una falla catastrófica. Cuando el cliente investiga el origen de la falla, acusa a su organización de negligencia por no haber llevado a cabo revisiones de código que hubieran permitido detectar el problema antes de poner en producción el sistema. Su organización responde que las revisiones de código no estaban en el proceso requerido. ¿Cuáles son las implicancias legales y éticas que aparecen en esta disputa?

R/: El cliente tiene el derecho de reclamar por un producto que debió realizar los objetivos requeridos, y podría poder hacer el causal de una demanda legal ya que en contrato del software estas sus funciones y por lo cual el cliente pago por tal suma, además de un bajo prestigio de la empresa que desarrollo el software.

No hay comentarios :