Autoevaluacion:
1. ¿Cuales son las características del paradigma ciclo de vida clásico?
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos
• arquitectura de software
• detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
2. ¿En que consiste el paradigma de construcción de prototipos?
Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.
En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir. El método tomara una de las 3 formas siguientes:
Un prototipo en papel que describa la interrelacion hombre-maquina de forma que facilita el usuario la comprensión como producirá tal interrelacion; un prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado o un programa existente que ejecute parte o toda la función deseada pero que tenga otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.
3. ¿Cuales son los pasos a seguir en el paradigma espiral?
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
4. ¿Cuáles son las desventajas del modelo DRA?
• Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
• Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
• Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
• Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
• Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.
5. ¿Cuál es el parádigma de técnicas de cuarta generación?
El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.
Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generación de informes, manipulación de datos, interacción y definición de pantallas y generación de códigos, capacidades gráficas de alto nivel y capacidad de hojas de cálculo. Cada una de estas herramientas existe, pero solo son para dominios de aplicación muy específicos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones de software.
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos
• arquitectura de software
• detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
2. ¿En que consiste el paradigma de construcción de prototipos?
Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.
En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir. El método tomara una de las 3 formas siguientes:
Un prototipo en papel que describa la interrelacion hombre-maquina de forma que facilita el usuario la comprensión como producirá tal interrelacion; un prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado o un programa existente que ejecute parte o toda la función deseada pero que tenga otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.
3. ¿Cuales son los pasos a seguir en el paradigma espiral?
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
4. ¿Cuáles son las desventajas del modelo DRA?
• Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
• Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
• Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
• Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
• Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.
5. ¿Cuál es el parádigma de técnicas de cuarta generación?
El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.
Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas las siguientes herramientas: lenguajes no procedimentales para consulta a base de datos, generación de informes, manipulación de datos, interacción y definición de pantallas y generación de códigos, capacidades gráficas de alto nivel y capacidad de hojas de cálculo. Cada una de estas herramientas existe, pero solo son para dominios de aplicación muy específicos. No existe hoy disponible un entorno deT4G que pueda aplicarse con igual facilidad a todas las categorías de aplicaciones de software.
Proporcione cinco ejemplos de desarrollo del software que sean adecuados para construir prototipos. Nombre dos o tres aplicaciones que fueran más difíciles para construir prototipos.
• adecuados para construir prototipos,
1. Sistema para un negocio de venta por internet, como mercado libre.
2. Sistema para administración de una refaccionaria.
3. Sistema de almacenes.
4. Sistemas para tiendas de autoservicio.
5. Sistemas para consultar citas medicas como ISSSTENET.
• Difíciles para construir prototipos
1. Sistemas para dispositivos médicos.
2. Sistemas para aviónica
Explique como el paradigma ciclo de vida clásico y el de construcción de prototipos pueden acomodarse en el modelo espiral.
Es también al igual que el anterior un modelo evolutivo
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
Que es el analista de sistemas?
El analista tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema informático.
El diseñador realiza, con base en el análisis, el diseño de la solución
El analista tiene que delimitar el análisis para ver lo que se quiere hacer inicialmente y después darle al usuario nuevas opciones de uso.
Hoy en día, estas funciones han quedado claramente obsoletas a pesar de que la categoría profesional sigue existiendo como tal. Los avances de la ingeniería del software en su corta vida han puesto de manifiesto que estas funciones no son suficientes para lograr un mínimo éxito en el desarrollo de software.
Las funciones más relevantes que faltan son:
Dirección (de proyectos), para dirigir los recursos hacia el resultado deseado.
Educción de requisitos, para determinar el comportamiento que se espera del software.
Garantía de calidad, para garantizar las expectativas del cliente.
Diseño, para que exista una mínima certeza de que el software es viable y eficaz con la tecnología existente.
Gestión de configuración, para controlar el caos a medida que el software crece.
Estas funciones han sido adoptadas en muchos casos por analistas, pero no son materia específica de esta profesión. En algunas organizaciones (y en algunos países) la profesión ya no existe, siendo sustituida por otras figuras tales como el ingeniero de software, el jefe de proyecto, el modelador de software, o el analista-programador. Esta última figura es muy popular ya que resuelve los típicos problemas de comunicación que existían entre analistas y programadores. Estos problemas se deben a la extrema idealización de la especialización de funciones.
Es deseable también que el analista de sistemas tenga conocimientos -al menos básicos- de usabilidad. Ya que cualquier sistema que no esté al servicio de los usuarios o diseñado pensando en el usuario, no tiene mucho sentido.
Que es el analista-programador?
El Analista Programador es la persona que realiza las funciones de un analista técnico y de un programador; es decir, parte de una información previa recibida del analista funcional, en función de la cual desarrolla las aplicaciones y organiza los datos. Es el perfil más buscado en la actualidad.
En base a sus conocimientos en el o los lenguajes de programación necesarios en cada caso, sintetiza, organiza y lo lleva a la práctica mediante la codificación de la silución. Requiere características de personalidad similares a las de un programador, con mayor visión global y capacidad de análisis y síntesis.
Que es un programador?
Un programador es aquella persona que escribe, depura y mantiene el código fuente de un programa informático, es decir, del conjunto de instrucciones que ejecuta el hardware de una computadora para realizar una tarea determinada. La programación es una de las principales disciplinas dentro de la informática. En la mayoría de los países, programador es también una categoría profesional reconocida.
Los programadores también reciben el nombre de desarrolladores de software, aunque estrictamente forman parte de un equipo de personas de distintas especialidades (mayormente informáticas), y siendo que el equipo es propiamente el desarrollador.
El programador se encarga de la implementación de prototipos mediante un lenguaje de programación, que compilados pueda entender la computadora.
Inicialmente, la profesión se formalizó desde el enfoque Tayloriano de la especialización de funciones en la empresa. Así, el proceso de producción de software se concibe como un conjunto de tareas altamente especializadas donde está claramente definido el papel de cada categoría profesional:
El analista, tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema de información.
El programador cuya única función consistía en trasladar las especificaciones del analista en código ejecutable para la computadora. Dichas especificaciones se recogen en un documento denominado cuaderno de carga, medio de comunicación entre ambos. Esto se consideraba un trabajo mecánico y de baja cualificación.
Hoy día se reconoce que este enfoque no es válido para organizar tareas de tipo intelectual, como es el desarrollo de software. De manera que la profesión de programador ha ido evolucionando. Las dificultades de comunicación entre analistas y programadores (un mero documento no basta para describir lo que se quiere hacer) dio origen a una categoría de profesional intermedia, denominada analista-programador. La concepción original del programador ha desaparecido siendo sustituida por la de un profesional mucho más formado y con unas funciones menos "mecánicas".
La profesión de analista también ha evolucionado, surgiendo el concepto diseñador (de software). Esto se debe a los avances de la ingeniería del software donde se reconoce que el análisis es una actividad compleja y distinta del diseño. Escuetamente, el análisis describe el problema (es decir qué hacer) mientras que el diseño describe la solución (cómo hacerlo).
En la mayoría de países industrializados esto ha dado lugar a la categoría profesional del diseñador o arquitecto del software.
Obligatorias:
¿Cual de los paradigmas de la ingeniería de software sería más útil para las aplicaciones del software?¿Porque?
PARADIGMA DEL MODELO ESPIRAL
Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.
CARACTERISTICAS: Es también al igual que el anterior un modelo evolutivo que combina el modelo clásico con el diseño de prototipos. Incluye la etapa de análisis de riesgos, no incluida anteriormente. Es ideal para crear productos con diferentes versiones mejoradas como se hace con los software modernos de microcomputadoras. La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. Este es el enfoque más realista actualmente.
El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
Proporcione tres ejemplos de técnicas de 4ª generación.
1. Con muy pocas excepciones el dominio de aplicación actual de las T4G esta limitada a las aplicaciones de sistema de información comerciales, específicamente del análisis de información comerciales, específicamente del análisis de información y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G se han usado muy poco en productos de ingeniería y áreas de aplicación de sistemas.
2. La recolección de datos preliminares que acompañan al uso de T4G parece indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas de trabajo medio así como también la cantidad e análisis y diseño.
3. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.
Describa el modelo concurrente
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo
Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.
El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
A medida que vaya hacia afuera del modelo espiral ¿qué puede decir del software que se esta desarrollando?
Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan según la reacción ante la evolución del cliente.
VENTAJAS:
• El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software.
• Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
• Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
• Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto.
• Reduce los riesgos antes de que se conviertan en problemáticos.
Pero al igual que otros paradigmas puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. El modelo en sí mismo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.
La siguiente figura define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representan el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuara hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del cubo siguiente y se inicia un nuevo proyecto de desarrollo.
Explique los pasos tradicionales de cualquier modelo
Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algún subconjunto de estos requerimientos al software; esta versión del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos.
La ingeniería y análisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequeña cantidad de análisis y diseño a nivel superior. Además de un análisis costo beneficio del sistema es decir si toda la inversión que se hará para el sistema conviene a los beneficios que traerá el mismo.
Análisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la información del software, así como la función, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.
• estructura de datos
• arquitectura de software
• detalle procedimental
El diseño traduce los requerimientos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificación. Como los requerimientos y el diseño que se documentan forman parte de la configuración del software.
Codificación. El diseño debe traducirse en una forma legible. El paso de la codificación ejecuta la tarea de establecer la etapa de diseño legible para la maquina, si el diseño se ejecuta de una manera detallada la codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa, la prueba se enfoca sobre la lógica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producirá los resultados que realmente se requieren.
Mantenimiento. El software sufrirá indudablemente cambios después que se le entregue al cliente los cambios ocurrirán debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos periféricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.
Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, entrevista, diseño, codificación, prueba y mantenimiento.
No hay comentarios:
Publicar un comentario