Está en la página 1de 0

Gilber & Sistemas

1
GilberBASILIOROBLES
2007
Gilber & Sistemas
2
AnlisisyDiseodeSistemas
NDICEYCONTENIDOS
INTRODUCCIN6
TEMAI.PLANIFICACINDEPROYECTOSDESOFTWARE8
1.1. QueesunproyectodeSistemaoSoftware.9
1.2. ObjetivosdelaPlanificacindelProyecto.9
1.3.1. ActividadesasociadasalProyectodeSoftware.10
1.3.1. mbitodelSoftware.10
1.4. Recursos.10
1.4.1. RecursosHumanos.11
1.4.2. RecursooComponentesdeSoftwareReutilizables.11
1.4.3. RecursosdeEntorno.12
1.5. EstimacindelProyectodeSoftware.12
1.5.1. EstimacinBasadaenelProceso.13
1.6. DiferentesModelosdeEstimacin.13
1.6.1. LosModelosEmpricos.14
1.6.2. ElModeloCOCOMO.14
1.6.3. HerramientasAutomticasdeEstimacin.14
Resumen.15
TEMAII.ANLISISDESISTEMASDECOMPUTACIN.16
2.1. ConceptosyAnlisis.17
2.2. ObjetivosdelAnlisis.18
Gilber & Sistemas
3
2.2.1. IdentificacindeNecesidades.18
2.2.2. EstudiodeViabilidad.18
2.2.2.1. ViabilidadEconmica.20
2.2.2.2. ViabilidadTcnica.20
2.2.2.3 ViabilidadLegal.20
2.2.3. AnlisisEconmicoyTcnico.20
2.2.4. ModeladodelaArquitecturadelSistema.21
2.2.5. EspecificacionesdelSistema.21
Conclusiones. 22
TEMAIII.DISEODESISTEMASDECOMPUTACIN.23
3.1. ConceptosyPrincipios.24
3.1.1. ElDiseodeLosDatos.24
3.1.2. ElDiseoArquitectnico.24
3.1.3. ElDiseodelaInterfaz.24
3.1.4. ElDiseodelosProcedimientos.24
3.2. DiseodelaSalida.26
3.3. DiseodeArchivos.26
3.4. DiseodeInteraccionesconlaBasedeDatos.27
3.5. HerramientasparaelDiseodeSistemas.27
3.5.1. HerramientasdeEspecificacin.27
3.5.2. HerramientasparaPresentacin.28
3.5.3. HerramientasparaelDesarrollodeSistemas.28
3.5.4. HerramientasparaIngenieradeSoftware.28
3.5.5. GeneradoresdeCdigos.28
3.5.6. HerramientasparaPruebas.28
Conclusiones.29
Gilber & Sistemas
4
TEMAIV.IMPLANTACIN,EVALUACINYPRUEBADESISTEMAS.30
4.1. IMPLANTACIN.ConceptosyDefinicin.31
4.2. CapacitacindeUsuariosdelSistema. 32
4.3.1 ObjetivosdelaCapacitacin.33
4.4. LaEvaluacindelSistema.33
4.4.1. Evaluacinoperacional.33
4.4.2. ImpactoOrganizacional.33
4.4.3. DesempeodelDesarrollo.34
4.5. PruebasdeSistemas.34
CONCLUSIONESGENERALES.35
BIBLIOGRAFA.37
NOTASFINALES.38
Gilber & Sistemas
5
TEMAI.
PLANIFICACINDEPROYECTOSDE
SOFTWARE
TEMAI. LANIFICACINDEUNPROYECTODESISTEMAS.
DESARROLLO.
1.1. QueesunproyectodeSistemaoSoftware.?
Es el Proceso de gestin para la creacin de un Sistema o software, la cual
encierraunconjuntodeactividades,unadelascualeseslaestimacin,estimar
es echar un vistazo al futuro y aceptamos resignados cierto grado de
incertidumbre. Aunque la estimacin, es mas un arte que una Ciencia, es una
actividadimportantequenodebellevarseacabodeformadescuidada.Existen
tcnicas tiles para la estimacin de costes de tiempo. Y dado que la
estimacin es la base de todas las dems actividades de planificacin del
proyectoysirvecomoguaparaunabuenaIngenieraSistemasySoftware.
Alestimartomamosencuentanosolodelprocedimientotcnicoautilizarenel
proyecto, sino que se toma en cuenta los recursos, costos y planificacin. El
Tamaodelproyectoesotrofactorimportantequepuedeafectarlaprecisinde
las estimaciones. A medida que el tamao aumenta, crece rpidamente la
interdependenciaentrevarioselementosdelSoftware.
La disponibilidad de informacin Histrica es otro elemento que determina el
riesgodelaestimacin.
Gilber & Sistemas
6
1.2.Objeti vosdel aPlani ficaci ndel Proyecto.
El objetivo de la Planificacin del proyecto de Software es proporcionar un
marco de trabajo que permita al gestor hacer estimaciones razonables de
recursos costos y planificacin temporal. Estas estimaciones se hacen dentro
de un marco de tiempo limitado al comienzo de un proyecto de software, y
deberan actualizarse regularmente medidaque progresa el proyecto. Adems
lasestimacionesdeberandefinirlosescenariosdelmejorcaso,ypeorcaso,de
modoquelosresultadosdelproyectopuedenlimitarse.
ElObjetivodelaplanificacinselogramedianteunprocesodedescubrimiento
delainformacinquelleveaestimacionesrazonables.
1.3Acti vi dadesasoci adasalproyectodesoftware.
1.3.1mbitodelSoftware.
Es la primera actividad dellevada a cabo durantela planificacin del proyecto
deSoftware.
Enestaetapasedebenevaluarlafuncinyelrendimientoqueseasignaronal
SoftwaredurantelaIngenieradelSistemadeComputadoraparaestablecerun
mbito de proyecto que no sea ambiguo, e incomprensible para directivos y
tcnicos
Describe la funcin, el rendimiento, las restricciones, las interfaces y la
fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan
paradarmasdetallesantesdelcomienzodelaestimacin.Lasrestriccionesde
rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento,
identifican los limites del software originados por el hardware externo, por la
memoriadisponibleyporotrossistemasexistentes.
Elmbitosedefinecomounprerequisitoparalaestimacinyexistenalgunos
elementosquesedebetomarencuentacomoes:
La Obtencin de la Informacin necesaria para el software. Para esto el
analista y el cliente se renen sobre las expectativas del proyecto y se
ponendeacuerdoenlospuntosdeintersparasudesarrollo.
Gilber & Sistemas
7
1.4 RECURSOS:
LaSegundatareadelaplanificacindeldesarrollodeSoftwareeslaestimacin
delosrecursosrequeridosparaacometerelesfuerzodedesarrollodeSoftware,
estosimulaaunapirmidedondelasHerramientas(hardwareySoftware),son
la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en
segundoniveldelapirmideseencuentranlosComponentesreutilizables.
Y en la parte mas alta de la pirmide se encuentra el recurso primario, las
personas(elrecursohumano).
Cadarecursoquedaespecificadomediantecuatrocaractersticas:
DescripcindelRecurso.
Informesdedisponibilidad.
Fechacronolgicaenlaqueserequiereelrecurso.
Tiempoduranteelqueseraplicadoelrecurso.
1.4.1 RecursosHumanos.
La Cantidad de personas requeridas para el desarrollo de un proyecto de
software solo puede ser determinado despus de hacer una estimacin del
esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y
seleccionar la posicin dentro de la organizacin y la especialidad que
desempearacadaprofesional.
1.4.2 Recursosocomponentesdesoftwarereutilizables.
Cualquierestudiosobrerecursosdesoftwareestaraincompletosinestudiarla
reutilizacin,estoeslacreacinylareutilizacindebloquesdeconstruccinde
Software.
Tales bloques se deben establecer en catlogos para una consulta ms fcil,
estandarizarse para una fcil aplicacin y validarse para la tambin fcil
integracin.
El Autor Bennatan sugiere cuatro categoras de recursos de software que se
deberantenerencuentaamedidaqueseavanzaconlaplanificacin:
Componentesyadesarrollados.
Componentesyaexperimentados.
ComponentesconexperienciaParcial.
Componentesnuevos.
Gilber & Sistemas
8
1.4.3 Recursosdeentorno.
El entorno es donde se apoya el proyecto de Software, llamado a menudo
entornodeIngenieradeSoftware,incorporaHardwareySoftware.
El Hardware proporciona una plataforma con las herramientas (Software)
requeridas para producir los productos que son el resultado de la buena
practica de la Ingeniera del Software, un planificador de proyectos debe
determinar la ventana temporal requerida para el Hardware y el Software, y
verificar que estos recursos estn disponibles. Muchas veces el desarrollo de
las pruebas de validacin de un proyecto de software para la composicin
automatizada puede necesitar un compositor de fotografas en algn punto
duranteeldesarrollo.Cadaelementodehardwaredebeserespecificadoporel
planificadordelProyectodeSoftware.
1.5. ESTIMACINDELPROYECTODESOFTWARE.
EnelprincipioelcostodelSoftwareconstituaunpequeoporcentajedelcosto
total de los sistemas basados en Computadoras. Hoy enda el Software es el
elementomascarodelamayoradelossistemasinformticos.
Ungranerrorenlaestimacindelcostopuedeserloquemarqueladiferencia
entrebeneficiosyperdidas,laestimacindelcostoydelesfuerzodelsoftware
nunca ser una ciencia exacta, son demasiadas las variables: humanas,
tcnicas,deentorno, polticas, quepueden afectarelcosto finaldelsoftware y
elesfuerzoaplicadoparadesarrollarlo.
Para realizar estimaciones seguras de costos y esfuerzos tienen varias
opcionesposibles:
Deje la estimacin para mas adelante (obviamente podemos realizar una
estimacinalcienporcienfiabledespusdehaberterminadoelproyecto.
Baselasestimacionesenproyectossimilaresyaterminados.
Utilicetcnicasdedescomposicinrelativamentesencillasparagenerarlas
estimacionesdecostosyesfuerzodelproyecto.
Desarrolle un modelo emprico para l calculo de costos y esfuerzos del
Software.
Desdichadamentelaprimeraopcin,aunqueatractivanoespractica.
Gilber & Sistemas
9
LaSegundaopcin puede funcionarrazonablemente bien sielproyecto actual
es bastante similar a los esfuerzos pasadosy si otras influencias del proyecto
son similares. Las opciones restantes son mtodos viables para la estimacin
del proyecto de software. Desde el punto de vista ideal, se deben aplicar
conjuntamente las tcnicas indicadas usando cada una de ellas como
comprobacindelasotras.
Antesdehacerunaestimacin,elplanificadordelproyectodebecomprenderel
mbitodelsoftwareaconstruirygenerarunaestimacindesutamao.
1.5.1 EstimacinbasadaenelProceso.
Eslatcnicamscomnparaestimarunproyectoesbasarlaestimacinenel
procesoquesevaautilizar,esdecir,elprocesosedescomponeenunconjunto
relativamentepequeodeactividadesotareas,yenelesfuerzorequeridopara
llevaracabolaestimacindecadatarea.
Al igual que las tcnicas basadas en problemas, la estimacin basada en el
procesocomienzaenunadelineacindelasfuncionesdelsoftwareobtenidasa
partir del mbito del proyecto. Se mezclan las funciones del problema y las
actividadesdelproceso.Comoultimopasosecalculanloscostosyelesfuerzo
decadafuncinylaactividaddelprocesodesoftware.
1.6. DIFERENTESMODELOSDEESTIMACIN.
Existendiferentesmodelosdeestimacincomoson:
1.6.1 LosModelosEmpricos:
Donde los datos que soportan la mayora de los modelos de estimacin
obtienen una muestra limitada de proyectos. Por esta razn, el modelo de
estimacin no es adecuado para todas las clases de software y en todos los
entornosdedesarrollo.Porlotantolosresultadosobtenidosdedichosmodelos
sedebenutilizarconprudencia.
1.6.2 ElModeloCOCOMO.
BarryBoehm,ensulibroclsicosobreeconomadelaIngenieradelSoftware,
introduce una jerarqua de modelos de estimacin de Software con el nombre
de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo
constructivodecostos.LajerarquademodelosdeBoehmestaconstituidapor
lossiguientes:
Gilber & Sistemas
10
ModeloI. El Modelo COCOMO bsico calcula el esfuerzo y el costo
del desarrollo de Software en funcin del tamao del programa, expresado
enlaslneasestimadas.
ModeloII. El Modelo COCOMO intermedio calcula el esfuerzo del
desarrollodesoftwareenfuncindeltamaodelprogramaydeunconjunto
deconductoresdecostosqueincluyenlaevaluacinsubjetivadelproducto,
delhardware,delpersonalydelosatributosdelproyecto.
ModeloIII. El modelo COCOMO avanzado incorpora todas las
caractersticas de la versin intermedia y lleva a cabo una evaluacin del
impacto de los conductores de costos en cada caso (anlisis, diseo, etc.)
delprocesodeingenieradeSoftware.
1.6.3 HerramientasAutomticasDeEstimacin.
Las herramientas automticas de estimacin permiten al planificador estimar
costos y esfuerzos, as como llevar a cabo anlisis del tipo, que pasa si, con
importantes variables del proyecto, tales como la fecha de entrega o la
seleccin del personal. Aunque existen muchas herramientas automticas de
estimacin, todas exhiben las mismas caractersticas generales y todas
requierendeunaomsclasesdedatos.
Apartirdeestosdatos,elmodeloimplementadoporlaherramientaautomtica
de estimacin proporciona estimaciones del esfuerzo requerido para llevar a
cabo el proyecto, los costos, la carga de personal, la duracin, y en algunos
casoslaplanificacintemporaldedesarrolloyriesgosasociados.
En resumen el planificador del Proyecto de Software tiene que estimar tres
cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo
requerirycuantagenteestarimplicada.Ademselplanificadordebepredecir
losrecursosdehardwareysoftwarequevaarequeriryelriesgoimplicado.
Para obtener estimaciones exactaspara unproyecto, generalmente se utilizan
al menos dos de las tres tcnicas referidas anteriormente. Mediante la
comparacinyla conciliacindelas estimacionesobtenidas conlas diferentes
tcnicas, el planificador puede obtener una estimacin ms exacta. La
estimacin del proyecto de software nunca ser una ciencia exacta, pero la
combinacin de buenos datos histricos y tcnicas puede mejorar la precisin
delaestimacin.
Gilber & Sistemas
11
TEMAII.
ANLISISDESISTEMASDECOMPUTACIN
TEMAII. Anl isi sdeSi stemasdeComputaci n.
DESARROLLO.
2.1 ConceptosyAnlisi s:
Es un conjunto o disposicin de procedimientos o programas relacionados de
maneraquejuntosformanunasolaunidad.Unconjuntodehechos,principiosy
reglasclasificadasydispuestasdemaneraordenadamostrandounplanlgico
enlaunindelaspartes.Unmtodo,planoprocedimientodeclasificacinpara
hacer algo. Tambin es un conjunto o arreglo de elementos para realizar un
objetivopredefinidoenelprocesamientodelaInformacin.Estosellevaacabo
teniendoencuentaciertosprincipios:
Debe presentarse y entenderse el dominio de la informacin de un
problema.
DefinalasfuncionesquedeberealizarelSoftware.
Represente el comportamiento del software a consecuencias de
acontecimientosexternos.
Divida en forma jerrquica los modelos que representan la informacin,
funcionesycomportamiento.
El proceso debe partir desde la informacin esencial hasta el detalle de la
Implementacin.
Gilber & Sistemas
12
LafuncindelAnlisispuedeserdarsoportealasactividadesdeunnegocio,o
desarrollar un producto que pueda venderse para generar beneficios. Para
conseguiresteobjetivo,unSistemabasadoencomputadorashaceusodeseis
(6)elementosfundamentales:
Software, que son Programas de computadora, con estructuras de datos y
sudocumentacinquehacenefectivalalogsticametodologaocontrolesde
requerimientosdelPrograma.
Hardware, dispositivos electrnicos y electromecnicos, que proporcionan
capacidad de clculos y funciones rpidas, exactas y efectivas
(Computadoras, Censores, maquinarias, bombas, lectores, etc.), que
proporcionanunafuncinexternadentrodelosSistemas.
Personal, son los operadores o usuarios directos de las herramientas del
Sistema.
Base de Datos, una gran coleccin de informaciones organizadas y
enlazadasalSistemaalasqueseaccedepormediodelSoftware.
Documentacin, Manuales, formularios, y otra informacin descriptiva que
detallaodainstruccionessobreelempleoyoperacindelPrograma.
Procedimientos, o pasos quedefinen elusoespecifico decada uno de los
elementos o componentes del Sistema y las reglas de su manejo y
mantenimiento.
Un Anlisisde Sistema se lleva a caboteniendoencuenta lossiguientes
objetivosenmente:
IdentifiquelasnecesidadesdelCliente.
Evale que conceptos tiene el cliente del sistema para establecer su
viabilidad.
RealiceunAnlisisTcnicoyeconmico.
Asigne funciones al Hardware, Software, personal, base de datos, y otros
elementosdelSistema.
Establezcalasrestriccionesdepresupuestosyplanificacintemporal.
Creeunadefinicindelsistemaqueformeelfundamentodetodoeltrabajo
deIngeniera.
Gilber & Sistemas
13
Para lograr estos objetivos se requiere tener un gran conocimiento y
dominio del Hardware y el Software, as como de la Ingeniera humana
(ManejoyAdministracindepersonal),yadministracindebasededatos.
2.2 Obj eti vosdelAnlisis.
2.2.1 IdentificacindeNecesidades.
Eselprimerpasodelanlisisdelsistema,enesteprocesoenAnalistaserene
conelclientey/ousuario(unrepresentanteinstitucional,departamentalocliente
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
identificacinydesarrollodelproyecto.
Algunos autores suelen llamar a esta parte Anlisis de Requisitos y lo
dividenencincopartes:
Reconocimientodelproblema.
EvaluacinySntesis.
Modelado.
Especificacin.
Revisin.
Antesdesureuninconelanalista,elclientepreparaundocumentoconceptual
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.
2.2.2 EstudiodeViabilidad.
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
perdidas 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
debentomarencuentacuatroreasprincipalesdeinters:
Gilber & Sistemas
14
2.2.2.1 Viabilidadeconmica.
Unaevaluacindeloscostosdedesarrollo,comparadosconlosingresosnetos
obeneficiosobtenidosdelproductooSistemadesarrollado.
2.2.2.2 ViabilidadTcnica.
Un estudio de funciones, rendimiento y restricciones que puedan afectar la
realizacindeunsistemaaceptable.
2.2.2.3 ViabilidadLegal.
Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad
legalenquesepodraincurriraldesarrollarelSistema.
Alternativas. Una evaluacin de los enfoques alternativos del desarrollo del
productooSistema.
Elestudiodelaviabilidadpuededocumentarsecomouninformeaparteparala
altagerencia.
2.2.3 AnlisisEconmicoyTcnico.
El anlisis econmico incluye lo que llamamos, el anlisis de costos
beneficios, significa una valoracin de la inversin econmica comparado con
losbeneficiosqueseobtendrnenlacomercializacinyutilidaddelproductoo
sistema.
Muchas veces en el desarrollo de Sistemas de Computacin estos son
intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la
caractersticasdelSistema.Elanlisisdecostosbeneficiosesunafasemuy
importantedeelladependelaposibilidaddedesarrollodelProyecto.
EnelAnlisisTcnico,elAnalistaevalalosprincipiostcnicosdelSistemayal
mismo tiempo recoge informacin adicional sobre el rendimiento, fiabilidad,
caractersticasdemantenimientoyproductividad.
Losresultadosobtenidosdelanlisistcnicosonlabaseparadeterminarsobre
si continuar o abandonar el proyecto, si hay riesgos de que no funcione, no
tenga el rendimiento deseado, o si las piezas no encajan perfectamente unas
conotras.
Gilber & Sistemas
15
2.2.4 ModeladodelaarquitecturadelSistema.
Cuandoqueremosdaraentendermejorloquevamosaconstruirenelcasode
edificios,Herramientas,Aviones,Maquinas,secreaunmodeloidntico,peroen
menorescala(maspequeo).
SinembargocuandoaquelloqueconstruiremosesunSoftware,nuestromodelo
debe tomar una forma diferente, deben representar todas las funciones y
subfuncionesdeunSistema.Losmodelosseconcentranenloquedebehacer
elsistema noencomo lo hace, estosmodelos puedenincluir notacingrfica,
informacinycomportamientodelSistema.
Todos los Sistemas basados en computadoras pueden modelarse como
transformacindelainformacinempleandounaarquitecturadeltipoentraday
salida.
2.2.5 EspecificacionesdelSistema.
Es un Documento que sirve como fundamento para la Ingeniera Hardware,
software, Base de datos, e ingeniera Humana. Describe la funcin y
rendimiento de un Sistema basado en computadoras y las dificultades que
estarn presente durante su desarrollo. Las Especificaciones de los requisitos
delsoftwareseproduceenlaterminacindelatareadelanlisis.
En Conclusin un proyecto de desarrollo de un Sistema de Informacin
comprende varios componentes o pasos llevados a cabo durante la etapa del
anlisis, el cual ayuda a traducir las necesidades del cliente en un modelo de
Sistema que utiliza uno mas de los componentes: Software, hardware,
personas,basededatos,documentacinyprocedimientos.
Gilber & Sistemas
16
TEMAIII.
DISEODESISTEMASDECOMPUTACIN
TEMAIII. DISEODESISTEMASDECOMPUTACIN.
DESARROLLO.
3.1. Conceptosyprinci pios:
El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y
principios con el propsito de definir un dispositivo, un proceso o un Sistema,
consuficientesdetallescomoparapermitirsuinterpretacinyrealizacinfsica.
LaetapadelDiseodelSistemaencierracuatroetapas:
3.1.1 Eldiseodelosdatos.
Trasforma el modelo de dominio de la informacin, creado durante el anlisis,
enlasestructurasdedatosnecesariosparaimplementarelSoftware.
3.1.2 ElDiseoArquitectnico.
Definelarelacinentrecadaunodeloselementosestructuralesdelprograma.
3.1.3 ElDiseodelaInterfaz.
Describe como se comunica elSoftware consigomismo, conlos sistemas que
operanjuntoconelyconlosoperadoresyusuariosqueloemplean.
Gilber & Sistemas
17
3.1.4 ElDiseodeprocedimientos.
Transforma elementos estructurales de la arquitectura del programa. La
importancia del Diseo del Software se puede definir en una sola palabra
Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El
Diseoeslanicamaneradematerializarconprecisinlosrequerimientosdel
cliente.
El Diseo del Software es un proceso y un modelado a la vez. El proceso de
Diseoesunconjuntodepasosrepetitivosquepermitenaldiseadordescribir
todos los aspectos del Sistema a construir. A lo largo del diseo se evala la
calidaddeldesarrollodelproyectoconunconjuntoderevisionestcnicas:
El diseo debe implementar todos los requisitos explcitos contenidos en el
modelodeanlisisydebeacumulartodoslosrequisitosimplcitosquedeseael
cliente.
Debeseruna gua quepuedan leeryentenderlos que construyan elcdigoy
losquepruebanymantienenelSoftware.
El Diseo debe proporcionar una completa idea de lo que es el Software,
enfocandolosdominiosdedatos,funcionalycomportamientodesdeelpuntode
vistadelaImplementacin.
Para evaluar la calidad de una presentacin del diseo, se deben establecer
criteriostcnicosparaunbuendiseocomoson:
Un diseo debe presentar una organizacin jerrquica que haga un uso
inteligentedelcontrolentreloscomponentesdelsoftware.
Eldiseodebesermodular,esdecir,sedebehacerunaparticinlgicadel
Softwareenelementosquerealicenfuncionesysubfuncionesespecificas.
Undiseodebecontenerabstraccionesdedatosyprocedimientos.
Debe producir mdulos que presenten caractersticas de funcionamiento
independiente.
Debe conducir a interfaces que reduzcan la complejidad de las conexiones
entrelosmdulosyelentornoexterior.
Gilber & Sistemas
18
Debeproducirundiseo usando unmtodoquepudiera repetirse segnla
informacinobtenidaduranteelanlisisderequisitosdeSoftware.
Estos criterios no se consiguen por casualidad. El proceso de Diseo del
Software exige buena calidad a travs de la aplicacin de principios
fundamentalesdeDiseo,Metodologasistemticayunarevisinexhaustiva.
Cuandose va a disearunSistema deComputadoras se debetenerpresente
que el proceso de un diseoincluye, concebir yplanear algoenla mente, as
comohacerundibujoomodeloocroquis.
3.2. Diseodel aSal ida.
Enestecasosalidaserefierealosresultadoseinformacionesgeneradasporel
Sistema, Para la mayora de los usuarios la salida es la nica razn para el
desarrollo de un Sistema y la base de evaluacin de su utilidad. Sin embargo
cuandoserealizaunsistema,comoanalistasdebenrealizarlosiguiente:
Determine que informacin presentar. Decidir si la informacin ser
presentada en forma visual, verbal o impresora y seleccionar el medio de
salida.
Dispongalapresentacindelainformacinenunformatoaceptable.
Decidacomodistribuirlasalidaentrelosposiblesdestinatarios.
3.3. DiseodeArchi vos.
Incluye decisionesconrespecto ala naturaleza ycontenidodelpropio archivo,
como si se fuera a emplear para guardar detalles de las transacciones, datos
histricos, o informacin de referencia. Entre las decisiones que se toman
duranteeldiseodearchivos,seencuentranlassiguientes:
Los datos que deben incluirse en el formato de registros contenidos en el
archivo.
La longitud de cada registro, con base en las caractersticas de los datos
quecontenga.
Lasecuenciaadisposicindelosregistrosdentrodelarchivo(Laestructura
dealmacenamientoquepuedesersecuencial,indexadaorelativa).
Gilber & Sistemas
19
No todos los sistemas requieren del diseo de todos los archivos, ya que la
mayora de ellos pueden utilizar los del viejo Sistema y solo tenga que
enlazarse el nuevo Sistema al Archivo maestro donde se encuentran los
registros.
3.4. DiseodeInteraccionesconl aBasedeDatos.
Lamayoradelossistemasdeinformacinyaseanimplantadoensistemasde
cmputosgrandesopequeos,utilizanunabasededatosquepuedenabarcar
varias aplicaciones, por esta razn estos sistemas utilizan u administrador de
base de datos, en este caso el diseador no construye la base de datos sino
queconsultaasuadministradorparaponersedeacuerdoenelusodeestaen
elsistema.
3.5 HerramientasparaelDiseodeSi stemas.
Apoyan el proceso de formular las caractersticas que el sistema debe tener
para satisfacer los requerimientos detectados durante las actividades del
anlisis:
3.5.1 Herramientasdeespecificacin.
Apoyan el proceso de formular las caractersticas que debe tener una
aplicacin, tales como entradas, Salidas, procesamiento y especificaciones de
control.Muchasincluyenherramientasparacrearespecificacionesdedatos.
3.5.2 Herramientasparapresentacin.
Se utilizanpara describirla posicin dedatos, mensajes yencabezadossobre
laspantallasdelasterminales,reportesyotrosmediosdeentradaysalida.
3.5.3 HerramientasparaeldesarrollodeSistemas.
Estas herramientas nos ayudan como analistas a trasladar diseos en
aplicacionesfuncionales.
Gilber & Sistemas
20
3.5.4 HerramientasparaIngenieradeSoftware.
ApoyanelProcesodeformulardiseosdeSoftware,incluyendoprocedimientos
ycontroles,ascomoladocumentacincorrespondiente.
3.5.5 Generadoresdecdigos.
Producen el cdigo fuente y las aplicaciones a partir de especificaciones
funcionalesbienarticuladas.
3.5.6 Herramientasparapruebas.
Apoyanla fase de la evaluacinde un Sistema o de partes del mismo contra
las especificaciones. Incluyen facilidades para examinar la correcta operacin
delSistemaascomoelgradodeperfeccinalcanzadoencomparacinconlas
expectativas.
Larevolucindelprocesamientodedatosdemaneracomputarizada,juntocon
las practicas de Diseo sofisticadas estn cambiando de forma dramtica la
manera en que se trasladan las especificaciones de Diseo d Sistemas de
Informacinfuncionales.
En Conclusiones Generales. En una organizacin o Empresa, el anlisis y
Diseo deSistemas,es elprocesode estudiarsuSituacinconla finalidad de
observar como trabaja y decidir si es necesario realizar una mejora el
encargadodellevaracaboestastareaseselanalistadesistemas.
Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un
estudiodeSistemasparadetectartodoslosdetallesdelasituacinactualdela
empresa. La informacin reunida coneste estudio sirve como base para crear
varias estrategias de Diseo. Los administradores deciden que estrategias
seguir. Los Gerentes, empleados y otros usuarios finales que se familiarizan
cada vez mas con el uso de computadoras estn teniendo un papel muy
importanteeneldesarrollodesistemas.
TodaslasorganizacionessonSistemasqueactandemanerareciprocaconsu
medio ambiente recibiendo entradas y produciendo salidas. Los Sistemas que
pueden estar formados por otros Sistemas de denominan Subsistemas y
funcionanparaalcanzarlosfinesdesuImplantacin.
Gilber & Sistemas
21
TEMAIV.
IMPLANTACIN,EVALUACINYPRUEBA
DESISTEMASDECOMPUTACIN
TEMAIV. IMPLANTACIN,EVALUACINYPRUEBAS.
DESARROLLO.
4.1. IMPLANTACIN.ConceptoyDefi ni cin.
Esla ultima fase deldesarrollo deSistemas.Eselproceso instalarequipos o
Software nuevo,como resultadodeunanlisisydiseo previo como resultado
de la sustitucin o mejoramiento de la forma de llevar a cavo un proceso
automatizado.
Al Implantar un Sistema de Informacin lo primero que debemos hacer es
asegurarnosque elSistema seaoperacionalo seaque funcionedeacuerdoa
losrequerimientosdelanlisisypermitirquelosusuariospuedanoperarlo.
ExistenvariosenfoquesdeImplementacin:
Esdarleresponsabilidadalosgrupos.
Usodediferentesestrategiasparaelentrenamientodelosusuarios.
Gilber & Sistemas
22
ElAnalistadeSistemasnecesitaponderarlasituacinyproponerunplande
conversinqueseaadecuadoparalaorganizacin.
ElAnalistanecesitaformularmedidasdedesempeoconlascualesevaluar
alosUsuarios.
Debe Convertir fsicamente el sistema de informacin antiguo, al nuevo
modificado.
En la preparacin de la Implantacin, aunque el Sistema este biendiseado y
desarrolladocorrectamente su xito depender desu implantacin yejecucin
por lo que es importante capacitar al usuario con respecto a su uso y
mantenimiento.
4.2. CapacitacindeUsuariosdelSistema:
Es ensear a los usuarios que se relacionan u operan en un proceso de
implantacin.
La Responsabilidad de esta capacitacin de los Usuarios primarios y
secundarios es del Analista, desde el personal de captura de datos hasta
aquellosquetomanlasdecisionessinusarunaComputadora.
Nosedebeincluirapersonasdediferentesnivelesdehabilidadeinteresesde
trabajodebidoaquesienunaEmpresaexistentrabajadoresinexpertosnose
pueden incluir en la misma seccin de los expertos ya que ambos grupos
quedaranperdidos.
Es como querer conducir dos Barcos con diferentes destinos con un mismo
Mapaderutasoconelmismotimn.
Aun y cuando la Empresa puede contratar los Servicios de Instructores
externos, el analista es la persona que puede ofrecer la mejor capacitacin
debido a que conoce el personal y al Sistema mejor que cualquier otro. A la
faltaoimposibilidaddelanalistalaorganizacinpuedecontratarotrosservicios
decapacitacincomoson:
Vendedores: Son aquellos que proporcionan capacitacin gratuita fuera
delaEmpresadeunoodosdas.
Gilber & Sistemas
23
Instructor pagado externamente: Son aquellos que pueden ensear todo
acerca de las computadoras pero para algunos usuarios esta no es una
capacitacinnecesaria.
Instructoresencasa:Estnfamiliarizadosconelpersonalypuedenadecuar
los materiales a sus necesidades, pero le faltara experiencia en Sistemas
deInformacinqueesrealmentelanecesidaddelusuario.
4.3.1 ObjetivosdelaCapacitacin:
Es lograr que los usuarios tengan el Dominio necesario de las cosas bsicas
acerca de las maquinarias y procesos que se emplean para su operacin de
maneraeficienteysegura.
4.4. LaEval uaci ndelSistema:
SellevaacaboparaidentificarpuntosdbilesyfuertesdelSistemaimplantado.
La evaluacin ocurre a lo largo de cualquiera de las siguientes cuatro
dimensiones:
4.4.1 Evaluacinoperacional:
Es el Momento en que s evala la manera en que funciona el Sistema, esto
incluyesufacilidaddeuso,Tiempoderespuestaanteunanecesidadoproceso,
comoseadecuanlosformatosenquesepresentalaInformacin,contabilidad
globalysuniveldeUtilidad.
4.4.2 ImpactoOrganizacional:
Identifica y mide los beneficios operacionales para la Empresa en reas tales
como, Finanzas (Costos, Ingresos y Ganancias), eficiencia en el desempeo
laboral e impacto competitivo, Impacto, rapidez y organizacin en el flujo de
Informacininternayexterna.
4.4.3 DesempeodelDesarrollo.
Es la evaluacin del Proceso de desarrollo adecuado tomando en cuentas
ciertos criterios como, Tiempo y esfuerzo en el desarrollo concuerden con
presupuesto y estndares y otros criterios de Administracin de Proyectos.
Adems se incluyen la valoracin de los mtodos y herramientas utilizados
duranteeldesarrollodelSistema.
Gilber & Sistemas
24
4.5. PruebadeSi stemas.
Dependiendo del tamao de la Empresa que usara el Sistema y el riesgo
asociado a su uso, puede hacerse la eleccin de comenzar la operacin del
Sistema solo en un rea dela Empresa (como una Prueba piloto), que puede
llevarse a cabo en un Departamento o con una o dos personas. Cuando se
implantaunnuevo sistema lo aconsejableesqueelviejo yelnuevofuncionen
de manera simultanea o paralela con la finalidad de comparar los resultados
que ambos ofrecen en su operacin, adems dar tiempo al personal para su
entrenamientoyadaptacinalnuevoSistema.
Durante el Proceso de Implantacin y Prueba se debenimplementar todas las
estrategias posibles para garantizar que en el uso inicial del Sistema este se
encuentrelibredeproblemaslocualsepuededescubrirduranteesteprocesoy
levaracabolascorreccionesdelugarparasubuenfuncionamiento.
DesdichadamentelaevaluacindeSistemasnosiemprerecibelaatencinque
merece,sinembargocuandosellevaacabodemaneraadecuadaproporciona
muchas informaciones que pueden ayudar a mejorar la efectividad de los
esfuerzosdedesarrollodeaplicacionesfuturas.
BIBLIOGRAFA
AnlisisyDiseodeSistemas
Autor:HenryF.Korth&AbrahamSilberschatz
SegundaEdicin.
EditoraMcGrawHill
IngenieradelSoftware
Autor:RogerS.Pressman
CuartaEdicin.
EditoraMcGrawHill
EnciclopediadeTrminosdeComputacin
Autor:LindaGail/JohnChristie
Editora:PHH,PenticeHall
Trabajorealizadopor:
GilberBASILIOROBLES
Av.FaustoFigueroaB4.
Huanuco,RepblicadelPer.
TelfonoCel.:(064)9473720
EMail: gilber.basilio.robles@hotmail.com
Homepage: http://gilber.es.tl http://www.usuarios.lycos.es/gisatel

También podría gustarte