INTRODUCCIN

Nuestra visin est centrada en la escasa o casi nula intervencin en el

campo de construccin de software a nivel de la Educacin Bsica
General, cuando en realidad nos desenvolvemos en un mundo
globalizado en cuestiones tecnolgicas, donde en nuestro pas no ha
sido muy explotada y hay requerimiento de personal a fines a esta rea.
Nuestra misin en este proyecto es colaborar con los docentes del
plantel, alumnado y generaciones siguientes a impulsar y llenar de
conocimientos para que en un futuro no muy lejano adquieran esos
conocimientos bsicos y slidos para facilitarle su tarea.
El ciclo de vida del desarrollo Software (SDLC en sus siglas inglesas),
es una secuencia estructurada y bien definida de las etapas en
Ingeniera de software para desarrollar el producto software deseado

1 Pgina

1. PROPUESTA DE TRABAJO
La implementacin de un software Triangulo EGB alumno profesor
representante, el cual servir de gran beneficio para los tres.
1.1. PROPUESTA
Mediante el software a implementar, el representante sabr como esta
su representado en la institucin, pues a medida que el profesor pase
notas, el representante se dar por enterado del rendimiento por
medio de las calificaciones.
1.2. CONDICIONES
Las condiciones se transmitirn siempre y cuando el docente realice el
pase de nota.
1.3. ESTRATEGIAS A UTILIZAR
La informacin ser enviada va internet, para esto se utilizara toda la
tecnologa disponible en el mercado, tanto iPod, Table, Laptops, Pc.
Mvil, etc.. La plataforma de internet es la va ms rpida para
conocer el desenvolvimiento de los estudiantes, por lo que el software
de programacin tendr que ser a fin a la plataforma.

2 Pgina

2. MEMORIA DESCRIPTIVA
2.1. DESCRIPCIN GENERAL
El Ciclo de vida del software es el proceso que se sigue para
construir, entregar y hacer evolucionar el software, desde la
concepcin de una idea hasta la entrega y retiro del sistema. Se
definen las distintas fases intermedias que se requieren para validar el
desarrollo de un software, 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.
Diversas

organizaciones

profesionales

(IEEE

ISO/IEC)

han

publicado normas relativas al ciclo de vida del software.

Concretamente: Todas consideran una actividad como un conjunto de
tareas u una tarea como una accin que transforma entradas en
salidas.
2.2. MODELO DE PROCESO
2.2.1. Modelo de Proceso: IEEE 1074
Define las actividades que constituyen los procesos necesarios
para el desarrollo y el mantenimiento de software, ya sea parte
de un sistema mayor o autnomo (stand-alone). (Anexo N 1)
Los procesos de gestin y soporte a lo largo de todo el ciclo
de vida.
Procesos divididos en actividades (obligatorias y opcionales):

3 Pgina

 Informacin de entrada.
Descripcin.
Informacin de salida.
Antes de empezar un proyecto, revisar las actividades para
ver si son aplicables, y establecer un orden.
Conformidad con el estndar: realizacin de todas las
actividades obligatorias.
2.2.2. Modelo de Proceso: Familia ISO 9000
Familia de estndares para la gestin de la calidad de cualquier
proceso de produccin. (Anexo N 2)
La organizacin debe tener un sistema de calidad que supervise
todas las fases de la produccin y entrega del producto:
Audita proyectos para asegurar que cumplen los controles
de calidad.
Mejora la calidad del propio sistema de calidad.
Proporciona entradas al grupo de desarrollo (como nuevas
notaciones, procedimientos, estndares).
Produce informes para la direccin.
Para cada proyecto se define un plan de calidad.
Variantes:
2.2.2.1. ISO 9001

4 Pgina

Describe el sistema de calidad utilizado para mantener

el desarrollo de un producto que implique diseo.
2.2.2.2. ISO 9000-3
Contiene directrices que interpretan ISO 9001 para el
desarrollador de software.
2.2.2.3. ISO 9004-2
Contiene guas para proporcionar servicios de software,
como por ejemplo el soporte de usuario.
2.2.3. Modelo de Proceso: ISO 12207
En 1987, en una sesin plenaria de la ISO, la delegacin
norteamericana solicit al International Software Engineering
Standards Group el desarrollo de una norma relativa al proceso
del ciclo de vida del software. En 1989, se constituy el Grupo
de Trabajo 7 para iniciar el proyecto.
El estndar ISO/IEC 12207 describe la arquitectura del ciclo de
vida del software, pero no especifica los detalles de cmo
implementar o llevar a cabo las actividades o tareas incluidas en
los procesos.
La ISO 12207 proporciona un proceso estructurado utilizando
terminologa aceptada, ms que dictar un mtodo particular del
ciclo de vida o un mtodo para el desarrollo de software. Puesto
que es un documento relativamente de alto nivel, el ISO 12207
no especifica detalladamente cmo realizar las actividades y las
tareas que abarcan los procesos. Ni prescribe el nombre, el
formato, o el contenido de la documentacin. Por lo tanto, las
organizaciones que intentan aplicar el ISO

12207

pueden

5 Pgina

utilizar los estndares o procedimientos adicionales donde se

especifican este tipo de detalles. (Anexo N 3).
El estndar es independiente de tecnologas y de metodologas
de desarrollo y son tiles para cualquier forma de modelo de
ciclo de vida, por ejemplo, cascada, incremental, espiral, etc. De
hecho, una de las responsabilidades del proveedor del servicio
es la de seleccionar un modelo de ciclo de vida y mapear los
requerimientos del estndar 12207 a ese ciclo de vida en
particular, por lo que sus actividades pueden ser llevadas a cabo
de forma secuencial, repetida y combinndolas acorde a la
seleccin del proyecto del modelo del ciclo de vida.

6 Pgina

Variante:
2.2.3.1. ISO 12207-1
"Un marco de referencia que contiene los procesos, las
actividades y las tareas involucradas en el desarrollo, la
explotacin y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la
definicin de los requisitos hasta la finalizacin de su
uso."
Segn la Norma ISO 12207-1, las actividades a realizar
durante el ciclo de vida del software se agrupan en
cinco procesos principales, ocho procesos de soporte y
cuatro procesos de la organizacin, as como un
proceso especial que permite adaptar el ciclo de vida a
cada proyecto concreto. A destacar que la norma no
recomienda ningn modelo concreto de ciclo de vida, ni
de gestin del software, ni detalla cmo realizar
ninguna de las actividades.
2.3. PROCESOS DEL CICLO DE VIDA SOFTWARE
Dichas actividades se agrupan en cinco procesos principales, ocho
procesos de soporte y cuatro procesos de la organizacin.
2.3.1. Procesos principales
Son aquellos que resultan tiles a las personas que inician o
realizan el desarrollo, la explotacin o el mantenimiento del
software durante su ciclo de vida.

7 Pgina

2.3.1.1 Proceso de adquisicin

Son las actividades y tareas que el comprador, el
cliente o el usuario realiza para adquirir un sistema,
un producto o un servicio software:
Preparacin y publicacin de solicitud de ofertas
Seleccin del suministrador
Gestin de procesos desde la adquisicin hasta
la aceptacin del producto., etc.
2.3.1.2. Proceso de suministro
Son las actividades y tareas que el suministrador
realiza:
Propuesta para responder a la peticin de un
comprador
Firma de contrato de suministro del producto
Identificacin de recursos y procedimientos para
garantizar el xito del proyecto
Desarrollo de los planes del proyecto
Ejecucin de dichos planes
Entrega del producto al comprador
2.3.1.3. Proceso de desarrollo
Tradicionalmente, el proceso de desarrollo se ha
distribuido por fases como indica la figura:
Actualmente, en proceso de desarrollo tradicional
desglosa sus fases en actividades, siendo las ms
principales las siguientes:
8 Pgina

 Anlisis de los requisitos del sistema (Estudio de

viabilidad, requisitos de seguridad, interaccin
hombre mquina, interfaces, restricciones
aplicables al diseo, etc.)
Diseo

de

(Componentes

la

arquitectura
de

hardware

del

sistema

software,

operaciones manuales del sistema, etc.)

Anlisis de requisitos de software
Diseo de la arquitectura del software
Diseo detallado del software
Codificacin y prueba de software
Integracin del software
Prueba del software
Integracin del sistema
Prueba del sistema

9 Pgina

 Instalacin del software en el entorno de

explotacin final donde vaya a funcionar
Aceptacin del software por parte del comprador
2.3.1.4. Proceso de explotacin
Tambin Llamado proceso de operacin, incluye la
explotacin del software y el soporte operativo a los
usuarios.
2.3.1.5. Proceso de mantenimiento
Es el proceso que aparece cuando el software
necesita modificaciones, ya sea en cdigo o en la
documentacin aportada
2.3.2. Procesos de soporte
Son procesos de apoyo al resto de los procesos y se aplican
en cualquier punto del ciclo de vida del software. Son los
siguientes:
2.3.2.1. Proceso de documentacin
Registra la informacin producida por un proceso o
actividad del ciclo de vida. El proceso permite
planificar,

disear,

desarrollar,

producir,

editar,

distribuir, y mantener los documentos necesarios para

todas las personas involucradas en el software.
2.3.2.2. Proceso de gestin de la configuracin
Aplica

procedimientos

administrativos y tcnicos

durante todo el ciclo de vida del sistema para:

10 Pgina

 Identificar, definir y establecer la lnea base de los

elementos de configuracin del software del
sistema.
Controlar las modificaciones y las versiones de los
elementos
Registrar el estado de los elementos y las
peticiones de modificacin
Asegurar la complexin, la consistencia y la
correccin de los elementos
Controlar el almacenamiento, la manipulacin y la
entrega de los elementos
2.3.2.3. Proceso de aseguramiento de la calidad
Garantiza que los procesos y los productos software
del ciclo de vida cumplen los requisitos especificados
y cumplen con los planes establecidos.
2.3.2.4. Proceso de verificacin
Verifica si los requisitos de un sistema o del software
estn completos y son correctos y si los productos
software de cada fase del ciclo de vida cumplen los
requisitos impuestos sobre ellos en las fases previas.
2.3.2.5. Proceso de validacin
Determina si el sistema o software final cumplen los
requisitos previos para su uso.
2.3.2.6. Proceso de revisin conjunta
Sirve para evaluar el estado del software y sus
productos en una actividad del ciclo de vida o una fase
de un proyecto.
11 Pgina

2.3.2.7. Proceso de auditora

Permite establecer en momentos predeterminados si
se han cumplido los requisitos, los planes y el
contrato.
2.3.2.8. Proceso de resolucin de problemas
Permite

analizar

eliminar

los

problemas

(disconformidades con los requisitos o el contrato)

descubiertos durante el desarrollo, la explotacin, el
mantenimiento u otro proceso.
2.3.3. Procesos de Organizacin
Son los procesos que emplea una organizacin para llevar a
cabo funciones tales como la gestin, la formacin del personal
o la mejora del proceso. Suelen llevarse a cabo en el mbito
organizativo, fuera del mbito de proyectos y contratos
especficos.
2.3.3.1. Proceso de gestin
Comprende las actividades y tareas genricas que
puede emplear una organizacin que tenga que
gestionar sus procesos (planificacin, seguimiento y
control, evaluacin, revisin, etc.)
2.3.3.2. Proceso de infraestructura
Establece la infraestructura necesaria para cualquier
otro

proceso

(hardware,

software,

herramientas,

normas, tcnicas e instalaciones para el desarrollo, la

explotacin o el mantenimiento).
2.3.3.3. Proceso de mejora
12 Pgina

Establece, valora, mide, controla y mejora los

procesos del ciclo de vida del software.

2.3.3.4. Proceso de formacin

Proporciona

formacin

mantiene

al

personal

formado, incluye, por tanto, el desarrollo del material

de formacin y la implementacin de un plan de
formacin.
2.4. TIPOS DE CICLOS DE VIDA DEL SOFTWARE
Un modelo de ciclo de vida del software es una caracterizacin
-descriptiva o prescriptiva- de la evolucin del software.
Los

modelos

prescriptivos

dictan

pautas

de

cmo

deberan

desarrollarse los sistemas de software; por lo tanto son ms fciles de

articular ya que los detalles del desarrollo pueden ser ignorados,
generalizados, etc. Esto puede dejar dudas acerca de la validez y
robustez de este tipo de modelos. Otra forma de encarar el desarrollo
de un modelo es la forma descriptiva, la cual se basa en la
observacin del desarrollo de sistemas reales. Son ms difciles de
articular debido a dos razones fundamentales:
Existen diferentes modelos de ciclo de vida del software que han
intentado resolver el problema de crear software. El auge de cada uno
est asociado a un momento en el tiempo, unas tecnologas
determinadas y una cierta metodologa asociada.
Algunos de los ms conocidos son:

13 Pgina

 En Cascada
En V
En Espiral
Incremental
Prototipado
2.4.1. Herramientas
Las herramientas CASE son diversas aplicaciones informticas
o

programas

informticos destinadas

aumentar

la

productividad en el desarrollo de software reduciendo el costo

de las mismas en trminos de tiempo y de dinero.

Existen diferentes herramientas informticas que pueden

facilitar el desarrollo de un estudio de Anlisis de Ciclo de Vida,
especialmente las fases de inventario, evaluacin de impactos e
interpretacin de resultados.

Dos de las herramientas software ms utilizadas actualmente

son: SimaPro y GaBi, ambas pueden utilizarse para evaluar
cualquier tipo de producto o proceso y contienen bases de datos
con informacin de inventario de ciclo de vida de diversos
productos y procesos. El uso de este software est sujeto a
diferentes tipos de licencia, de coste variable, segn las
caractersticas del usuario (profesional, estudiante, etc.).

14 Pgina

Este tipo de programa de uso general requiere sin embargo de

un alto conocimiento de la metodologa de ACV, mientras que
existen otras herramientas especficas para el sector de la
construccin como, por ejemplo, EcoCalculator, Bees o Elodie.
Estas herramientas especficas tienen interfaces ms adaptadas
a facilitar la entrada de datos y la interpretacin de los
resultados obtenidos.

Tanto

las

herramientas

generales

como

las

especficas

requieren de la introduccin manual de datos por parte del

usuario, sin que por el momento se haya conseguido una
transferencia

de

datos

desde

otros

software

utilizados

habitualmente por los profesionales del sector (como, por

ejemplo, herramientas de simulacin del consumo energtico
durante el uso o de elaboracin de presupuestos).

15 Pgina

16 Pgina

3. DESCRIPCIN TCNICA
3.1. Ciclo de vida en Cascada
Conocido tambin como ciclo de vida lineal o bsica, este modelo de
ciclo de vida fue propuesto por Winston Royce en el a-o 1970. Es un
ciclo de vida que admite iteraciones. Despus de cada etapa se
realiza una o varias revisiones para comprobar si se puede pasar a la
siguiente. Es un modelo rgido, poco flexible, y con muchas
restricciones. Aunque fue uno de los primeros, y sirvi de base para el
resto de los modelos de ciclo de vida, sin embargo, para muchos
proyectos modernos, ha quedado un poco desactualizado.

3.1.1. Fases del modelo de cascada

De esta forma, cualquier error de diseo detectado en la etapa
de prueba conduce necesariamente al rediseo y nueva
programacin del cdigo afectado, aumentando los costos del
desarrollo. La palabra cascada sugiere, mediante la metfora de

17 Pgina

la fuerza de la gravedad, el esfuerzo necesario para introducir

un cambio en las fases ms avanzadas de un proyecto

3.1.1.1. Anlisis de requisitos

En esta fase se analizan las necesidades de los
usuarios finales del software para determinar qu
objetivos debe cubrir. De esta fase surge una memoria
llamada SRD, que contiene la especificacin completa
de lo que debe hacer el sistema sin entrar en detalles
internos. Es importante sealar que en esta etapa se
debe consensuar todo lo que se requiere del sistema y
ser aquello lo que seguir en las siguientes etapas, no
pudindose requerir nuevos resultados a mitad del
proceso de elaboracin del software de una manera.

3.1.1.2. Diseo del Sistema

Descompone y organiza el sistema en elementos que
puedan elaborarse por separado, aprovechando las
ventajas del desarrollo en equipo. Como resultado
surge el SDD, que contiene la descripcin de la
estructura

relacional

global

del

sistema

la

especificacin de lo que debe hacer cada una de sus

partes, as como la manera en que se combinan unas
con otras.

3.1.1.3. Diseo del Programa

18 Pgina

Es la fase en donde se realizan los algoritmos

necesarios para el cumplimiento de los requerimientos
del usuario as como tambin los anlisis necesarios
para saber qu herramientas usar en la etapa de
Codificacin
3.1.1.4. Codificacin
Es la fase en donde se implementa el cdigo fuente,
haciendo uso de prototipos as como de pruebas y
ensayos

para

corregir errores.

Dependiendo

del

lenguaje de programacin y su versin se crean las

bibliotecas y componentes reutilizables dentro del
mismo proyecto para hacer que la programacin sea un
proceso mucho ms rpido.

3.1.1.5. Pruebas
Los elementos, ya programados, se ensamblan para
componer el sistema y se comprueba que funciona
correctamente y que cumple con los requisitos, antes
de ser entregado al usuario final.

3.1.1.6. Verificacin
Es la fase en donde el usuario final ejecuta el sistema,
para ello el o los programadores ya realizaron
exhaustivas pruebas para comprobar que el sistema no
falle.

19 Pgina

3.1.1.7. Mantenimiento
Una de las etapas ms crticas, ya que se destina un 75 %
de los recursos, es el mantenimiento del Software ya que al
utilizarlo como usuario final puede ser que no cumpla con
todas nuestras expectativas.

3.1.2. Ventajas del modelo de cascada

Es un modelo lineal y, por supuesto, los modelos lineales son las
ms simples a ser implementadas.
La cantidad de recursos es mnimo.
La documentacin se produce en cada etapa. Esto hace que la
comprensin del producto disear procedimiento ms sencillo.
Despus de cada etapa importante de la codificacin de software,
las

pruebas

se

realizan

para

comprobar

el

correcto

funcionamiento del cdigo.

3.1.3. Desventajas del Modelo Cascada

No se puede volver atrs, si la fase de diseo ha ido mal, las
cosas pueden ser muy complicado en la fase de ejecucin.
Cualquier cambio que se menciona en el medio puede causar
mucha confusin.
Los pequeos cambios o errores que surgen en el software
completo puede causar mucho problema.

20 Pgina

 Es difcil en condiciones de mencionar si lo que se ha diseado

es exactamente lo que haba pedido

3.2. Ciclo de vida en V

El modelo en V es una variacin del modelo en cascada que muestra
cmo se relacionan las actividades de prueba con el anlisis y el
diseo. El modelo de ciclo de vida V proviene del principio que
establece que los procedimientos utilizados para probar si la
aplicacin cumple las especificaciones ya deben haberse creado en la
fase de diseo

Es un proceso que representa la secuencia de pasos en el desarrollo

del ciclo de vida de un proyecto. Se describen las actividades y
resultados que deben producirse durante el desarrollo del producto. El
lado

izquierdo

de

la V representa

la

descomposicin

de

las

necesidades, y la creacin de las especificaciones del sistema. El lado

derecho de la V representa la integracin de las piezas y su
verificacin. V significa Verificacin y validacin. Es muy similar
al modelo de la cascada clsico ya que es muy rgido y contiene una
gran cantidad de iteraciones.

3.2.1. Objetivos
Proporciona una gua para la planificacin y realizacin
de proyectos. Los siguientes objetivos estn destinados a ser
alcanzados durante la ejecucin del proyecto:

Minimizacin de los riesgos del proyecto

21 Pgina

 Mejora y Garanta de Calidad

Reduccin de los gastos totales durante todo el proyecto y
sistema de Ciclo de Vida
Mejora de la comunicacin entre todos los inversionistas
3.2.2. Partes del mtodo
El Mtodo-V es una representacin grfica del ciclo de vida del
desarrollo del sistema. Resume los pasos principales que hay
que tomar en conjuncin con las correspondientes entregas de
los sistemas de validacin.

La

corriente

de

especificacin

(parte

izquierda, Project

definition) consiste principalmente de:

Conceptos de operaciones: que debe hacer el sistema a
grandes rasgos.
Requisitos del sistema y arquitectura del mismo.
Diseo detallado.
La corriente de pruebas (parte derecha, Project test and
integration), por su parte, suele consistir de:
22 Pgina

 Integracin de las distintas partes, prueba y verificacin de las

mismas.
Verificacin y validacin del sistema en conjunto.
Mantenimiento del sistema.
La corriente de desarrollo puede consistir (depende del tipo
de sistema y del alcance del desarrollo) en personalizacin,
configuracin o codificacin.
3.2.3. VENTAJAS:
El modelo en V hace ms explcita la tarea parte de la
iteracin de las actividades del proceso.
Las pruebas de cada fase ayudaran a corregir posibles
errores sin tener que esperar a que sean rectificados en la
etapa final del proceso.
Con las pruebas unitarias y de integracin se consigue
obtener exactitud en los programas.
3.2.4. DESVENTAJAS:
Al encontrarse errores luego de realizar las pruebas se pierde
tiempo y dinero, ya que cada prueba se realiza luego de
haber terminado la implementacin.
En el caso de este modelo son, obviamente, ms las ventajas
que encontramos, hace el proceso ms dinmico, con la
opcin de realizar pruebas que nos ayudarn a corregir
posibles errores durante su fase de desarrollo adems de
poseer ventajas realmente notables que lo convierten en un
modelo ms completo y robusto que nos ayudaran a obtener
un sistema de mejor calidad.
3.3. Ciclo de vida Espiral
23 Pgina

El desarrollo en espiral es un modelo de ciclo de vida del software

definido

por

primera

vez

por Barry

Boehm en

1986, utilizado

generalmente en la Ingeniera de software. Las actividades de este

modelo se conforman en una espiral, en la que cada bucle
o iteracin representa un conjunto de actividades. Las actividades no
estn fijadas a ninguna prioridad, sino que las siguientes se eligen en
funcin del anlisis de riesgo, comenzando por el bucle interior.

Este sistema es muy utilizado en proyectos grandes y complejos como

puede ser, por ejemplo, la creacin de un Sistema Operativo. Al ser un
modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que
uno de los aspectos fundamentales de su xito radica en que el
equipo que lo aplique tenga la necesaria experiencia y habilidad para
detectar y catalogar correctamente los riesgos.

3.3.1. Regiones de tareas

El modelo en espiral se divide en un nmero de actividades de
marco de trabajo, tambin llamadas regiones de tareas.
Generalmente, existen entre tres y seis regiones de tareas.

24 Pgina

3.3.1.1. Comunicacin con el cliente: Las tareas requeridas

para establecer comunicacin entre el desarrollador y el
cliente.
3.3.1.2. Planificacin: Las tareas requeridas para definir
recursos, el tiempo y otra informacin relacionadas con
el proyecto.
3.3.1.3. Anlisis de riesgos: Las tareas requeridas para
evaluar riesgos tcnicos y de gestin.
3.3.1.4. Ingeniera: Las tareas requeridas para construir una o
ms representaciones de la aplicacin.
3.3.1.5. Construccin y accin: Las tareas requeridas para
construir, probar, instalar y proporcionar soporte al
usuario (por ejemplo: documentacin y prctica).
3.3.1.6. Evaluacin del cliente: Las tareas requeridas para
obtener la reaccin del cliente segn la evaluacin de
las representaciones del software creadas durante la
etapa de ingeniera e implementada durante la etapa de
instalacin
3.4. Ciclo de vida Incremental

25 Pgina

El modelo incremental fue propuesto por Harlan Mills en el ao 1980.

Surgi el enfoque incremental de desarrollo como una forma de reducir
la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de
retrasar la toma de decisiones en los requisitos hasta adquirir
experiencia con el sistema. Este modelo se conoce tambin bajo las
siguientes denominaciones:
Mtodo de las comparaciones limitadas sucesivas.
Ciencia de salir del paso.
Mtodo de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial
con la filosofa interactiva de Construccin de Prototipos. Como se
muestra en la figura, el modelo incremental aplica secuencias lineales de
forma escalonada mientras progresa el tiempo en el calendario. Cada
secuencia lineal produce un incremento del software. El primer
incremento generalmente es un producto esencial denominado ncleo.
En una visin genrica, el proceso se divide en 4 partes:
Anlisis
Diseo
Cdigo
Prueba

26 Pgina

Sin embargo, para la produccin del Software, se usa el principio de

trabajo en cadena o Pipeline. 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 elabora el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Un modelo incremental lleva a pensar en un desarrollo modular, con
entregas parciales del producto Software denominados "incrementos" del
sistema, que son escogidos en base a prioridades predefinidas de algn
modo. El modelo permite una implementacin con refinamientos
sucesivos (ampliacin y/o mejoras). Con cada incremento se agrega
nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la
versin previamente implementada del producto software.
3.4.1. 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.
Resulta ms sencillo acomodar cambios al acotar el tamao de
los incrementos.
3.4.2. Desventajas

27 Pgina

 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.
3.5. Ciclo de vida Prototipado
El modelo de ciclo de vida de prototipos fue propuesto por Gomaa en
1984.
Un prototipo es un mecanismo para identificar los requisitos del software.
La construccin de prototipos es un proceso que facilita al ingeniero de
software el desarrollo de la aplicacin. El prototipo suele tomar una de
las tres formas siguientes:
Un modelo en papel o en computadora que describe la interaccin
hombre-mquina, de forma que facilite al usuario la comprensin de su
funcionamiento. Por ejemplo, si el sistema a construir es un cajero
automtico, se puede hacer un programa que simule la interaccin del
usuario con el cajero sin que el programa est conectado a ninguna base
de datos real ni se despache dinero. De esta manera el cliente puede
hacerse a la idea de cmo va a funcionar el sistema final sin tener que
construirlo, y as discutirlo con el ingeniero de software. Naturalmente, en
un prototipo no se simularn todas las funcionalidades del sistema pero,
si es necesario, se podrn construir otros a medida que la aplicacin se
vaya desarrollando

28 Pgina

3.5.1. Ventajas
Permite la construccin del sistema con requisitos poco claros o
cambiantes
El cliente recibe una versin del sistema en muy poco tiempo,
por lo que lo puede evaluar, probar e, incluso, empezar a
utilizarlo.
Se pueden introducir cambios en las funcionalidades del
sistema en cualquier momento.
Involucra al usuario en la evaluacin de la interfaz de usuario.
Se reduce el riesgo y la incertidumbre sobre el desarrollo.
Genera signos visibles de progreso, que se utilizan cuando
existe una demanda en la velocidad del desarrollo.
Permite entender bien el problema antes de la implementacin
final.
3.5.2. Desventajas
El cliente puede quedar convencido con las primeras versiones
y, quizs, no vea la necesidad de completar el sistema o
redisearlo con la calidad necesaria

29 Pgina

 Requiere trabajo del cliente para evaluar los distintos prototipos

y traducirlo en nuevos requisitos.
Requiere un tiempo adicional para definir adecuadamente el
sistema.
No se sabe exactamente cunto ser el tiempo de desarrollo ni
cuantos prototipos se tienen que desarrollar.
Si un prototipo fracasa, el coste del proyecto puede resultar muy
caro.

30 Pgina

4. GLOSARIO
IEEE

Institute of Electrical and Electronics Engineers.

ISO

International Organization for Standardization.

IEC

International Electrotechnical Commission

SRD

Documento de especificacin de requisitos

SDD

Documento de Diseo del Software

CASE

Computer Aided Software Engineering

Ingeniera de Software Asistida por Computadora

SDLC

Ciclo de vida del desarrollo Software

31 Pgina

Captulo I
Proceso de produccin de bienes o prestacin de servicio (describe lnea de
accin)
BLOG (CMO Y EN QU ?SERVIDOR LO CREAN PASO A PASO)
1. Recursos
Equipo de computacin (Lapto, Pc)
Lenguaje de programacin
Software
Internet
1.1

Talento Humano:
Estudiante
Jean Carlos Rugel Lima
Jefferson Guido Cedeo Pionce
Tutor

1.2

Tecnolgicos:
Internet
Computadora
Biblioteca virtual

1.3

Recursos financieros:
N
2
4

Descripcin

Ingreso

Egreso

Tecnologa
Alimentacin
Aporte personal
Total

32 Pgina

CRONOGRAMA

33 Pgina

CONCLUCIONES

34 Pgina

RECOMENDACIONES

35 Pgina

BIBLIOGRAFA
http://www.ecured.cu/Ciclo_de_vida_del_software
http://www.jroliva.com/fernando/An%C3%A1lisis/Teoria/Tema2.pdf
http://ocw.uc3m.es/ingenieria-informatica/desarrollo-de-sistemas-deinformacion-corporativos-1/documentos/gestion-integral-del-proyecto
https://www.google.com.ec/search?
q=Familia+ISO+9000&espv=2&biw=1024&bih=643&source=lnms&tbm=
isch&sa=X&ved=0ahUKEwjVkK_F0dbJAhVG6SYKHX4MCVgQ_AUIBig
B#imgrc=8rbffKqiy1VNPM%3A
http://www.hanantek.com/es/modelos-ciclo-vida-software
https://es.wikipedia.org/wiki/M%C3%A9todo_en_V
http://quecomputadoracomprar.com/ventajas-y-desventajas-modelocascada/
https://ingsoft2euh.wordpress.com/2012/09/16/modelo-en-v-ventajas-ydesventajas/
https://es.wikipedia.org/wiki/Desarrollo_en_espiral
http://sofware1nathalygrijalva.blogspot.com/2012/10/modelo

espiral.html
https://procesosoftware.wikispaces.com/Modelo+Incremental
http://spanishpmo.com/index.php/ciclos-de-vida-prototipo/
https://es.wikipedia.org/wiki/Herramienta_CASE
http://www.tutorialspoint.com/es/software_engineering/software_develo

pment_life_cycle.htm
http://www.construction21.org/espana/community/pg/pages/view/539/

RESPONSABLES
36 Pgina

_____________________

_________________________

Jean Carlos Rugel Lima

Jefferson Guido Cedeo Pionce

Director del Proyecto

___________________________

Lcdo(a)________

37 Pgina

ANEXOS
ANEXO N 1
Modelo de Proceso: IEEE 1074

38 Pgina

ANEXO N 2
Modelo de Proceso: Familia ISO 9000

39 Pgina

ANEXO N 3
Modelo de Proceso: ISO 12207

2. MARCO VALORATIVO SEGUIMIENTO Y ACOMPAAMIENTO

40 Pgina