Академический Документы
Профессиональный Документы
Культура Документы
Representacin grfica
Despus de cada etapa se realiza una revisin para comprobar si se puede pasar
a la siguiente.
Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un
tipo de documento especfico. Idealmente, cada fase podra hacerla un equipo
diferente gracias a la documentacin generada entre las fases. Las fases son:
Anlisis: Toma como entrada una descripcin en lenguaje natural de lo que
quiere el cliente. Produce el S.R.D. (Software Requirements Document
Documento de Requisitos del software).
o Anlisis de Requisitos del Sistema.
o Anlisis de Requisitos del Software.
Diseo: Su entrada es el S.R.D. Produce el S.D.D. (Software Design
Document Documento de Plan del software)
o Diseo Preliminar.
o Diseo Detallado.
1.2
1.3 Desventajas
Es difcil obtener todos los requisitos al comienzo. Lo normal es que el
cliente no tenga perfectamente definidas las especificaciones del sistema, o
puede ser que surjan necesidades imprevistas.
Si se han cometido errores en una fase es difcil volver atrs. Al cambiar
alguna de las etapas se debe revisar todas las etapas subsiguientes.
Es comparativamente ms lento que los dems y el coste es mayor
tambin.
Se tarda mucho en disponer del software.
No se tiene el producto hasta el final, esto quiere decir que:
o Si se comete un error en la fase de anlisis no lo descubrimos hasta
la entrega, con el consiguiente gasto intil de recursos.
o El cliente no ver resultados hasta el final, con lo que puede
impacientarse.
No se tienen indicadores fiables del progreso del trabajo (sndrome del
90%).
El mantenimiento se realiza en el cdigo fuente
Impone una estructura de gestin de proyectos
1.4 Aplicaciones
Aquellos para los que se dispone de todas las especificaciones desde el
principio, por ejemplo, los de reingeniera.
Se est desarrollando un tipo de producto que no es novedoso.
Proyectos complejos que se entienden bien desde el principio.
Cada vez parece ms evidente que cuanto mayor sea el nivel en el que se
especifique el software, ms rpido se podr construir el programa.
El paradigma T4G para la ingeniera del software se orienta hacia la posibilidad
de especificar el software usando formas de lenguaje especializado o notaciones
grficas que describa el problema que hay que resolver en trminos que los
entienda el cliente.
Actualmente, un entorno para el desarrollo de software que soporte el paradigma
T4G puede incluir todas o algunas de las siguientes herramientas:
Lenguajes no procedimentales de consulta a bases de datos,
Generacin de informes,
Manejo de datos,
Interaccin y definicin de pantallas,
Generacin de cdigos,
Capacidades grficas de alto nivel,
Capacidades de hoja de clculo,
Generacin automatizada de HTML y lenguajes similares utilizados para la
creacin de sitios web usando herramientas de software avanzado.
Al igual que otros paradigmas, T4G comienza con el paso de reunin de
requisitos. Por esta razn, el dilogo cliente-desarrollador descrito por los otros
paradigmas sigue siendo una parte esencial del enfoque T4G.
Las tcnicas de cuarta generacin ya se han convertido en una parte importante
del desarrollo de software. Cuando se combinan con enfoques de
ensamblaje de componentes el paradigma T4G se puede convertir en el
enfoque dominante hacia el desarrollo del software.
2.1 Desventajas.
Las T4G estn limitadas a las aplicaciones de sistema de informacin
comercial, y de la obtencin de informes en las grandes bases de datos.
Las herramientas actuales de T4G no son ms fciles de utilizar que los lenguajes
de programacin.
El cdigo fuente producido por tales herramientas es ineficiente y el
mantenimiento de grandes sistemas de software desarrollados mediante T4G, es
cuestionable
2.2 Diseo Grafico
3. Prototipo
Un cliente, a menudo, define un conjunto de objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, proceso o salida.
En otros casos, el responsable del desarrollo del software puede no estar seguro
de la eficacia de un algoritmo, de la capacidad de adaptacin de un sistema
operativo, o de la forma en que debera tomarse la interaccin hombre mquina.
En este caso el paradigma de construccin de prototipos puede ofrecer el mejor
enfoque.
Escuchar al Cliente: El paradigma de construccin de prototipos
comienza con la recoleccin de requisitos. El desarrollador y el cliente
encuentran y definen los objetivos globales para el software, identifican los
requisitos conocidos y las reas del esquema en donde es obligatoria ms
definicin.
23.1 Ventajas
3.3 Desventajas
Fase inicio: Es una descripcin del producto final a partir de una buena
idea y se presenta el anlisis de negocio para el producto
Fase de elaboracin: Especifica en detalle la mayora de los casos de
uso del producto y se disea la arquitectura del sistema. Se crea la lnea
base de la arquitectura.
Fase de construccin: Se construye el producto. Aqu la lnea base de la
arquitectura crece hasta convertirse en el sistema completo y preparado
para ser entregado a los usuarios.
Modelo de casos de uso: Con todos los casos de uso y su relacin con los
usuarios.
Modelo de anlisis: Con dos propsitos: refinar los casos de uso con ms
detalle y establecer la asignacin inicial de funcionalidad del sistema a un
conjunto de objetos que proporcionan el comportamiento.
colaboraciones
entre
los
Modelo de prueba: Que describe los casos de prueba que verifican los
casos de uso y por supuesto una representacin de la arquitectura.
El sistema tambin debe tener un modelo del dominio o modelo del negocio
que describa el contexto del negocio en el que se halla el sistema.
Producto: Artefactos que se crean durante la vida del proyecto, como los
modelos, cdigo fuente, ejecutables y documentacin.
5.5
5.6
5.8 Ventajas
5.9 Desventajas
una base para el plan del proyecto OO. El trabajo tcnico asociado con la
ingeniera del software OO sigue el camino iterativo. La ingeniera del
software OO hace hincapi en la reutilizacin. Por lo tanto, las clases se
buscan en una biblioteca (de clases O0 existentes) antes de construirse.
Cuando una clase no puede encontrarse en la biblioteca, el desarrollador de
software aplica anlisis orientado a objetos (AOO), diseo orientado a
objetos (DOO), programacin orientada a objetos (POO) y pruebas
orientadas a objetos (PROO) para crear la clase y los objetos derivados de
la clase. La nueva clase se pone en la biblioteca de tal manera que pueda
ser reutilizada en el futuro.
7.3 Ventajas
7.4 Desventajas
Por un lado est el anlisis y el diseo global. Por otra parte estn los
pequeos incrementos, con las fases de diseo detallado, codificacin y
mantenimiento.
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 modelo incremental entrega el software en partes pequeas, pero
utilizables, llamadas ((incrementos).
En general, cada incremento se construye sobre aqul que ya ha sido entregado.
8.3 Desventajas
Los errores en la deteccin de requisitos se encuentran tarde.
Cada incremento no es el producto final, sino ms bien un producto q se acerca
cada vez ms a serlo, el incremento n ser el producto final.
9. Framework
En el desarrollo de software, un framework es una estructura de soporte
definida en la cual otro proyecto de software puede ser organizado y desarrollado.
Tpicamente, un framework puede incluir soporte de programas, bibliotecas y un
lenguaje interpretado entre otros software para ayudar a desarrollar y unir los
diferentes componentes de un proyecto.
9.1 Arquitectura
Dentro de este aspecto, podemos basarnos en el modelo MVC (Controlador =>
Modelo => Vista) ya que debemos fragmentar nuestra programacin. Tenemos
que contemplar estos aspectos bsicos en cuanto a la implementacin de nuestro
sistema:
10.3. Desventajas
10.4 Aplicaciones
11.2 Ventajas
11.3 Desventajas