presentación de gestion de desarrollo de sistemas
DESCRIPTION
Gestión de Desarrollo de SistemasTRANSCRIPT
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