Modulo PD 1 Unidad 1

DESARROLLO DE
PROYECTOS INFORMTICOS
Gua para el estudiante
Elaborado por el formador:
VERNICA FABIANA RINCN CANTOR
INSTITUTO COLOMBIANO DE APRENDIZAJE

INCAP
INSTITUTO COLOMBIANO DE APRENDIZAJE INCAP

DESARROLLO DE PROYECTOS INFORMTICOS
Programa Tcnico Laboral en Sistemas
EL SIGUIENTE MATERIAL SE PREPAR CON FINES

ESTRICTAMENTE ACADMICOS, DE ACUERDO CON EL
ARTCULO 32 DE LA LEY 23 DE 1982, CUYO TEXTO ES EL
SIGUIENTE:
ARTCULO 32:
Es permitido utilizar obras literarias, artsticas o parte de ellas,
a ttulo de ilustracin en obras destinadas a la enseanza, por
medio de publicaciones, emisiones o radiodifusiones, o
grabaciones sonoras o visuales, dentro de los lmites
justificados por el fin propuesto, o comunicar con propsito de
enseanza la obra radiodifundida para fines escolares,
educativos, universitarios y de formacin personal sin fines de
lucro, con la obligacin de mencionar el nombre del autor y el
ttulo de las obras utilizadas.
Desarrollo de
Proyectos Informticos
Instituto Colombiano de Aprendizaje
Elaborado por:
Vernica Fabiana Rincn Cantor
Editado por:
Instituto Colombiano de Aprendizaje INCAP
Avenida Caracas No. 63-66
Prohibida la reproduccin parcial o total

bajo cualquier forma
(Art. 125 Ley 23 de 1982)
Bogot Colombia
2
Versin 01 - Julio 2010
CONTENIDO
PRESENTACIN 5
GUA METODOLGICA 6
UNIDAD UNO
CICLO DE VIDA DEL SOFTWARE 10
ETAPAS DEL CICLO DE VIDA DEL SOFTWARE 11
MODELOS DEL CICLO DE VIDA DEL SOFTWARE 14
Modelo en cascada 15
Modelo en Espiral 16
Modelo Incremental 18
Modelo Evolutivo 20
Modelo Concurrente 21
METODOLOGAS 22
Metodologa CMMI 23
Metodologa ISO 25
Metodologa SCRUM 25
TCNICAS DE RECOLECCION DE DATOS 26
Introspeccin 27
Entrevista Abierta 28
Cuestionario 30
Grupos de Discusin 30
Tormenta de Ideas 31
Entrevistas 32
Observacin 33
FICHA PARA ENTREVISTAS 33
ESPECIFICACION DE REQUERIMIENTOS 37
FORMATO IEEE830 REQUERIMIENTOS 47
UNIDAD DOS
UML 51
3
DIAGRAMAS DE CASO DE USO 52

DIAGRAMAS DE SECUENCIA 55
HERRAMIENTAS CASE 59
MODELO ENTIDAD RELACION 60
CRONOGRAMAS 61
BIBLIOGRAFIA 63
Apreciado estudiante:
Usted escogi al INCAP para que lo oriente en el camino de la formacin profesional. La

institucin le proporcionar un formador, quien le ayudar a descubrir sus propios
conocimientos y habilidades.
El INCAP, le ofrece adems, recursos para que usted alcance sus metas, es decir, lo que se
haya propuesto y para ello dispondr de mdulos gua, audiovisuales de apoyo, sistemas de
evaluacin, aula y espacios adecuados para trabajos individuales y de grupo.
ste mdulo gua que constituye adems un portafolio de evidencias de aprendizaje, est
distribuido de la siguiente manera:
PRESENTACIN: Es la informacin general sobre los contenidos, la metodologa, los

alcances la importancia y el propsito del mdulo.
GUA METODOLGICA: Orienta la prctica pedaggica en el desarrollo del proceso de

formacin evaluacin y se complementa con el documento de la didctica para la formacin
por competencias de manejo del formador.
DIAGNSTICO DE ESTILO DE APRENDIZAJE: Que le permitir utilizar la estrategia ms

adecuada para construir sus propios aprendizajes.
AUTOPRUEBA DE AVANCE: Es un cuestionario que tiene como finalidad que usted mismo
descubra, qu tanto conoce los contenidos de cada unidad, y le sirve de insumo para la
concertacin de su formacin y el reconocimiento de los aprendizajes previos por parte de su
formador (talleres que se encuentran al final de cada unidad).
CONTENIDOS: Son el cuerpo de la unidad y estn presentados as:

Unidad
Logro de competencia laboral
Indicadores de logro: Evidencias
Didctica del mtodo inductivo Activo para el desarrollo de las competencias:
FDH: Formador Dice y Hace,
FDEH: Formador Dice y Estudiante Hace,
EDH: Estudiante Dice y Hace.
VALORACIN DE EVIDENCIAS
BIBLIOGRAFA
4
PRESENTACIN
SENTACIN
Desarrollar un software significa construirlo simplemente

mediante su descripcin. Una de las mayores deficiencias en la
prctica de construccin de software es la poca atencin que se
presta a la discusin del problema. En general los
desarrolladores se centran en la solucin dejando el problema
inexplorado. El problema a resolver debe ser deducido a partir de
su solucin.
El presente mdulo ofrece al estudiante herramientas para

desarrollar un software, donde intervienen muchas personas
como lo es el cliente quien es el que tiene el problema en su
empresa y desea que sea solucionado, para esto existe el
analista quien es el encargado de hacerle llegar todos los
requerimientos y necesidades que tiene el cliente a los
programadores quienes son las personas encargadas de realizar
lo que es la codificacin y diseo del sistema para despus
5
PRESENTACIN
GUA METODOLGICA
probarlo e instalarlo al cliente. Es as como intervienen varias

personas ya que una sola persona no podra determinar todo lo
necesario lo ms seguro que le haga falta algn requerimiento o
alguna parte del nuevo sistema y entre ms estn involucradas
mejor para cubrir con todos los requerimientos del sistema.
La estrategia metodolgica del INCAP, para la formacin tcnica del aprendiz

mediante competencias laborales, comprende dos caminos:
1. Las clases presenciales dictadas por el Formador haciendo uso del mtodo
inductivo activo
2. El trabajo prctico de los estudiantes dirigido y evaluado por el Formador, a travs

de talleres, desarrollo de casos, lecturas y consultas de los temas de clase etc.
Con esto se busca fomentar en el estudiante el anlisis, el uso de herramientas
tecnolgicas y la responsabilidad.
Los mdulos gua utilizados por el INCAP, para desarrollar cada uno de los
cursos, se elaboran teniendo en cuenta sta metodologa. Sus caractersticas y
recomendaciones de uso son:
6
A cada unidad de aprendizaje le corresponde un logro de competencia laboral el

cual viene definido antes de desarrollar su contenido. Seguidamente se definen
los indicadores de logro o sea las evidencias de aprendizaje requeridas que
evaluar el Formador.
Glosario: Definicin de trminos o palabras utilizadas en la unidad que son propias

del tema a tratar.
Desarrollo de la unidad dividida en contenidos breves seguidos por ejercicios,

referenciados as:
FDH (El Formador Dice y Hace): Corresponde a la explicacin del contenido

y el desarrollo de los ejercicios por parte del Formador.
FDEH (El Formador Dice y el Estudiante Hace): El estudiante desarrolla los

ejercicios propuestos y el Formador supervisa.
EDH (El estudiante dice y hace): Es el trabajo prctico que desarrollan los
estudiantes fuera de la clase, a travs de talleres, desarrollo de casos,
lecturas y consultas de los temas, los cuales deben ser evaluados por el
Formador.
Al final de cada unidad se puede presentar un resumen de los contenidos ms

relevantes y ejercicios generales.
DIAGNSTICO
INFORMACIN GENERAL
Regional_____________Programa__________________Mdulo____________
Estudiante_________________________Formador_______________________
EVALUACIN DIAGNSTICA
Estilo de aprendizaje_______________________________________________
7
8
Unidad
Ciclo de Vida y Anlisis de
Uno
1
requerimientos
T E M A S
1. Ciclo de Vida del Software y Metodologas

2. Tcnicas de Recoleccin de Datos
3. Anlisis de requerimientos
Logros de Competencia
1. Conocer el ciclo de vida del software y aplicar tcnicas de recoleccin de

datos (entrevistas, observacin) de acuerdo a los requerimientos del
cliente, elaborar informe de especificacin de requisitos de software
utilizando herramientas informticas segn protocolos y normas.
Indicador de Logro Evidencia de
1. Conoce el ciclo de vida del software y

las metodologas Conocimiento
2. Conoce tcnicas de recoleccin y las
diferentes formas de anlisis y organizacin Conocimiento
3. Elabora propuestas de trabajo de acuerdo
con las necesidades expuestas en los
requerimientos segn normas y protocolos Producto 9
10
El Formador Dice y Hace:
1. Ciclo de vida del software
Software: procedimientos y reglas lgicas escritas en la forma de

programas y aplicaciones, que definen el modo de operacin de la
computadora. Es la suma total de los programas de computadora,
procedimientos, reglas, la documentacin asociada y los datos que
pertenecen a un sistema de cmputo.
Aplicacin: es un tipo de programa informtico diseado como
herramienta para permitir a un usuario realizar uno o diversos tipos
de trabajo. Ciertas aplicaciones desarrolladas 'a medida' suelen
ofrecer una gran potencia ya que estn exclusivamente diseadas
para resolver un problema especfico.
Desarrollo de Software: es aquel en que las necesidades del
usuario son traducidas en requerimientos de software, estos
requerimientos transformados en diseo y el diseo implementado
en cdigo, el cdigo es probado, documentado y certificado para su
uso operativo". Concretamente "define quin est haciendo qu,
cundo hacerlo y cmo alcanzar un cierto objetivo:
Ciclo de Vida: Un modelo de ciclo de vida define el estado de las
fases a travs de las cuales se mueve un proyecto de desarrollo de
software. Desde la fase inicial hasta la fase final. El propsito es
definir las distintas fases intermedias que se requieren para validar
el desarrollo de la aplicacin, es decir, para garantizar que el
software cumpla los requisitos para la aplicacin y verificacin de
los procedimientos de desarrollo: se asegura de que los mtodos
utilizados son apropiados.
INSTITUTO COLOMBIANO DE APRENDIZAJE INCAP

Desarrollo de Proyectos Informticos
2. ETAPAS DEL CICLO DE VIDA DEL SOFTWARE
Necesidades: esta etapa tiene como objetivo

la consecucin de un primer documento en que
queden reflejados los requerimientos y
funcionalidades que ofrecer al usuario del
sistema a desarrollar (qu, y no cmo, se va a
desarrollar).
Dado que normalmente se trata de

necesidades del cliente para el que se crear la
aplicacin, el documento resultante suele tener
como origen una serie de entrevistas cliente-
proveedor situadas en el contexto de una
relacin comercial, siendo que debe ser
comprendido por ambas partes (puede incluso
tomarse como base para el propio acuerdo
comercial).
Especificaciones: Por medio de esta etapa se

obtendr un nuevo documento que definir con
ms precisin el sistema requerido por el
cliente.
Lo ms normal ser que no resulte posible

obtener una buena especificacin del sistema a
la primera; sern necesarias sucesivas
versiones del documento en que irn quedando
reflejada la evolucin de las necesidades del
cliente (por una parte no siempre sabe en los
primeros contactos todo lo que quiere
realmente, y por otra parte pueden surgir
cambios externos que supongan
requerimientos nuevos o modificaciones de los
ya contemplados).
12
Anlisis: Es necesario determinar qu

elementos intervienen en el sistema a
desarrollar, as como su estructura, relaciones,
evolucin en el tiempo, detalle de sus
funcionalidades, ... que van a dar una
descripcin clara de qu sistema vamos a
construir, qu funcionalidades va a aportar y
qu comportamiento va a tener
Diseo: Tras la etapa anterior ya se tiene claro

que debe hacer el sistema, ahora tenemos que
determinar cmo va a hacerlo (cmo debe ser
construido el sistema?; aqu se definirn en
detalle entidades y relaciones de las bases de
datos, se pasar de casos de uso esenciales a
su definicin como casos expandidos reales, se
seleccionar el lenguaje ms adecuado, el
Sistema Gestor de Bases de Datos a utilizar en
su caso, libreras, configuraciones hardware,
redes, etc.).
Implementacin: Llegado este punto se

empieza a codificar algoritmos y estructuras de
datos, definidos en las etapas anteriores, en el
correspondiente lenguaje de programacin y/o
para un determinado sistema gestor de bases
de datos.
Pruebas: el objetivo de estas pruebas es

garantizar que el sistema ha sido desarrollado
correctamente, sin errores de diseo y/o
programacin. Es conveniente que sean
planteadas al menos tanto a nivel de
cada mdulo (aislado del resto), como
13
de integracin del sistema (segn sea la

naturaleza del proyecto en cuestin se podrn
tener en cuenta pruebas adicionales, p.ej. de
rendimiento).
Validacin: Esta etapa tiene como objetivo la

verificacin de que el sistema desarrollado
cumple con los requisitos expresados
inicialmente por el cliente y que han dado lugar
al presente proyecto (para esta fase tambin es
interesante contar con los use cases, generados
a travs de las correspondientes fases previas,
que servirn de gua para la verificacin de que
el sistema cumple con lo descrito por estos).
Mantenimiento y Evolucin: Finalmente la

aplicacin resultante se encuentra ya en fase de
produccin (en funcionamiento para el cliente,
cumpliendo ya los objetivos para los que ha sido
creada). A partir de este momento se entra en la
etapa de mantenimiento, que supondr ya
pequeas operaciones tanto de correccin como
de mejora de la aplicacin (p.ej. mejora del
rendimiento), as como otras de mayor
importancia, fruto de la propia evolucin (p.ej.
nuevas opciones para el usuario debidas a
nuevas operaciones contempladas para el
producto).
14
El Formador Dice y el estudiante Hace:
3. MODELOS DEL CICLO DE V IDA DEL SOFTWARE
Un modelo de ciclo de vida de software es una vista de las actividades que

ocurren durante el desarrollo de software, intenta determinar el orden de
las etapas involucradas y los criterios de transicin asociadas entre estas
etapas.
Un modelo de ciclo de vida del software:
Describe las fases principales de desarrollo de software.
Define las fases primarias esperadas de ser ejecutadas durante esas

fases.
Ayuda a administrar el progreso del desarrollo, y
Provee un espacio de trabajo para la definicin de un detallado proceso

de desarrollo de software.
As, los modelos por una parte suministran una gua para los
desarrolladores de software con el fin de ordenar las diversas actividades
tcnicas en el proyecto, por otra parte suministran un marco para la
administracin del desarrollo y el mantenimiento, en el sentido en que
permiten estimar recursos, definir puntos de control intermedios, monitorear
el avance, etc.
15
3.1. MODELO EN CASCADA
Es un modelo base para los dems modelos. Fue definido por Royce y se
trata principalmente de que se debe completar un paso correctamente sin
ningn error para pasar al siguiente.
Caractersticas del modelo cascada

Este modelo muestra de una forma bsica el desarrollo de software, y
representa en fases separadas procesos fundamentales.
Dice que se debe probar el software despus de construirlo y antes de
operarlo. Cada fase tiene como salida documentacin.
Fases del Modelo Cascada
Las fases son:

Ingeniera y Anlisis del Sistema: establece requisitos de los
elementos del sistema.
Anlisis de los requisitos del software: identifica las funciones del
software, el rendimiento, sus interfaces y la informacin.
16
Diseo: se basa en estructura de datos, arquitectura del software el

detalle de los procedimientos y la caracterizacin de la interfaz.
Adems escoge las herramientas para la codificacin.
Codificacin: el diseo se traduce en lenguaje de mquina.
Pruebas: Aqu se comprueba si existe algn error con el software o
si funciona correctamente. Hasta que sea aceptado por el usuario.
Mantenimiento: esta fase se da debido a que despus de la entrega
pudo haber errores en el software, o el software no se adapte al
entorno externo o que el cliente requiera ampliaciones funcionales o
de rendimiento.
VENTAJA
Este modelo como es sencillo solo utiliza los pasos intuitivos para
desarrollar software, adems es fcil de explicarlo al cliente.
DESVENTAJAS
Los proyectos raramente siguen el flujo secuencial, hay iteraciones
El cliente no puede establecer al principio todos los requisitos.
El cliente deber tener paciencia pues la versin operativa del
producto solo estar disponible en las ltimas etapas del proyecto.
3.2. MODELO EN ESPIRAL
Es una serie de ciclos los cuales se repiten en forma de espiral, cada vez
que se avanza un ciclo se va alcanzando un nivel superior hasta concluir el
proyecto.
Lo caracterstico de este modelo es que incluye un anlisis de riesgo es
decir que podemos analizar si el proyecto puede continuar o mejor lo
suspendemos.
Este modelo se basa en que antes de hacer algo debemos analizarlo,
tambin debemos buscar varias opciones de resolucin de problemas para
de all escoger la opcin ms conveniente, y adems analizar los riesgos
que se pueda tener. Este modelo necesita de otro para poder desarrollarse.
Se debe escoger el modelo cascada cuando se pierda el control del
17
presupuesto o por el calendario; y el de prototipeo cuando tengamos

problemas con la interfaz.
El modelo espiral consta de 4 cuadrantes que son sus fases y se dividen de

la siguiente forma:
1.- Planificacin
2.- Anlisis de Riesgos
3.- Ingeniera
4.- Evaluacin
En cada vuelta o iteracin hay que tener en cuenta
Los Objetivos: Que necesidad debe cubrir el producto.
Alternativas: Las diferentes formas de conseguir los objetivos de forma

exitosa, desde diferentes puntos de vista como pueden ser:
1. Caractersticas: experiencia del personal, requisitos a cumplir, etc.

2. Formas de gestin del sistema.
3. Riesgo asumido con cada alternativa.
18
VENTAJAS
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida
del software de computadora.
Como el software evoluciona a medida que progresa el proceso, el
desarrollador y el cliente comprenden y reaccionan mejor ante riesgos
en cada uno de los niveles evolutivos.
El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de
construccin de prototipos en cualquier etapa de evolucin del producto.
El modelo en espiral demanda una consideracin directa de los riesgos
tcnicos en todas las etapas del proyecto y si se aplica
adecuadamente debe reducir los riesgos antes de que se
conviertan en problemas
DESVENTAJAS
Resulta difcil convencer a grandes clientes de que el enfoque evolutivo
es controlable.
Debido a su elevada complejidad no se aconseja utilizarlo en pequeos
sistemas.
Genera mucho tiempo en el desarrollo de sistemas.
1.3. MODELO INCREMENTAL
19
El desarrollo incremental es el proceso de construccin siempre

incrementando subconjuntos de requerimientos del sistema. En una visin
genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y
Prueba. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento. Es el mismo cliente el que incluye
o desecha elementos al final de cada incremento a fin de que el software se
adapte mejor a sus necesidades reales. El proceso se repite hasta que se
elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros mtodos de modelado, el Modelo Incremental es de

naturaleza interactiva pero se diferencia de aquellos en que al final de cada
incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente til cuando no se cuenta con una

dotacin de personal suficiente. Los primeros pasos los pueden realizar un
grupo reducido de personas y en cada incremento se aadir personal, de
ser necesario. Por otro lado los incrementos se pueden planear para
gestionar riesgos tcnicos.
Ventajas:
Con un paradigma incremental se reduce el tiempo de desarrollo inicial,
ya que se implementa la funcionalidad parcial.
Tambin provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del Software.
El modelo proporciona todas las ventajas del modelo en cascada
realimentado, reduciendo sus desventajas slo al mbito de cada
incremento.
Permite entregar al cliente un producto ms rpido en comparacin del
modelo de cascada.
Resulta ms sencillo acomodar cambios al acotar el tamao de los
incrementos.
Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel
administrativo como tcnico.
20
Desventajas:
El modelo Incremental no es recomendable para casos de sistemas de
tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o
de alto ndice de riesgos.
Requiere de mucha planeacin, tanto administrativa como tcnica.
Requiere de metas claras para conocer el estado del proyecto.
1.4. MODELO EVOLUTIVO
El modelo de desarrollo evolutivo (algunas veces denominado como

prototipado evolutivo) construye una serie de grandes
versiones sucesivas de un producto. El modelo evolutivo asume que,
los requerimientos son cuidadosamente examinados, y slo esos que
son bien comprendidos son seleccionados para el primer incremento.
Los desarrolladores construyen una implementacin parcial del sistema
que recibe slo estos requerimientos.
21
El sistema es entonces desarrollado, los usuarios lo usan, y proveen

retroalimentacin a los desarrolladores. Basada en esta
retroalimentacin, la especificacin de requerimientos es actualizada, y
una segunda versin el producto es desarrollada y desplegada. El
proceso se repite indefinidamente
Desventajas
El proceso no es visible. Se tienen que hacer entregas regulares
para medir el progreso.
Si los sistemas se desarrollan rpidamente es muy costoso
producir documentos que reflejen cada versin
Los sistemas tienen una estructura deficiente, tendiendo a daar
la estructura del software
Se requieren tcnicas y herramientas especiales, permiten un
desarrollo rpido pero suelen ser incompatibles con otras
herramientas o tcnicas
1.5. MODELO CONCURRENTE
Es un modelo de tipo de red donde todas las personas actan

simultneamente o al mismo tiempo. Por ejemplo, el personal est
escribiendo requisitos diseando, codificando, haciendo pruebas y
probando la integracin (todo al mismo tiempo). El modelo de proceso
22
concurrente se puede representar en forma de esquema como una serie

de actividades tcnicas importantes, tareas y estados asociados a ellas.
Orientada a integrar sistemticamente y en forma simultnea el diseo

de productos y procesos, para que sean considerados desde un
principio todos los elementos del ciclo de vida de un producto, desde la
concepcin inicial hasta su disposicin final. Debe otorgar adems una
organizacin flexible y bien estructurada, proponer redes de funciones
apoyadas por tecnologas apropiadas y arquitecturas comunes de
referencia (ej: computadores en red y en bases de datos).
Los objetivos globales que se persiguen con la implementacin de la IC

son:
1. Acortar los tiempos de desarrollo de los productos.

2. Elevar la productividad.
3. Aumentar la flexibilidad.
4. Mejor utilizacin de los recursos.
5. Productos de alta calidad.
6. Reduccin en los costos de desarrollo de los productos.
Ventajas
Excelente para proyectos en los que se conforman grupos de trabajo
independientes.
Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas
Si no se dan las condiciones sealadas no es aplicable.
Si no existen grupos de trabajo no se puede trabajar en este mtodo
2. METODOLOGAS
Conjunto de procedimientos, tcnicas, herramientas y un soporte

documental que ayuda a los desarrolladores a realizar nuevo software
23
Tarea: actividades elementales en que se dividen los procesos
Procedimiento: definicin de la forma e ejecutar la tarea
Tcnica: herramienta utilizada para aplicar un procedimiento
Herramienta: para realizar una tcnica, podemos apoyarnos en las

herramientas software que automatizan sus aplicacin.
Producto: resultado de cada etapa.
METODOLOGA VS CICLO DE VIDA
Una metodologa puede seguir uno o varios modelos de ciclo de vida, es

decir, el ciclo de vida indica qu es lo que hay que obtener a lo largo del
desarrollo del proyecto pero no cmo hacerlo.
La metodologa indica cmo hay que obtener los distintos productos

parciales y finales
CARACTERSTICAS DE UNA METODOLOGA
Existencia de reglas predefinidas

Cobertura total del ciclo de desarrollo
Verificaciones intermedias
Planificacin y control
Comunicacin efectiva
Utilizacin sobre un abanico amplio de proyectos
Fcil formacin
Herramientas CASE
Actividades que mejoren el proceso de desarrollo
Soporte al mantenimiento
Soporte de la reutilizacin de software
METODOLOGA CMMI: El modelo CMMI proporciona un marco para la

mejora de procesos que pueden ayudar a una organizacin en la mejora
24
de sus procesos y su habilidad para desarrollar, adquirir y mantener sus

productos y servicios.
El uso de estas metodologas ofrece a las Organizaciones un

instrumento til para la sistematizacin de las actividades que dan
soporte al Ciclo de Vida del Software, estableciendo unas pautas de
trabajo que permiten alcanzar los siguientes objetivos:
Proporcionar o disear Sistemas de Informacin que ayuden a

conseguir los fines de la Organizacin mediante la definicin de un
marco estratgico para el desarrollo de los mismos.
Dotar a la Organizacin de Productos Software que satisfagan las
necesidades de los usuarios dando una mayor importancia al Anlisis de
Requisitos.
Facilitar la comunicacin y entendimiento entre los distintos participantes

en la produccin de software a lo largo del Ciclo de Vida del Proyecto,
teniendo en cuenta su papel y responsabilidad, as como las
necesidades de todos y cada uno de ellos.
Se contempla el desarrollo de Sistemas de Informacin para las distintas

tecnologas que actualmente estn conviviendo y los aspectos de
Gestin de Proyectos que aseguran el cumplimiento de sus objetivos
en trminos de calidad, coste y plazos
Soluciones:
Compromiso asegurado
Automatizar lo ms posible las actividades de control y gestin de los
procesos de los proyectos
Comenzar a documentar los procesos implcitos, en la medida de lo
posible o plantillas en office, implementacin de sistemas de gestin
Utilizacin de sistemas libres para minimizar los costos de
implementacin
Problemtica:
Requiere mucho esfuerzo, compromiso de toda la organizacin
Comenzar a disear y/o documentar procesos, luego desplegarlos y
ponerlos en prctica
25
Requiere un mnimo de cantidad de personal (no menos de 10

personas en la prctica)
Fuerte inversin econmica
METODOLOGIA ISO: Las series de ISO 9000 son un grupo de 5
individuales, pero relacionadas, estndares internacionales de
administracin de la calidad y aseguramiento de calidad.
ISO 9001:2000 sistemas de Gestin Requisitos
ISO 9004:2000 Sistemas de Gestin de la Calidad Gua de mejoras
del funcionamiento
ISO 9001:2000 es la norma que contiene los requisitos que debe cumplir
una organizacin para la implementacin de un Sistema de Gestin.
ISO 9000-3: dedicada al proceso de desarrollo con calidad del software.
Gua para la aplicacin para el desarrollo, implementacin y
mantenimiento de software.
Beneficios de la Norma:
Mejor documentacin de los sistemas
Cambio cultural positivo
Incremento en la eficiencia y productividad
Mayor percepcin de calidad
Se ampla la satisfaccin del cliente
Se reducen las auditoras de calidad de los clientes
Agiliza el tiempo de desarrollo de un sistema.
ISO 12207
Esta norma esta orientada a los procesos de ciclo de vida del software
de la organizacin ISO.
Establece un proceso de ciclo de vida para el software que incluye
procesos y actividades que se aplican desde la definicin de requisitos,
pasando por la adquisicin y configuracin de los servicios del sistema,
hasta la finalizacin de su uso.
METODOLOGIA SCRUM: Esta metodologa se basa en una filosofa del

desarrollo gil de software. Lo interesante es que si un integrante del
equipo se cae se viene abajo todo el equipo as que deben de estar
coordinados para que todos vayan a la misma velocidad.
Esta metodologa est basada entre muchas bajo estas premisas:

a) Los individuos por encima de los procesos y herramientas
b) En entregar soluciones por encima de reportes de seguimiento.
c) A dar respuesta a los cambios en lugar de ceirse a seguir un plan
26
Debe de haber una cohesin de equipo fuerte, porque el triunfo de un

hito no es el triunfo de un solo jugador sino de todo el equipo, l mismo
entrega el resultado. Todos colaboramos para obtener el triunfo y
empujamos al que no est caminando como se debe.
Se centra en presentar al cliente la solucin que l pueda operar y usar,
no solamente en entregar un reporte de lo que se ha hecho, de esta
forma el cliente ve el progreso y puede decir cuando o no parar. Esto es
una fortaleza ya que la mayora est acostumbrada a un plan y el
resultado lo ve al final del proyecto.
Con la metodologa SCRUM el cliente va viendo el resultado del
producto y decide si sigue o termina el producto en ese momento. O
inclusive tan radical como se escucha darle un giro completo.
El Estudiante Dice y Hace:
1. El estudiante Investigar informacin sobre la certificacin CMM,

organizaciones de software con certificacin CMM. Tamao, Tiempo
requerido para lograr la certificacin y costo
2. El estudiante elaborara un cuadro comparativo de los modelos de ciclo
de vida del software indicando (concepto, ventajas, desventajas y
proyectos a utilizar.
TCNICAS DE RECOLECCION DE DATOS
La solucin de un problema complejo, normalmente implica satisfacer las

necesidades de diversos grupos de inters. Estos grupos pueden ser
divididos en clientes y usuarios: Un cliente es una persona que tiene
influencia sobre los requerimientos del sistema aunque no vaya a ser un
usuario del mismo, mientras que los usuarios son las personas o grupos
de personas que van a interactuar directamente con el sistema.
27
Entender las necesidades de clientes y usuarios es una parte fundamental

de un proyecto. Para entender las necesidades de estas personas hay
que empezar por identificarlos. Algunas preguntas que podemos hacer
para ayudarnos en esta labor son:
Cules sern los diferentes roles organizacionales que usaran el

sistema?
Quin va a pagar por el sistema?
Qu otra persona se ver afectada por las salidas que el sistema
produce?
Quin es responsable de evaluar y aceptar el sistema cuando se libere?
Quin ser responsable de darle mantenimiento al sistema?
Una vez que hemos identificado a los clientes y usuarios podemos aplicar
varias tcnicas para identificar cules son sus necesidades. La siguiente
seccin describe esas tcnicas y algunas herramientas que ayudan a
entender cules son las necesidades de los usuarios respecto al sistema
que se va a construir.
INTROSPECCIN:
La introspeccin es el medio ms obvio y comnmente usado para
entender los requerimientos de un sistema. Consiste en estudiar el
ambiente del usuario para posteriormente tratar de imaginar qu es lo que
me gustara que hiciera el sistema si yo estuviera a cargo de hacer el
trabajo con su ayuda.
Esta tcnica es til pero hay que considerar que la experiencia de un

analista de sistemas es muy diferente que la experiencia de los usuarios
potenciales del software y por lo tanto es difcil que las conclusiones del
analista reflejen la experiencia de las personas que hacen la tarea da con
da.
Esto se hace ms evidente en el diseo de la interfaz grfica del usuario,

lo que para un analista es el comportamiento comn de un software,
puede resultar confuso o frustrante para un usuario. Tradicionalmente,
28
debido a las limitaciones grficas que anteriormente tenan las

computadoras, se creaba una brecha entre el diseo de la aplicacin y las
necesidades de uso del usuario, sin embargo debido a la evolucin de los
ambientes grficos el paradigma est cambiando: La obligacin del
usuario no es aprender a dominar una tecnologa, es la tecnologa la que
debe ayudar al usuario a hacer su trabajo. La explosin del Internet ha
creado nuevas especialidades como user experience en las cuales la
psicologa y la sociologa son las principales herramientas cientficas.
La recomendacin, cuando se usa la introspeccin, es apoyarla con la

informacin previa que generan otras tcnicas como por ejemplo la
entrevista abierta. En cualquier caso es recomendable validar cualquier
duda con un experto de dominio. Los expertos de dominio son personas
con mucha experiencia en un rea particular del negocio que es de
inters para el sistema. Por ejemplo, en el caso de una lnea de
produccin, el operador de alguna mquina de la lnea puede ser un
experto de dominio que aporte valiosa informacin para la automatizacin
del proceso.
ENTREVISTA ABIERTA
Con los objetivos en mente, se saca la lista de datos que quiero

conseguir y que fuentes son las mas adecuadas para
proporcionrmelos. Segn lo anterior decido que instrumento me
conviene.
Una de las principales consideraciones a tomar en cuenta en una
entrevista es lograr que la predisposicin del entrevistador no influya en el
29
resultado de la narrativa capturada. Como proveedores de soluciones,

estamos acostumbrados a identificar soluciones al mismo tiempo que
escuchamos problemas, cuando hacemos esto, tendemos a influenciar
las respuestas del entrevistado, provocando una mala comprensin del
problema o una reduccin en el grado de libertad de la solucin.
Una entrevista debe considerar preguntas libres de contexto (Gausse and
Weinberg, 1989), es decir, preguntas que no influencien las respuestas de
los entrevistados hacia las respuestas que queremos or. Por ejemplo:
Quines son los usuarios del sistema?
Qu problemas tienen actualmente?
Cules son sus necesidades respecto a la solucin?
Algunos consejos que pueden ayudarnos durante una entrevista:

No hagas preguntas donde se suponga de antemano que la gente puede
describir actividades complejas.
En general la gente puede hacer muchas cosas que no puede describir.
Cuando necesites entender una actividad compleja separa la pregunta en
varias partes o utiliza otra tcnica como la investigacin de campo.
Haz preguntas abiertas que le permitan al usuario extenderse en sus
respuestas y a ti comprender mejor su problemtica.
No hagas preguntas que influencien la respuesta del entrevistado: Usted
necesita una pantalla para realizar esta tarea, verdad?
No hagas preguntas para controlar la conversacin: Podemos regresar a
la pregunta anterior?
No hagas preguntas que se respondan as mismas: 50 elementos en
esta lista son suficientes, verdad?
Evita preguntas que empiecen con Por qu?. Habitualmente estas
preguntas ponen al entrevistado a la defensiva porque aparentan
cuestionar la manera en que hace su trabajo.
No esperes respuestas sencillas. Cuando las obtengas sigue
preguntando para descubrir ms ruinas enterradas.
No apures al entrevistado para que responda. Si haces esto
probablemente no querr responder tu prxima pregunta.
Por ltimo lo ms importante: Escucha con atencin.
30
CUESTIONARIO
Consisten en una serie de preguntas que el entrevistador hace de manera

secuencial o que se entregan al entrevistado para que l mismo conteste.
Los cuestionarios tienen la deficiencia de que no utilizan los elementos de

interaccin de la entrevista, por lo tanto se corre el riesgo de que, dado
que la persona a la que se entrevista tiene diferente historia y por lo tanto
diferentes conocimientos y categoras para clasificar los conceptos,
algunas preguntas se malinterpreten o resulten irrelevantes y fuera de
contexto.
GRUPOS DE DISCUCIN
Para tener una visin general y rpida de lo que un grupo de personas

piensa, puede usar un grupo de discusin. En estos grupos, a manera de
pltica informal un moderador hace la entrevista para encontrar la
informacin deseada.
Consiste en involucrar a los usuarios en el proceso de desarrollo mediante

talleres o workshops en los cuales se identifican los requerimientos. En
los talleres pueden utilizarse diferentes tcnicas para ir descubriendo
requerimientos como "Casos de Uso", "Story Boards", "Modelos" o
"Prototipos".
Los grupos de desarrollo tienen el inconveniente de que no son

comunidades naturales, por lo tanto es difcil que los participantes
compartan categoras. Otro riesgo en estos talleres es que, dadas las
31
jerarquas que existen dentro de una empresa, alguno de los participantes

puede no sentirse libre para expresar su opinin o puede sentirse
obligado a dar una opinin sobre un punto que desconoce o en el que l
no es experto.
Algunas recomendaciones para conducir un grupo de desarrollo

son:
Da a todos la oportunidad de hablar. Esto es esencial para que el

workshop se considere imparcial.
Procura que la sesin se mantenga andando. Existe una tendencia

natural a que el workshop se convierta en una sesin de quejas.
Identifica los problemas/requerimientos pero no profundices. Una vez que
se ha identificado un problema/requerimiento avanza al siguiente.
Permanece alerta para recoger informacin y hallazgos.
Al final, resume la sesin y trabaja en generar conclusiones
TORMENTA DE IDEAS
La Tormenta de Ideas consiste en listar todas las ideas sobre un tema que
se le ocurren a un auditorio determinado y posteriormente filtrarlas,
desarrollarlas y priorizarlas.
Una sesin de este tipo comienza con la aclaracin del objetivo. El

objetivo es muy importante porque permite mantener en foco la sesin, sin
embargo no debe de ser limitante para la creatividad de las ideas
expresadas, es ms las ideas ms descabelladas pueden resultar en
soluciones innovadoras. Los participantes deben de aportar ideas sin
interrupcin y tantas como sea posible, para lograr esto, el moderador
debe crear un ambiente en el que la creatividad y la apertura de mente
tengan un lugar prioritario, por ejemplo evitando crticas o debates durante
la aportacin de ideas.
Cuando las ideas comienzan a repetirse y los participantes empiezan a

demorarse mucho tiempo entre idea e idea, es momento de suspender la
sesin y pasar a filtrar, combinar, ordenar y priorizar las ideas. Al hacer
32
esto, es necesaria la participacin del grupo mediante debates y

consensos. El moderador debe de evitar que la discusin se vuelva
personal o que los debates se prolonguen demasiado, esto puede
lograrse usando rondas de votacin con prioridades, en las cuales a los
miembros se les da una cantidad de puntos que deben distribuir entre las
diferentes opciones, nunca asignado ms del 50% de sus puntos a una
opcin. Al final se suman los puntos y la opcin con ms puntos resulta
ganadora.
ENTREVISTA:
Es una serie de preguntas que puede realizarse personalmente, por

telfono, correo o por correo electrnico. Segn su diseo estas pueden
ser:
Estructurada: es un cuestionario con preguntas que requieren

seleccin de una sola respuesta.
Semi-estructurada: contiene preguntas de seleccin y preguntas
abiertas.
OBSERVACIN
33
A veces UD preferir observar la conducta de personas, objetos y

sucesos o algn fenmeno de inters, en forma directa.
La observacin puede hacerse de la siguiente manera:
Estructurada: se especifica previamente lo que se va a observar y

como se va a registrar la observacin
No estructurada: El observador anota todos los aspectos que le
parezcan importantes es ms exploratoria.
FICHA PARA ENTREVISTAS
Informacin del Proyecto
Proyecto: NOMBRE DEL PROYECTO
Entrevistador(es): NOMBRE DE LA PERSONA(S)
Entrevistado(s): NOMBRE DE LA PERSONA(S)
Fecha de la Entrevista: FECHA
Lugar de la Entrevista: LUGAR
34
Documentos Propuesta del Proyecto > Pblico

Relacionados: objetivo y beneficios
Glosario de trminos
TAREAS: Copie este archivo por cada entrevista hecha.
COmplete los detalles. Haga una liga de este archivo a la
seccin de "Notas de Entrevistas y Lluvias de Ideas" de user-
needs.html.
Impacto del proceso: La planeacin de preguntas para las entrevistas
con inversionistas es la clave para un levantamiento de datos efectivo.
Los buenos requerimientos son necesarios para construir el sistema
correctamente. Estas notas debern ser guardadas como parte de la
documentacin en requerimientos del usuario para ser referenciadas
cuando la especificacin de requerimientos de software sea redactada o
actualizada.
Preguntas y Respuestas de la Entrevista
TAREAS: Antes de la entrevista, planee las preguntar que va a

hacer. Despus, escriba las respuestas que recibi y cualquier
otra pregunta o respuesta adicional que pueda surgir.
Cmo se dio cuenta de la necesidad de este producto?
RESPUESTA
Qu tipos de usuarios podran utilizar este producto?
RESPUESTA
Podra dar un ejemplo de cmo un usuario podra utilizar el
producto?
RESPUESTA
Existe algn riesgo por utilizar este producto?
RESPUESTA
PREGUNTA1
RESPUESTA1
PREGUNTA2
RESPUESTA2
PREGUNTA3
RESPUESTA3
PREGUNTA4
RESPUESTA4
Otras Notas de la Entrevista
TAREAS: Anote todo lo dems que haya surgido de la entrevista,

ya sea explcita o implcitamente. Recuerde confirmar los datos
que recab implcitamente si tuviera dudas sobre ellos. Por
ejemplo, tome notas de que el entrevista utiliza un significado
poco usual para cierto trmino. Aada ligas a cualquier
documento que le entregue el entrevistado.
NOTA
35
NOTA
NOTA
Lista de Pendientes de la Entrevista
Antes de la entrevista
1. Decida que objetivos desea cumplir
2. Prepare una lista de preguntas
Pregunte sobre las cosas que conoce y que desea
conocer, basado en su entendimiento actual de los requerimientos
Mantenga las preguntas simples. No utilice preguntas con
muchas partes, rompa los temas complejos en preguntas individuales.
Confirme las suposiciones ms importantes. Por ejemplo:
"Ud. es la persona que utilizar este programa, cierto?" "El total
necesita ser impreso y actualizado por cada elemento que se
escanea, verdad?"
Evite sugerir o hacer preguntas de muchas partes, porque
la respuesta correcta podra ser una que Ud. no conozca todava. Por
ejemplo, INCORRECTO: "Ud. entrara al sistema desde su escritorio
aqu o desde su casa?" CORRECTO: "Cules son algunos de los
lugares de donde entrara al sistema?" "Desde aqu en mi oficina,
pero tambin cuando trabajo con otras personas algunas veces me
conecto desde las computadoras en sus oficinas o desde una
computadora en el laboratorio o en la sala de juntas... as que no
quisiera una cookie guardada aqu."
Trate de encontrar la prioridad para cada requerimiento:
esencial, esperado, deseado u opcional.
Escriba ms preguntas abiertas para ver si nuevos
requerimientos de importancia salen a la luz.
No haga muchas preguntas que parezcan fuera del tema.,
podra accidentalmente cambiar el enfoque o hacer especulaciones
incorrectas. Por ejemplo, "Le gustara que el sistema hiciera tambin
estas otras diez caractersticas?" "Claro!"
3. Seleccione a los entrevistados que representen a todos los
inversionistas importantes.
4. Revise sus preguntas. Cree que pueden ser contestadas? Le
ayudarn a alcanzar sus objetivos? Si no es as, redctelas de nuevo.
5. Decida si desea hacer esta entrevista va email, telfono o en
persona
6. Programe una entrevista segn la conveniencia del entrevistado.
Planee que la entrevista dure no ms de una hora.
Durante la entrevista
1. Sea atento, corts y profesional
36
2. Presntese Ud. mismo y explique por qu est Ud. ah.

3. ASegrese que est entrevistando a la persona que fue a
entrevistar. Consiga su informacin de contacto (por ejemplo, su
direccin de email) si an no la tiene.
4. Pida permiso para tomar notas. No grabe en cinta o video.
5. Confirme el tiempo disponible con el que cuentan Ud. y el
entrevistado para esta sesin.
6. D una indicacin rpida del tipo y nmero de preguntas
que va a hacer
7. Haga todas las preguntas.
8. Escuche. Es para eso que esta Ud. ah.
9. Si el entrevistado se refiere a documentos existente,
sistemas, equipo o personas, asegrese de entender de el o
ella est hablando. Si es importante, pregunte si puede
conseguir una copia o una pantalla (pero no solicite nada que
pueda ser confidencial), o tome nota de los aspectos
importantes de los elementos a los que se refiere. Apunte las
URLs de cualquier sitio web pblico existente que salga en la
entrevista.
10. Intente no responder las preguntas Ud. mismo, o
reaccionar a las solicitudes del entrevistado haciendo
promesas de resolver sus problemas. La entrevistas son para
entender los problemas, no para resolverlos o programar
fechas de entrega.
11. Anote los elementos de los puede obtener ms
informacin ms tarde. Por ejemplo, si el entrevistado
empieza a explicarle con detalle algo que Ud. sabe que puede
aprender por su cuenta, o si el entrevistado no conoce la
respuesta y empieza a especular, debera intentar seguir con
la siguiente pregunta.
12. Si se da cuenta que ha preparado mal las preguntas,
concntrese en obtener informacin que le ayudar a preparar
las siguientes preguntas correctamente.
13. Termine puntualmente. Si necesita ms tiempo contine
via email o en una reunin posterior.
14. Resuma los elementos de accin que investigar ms
tarde
15. Pregunte si el entrevistado tiene preguntas para Ud., o si
hay algo ms que desea que Ud. le pregunte.
16. Asegrese de dejar sus datos de contacto
17. Agradezca al entrevistado por su tiempo
37
Despus de la entrevista
1. En las primeras 24 horas, lea sus notas y complete los
detalle importantes que fueron mencionados pero que no
anot
2. Capture sus notas para que las pueda compartir con su
equipo y archivadas
3. Formule cualquier pregunta importante que desee hacer
despus
4. Dentro de 2 o 3 das despus, enve un mensaje por
email para
Agradecer al entrevistado de nuevo
Confirmar que tiene la direccin de correo correcta,
y facilitar a sus entrevistados la comunicacin con Ud.
Pregunte cualquier pregunta que tenga an
El Estudiante Dice y
Hace:
1. El estudiante deber entrevistarse con su cliente y desarrollar la
ficha anterior, realizar como mnimo 3 entrevistas
2. El estudiante realizara un informe indicando que tipos de
recoleccin de datos realiz y mostrando los resultados de cada uno.
ESPECIFICACION DE REQUERIMIENTOS
El correcto manejo de los requerimientos es un factor del que depende

el xito del proyecto.
Un requerimiento es una condicin o capacidad que el sistema debe
cumplir
De forma ms refinada
Una capacidad del sistema requerida por el usuario para resolver
un problema o alcanzar un objetivo
Capacidad que el sistema debe poseer o brindar a fin de
satisfacer un contrato, especificacin, estndar o alguna otra
documentacin formalmente impuesta
38
De manera formal, los requerimientos se documentan en el Documento

de Especificacin de Requerimientos (SRS), (Software Requirements
Specification)
El SRS sirve como contrato entre desarrolladores y cliente.
Existe una serie de atributos que debe tener una especificacin de

software:
Claridad/Carencia de ambigedad: Cada uno de los requerimientos
tiene una sola interpretacin posible.
Completa: Todo lo que el software debe hacer est incluido en las
especificaciones. Las respuestas a cualquier tipo de datos de entrada
en cualquier situacin posible estn incluidas en las especificaciones.
Correcta: Cada uno de los requerimientos representa algo que el
sistema requiere.
Entendible: Cualquier tipo de lector puede, fcilmente, comprender el
significado de todos los requerimientos con una explicacin mnima
Verificable: Existe alguna tcnica finita y costeable que puede ser usada
para verificar que cada uno de los requerimientos especificados est
incluido en el sistema terminado.
Consistente: No existen conflictos entre requerimientos.
Factible: Existe por lo menos un diseo y una implementacin que
satisfacen todos los requerimientos especificados.
Rastreable: Est escrita de manera que facilita la referencia de cada
requerimiento individual. El origen de cada requerimiento est claro.
Concisa: Es lo ms corta posible, sin afectar otras cualidades de la
especificacin.
Diseo Independiente: Existe ms de un diseo e implementacin que
satisface correctamente todos los requerimientos del sistema.
Modificable: Tiene una estructura y estilo que permiten hacer cambios
de una manera fcil, completa y consistente.
No redundante: Los requerimientos no estn repetidos
Precisa: Se usan cantidades numricas cuando es posible con el
apropiado nivel de precisin.
39
En general los siguientes pero se sugiere seleccionar una plantilla del

estndar de la IEEE
1. Enunciado resumen del proyecto
Por ejemplo:. El propsito de este proyecto es crear una terminal de
ventas a ser utilizada en tiendas supermercado
2. Cliente o Clientes:
Por ejemplo: Tiendas Ramrez y Asociados.
3. Requerimientos funcionales del sistema: lo que se supone debe
hacer el sistema, como:
El sistema debe autorizar crditos OBLIGATORIO
IMPORTANTE: Los requerimientos funcionales pueden capturarse en
forma de lista o por medio de casos de uso (siguiente tema).
Funcionales: Qu va a hacer el sistema Interfaces externas, cmo
interacta el sistema con el hardware, personas, y otros sistemas
Desempeo: Velocidad, disponibilidad, tiempo de respuesta, tiempo de
recuperacin, etc.
Atributos: Portabilidad, mantenimiento, seguridad, etc.
4. Otros requerimientos
Participantes
Grupos afectados
Acepciones
Riesgos
Glosario
Limitaciones: estndares, lenguaje de implementacin, polticas de
integridad de la base de datos, lmite de recursos, sistemas operativos,
etc.
Correcto
Los requerimientos reflejan una necesidad real
Cada requerimiento es uno que el software deber implementar
No ambiguo
Una sola interpretacin
No usar ms de una palabra para un mismo trmino (pedido u
orden, por ejemplo)
Glosario si es necesario
40
PERSONAL
Sin duda el elemento ms valioso en el desarrollo de proyectos
Quines participan en un proyecto de software?
Programadores
Lder de proyecto
Arquitectos de software
Usuarios
Analistas/Diseadores
Clientes
Ingenieros de requerimientos
Ingenieros de proceso
Ingenieros de pruebas
Cules son las caractersticas deseables de un lder de proyecto?

Motivador
Organizado
Innovador
Solucionador de Problemas
Cmo se organiza el equipo de trabajo?

Centralizado Controlado (CC): El jefe del equipo se encarga de la
resolucin de problemas a alto nivel y la coordinacin interna del equipo.
La comunicacin entre el jefe y los miembros del equipo es vertical.
Descentralizado Controlado (DC): Un jefe definido que coordina tareas
especficas y jefes secundarios con responsabilidades sobre subtareas.
La resolucin de problemas es una actividad del grupo, la comunicacin
es horizontal y vertical.
Descentralizado Democrtico (DD) o Egoless: No tiene un jefe
permanente, se nombran de acuerdo a la tarea. La solucin de
problemas se hace por consenso. La comunicacin es horizontal.
41
Qu factores se deben considerar cuando se estructura un equipo de

software?
Complejidad del proyecto (dificultad del problema, tamao del software)
Tiempo de desarrollo.
Modularidad.
Calidad.
Comunicacin requerida.
Discusin sobre ventajas y desventajas de cada tipo de organizacin.
Cmo creamos un equipo de alto rendimiento?

Confianza entre los miembros del equipo.
Distribucin de habilidades de acuerdo al problema.
Los inconformistas deben ser excluidos.
Qu factores pueden contaminar el desempeo de un equipo?

Atmsfera de trabajo frentica, malgastan energa y se descentran de
los objetivos
Alta frustracin causada por factores tecnolgicos, del negocio o
personales que provocan friccin entre los miembros del equipo.
Procedimientos coordinados pobremente o fragmentados o una
definicin pobre o impropiamente elegida del modelo de procesos que se
convierte en un obstculo a saltar.
Definicin confusa de los papeles a desempear produciendo una falta
de responsabilidad y la acusacin correspondiente.
Continua y repetida exposicin al fallo que conduce a una prdida de
confianza y una cada de la moral.
RIESGOS
El riesgo siempre implica dos caractersticas:
Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no

puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de
probabilidad.
42
Prdida: Si el riesgo se convierte en una realidad, ocurrirn

consecuencias no deseadas o prdidas.
Cuando se analizan los riesgos es importante cuantificar el nivel de

incertidumbre y el grado de prdidas asociado con cada riesgo. Para
hacerlo, se consideran diferentes categoras de riesgos
Los riesgos del proyecto amenazan al plan del proyecto. Es decir, si los
riesgos del proyecto se hacen realidad, es probable que la planificacin
temporal del proyecto se retrase y que los costos aumenten. Los riesgos
del proyecto identifican los problemas potenciales de presupuesto,
planificacin temporal, personal (asignacin y organizacin), recursos.
cliente y requisitos y su impacto en un proyecto de software.
Los riesgos tcnicos amenazan la calidad y la planificacin temporal del
software que hay que producir. Si un riesgo tcnico se convierte en
realidad, la implementacin puede llegar a ser difcil o imposible. Los
riesgos tcnicos identifican problemas potenciales de diseo,
implementacin, de interfaz. verificacin y de mantenimiento. Adems.
las ambigedades de especificaciones, incertidumbre tcnica, tcnicas
anticuadas y las "tecnologas punta" son tambin factores de riesgo. Los
riesgos tcnicos ocurren porque el problema es ms difcil de resolver de
lo que pensbamos.
Los riesgos del negocio amenazan la viabilidad del software a construir
Los riesgos del negocio a menudo ponen en peligro ei proyecto o el
producto. Los candidatos para los cinco principales riesgos del negocio
son:
1. Construir un producto o sistema excelente que no quiere nadie en

realidad (riesgo de mercado),
2. Construir un producto que no encaja en la estrategia comercial general de

la compaa (riesgo estratgico),
3. Construir un producto que ei departamento de ventas no sabe cmo

vender
43
4. Perder el apoyo de una gestin experta debido a cambios de enfoque o a

cambios de personal (riesgo de direccin)
4. Perder presupuesto o personal asignado (riesgos de presupuesto).

5. Es extremadamente importante recalcar que no siempre funciona una
categorizacin tan sencilla. Algunos riesgos son simplemente imposibles
de predecir. Otra categorizacin general de los riesgos ha sido
propuesta por Charette. Los riesgos conocidos son todos aquellos que
se pueden descubrir despus de una cuidadosa evaluacin del plan del
proyecto. del entorno tcnico y comercial en el que se desarrolla el
proyecto y otras fuentes de informacin fables (p. ej.: fechas de entrega
poco realistas. falta de especificacin de requisitos o de mbito del
software. o un entorno pobre de desarrollo), los riesgos predecibles se
extrapolan de la experiencia en proyectos anteriores (ej.: cambio de
personal, mala comunicacin con el cliente. disminucin del esfuerzo del
personal a medida que atienden peticiones de mantenimiento). Pueden
ocurrir pero son extremadamente difciles de identificar por adelantado.
EJEMPLO DOCUMENTO ESPECIFICACION DE

REQUERIMIENTOS
Especificacin de Requerimientos de Software (SRS)

Informacin de la versin
Proyecto: NOMBREDELPROYECTO
Nmero Interno de X.Y.Z
Versin:
Formas Anexas: SRS > Conjunto de casos de uso
SRS > Conjunto de caractersticas
Documentos Propuesta de proyecto
Relacionados: Conjunto de caractersticas
LIGAS A OTROS ESTNDARES
RELEVANTES
LIGAS A OTROS DOCUMENTOS
Impacto del proceso: Especificacin de Requerimientos de Software
(SRS) define de forma precisa el producto de software que se va a
44
construir. Las decisiones hechas escribiendo la SRS estn basados en

informacin de los documentos de la propuesta del proyecto y
requerimientos del usuario. El conjunto de requerimientos de SRS
deben ser satisfechos en el diseo del sistema. La SRS es verificada y
validada por la actividades marcadas en el plan de QA.
Introduccin
TAREAS: Proveer un breve resumen de esta entrega del producto. Puede
copiar el texto de la propuesta del proyecto, pegarla aqu, y resumirlo.
PRRAFO
PRRAFO
Para ms informacin, vea la propuesta del proyecto.
Casos de Uso
RESUMEN DE UN PRRAFO
Detalles:
Los actores son descritos en el documento de requerimientos del
usuario.
El conjunto de casos de uso use case suite enumera los casos de uso
en una forma organizada.
Requerimientos Funcionales
RESUMEN DE UN PRRAFO
Detalles:
El conjunto de caractersticas enumera todas las caractersticas en una
forma organizada.
Requerimientos No-Funcionales
TAREAS: Describa los requerimientos no funcionales para esta entrega.
Abajo se pueden ver algunos ejemplos.
Cules son los requerimientos de usabilidad?
Nuestro principal criterio para hacer el sistema usable es la dificultad de
realizar cada caso de uso de alta frecuencia. La dificultad depende de el
nmero de pasos, el conocimiento que el usuario debe tener en cada
paso, las decisiones que el usuario debe realizar en cada paso, y la
mecnica de cada paso (por ejemplo, escribir el ttulo de un libro de forma
exacta es difcil, hacer click en una lista es fcil).
La interfaz del usuario deber ser tan familiar como sea posible a los
usuarios que han usado otras aplicaciones web y aplicaciones de
escritorio en Windows. Por ejemplo, seguiremos las guas de la UI para
nombrar los menus, botones y las cajas de dilogo siempre que sea
posible.
Cul es la confiabilidad y los requerimientos de ltimo minuto?

PRRAFO
PRRAFO
Detalles:
DETALLE
DETALLE
DETALLE
Cules son los requerimientos de precaucin?
PRRAFO
PRRAFO
Detalles:
45
DETALLE
DETALLE
DETALLE
Cules son los requerimientos de seguridad?
El acceso ser controlado con nombres de usuario y contraseas.
Solo los usuarios con derechos de administrador podrn accesar las
funciones administrativas, los usuarios normales no podrn.
Detalles:
Las contraseas debern tener de 4 a 14 caracteres de longitud
No utilizaremos comunicaciones encriptadas (SSL) para este sitio
DETALLE
Cules son los requerimientos de desempeo y escalabilidad?
PRRAFO
PRRAFO
Detalles:
DETALLE
DETALLE
DETALLE
Cules son los requerimientos de mantenimiento y actualizacin?
La capacidad de mantenimiento es nuestra habilidad para realizar cambios
al producto en el tiempo. Necesitamos una capacidad de mantenimiento
fuerte para retener a nuestros primeros clientes. Resolveremos esto
anticipando varios tipos de cambios y documentando cuidadosamente
nuestro diseo y nuestra implementacin.
La capacidad de actualizacin es nuestra habilidad para entregar nuevas
versiones del producto a bajo costo a los clientes con un mnimo de tiempo
de descarga o disrupcin. Una caracterstica clave para apoyar este
objetivo es la descarga automtica de parches o actualizaciones y
actualizaciones del equipo del usuario final. Tambin debemos utilizar
formatos para archivos de datos que incluyan suficientes meta-datos para
permitirnos trasformar con seguridad la informacin existente del usuario
durante una actualizacin.
Detalles:
DETALLE
DETALLE
DETALLE
Cules son los requerimientos de soportabilidad y operabilidad?
La soportabilidad es nuestra habilidad de proveer soporte tcnico eficiente
y a buen precio. Nuestro objetivo es limitar nuestros costos de soporte a
solo 5% de las tarifas de licenciamiento anual. Las caractersticas de
actualizacin automtica del producto no ayudar a entregar fcilmente
parches a los usuarios finales. La gua del usuario y el sitio web del
producto incluyen una gua de resolucin de problemas y una lista de
informacin que debe tener a la mano antes de contactar a soporte
tcnico.
La operabilidad es nuestra habilidad de hospedar y operar el software
como un ASP (Proveedor de Servicios de Aplicaciones). Las
caractersticas del producto debern ayudarnos a alcanzar nuestros
objetivos de 99.9% en lnea (con 43 minutos mximo fuera de lnea por
mes). Las caractersticas principales que soporten esto son la capacidad
46
de crear respaldos de datos en tiempo de operacin, y el monitoreo de la

aplicacin.
Cules son los requerimientos del ciclo de vida del negocio?
El ciclo de vida del negocio de un producto incluye todo lo que le pasa a
ese producto sobre un periodo de varios aos, desde la decisin inicial de
compra, a travs de importantes pero poco frecuentes casos de uso,
hasta el retiro del producto. Los requerimientos principales de del ciclo de
vida son listados abajo.
Detalles:
Los clientes debern se capaces de manejar el nmero de licencias con
el que ya cuentan y de hacer decisiones informadas sobre las compras
de ms licencias cuando sea necesario
el producto deber soportar operacin diaria y nuestra auditora de fin de
ao
La informacin del cliente deber ser almacenada en un formato que sea
accesible incluso despus de que la aplicacin sea retirada.
Requerimientos Ambientales
TAREAS: Describa los requerimientos ambientales para esta entrega. Los
requerimientos ambientales describen el sistema ms grande hardware,
software, y los data con el que este producto debe trabajar. Se proveen
algunos ejemplos ms abajo.
Cules son los requerimientos de hardware del sistema?
PRRAFO
PRRAFO
Detalles:
DETALLE
DETALLE
Cules son los requerimientos de software del sistema?
PRRAFO
PRRAFO
Detalles:
DETALLE
DETALLE
Qu Interfaces de Aplicacin del Programa (APIs) deben incluirse?
PRRAFO
PRRAFO
Detalles:
Debemos implementar esta API estndar.
DETALLE
DETALLE
Cules son los requerimientos de importacin y exportacin de
datos?
PRRAFO
PRRAFO
Detalles:
El sistema deber almacenar todos los datos en una base de datos SQL
estndar, donde pueda ser accesado por otros programas.
El sistema podr almacenar todos los datos en un archivo XML, usando
una DTD estndar.
47
El sistema deber leer y escribir archivos .XYZ vlidos para ser usados
por OTRA APLICACIN
FORMATO IEEE830 REQUERIMIENTOS
Especificacin de requisitos de software
Proyecto: [Nombre del proyecto]

Revisin [99.99]
[Mes de ao]
48
Instrucciones para el uso de este formato

Este formato es una plantilla tipo para documentos de requisitos del
software.
Est basado y es conforme con el estndar IEEE Std 830-1998.
Las secciones que no se consideren aplicables al sistema descrito podrn

de forma justificada indicarse como no aplicables (NA).
Notas:
Los textos en color azul son indicaciones que deben eliminarse y, en su
caso, sustituirse por los contenidos descritos en cada apartado.
Los textos entre corchetes del tipo [Inserte aqu el texto] permiten la
inclusin directa de texto con el color y estilo adecuado a la seccin, al
pulsar sobre ellos con el puntero del ratn.
Los ttulos y subttulos de cada apartado estn definidos como estilos de

MS Word, de forma que su numeracin consecutiva se genera
automticamente segn se trate de estilos Titulo1, Titulo2 y Titulo3.
La sangra de los textos dentro de cada apartado se genera

automticamente al pulsar Intro al final de la lnea de ttulo. (Estilos Normal
indentado1, Normal indentado 2 y Normal indentado 3).
El ndice del documento es una tabla de contenido que MS Word actualiza

tomando como criterio los ttulos del documento.
Una vez terminada su redaccin debe indicarse a Word que actualice todo
su contenido para reflejar el contenido definitivo.
De la plantilla de formato del documento & Coloriuris http://www.qualitatis.org
41
Ficha del documento
Fecha Revisin Autor Verificado dep.

calidad.
[Fecha] [Rev] [Descripcion] [Firma o sello]
Documento validado por las partes en fecha: [Fecha]
Por el cliente Por la empresa suministradora
Fdo. D./ Da [Nombre] Fdo. D./Da [Nombre]
42
Contenido
FICHA DEL DOCUMENTO 3
CONTENIDO 4
1 INTRODUCCIN 6
1.1 Propsito 6
1.2 Alcance 6
1.3 Personal involucrado 6
1.4 Definiciones, acrnimos y abreviaturas 6
1.5 Referencias 6
1.6 Resumen 6
2 DESCRIPCIN GENERAL 7
2.1 Perspectiva del producto 7
2.2 Funcionalidad del producto 7
2.3 Caractersticas de los usuarios 7
2.4 Restricciones 7
2.5 Suposiciones y dependencias 7
2.6 Evolucin previsible del sistema 7
3 REQUISITOS ESPECFICOS 7
3.1 Requisitos comunes de los interfaces 8
3.1.1 Interfaces de usuario 8
3.1.2 Interfaces de hardware 8
3.1.3 Interfaces de software 8
3.1.4 Interfaces de comunicacin 8
3.2 Requisitos funcionales 8
3.2.1 Requisito funcional 1 9
3.2.4 Requisito funcional n 9
3.3 Requisitos no funcionales 9
3.3.1 Requisitos de rendimiento 9
3.3.2 Seguridad 9
3.3.3 Fiabilidad 9
3.3.4 Disponibilidad 9
3.3.5 Mantenibilidad 10
3.3.6 Portabilidad 10
3.4 Otros requisitos 10
4 Apndices 10
43
Introduccin
[Inserte aqu el texto]
La introduccin de la Especificacin de requisitos de software (SRS) debe
proporcionar una vista general de la SRS. Debe incluir el objetivo, el alcance,
las definiciones y acrnimos, las referencias, y la vista general del SRS.
Propsito
Propsito del documento
Audiencia a la que va dirigido
Alcance
Identificacin del producto(s) a desarrollar mediante un nombre
Consistencia con definiciones similares de documentos de mayor nivel
(ej. Descripcin del sistema) que puedan existir
Personal involucrado
Nombre [Inserte aqu el texto]
Rol [Inserte aqu el texto]
Categora [Inserte aqu el texto]
profesional
Responsabilidades [Inserte aqu el texto]
Informacin de [Inserte aqu el texto]
contacto
Aprobacin [Inserte aqu el texto]
Relacin de personas involucradas en el desarrollo del sistema, con

informacin de contacto.
Esta informacin es til para que el gestor del proyecto pueda localizar a
todos los participantes y recabar la informacin necesaria para la obtencin
de requisitos, validaciones de seguimiento, etc.
Definiciones, acrnimos y abreviaturas
Definicin de todos los trminos, abreviaturas y acrnimos necesarios para
interpretar apropiadamente este documento. En ella se pueden indicar
referencias a uno o ms apndices, o a otros documentos.
Referencias
Fech
Referencia Titulo Ruta a Autor
[Ref.] [Ttulo] [Ruta] [Fecha] [Autor]
Relacin completa de todos los documentos relacionados en la

especificacin de requisitos de software, identificando de cada documento
el titulo, referencia (si procede), fecha y organizacin que lo proporciona.
Resumen
44
Descripcin del contenido del resto del documento

Explicacin de la organizacin del documento
Descripcin general
Perspectiva del producto
Indicar si es un producto independiente o parte de un sistema mayor. En el
caso de tratarse de un producto que forma parte de un sistema mayor, un
diagrama que site el producto dentro del sistema e identifique sus
conexiones facilita la comprensin.
Funcionalidad del producto
Resumen de las funcionalidades principales que el producto debe realizar,
sin entrar en informacin de detalle.
En ocasiones la informacin de esta seccin puede tomarse de un
documento de especificacin del sistema de mayor nivel (ej. Requisitos del
sistema).
Las funcionalidades deben estar organizadas de manera que el cliente o
cualquier interlocutor pueda entenderlo perfectamente. Para ello se pueden
utilizar mtodos textuales o grficos.
Caractersticas de los usuarios
Tipo de usuario [Inserte aqu el texto]
Formacin [Inserte aqu el texto]
Habilidades [Inserte aqu el texto]
Actividades [Inserte aqu el texto]
Descripcin de los usuarios del producto, incluyendo nivel educacional,

experiencia y experiencia tcnica.
Restricciones
Descripcin de aquellas limitaciones a tener en cuenta a la hora de disear y
desarrollar el sistema, tales como el empleo de determinadas metodologas
de desarrollo, lenguajes de programacin, normas particulares, restricciones
de hardware, de sistema operativo etc.
Suposiciones y dependencias
Descripcin de aquellos factores que, si cambian, pueden afectar a los
requisitos. Por ejemplo una asuncin puede ser que determinado sistema
operativo est disponible para el hardware requerido. De hecho, si el
sistema operativo no estuviera disponible, la SRS debera modificarse.
Evolucin previsible del sistema
Identificacin de futuras mejoras al sistema, que podrn analizarse e
implementarse en un futuro.
Requisitos especficos
Esta es la seccin ms extensa y ms importante del documento.
45
Debe contener una lista detallada y completa de los requisitos que debe
cumplir el sistema a desarrollar. El nivel de detalle de los requisitos debe ser el
suficiente para que el equipo de desarrollo pueda disear un sistema que
satisfaga los requisitos y los encargados de las pruebas puedan determinar si
stos se satisfacen.
Los requisitos se dispondrn en forma de listas numeradas para su

identificacin, seguimiento, trazabilidad y validacin (ej. RF 10, RF 10.1, RF
10.2,...).
Para cada requisito debe completarse la siguiente tabla:
Nmero de requisito [Inserte aqu el texto]

Nombre de requisito [Inserte aqu el texto]
Tipo Requisito Restriccin
Fuente del requisito [Inserte aqu el texto]
Prioridad del requisito Baja/
Alta/Esencial Media/Deseado Opcional
y realizar la descripcin del requisito
La distribucin de los prrafos que forman este punto puede diferir del
propuesto en esta plantilla, si las caractersticas del sistema aconsejan otra
distribucin para ofrecer mayor claridad en la exposicin.
Requisitos comunes de los interfaces
Descripcin detallada de todas las entradas y salidas del sistema de
software.
Interfaces de usuario
Describir los requisitos del interfaz de usuario para el producto. Esto puede
estar en la forma de descripciones del texto o pantallas del interfaz. Por
ejemplo posiblemente el cliente ha especificado el estilo y los colores del
producto. Describa exacto cmo el producto aparecer a su usuario previsto.
Interfaces de hardware
Especificar las caractersticas lgicas para cada interfaz entre el producto y
los componentes de hardware del sistema. Se incluirn caractersticas de
configuracin.
Interfaces de software
Indicar si hay que integrar el producto con otros productos de software.
Para cada producto de software debe especificarse lo siguiente:
Descripcin del producto software utilizado
Propsito del interfaz
Definicin del interfaz: contiendo y formato
46
Interfaces de comunicacin
Describir los requisitos del interfaces de comunicacin si hay
comunicaciones con otros sistemas y cuales son las protocolos de
comunicacin.
Requisitos funcionales
Definicin de acciones fundamentales que debe realizar el software al recibir
informacin, procesarla y producir resultados.
En ellas se incluye:
Comprobacin de validez de las entradas
Secuencia exacta de operaciones
Respuesta a situaciones anormales (desbordamientos, comunicaciones,
recuperacin de errores)
Parmetros
Generacin de salidas
Relaciones entre entradas y salidas (secuencias de entradas y salidas,
formulas para la conversin de informacin)
Especificacin de los requisitos lgicos para la informacin que ser
almacenada en base de datos (tipo de informacin, requerido)
Las requisitos funcionales pueden ser divididos en sub-secciones.

Requisito funcional 1
Requisito funcional n
Requisitos no funcionales
Requisitos de rendimiento
Especificacin de los requisitos relacionados con la carga que se espera
tenga que soportar el sistema. Por ejemplo, el nmero de terminales, el
nmero esperado de usuarios simultneamente conectados, nmero de
transacciones por segundo que deber soportar el sistema, etc.
Todos estos requisitos deben ser mesurables. Por ejemplo, indicando el
95% de las transacciones deben realizarse en menos de 1 segundo, en
lugar de los operadores no deben esperar a que se complete la
transaccin.
Seguridad
Especificacin de elementos que protegern al software de accesos, usos y
sabotajes maliciosos, as como de modificaciones o destrucciones maliciosas
o accidentales. Los requisitos pueden especificar:
Empleo de tcnicas criptogrficas.
Registro de ficheros con logs de actividad.
Asignacin de determinadas funcionalidades a determinados
mdulos.
Restricciones de comunicacin entre determinados mdulos.
47
Comprobaciones de integridad de informacin crtica.

Fiabilidad
Especificacin de los factores de fiabilidad necesaria del sistema. Esto se
expresa generalmente como el tiempo entre los incidentes permisibles, o el
total de incidentes permisible.
Disponibilidad
Especificacin de los factores de disponibilidad final exigidos al sistema.
Normalmente expresados en % de tiempo en los que el software tiene que
mostrar disponibilidad.
Mantenibilidad
Identificacin del tipo de mantenimiento necesario del sistema.
Especificacin de quien debe realizar las tareas de mantenimiento, por
ejemplo usuarios, o un desarrollador.
Especificacin de cuando debe realizarse las tareas de mantenimiento. Por
ejemplo, generacin de estadsticas de acceso semanales y mensuales.
Portabilidad
Especificacin de atributos que debe presentar el software para facilitar su
traslado a otras plataformas u entornos. Pueden incluirse:
Porcentaje de componentes dependientes del servidor.
Porcentaje de cdigo dependiente del servidor.
Uso de un determinado lenguaje por su portabilidad.
Uso de un determinado compilador o plataforma de desarrollo.
Uso de un determinado sistema operativo.
Otros requisitos
Cualquier otro requisito que no encaje en ninguna de las secciones
anteriores.
Por ejemplo:
Requisitos culturales y polticos
Requisitos Legales
Apndices
Pueden contener todo tipo de informacin relevante para la SRS pero que,
propiamente, no forme parte de la SRS.
El Estudiante Dice y Hace:
1. El estudiante elaborara el anlisis de requerimientos de la

aplicacin utilizando el formato IEEE830
48
49

Modulo PD 1 Unidad 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modulo PD 1 Unidad 1

Uploaded by

Copyright:

Available Formats

DESARROLLO DE

Gua para el estudiante

Elaborado por el formador:

VERNICA FABIANA RINCN CANTOR

INSTITUTO COLOMBIANO DE APRENDIZAJE

INSTITUTO COLOMBIANO DE APRENDIZAJE INCAP

Programa Tcnico Laboral en Sistemas

EL SIGUIENTE MATERIAL SE PREPAR CON FINES

Prohibida la reproduccin parcial o total

Versin 01 - Julio 2010

DIAGRAMAS DE CASO DE USO 52

Usted escogi al INCAP para que lo oriente en el camino de la formacin profesional. La

PRESENTACIN: Es la informacin general sobre los contenidos, la metodologa, los

GUA METODOLGICA: Orienta la prctica pedaggica en el desarrollo del proceso de

DIAGNSTICO DE ESTILO DE APRENDIZAJE: Que le permitir utilizar la estrategia ms

CONTENIDOS: Son el cuerpo de la unidad y estn presentados as:

Desarrollar un software significa construirlo simplemente

El presente mdulo ofrece al estudiante herramientas para

probarlo e instalarlo al cliente. Es as como intervienen varias

La estrategia metodolgica del INCAP, para la formacin tcnica del aprendiz

2. El trabajo prctico de los estudiantes dirigido y evaluado por el Formador, a travs

A cada unidad de aprendizaje le corresponde un logro de competencia laboral el

Glosario: Definicin de trminos o palabras utilizadas en la unidad que son propias

Desarrollo de la unidad dividida en contenidos breves seguidos por ejercicios,

FDH (El Formador Dice y Hace): Corresponde a la explicacin del contenido

FDEH (El Formador Dice y el Estudiante Hace): El estudiante desarrolla los

Al final de cada unidad se puede presentar un resumen de los contenidos ms

1. Ciclo de Vida del Software y Metodologas

1. Conocer el ciclo de vida del software y aplicar tcnicas de recoleccin de

Indicador de Logro Evidencia de

1. Conoce el ciclo de vida del software y

1. Ciclo de vida del software

Software: procedimientos y reglas lgicas escritas en la forma de

INSTITUTO COLOMBIANO DE APRENDIZAJE INCAP

2. ETAPAS DEL CICLO DE VIDA DEL SOFTWARE

Necesidades: esta etapa tiene como objetivo

Dado que normalmente se trata de

Especificaciones: Por medio de esta etapa se

Lo ms normal ser que no resulte posible

Anlisis: Es necesario determinar qu

Diseo: Tras la etapa anterior ya se tiene claro

Implementacin: Llegado este punto se

Pruebas: el objetivo de estas pruebas es

de integracin del sistema (segn sea la

Validacin: Esta etapa tiene como objetivo la

Mantenimiento y Evolucin: Finalmente la

El Formador Dice y el estudiante Hace:

3. MODELOS DEL CICLO DE V IDA DEL SOFTWARE

Un modelo de ciclo de vida de software es una vista de las actividades que

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software.

Define las fases primarias esperadas de ser ejecutadas durante esas

Ayuda a administrar el progreso del desarrollo, y

Provee un espacio de trabajo para la definicin de un detallado proceso

3.1. MODELO EN CASCADA

Caractersticas del modelo cascada

Fases del Modelo Cascada

Las fases son:

Diseo: se basa en estructura de datos, arquitectura del software el

3.2. MODELO EN ESPIRAL

presupuesto o por el calendario; y el de prototipeo cuando tengamos

El modelo espiral consta de 4 cuadrantes que son sus fases y se dividen de

En cada vuelta o iteracin hay que tener en cuenta