REQUERIMIENTOS
Un requerimiento e una condición o capacidad
a la que el sistema (siendo construido) debe conformar
Un requerimiento de software puede ser
definido como:
- Una
capacidad del software necesaria por el usuario para resolver un problema
o alcanzar un objetivo.
- Una
capacidad del software que debe ser reunida o poseída por un sistema o
componente del sistema para satisfacer un contrto, especificación,
estándar, u otra documentación formal
DOCUMENTO DE ESPECIFICACIÓN DEL SISTEMA
1. Definición
del problema
2. Descripción
funcional
3. Restricciones
4. Diagramas
de flujo de datos
5. Modelo
de Modelo de datos
6. Diccionario
de datos
7. Casos
de uso
8. Documentos
adicionales
RIESGOS EN INGENIERÍA DE SOFTWARE
- Riesgos
del proyecto
- Incremento en costes
- Desbordamiento organizativo
- Riesgos
del negocio
- De
mercado
- De
estrategia
- De
ventas
- De
gestión
- De
presupuesto
Identificación de riesgos
- Grupos
de riegos
- Genéricos:
Son comunes a todos los proyectos
- Específicos:
Implican un conocimiento profundo del proyecto
- Categorías
- Relacionados con el tamaño del producto
- Con el impacto en la organización
- Con el tipo de cliente
- Con la definición del proceso de producción
- Con el entorno de desarrollo
- Con la tecnología
- Con la experiencia y tamaño del equipo
- Asociados
con el tamaño del producto
- Tamaño estimado del proyecto (LOC/PF)
- Confianza en la estimación
- Numero de programas, archivos y transacciones
- Tamaño relativo al resto de proyectos
- Tamaño de la base de datos
- Número de usuarios
- Número de cambios de requerimientos previstos antes
y después de la entrega
- Cantidad de software reutilizado
- Impacto en la organización
- Efecto del producto en la cifra de ventas
- Visibilidad desde la dirección de la
organización
- Fecha límite de entrega razonable
- Número de clientes que usarán el producto
- Numero de productos con los que deberá
interaccionar
- Sofisticación del usuario final
- Cantidad y calidad de la documentación a
entregar al cliente
- Límites legales y gubernamentales
- Costes asociados al retraso en la entrega
- Costes asociados a errores en el producto
- Relacionados con el cliente
- Hay experiencias anteriores con dicho cliente
- Tiene una idea clara de lo que precisa
- Está dispuesto a dedicar tiempo en la
especificación formal de requerimientos
- Está dispuesto a relacionarse de forma ágil
con el equipo de desarrollo
- Está dispuesto a participar en la revisiones
- Es un usuario experto
- Dejará trabajar al equipo de desarrollo sin
dar consejos de experto informático
- Entiende el ciclo de vida de una aplicación
·
Riesgos del proceso de producción
- Hay una política clara de
normalización y seguimiento de una metodología
- Existe una metodología escrita
para el proyecto
- Se ha utilizado en otros
proyectos
- Están los gestores y
desarrolladores formados
- Conoce todo el mundo los
standards
- Existen plantillas y modelos
para todos los documentos resultado del proceso
- Se aplican revisiones técnicas
de la especificación de requerimientos diseño y codificación
- Se aplican revisiones técnicas
de los procedimientos de revisión y prueba
·
Riesgos tecnológicos
- Se trata de una tecnología nueva
en la organización
- Se requieren nuevos algoritmos o
tecnología de I/O
- Se debe interactuar con hardware
nuevo
- Se debe interactuar con software
que no ha sido probado
- Se debe interactuar con un B.D.
cuya funcionalidad y rendimiento no ha sido probada
- Es requerido un interface de
usuario especializado
- Se necesitan componentes de
programa radicalmente diferentes a los hasta ahora desarrollados
- Se identifican cuatro
componentes del riesgo en un proyecto software
- Rendimiento
- Coste
- Mantenibilidad
- Planificación
- Tras identificar los
factores de riesgo, es necesario averiguar a qué componentes del riesgo
afectan y en qué medida
- Despreciable
- Marginal
- Crítica
- Catastrófica
ADMINISTRACIÓN DE
RIESGOS
La gestión de riesgos es un enfoque estructurado para
manejar la incertidumbre relativa a una amenaza, a través de
una secuencia de actividades humanas que incluyen evaluación
de riesgo,
estrategias de desarrollo para manejarlo y mitigación del riesgo utilizando
recursos gerenciales. Las estrategias incluyen transferir el riesgo a otra
parte, evadir el riesgo, reducir los efectos negativos del riesgo y aceptar
algunas o todas las consecuencias de un riesgo particular.
Algunas veces, el manejo de riesgos se
centra en la contención de riesgo por causas físicas o legales (por ejemplo,
desastres naturales o incendios, accidentes, muerte o demandas). Por otra
parte, la gestión de riesgo financiero se enfoca en los riesgos que pueden ser
manejados usando instrumentos financieros y comerciales.
El objetivo de la gestión de riesgos
es reducir diferentes riesgos relativos a un ámbito preseleccionado a un nivel
aceptado por la sociedad. Puede referirse a numerosos tipos de amenazas
causadas por el medio ambiente, la tecnología, los seres humanos, las
organizaciones y la política. Por otro lado, involucra todos los recursos disponibles
por los seres humanos o, en particular, por una entidad de manejo de riesgos
(persona, staff,
organización).
Así, la administración de riesgo empresarial es un proceso realizado por el consejo
directivo de una entidad, la administración y el personal de dicha entidad. Es
aplicado en el establecimiento de estrategias de toda la empresa,
diseñada para identificar eventos potenciales que puedan afectar a la entidad y
administrar los riesgos para proporcionar una seguridad e integridad razonable
referente al logro de objetivos.
La gestión de riesgos financieros ha
cobrado una especial relevancia a nivel internacional, debido en parte a las
crisis financieras de los años noventa. La gestión de riesgos financieros se
ocupa de diversos tipos de riesgos financieros.
GESTIÓN DEL PROCESO
DE DESARROLLO DE SISTEMAS DE SOFTWARE.
Un 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.
Actividades para el
desarrollo de software.
Planificació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.
Implementación
La implementación es parte del proceso en el que los ingenieros
de software programan el código para el proyecto.
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 una API,
tanto interior como exterior.
Despliegue
y mantenimiento
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 y mejora del software 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.
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.
Modelo Cascada
El modelo de cascada muestra un
proceso donde los desarrolladores han de seguir las siguientes fases 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.
Modelo
de Espiral
La principal características 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 iteraciones 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 cómo
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:
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.
Modelo
Iterativo e Incremental
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
Desarrollo Ágil
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 cómo 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.
PLANEACIÓN DE
RECURSOS DEL PROYECTO DE SOFTWARE, RECURSOS HUMANOS, PROCESOS Y METODOLOGÍAS, Y
HERRAMIENTAS Y EQUIPO.
Planeación
de recursos del proyecto de software.
El objetivo de la planeación
del proyecto de Software, es proporcionar un marco de trabajo que permita al
gestor hacer estimaciones razonables de recursos, costos y planificación
temporal. Esta se logra mediante un proceso de descubrimiento de la información
que lleve a estimaciones razonables.
La Segunda tarea de la
planificación del desarrollo de Software es la estimación de los recursos
requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a
una pirámide donde las Herramientas (hardware y Software), son la base
proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo
nivel de la pirámide se encuentran los Componentes reutilizables.
Y en la parte más alta de la
pirámide se encuentra el recurso primario, las personas (el recurso humano).
Cada recurso queda especificado
mediante cuatro características:
- Descripción del Recurso.
- Informes de disponibilidad.
- Fecha cronológica en la que se requiere el
recurso.
- Tiempo durante el que será aplicado el
recurso.
Planeación
de recursos humanos.
La Cantidad de
personas requeridas para el desarrollo de un proyecto de software solo puede
ser determinado después de hacer una estimación del esfuerzo de desarrollo (por
ejemplo personas mes o personas años), y seleccionar la posición dentro de la
organización y la especialidad que desempeñara cada profesional.
Planeación
de procesos y metodologías
El Diseño de Sistemas se define el proceso de
aplicar ciertas técnicas y principios con el propósito de definir un
dispositivo, un proceso o un Sistema, con suficientes detalles como para
permitir su interpretación y realización física.
La etapa del Diseño del Sistema encierra cuatro
etapas:
1. El diseño de los datos.
Trasforma el modelo de dominio de
la información, creado durante el análisis, en las estructuras de datos
necesarios para implementar el Software.
2. El Diseño Arquitectónico.
Define la relación entre cada uno
de los elementos estructurales del programa.
3. El Diseño de la Interfaz.
Describe como se comunica el
Software consigo mismo, con los sistemas que operan junto con él y con los
operadores y usuarios que lo emplean.
4. El Diseño de procedimientos.
Transforma elementos estructurales de la arquitectura
del programa. La importancia del Diseño del Software se puede definir en una
sola palabra Calidad, dentro del diseño es donde se fomenta
la calidad del Proyecto. El Diseño es la única manera de materializar con
precisión los requerimientos del cliente.
El Diseño del Software es un proceso y un modelado
a la vez. El proceso de Diseño es un conjunto de pasos repetitivos que permiten
al diseñador describir todos los aspectos del Sistema a construir. A lo largo
del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de
revisiones técnicas:
El diseño debe implementar todos los requisitos
explícitos contenidos en el modelo de análisis y debe acumular todos los
requisitos implícitos que desea el cliente.
Debe ser una guía que puedan leer y entender los
que construyan el código y los que prueban y mantienen el Software.
El Diseño debe proporcionar una completa idea de lo
que es el Software, enfocando los dominios de datos, funcional y comportamiento
desde el punto de vista de la Implementación.
Para evaluar la calidad de una presentación del
diseño, se deben establecer criterios técnicos para un buen diseño como son:
- Un
diseño debe presentar una organización jerárquica que haga un uso
inteligente del control entre los componentes del software.
- El
diseño debe ser modular, es decir, se debe hacer una partición lógica del
Software en elementos que realicen funciones y subsunciones específicas.
- Un
diseño debe contener abstracciones de datos y procedimientos.
- Debe
producir módulos que presenten características de funcionamiento
independiente.
- Debe
conducir a interfaces que reduzcan la complejidad de las conexiones entre
los módulos y el entorno exterior.
- Debe
producir un diseño usando un método que pudiera repetirse según la
información obtenida durante el análisis de requisitos de Software.
Estos criterios no se consiguen por casualidad. El
proceso de Diseño del Software exige buena calidad a través de la aplicación de
principios fundamentales de Diseño, Metodología sistemática y una revisión
exhaustiva.
Cuando se va a diseñar un Sistema de Computadoras
se debe tener presente que el proceso de un diseño incluye, concebir y planear
algo en la mente, así como hacer un dibujo o modelo o croquis.
Planeación
de herramientas y equipo.
El entorno es donde se apoya el
proyecto de Software, llamado a menudo entorno de Ingeniería de Software,
incorpora Hardware y Software.
El Hardware proporciona una
plataforma con las herramientas (Software) requeridas para producir los
productos que son el resultado de la buena práctica de la Ingeniería del
Software, un planificador de proyectos debe determinar la ventana temporal
requerida para el Hardware y el Software, y verificar que estos recursos estén
disponibles. Muchas veces el desarrollo de las pruebas de validación de un
proyecto de software para la composición automatizada puede necesitar un
compositor de fotografías en algún punto durante el desarrollo. Cada elemento
de hardware debe ser especificado por el planificador del Proyecto de Software.
http://www.e-mas.co.cl/categorias/informatica/analisisyd.htm
CALENDARIO O CRONOGRAMA
Se
trata de organizar las actividades que se van a llevar a cabo en la
intervención mediante un cronograma.
El cronograma es "un esquema básico donde
se distribuye y organiza en forma de secuencia temporal el conjunto de
actividades diseñadas a lo largo de una intervención. La organización temporal
básicamente se organiza en torno a dos ejes: la duración de la actividad y el
tiempo que previsiblemente el usuario dedicará al desarrollo de cada
actividad".
DIAGRAMA DE GANTT
El diagrama de Gantt es
una popular herramienta gráfica cuyo objetivo es mostrar el tiempo de
dedicación previsto para diferentes tareas o actividades a lo largo de un
tiempo total determinado. A pesar de esto, el diagrama de Gantt no indica las
relaciones existentes entre actividades.
MÉTODO DE RUTA CRÍTICA – CPM
El método de la ruta
crítica o del camino crítico es un algoritmo utilizado para el cálculo
de tiempos y plazos en la planificación de proyectos.1 Este sistema de cálculo conocido por sus siglas
en inglés CPM (Critical Path Method), fue desarrollado en 1957 en los Estados
Unidos de América, por un centro de investigación de operaciones para las
firmas Dupont y Remington Rand, buscando el control y la optimización de los
costos mediante la planificación y programación adecuadas de las actividades
componentes del proyecto.
Si bien el método de la ruta crítica no constituye un sistema de gestión
per-se, muchos sistemas de gestión de proyecto han utilizado este algoritmo
para obtener indicadores válidos para la planificación.
En administración y gestión de proyectos, una ruta crítica es la secuencia de los elementos terminales de la red
de proyectos con la mayor duración entre ellos,
determinando el tiempo más corto en el que es posible completar el proyecto. La
duración de la ruta crítica determina la duración del proyecto entero. Cualquier
retraso en un elemento de la ruta crítica afecta a la fecha de término planeada
del proyecto, y se dice que no hay holgura en la ruta crítica.
Un proyecto puede tener varias rutas críticas paralelas. Una ruta
paralela adicional a través de la red con la duración total cercana a la de la
ruta crítica, aunque necesariamente menor, se llama ruta sub-crítica.
Originalmente, el método de la ruta crítica consideró solamente
dependencias entre los elementos terminales. Un concepto relacionado es la
cadena crítica, la cual agrega dependencias de recursos. Cada recurso depende
del manejador en el momento donde la ruta crítica se presente.
A diferencia de la técnica de revisión y evaluación de programas (PERT), el método de la
ruta crítica usa tiempos ciertos (reales o determinísticos). Sin embargo, la
elaboración de un proyecto basándose en redes CPM y PERT son similares y
consisten en:
·
Identificar todas las actividades que involucra el proyecto,
lo que significa, determinar relaciones de precedencia, tiempos técnicos para
cada una de las actividades.
·
Construir una red con base en nodos y actividades (o arcos,
según el método más usado), que implican el proyecto.
·
Analizar los cálculos específicos, identificando la
ruta crítica y las holguras de las actividades que componen el proyecto.
En términos prácticos, la ruta crítica se interpreta como la dimensión
máxima que puede durar el proyecto y las diferencias con las otras rutas que no
sean la crítica, se denominan tiempos de holgura.
PERT
La Técnicas de Revisión y Evaluación de
Proyectos (en inglés, Project
Evaluation and Review Techniques), comúnmente abreviada como PERT, es un modelo para la administración y gestión
de proyectos inventado en 1958 por la Oficina de Proyectos Especiales
de la Marina de Guerra del Departamento de Defensa de los EE. UU. como parte del proyecto Polaris de misil balístico móvil lanzado desde
submarino. Este proyecto fue una respuesta directa a la crisis del Sputnik.
PERT es básicamente un método para
analizar las tareas involucradas en completar un proyecto dado, especialmente
el tiempo para completar cada tarea, e identificar el tiempo mínimo necesario
para completar el proyecto total.
Este modelo de proyecto fue el primero
de su tipo, un reanimo para la administración científica, fundada por el fordismo y el taylorismo. No es muy común el modelo de proyectos, todos se
basan en PERT de algún modo. Sólo el método
de la ruta crítica (CPM)
de la Corporación
DuPont fue
inventado en casi el mismo momento que PERT.
La parte más famosa de PERT son las Redes PERT, diagramas de líneas
de tiempo que se interconectan.
Una malla PERT permite planificar y
controlar el desarrollo de un proyecto. A diferencia de las redes CPM,
las redes PERT trabajan con tiempos probabilísticos. Normalmente para
desarrollar un proyecto específico lo primero que se hace es determinar, en una
reunión multidisciplinaria, cuáles son las actividades que se deberá ejecutar
para llevar a feliz término el proyecto, cuál es la precedencia entre ellas y
cuál será la duración esperada de cada una.
Para definir la precedencia entre
actividades se requiere de una cierta cuota de experiencia profesional en el
área, en proyectos afines.
