UNIVERSIDAD NACIONAL DE MOQUEGUA

CUESTIONARIO
DESARROLLO Y PRODUCCION DE SOFTWARE

Docente: Ing. Vaneza Flores Gutierrez

INTEGRANTES Henrry Jaime Edith Elisa

PROBLEMAS CAPITULO II 2.1. En la introduccin a este captulo Baetjer seala: ". El proceso proporciona una interaccin entre los usuarios y diseadores, entre los usuarios y las herramientas en evolucin, y entre los diseadores y las herramientas de la evolucin [la tecnologa]" enliste 5 preguntas a.- Que de beberan pedir los diseadores a los usuarios. Con que tipo de software y hardware cuenta actualmente Que reas va a abracar el sistema deseado Cuenta con un sistema actualmente Si cuenta con un presupuesto adecuado Que funcionalidades deben cumplir el sistema

b.- Que pregunta deberan hacer los usuarios a los diseadores. Qu tiempo de duracin tendr el sistema implantado Cuntova a costar el sistema Cuanto tiempo demandara en realizar el proyecto Cul es el grado de seguridad del sistema Qu tipo de equipo informtico se necesitara

c.- Los usuarios deberan preguntarse sobre el producto software que ha de elaborarse El sistema debe ser sencillo Un interfaz agradable Que el sistema sea rpido Que el sistema tenga una gua de ayuda Que el sistema sea seguro

d.- Los diseadores deberan preguntarse asimismo sobre el producto software que se va a construir y el proceso que se utilizar para su construccin. Que lenguaje de programacin se usara Que gestor de base de datos se utilizara Cada cuanto tiempo se realizaran las pruebas del software a implantar Que plan de contingencia se tendr en caso que falle el sistema Qu tipo de metodologa se utilizara para el proyecto de desarrollo de software

2,2. Trate de desarrollar un conjunto de acciones para la actividad de comunicacin. Seleccione una accin y definir un conjunto de tareas para ello. Accin recabar requerimientos Tareas: Elaborar la lista de participantes del proyecto. Invitar a todos los participantes a una reunin. Pedir a cada participante que haga una relacin de las caractersticas que requiere. Analizar los requerimientos y construir la lista definitiva. Ordenar sus requerimientos y su funcionalidad. Identificar las reas de incertidumbre.

2,3. Un problema comn durante la comunicacin se produce cuando se encuentra con dos actores que tienen ideas contradictorias sobre lo que el software debe ser. Es decir, usted tiene requerimientos mutuamente antagnicos. Desarrollar un proceso de patrones (esto sera un patrn de etapa) con la plantilla presentada en la seccin 2.1.3 que soluciona este problema y sugerir un enfoque eficaz para ello. Nombre de patrn: Establecer Planeacin Intencin: consiste en describir las tareas tcnicas por realizar, los riesgos probables, los recursos que se requieren, los productos del trabajo que se obtendrn y una programacin de las actividades. Tipo: Patrn de etapa Contexto de inicial: Antes de iniciar este patrn deben cumplirse las siguientes condiciones: 1. 2. 3. Los clientes y los ingenieros de software hayan establecido una comunicacin colaboradora. Haya terminado con xito cierto nmero de patrones de tarea para el padrn de comunicacin. Se conozcan el alcance del proyecto, los requerimientos bsicos del negocio y las restricciones del proyecto.

Problema: elaboracin de la arquitectura del sistema poco clara. Los integrantes no estn seguros de la planeacin para el desarrollo del software. Solucin: Que todos los integrantes estn de acuerdo sobre la arquitectura que se va a seguir para la planeacin del proyecto siguiendo experiencias anteriores se tomara la decisin. Contexto resultante: los participantes aprueban la elaboracin del plan a llevarse a cabo. Patrones relacionados: Patrn de etapa de comunicacin. Patrones de tareas plan de desarrollo del proyecto, descripcin de la arquitectura, programacin de actividades, recursos que se requieren. 2.4. Hacer una investigacin sobre PSP y presentar una breve presentacin que describe los tipos de mediciones que se le pide que haga a un ingeniero individual de software y de cmo las mediciones se puede utilizar para mejorar la efectividad personal. El PSP es un mejoramiento en s de los procesos y fue diseado para ayudar a los ingenieros a controlar, administrar y mejorar su manera de trabajar. Es una estructura con un marco referencial, directrices y procedimientos para el desarrollo de software. El PSP proporciona datos histricos para realizar mejor su trabajo de acuerdo a los compromisos establecidos, y hace que los elementos rutinarios de su trabajo sean ms previsibles y ms eficaces. Adems proporciona mtodos detallados de planificacin y estimacin, muestra a los ingenieros cmo controlar su rendimiento frente a esos planes y explica cmo los procesos definidos guan su trabajo. Est alineado y diseado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504

Muchas compaas actualmente, utilizan CMMI para medir sus esfuerzos de mejora de sus procesos y en lugar de describir una organizac in como Buena o excelente para desarrollar software, se puede ser ms concreto y establecer que la organizacin se encuentra en nivel 3 CMMI. CMMI clasifica a las organizaciones en uno de los cinco niveles siguientes:

Nivel 1: Inicial Nivel 2: Repetible Nivel 3: Definido Nivel 4: Administrado Nivel 5: Optimizado Tabla 1: Niveles de Mejoramiento PSP Nivel Nombre PSP0 Medicin personal PSP0.1 Registro de defectos

PSP1

Planeamiento personal

PSP2 PSP3

Gerenciamiento de la actividad personal Procesos personal cclico

Actividad Registro de tiempo Registro de efectos Patrn de tipos de defectos Patrn de codificacin Medida de tamao Propuesta de mejoramiento de procesos Estimacin de tamao Informe de pruebas Planeamiento de tareas Cronogramas Revisin de cdigo Revisiones de proyecto Patrones de proyecto Desarrollo cclico

El PSP muestra cmo producir de forma regular software de alta calidad. Utilizando el PSP se obtienen datos que muestran la efectividad del trabajo y se identifican los puntos fuertes y las debilidades, adems se practican habilidades y mtodos que ingenieros del software van a desarrollar durante muchos aos de pruebas y errores. El PSP muestra cmo producir de forma regular software de alta calidad. Utilizando el PSP se obtienen datos que muestran la efectividad del trabajo y se identifican los puntos fuertes y las debilidades, adems se practican habilidades y mtodos que ingenieros del software van a desarrollar durante muchos aos de pruebas y errores. 2,5. El uso de "scripts" (un mecanismo necesario en TSP) no es universalmente elogiado dentro de la comunidad del software. Haga una lista de pros y los contras con respecto a las secuencias de comandos (scripts) y sugieren al menos dos situaciones en las que podran ser tiles y otras dos situaciones en las que podran ofrecer menos beneficios. Los escritos (scripts) definen actividades especficas del proceso (por ejemplo lanzamiento, diseo, implementacin, integracin y prueba de unidad) que son parte del proceso del equipo. Los scripts son el punto medular de PSP, por lo que se hace mucho nfasis en que deben ser seguidos en forma disciplinada, ya que de ello depender el xito de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generar en su realizacin un conjunto de datos, fundamentalmente de carcter estadstico En los scripts de PSP no se incluyen tareas y actividades para la etapa de anlisis de requerimientos. Siempre se parte de una definicin de requerimientos que no va a cambiar.

Script general Revisar los objetivos del proyecto con las de gestin, acordar, y documentar las metas del equipo. Establecer las funciones del equipo. Definir el proceso de desarrollo del equipo. Elaborar un plan de calidad y plantear los objetivos de calidad. Preparar un plan para las necesidades de soporte necesarias. Producir una estrategia de desarrollo general Elaborar un plan de desarrollo para el proyecto en su totalidad. Hacer planes detallados para cada ingeniero en la siguiente fase. Adaptar los planes individuales a un plan de equipo. Hacer un balance de la cantidad de trabajo para obtener un programa mnimo en trminos generales. Valorar los riesgos del proyecto y asignar responsabilidad de rastreo para cada riesgo clave. Ventajas: Brinda ayuda a los diseadores, mediante una gua bien estructurada, para la realizacin de cada etapa del proceso de software 2,6. Leer [Nog00] y escribir un documento de dos o tres pginas que discute el impacto de "caos" en la ingeniera de software. Resumen Este artculo discute los problemas de la ingeniera de software como el eslabn ms dbil en el desarrollo de sistemas capaces de conseguir la superioridad de informacin. Los cambios rpidos en la tecnologa de introducir dificultades adicionales en trminos de planificacin estratgica, estructura organizacional, y la ingeniera de proyectos de desarrollo de software. En el entorno tan complejo, una nueva forma de pensar se requiere. Se analiza la introduccin de los sistemas adaptativos complejos como una alternativa para la planificacin y el cambio. La estrategia de "competir en el borde", se analiza la muestra de los riesgos y las habilidades que se requieren navegar en el borde. Se discute la viabilidad de utilizar esta teora en ingeniera de software como una alternativa a los procesos burocrticos de desarrollo de software. Se presentan tambin algunas recomendaciones que podran ayudar a adquirir una ventaja competitiva en el desarrollo de software, por lo tanto, lograr la superioridad de la informacin. 2,7. Proporcione tres ejemplos de proyectos de software que podran efectuarse con el modelo en cascada. Sea especfico. El modelo en cascada es adecuada para proyectas con las siguientes caractersticas El problema es bien entendido (los requisitos estn bien definidos) La fecha de entrega es realista Es probable que los grandes cambios en los requisitos se le pedir medida que avanza el proyecto. Ejemplos: Una modificacin a un programa existente Implementacin directa de un clculo numrico Una mejora limitada a un programa existente Una adaptacin a un software contable debido a los cambios en las regulaciones del gobierno 2,8. Proporcione tres ejemplos de proyectos de software que podran ser susceptibles a la modelo de prototipo. Sea especfico.

El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.

EJEMPLO 1 Las empresas dedicadas a la compraventa de productos de primera necesidad (como pueden ser supermercados o tiendas de ropa) no necesitan complejos sistemas informticos que lleven la contabilidad, o que visualicen de forma rpida en pantalla la relacin unidades, precio unidad, total. La creacin de prototipos ayuda a que nuestro cliente imagine su propio software tal y como si l estuviera elaborndolo. EJEMPLO 2 La configuracin de la interfaz con el usuario y el formato de los despliegues de salida El diseo rpido conducen a la construccin de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. EJEMPLO 3 Las compaas de ofrecen servicios de carteleras u horarios de pelculas necesitan tener una interfaz muy llamativa y cuando van a adquirirla necesitan hacer una rpida construccin de un prototipo el cual se va a evaluacin del usuario para aclarar dudas y dar a conocer sus ideas sobre l. 2,9. Qu adaptaciones del proceso se requiere si el prototipo se convierta en un sistema de entrega SQA es un set de actividades sistemticas que aseguran que el proceso del software y productos conformados por requerimientos, estndares, y procedimientos. Los procesos incluyen todas las actividades involucradas en el diseo, codificacin, pruebas y mantenimiento; Los productos incluyen software, datos asociados, documentacin, y toda la documentacin para soporte y reportes y/o producto? Reglas de diseo ms rigurosos y procedimientos de SQA debe aplicarse desde el principio El prototipo debe ser diseado pensando en la extensibilidad y se ejecutar mediante un entorno de programacin que se presta al desarrollo del sistema de produccin El prototipo es inicialmente un mecanismo para identificar las necesidades, y luego se convierte en el marco de las extensiones que har que se convierta en un sistema de produccin 2. I0. Proporcione tres ejemplos de proyectos de software que podran ser susceptibles a la modelo incremental. Sea especfico. Un sistema operativo. Las diversas partes del SO podra ser desarrollado como el cliente los quiere. Por ejemplo, el cliente que desee especificar la primera interfaz grfica de usuario, y probarlo antes de proporcionar especificaciones adicionales para las partes restantes del SO. La GUI podra

entonces ser desarrollado; una vez que el usuario autorizado, algunas de las funciones ms importantes de la porcin de capa de abstraccin de hardware se podra aadir. El proceso podra continuar hasta que todo el sistema es completo, con los clientes obtener actualizaciones continuas para probar y aprobar. Una aplicacin del navegador de Internet. La aplicacin de base podra ser desarrollada y distribuida, seguida por cualquiera de una serie de plug-ins para aumentar la funcionalidad. Los plug-ins pueden incluir la interpretacin de JavaScript, el anlisis de XML, y as sucesivamente. La mayora de los navegadores disponibles podran seguir este modelo. La telemetra satelital y el software de control. Hay un nmero de piezas a un sistema de esta naturaleza, todos los cuales pueden ser desarrollados (bsicamente) de forma independiente, y despus se integra ms tarde. El cliente puede (de nuevo) hacerse cargo de las partes del sistema, tales como la telemetra decommutator, codificador de mando, y archivador de la historia de la telemetra. 2.11. Como avanza hacia afuera por el flujo de proceso en espiral qu puedes decir acerca del software que est desarrollando o mantenido? En primer lugar, en cada nivel de la espiral del software real que representa la solucin es considerablemente ms compleja. Sin embargo, puede haber un perifrico o requerimiento de software que sea importante en cada fase, el software para el modelado y el anlisis que puede ser muy compleja. En segundo lugar, la mayor parte del software en las ltimas fases debera ser ms fiable, mejor documentado y probado ms a fondo. Esto puede incluso hasta el punto en que la nueva versin del software este diseado y desarrollado especficamente para mejorar o para solicitar una nueva versin y no "reemplazar" el software ya existentes. En tercer lugar, en las fases ltimas de espiral, algunos de los programas iniciales pueden ya no existir, puede haber sido abandonada, o haya dejado de ser aplicable al producto, ya que no se ha mantenido. 2,12. Es posible combinar los modelos de procesos? Si es as, proporcionar un ejemplo Si, se pueden combinar modelos de procesos, en sistemas grandes donde se hace primero un prototipo al principio de software para aclarar primero las dudas acercas de las necesidades del cliente, y luego cuando se quiera volver a implementar se puede rehacer su implementacin ms ordenada y especficamente ya de las partes ms comprendidas del sistema, se puede desarrollar y especificar utilizando un proceso basado en el modelo en cascada y siempre dejar las otras partes como la interfaz del usuario, como un modelo evolutivo en el cual poco a poco se va explorando hasta llegar a donde se quiere. 2,13. El modelo de proceso concurrente define un conjunto de "estados". Describa lo que estos estados representan en sus propias palabras, a continuacin, indican la forma en que entran en juego en el modelo de proceso concurrente. En pocas palabras, el modelo de proceso concurrente asume que diferentes partes de un proyecto ser de las diferentes etapas de la integridad, y por lo tanto, las diferentes actividades de ingeniera de software estn llevando a cabo al mismo tiempo. El desafo consiste en gestionar la concurrencia y ser capaz de evaluar el estado del proyecto. Las etapas incluyen el subdesarrollo inactivo, en espera de cambios, que se examina, en proceso de revisin, lnea base, hecho. Estos estados representan las diferentes etapas de la terminacin del proyecto de desarrollo de software, y se llevan a cabo al mismo tiempo. Se proporciona una situacin precisa del estado actual del proyecto de desarrollo de software.

2.14. Cules son las ventajas y desventajas de desarrollar software en el que la calidad es "suficientemente bueno"? Es decir, lo que sucede cuando hacemos hincapi en la velocidad de desarrollo sobre la calidad del producto? Ventajas Mejorar las habilidades de liderazgo y la gestin por el desarrollo personal mayor. Crea un ambiente consciente de la calidad. Funcionar como un ncleo de control de calidad en toda la compaa a nivel de taller. Aumenta la moral de los empleados y el sentido de objetivo comn. Los empleados deben estar bien educados y tienen una buena comprensin de la organizacin ms all del rea de trabajo propia. Los crculos de calidad rentable. Libera tienda de la gestin de los trabajadores de planta mejor situados para identificar los problemas.

Desventajas La intensidad del trabajo aumenta, a medida que ms problemas se resuelven ms se espera de los trabajadores. Puede ser introducido es decir, las razones incorrectas. cambio de actitud. La administracin debe estar totalmente comprometido con la calidad de los sistemas, si no se implementan las soluciones puede ser frustrante para los participantes. Puede tener un efecto negativo sobre las relaciones laborales. Puede centrarse en los problemas mundanos. Las ventajas de desarrollo de software en el que la calidad es "suficientemente bueno" es que el producto o el software cumpla con el plazo, sin embargo, puede dar lugar a la entrega de software que es de baja calidad y necesita tiempo para la calidad inadecuada. Cuando la velocidad se hace ms hincapi en la calidad del producto puede llevar a muchas fallas, el software puede requerir ms pruebas, diseo y trabajo de implementacin a continuacin, hacer. Los requisitos pueden ser mal definidos y puede tener que cambiar continuamente. La mitad de corazn y de la velocidad puede hacer que la gestin del riesgo de no detectar los principales riesgos del proyecto. Muy poca calidad puede dar lugar a problemas de calidad y las revisiones ms tarde. 2,15. Proporcione tres ejemplos de proyectos de software que podran ser susceptibles al modelo basado en componentes. Sea especfico. Una aplicacin de PDA inalmbrico en Java. Esto puede incluir cualquier nmero de aplicaciones de datos posibles, tales como libreta de direcciones, lista de tareas, calendario de reuniones, lista de telfonos, y muchos ms. Los componentes estn disponibles para realizar estas funciones, de manera que la aplicacin se desarroll utilizando ellos. El equipo de desarrollo podra centrarse en todas las partes de forma independiente, control de cada parte COTS de forma individual antes de su integracin con todo el sistema. Estas piezas pueden ser intercambiadas dentro y fuera segn sea necesario, en base a los resultados del proceso de pruebas de integracin. Un ordenador distribuido controlador para el control industrial en una fbrica. Todas las mquinas podran tener sus propios sistemas en tiempo real basados en computadoras, que estn conectados en red. La red podra permitir el control al pasar a una "seal de control", tanto como en un "token ring" de la red. Firmware Cada mquina controlador individual sera un componente en el sistema.

Una orientada a objetos de eventos del sistema de manejo (como en Java). Los componentes se incluyen los objetos necesarios que tienen comportamientos para manejar los diferentes tipos de eventos que la mquina virtual puede producir. Un tiempo real traductor de idiomas. El traductor podra tener componentes para varios idiomas, e incluso podra incluir un diccionario de sinnimos y / o un diccionario de frases para cualquiera o todos los componentes del lenguaje.

2,16. Es posible demostrar que un componente de software, e incluso todo el programa es correcto. As que, por qu no todo el mundo hace esto? Una de las razones que la mayora de los esfuerzos de desarrollo no incluyen software de prueba de la correccin es que en la actualidad, no existe ningn producto de software disponible en el mercado para probar la exactitud del software genrico. Este proceso por lo tanto sera necesario que el equipo de desarrollo de software genere su propia prueba, una tarea para la cual es muy poco probable que un cliente estara dispuesto a pagar. Una excepcin a esto es la verificacin del compilador, para el desarrollo de aplicaciones del software. Un obstculo adicional es que las pruebas para verificar la correccin incluso de programas informticos especficos son muy difciles de desarrollar. Los enfoques habituales requieren descomponer el software en cualquiera de los modelos matemticos o de orientacin grfica. 2.17 - Son lo mismo el proceso unificado y UML? Explique su respuesta. No porque: UML es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. RUP es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. UML es una herramienta del RUP. UML es un lenguaje de modelado estndar, no un proceso de desarrollo de software