Analisis Y Diseño De Sistema

SISTEMA ABIERTO
SAETI

ANÁLISIS Y
DISEÑO DE SISTEMAS

NOMBRE:
EVANGELINA LÓPEZ DE LOS SANTOS

NOVIEMBRE DE 2005

TURNO VESPERTINO
ANÁLISIS Y DISEÑO DE SISTEMAS

UNIDAD I: MÉTODOS TRADICIONALES DEL ANÁLISIS DE SISTEMAS

1. CONCEPTOS GENERALES
1. SISTEMAS
2. SISTEMAS DE INFORMACIÓN
3. ANÁLISIS
4. DISEÑO
5. ANALISTA DE SISTEMAS
6. PROGRAMADOR
7.ADMINISTRADOR DE BASE DE DATOS

2. CICLO DE VIDA CLÁSICO.
El ciclo de vida del proyecto clásico:
Cada proyecto atraviesa por algún tipo de análisis, diseño e implantación, aunque no se haga exactamente como se muestra en el diagrama.
El ciclo de vida del proyecto clásico.
 
o Las fases de exploración y análisis pudieran juntarse en una sola (sobre todo en organizaciones en las cualesse considera factible desde el inicio cualquier cosa que quiera el usuario).
o Puede no haber fase de estudio de hardware si se cree que cualquier sistema nuevo pudiera instalarse con las computadoras existentes sin causar mayor problema operacional.
o Las fases de diseño preliminar y de diseño de detalles pudieran juntarse en una sola llamada simplemente de diseño.
oDiversas fases de prueba pueden juntarse en una sola; de hecho, podrían incluirse con la codificación.
De aquí que el ciclo de vida del proyecto en una organización sola puede tener cinco fases o siete o doce, pero seguir siendo todavía de tipo clásico.
Implantación ascendente: El uso de la implantación ascendente es una de las grandes debilidades del ciclo de vida de los proyectos clásicos. Seespera que los programadores lleven a cabo primero sus pruebas modulares, luego las pruebas del subsistema, y finalmente las pruebas del sistema mismo. Este enfoque también se conoce como el ciclo de vida de cascada.
 
Modelo de cascada del desarrollo de sistemas.
 
o Nada está hecho hasta que todo esté terminado. Por eso, si el proyecto se atrasa y la fecha límite cae precisamenteen medio del proceso de prueba del sistema, no habrá nada que mostrarle al usuario más que una enorme pila de listados de programas, los cuales, vistos en su totalidad no le ofrecen nada de valor.
o Las fallas más triviales se encuentran al comienzo de período de prueba y las más graves al final. Esto es casi una tautología: las pruebas modulares dejan al descubierto fallas relativamentesimples, las pruebas de los sistemas, por otra parte, descubren errores grandes de interfaz entre subsistemas.
o La eliminación de fallas suele ser extremadamente difícil durante las últimas etapas de prueba del sistema. Nótese que se puede distinguir entre pruebas y eliminación de fallas. La eliminación de fallas es el arte de descubrir dónde está la falla después de que el proceso deprueba ha determinado que la falla de hecho existe. Cuando la falla se descubre durante la fase de prueba del sistema en un proyecto ascendente, a menudo suele ser extremadamente difícil determinar cuál módulo la contiene.
o La necesidad de prueba con la computadora aumenta exponencialmente durante las etapas finales de prueba. Para ser más específicos, el administrador del proyecto amenudo descubre que necesita una gran cantidad de horas-máquina para probar el sistema, dado que suele ser difícil obtener tanto tiempo de uso de la computadora, el proyecto suele atrasarse mucho.
Progresión secuencial: La segunda debilidad más importante del ciclo de vida de un proyecto clásico es su insistencia en que las fases se sucedan secuencialmente. Querer esto es una tendencia naturalhumana: deseamos decir que hemos terminado la fase de análisis del sistema y que nunca tendremos que volver a preocuparnos por ella. de hecho, muchas organizaciones formalizan esto con un ritual conocido como "congelar" la especificación o congelar el documento de diseño.
El único problema que trae consigo este deseo de progreso ordenado es que no es nada realista. En lo particular, el enfoque...