Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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.
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.
Planificación[editar]
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.
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.
Despliegue y mantenimiento[editar]
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. 1Hay 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. 2Como 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
Modelo de cascada[editar]
El modelo de cascada define las siguientes etapas que deben cumplirse de forma sucesiva:
1. Especificación de requisitos
2. Diseño 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.
Modelo de espiral[editar]
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;
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:
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.
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.
Desarrollo ágil[editar]
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.
Codificación y corrección[editar]
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.
Orientado a la Reutilización[editar]
4. Solo el 15% del código encontrado en muchos sistemas es único y novedoso a una aplicación
especifica.
ISO 9000
ISO 15504
Métodos formales[editar]
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.
Las metodologías basadas en los autómatas finitos permiten especificación de software ejecutable
y evitar la creación convencional de código.
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.
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:
Gerente de proyecto[editar]
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.
Analista de requerimientos[editar]
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.
Testeador[editar]
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.
Arquitecto de software[editar]
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.