Material de complementario de lectura para la asignatura de:

Gestión de Desarrollo de Sistemas de Información

ADMINISTRACIÓN DE PROYECTOS

CICLO DE VIDA

El método de ciclo de vida del desarrollo de los sistemas a menudo funciona bien

en los grandes proyectos con requerimientos bien definidos, donde no hay mucha

presión para terminar rápido el proyecto. El uso de este método requiere una

administración apropiada y efectiva, lo que posiblemente incluye a un usuario

como el líder, si el proyecto no es altamente técnico.

La elaboración de prototipos: Es útil en situaciones donde los requerimientos se

definen pobremente y/o cuando se necesita velocidad, para esto se requiere una

administración efectiva para asegurar que las interacciones en la elaboración de

prototipos no continuarán indefinidamente. Es importante contar con herramientas

como lenguajes de software de cuarta generación y generadores de pantalla.

Desarrollo rápido de aplicaciones (DRA): Es necesario cuando los nuevos

sistemas se necesitan muy rápido. El desarrollo rápido de aplicaciones tal vez es

menos apropiado que los lenguajes de programación convencionales en grandes

proyectos o para desarrollar sistemas con una gran cantidad de cálculos o con

procesamiento en tiempo real.

Desarrollo orientado a objetos: Este se está volviendo cada vez más popular, pero

su uso se ve limitado por una escasez de personal que cuente con las habilidades

en este campo. Ej: Java es un lenguaje orientado a objetos que resulta

especialmente adecuado para desarrollar aplicaciones de red, a pesar que este

tipo de lenguaje tiende a ejecutarse lentamente.

Desarrollo del usuario final: Aunque es más apropiado para proyectos pequeños,

el desarrollo del usuario final constituye una posibilidad para proyectos más

grandes cuyas prioridades no son muy elevadas, para conducir a una respuesta

oportuna de la unidad central de sistemas de información.

Comprar o subcontratar: En los sistemas más grandes y complejos que tienen un

significativo riesgo de fracaso, las organizaciones deben considerar siempre la

opción de recurrir a una fuente externa. Los ejecutivos necesitan estar conscientes

de los costos relativamente altos de implementaciones adicionales que implican la

compra de paquetes de software empresarial.

Características del ciclo de vida del proyecto

El ciclo de vida del proyecto define las fases que conectan el inicio de un proyecto

con su fin. Por ejemplo, cuando una organización identifica una oportunidad a la

cual le interesaría responder, frecuentemente autoriza un estudio de viabilidad

para decidir si se emprenderá el proyecto. La definición del ciclo de vida del

proyecto puede ayudar al director del proyecto a determinar si deberá tratar el

estudio de viabilidad como la primera fase del proyecto o como un proyecto

separado e independiente. Cuando el resultado de dicho esfuerzo preliminar no

sea claramente identificable, lo mejor es tratar dichos esfuerzos como un proyecto

por separado. Las fases del ciclo de vida de un proyecto no son lo mismo que los

Grupos de Procesos de Dirección de Proyectos.

Las fases del ciclo de vida de un proyecto son: Inicio → Planificación →

Ejecución → Cierre del proyecto. La transición de una fase a otra dentro del

ciclo de vida de un proyecto generalmente implica y, por lo general, está definida

por alguna forma de transferencia técnica. Generalmente, los productos

entregables de una fase se revisan para verificar si están completos, si son

exactos y se aprueban antes de iniciar el trabajo de la siguiente fase. No obstante,

no es inusual que una fase comience antes de la aprobación de los productos

entregables de la fase previa, cuando los riesgos involucrados se consideran

aceptables. Esta práctica de superponer fases, que normalmente se realiza de

forma secuencial, es un ejemplo de la aplicación de la técnica de compresión del

cronograma denominada ejecución rápida.

No existe una única manera, que sea la mejor, para definir el ciclo de vida ideal de

un proyecto. Algunas organizaciones han establecido políticas que estandarizan

todos los proyectos con un ciclo de vida único, mientras que otras permiten al

equipo de dirección del proyecto elegir el ciclo de vida más apropiado para el

proyecto del equipo. Asimismo, las prácticas comunes de la industria a menudo

conducen a usar un ciclo de vida preferido dentro de dicha industria.

Los ciclos de vida del proyecto generalmente definen:

Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en

qué fase se debe realizar el trabajo del arquitecto?)

Cuándo se deben generar los productos entregables en cada fase y

cómo se revisa, verifica y valida cada producto entregable

Quién está involucrado en cada fase (por ejemplo, la ingeniería

concurrente requiere que los implementadores estén involucrados en

las fases de requisitos y de diseño)

Cómo controlar y aprobar cada fase.

Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy

detalladas. Las descripciones muy detalladas de los ciclos de vida pueden incluir

formularios, diagramas y listas de control para proporcionar estructura y control.

La mayoría de los ciclos de vida de proyectos comparten determinadas

características comunes:

En términos generales, las fases son secuenciales y, normalmente, están

definidas por alguna forma de transferencia de información técnica o

transferencia de componentes técnicos.

El nivel de coste y de personal es bajo al comienzo, alcanza su nivel

máximo en las fases intermedias y cae rápidamente cuando el proyecto se

aproxima a su conclusión

Ilustración 1. Coste del proyecto y nivel de personal típicos a lo largo del ciclo de vida del proyecto

[PMBOK®]

El nivel de incertidumbre es el más alto y, por lo tanto, el riesgo de no cumplir con

los objetivos es más elevado al inicio del proyecto. La certeza de terminar con

éxito aumenta gradualmente a medida que avanza el proyecto

El poder que tienen los interesados en el proyecto para influir en las

características finales del producto del proyecto y en el coste final del proyecto es

más alto al comienzo y decrece gradualmente a medida que avanza el proyecto.

La ilustración 2 muestra este hecho. Una de las principales causas de este

fenómeno es que el coste de los cambios y de la corrección de errores

generalmente aumenta a medida que avanza el proyecto

Ilustración 2. Influencia de los interesados a lo largo del tiempo. [PMBOK®]

Aun cuando muchos ciclos de vida de proyectos tienen nombres de fases

similares y requieren productos entregables similares, muy pocos ciclos de vida

son idénticos. Algunos tienen cuatro o cinco fases, pero otros pueden tener nueve

o más. En una misma área de aplicación pueden darse variaciones significativas.

El ciclo de vida del desarrollo de software de una organización puede tener una

única fase de diseño, mientras que otro puede tener fases separadas para el

diseño arquitectónico y el detallado. Los subproyectos también pueden tener

distintos ciclos de vida de proyectos.

Por ejemplo, una empresa de arquitectura contratada para diseñar un nuevo

edificio de oficinas participa primero en la fase de definición del propietario,

mientras hace el diseño, y luego en la fase de implementación del propietario,

mientras da soporte al esfuerzo de construcción.

El proyecto de diseño del arquitecto, sin embargo, tendrá su propia serie de fases,

desde el desarrollo conceptual, pasando por la definición e implementación, hasta

llegar a la conclusión. El arquitecto puede, inclusive, tratar el diseño de los

edificios y el soporte a la construcción como proyectos separados, cada uno con

su propio conjunto de fases.

También podemos ver en la gráfica siguiente, como se relacionan las fases del

ciclo de vida de un proyecto, con las personas que intervienen en él y su impacto

en el coste del proyecto.

Ilustracion 3 (Kezner) People with the ability to influence cost

Igualmente lo podemos ver cómo según cambiamos de fase en un proyecto, se

elevan los costes de los posibles cambios y se reducen la posibilidad de reducir

costes.

Ilustracion 4 (Krezner9 People with the ability to influence cost

Características de las fases del proyecto

La conclusión y la aprobación de uno o más productos

entregables caracterizan a una fase del proyecto. Un producto entregable

es un producto de trabajo que se puede medir y verificar, tal como una

especificación, un informe del estudio de viabilidad, un documento de

diseño detallado o un prototipo de trabajo. Algunos productos entregables

pueden corresponder al mismo proceso de dirección de proyectos,

mientras que otros son los productos finales o componentes de los

productos finales para los cuales se creó el proyecto. Los productos

entregables, y en consecuencia las fases, son parte de un proceso

generalmente secuencial, diseñado para asegurar el adecuado control del

proyecto y para obtener el producto o servicio deseado, que es el objetivo

del proyecto.

En cualquier proyecto específico, las fases se pueden subdividir

en subfases en función del tamaño, complejidad, nivel de riesgo y

restricciones del flujo de caja. Cada subfase se alinea con uno o más

productos entregables específicos para el seguimiento y control. La

mayoría de estos productos entregables de las subfases están

relacionados con el producto entregable de la fase principal, y las fases

normalmente toman el nombre de estos productos entregables de

las subfases: requisitos, diseño, construcción, prueba, puesta en marcha,

rotación, entre otros, según corresponda.

Por lo general, una fase del proyecto concluye con una revisión del

trabajo logrado y los productos entregables, a fin de determinar la

aceptación, tanto si aún se requiere trabajo adicional como si se debe

considerar cerrada la fase. Con frecuencia, la dirección lleva a cabo una

revisión para tomar una decisión a fin de comenzar las actividades de la

siguiente fase sin cerrar la fase actual, por ejemplo, cuando el director del

proyecto elige la ejecución rápida como curso de acción. Otro ejemplo es

cuando una compañía de tecnología de la información elige un ciclo de vida

iterativo donde más de una fase del proyecto puede avanzar de forma

simultánea. Los requisitos de un módulo se pueden recopilar y analizar antes

de que el módulo sea diseñado y construido. Mientras se lleva a cabo el

análisis de un módulo, se puede comenzar a recopilar los requisitos de otro

módulo de forma paralela.

Del mismo modo, se puede cerrar una fase sin la decisión de iniciar alguna

otra fase. Por ejemplo, el proyecto está completo o se considera que el

riesgo es demasiado alto para permitir la continuidad del proyecto. La

conclusión formal de la fase no incluye la autorización de la fase posterior.

Para un control efectivo, cada fase se inicia formalmente para producir una

salida, dependiente de la fase, del Grupo de Procesos de Iniciación, que

especifique lo que está permitido y lo que se espera para dicha fase, como

se muestra en la ilustración5. Se puede realizar una revisión al final de cada

fase con el objetivo explícito de obtener la autorización para cerrar la fase

actual e iniciar la fase posterior. En ocasiones, se pueden obtener ambas

autorizaciones en una sola revisión. Las revisiones al final de cada fase son

también conocidas como: salidas de fase, entradas a la fase o puntos de

cancelación.

Ilustración 5 Secuencia de fases típicas en un Ciclo de Vida del Proyecto .[PMBOK®]

Relaciones del ciclo de vida del proyecto y del ciclo de vida del producto

Muchos proyectos están vinculados con el trabajo continuo de la organización

ejecutante. Algunas organizaciones aprueban formalmente los proyectos sólo tras

haber concluido un estudio de viabilidad, un plan preliminar o alguna otra forma

equivalente de análisis. En estos casos, la planificación o el análisis

preliminar adquiere la forma de un proyecto separado. Por ejemplo, se pueden

presentar fases adicionales como resultado de desarrollar y probar un prototipo

antes de iniciar un proyecto para el desarrollo del producto final. Algunos tipos de

proyectos, especialmente los proyectos de desarrollo de servicios internos o

productos nuevos, se pueden iniciar de manera informal durante un período

limitado que permita obtener la aprobación formal de fases o actividades

adicionales.

Las fuerzas impulsoras que crean los estímulos para un proyecto se conocen

habitualmente como problemas, oportunidades o requisitos de negocio. El efecto

de estas presiones es que, en general, la dirección debe priorizar esta solicitud

con respecto a las necesidades y a las demandas de recursos de otros posibles

proyectos.

La definición del ciclo de vida del proyecto también identificará qué tareas de

transición al final del proyecto están incluidas y cuáles no, a fin de vincular el

proyecto con las operaciones de la organización ejecutante. Por ejemplo, cuando

se envía un nuevo producto a fabricación o comercializa un nuevo programa de

software. Debe tenerse cuidado en distinguir entre el ciclo de vida del proyecto y el

ciclo de vida del producto. Por ejemplo, un proyecto emprendido para colocar en el

mercado un nuevo ordenador de escritorio es sólo un aspecto del ciclo de vida del

producto. La Ilustración 6 muestra el ciclo de vida del producto que comienza con

el plan de negocio, pasa por la idea, hasta llegar al producto, las operaciones y la

retirada del producto. El ciclo de vida del proyecto atraviesa una serie de fases

para crear el producto. Proyectos adicionales pueden incluir una actualización del

rendimiento del producto. En algunas áreas de aplicación, tales como el desarrollo

de nuevos productos o el desarrollo de software, las organizaciones consideran el

ciclo de vida del proyecto como parte del ciclo de vida del producto.

Ilustración 6. Relación entre el ciclo de vida del producto y el ciclo de vida del proyecto. [PMBOK®]

TEMA 2

Ingeniería del Software

2.1 “P” de la ingeniería de software

Personas

Proceso

Proyecto

Producto

2.2 Fases genéricas

Definición

Desarrollo

Mantenimiento

Corrección

Adaptación

Mejora

Prevención

Persona

El factor humano siempre será el más importante en el desarrollo de soluciones

de software muchos empresarios famosos, líderes de empresas tecnológicas,

coinciden que el éxito que han alcanzado sus empresas no se debe a las

herramientas que utilizan, son las personas y el trabajo en equipo.

Por todos los medios posibles se debe atraer el personal talentoso e inteligente

que desea superarse y sobre todo, desea trabajar en equipo para la realización

del proyecto en que participe. El reclutamiento y selección es fundamental en la

gestión del personal, aquí se ve realmente cuáles son las personas que están en

la capacidad de aportar a la organización, y no sólo eso, también se ve si pueden

trabajar bajo presiones y sobre todo en equipo.

El proceso de software está integrado por participantes, líderes de equipo,

arquitectos, desarrolladores, ingenieros de prueba, personal de gestión, usuarios,

clientes, etc. Los participantes se los puede clasificar en cinco categorías:

1. Gestores ejecutivo: Definen los aspectos del negocio.

2. Gestores del proyecto: Planifican, motivan, organizan y controlan a los

profesionales que construyen el software.

3. Profesionales: Proporcionan las habilidades técnicas necesarias.

4. Clientes: Especifican los requerimientos.

5. Usuarios finales: Interactúan con el software.

Los líderes de equipo juegan un importantísimo papel puesto que deben ser capaz

de motivar al personal técnico para que produzca lo mejor sobre la base de su

capacidad. El equipo de software debe ser uno solo, es decir, funcionar como

conjunto, apoyarse mutuamente con el fin de lograr el cumplimiento de los

objetivos planteados. Todos los miembros del equipo deben tenerse confianza y

distribuir la carga de trabajo según el problema que se esté tratando. No todo

equipo es eficiente, pero se puede lograr esto con la suficiente motivación y el

apoyo de un buen gestor de proyectos.

Producto

Se denomina productos a todos aquellos artefactos que se creen durante la vida

del proyecto, modelos, códigos, ejecutable, documentación, diagramas UML,

bocetos de la interfaz de usuario, prototipos, componentes, planes de prueba,

ingeniería y gestión, colección de modelos, modelos de casos de uso, análisis,

diseño, despliegue, implementación y prueba. Antes de planear un proyecto, se

deben establecer los objetivos y el alcance que tendrá el proyecto, además de sus

restricciones, herramientas, técnicas y planes de gestión. Con una buena

planificación se puede estimar el tiempo que tomará desarrollar o construir el

producto y redimensionar el valor cuantitativo del mismo.

Definidos los objetivos y el dominio del producto se determinan soluciones

alternativas y viables. Para lograr rapidez en la construcción del producto, se debe

dividir la carga de trabajo entre el equipo de desarrollo, es decir, dividir el

problema. Esto, con el fin de desarrollar con mayor eficiencia y eficacia y en el

tiempo acordado con el cliente, el producto.

Proceso

Se denomina proceso al conjunto de actividades que se realizan para crear el

producto (Plantilla para crear el proyecto). El proceso se define en términos de

flujos de trabajo (conjunto de actividades), se identifican trabajadores y artefactos,

además de que se utilizan diagramas de actividad de UML para describir los flujos

de trabajo. El equipo de desarrollo debe elegir el proceso adecuado y que le

permita obtener una solución o producto que satisfaga las necesidades o

requerimientos del cliente.

Seleccionado el modelo de procesos, se desarrolla una planeación preliminar del

proyecto basado en las actividades del marco de trabajo. Esta planeación

comienza con la combinación del producto y el proceso. Cuando el equipo de

desarrollo de software ha definido correctamente el modelo de proceso, debe de

asegurarse de que este sea flexible y adecuado para el proyecto

Proyecto

Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto,

servicio o resultado único. Es un elemento organizativo de gestión que establece

una secuencia de cambios, por el cual va evolucionando diariamente. El mismo

establece una serie de iteraciones e hitos dentro de los cuales se desarrollan una

serie de casos de usos o requisitos. Debemos tener en cuenta muchos parámetros

para realizar un proyecto con la calidad requerida, y saber que existen factores

que atentan con el buen desempeño de un proyecto, estos son:

1. El personal de software no entiende las necesidades del los clientes.

2. El ámbito del producto está mal definido.

3. Los cambios se gestionan mal.

4. La tecnología elegida cambia.

5. Las necesidades comerciales cambian.

6. Los plazos de entrega no son realistas.

7. Los usuarios se resisten a la utilización del software.

8. Se pierde el patrocinio.

9. El equipo del proyecto carece de personal con las habilidades apropiadas.

10. Los gestores evitan las mejores prácticas y las lecciones aprendidas.

2.1 Fases Genéricas de la Ingeniería del Software

Fase de Definición: se centra sobre el qué. Es decir, durante la definición, el que

desarrolla el software intenta identificar qué información ha de ser procesada, qué

función y rendimiento se desea, qué comportamiento del sistema, qué interfaces

van a ser establecidas, qué restricciones de diseño existen, y qué criterios de

validación se necesitan para definir un sistema correcto. Por tanto, han de

identificarse los requisitos clave del sistema y del software. Aunque los métodos

aplicados durante la fase de definición variarán dependiendo del paradigma de

ingeniería del software (o combinación de paradigmas) que se aplique, de alguna

manera tendrán lugar tres tareas principales: ingeniería de sistemas o de

información, planificación del proyecto del software y análisis de los requisitos.

Fase de Desarrollo: se centra en el cómo. Es decir, durante el desarrollo un

ingeniero del software intenta definir cómo han de diseñarse las estructuras de

datos, cómo ha de implementarse la función dentro de una arquitectura de

software, cómo han de implementarse los detalles procedimentales, cómo han de

caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de

programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba.

Los métodos aplicados durante la fase de desarrollo variarán, aunque las tres

tareas específicas técnicas deberían ocurrir siempre: diseño del software,

generación de código y prueba del software.

Fase de Mantenimiento: se centra en el cambio que va asociado a la corrección de

errores, a las adaptaciones requeridas a medida que evoluciona el entorno del

software y a cambios debidos a las mejoras producidas por los requisitos

cambiantes del cliente. Durante la fase de mantenimiento se encuentran cuatro

tipos de cambios:

Corrección. Incluso llevando a cabo las mejores actividades de garantía de

calidad, es muy probable que el cliente descubra los defectos en el software. El

mantenimiento correctivo cambia el software para corregir los defectos.

Adaptación. Con el paso del tiempo, es probable que cambie el entorno original

(por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características

externas de productos) para el que se desarrolló el software. El mantenimiento

adaptativo produce modificación en el software para acomodarlo a los cambios de

su entorno externo.

Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir

funciones adicionales que van a producir beneficios. El mantenimiento perfectivo

lleva al software más allá de sus requisitos funcionales originales.

Prevención. El software de computadora se deteriora debido al cambio, y por esto

el mantenimiento preventivo también llamado reingeniería del software, se debe

conducir a permitir que el software sirva para las necesidades de los usuarios

finales. En esencia, el mantenimiento preventivo hace cambios en programas de

computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

Por lo que los tipos de mantenimiento son:

Perfectivo (60%): mejora del software (rendimiento, flexibilidad,

reusabilidad) o implementación de nuevos requisitos. También se conoce

como mantenimiento evolutivo.

Adaptativo (18%): adaptación del software a cambios en su entorno

tecnológico (nuevo hardware, otro sistema de gestión de bases de datos,

otro sistema operativo...)

Correctivo (17%): corrección de fallos detectados durante la explotación.

Preventivo (5%): facilitar el mantenimiento futuro del sistema (verificar pre-

condiciones, mejorar legibilidad...).

Es importante tener en cuenta el efecto del Iceberg, es decir, en el momento en el

que se le hace mantenimiento a un Software no se cuenta muchas veces con el

factor económico (¿Cuánto dinero se invertirá en el mantenimiento?), y una vez se

comienza a desarrollar la fase de mantenimiento en la aplicación, comienzan a

surgir nuevos requerimientos, el efecto del iceberg (en la superficie se ve solo una

parte de lo que realmente es su tamaño).

Dificultades encontradas:

• Documentación inadecuada, obsoleta o inexistente.

• Componentes complejos.

• Componentes mal estructurados.

• Poca familiaridad de las aplicaciones.

• Presión del tiempo.

• Falta de comunicación y participación de los usuarios.

• Gran cantidad de requerimientos.

• Gran cantidad de parches.

Las fases y los pasos relacionados descritos se complementan con un número de

actividades protectoras. Entre las actividades típicas de esta categoría se incluyen:

Seguimiento y control del proyecto de software

Revisiones técnicas formales

Garantía de calidad del software

Gestión de configuración del software

Preparación y producción de documentos

Gestión de reutilización

Mediciones

Gestión de riesgos

Metodología para el Desarrollo de Sistemas

Una Metodología para el Desarrollo, es un conjunto de actividades llevadas a

cabo para desarrollar y poner en marcha un Sistema de Información.

Objetivos y Tipos de Metodologías

Objetivos de las metodologías

• Definir actividades a llevar a cabo en un proyecto de sistemas

• Unificar criterios en la organización para el desarrollo de S.I.

• Proporcionar puntos de control y revisión.

Tipos de Metodologías

• Estructurada

• Evolutiva-Incremental

• Prototipos

• Orientada a objetos

Etapas en el desarrollo de sistemas

Análisis de requisitos

Extraer los requisitos de un producto de software es la primera etapa para crearlo.

Mientras que los clientes piensan que ellos saben lo que el software tiene que

hacer, se requiere de habilidad y experiencia en la ingeniería de software para

reconocer requisitos incompletos, ambiguos o contradictorios.

El resultado del análisis de requisitos con el cliente se plasma en el documento

ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir

definida por varios estándares, tales como CMM-I.

Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las

principales entidades que participarán en el desarrollo del software.

La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es

una parte crucial.

De esta etapa depende en gran medida el logro de los objetivos finales. Se han

ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no

está formalizada, ya se habla de la Ingeniería de Requisitos. La IEEE Std. 830-

1998 normaliza la creación de las Especificaciones de Requisitos Software

(Software Requirements Specification).

Diseño y arquitectura

Se refiere a determinar cómo funcionará de forma general sin entrar en detalles.

Consiste en incorporar consideraciones de la implementación tecnológica, como el

hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que

realizará el sistema, y se transforman las entidades definidas en el análisis de

requisitos en clases de diseño, obteniendo un modelo cercano a la programación

orientada a objetos.

Programación

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería

de software, pero no es necesariamente la porción más larga. La complejidad y la

duración de esta etapa está íntimamente ligada al o a los lenguajes de

programación utilizados.

Pruebas

Consiste en comprobar que el software realice correctamente las tareas indicadas

en la especificación. Una técnica de prueba es probar por separado cada módulo

del software, y luego probarlo de forma integral, para así llegar al objetivo. Se

considera una buena práctica el que las pruebas sean efectuadas por alguien

distinto al desarrollador que la programó, idealmente un área de pruebas; sin

perjuicio de lo anterior el programador debe hacer sus propias pruebas.

En general hay dos grandes formas de organizar un área de pruebas, la primera

es que esté compuesta por personal inexperto y que desconozca el tema de

pruebas, de esta forma se evalúa que la documentación entregada sea de calidad,

que los procesos descritos son tan claros que cualquiera puede entenderlos y el

software hace las cosas tal y como están descritas.

El segundo enfoque es tener un área de pruebas conformada por programadores

con experiencia, personas que saben sin mayores indicaciones en qué

condiciones puede fallar una aplicación y que pueden poner atención en detalles

que personal inexperto no consideraría.

Documentación

Todo lo concerniente a la documentación del propio desarrollo del software y de la

gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas,

manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales

correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos

requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del

software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar

mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores,

o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas.

De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y

trabajo de construcción es dar mantenimiento.

Modelos de proceso de sw / metodologías de desarrollo de sw (continúan en la

siguiente entrega)

Bibliografía

Recuperado de http://www.ehu.es/asignaturasKO/PM/PMBOK/cap2PMBOK.htm

http://www.ecured.cu/index.php/Cuatro_P_%CC%81s, C atro P

Pressman, Roger S. Ingeniería del Software. Un enfoque Práctico (Quinta Edición). Madrid: Concepción

Femández Madrid, 2005

GUÍA DE LOS FUNDAMENTOS PARA LA DIRECCIÓN DE PROYECTOS (Guía del PMBOK ® ) Quinta

edición