Analisis de Sistemas

Ao de la Consolidacin del Mar de Grau
UNIVERSIDAD NACIONAL SAN LUIS

GONZAGA
FACULTAD DE INGENIERA DE SISTEMAS
DISEO E IMPLEMENTACION DE
SISTEMAS
DOCENTE:
Ing. Jhon Romero Lovera
TEMA:
Anlisis de Sistemas
INTEGRANTES:
Beltran Ramos, Renzo Armando
Campos Navarro, Luis Miguel
Castaeda Gutirrez, Jess
De la cruz Apari, Joan Kimberly
Garibay Cadenas, Vctor Alfredo
Morales Muoz, Michael
Ramos Gutirrez, Juan ngel
Ricalde Vega, Harold Steve
Salcedo Vlchez, Almamia Indalicia
Ciclo:
VIII
ICA PERU
2016
ANALISIS DE SISTEMAS
DEDICATORIA
Este presente trabajo est dedicado a
Dios, por brindarme la dicha de la
salud y bienestar fsico y espiritual. A
mis padres, por los innumerables
motivos hayan logrado encaminarnos
por el buen camino y as lograr
nuestros objetivos.
A nuestros ingenieros por su tiempo,
por su apoyo as como por la
sabidura que nos transmiten en el
desarrollo de nuestra formacin
NDICE
INTRODUCION
1. CICLO DE VIDA DEL SOFTWARE..
Pgina 3
Pgina 4
1
2. MODELOS DE CICLO DE VIDA DE UN SISTEMA

3. OBJETIVOS DEL ANLISIS DE SISTEMA DE INFORMACIN..
4. PLANIFICACIN
5. ANLISIS.
6. METODOLOGAS DE ANLISIS DE REQUERIMIENTOS..
7. METODOLOGAS TRADICIONALES Y GILES..
8. ESPECIFICACIN DEL SOFTWARE..
9. INGENIERA DE REQUERIMIENTOS.
10. VALIDACION DEL SOFTWARE..
11. REQUERIMIENTOS DEL SISTEMA.
12. ESPECIFICACIN DE LOS REQUERIMIENTOS
13. ERS( ESPECIFICACION DE REQUISITOS DEL SOFTWARE...
Pgina 4
Pgina 12
Pgina 13
Pgina 20
Pgina 23
Pgina 24
Pgina 29
Pgina 29
Pgina 29
Pgina 30
Pgina 30
Pgina 31
INTRODUCCION
El Anlisis de Sistemas trata bsicamente de determinar los
objetivos y lmites del sistema objeto de anlisis, caracterizar su
estructura y funcionamiento, marcar las directrices que permitan
alcanzar los objetivos propuestos y evaluar sus consecuencias.
2
Dependiendo de los objetivos del anlisis, podemos encontrarnos

ante dos problemticas distintas:
Anlisis de un sistema ya existente para comprender,
mejorar, ajustar y/o predecir su comportamiento.
Anlisis como paso previo al diseo de un nuevo sistemaproducto.
En cualquier caso, podemos agrupar ms formalmente las tareas
que constituyen el anlisis en una serie de etapas que se suceden
de forma iterativa hasta validar el proceso completo:
Conceptualizacin
Consiste en obtener una visin de muy alto nivel del sistema,
identificando sus elementos bsicos y las relaciones de stos
entre s y con el entorno.
Anlisis funcional
Describe las acciones o transformaciones que tienen lugar en el
sistema. Dichas acciones o transformaciones se especifican en
forma de procesos que reciben unas entradas y producen unas
salidas.
Anlisis de condiciones (o constricciones)
Debe reflejar todas aquellas limitaciones impuestas al sistema
que restringen el margen de las soluciones posibles.
ANLISIS DE SISTEMAS
3
1.-CICLO DE VIDA DEL SOFTWARE.

Describe el desarrollo de software desde la fase inicial hasta la
fase final, proponiendo etapas que sirven como referencia para
realizar este proceso. Las fases que conforman el ciclo de vida
son:
Preanlisis
Anlisis
Diseo
Desarrollo
Pruebas
Implantacin
Mantenimiento
2.-MODELOS DE CICLO DE VIDA DE UN SISTEMA.

El modelo en cascada:
Tambin llamado ciclo de vida clsico o tradicional, es el modelo
ms antiguo cuya propuesta de trabajo se fundamenta en un
proceso ordenado y secuencial donde el producto de cada etapa,
es el insumo para la etapa posterior. Las caractersticas
principales de este modelo son:
Se recomienda para el desarrollo de

productos de gran tamao
cuyo tiempo de entrega sea
largo.
No
se
requiere
demasiada
experiencia por parte del
equipo de trabajo
El inicio de una etapa debe esperar la
finalizacin de la etapa anterior
La documentacin del proceso realizado, se produce en cada
etapa
Se pueden presentar iteraciones entre las etapas del
desarrollo, pero resultan costosas e implican repetir el trabajo.
Cuando se trata de nuevos desarrollos, los requisitos del
producto deben estar bien definidos y ser estables.
Si se trata de una adaptacin o una mejora de un producto
existente, los requisitos deben entenderse de manera razonable.
Un error encontrado en la etapa de pruebas, conduce al
rediseo del producto
Los primeros resultados se obtienen despus de un tiempo
considerable
El modelo en V:
Se considera como una versin mejorada del modelo en cascada
y por tanto, conserva las caractersticas de secuencialidad y
organizacin. El modelo en V fundamenta su enfoque en la
5
minimizacin de riesgos, la mejora de calidad, la reduccin total

de gastos y el perfeccionamiento de la comunicacin entre los
participantes del proyecto de desarrollo de software. Adems,
incorpora
procesos
de
verificacin
y
validacin.
Las
caractersticas de este modelo son:
S
e
recomienda
para
el
desarrollo
de
productos
pequeos con
equipos
de
trabajo de hasta cinco
integrantes.
Ideal
para
los
analistas que no han
programado siguiendo un modelo
El inicio de una etapa debe esperar la finalizacin de la
etapa anterior
La documentacin del proceso realizado, se produce en cada
etapa
Contiene etapas de retroalimentacin para facilitar
correcciones
El modelo no contempla la posibilidad de retornar a etapas
inmediatamente anteriores, situacin que en la realidad puede
ocurrir.
Las pruebas comienzan a efectuarse despus de la
implantacin, esto puede conducir a un retroceso de todo un
proceso que cost tiempo y dinero.
Prototipos:
6
Este modelo tambin se ha llamado evolutivo, se fundamenta en

el desarrollo de un producto inicial que se presenta al usuario
para obtener su aprobacin y se perfecciona, a travs de
diferentes versiones, hasta obtener el producto adecuado. El
modelo por prototipo se caracteriza por:
Es un
menos
formal
de
desarrollo
Se
recomienda
modelo
para
el
desarrollo de
productos
pequeos o
de tamao
medio
til cuando se desconocen los requerimientos del producto o

son poco estables
Proporciona rapidez en el proceso de desarrollo
Conveniente
en
desarrollos
que
requieren
probar
arquitecturas y tecnologas
La posibilidad de establecer el nmero de iteraciones
necesarias para obtener el producto definitivo, es mnima.
La documentacin del proceso se realiza sobre la versin
final del producto
A medida que avanza el proceso, incorporar cambios en los
prototipos se convierte en una tarea difcil y costosa.
La tcnica de los prototipos se puede implementar dentro de
cualquier modelo de proceso.
Espiral:
Se trata de una propuesta que combina las propiedades de los
modelos cascada y prototipos. Se fundamenta en un proceso de
desarrollo en el cual se hacen entregas del producto -cada una
ms evolucionada o completa que la anterior- teniendo en cuenta
7
los riesgos que pueden afectar el proceso. Cada ciclo del espiral
representa una etapa del ciclo de vida del software. Las
caractersticas principales del modelo en espiral son:
Es
un
enfoque
acertado
para el
desarrollo de software a gran

escala
Cada iteracin incluye definicin de objetivos, evaluacin y
reduccin de riesgos, desarrollo y validacin y planificacin.
Exige cuidado con el tratamiento de los riesgos que se
presentan en el proceso
Requiere habilidad para evaluar el riesgo y resolverlo
efectivamente
Si se pasa por alto un riesgo, surgirn dificultades en el
proceso
El producto evoluciona conforme avanza el proceso de
desarrollo
Desarrollo Rpido de Aplicaciones (DRA)

El modelo DRA es una versin que integra las caractersticas de
los modelos cascada y prototipos, aadiendo velocidad de
desarrollo. Propone la divisin del proyecto en mdulos que son
8
desarrollados por cada equipo de trabajo y luego se integran para

configurar el producto definitivo.
Ofrece
proceso
de
Requiere
el
desarrolladores y
flexibilidad
al
desarrollo
compromiso de los
los
clientes
Los requisitos
del
producto
deben
ser
comprendidos
desde el inicio
Aquellos
productos
de
software que se
puedan dividir en
mdulos, cuyo tiempo de desarrollo no exceda los tres meses,
pueden abordarse con este modelo.
Resalta el uso de componentes de software existente
Apoya la construccin del producto con la generacin

automtica de cdigo
Modelo incremental
Combina elementos del modelo tradicional aplicado en forma
iterativa. Este modelo emplea secuencias lineales escalonadas
que proporcionan incrementos del producto.
Requiere
de
la
planeacin
del
desarrollo
de
acuerdo
con las prioridades
del
producto
de
funcionalidad establecidas por el cliente.

Requiere poco personal para el desarrollo de los incrementos
iniciales, pero se puede vincular nuevo personal si los
incrementos as lo exigen.
El primer incremento es un producto que incorpora las
funcionalidades prioritarias completamente funcionales.
La evaluacin del incremento, por parte del cliente, origina
un plan para el desarrollo del incremento siguiente.
Cada incremento integra nuevas funcionalidades al producto
Modelo de proceso de software:

Los seis modelos analizados anteriormente, son marcos de
trabajo que guan el proceso de desarrollo de un producto
software, es decir son modelos de proceso de software.
Obsrvese que cada uno de ellos aplica un enfoque particular.
Adems, tenemos otros modelos que son los siguientes:
Modelo repetitivo
Este modelo gua el proceso de desarrollo de software en
repeticiones. Proyecta el proceso de desarrollo de forma cclica
repitiendo cada paso despus de cada ciclo en el proceso de
SDLC.
10
El software primero se desarrolla en menor escala y se siguen y

tienen en consideracin todos los pasos. Entonces, por cada
repeticin, ms mdulos y caractersticas son diseados,
codificados, evaluados y aadidos al software. Cada ciclo produce
un sotware completo, con ms caractersticas y capacidad que
los previos.
Despus de cada repeticin, el equipo directivo puede
concentrarse en la gestin de riesgos y prepararse para la
siguiente repeticin. Como el ciclo incluye pequeas porciones de
la totalidad del proceso software, es ms fcil gestionar el
proceso de desarrollo, pero a la vez se consumen ms recursos.
Modelo Big Bang
Este modelo es el modelo con la forma ms simple. Requiere

poca planificacin, mucha programacin y tambin muchos
fondos. Este modelo se conceptualiza alrededor de la teora de
creacin del universo 'Big Bang'.
Tal como
galaxias,
manera,
podemos
cuentan los cientficos, despus del big bang muchas

planetas y estrellas evolucionaron. De la misma
si reunimos muchos fondos y programacin, quiz
conseguir el mejor producto de software.
11
Para este modelo, se requiere poca planificacin. No sigue ningn

proceso concreto, y a veces el cliente no est seguro de las
futuras necesidades y requisitos. Por tanto, la entrada o input
respecto a los requisitos es arbitraria.
Este modelo no es recomendable para grandes proyectos de
software, pero es bueno para aprender y experimentar.
3.-OBJETIVOS
DEL
INFORMACIN.
ANLISIS
DE
SISTEMA
DE
Identificacin de Necesidades
Es el primer paso del anlisis del sistema, en este proceso el
Analista se rene con el cliente y/o usuario (un representante
institucional, departamental o cliente particular), e identifican las
metas globales, se analizan las perspectivas del cliente, sus
necesidades y requerimientos, sobre la planificacin temporal y
presupuestal, lneas de mercadeo y otros puntos que puedan
ayudar a la identificacin y desarrollo del proyecto.
Antes de su reunin con el analista, el cliente prepara un

documento conceptual del proyecto, aunque es recomendable
que este se elabore durante la comunicacin Cliente analista, ya
que de hacerlo el cliente solo de todas maneras tendra que ser
modificado, durante la identificacin de las necesidades.
12
Estudio de Viabilidad
Muchas veces cuando se emprende el desarrollo de un proyecto
de Sistemas los recursos y el tiempo no son realistas para su
materializacin sin tener prdidas econmicas y frustracin
profesional. La viabilidad y el anlisis de riesgos estn
relacionados de muchas maneras, si el riesgo del proyecto es
alto, la viabilidad de producir software de calidad se reduce, sin
embargo, se deben tomar en cuenta cuatro reas principales de
inters:
Viabilidad econmica
Una evaluacin de los costos de desarrollo, comparados con
los ingresos netos o beneficios obtenidos del producto o Sistema
desarrollado.
Viabilidad Tcnica
Un estudio de funciones, rendimiento y restricciones que puedan
afectar la realizacin de un sistema aceptable.
Viabilidad Legal
Es determinar cualquier posibilidad de infraccin, violacin
o responsabilidad legal en que se podra incurrir al desarrollar el
Sistema.
Alternativas
13
Una evaluacin de los enfoques alternativos del desarrollo del

producto o Sistema.El estudio de la viabilidad puede
documentarse como un informe aparte para la alta gerencia.
4.- PLANIFICACIN.
Antes de que se le d oficialmente el pistoletazo de salida a un
proyecto de desarrollo de un sistema de informacin, es necesario
realizar una serie de tareas previas que influirn decisivamente
en la finalizacin con xito del proyecto. Estas tareas se conocen
popularmente como el fuzzy front-end del proyecto al no estar
sujetas a plazos.
Las tareas iniciales que se realizarn esta fase inicial del proyecto
incluyen actividades tales como la determinacin del mbito del
proyecto, la realizacin de un estudio de viabilidad, el anlisis de
los riesgos asociados al proyecto, una estimacin del coste del
proyecto, su planificacin temporal y la asignacin de recursos a
las distintas etapas del proyecto.
Delimitacin del mbito del proyecto.

Resulta esencial determinar el mbito del proyecto al comienzo
del mismo. Han de establecerse de antemano qu cuestiones han
de resolverse durante la realizacin del proyecto y cules se
dejarn fuera. Tan importante es determinar los aspectos
abarcados por el proyecto como fijar aqullos aspectos que no se
incluirn en el proyecto. Estos ltimos han de indicarse
explcitamente.
Si es necesario, se puede especificar todo aquello que se
posponga hasta una versin posterior del sistema. Si, en algn
momento, fuese necesario incluir en el proyecto algn aspecto
que no haba sido considerado o que ya haba sido descartado, es
obligatorio reajustar la estimacin del coste del proyecto y su
planificacin temporal. Como resultado de la delimitacin del
mbito del proyecto se obtiene un documento breve, de 1 2
14
pginas, en el que se describe el problema que nuestro sistema

de informacin pretende resolver. Este documento, denominado a
veces mission statement o project charter, debe existir siempre
en todo proyecto.
En l se recoger la descripcin de ms alto nivel de la
funcionalidad que tendr nuestro sistema de informacin, sus
caractersticas principales y sus objetivos clave. Obviamente, este
documento debe formar parte del contrato que se firme con el
cliente en el arranque oficial del proyecto. Adems de ser breve,
una buena descripcin del proyecto debe superar con xito la
prueba del ascensor.
Debe estar escrito en un lenguaje que cualquiera pueda entender,
evitando un vocabulario excesivamente tcnico. Adems, debe
recoger todo lo que le contaramos a un conocido en unos
segundos acerca del proyecto en el que estamos trabajando si
nos lo cruzramos por la calle o nos lo encontrsemos en un
ascensor.
Estudio de viabilidad.
Con recursos ilimitados (tiempo y dinero), casi cualquier proyecto
se podra llevar a buen puerto. Por desgracia, en la vida real los
recursos son ms bien escasos, por lo que no todos los proyectos
son viables.
En un conocido informe de 1994 (el informe Chaos del Standish
Group), se hizo un estudio para determinar el alcance de la
conocida como "crisis crnica de la programacin" y, en la
medida de lo posible, identificar los principales factores que
hacen fracasar proyectos de desarrollo de software y los
ingredientes clave que pueden ayudar a reducir el ndice de
fracasos. De entre los proyectos analizados: - Slo uno de cada
seis se complet a tiempo, de acuerdo con su presupuesto y con
todas las caractersticas inicialmente especificadas. - La mitad de
los proyectos lleg a completarse eventualmente, costando ms
de lo previsto, tardando ms tiempo del estimado inicialmente y
con menos caractersticas de las especificadas al comienzo del
proyecto. - Por ltimo, ms de un 30% de los proyectos se cancel
antes de completarse.
15
Dado que cinco de cada seis proyectos analizados no se ajustaron

al plan previsto, no es de extraar que resulte aconsejable
realizar un estudio de viabilidad antes de comenzar el desarrollo
de un sistema de informacin para determinar si el proyecto es
econmica, tcnicas y legalmente viable. De hecho, lo primero
que deberamos hacer es plantearnos si la mejor opcin es
desarrollar un sistema informatizado o es preferible un sistema
manual. Algo as debieron hacer los rusos cuando decidieron
llevar lpices al espacio (segn dicen, los americanos gastaron
una fortuna hasta que inventaron un bolgrafo que funcionaba en
ausencia de gravedad).
Antes de comenzar un proyecto, se debera evaluar la viabilidad
econmica, tcnica y legal del mismo. Y no slo eso, el resultado
del estudio de viabilidad debera ajustarse a la realidad. A Jerry
Weinberg, un conocido consultor, se le ocurri preguntar a los
asistentes a una conferencia suya, en el Congreso Internacional
de Ingeniera del Software de 1987, cuntos de ellos haban
participado en un estudio de viabilidad en el que se hubiese
determinado que el proyecto no era tcnicamente viable. De los
mil quinientos asistentes, nadie levant la mano.
Anlisis de riesgos
Independientemente de la precisin con la que hayamos
preparado nuestro proyecto, siempre se produce algn
contratiempo que eche por tierra la mejor de las planificaciones.
Es algo inevitable con lo que hemos de vivir y para lo cual
disponemos de una herramienta extremadamente til: la gestin
de riesgos, que tradicionalmente se descompone en evaluacin
de riesgos y control de riesgos.
La evaluacin de riesgos se utiliza para identificar "riesgos" que
pueden afectar negativamente al plan de nuestro proyecto,
estimar la probabilidad de que el riesgo se materialice y analizar
su posible impacto en nuestro proyecto. Qu sucedera si algn
miembro clave del nuestro equipo abandona la empresa, se va de
vacaciones, se pone enfermo o pide una baja por depresin
causada por un entorno de trabajo hostil? y si al final nos
encontramos con algn problema de compatibilidad del sistema
que hemos desarrollamos con la configuracin de los equipos
sobre los que ha de funcionar? si, inadvertidamente, borramos o
modificamos errneamente algn que otro fichero clave? si
16
nuestro ordenador se avera? Una vez analizados los riesgos

potencialmente ms peligrosos, podemos recurrir a distintas
tcnicas de control de riesgos.
Por ejemplo, podemos elaborar planes de contingencia para los
riesgos que sean ms probables y de consecuencias ms
desastrosas para el proyecto. O tal vez seamos capaces de
eliminar el riesgo de raz (o mitigarlo) si buscamos alguna
alternativa en la que el riesgo identificado no pueda presentarse
(o se presente debilitado). Independientemente de la solucin por
la que optemos, el anlisis de riesgos nos ensea que hemos de
dejar un margen para imprevistos previsibles y aadir cierta
holgura a la planificacin de nuestro proyecto. Las hiptesis
barajadas al analizar riesgos potenciales pueden convertirse en
realidad y nunca est de ms dejar algo de margen de maniobra.
Estimacin
Sin duda, una de las tareas ms peliagudas de cualquier proyecto
de desarrollo de software es la estimacin inicial del coste de algo
que an no conocemos. De hecho, la realizacin de malas
estimaciones ha sido identificada como una de las dos causas
ms comunes del fracaso de un proyecto de desarrollo de
software (Glass, 2003). La otra es la existencia de requerimientos
inestables sujetos a continuos cambios.
Como dijo Bhr, la prediccin es difcil, especialmente si se trata
del futuro. Adems, la estimacin del coste asociado se suele
realizar en el peor momento posible: al comienzo, cuando menos
conocemos del proyecto y mayor es el margen del error de la
estimacin. Afortunadamente, existen algunas reglas heursticas
que nos pueden ayudar a estimar con una precisin razonable el
coste y duracin de un proyecto. El arte de una buena estimacin
est basado, fundamentalmente, en la experiencia del estimador.
Haber participado en proyectos de similares caractersticas puede
ser esencial para que seamos capaces de realizar una buena
estimacin. Tambin podemos obtener resultados aceptables si
tenemos en cuenta lo siguiente: - Nunca se ha de realizar una
estimacin sobre la marcha, por mucho que nos presionen. Una
respuesta apresurada slo sirve para pillarnos los dedos y que
despus no podamos cumplir con las expectativas que nosotros
mismos hemos creado.
17
Una estimacin siempre ha de ser meditada, tras un estudio

pormenorizado de los distintos factores que pueden afectar a la
realizacin de nuestro proyecto.
- La incertidumbre en la estimacin es inevitable, pero en
ocasiones puede reducirse. Cuantos ms datos histricos
recopilemos y ms precisa sea la informacin de la que
dispongamos acerca de nuestro proyecto, mejor ser nuestra
estimacin.
- Hemos de descomponer nuestro proyecto en tareas de la
granularidad adecuada. El error que se comete al estimar el
conjunto de las actividades del proyecto es mayor que el que se
comete cuando estimamos cada una de las actividades por
separado. Los errores que cometamos en las distintas
estimaciones tendern a compensarse (la ley de los grandes
nmeros en accin).
- Es muy frecuente subestimar el esfuerzo necesario cuando
descomponemos un problema complejo en multitud de tareas.
Esto se debe a que, durante el transcurso del proyecto, tambin
han de realizarse otras muchas tareas que probablemente
hayamos olvidado incluir en nuestra estimacin. Adems,
consideradas de forma independiente, las distintas tareas del
proyecto resultan aparentemente ms fciles de realizar de lo que
en
realidad
son.
- Resulta aconsejable utilizar varias tcnicas de estimacin y
contrastar los resultados con ellas obtenidos. Por ejemplo,
podemos realizar una estimacin en funcin del coste un proyecto
similar, utilizar algn modelo matemtico de estimacin
(COCOMO o similar) y realizar una tercera estimacin
descomponiendo nuestro proyecto en tareas. Si los resultados
obtenidos con las distintas tcnicas de estimacin son similares,
probablemente nuestra estimacin sea buena.
Planificacin temporal y asignacin de recursos
Una vez que hemos decidido seguir adelante con nuestro
proyecto, hemos de planificar su temporizacin. Una planificacin
excesivamente detallada (con el proyecto descompuesto en
tareas de un da, por ejemplo) puede resultar contraproducente.
Cualquier error de planificacin causado por algn imprevisto nos
18
forzar a replanificar el resto del proyecto, retrasando an ms

nuestro proyecto.
Una planificacin por semanas suele ser razonable para afrontar
con comodidad las contingencias con las que nos vayamos
encontrando sin tener que estar continuamente reajustando el
plan del proyecto. Pase lo que pase, la planificacin del proyecto
ha de reajustarse cada vez que cambien las circunstancias del
mismo. Si no se ha podido terminar una tarea en el tiempo
inicialmente establecido, no nos vale suponer alegremente que
posteriormente se recuperar el tiempo perdido. Los proyectos se
retrasan poco a poco.
Debemos aprovechar las primeras seales de alarma y no
esconderlas debajo de la alfombra fingiendo que todo marcha
segn lo previsto. Tampoco vale decir que algo est casi
terminado. O lo est o no lo est. Si no lo est, el plan ha de
ajustarse a la situacin real del proyecto. Pensar que algo est
casi acabado slo para darnos una falsa sensacin de seguridad.
Adems, el 10% final de algo tiende a requerir el 90% del tiempo,
as que no nos sirve de nada saber que hemos realizado 80% del
esfuerzo si no podemos asegurar a qu parte corresponde el 20%
que nos queda (a la que se termina rpidamente o a la que
consume la mayor parte de nuestro tiempo?). Como dice un viejo
adagio: "la primera mitad se lleva el 90% del tiempo; la segunda,
el 90% restante".
No use nunca en su planificacin el hecho de que determinadas
actividades del proyecto estn casi terminadas. La planificacin
es fundamental en la gestin de un proyecto de desarrollo de
software. Procure siempre mantener su plan al da. Un plan que
no se ajusta a la realidad no sirve de mucho.
Cuando algn retraso indique que posiblemente le ser imposible
cumplir los plazos establecidos, hable con su cliente. A l le
interesa saberlo y, aunque probablemente no se lo agradezca, a
la larga resultar beneficioso y usted habr cumplido con su
obligacin profesional.
Algunos errores comunes
19
Cuando las cosas no marchen del todo bien, hemos de evitar

tomar algunas medidas que lo nico que conseguirn es
perjudicarnos. Aqu van algunas de las ms comunes:
- Abreviar las etapas iniciales del proceso de desarrollo de
software (planificacin y anlisis, generalmente) para pasar
directamente a la "construccin" del sistema. Los errores
cometidos en las fases iniciales de un proyecto son mucho ms
costosos de corregir a la larga, por lo que abreviar las etapas
iniciales tiene graves consecuencias.
- No gestionar adecuadamente los cambios que inevitablemente
ocurren durante el proyecto. Tan malo es permitir cualquier
cambio de forma indiscriminada como ser excesivamente rgidos
a la hora de no admitir cambios, aunque stos sean razonables.
- Reducir la interaccin con el cliente, ya que aparentemente slo
se dedica a entorpecer nuestro trabajo con sus continuos cambios
de opinin y sus expectativas poco realistas. Craso error. Al fin y
al cabo, el cliente es la persona cuyas necesidades hemos de
descubrir y satisfacer.
- Olvidar que aadir personal a un proyecto retrasado, por lo
general, slo lo retrasa ms (la ley de Brooks). La curva de
aprendizaje que se necesita para comenzar a ser productivo ha
de tenerse siempre en cuenta. Adems, quin le resuelve las
dudas al recin incorporado? El tiempo que empleen los dems
miembros del equipo ser tiempo que no podrn utilizar en otras
cosas.
- Someter a los miembros de nuestro equipo a continuas
interrupciones durante su jornada de trabajo (llamadas
telefnicas, reuniones, consultas...). La calidad del trabajo
intelectual depende de la capacidad del trabajador de mantener
su "estado de flujo" (un estado relajado de inmersin total en un
problema que facilita su comprensin y la generacin de
soluciones). Se tarda unos 15 minutos en conseguir este estado,
por lo que una simple interrupcin cada 10 minutos afecta
drsticamente al rendimiento del trabajador.
- Hacer trabajar horas extra a los miembros del equipo de
desarrollo slo sirve para disminuir su productividad (trabajo
20
realizado por unidad de tiempo). Tras una larga jornada de

trabajo, la mente pierde su frescura y comete errores que luego
tendrn que corregirse. Adivina cmo? Con ms horas extra.
- No informar de pequeos retrasos pensando que ms tarde se
recuperar el tiempo perdido. La planificacin temporal del
proyecto debe ir ajustndose conforme vamos aprendiendo ms
cosas acerca del problema al que nos enfrentamos. En el peor de
los casos, se deben negociar algunos recortes con el cliente si
ste desea mantener los plazos estipulados al comienzo del
proyecto.
- Confiar excesivamente en la mejora de rendimiento que se
producir gracias al uso de una nueva herramienta, tecnologa o
metodologa (error conocido como el "sndrome de la bala de
plata" en honor a un artculo muy recomendable escrito por Fred
Brooks: No silver bullets - Essence and accidents of Software
Engineering, Computer, 1987). Observe el tipo de errores
comunes que aparece en la lista anterior. En general, no prestar
la debida atencin a las necesidades de los integrantes del equipo
de desarrollo o a las del cliente garantiza que un proyecto no
terminar con xito. El factor humano es ms importante que el
tcnico.
5.ANLISIS.
Lo primero que debemos hacer para construir un sistema de
informacin es averiguar qu es exactamente lo que tiene que
hacer el sistema. La etapa de anlisis en el ciclo de vida del
software corresponde al proceso mediante el cual se intenta
descubrir qu es lo que realmente se necesita y se llega a una
comprensin adecuada de los requerimientos del sistema (las
caractersticas que el sistema debe poseer). Por qu resulta
esencial la etapa de anlisis?
Simplemente, porque si no sabemos con precisin qu es lo que
se necesita, ningn proceso de desarrollo nos permitir obtenerlo.
El problema es que, de primeras, puede que ni nuestro cliente
sepa de primeras qu es exactamente lo que necesita. Por tanto,
deberemos ayudarle a averiguarlo con ayuda de distintas tcnicas
(algunas de las cuales aprenderemos a utilizar ms adelante).
21
Por qu es tan importante averiguar exactamente cules son los

requerimientos del sistema si el software es fcilmente maleable
(aparentemente)? Porque el coste de construir correctamente un
sistema de informacin a la primera es mucho menor que el coste
de construir un sistema que habr que modificar ms adelante.
Cuanto antes se detecte un error, mejor.
Distintos estudios han demostrado que eliminar un error en las
fases iniciales de un proyecto (en la etapa de anlisis) resulta de
10 a 100 veces ms econmico que subsanarlo al final del
proyecto. Conforme avanza el proyecto, el software se va
describiendo con un mayor nivel de detalle, se concreta cada vez
ms y se convierte en algo cada vez ms rgido.
Es posible determinar de antemano todos los requerimientos de
un sistema de informacin? Desgraciadamente, no. De hecho,
una de las dos causas ms comunes de fracaso en proyectos de
desarrollo de software es la inestabilidad de los requerimientos
del sistema (la otra es una mala estimacin del esfuerzo
requerido por el proyecto).
En el caso de una mala estimacin, el problema se puede
solucionar estableciendo objetivos ms realistas. Sin embargo, en
las etapas iniciales de un proyecto, no disponemos de la
informacin necesaria para determinar exactamente el problema
que pretendemos resolver. Por mucho tiempo que le dediquemos
al anlisis del problema (un fenmeno conocido como la parlisis
del anlisis). La inestabilidad de los requerimientos de un sistema
es inevitable. Se estima que un 25% de los requerimientos
iniciales de un sistema cambian antes de que el sistema
comience a utilizarse. Muchas prcticas resultan efectivas para
gestionar adecuadamente los requerimientos de un sistema y, en
cierto modo, controlar su evolucin. Un buen analista debera
tener una formacin adecuada en:
- Tcnicas de elicitacin de requerimientos.
- Herramientas de modelado de sistemas.
- Metodologas de anlisis de requerimientos.
22
Tcnicas de elicitacin de requerimientos

En la fase de anlisis, los errores ms difciles de corregir son los
causados por "requerimientos ausentes", generalmente en la
forma de suposiciones que se dan por sabidas, pero nunca se
llegan a plasmar explcitamente. Por este motivo, elicitar los
requerimientos de un sistema de informacin (esto es, obtener de
algn modo cules son realmente esos requerimientos) resulta
una actividad esencial en cualquier proceso de desarrollo de
software.
La elicitacin de requerimientos requiere previamente la
identificacin de las personas afectadas por el proyecto, sus
stakeholders (literalmente, los que apuestan algo), lo que incluye
desde el cliente que paga el proyecto hasta los usuarios finales de
la aplicacin, sin olvidarse de terceras personas y organizaciones
relacionadas indirectamente con el sistema que se va a
desarrollar (por ejemplo, empresas competidoras y organismos
reguladores).
En la elicitacin de requerimientos se recurre a distintas tcnicas
que favorezcan la comunicacin entre el analista y el resto de
personas involucradas, como puede ser la realizacin de
entrevistas (en las que importa no slo lo que se pregunta, sino
cmo se pregunta), el diseo de cuestionarios (cuando no
tenemos tiempo ni recursos para entrevistar personalmente a
todo el mundo) o el desarrollo de prototipos (para recoger
informacin que, de otra forma, no obtendramos hasta las etapas
finales del proyecto, cuando cualquier rectificacin saldra mucho
ms cara).
Tambin se puede observar el funcionamiento normal del entorno
en el que se instalar nuestro sistema o, incluso, participar
activamente en l (por ejemplo, desempeando temporalmente el
trabajo de los usuarios de nuestro sistema). Por ltimo, tambin
podemos investigar por nuestra cuenta consultando documentos
relacionados con el tema de nuestro proyecto o estudiando
productos similares que ya existan en el mercado.
Herramientas de modelado de sistemas.
23
Un modelo, bsicamente, no es ms que una simplificacin de la

realidad. El uso de modelos en la construccin de sistemas de
informacin resulta esencial por los siguientes motivos:
- Los modelos ayudan a comunicar la estructura de un sistema
complejo (y, por tanto, a comunicarnos con las dems personas
involucradas en un proyecto).
- Los modelos sirven para especificar el comportamiento deseado
del sistema (como gua para las etapas posteriores del proyecto).
- Los modelos nos ayudan a comprender mejor lo que estamos
diseando (por ejemplo, para detectar inconsistencias y
corregirlas).
- Los modelos nos permiten descubrir oportunidades de
simplificacin (ahorrarnos trabajo en el proyecto actual) y de
reutilizacin (ahorrarnos trabajo en futuros proyectos).
En resumidas cuentas, los modelos, entre otras cosas, facilitan el
anlisis de los requerimientos del sistema, as como su posterior
diseo e implementacin. Un modelo, en definitiva, proporciona
"los planos" de un sistema. El modelo ha de capturar "lo esencial"
desde determinado punto de vista.
En funcin de para qu queramos el modelo, lo haremos ms o
menos detallado, siempre de acuerdo a su relevancia y utilidad.
Un sistema de informacin es un sistema complejo, por lo que a
(casi) nadie se le ocurrira intentar describirlo utilizando un nico
modelo.
De hecho, todo sistema puede describirse desde distintos puntos
de vista y nosotros utilizaremos distintos tipos de modelos
dependiendo del aspecto del sistema en que deseemos centrar
nuestra atencin:
- Existen modelos estructurales que nos ayudan a la hora de
organizar un sistema complejo. Por ejemplo, un diagrama
entidad/relacin nos indica cmo se estructuran los datos de un
sistema de informacin, mientras que un diagrama de flujo de
datos nos da informacin acerca de cmo se descompone un
24
sistema en subsistemas y del flujo de datos que existe entre los

distintos subsistemas.
- Tambin existen modelos de comportamiento que nos permiten
analizar y modelar la dinmica de un sistema. Por ejemplo, un
diagrama de estados representa los distintos estados en que
puede encontrarse un sistema y cmo se puede pasar de un
estado a otro, mientras que la descripcin de un caso de uso nos
ayuda a comprender la secuencia de pasos involucrada en la
consecucin de un objetivo concreto por parte de un usuario del
sistema.
Metodologa del desarrollo de software
Una metodologa para el desarrollo de software son los procesos a
seguir sistemticamente para idear, implementar y mantener un
producto software desde que surge la necesidad del producto
hasta que cumplimos el objetivo por el cual fue creado.
6.METODOLOGAS DE ANLISIS DE REQUERIMIENTOS.

Las tcnicas de elicitacin de requerimientos y las herramientas
de modelado de sistemas de las que hemos hablado en los
prrafos anteriores deben utilizarse acompaadas de una
metodologa adecuada. En este contexto, una metodologa no es
ms que un conjunto de convenciones que han resultado tiles en
la prctica y cuyo uso combinado se recomienda.
Las metodologas de anlisis particulares, de las que hay muchas,
usualmente estn ligadas, o bien al uso de determinadas
herramientas (por lo que el vendedor de la herramienta se
convierte, muchas veces, en el nico promotor de la
metodologa), o bien a empresas de consultora concretas (que
ofrecen cursos de aprendizaje de la metodologa que proponen).
En general, no obstante, la eleccin adecuada de las tcnicas
utilizadas depender de la situacin concreta en la que se
encuentre nuestro proyecto. Por este motivo, lo ms adecuado es
aprender cuantas ms tcnicas mejor y averiguar en qu
situaciones resulta ms efectiva cada una de ellas.
25
7.METODOLOGAS TRADICIONALES Y GILES.

Desarrollar un buen software depende de un gran nmero de
actividades y etapas, donde el impacto de elegir la metodologa
para un equipo en un determinado proyecto es trascendental
para el xito del producto. Se pueden clasificar las metodologas
en dos grupos.
Las metodologas tradicionales, que se basan en una fuerte
planificacin durante todo el desarrollo, y las metodologas giles,
en las que el desarrollo de software es incremental, cooperativo,
sencillo y adaptado.
Metodologas tradicionales
Las metodologas tradicionales son denominadas, a veces, de
forma peyorativa, como metodologas pesadas. Centran su
atencin en llevar una documentacin exhaustiva de todo el
proyecto y en cumplir con un plan de proyecto, definido todo
esto, en la fase inicial del desarrollo del proyecto.
Otra de las caractersticas importantes dentro de este enfoque,
son los altos costes al implementar un cambio y la falta de
flexibilidad en proyectos donde el entorno es voltil. Las
metodologas tradicionales (formales) se focalizan en la
documentacin, planificacin y procesos (plantillas, tcnicas de
administracin, revisiones, etc.).
Rational Unified Process (RUP)
Forma disciplinada de asignar tareas y responsabilidades en el
desarrollo de un software (quin hace qu, cundo y cmo). Su
objetivo es asegurar la produccin de software de alta calidad que
satisfaga los requerimientos de los usuarios finales (respetando
cronograma y presupuesto).
Fue desarrollado por la empresa Rational Software, actualmente
propiedad de IBM. Junto con el Lenguaje Unificado de Modelado
UML, constituye la metodologa estndar ms utilizada para el
26
anlisis, diseo, implementacin y documentacin de sistemas

orientados a objetos.
Fases del ciclo de vida del RUP.
a) Inicio.
Esta fase tiene como propsito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos
asociados al proyecto, proponer una visin muy general de la
arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.
b) Elaboracin.
En la fase de elaboracin se seleccionan los casos de uso que
permiten definir la arquitectura base del sistema y se
desarrollaran en esta fase, se realiza la especificacin de los
casos de uso seleccionados y el primer anlisis del dominio del
problema, se disea la solucin preliminar.
c) Desarrollo
El propsito de esta fase es completar la funcionalidad del
sistema, para ello se deben clarificar los requerimientos
pendientes, administrar los cambios de acuerdo a las
evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
d) Cierre.
El propsito de esta fase es asegurar que el software est
disponible para los usuarios finales, ajustar los errores y
defectos encontrados en las pruebas de aceptacin, capacitar a
los usuarios y proveer el soporte tcnico necesario. Se debe
verificar que el producto cumpla con las especificaciones
entregadas por las personas involucradas en el proyecto.
Ventajas.
Evaluacin en cada fase que permite cambios de objetivos.
Funciona bien en proyectos de innovacin.
27
Es sencillo, ya que sigue los pasos intuitivos necesarios a la

hora de desarrollar el software.
Seguimiento detallado en cada una de las fases.
Desventajas
La evaluacin de riesgos es compleja
Excesiva flexibilidad para algunos proyectos
Estamos poniendo a nuestro cliente en una situacin que
puede ser muy incmoda para l.
Nuestro cliente deber ser capaz de describir y entender a
un gran nivel de detalle para poder acordar un alcance del
proyecto con l.
Metodologas Agiles
SCRUM
Scrum es un proceso en el que se aplican de manera regular un
conjunto de buenas prcticas para trabajar colaborativamente, en
equipo, y obtener el mejor resultado posible de un proyecto. En
Scrum se realizan entregas parciales y regulares del producto
final, priorizadas por el beneficio que aportan al receptor del
proyecto. Por ello, Scrum est especialmente indicado para
proyectos en entornos complejos, donde se necesita obtener
resultados pronto, donde los requisitos son cambiantes o poco
definidos, donde la innovacin, la competitividad, la flexibilidad y
la productividad son fundamentales.
Scrum tambin se utiliza para resolver situaciones en que no se
est entregando al cliente lo que necesita, cuando las entregas se
alargan demasiado, los costes se disparan o la calidad no es
aceptable, cuando se necesita capacidad de reaccin ante la
competencia, cuando la moral de los equipos es baja y la rotacin
alta, cuando es necesario identificar y solucionar ineficiencias
sistemticamente o cuando se quiere trabajar utilizando un
proceso especializado en el desarrollo de producto
28
El equipo Scrum
En Scrum tenemos lo que se llama Scrum team que consiste
en el propietario del producto, el equipo de desarrollo y el
Scrum master. Los equipos de Scrum se organizan a s mismos
lo que quiere decir que ellos mismos deciden la manera de
trabajar que mejor les convenga sin depender de que los dirija
nadie de fuera. Este modelo de equipo est diseado para
optimizar la flexibilidad, creatividad y productividad.
a) Propietario del producto

Es el responsable de maximizar el valor del producto y del
trabajo del equipo de desarrollo. El propietario del producto es
una persona (que puede estar representando a una empresa)
que trabaja junto al equipo de desarrollo. Su funcin no es
desarrollar el producto, su funcin es decir lo que quiere, cmo
lo quiere y qu es lo que quiere en cada iteracin. Se podra
decir que es la voz del cliente.
Para que el Dueo de Producto pueda hacer bien su trabajo,
toda la organizacin debe respetar sus decisiones y asimismo
es la nica persona responsable de gestionar la Lista del
Producto (Product Backlog).
b) Equipo desarrollo
Consiste en profesionales que desarrollan el producto y cuya
funcin es entregar versiones estables y funcionales del
producto al final de cada iteracin. Los equipos de desarrollo
tienen la capacidad para organizarse a s mismos. El tamao
del equipo debera ser de entre 3 y 9 personas.
c) Scrum master
Es la persona que mejor conoce y maneja Scrum en todo el
equipo. Es el responsable de que Scrum sea entendido y
promulgado. Entre sus funciones est ayudar al propietario del
producto a entender la planificacin y ayudar al equipo de
desarrollo a crear productos con gran valor, por ejemplo.
29
Artefactos de Scrum
a) El Product Backlog
El Product Backlog es un listado dinmico y pblicamente
visible para todos los involucrados en el proyecto. En l, el
Dueo de Producto, mantiene una lista actualizada de
requerimientos funcionales para el software. Esta lista,
representa "qu es lo que se pretende" pero sin mencionar
"cmo hacerlo", ya que eso ser tarea del Scrum Team. El
Product Backlog, es creado y modificado nicamente por el
Dueo de Producto. La lista tiene como caracterstica particular
que nunca est terminada, pues evoluciona durante el
desarrollo del proyecto.
b) El Sprint Backlog
El Sprint Backlog es la recopilacin sinttica de items del
Product Backlog, negociados entre el Dueo de Producto y el
Scrum Team en la ceremonia de planificacin, reunin que se
realiza al comienzo del Sprint. Esta recopilacin, que durante la
planificacin ha sido propuesta por el Dueo de Producto y ya
negociada, es aquella que el Scrum Team se compromete a
construir durante el Sprint en curso.
Debido a que el Product backlog est organizado por prioridad,
el Sprint backlog es construido con los requerimientos ms
prioritarios del Product backlog y con aquellos que quedaron
por resolver en el Sprint anterior. El Sprint Backlog,
generalmente (y muy recomendado), se visualiza mediante
tableros fsicos tambin llamados Scrum Taskboard - que
hacen visible el proceso de construccin, a toda persona que
ingrese al rea de desarrollo.
Metodologas tradicionales vs Metodologas giles
Tener metodologas diferentes para aplicar de acuerdo con el
proyecto que se desarrolle resulta una idea interesante. Estas
metodologas pueden involucrar prcticas tanto de metodologas
30
giles como de metodologas tradicionales. Las metodologas

tradicionales han intentado abordar la mayor cantidad de
situaciones de contexto del proyecto, exigiendo un esfuerzo
considerable para ser adaptadas, sobre todo en proyectos
pequeos y con requisitos muy cambiantes.
Las metodologas giles ofrecen una solucin casi a medida para
una gran cantidad de proyectos que tienen estas caractersticas.
Una delas cualidades ms destacables en una metodologa gil es
su sencillez, tanto en su aprendizaje como en su aplicacin,
reducindose as los costos de implantacin en un equipo de
desarrollo. Esto ha llevado hacia un inters creciente en las
metodologas giles.
Sin embargo, hay que tener presente una serie de inconvenientes
y restricciones para su aplicacin, tales como: estn dirigidas a
equipos pequeos o medianos, el entorno fsico debe ser un
ambiente que permita la comunicacin y colaboracin entre todos
los miembros del equipo durante todo el tiempo, cualquier
resistencia del cliente o del equipo de desarrollo hacia las
prcticas y principios puede llevar al proceso al fracaso (el clima
de trabajo, la colaboracin y la relacin contractual.
8. ESPECIFICACIN DEL SOFTWARE.
Es la primera actividad dentro de los procesos de software.
Es el proceso de comprensin y definicin de que servicios
requiere el sistema.
Identificacin
de
restricciones
de
funcionamiento
y
desarrollo.
Es la etapa ms importante dentro del proceso de
software pues se delimita el alcance del desarrollo.
Un error en esta etapa representa inevitablemente
problemas en el resto del desarrollo.
9. INGENIERA DE REQUERIMIENTOS.
Este proceso de ingeniera conduce al documento de
requerimientos (especificacin del sistema)
Se presenta en dos niveles de detalle:
Los usuarios y clientes: necesitan las especificaciones de alto
nivel (funcionalidad)
31
Los desarrolladores: Necesitan las especificaciones de bajo

nivel (programacin)
Se compone de cuatro fases principales
1.Estudio de viabilidad.
2.Obtencin y anlisis de requerimientos.
3.Especificacin de requerimientos.
4.Validacin de requerimientos.
La ingeniera de requerimientos es el arte de saber
preguntar
10.
VALIDACIN DEL SOFTWARE
- (V&V) La Verificacin y Validacin
- Se utiliza para demostrar que el sistema se ajusta
a
las
especificaciones
y
cumple
las
expectativas
del usuario final.
- Los sistemas no se deben probar como una simple
unidad monoltica. Por eso se divide en 3 fases
1. Pruebas de componentes (o unidades)
2. Pruebas del sistema
3. Pruebas de aceptacin
- La prueba del software debe hacerse por un equipo aparte a los
programadores
- Las pruebas son diseadas previamente al desarrollo del
software
- Las pruebas pueden dividirse comercialmente as:
1. Alfa: Pruebas de aceptacin para un nico cliente
2. Beta: Pruebas de aceptacin de un producto comercial que se
le entrega a un ncleo de clientes potenciales.
11.
-
REQUERIMIENTOS DEL SISTEMA.

Requerimientos de usuario
Requerimientos del sistema ((x) de dominio*)
Funcionales
No Funcionales
32
12.
13.
De producto
Organizacional
Externo
Otros:
Requerimientos
de
interfaz
de
integracin
con otros sistemas: procedimientos, lenguajes, estructura de
datos,
etc.
*de dominio: Significa en el ambiente donde existe el sistema.
ESPECIFICACIN DE LOS REQUERIMIENTOS.
A
quin
se
le
hacen
especificaciones
requerimientos?
A TODOS!!!
A los usuarios
A los clientes
A los administradores
A los ingenieros de sistemas
A los ingenieros de pruebas
A los ingenieros de mantenimiento
Estilos de especificacin de los requerimientos:
Estructurado (Formularios o plantillas)
Descripcin de diseo (secuencias algortmicas)
Grfico (Casos de uso)
Matemtico (Notaciones mquinas de estado)
de
los
ERS (Especificacin de Requisitos del Software)
Es un documento que define, de forma completa, precisa y

verificable, los requisitos, el diseo, el comportamiento u otras
caractersticas de un sistema o componente de un sistema.
CARACTERISTICAS FUNDAMENTALES DE UNA ERS
- Debe incluir informacin veraz.
- Debe comunicar dicha informacin de forma eficaz.
- Describir correctamente todos los requisitos del software.
- No describir ningn detalle del diseo del software, de su
verificacin o de la direccin del proyecto.
CARACTERISTICAS DE UNA BUENA ERS.
- No ambigua.
- Completa.
- Fcil de verificar.
33
Consistente.
Fcil de modificar.
Fcil para identificar el origen de cada requisito.
Fcil de utilizar durante las fases de explotacin
mantenimiento.
ESTRUCTURA PARA LA ERS.
34

Analisis de Sistemas

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Analisis de Sistemas

Загружено:

Авторское право:

Доступные форматы

Ao de la Consolidacin del Mar de Grau

UNIVERSIDAD NACIONAL SAN LUIS

2. MODELOS DE CICLO DE VIDA DE UN SISTEMA

Dependiendo de los objetivos del anlisis, podemos encontrarnos

1.-CICLO DE VIDA DEL SOFTWARE.

2.-MODELOS DE CICLO DE VIDA DE UN SISTEMA.

Se recomienda para el desarrollo de

experiencia por parte del

minimizacin de riesgos, la mejora de calidad, la reduccin total

Este modelo tambin se ha llamado evolutivo, se fundamenta en

til cuando se desconocen los requerimientos del producto o

Proporciona rapidez en el proceso de desarrollo

desarrollo de software a gran

Desarrollo Rpido de Aplicaciones (DRA)

desarrollados por cada equipo de trabajo y luego se integran para

Resalta el uso de componentes de software existente

Apoya la construccin del producto con la generacin

funcionalidad establecidas por el cliente.

Modelo de proceso de software:

El software primero se desarrolla en menor escala y se siguen y

Modelo Big Bang

Este modelo es el modelo con la forma ms simple. Requiere

cuentan los cientficos, despus del big bang muchas

Para este modelo, se requiere poca planificacin. No sigue ningn

Antes de su reunin con el analista, el cliente prepara un

Una evaluacin de los enfoques alternativos del desarrollo del

Delimitacin del mbito del proyecto.

pginas, en el que se describe el problema que nuestro sistema

Dado que cinco de cada seis proyectos analizados no se ajustaron

nuestro ordenador se avera? Una vez analizados los riesgos

Una estimacin siempre ha de ser meditada, tras un estudio

forzar a replanificar el resto del proyecto, retrasando an ms

Cuando las cosas no marchen del todo bien, hemos de evitar

realizado por unidad de tiempo). Tras una larga jornada de

Por qu es tan importante averiguar exactamente cules son los

Tcnicas de elicitacin de requerimientos

Un modelo, bsicamente, no es ms que una simplificacin de la

sistema en subsistemas y del flujo de datos que existe entre los

6.METODOLOGAS DE ANLISIS DE REQUERIMIENTOS.

7.METODOLOGAS TRADICIONALES Y GILES.

anlisis, diseo, implementacin y documentacin de sistemas

Es sencillo, ya que sigue los pasos intuitivos necesarios a la

a) Propietario del producto

giles como de metodologas tradicionales. Las metodologas

Los desarrolladores: Necesitan las especificaciones de bajo

REQUERIMIENTOS DEL SISTEMA.

ERS (Especificacin de Requisitos del Software)

Es un documento que define, de forma completa, precisa y

ESTRUCTURA PARA LA ERS.

Вам также может понравиться