Desarrollo y Produccion de Software

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 introducción a este capítulo Baetjer señala: ". El proceso proporciona una interacción entre los usuarios y diseñadores, entre los usuarios y las herramientas en evolución, y entre los diseñadores y las herramientas de la evolución [la tecnología]" enliste 5 preguntas a.- Que de beberían pedir los diseñadores 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 deberían hacer los usuarios a los diseñadores.     

Qué tiempo de duración tendrá el sistema implantado Cuántova a costar el sistema Cuanto tiempo demandara en realizar el proyecto Cuál es el grado de seguridad del sistema Qué tipo de equipo informático se necesitara

c.- Los usuarios deberían preguntarse sobre el producto software que ha de elaborarse     

El sistema debe ser sencillo Un interfaz agradable Que el sistema sea rápido Que el sistema tenga una guía de ayuda Que el sistema sea seguro

d.- Los diseñadores deberían preguntarse asimismo sobre el producto software que se va a construir y el proceso que se utilizará para su construcción.     

Que lenguaje de programación 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 metodología se utilizara para el proyecto de desarrollo de software

2,2. Trate de desarrollar un conjunto de acciones para la actividad de comunicación. Seleccione una acción y definir un conjunto de tareas para ello. Acción recabar requerimientos Tareas:      

Elaborar la lista de participantes del proyecto. Invitar a todos los participantes a una reunión. Pedir a cada participante que haga una relación de las características 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 común durante la comunicación 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 antagónicos. Desarrollar un proceso de patrones (esto sería un patrón de etapa) con la plantilla presentada en la sección 2.1.3 que soluciona este problema y sugerir un enfoque eficaz para ello. Nombre de patrón: Establecer Planeación Intención: consiste en describir las tareas técnicas por realizar, los riesgos probables, los recursos que se requieren, los productos del trabajo que se obtendrán y una programación de las actividades. Tipo: Patrón de etapa Contexto de inicial: Antes de iniciar este patrón deben cumplirse las siguientes condiciones: 1. 2. 3.

Los clientes y los ingenieros de software hayan establecido una comunicación colaboradora. Haya terminado con éxito cierto número de patrones de tarea para el padrón de comunicación. Se conozcan el alcance del proyecto, los requerimientos básicos del negocio y las restricciones del proyecto.

Problema: elaboración de la arquitectura del sistema poco clara. Los integrantes no están seguros de la planeación para el desarrollo del software. Solución: Que todos los integrantes estén de acuerdo sobre la arquitectura que se va a seguir para la planeación del proyecto siguiendo experiencias anteriores se tomara la decisión. Contexto resultante: los participantes aprueban la elaboración del plan a llevarse a cabo. Patrones relacionados: Patrón de etapa de comunicación. Patrones de tareas plan de desarrollo del proyecto, descripción de la arquitectura, programación de actividades, recursos que se requieren. 2.4. Hacer una investigación sobre PSP y presentar una breve presentación que describe los tipos de mediciones que se le pide que haga a un ingeniero individual de software y de cómo las mediciones se puede utilizar para mejorar la efectividad personal. El PSP es un mejoramiento en sí de los procesos y fue diseñado 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 históricos para realizar mejor su trabajo de acuerdo a los compromisos establecidos, y hace que los elementos rutinarios de su trabajo sean más previsibles y más eficaces. Además proporciona métodos detallados de planificación y estimación, muestra a los ingenieros cómo controlar su rendimiento frente a esos planes y explica cómo los procesos definidos guían su trabajo. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504

Muchas compañías actualmente, utilizan CMMI para medir sus esfuerzos de mejora de sus procesos y en lugar de describir una organización como “Buena” o “excelente” para desarrollar software, se puede ser más concreto y establecer que la organización 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 Medición personal PSP0.1

Registro de defectos

PSP1

Planeamiento personal

PSP2

Gerenciamiento de la actividad personal

PSP3

Procesos personal cíclico

Actividad Registro de tiempo Registro de efectos Patrón de tipos de defectos Patrón de codificación Medida de tamaño Propuesta de mejoramiento de procesos Estimación de tamaño Informe de pruebas Planeamiento de tareas Cronogramas Revisión de código Revisiones de proyecto Patrones de proyecto Desarrollo cíclico

El PSP muestra cómo 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, además se practican habilidades y métodos que ingenieros del software van a desarrollar durante muchos años de pruebas y errores. El PSP muestra cómo 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, además se practican habilidades y métodos que ingenieros del software van a desarrollar durante muchos años 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 podrían ser útiles y otras dos situaciones en las que podrían ofrecer menos beneficios. Los escritos (scripts) definen actividades específicas del proceso (por ejemplo lanzamiento, diseño, implementación, integración 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 realización un conjunto de datos, fundamentalmente de carácter estadístico En los scripts de PSP no se incluyen tareas y actividades para la etapa de análisis de requerimientos. Siempre se parte de una definición de requerimientos que no va a cambiar.

Script general Revisar los objetivos del proyecto con las de gestión, 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 mínimo en términos generales.  Valorar los riesgos del proyecto y asignar responsabilidad de rastreo para cada riesgo clave. Ventajas: Brinda ayuda a los diseñadores, mediante una guía bien estructurada, para la realización de cada etapa del proceso de software 2,6. Leer [Nog00] y escribir un documento de dos o tres páginas que discute el impacto de "caos" en la ingeniería de software. Resumen Este artículo discute los problemas de la ingeniería de software como el eslabón más débil en el desarrollo de sistemas capaces de conseguir la superioridad de información. Los cambios rápidos en la tecnología de introducir dificultades adicionales en términos de planificación estratégica, estructura organizacional, y la ingeniería de proyectos de desarrollo de software. En el entorno tan complejo, una nueva forma de pensar se requiere. Se analiza la introducción de los sistemas adaptativos complejos como una alternativa para la planificación 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 teoría en ingeniería de software como una alternativa a los procesos burocráticos de desarrollo de software. Se presentan también algunas recomendaciones que podrían ayudar a adquirir una ventaja competitiva en el desarrollo de software, por lo tanto, lograr la superioridad de la información. 2,7. Proporcione tres ejemplos de proyectos de software que podrían efectuarse con el modelo en cascada. Sea específico. El modelo en cascada es adecuada para proyectas con las siguientes características El problema es bien entendido (los requisitos están 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 modificación a un programa existente  Implementación directa de un cálculo numérico  Una mejora limitada a un programa existente  Una adaptación a un software contable debido a los cambios en las regulaciones del gobierno 2,8. Proporcione tres ejemplos de proyectos de software que podrían ser susceptibles a la modelo de prototipo. Sea específico.

El Modelo de prototipos, en Ingeniería 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 informáticos que lleven la contabilidad, o que visualicen de forma rápida en pantalla la relación unidades, precio unidad, total. La creación de prototipos ayuda a que nuestro cliente imagine su propio software tal y como si él estuviera elaborándolo. EJEMPLO 2 La configuración de la interfaz con el usuario y el formato de los despliegues de salida El diseño rápido conducen a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteración 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 compañías de ofrecen servicios de carteleras u horarios de películas necesitan tener una interfaz muy llamativa y cuando van a adquirirla necesitan hacer una rápida construcción de un prototipo el cual se va a evaluación 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 sistemáticas que aseguran que el proceso del software y productos conformados por requerimientos, estándares, y procedimientos. Los procesos incluyen todas las actividades involucradas en el diseño, codificación, pruebas y mantenimiento; Los productos incluyen software, datos asociados, documentación, y toda la documentación para soporte y reportes y/o producto? Reglas de diseño más rigurosos y procedimientos de SQA debe aplicarse desde el principio El prototipo debe ser diseñado pensando en la extensibilidad y se ejecutará mediante un entorno de programación que se presta al desarrollo del sistema de producción 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 producción 2. I0. Proporcione tres ejemplos de proyectos de software que podrían ser susceptibles a la modelo incremental. Sea específico. Un sistema operativo. Las diversas partes del SO podría ser desarrollado como el cliente los quiere. Por ejemplo, el cliente que desee especificar la primera interfaz gráfica de usuario, y probarlo antes de proporcionar especificaciones adicionales para las partes restantes del SO. La GUI podría

entonces ser desarrollado; una vez que el usuario autorizado, algunas de las funciones más importantes de la porción de capa de abstracción de hardware se podría añadir. El proceso podría continuar hasta que todo el sistema es completo, con los clientes obtener actualizaciones continuas para probar y aprobar. Una aplicación del navegador de Internet. La aplicación de base podría ser desarrollada y distribuida, seguida por cualquiera de una serie de plug-ins para aumentar la funcionalidad. Los plug-ins pueden incluir la interpretación de JavaScript, el análisis de XML, y así sucesivamente. La mayoría de los navegadores disponibles podrían seguir este modelo. La telemetría satelital y el software de control. Hay un número de piezas a un sistema de esta naturaleza, todos los cuales pueden ser desarrollados (básicamente) de forma independiente, y después se integra más tarde. El cliente puede (de nuevo) hacerse cargo de las partes del sistema, tales como la telemetría decommutator, codificador de mando, y archivador de la historia de la telemetría. 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 solución es considerablemente más compleja. Sin embargo, puede haber un periférico o requerimiento de software que sea importante en cada fase, el software para el modelado y el análisis que puede ser muy compleja. En segundo lugar, la mayor parte del software en las últimas fases debería ser más fiable, mejor documentado y probado más a fondo. Esto puede incluso hasta el punto en que la nueva versión del software este diseñado y desarrollado específicamente para mejorar o para solicitar una nueva versión 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 implementación más ordenada y específicamente ya de las partes más 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 continuación, 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 ingeniería de software están llevando a cabo al mismo tiempo. El desafío 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 revisión, línea base, hecho. Estos estados representan las diferentes etapas de la terminación del proyecto de desarrollo de software, y se llevan a cabo al mismo tiempo. Se proporciona una situación precisa del estado actual del proyecto de desarrollo de software.

2.14. ¿Cuáles 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 gestión por el desarrollo personal mayor. · Crea un ambiente consciente de la calidad. · Funcionar como un núcleo de control de calidad en toda la compañía a nivel de taller. · Aumenta la moral de los empleados y el sentido de objetivo común. · Los empleados deben estar bien educados y tienen una buena comprensión de la organización más allá del área de trabajo propia. · Los círculos de calidad rentable. · Libera tienda de la gestión de los trabajadores de planta mejor situados para identificar los problemas.

Desventajas · La intensidad del trabajo aumenta, a medida que más problemas se resuelven más se espera de los trabajadores. · Puede ser introducido es decir, las razones incorrectas. cambio de actitud. · La administración 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 más hincapié en la calidad del producto puede llevar a muchas fallas, el software puede requerir más pruebas, diseño y trabajo de implementación a continuación, hacer. Los requisitos pueden ser mal definidos y puede tener que cambiar continuamente. La mitad de corazón y de la velocidad puede hacer que la gestión del riesgo de no detectar los principales riesgos del proyecto. Muy poca calidad puede dar lugar a problemas de calidad y las revisiones más tarde. 2,15. Proporcione tres ejemplos de proyectos de software que podrían ser susceptibles al modelo basado en componentes. Sea específico. Una aplicación de PDA inalámbrico en Java. Esto puede incluir cualquier número de aplicaciones de datos posibles, tales como libreta de direcciones, lista de tareas, calendario de reuniones, lista de teléfonos, y muchos más. Los componentes están disponibles para realizar estas funciones, de manera que la aplicación se desarrolló utilizando ellos. El equipo de desarrollo podría centrarse en todas las partes de forma independiente, control de cada parte COTS de forma individual antes de su integración con todo el sistema. Estas piezas pueden ser intercambiadas dentro y fuera según sea necesario, en base a los resultados del proceso de pruebas de integración. Un ordenador distribuido controlador para el control industrial en una fábrica. Todas las máquinas podrían tener sus propios sistemas en tiempo real basados en computadoras, que están conectados en red. La red podría permitir el control al pasar a una "señal de control", tanto como en un "token ring" de la red. Firmware Cada máquina controlador individual sería 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 máquina virtual puede producir. Un tiempo real traductor de idiomas. El traductor podría tener componentes para varios idiomas, e incluso podría incluir un diccionario de sinónimos 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 mayoría de los esfuerzos de desarrollo no incluyen software de prueba de la corrección es que en la actualidad, no existe ningún producto de software disponible en el mercado para probar la exactitud del software genérico. Este proceso por lo tanto sería necesario que el equipo de desarrollo de software genere su propia prueba, una tarea para la cual es muy poco probable que un cliente estaría dispuesto a pagar. Una excepción a esto es la verificación del compilador, para el desarrollo de aplicaciones del software. Un obstáculo adicional es que las pruebas para verificar la corrección incluso de programas informáticos específicos son muy difíciles de desarrollar. Los enfoques habituales requieren descomponer el software en cualquiera de los modelos matemáticos o de orientación gráfica. 2.17 - ¿Son lo mismo el proceso unificado y UML? Explique su respuesta. No porque: UML es un lenguaje gráfico 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 metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. UML es una herramienta del RUP. UML es un lenguaje de modelado estándar, no un proceso de desarrollo de software