GESTIÓN Y PLANIFICACIÓN DE PROYECTOS SOFTWARE

TRABAJO COLABORATIVO No 2

TUTOR:
JAIRO MARTINEZ BANDA.

PRESENTADO POR:
CLAUDIA GUERRA HERRERA
CC: 59310152
DERLIS DEL MONCALEANO
C.C. 50.995.243
BETTY SULAY PEÑA
C.C. 52162775

GRUPO: 301404_51

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD

ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA
INGENIERIA DE SISTEMAS
2010
 IINTRODUCCION

La gestión de proyectos busca las técnicas necesarias para planificar, organizar, supervisar
y controlar proyectos de software. El objetivo de gestionar proyectos es tener un producto
de alta calidad. La gestión del proyecto de software es el primer nivel del proceso de
ingeniería de software, porque cubre todo el proceso de desarrollo.

La actividad de gestión del proyecto comprende medición y métricas, estimación, análisis

de riesgos, planificación, seguimiento y control.

La realización de este trabajo colaborativo fue de gran ayuda para aclarar dudas, afianzar
conocimientos e interiorizar en los diferentes aspectos y temas del contenido.

La asignación de roles se desarrollo de la siguiente manera:

 Yudis M. Mendoza. Participa pero no aporta.

 Betty Peña. Aporte al tercer caso.
 Derlis Moncaleano. Aporta al primer caso y segundo caso.
 Ana Galindo. No aporta
 Claudia M. Guerra H. Aporta al cuarto caso.
ESTUDIOS DE CASO

1. Se le ha nombrado gestor de proyectos dentro de una gran compañía de productos

software, su trabajo consiste en dirigir la versión de la siguiente generación de su
famoso procesador de textos. Como la competencia es intensa, se han establecido y
anunciado fechas rígidas de entrega.
¿Qué estructura de equipo elegiría y porqué? ¿Qué modelo(s) de proceso de software
elegiría y por qué?

Un proceso de software proporciona la estructura desde la que se puede establecer un

detallado plan para el desarrollo del software. Un pequeño número de actividades
estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su
tamaño o complejidad. Diferentes conjuntos de tareas -tareas, hitos, productos del trabajo y
puntos de garantía de calidad- permiten a las actividades estructurales adaptarse a las
características del proyecto de software y a los requisitos del equipo del proyecto.
Finalmente, las actividades protectoras -tales como garantía de calidad del software, gestión
de la configuración del software y medición- cubren el modelo de proceso. Las actividades
protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.

Existen casi tantas estructuras de organización de personal para el desarrollo de software

como organizaciones que se dedican a ello. Para bien o para mal, el organigrama no puede
cambiarse fácilmente. Las consecuencias prácticas y políticas de un cambio de
organización no están dentro del alcance de las responsabilidades del gestor de un proyecto
de software. Sin embargo, la organización del personal directamente involucrado en un
nuevo proyecto de software está dentro del ámbito del gestor del proyecto. Las siguientes
opciones pueden aplicarse a los recursos humanos de un proyecto que requiere n personas
trabajando durante k años: n individuos son asignados a m diferentes tareas funcionales,
tiene lugar relativamente poco trabajo conjunto; la coordinación es responsabilidad del
gestor del software que puede que tenga otros seis proyectos de los que preocuparse.

La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto,
proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de
ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de
proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al
principio
de la evolución del proyecto se arriesga a construir una elegante solución para un problema
equivocado.

El gestor de proyectos de software, trabajando junto con el equipo, debería refinar

claramente los roles y las responsabilidades antes del comienzo del proyecto.
Dirigimos los proyectos de software planificados y controlados por una razón principal -es
la Única manera conocida de gestionar la complejidad.

Particularmente diría que Descentralizado controlado (DC). Este equipo de ingeniería del
software tiene un jefe definido que coordina tareas específicas y jefes secundarios que
tienen responsabilidades sobre subtareas. La resolución de problemas sigue siendo una
actividad del grupo, pero la implementación de soluciones se reparte entre subgrupos por el
jefe de equipo. La comunicación entre subgrupos e individuos es horizontal.
También hay comunicación vertical a lo largo de la jerarquía
de control.
“Descentralizado Controlado” el líder de proyecto debe estar definido con roles claros
que este enfocando y dirigiendo a un norte fijo al equipo, ya que se va a desarrollar un
software que es bastante similar a las que se han construido antes se hace lógico y necesario
la colaboración de algunos miembros del grupo que tengan bastante experiencia en este
tipo de desarrollo” jefes secundarios”. Es decir que debido a la experiencia previa en el
desarrollo de este tipo de aplicaciones resulta bastante útil la división del grupo de trabajo
en subgrupos encabezados por líderes conocedores de dicha aplicación que colaboraran al
gestor del proyecto.

En cuanto al modelo de que se implementara en este proyecto el modelo DRA (desarrollo

rápido de aplicaciones), debido al manejo y los conocimientos previos del equipo en cuanto
al desarrollo de aplicaciones de este tipo. Si hay límites de tiempo muy severos y el
problema
se puede compartimentar mucho, el modelo apropiado es el DRA (en inglés RAD). Si la
fecha límite está tan próxima que no va a ser posible entregar toda la funcionalidad, una
estrategia incremental puede ser lo mejor.

2. Se le ha nombrado gestor de proyecto de una compañía que trabaja en el mundo de la

Ingeniería Genética, su trabajo consiste en dirigir el desarrollo de un nuevo producto de
software que acelere el ritmo de impresión de genes. El trabajo es orientado a I+D pero la
meta es implementar el software para el siguiente año.
¿Qué estructura de equipo elegiría y porqué? ¿Qué modelo(s) de proceso de software
elegiría y por qué?

El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para (1) los
clientes que han solicitado el producto y la gente que realizará el trabajo; (2) las
características del producto en sí, y (3) el entorno del proyecto en el que trabaja el equipo
de software. Cuando se selecciona un modelo de proceso, el equipo define entonces un plan
de proyecto preliminar basado en un conjunto de actividades estructurales. Una vez
establecido el plan preliminar, empieza la descomposición del proceso. Es decir, se debe
crear un plan completo reflejando las tareas requeridas a las personas para cubrir las
actividades estructurales.

Situaciones
Hechos Alternativas de solución
problemáticas
Seleccionar el personal idóneo, de acuerdo a
La necesidad de contar la experiencia y perfil profesional.
con personal para el Consideramos que la estructura de equipo
desarrollo del software sería el de Centralizado controlado (CC) ya
Implementar altamente preparado y que es un nuevo producto. El jefe del equipo se
nuevo producto motivado. Atraer, encarga de la resolución de problemas a alto
aumentar, motivar, nivel y la coordinación
desplegar y retener interna del equipo. La comunicación entre el
el talento necesario para jefe y los miembros del equipo es vertical.
mejorar su capacidad de
desarrollo de software.

Entrega del Tiempo desarrollo del Implementar estrategia de prototipos o

producto producto. versiones del producto final para que los
clientes conozcan el producto. El modelo se
software que elegiríamos seria el ESPIRAL, ya
que proporciona un desarrollo rápido de
versiones del software.

Actividades estructurales del modelo Espiral:

Comunicación con el cliente: las tareas

requeridas para establecer comunicación entre
 el desarrollador y el cliente.

Planificación: las tareas requeridas para

definir recursos, el tiempo y otras
informaciones relacionadas con el proyecto.
Son todos los requerimientos.

Análisis de riesgos: las tareas requeridas para

evaluar riesgos técnicos y otras informaciones
relacionadas con el proyecto.

Ingeniería: las tareas requeridas para

construir una o más representaciones de la
aplicación.

Construcción y adaptación: las tareas

requeridas para construir, probar, instalar y
proporcionar soporte al usuario.

Evaluación el cliente: las tareas requeridas

para obtener la reacción del cliente según la
evaluación de las representaciones del
software creadas durante la etapa de
ingeniería e implementación durante la etapa
de instalación.

3. Usted es el jefe de proyectos de una compañía de software.

Se le ha pedido que dirija a un equipo que está desarrollando un software Simulador
de Vuelos. Construya una tabla de riesgo para el proyecto.

CLASES DE RIESGOS Y DISEÑO DE LA TABLA DE RIESGOS

Existen algunos riesgos que pueden catalogarse de universales, a continuación se describen
algunos de ellos
 Rotación del personal (deja el proyecto antes que este finalice)
 Cambio de administración en la organización
 Cambio en los requerimientos
 Retrasos en la especificación
 Subestimación de tamaño
 Bajo desempeño de las herramientas de software
 Cambio de tecnología
 Competencia del producto

Riesgos del proyecto. Amenazan el plan del proyecto, si los riesgos se presentan, es
probable que la planeación se atrase y los costos aumenten.
 Presupuesto.
 Planeación temporal.
 Asignación y organización del personal.
 Recursos.
 Cliente.
 Requisitos.

Riesgos técnicos. Amenazan la calidad y la planeación temporal, si los riesgos se presentan,

la implementación puede ser difícil o imposible. Identifican problemas potenciales de:
 Ambigüedad de especificaciones.
 Diseño.
 Implementación.
 Interface.
 Técnicas anticuadas.
 Verificación.
 Mantenimiento.

Riesgos del negocio: Amenazan la viabilidad del software a construir. Pone en peligro al
proyecto o al producto.

 Riesgo de mercado. Construir un producto que nadie quiera.

 Riesgo estrategia: Construir un producto que no encaje en la estrategia comercial de la
empresa.
 Riesgo de ventas. Construir un producto que el departamento de ventas no sepa cómo
vender.
  Riesgo de dirección. Perder el apoyo de la dirección por cambio de personal o de
enfoque.
 Riesgo de presupuesto. Perder presupuesto o personal asignado.

Riesgos conocidos. Se pueden descubrir después de una cuidadosa evaluación del plan del
proyecto, del medio ambiente comercial y técnico y otras fuentes de información fiables.

 Fechas de entrega poco realistas.

 Falta de especificación de requerimientos.
 Medio ambiente pobre de desarrollo.

Riesgos predecibles. Se calculan con la experiencia de proyectos anteriores.

 Cambio de personal.
 Mala comunicación con el cliente.
 Disminución del esfuerzo de personal a medida que se atienden peticiones de
mantenimiento.

PASOS NECESARIOS PARA LA CREACION DE UNA TABLA DE RIESGOS

1. En la primera columna se listan todo los riesgos en desorden

2. En la segunda columna se pone la categoría del riesgo.
3. En la tercera columna se pone la probabilidad estimada del riesgo. Puede ser estimada por
consenso, o individualmente y sacar un promedio.
4. En la cuarta columna se pone el impacto del riesgo
 1 catastrófico
 2 críticos
 3 marginal
 4 despreciable
 RIESGO CAT. PROB. % IMPACTO
El personal contratado abandona el proyecto antes de su
finalización. IO A 75% 2
Alguien de la plantilla abandona el proyecto antes de su
finalización. IO A 75% 2
La falta de entusiasmo en la gestión de riesgos impide
detectar los riesgos más importantes del proyecto. ED A 75% 2
La gestión de riesgos del proyecto software consume más
tiempo del esperado. PP A 75% 2
Unos requisitos rígidos de compatibilidad con el sistema
existente necesitan un trabajo extra de comprobación,
diseño e implementación. PP A 75% 3
La incorporación de nuevo personal de desarrollo al
proyecto ya avanzado, y el aprendizaje y comunicaciones
extra imprevistas reducen la eficiencia de los miembros del
equipo existentes. IO A 75% 3
No se puede construir un producto de tal envergadura en el
tiempo asignado. TP B 25% 1
Los planes del proyecto se abandonan por la presión,
llevando al caos y a un desarrollo ineficiente OG B 25% 1
No se ha solicitado información al usuario, por lo que el
producto al final no se ajusta a las necesidades del usuario, y
hay que volver a crear el producto. UF B 25% 1
Un mal diseño implica volver a diseñar e implementar. DI B 25% 1
La planificación no incluye tareas necesarias. TP B 25% 2
Los usuarios no han realizado la compra del material
necesario para el proyecto y, por tanto, no tienen la
infraestructura necesaria. UF B 25% 2
El desarrollo de una interfaz de usuario inadecuada requiere
volver a diseñarla y a implementarla. PP B 25% 2
El trabajo con un entorno software desconocido causa
problemas no previstos. ED B 25% 2
Un diseño demasiado sencillo no cubre las cuestiones
principales, con lo que hay que volver a diseñar e
implementar. TP B 25% 2
Un diseño demasiado complejo exige tener en cuenta
complicaciones innecesarias e improductivas en la
implementación. DI B 25% 2
El producto está implementado en un lenguaje de bajo nivel
(por ejemplo, ensamblador) y la productividad es menor de
la esperada. DI B 25% 2
La falta de rigor (ignorar los fundamentos y estándares del
desarrollo de software) conduce a fallos de comunicación,
problemas de calidad y repetición del trabajo PP B 25% 2
El ciclo de revisión/decisión de la directiva es más lento de
lo esperado. OG B 25% 3

Los ciclos de revisión/decisión del cliente para los planes,

prototipos y especificaciones son más lentos de lo esperado. TC B 25% 3
El cliente piensa en una velocidad de desarrollo que el
personal de desarrollo no puede alcanzar TC B 25% 3
Las definiciones de la planificación, de los recursos y del
producto han sido impuestas por el cliente o un directivo
superior, y no están equilibradas. EP B 25% 3
La planificación se ha basado en la utilización de personas
especificas de un equipo, pero estas no están disponibles EP B 25% 3
El esfuerzo es mayor que el estimado EP B 25% 3
Las áreas desconocidas del producto llevan más tiempo del
esperado en el diseño y en la implementación EP B 25% 3
La estructura inadecuada de un equipo reduce la
productividad. OG B 25% 3
El presupuesto varía el plan del proyecto. OG B 25% 3
La planificación es demasiado mala para ajustarse a la
velocidad de desarrollo deseada. OG B 25% 3

Los espacios no están disponibles en el momento necesario. AI B 25% 3

Los espacios están disponibles pero no son adecuados (por
ejemplo, falta de teléfonos, cableado de la red, mobiliario,
material de oficina, etc.). AI B 25% 3
Las herramientas de desarrollo no funcionan como se
esperaba; el personal de desarrollo necesita tiempo para
resolverlo o adaptarse a las nuevas herramientas. AI B 25% 3
Las herramientas de desarrollo no se han elegido en función
de sus características técnicas, y no proporcionan las
prestaciones previstas. AI B 25% 3
La curva de aprendizaje para la nueva herramienta de
desarrollo es más larga de lo esperado. AI B 25% 3
Las partes del proyecto que se no se han especificado
claramente consumen más tiempo del esperado. PP B 25% 3
Utilizar lo último en informática alarga la planificación de
forma impredecible. PP B 25% 3
El requisito de trabajar con varios sistemas operativos
necesita más tiempo del esperado. PP B 25% 3
El trabajo con un entorno hardware desconocido causa
problemas imprevistos. ED B 25% 3
La contratación tarda más de lo esperado. IO B 25% 3
Los miembros del equipo no trabajan bien juntos. IO B 25% 3
Las personas clave sólo están disponibles una parte del
tiempo. IO B 25% 3
La burocracia produce un progreso más lento del esperado. PP B 25% 3
La falta de un seguimiento exacto del progreso hace que se
desconozca que el proyecto esté retrasado hasta que está
muy avanzado. PP B 25% 3
El exceso de rigor (aferramiento burocrático a las políticas y
estándares de software) lleva a gastar más tiempo en gestión
del necesario. PP B 25% 3
La creación de informes de estado a nivel de directiva lleva
más tiempo al desarrollador de lo esperado. PP B 25% 3
La presión excesiva en la planificación reduce la
productividad. EP B 25% 4
El proyecto languidece demasiado en el inicio difuso. OG B 25% 4
Los despidos y las reducciones de la plantilla reducen la
capacidad del equipo. OG B 25% 4
La dirección toma decisiones que reducen la motivación del
equipo de desarrollo. OG B 25% 4

Los espacios están sobre utilizados, son ruidosos o distraen. AI B 25% 4

Los miembros del equipo no se implican en el proyecto, y
por lo tanto no alcanzan el nivel de velocidad esperados IO B 25% 4
En el último momento, a los usuarios finales no les gusta el
producto, por lo que hay que volver a diseñarlo y a
construirlo. UF M 50% 1
El cliente no acepta el software entregado, incluso aunque
cumpla todas sus especificaciones. TC M 50% 1
Alcanzar el ámbito del producto o las restricciones de
velocidad requiere más tiempo del esperado, incluyendo el
tiempo para volver a diseñar e implementar. ED M 50% 1
La falta de la especialización necesaria aumenta los defectos
y la necesidad de repetir el trabajo. ET M 50% 2
Las tareas asignadas al personal no se ajustan a sus
posibilidades. ET M 50% 2
El personal necesita un tiempo extra para aprender un
lenguaje de programación nuevo. ET M 50% 2
La falta de relaciones entre la dirección y el equipo de
desarrollo ralentiza la toma de decisiones. ET M 50% 2
La falta de motivación y de moral reduce la productividad. ET M 50% 2
El producto depende de las normativas del gobierno, que
pueden cambiar de forma inesperada. FM M 50% 2
El producto depende de estándares técnicos provisionales,
que pueden cambiar de forma inesperada. FM M 50% 2
El producto es más grande que el estimado TP M 50% 2
La fecha final ha cambiado sin ajustarse al ámbito del
producto o a los recursos disponibles. EP M 50% 2
Los usuarios finales insisten en nuevos requisitos. UF M 50% 2
El tiempo de comunicación del cliente (por ejemplo, tiempo
para responder a las preguntas para aclarar los requisitos) es
más lento del esperado. TC M 50% 2
Las herramientas de soporte y entornos impuestos por el
cliente son incompatibles, tienen un bajo rendimiento o no
funcionan de forma adecuada, con lo que se reduce la
productividad. TC M 50% 2
El personal contratado no suministra los componentes en el
período establecido. ET M 50% 2
El personal contratado proporciona material de una calidad
inaceptable, por lo que hay que añadir un tiempo extra para
mejorar la calidad. ET M 50% 2
Los requisitos se han adaptado, pero continúan cambiando. PP M 50% 2
Los requisitos no se han definido correctamente. y su
redefinición aumenta el ámbito del proyecto. PP M 50% 2
Se añaden requisitos extra. PP M 50% 2
Se necesitan personas para el proyecto con habilidades muy
específicas y no se encuentran. IO M 50% 2
Las actividades iniciales de control de calidad son
recortadas, haciendo que se tenga que repetir el trabajo. PP M 50% 2
Un retraso en una tarea produce retrasos en cascada en las
tareas dependientes. EP M 50% 3
Las herramientas de desarrollo no están disponibles en el
momento deseado. AI M 50% 3
El cliente insiste en nuevos requisitos. TC M 50% 3
El cliente intenta controlar el proceso de desarrollo, con lo
que el progreso es más lento de lo esperado. TC M 50% 3
Una calidad no aceptable requiere de un trabajo de
comprobación, diseño e implementación superior al
esperado. PP M 50% 3
El personal necesita un tiempo extra para acostumbrarse a
trabajar con herramientas o entornos nuevos. ET M 50% 3
El personal necesita un tiempo extra para acostumbrarse a
trabajar con hardware nuevo. ET M 50% 3
Las personas más apropiadas para trabajar en el proyecto no
están disponibles ET M 50% 3
No hay suficiente personal disponible para el proyecto. ET M 50% 3
El personal trabaja más lento de lo esperado. ET M 50% 3
Las bibliotecas de código o clases tienen poca calidad, y
generan una comprobación extra, corrección de errores y la
repetición de algunos trabajos DI M 50% 3
Los componentes desarrollados por separado no se pueden
integrar de forma sencilla, teniendo que volver a diseñar y
repetir algunos trabajos. DI M 50% 3
Tamaño del producto (TP)
Impacto en la organización (IO)
Tipo de cliente (TC)
Proceso de producción (PP)
Entorno de desarrollo (ED)
Tecnología (T)
Experiencia técnica (ET)
Elaboración de la Planificación (EP)
Organización y Gestión (OG)
Ambiente o Infraestructura (AI)
Usuarios Finales (UF)

4. Asuma que ha sido contratado por una Universidad para desarrollar un sistema de
Generación de Horarios de Cursos para un determinado programa académico. Defina un
listado de tareas. Utilice las diferentes técnicas para establecer una planificación temporal
del proyecto. (PERT o CPM por ejemplo).

Los Sistemas de información representan actualmente una solución organizacional y

administrativa, basada en la tecnología de la información que conlleva a una actitud de
cambio respecto al entorno. Por lo tanto, las entidades y usuarios deben entender que los
sistemas de información son más que las computadoras y que el uso efectivo de estos
sistemas de información requiere de un entendimiento de las organizaciones, de su
administración y de tecnología de información.

Todos los Sistemas de Información pueden ser descritos como soluciones organizacionales
y administrativas para optar por una actitud desafiante respecto al entorno.

Este estudio de caso presenta, de una manera detallada la estructura de los procesos que se
realizan con relación a la elaboración de horarios en la Escuela de Ciencias Básicas
Tecnología e Ingeniería en la UNAD.

Luego del análisis en el que se muestra el estado inicial del sistema, se da a conocer una
descripción del diseño del nuevo sistema de información, adentrándose en las tablas y
procesos incluidas en la aplicación. Las labores de implementación y mantenimiento son
presentadas con las características más relevantes ya que las modificaciones necesarias se
realizaran según cambie el medio donde el sistema realice sus operaciones.

La Ingeniería de Software implica seguir en cualquier proyecto de software una

metodología de desarrollo y la utilización de distintas técnicas y herramientas. Los
diferentes procedimientos a seguir en cualquier proyecto de Ingeniería de software son:
Definición de requerimientos, Análisis, Diseño, Verificación y Validación (Pruebas de
Calidad del Software), Pruebas y Mantenimiento. Cuadro y tabla de congruencia
metodológica Requerimientos y especificaciones para el desarrollo de software.

Listado de Tareas

Desarrollar un módulo para el manejo de la información de los horarios de tutorías y la

disponibilidad de aulas, el cual permitirá almacenar, modificar y presentar la información
pertinente a horarios, previa elaboración y digitación realizada por la persona designada por
la ESCUELA para tal fin.

En la actualidad, la ECBTI de la UNAD realiza procesos el manejo de horarios de tutoría,

de forma manual, apoyados en software que si bien ayuda en cierta medida en la gestión de
la información, no representa una herramienta adecuada con el fin de optimizar el manejo
de la misma.
Al realizar los procesos de forma prácticamente manual, se detectó:

 Falta de información oportuna, debido a un proceso de consulta ineficiente.

 Inconsistencias en la información almacenada debido a la redundancia de los datos
almacenados.
 Acumulación de Trabajo

Las causas que originan dichas situaciones son:

 Falta la integración de la información que se maneja en toda la ESCUELA.

 Los reportes de horarios no cuentan con la información suficiente, provocando

congestiones innecesarias en búsquedas de información.

 Falta aprovechar óptimamente la capacidad inherente de las computadoras para hacer

cálculos, ordenar, recuperar y gestionar la información.
EL PROBLEMA

¿La implementación de un sistema de información que este conformado un módulo de

administración de horarios, agilizará y optimizará el manejo de la información para la
ECBTI de la UNAD?

MODELO DE PROGRAMACION.

Para la elaboración del programas se aplicó el Modelo Espiral cconsiderando la

importancia de la planificación insertando en él, cualquier otro modelo que se requiera
dependiendo de las necesidades que se presenten. Este modelo permite realizar una
planificación del proceso de desarrollo del software considerando los riesgos asociados en
cada etapa identificada. El identificar los riesgos en proyectos, evaluar su impacto,
monitorear y controlar el avance del desarrollo del proyecto, permite al administrador
aumentar las posibilidades de éxito de un proyecto o, minimizar las posibilidades de fracaso
de éste. Se comienza con la recolección de requisitos definiendo el objetivo global del
software e identificando un modelo rápido de lo que se requiere como son los datos de
entrada y el formato de salida, lo importante es que este prototipo, sirve como base para
identificar los requisitos del sistema, en este caso identificar las tablas con las que se va a
interactuar, restricciones en cuanto a qué datos se deben visualizar como salida si son
cálculos o simplemente información, la interfaz a utilizar, el tipo de uso que se le va a dar a
la información, entre otras, luego se comienza la fase de desarrollo, con el fin de traducir el
diseño a un lenguaje de programación, una vez elaborado y codificado el algoritmo del
programa se hacen las respectivas pruebas con el cliente para que verifique si el producto
software satisface sus requerimientos, de no ser así, en base al diseño creado se le
implementa o quita alguna de sus características y nuevamente pasa a la etapa de prueba.
Una vez se encuentre bien se matricula el programa para que pueda ser ejecutado.

FACTIBILIDAD.

A continuación se contemplan los requisitos tecnológicos que ya están satisfechos o

cubiertos para la creación del sistema.

Hardware. Además de los equipos y configuraciones, se tiene instalada la infraestructura

necesaria (capa física de la red) para la configuración de la red interna, requisito para el
desarrollo del proyecto, ya que es necesario compartir recursos e información

Software. En cuanto al software necesario para la realización del proyecto, la UNAD posee
una gran gama de herramientas software y sus respectivas licencias, como son sistemas
operativos, lenguajes de programación, procesadores de texto, hojas electrónicas,
manejadores de bases de datos, y otros.
 CONCLUSIONES.

 Al planear un proyecto se empieza con el resultado final - la meta - y luego se

trabaja hacia atrás a partir de ella.
 Propiciar una visión común hace que cada miembro del equipo del proyecto o del
contingente de trabajo esté orientado en la misma dirección.
 La realización del segundo trabajo colaborativo ayudo a despejar dudas y afianzar
conocimientos.
 Se identifico de manera clara el contenido de la unidad dos.
 Se reconoció la temática de la segunda unidad.
 Se hizo uso de las herramientas sugeridas.
 ANEXOS

Las producciones individuales se realizaron de la siguiente manera:

 Yudis M. Mendoza. No aporta

 Betty Peña. Aporte al tercer caso.
 Derlis Moncaleano. Aporta al primer caso y segundo caso.
 Ana Galindo. No aporta
 Claudia M. Guerra H. Aporta al cuarto caso.
 BIBLIOGRAFIA.

 IAN Sommerville – Ingeniería de software séptima edición – Editorial Pearson Addison

Wesley.
 PRESSMAN Roger S. – Ingeniería de software un enfoque practico, sexta edición.
Editorial Mc Graw Hill.
 PFLEEGER Shari Lawrence. – Ingeniería de software teoría y práctica. – Editorial
Prentice Hall.
 Marcela Varas C., "Apuntes de clases: Gestión de Proyectos de Ingeniería de Software",
Universidad de Concepción, 1998 (en colaboración con Ximena Hormazábal, Luis
Monsalve, Jorge Muñoz, César Olivares, Rodrigo Oviedo y Carmen Wolff).
 Ricardo Contreras, "Apuntes de clases: Ingeniería de Software", Universidad de
Concepción, 1997.