Mitos y desarrollo del Software.

Universidad Pedagógica de el Salvador.

Cátedra:

                        Ingeniería en sistema de                                             software.

Alumno:

                    Alex Balmore Gómez Cornejo.

Tema:

                    Mitos y desarrollo del

                        Software.

Índice.

Introducción.                                             3

Objetivos.                                                    4

Mitos del software.                                 5-6

Mitos de gestión.                                      7

Mitos del cliente.                                     8

Desarrollo ágil.                                         9

Procesos xp.                                         10

DAS.                                                               11

Scrum.                                                          12

Procesos escrum.                                     13

Conclusión.                                                 14

Fin.

Introducción.

Actualmente en nuestro País resaltan personajes con buena calidad de software

La humanidad sin creerlo pero nosotros tenemos la capacidad de ser grandes desarrolladores de ello surge la necesidad de comprender como evaluar u software dejando de fuera mitos surgidos en muchos casos por la manera de cómo fue desarrollado el sistema

Objetivos.

General.

               Desarrollo del software.

Especifico.

Ø Comprendes los mitos de software.

Ø Tipos de mitos que surgen y como invadirlos.

Ø Indagar sobre otros mitos de programación y procesos.

Mitos Del Software (admón.).

Los mitos del software-creencias del desarrollo  acerca del software y de los procesos empleados para construirlo- se pueden rastrear hasta los primeros días de la computación del desarrollo. Los mitos tienen ciertos atributos que los convierten en reales no cambiantes.

Muchas de las causas de la crisis del software pueden ser encontradas en una mitología que surge durante los primeros años del desarrollo del software Los mitos del software propagaron información errónea y con fusión

Mito:

Si fallamos en la planificación podemos añadir más programadores
y recuperar el tiempo perdido.
Realidad:

Ley de Brooks: "Agregar gente a un proyecto atrasado, lo
atrasa aún más".
Razón: Crear software no es una tarea particional, como dice el
Principio de Brooks: "Gestar a un bebé tarda 9 meses, no importa cuántas mujeres sean asignadas a la tarea.

Mito:

Una declaración general de los objetivos es suficiente para
comenzar a escribir los programas; podemos dar los detalles más adelante.

Realidad:

 Una mala definición inicial es la principal causa del trabajo en
vano. Es esencial una descripción formal y detallada del ámbito de la
información, funciones, rendimiento, interfaces y criterios de validación.
Esto solo puede determinarse después de una exhaustiva comunicación
entre el cliente y el analista.

Mito:

Una vez que hicimos el programa y funciona, nuestro trabajo ha terminado.
Realidad:

Los datos industriales indican que entre el 50% y el 70% de
todo el esfuerzo dedicado a un programa se realizará después de que se
le haya entregado al cliente por primera vez

Mitos _de Gestión (Profesional).

Los gestores están normalmente bajo la presión de cumplir presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. El gestor se agarra a un mito del software aun que tal creencia sólo disminuya la presión temporalmente.

Mito:

¿Por qué debemos cambiar nuestra forma de desarrollar el Software? Estamos haciendo el mismo tipo de programación a hora que hace diez años.

Realidad:

Aunque el dominio de la aplicación puede ser el mismo, la demanda de una mayor productividad y calidad, y el papel crítico del software en objetivos comerciales estratégicos, ha aumentado sustancialmente.

Mitos_del_cliente.

Un cliente que solicita una aplicación software puede ser interno a la compañía o una compañía exterior El cliente cree en los mitos que existen sobre el software debido a que los gestores y trabajadores responsa sables hacen muy poco para corregir la mala Información Los mitos conducen a que el cliente se cree una falsa expectativa y finalmente, quede insatisfecho con el desarrollo del software

Mito:

Una declaración general de los objetivos es suficiente para comenzar a escribir los programas, podemos dar los detalles más adelante

Realidad:

Una mala definición inicial es la principal causa del trabajo baldío en software. Una descripción formal y detallada del dominio de la información, funciones, rendimiento, interfaces, ligaduras de diseño y criterios de Validación es esencial. Estas características pueden determinarse sólo después de una exhaustiva comunicación entre el cliente y el analista.

Evaluación

Desarrollo ágil.

¿Qué es?

Podría decirse que es el trabajo desarrollado para la realización de un proyecto. Hay innumerables métodos de desarrollo ágil pero todos tienen un fin que es crear un software confiable. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas.

Esto consta de:

Planificación. Análisis de requerimientos. Diseño. Codificación.  Revisión y documentación.

Lo que se pretende con esto es crear un demo el cual se haya desarrollado sin ningún error al momento de la ejecución. Estos métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación.

Programación extrema xp.

Este método de programación  está basado en metodologías tradicionales adaptables  a los cambios, en cualquier etapa del desarrollo. Es considerado como la mejor metodología de desarrollo todo por lo que esta de acorde y se puede modificar y incluso darle cambios drásticos sin  que el obtenga daños en ninguna de sus etapas.

Procesos de xp.

Codificar

Es necesario codificar y plasmar nuestras ideas a través del código. En programación, el código expresa la interpretación del problema, así podemos utilizar el código para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar.

 Hacer pruebas

Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema, entonces habremos acabado por completo.

Escuchar

Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuáles son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.

Diseñar

El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.

Resumiendo las actividades de Xp: Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos qué codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.

Desarrollo Adoptivo del Software

(DAS).

Es una propuesta de desarrollo para software y sistemas de mayor complejidad apoyada en la colaboración humana y de equipo.

Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

Scrum.

Scrum, más que una metodología de desarrollo software, es una forma de auto-gestión de los equipos de programadores. Un grupo de programadores deciden cómo hacer sus tareas y cuánto van a tardar en ello. Scrum ayuda a que trabajen todos juntos, en la misma dirección, con un objetivo claro.

Scrum permite además seguir de forma clara el avance de las tareas a realizar, de forma que los "jefes" puedan ver día a día cómo progresa el trabajo.

Sin embargo, Scrum no es una metodología de desarrollo, puesto que no indica qué se debe hacer para hacer el código. Debería, por tanto, complementarse con alguna otra metodología de desarrollo. Se lleva bien con las metodologías ágiles y en concreto, con la programación extrema.

Procesos del Scrum.

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos. Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversión mediante la re planificación de objetivos que realiza al inicio de cada iteración. 

Conclusión.

Cada personal de desarrollo de sistemas debe de tener la manera de compren lo que su sistema requiere para evitar que surjan inconvenientes en procesos de demás que aun no se han detallado.

De igual manera  demos saber utilizar un método de programación  como el de xp para cuando el sistema u desarrollo requiera cambios no nos daría problemas u otros inconvenientes.