• No se han encontrado resultados

Proceso para el desarrollo de software Wikipedia, la enciclopedia libre pdf

N/A
N/A
Protected

Academic year: 2020

Share "Proceso para el desarrollo de software Wikipedia, la enciclopedia libre pdf"

Copied!
9
0
0

Texto completo

(1)

Proceso para el desarrollo de software

El Proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida un término más general que un determinado proceso para el desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software específicos que se ajustan a un modelo de ciclo de vida de espiral.

Generalidades

Actividades del desarrollo de software Planificación

Implementación, pruebas y documentación Despliegue y mantenimiento

Modelos de Desarrollo de Software Modelo de cascada

Modelo de espiral

Desarrollo iterativo e incremental Desarrollo ágil

Codificación y corrección Orientado a la Reutilización Modelos de mejora de procesos Métodos formales

Principales Roles en el proceso de Desarrollo de Software Descripción de roles en el Proceso de Desarrollo de Software

Gerente de proyecto Analista de requerimientos

Desarrollador de software o programador Testeador

Arquitecto de software

Véase también Referencias Enlaces externos

La gran cantidad de organizaciones de desarrollo de software implementan metodologías para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria armamentística, que en los Estados Unidos necesita un certificado basado en su modelo de procesos para poder obtener un contrato.

Índice

(2)

El estándar internacional que regula el método de selección, implementación y monitoreo del ciclo de vida del software es ISO 12207.

Durante décadas se ha perseguido la meta de encontrar procesos reproducibles y predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones intentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software. Otros aplican técnicas de gestión de proyectos para la creación del software. Sin una gestión del proyecto, los proyectos de software corren el riesgo de demorarse o consumir un presupuesto mayor que el planeado. Dada la cantidad de proyectos de software que no cumplen sus metas en términos de funcionalidad, costes o tiempo de entrega, una gestión de proyectos efectiva es algo imprescindible.

Algunas organizaciones crean un grupo propio (Software Engineering Process Group, abreviado SEPG) encargado de mejorar los procesos para el desarrollo de software en la organización.

La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de los requisitos. Los clientes suelen tener una idea más bien abstracta del resultado final, pero no sobre las funciones que debería cumplir el software.

Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo. Este documento se conoce como especificación funcional.

Planificación: es el paso previo al inicio de cualquier proyecto de desarrollo y sin dudas el más importante. En este se definen los requerimientos y funcionalidades que debe tener el software, mediante el trabajo en conjunto entre los desarrolladores, el departamento de ventas, los estudios de mercado y, fundamentalmente, el contacto con el cliente. En este punto se realizan asimismo los

análisis de riesgo para el emprendimiento y se fijan los requisitos de aseguramiento de la calidad.

La implementación es parte del proceso en el que los ingenieros de software programan el código para el proyecto de trabajo que está en relación de las demanda del software, en esta etapa se realizan las pruebas de caja blanca y caja negra.

Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del proceso tiene la función de detectar los errores de software lo antes posible.

La documentación del diseño interno del software con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentación de un API, tanto interior como exterior. Prácticamente es como una receta de cocina

Actividades del desarrollo de software

Actividades del proceso de desarrollo de software representados en el desarrollo en cascada. Hay algunos modelos más para representar este proceso.

Planificación

Implementación, pruebas y documentación

(3)

El despliegue comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su liberación y ha sido distribuido en el entorno de producción.

Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software.

El mantenimiento o mejora de un software con problemas recientemente desplegado, puede requerir más tiempo que el desarrollo inicial del software. Es posible que haya que incorporar código que no se ajusta al diseño original con el objetivo de solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno rediseñar el sistema para poder contener los costes de mantenimiento.

Los modelos de desarrollo de software son una representación abstracta de una manera en particular. Realmente no representa cómo se debe desarrollar el software, sino de un enfoque común. Puede ser modificado y adaptado de acuerdo a las necesidades del software en proceso de desarrollo. 1 Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado para sus necesidades. En ocasiones puede que una combinación de varios modelos sea apropiado. Existen tres paradigmas de los modelos de desarrollo de software:

1. Paradigma Tradicional:

Es uno de los paradigmas más antiguo, se inventó durante la creación del método estructurado. Si se elige un proyecto, el método varia en etapas.2 Como todo modelo, existen sus pros y contras al usar este paradigma:

Si se aplica este paradigma, unos de los principales problemas , es que las etapas realizadas no son autónomas de las siguientes, creando una dependencia estructural y en el acaso de un error atrasaría todo el proyecto. Se tiene que tener pautas bien definidas, y que no se incurra a modificación porque implicaría en que el software no cumpla con su ciclo de vida. Tener en cuenta que el cliente no se vea afectado por la impaciencia.3

(4)

2. Paradigma Orientado a Objetos: Estos modelos se basan en la Programación orientada a objetos; por lo tanto, se refiere al concepto de clase, el análisis de requisitos y el diseño. El modelo o paradigma orientado a objetos posee dos características principales, las cuales son:

Permite la re-utilización de software.

Facilita el desarrollo de herramientas informáticas de apoyo al desarrollo, el cual es simple al implementarla en una notación orientado a objetos llamado UML.4

3. Paradigma de Desarrollo Ágil: Es un paradigma de las Metodologías De Desarrollo basado en procesos ágiles. Estos intentan evitar los tediosos caminos de las metodologías tradicionales enfocándose en las personas y los resultados. Usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incorporando los cambios continuamente.4

El modelo de cascada define las siguientes etapas que deben cumplirse de forma sucesiva:

1. Especificación de requisitos 2. Diseño del software

3. Construcción o Implementación del software 4. Integración

5. Pruebas (o validación) 6. Despliegue (o instalación) 7. Mantenimiento

Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.

La principal característica del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.

La espiral se visualiza como un proceso que pasa a través de algunas interacciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:

1. crear planes con el propósito de identificar los objetivos del software, seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;

2. Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo;

3. la implementación del proyecto: implementación del desarrollo del software y su pertinente verificación;

Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la reutilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:

Modelo de cascada

(5)

1. El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes que acepten este análisis y actúen en consecuencia. Para ello es necesaria confianza en los desarrolladores así como la predisposición a gastar más para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.

2. Si la implementación del riesgo de análisis afectará de forma esencial los beneficios del proyecto, no debería utilizarse este modelo.

3. Los desarrolladores de software han de buscar de forma explícita riesgos y analizarlos de forma exhaustiva para que este modelo funcione.

La primera fase es la búsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por último, se evalúan los resultados y se inicia el diseño de la siguiente fase.

El desarrollo iterativo recomienda la construcción de secciones reducidas de software que irán ganando en tamaño para facilitar así la detección de problemas de importancia antes de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseño en el caso de clientes que no saben cómo definir lo que quieren.5

El desarrollo ágil de software utiliza un desarrollo iterativo como base para abogar por un punto de vista más ligero y más centrado en las personas que en el caso de las soluciones tradicionales. Los procesos ágiles utilizan retroalimentación en lugar de planificación, como principal mecanismo de control. La retroalimentación se canaliza por medio de pruebas periódicas y frecuentes versiones del software.

Hay muchas variantes de los procesos ágiles:

En el caso de la programación extrema (XP), las fases se realizan en pasos muy cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos puede ocurrir en un día o en una semana, en lugar de los meses o años de cada paso completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para proveer metas concretas al desarrollo. Después se programa el código, que será completo cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabrían como mejorar el conjunto de pruebas necesario. El diseño y la arquitectura emergen a partir de la refactorización del código, y se da después de programar. El diseño lo realizan los propios desarrolladores del código. El sistema, incompleto, pero funcional se despliega para su demostración a los usuarios (al menos uno de los cuales pertenece al equipo de desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la siguiente parte del sistema de más importancia.

El desarrollo de codificación y corrección (en inglés "Code and fix") es, más que una estrategia predeterminada, el resultado de una falta de experiencia o presión que se ejerce sobre los desarrolladores para cumplir con una fecha de entrega.6 Sin dedicar tiempo de forma explícita para el diseño, los programadores comienzan de forma inmediata a producir código. Antes o después comienza la fase de pruebas de software (a menudo de forma tardía) y los inevitables errores que se encuentran han de eliminarse antes de poder entregar el software.

La reutilización de software es un proceso donde se recurre al uso de activos de software en las especificaciones de análisis, diseños, implementación y pruebas de una aplicación o sistemas de software.7

Desarrollo iterativo e incremental

Desarrollo ágil

Codificación y corrección

(6)

La reutilización tiene ciertos Indicadores por ejemplo:

1. Entre el 40% y 60% de una aplicación es re-utilizable en otra.

2. Aproximadamente el 0% de una aplicación administrativa es re-utilizable.

3. Aproximadamente el 75% de las funciones son comunes a más de un programa.

4. Solo el 15% del código encontrado en muchos sistemas es único y novedoso a una aplicación especifica.

El rango general de uso recurrente está entre el 15% y 85%.8

La reutilización tiene Principios como la existencia de parecidos en distintos sistemas de un mismo dominio, donde el software puede representarse como una combinación de módulos y los sistemas nuevos se puede caracterizar por diferencias respecto a los antiguos sistemas.9

Capability Maturity Model Integration

El

Capability Maturity Model Integration (CMMI), en español «Integración de Modelos de

Madurez de Capacidades» es uno de los modelos líderes basados en mejores prácticas. Son

evaluaciones independientes las que confirman el grado con el que una organización siguen

sus propios procesos, que no evalúa la calidad de los procesos o del software que se produce.

CMMI ha reemplazado a CMM y tiene un ámbito global, no sólo en procesos destinados al

desarrollo del software.

ISO 9000

ISO 9000 describe estándares para un proceso organizado formalmente para resultar en un

producto y los métodos de gestión y monitoreo del progreso. Aunque este estándar se creó

inicialmente para el sector de producción, los estándares de ISO 9000 también se han aplicado

al desarrollo del software. Al igual que CMMI, que una organización está certificada con el ISO

9000 no garantiza la calidad del resultado final, sólo confirma que se ha seguido los procesos

establecidos.

ISO 15504

ISO 15504, también conocido como

Software Process Improvement Capability Determination

(SPICE), en español «Determinación de la Capacidad de Mejora del Proceso de Software» es

un marco para la evaluación de procesos de software. Este estándar tiene como objetivo un

modelo claro para poder comparar procesos. SPICE se utiliza como en el caso de CMMI.

Modela procesos para gestionar, controlar, guiar y monitorear el desarrollo del software. Este

modelo se utiliza entonces para medir lo que una organización o proyecto hace durante el

desarrollo del software. Esta información se analiza para identificar puntos débiles y definir

acciones para subsanarlos. También identifica puntos fuertes que pueden adoptarse en el resto

de la organización.

Los métodos formales son soluciones matemáticas para resolver problemas de software y hardware a nivel de requisitos, especificación y diseño. Ejemplos de métodos formales incluyen el Método B, la red de Petri, la demostración automática de teoremas, RAISE y el VDM. Hay varias notaciones de especificaciones formales, tales como el lenguaje Z. Más generalmente, se puede utilizar la teoría de autómatas para aumentar y validar el comportamiento de la aplicación diseñando un sistema de autómata finito.

Modelos de mejora de procesos

(7)

Las metodologías basadas en los autómatas finitos permiten especificación de software ejecutable y evitar la creación convencional de código.

Los métodos formales se suelen aplicar en software de aviación, especialmente si es software de seguridad crítico. Los estándares de aseguramiento del software de seguridad, tales como DO178B demandan métodos formales en el nivel más alto de categorización (Nivel A).

La formalización del desarrollo de software está ganando en fuerza poco a poco, en otros ámbitos, con la aplicación del lenguaje de especificación OCL2.0 (y especializaciones tales como Java Modeling Language) y particularmente con Model-driven Architecture, que permite la ejecución de diseños, incluso especificaciones.

Otra tendencia que está surgiendo en el desarrollo de software es la redacción de especificaciones en algún tipo de lógica (normalmente una variación de FOL), para acto seguido ejecutar esa lógica como si se tratase de un programa. El lenguaje OWL, basado en lógica descriptiva, es un buen ejemplo. También se está trabajando en enlazar un idioma natural de forma automática con lógica, lógica que puede ejecutarse. Ejemplo en este campo es el Attempto Controlled English, una lógica de negocios de Internet, que no busca controlar el vocabulario o la sintaxis. Una características de los sistemas que apoyan el vínculo bidireccional inglés-lógica y ejecución directa de la lógica es que pueden explicar sus resultados en inglés en un nivel de negocios o científico.

Un Rol se define como una “Función que alguien o algo cumple” (Abstracta Academy, 2016).

Cada uno de los roles aportará al grupo parte del total necesario para tener éxito en el desarrollo. Los roles son necesarios para cubrir todas las especificaciones necesarias para cumplir un proceso ya que no todos tenemos las mismas cualidades y experiencias. Además al asignar roles, se definen objetivos y actividades para cada uno; lo anterior evitando que alguna actividad no sea asignada o que dos personas realicen el mismo trabajo.

El software se construye en equipo y hay muchas metodologías diferentes. Los roles se asignan de acuerdo a las capacidades de cada persona, así como también su especialización, experiencia e interés. Los roles más comunes son:

Tiene por función presentar informes sobre las litigaciones de riesgos, hacer cumplir los plazos y lleva el control de los costos. También organiza el equipo, realiza planificación y estima el tiempo de las actividades. En conclusión, resuelve problemas.

Se encarga del revelamiento de los requerimientos esenciales para el desarrollo del Software, la documentación de los requerimientos para así el resto del equipo lo pueda consulta en cualquier momento. Debe ser una persona con capacidad de abstracción y análisis.

Encargado de la concepción y el diseño, escribe el código, prueba lo que construye y se encarga de hacer el mantenimiento del código.

Principales Roles en el proceso de Desarrollo de Software

Descripción de roles en el Proceso de Desarrollo de Software

Gerente de proyecto

Analista de requerimientos

(8)

Diseña y ejecuta las pruebas, para ello requiere conocer el producto a probar claro esta, estudiar funcionalidad del producto y desarrollar las pruebas que revelen incidentes críticos. Reporta los incidentes y provee información sobre la calidad del sistema.

Determina las estructuras de la aplicación y las tecnologías con las que se construirá la aplicación. Está encargado del aseguramiento de la calidad, mejorar continuamente la arquitectura. Gestiona los requerimientos no funcionales, asume la dirección técnica para asegurar que todos los aspectos de la arquitectura se estén desarrollando de manera correcta.

Debe ser una persona con un innato sentido de liderazgo, dispuesto a formar a los integrantes del equipo, dispuesto a recibir y aplicar abiertamente recomendaciones.

Ingeniería de software

Anexo:Filosofías del desarrollo de software Scrum

Metodología de desarrollo de software Desarrollo ágil de software

Programación extrema Prototipo

Desarrollo de software

Lenguaje unificado de modelado

1. [1] (http://tema3isoftware.blogspot.com/p/modelos-de-desarrollo-tecnicas-y.html) 2. https://owned030.blogspot.com/

3. «Copia archivada» (https://web.archive.org/web/20130420132709/http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polil ibros/P_proceso/ANALISIS_Y_DISEnO_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20I/1.5.htm). Archivado desde el original (http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_proceso/ANALISIS_Y_DISEnO_DE_SIS TEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20I/1.5.htm) el 20 de abril de 2013. Consultado el 8 de abril de 2014. 4. Ingeniería de software

5. ieeecomputersociety.org (http://doi.ieeecomputersociety.org/10.1109/MC.2003.1204375)

6. McConnell, Steve. «7: Lifecycle Planning». Rapid Development. Redmond, Washington: Microsoft Press. p. 140. 7. J.Sametinger.Software engineering with reusable components. Springer Verlag, Agosto 1997

8. Jonas A. Montilva, Nelson Arape y Juan Andres Colmenares. (14 de noviembre de 2003). «Desarrollo de software basado en componentes» (http://juancol.me/rsrc/sw-basado-en-comp-CAC2003.pdf). Consultado el 2 de abril de 2014.

9. «Ciclo de vida del Software» (https://web.archive.org/web/20130614204403/http://alarcos.inf-cr.uclm.es/doc/ISOFTW AREI/Tema03.pdf). Archivado desde el original (http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf) el 14 de junio de 2013. Consultado el 2 de abril de 2014.

No Silver Bullet: Essence and Accidents of Software Engineering (https://web.archive.org/web/20110503201309/htt p://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html)", 1986

Gerhard Fischer, "The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design" (http://l3d.cs.colorado.edu/~gerhard/papers/isfst2001.pdf), 2001

Testeador

Arquitecto de software

Véase también

Referencias

(9)

Lydia Ash: The Web Testing Companion: The Insider's Guide to Efficient and Effective Tests, Wiley, May 2, 2003. ISBN 0-471-43021-8

SaaSSDLC.com (http://SaaSSDLC.com/) — Software as a Service Systems Development Life Cycle Project

Systems Development Life Cycle (SDLC) (https://commons.wikimedia.org/wiki/File:Systems_Development_Life_Cycl e.jpg)[visual image]

Obtenido de «https://es.wikipedia.org/w/index.php?title=Proceso_para_el_desarrollo_de_software&oldid=118289721»

Esta página se editó por última vez el 16 ago 2019 a las 09:43.

El texto está disponible bajo la Licencia Creative Commons Atribución Compartir Igual 3.0; pueden aplicarse cláusulas adicionales. Al usar este sitio, usted acepta nuestros términos de uso y nuestra política de privacidad.

Referencias

Documento similar

En cuarto lugar, se establecen unos medios para la actuación de re- fuerzo de la Cohesión (conducción y coordinación de las políticas eco- nómicas nacionales, políticas y acciones

La acción formativa dirigida a personas mayores denominada Trabajos Tutorizados, se implantó en la Universidad Politécnica de Cartagena en el Curso Académico 2008/09, siendo

If certification of devices under the MDR has not been finalised before expiry of the Directive’s certificate, and where the device does not present an unacceptable risk to health

In addition to the requirements set out in Chapter VII MDR, also other MDR requirements should apply to ‘legacy devices’, provided that those requirements

The notified body that issued the AIMDD or MDD certificate may confirm in writing (after having reviewed manufacturer’s description of the (proposed) change) that the

 Tejidos de origen humano o sus derivados que sean inviables o hayan sido transformados en inviables con una función accesoria..  Células de origen humano o sus derivados que

1.—«Dona les herbes del terme de la present vila y Baro- nía de Reileu y la tenda de aquella pera la obra de la Iglesia no- va que se ha de fer en dita vila y que ajen de

Aunque la mirada cambia con los tiempos (la famosa Lucrecia de Víctor Hugo -a la que Donizetti puso música para su ópera- no le parecía a Gregorovius sino una