Cul es la diferencia entre el anlisis del sistema y el diseo del sistema?

Buena pregunta. Ambos estn estrechamente relacionados; de hecho, el diseo del

sistema forma parte del ciclo de vida de desarrollo del sistema (SDLC).
Primero debes entender qu es un "sistema". Bsicamente, los sistemas de
informacin estn en todas partes. Considere su supermercado local: tienen un
sistema que rastrea los niveles de inventario y reordena las existencias segn se
requiera. Tambin tienen un sistema que se ocupa del lado financiero de la
organizacin; cunto dinero se ha ganado a partir de un da de negociacin,
presupuestos de personal, etc. Estos sistemas no solo incluyen computadoras y
software. Tambin incluyen a las personas que usan el sistema y los procedimientos.
En resumen, un sistema de informacin es una coleccin de componentes de
hardware, software, datos, humanos y procesales destinados a proporcionar los datos
y la informacin correctos a la persona adecuada en el momento correcto.
El anlisis de sistemas se refiere al proceso por el cual pasan los analistas para
determinar cmo debera funcionar un sistema, es decir, determinar qu funciones
debe realizar el sistema, si es factible que se desarrolle (por ejemplo, la viabilidad
financiera, los beneficios del sistema). superan los costos de desarrollo del
sistema?), qu datos se recopilarn y almacenarn. En esencia, el anlisis de sistemas
se ocupa de la resolucin de problemas, creando un sistema que resolver un
problema organizacional.
El diseo de sistemas es en realidad el tercer paso del SDLC: es donde el diseo del
anlisis muestra cmo funcionar el sistema. Los componentes fsicos del sistema
se definen aqu, que especifica cmo se resolver el problema en cuestin.
Cmo hacer un anlisis de sistema y diseo de cualquier sistema?
El Anlisis y Diseo de Sistemas de Pozo, en resumen (SAD) es un proceso muy
riguroso e iterativo que requiere una mente abierta y espacio suficiente para
contingencias para que est preparado para todas las eventualidades. Puede seguir
los siguientes pasos para disear un sistema como analista:
1. Definir el enunciado del problema: para esta parte, deber realizar
investigaciones preliminares. Muchos analistas utilizan un amplio uso de
modelos y realizan entrevistas, desarrollan modelos de flujo de trabajo para
comprender el flujo actual de informacin, servicios y materiales. Le ayudar
a identificar las reas problemticas e identificar las principales lagunas en el
 sistema y cuellos de botella. Tendr que consultar a todos, desde los
empleados de primera lnea y la alta direccin. Definir la problemtica reas,
algunas herramientas que puede usar en este paso pueden ser:
Diagramas de diagramas de flujo
Cuestionarios y entrevistas.
Anlisis cuantitativo y cualitativo.
Despus de este paso, necesita disear un marco de tiempo y usar una utilidad de
administracin de proyectos ideando el marco de tiempo y las actividades.
Establezca plazos para usted.
2. Basado en el paso anterior seleccione las aplicaciones que se usaran en el
proceso y el tipo de sistema informtico y software necesarios para
automatizarlo / actualizarlo. Deber seleccionar si desea comprar una
aplicacin comercial o personalizar una aplicacin de software que satisfaga
sus necesidades especficas.
3. Presente su propuesta final y obtenga los trminos y condiciones formalmente
acordados por tu cliente. Haga la documentacin necesaria.
4. Implementacin: la etapa ms complicada y crucial en Anlisis y Diseo de
Sistemas. Tendr que ayudar a los empleados y a la administracin a
comprender los beneficios del sistema propuesto. Luego implementar su
solucin y capacitar a los empleados en el nuevo sistema. Tambin necesitar
hacer la documentacin necesaria para las aplicaciones, tambin necesitar
evaluar paso a paso cmo se est llevando a cabo el proceso y hacer los
cambios necesarios si surge la necesidad.
En desarrollo de software, cul es la diferencia entre anlisis y diseo?
El anlisis implica medir, detallar, aclarar y organizar. El anlisis generalmente se
realiza en preparacin para alguna otra actividad, como una decisin o un diseo. El
diseo se realiza cuando se toma la decisin de construir algo. El diseo involucra
imaginar y especificar alguna creacin que se ajuste a algunos requisitos. La mejor
manera de recordar la diferencia es que puede juzgar un diseo como bueno o malo,
mientras que solo puede validar un anlisis como correcto o incorrecto. Por ejemplo:
El diseo de un automvil no est bien o mal, es bueno o malo.
El anlisis del rendimiento del automvil es correcto o incorrecto, nunca es
bueno o malo.
REGLAS DEL CODD

Las doce reglas de Codd son un conjunto de trece reglas (numeradas del cero al
doce) propuestas por Edgar F. Codd, un pionero del modelo relacional de bases de
datos, diseado para definir lo que se requiere de un sistema de gestin de bases de
datos para considerarlo relacional.
Codd produjo estas reglas como parte de una campaa personal para evitar que su
visin de la base de datos relacional se diluya, ya que los proveedores de bases de
datos se mezclaron a principios de la dcada de 1980 para volver a empaquetar
productos existentes con una apariencia relacional. La Regla 12 fue diseada
especialmente para contrarrestar tal posicionamiento.
Regla 0:
El sistema debe calificar como relacional, como una base de datos y como un sistema
de gestin.
Para que un sistema califique como un sistema de administracin de bases de datos
relacionales (RDBMS), ese sistema debe usar sus recursos relacionales
(exclusivamente) para administrar la base de datos.
Regla 1: la informacin
Toda la informacin en una base de datos relacional (incluidos los nombres de tabla
y columna) se representa de una sola manera, a saber, como un valor en una tabla.
Regla 2: El acceso garantizado
Todos los datos deben ser accesibles. Esta regla es esencialmente una reafirmacin
de los principios fundamentales requisito para claves primarias. Dice que cada valor
escalar individual en la base de datos debe ser lgicamente direccionable
especificando el nombre del contenedor tabla, el nombre de la columna que lo
contiene y el valor de la clave principal del contenido fila.
Regla 3: tratamiento sistemtico de valores nulos
El DBMS debe permitir que cada campo permanezca nulo (o vaco).
Especficamente, debe admitir una representacin de "informacin faltante e
informacin inaplicable" quees sistemtico, distinto de todos los valores regulares
(por ejemplo, "distinto de cero o cualquier otro nmero ", en el caso de los valores
numricos), e independientemente del tipo de datos. Tambin se da a entender que
tales representaciones deben ser manipuladas por el DBMS en una forma
sistemtica.
Regla 4: Catlogo activo en lnea basado en el modelo relacional
El sistema debe admitir un catlogo en lnea, en lnea y relacional accesible para
usuarios autorizados por medio de su lenguaje de consulta habitual. Es decir, los
usuarios deben estar capaz de acceder a la estructura de la base de datos (catlogo)
usando el mismo lenguaje de consulta que usan para acceder a los datos de la base
de datos.
Regla 5: la sublenguaje de datos comprensivos
El sistema debe admitir al menos un lenguaje relacional que
1. Tiene una sintaxis lineal
2. Se puede usar de forma interactiva y dentro de los programas de aplicacin
3. Admite operaciones de definicin de datos (incluidas las definiciones de vista),
datos operaciones de manipulacin (actualizacin y recuperacin), seguridad e
integridad restricciones y operaciones de gestin de transacciones (inicio,
confirmacin y retrotraccin).
Regla 6: la actualizacin de la vista
Todas las vistas que son tericamente actualizables deben ser actualizadas por el
sistema.
Regla 7: insercin, actualizacin y eliminacin de alto nivel
El sistema debe admitir operadores de insercin, actualizacin y eliminacin de set-
at-a-time.

Esto significa que los datos se pueden recuperar de una base de datos relacional en
conjuntos construidos de datos de mltiples filas y / o mltiples tablas. Esta regla
establece que las operaciones de insercin, actualizacin y eliminacin deben ser
compatibles con cualquier conjunto recuperable en lugar de solo una fila en una sola
tabla.
Regla 8: independencia de los datos fsicos
Cambios al nivel fsico (cmo se almacenan los datos, ya sea en arreglos o enlaces
listas, etc.) no debe requerir un cambio en una aplicacin basada en la estructura.
Regla 9: independencia de datos lgicos
Los cambios en el nivel lgico (tablas, columnas, filas, etc.) no deben requerir un
cambio en una aplicacin basada en la estructura. La independencia de los datos
lgicos es ms difcil de lograr que la independencia fsica de los datos.
Regla 10: independencia de la integridad
Las restricciones de integridad deben especificarse por separado de los programas
de aplicacin y almacenarse en el catlogo. Debe ser posible cambiar tales
restricciones cuando sea apropiado sin afectar innecesariamente las aplicaciones
existentes.
Regla 11: independencia de la distribucin
La distribucin de porciones de la base de datos a varias ubicaciones debe ser
invisible para los usuarios de la base de datos. Las aplicaciones existentes deben
continuar funcionando con xito:
1. Cuando se presenta por primera vez una versin distribuida del DBMS; y
2. Cuando los datos distribuidos existentes se redistribuyen alrededor del sistema.
Regla 12: La no subversin
Si el sistema proporciona una interfaz de bajo nivel (registro a la vez), esa interfaz
no puede utilizarse para subvertir el sistema, por ejemplo, eludiendo una seguridad
relacional o una restriccin de integridad.

REGLAS DE CODD'S 12, recuperadas el 15 de agosto de 2013. Disponible en:

http://en.wikipedia.org/wiki/Codd%27s_12_rules