lunes, 24 de diciembre de 2012

Conceptos de Aspectos de Gestión


Conceptos de Aspectos de Gestión

La gestión eficaz de un proyecto de software se centra en las cuatro P’s:personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío. El gestor que emprende un proyecto sin un plan sólido arriesga el éxito del producto.

Personal

La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado se viene discutiendo desde los años 60 (por ejemplo, COUSO, WíT94, DEM981). De hecho, el «factor humano» es tan importante que el Instituto de Ingeniería del Software ha desarrollado unModelo de madurez de la capacidad de gestión de personal (MMCGP) «para aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar retener el talento necesario para mejorar su capacidad de desarrollo de software» [CUR94].

El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo. El MMCGP es compañero del modelo de madurez de la capacidad software, que guía a las organizaciones en la creación de un proceso de software maduro.

Cargos del Personal

  1. Operador de PC
  2. Técnico de Soporte y Mantenimiento
  3. Técnico de Reparación de PC, impresoras, monitores, celulares, etc.
  4. Técnico en Programación
  5. Técnico en Redes de PC, teléfonos y de comunicación
  6. Ingeniero en Computación
  7. Ingeniería en Sistemas de Información
  8. Ingeniería en Telecomunicaciones
  9. Administrados de Base de Datos
  10. Administrador de Redes
  11. Administrador de Servidores
  12. Administrador de Sistemas de Informáticos
  13. Analista Categorías: A, B, C.
  14. Diseñador de Web y de Interfaz
  15. Diseñador/a
  16. Auditor/a
  17. Evaluador/a
  18. Diseñador/a Informático/a
  19. Director/a de Centros
  20. Capacitadores  

Producto

Antes de poder planificar un proyecto, se deberían establecer los objetivos y el ámbito del producto, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso.


El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software.  Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).


El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto, y, más importante, intenta abordar estas características de una manera cuantitativa. Una vez que se han entendido los objetivos y el ámbito del producto, se consideran soluciones alternativas.


Proceso

Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas, hitos, productos del trabajo y puntos de garantía de calidad permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras tales como garantía de calidad del software, gestión de la configuración del software y medición cubren el modelo de proceso. Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.

Proyecto

Dirigimos los proyectos de software planificados y controlados por una razón principal es la Única manera conocida de gestionar la complejidad. Y todavía
seguimos esforzándonos. En 1998, los datos de la industria del software indicaron que el 26% de proyectos de software fallaron completamente y que el 46% experimentaron un desbordamiento en la planificación y en el coste [REE99]. Aunque la proporción de éxito para los proyectos de software ha mejorado un poco, nuestra proporción de fracaso de proyecto permanece más alto del que debería ser. Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.


Practicas Críticas

El Concilio Airlie ha desarrollado una lista de «prácticas críticas de software para la gestión basada en el rendimiento». Estas prácticas son «utilizadas deun modo consistente por, y consideradas críticas por, organizaciones y proyectos de software de mucho éxito cuyo rendimiento “final” es más consistente que los promedios de la industria» [AIR99]. En un esfuerzo por permitir a una organización de software determinar si un proyecto específico ha implementado prácticas críticas, el Concilio Airlie ha desarrollado unconjunto de preguntas de «Visión Rápida» [AIR99] para un proyecto:

Gestión formal del riesgo ¿Cuáles son los diez riesgos principales para este proyecto? Para cada uno de los riesgos ¿cuál es la oportunidad de que el riesgo se convierta en un problema y cuál es el impacto si lo hace?

Coste empírico y estimación de la planificación ¿Cuál es el tamaño actual estimado de la aplicación de software (sin incluir el software del sistema) que será entregada en la operación? ¿Cómo se obtuvo?

Gestión de proyectos basada en métricas ¿Dispone de un programa de métricas para dar una primera indicación de los problemas del desarrollo? Si es así, ¿cuál es la volatilidad de los requisitos actualmente?


Seguimiento del valor ganado ¿Informa mensualmente de las métricas del valor ganado? Si es así, ¿están calculadas estas métricas desde una red de actividades de tareas para el esfuerzo total a la próxima entrega?

Seguimiento de defectos frente a objetivos de calidad ¿Realiza el seguimiento e informa periódicamente del número de defectos encontrados en cada prueba de inspección [revisión técnica formal] y ejecución desde el principio del programa y del número de defectos que se corrigen y se producen en la actualidad?

Gestión del programa del personal ¿Cuál es la media de rotación de la plantilla en los tres Últimos meses por cada uno de los distribuidores/desarrolladores involucrados en el desarrollo del software para este sistema?

Si un equipo de proyectos de software no puede responder a estas preguntas, o las responde inadecuadamente, se debe realizar una revisión completa de las prácticas del proyecto.

PRACTICAS CRITICAS


PRACTICAS CRITICAS

El Concilio Airlie ha desarrollado una lista de «prácticas críticas de software para la gestión basada en el rendimiento». Estas prácticas son «utilizadas de un modo consistente por, y consideradas críticas por, organizaciones y proyectos de software de mucho éxito cuyo rendimiento “final” es más consistente que los promedios de la industria» [AIR99]. En un esfuerzo por permitir a una organización de software determinar si un proyecto específico ha implementado prácticas críticas.


Gestión formal del riesgo
 
¿Cuáles son los diez riesgos principales para este proyecto? Para cada uno delos riesgos ¿cuál es la oportunidad de que el riesgo se convierta en un problema y cuál es el impacto si lo hace?


Coste empírico y estimación de la planificación
 
 ¿Cuál es el tamaño actual estimado de la aplicación de software (sin incluir el software del sistema) que será entregada en la operación? ¿Cómo se obtuvo?


Gestión de proyectos basada en métricas
 
¿Dispone de un programa de métricas para dar una primera indicación de los problemas del desarrollo? Si es así, ¿cuál es la volatilidad de los requisitos actualmente?

Seguimiento del valor ganado
 
¿Informa mensualmente de las métricas del valor ganado? Si es así, ¿están calculadas estas métricas desde una red de actividades de tareas para el esfuerzo total a la próxima entrega?


Seguimiento de defectos frente a objetivos de calidad
 
 ¿Realiza el seguimiento e informa periódicamente del número de defectos encontrados en cada prueba de inspección [revisión técnica formal] y ejecución desde el principio del programa y del número de defectos que se corrigen y se producen en la actualidad?


Gestión del programa del personal
 
¿Cuál es la media de rotación de la plantilla en los tres Últimos meses por cada uno de los distribuidores/desarrolladores involucrados en el desarrollo del software para este sistema?

GESTION DEL PROYECTO DEL SOFTWARE

La gestion de proyecto del software implica la planificacion , supervision y control del personal , del proceso y los eventos que ocurren mientras evoluciona el software desde la fase preliminar a la implementacion operacional. La gestión eficaz de un proyecto de software se centraen las cuatro P’s:personal, producto, proceso proyecto, el orden no es arbitrario.


Personal

El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización del trabajo desarrollo cultural de espíritu de equipo.

 El proceso del software (y todos los proyectos de software)lo componen participantes que pueden clasificarse en una de estas cinco categorías:

Gestores superiores, que definen los aspectos de negocios que a menudo tienen una significativa
                                   influencia en el proyecto.

Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar controlar a los profesionales que
                                                  realizan el trabajo de software.

Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o
                         aplicación.

Clientes, que especifican los requisitos para la ingeniería del software otros elementos que tienen
                menor influencia en el resultado.

Usuarios finales, que interaccionan con el software una vez que se ha entregado para la producción

 Producto

Antes de poder planificar un proyecto, se deberían establecerlos objetivos el ámbito del producto‘, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta  información, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso,


El desarrollador de software el cliente deben reunirse para definir los objetivos del producto y suámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio continúa como el primer paso en el análisis de los requisitos del software Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).El ámbito identifica los datos primarios, funciones comportamientos que caracterizan al producto, y, más importante, intenta abordar estas características de una manera cuantitativa .Una vez que se han entendido los objetivos y el ámbito del producto, se consideran soluciones alternativas


Proceso

Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas, hitos, productos del trabajo y puntos de garantía de calidad permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras tales como garantía de calidad del software, gestión de la configuración del software y medición cubren el modelo de proceso. Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.


 
Proyecto

Dirigimos los proyectos de software planificados y controlados por una razón principal es la Única manera conocida de gestionar la complejidad. Y todavía 

seguimos esforzándonos. En 1998, los datos de la industria del software indicaron que el 26% de proyectos de software fallaron completamente y que el 46% experimentaron un desbordamiento en la planificación y en el coste [REE99]. Aunque la proporción de éxito para los proyectos de software ha mejorado un poco, nuestra proporción de fracaso de proyecto permanece más alto del que debería ser. Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.

modelo de desarrollo de software

Modelo de desarrollo de software


Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final.
Un modelo de desarrollo establece el orden en el que se harán las cosas en el proyecto, nos provee de requisitos de entrada y salida para cada una de las actividades.

Es necesario destacar el ciclo de vida del proyecto y el modelo de desarrollo.El ciclo de vida del proyecto ayuda a controlar las actividades del proyecto desde el inicio al fin del mismo.El modelo de desarrollo nos ayuda a la forma en la que vamos a construir el producto.Ambos se complementan para generar el producto desde el punto de vista técnico y administrativo.

Modelos de Desarrollo

El Modelo de Cascada.El Modelo en V.En Flor.PrototiposEl Modelo de Espiral.El Modelo de Procesos.Desarrollo Incremental.

El Modelo de Cascada

El modelo en cascada, uno de los primeros modelos de desarrollo de software que considera las diferentes actividades como fases separadas de tal forma que para iniciar una nueva actividad debe esperarse a la finalización de la actividad anterior. El resultado de cada etapa es uno o más documentos aprobados.
Las principales actividades de este modelo son las que podemos observar en el siguiente gráfico extraído de la red:

1. Análisis y definición de requerimientos: En esta etapa se definen los requisitos y requerimientos del sistema software a partir de consultas con los clientes y los usuarios del futuro sistema software. De esta etapa surge el documento de especificación de requisitos (SRD) que contiene toda la especificación del sistema sin entrar en detalles de diseño.
2. Diseño del sistema y del software: En esta etapa se dividen los requerimientos en subsistemas, se establece un arquitectura completa y se identifican y describen las relaciones fundamentales del sistema software. De esta etapa surge el documento de diseño del software (SDD) que contiene toda la descripción del sistema desde el punto de vista del diseño.
3. Implementación: En esta etapa el diseño del software se lleva a cabo implementándolo en un lenguaje de programación. Aquí se implementa el código fuente, se crean las bibliotecas y se reutilizan los componentes.
4. Pruebas: En esta etapa, los programas se integran y se prueban como un sistema completo para asegurar que se cumplen los requerimientos del software. Después de las pruebas el sistema se entrega al cliente.
5. Mantenimiento: Es la etapa más larga de todos los procesos de desarrollo. El sistema se instala y se pone en funcionamiento corrigiendo todos los errores no descubiertos en las etapas anteriores. También se mejora la implementación añadiendo nuevos requerimientos siempre que el usuario los necesite.
Este modelo ha sido muy criticado porque tiene muchas desventajas:
- Lo peor de todo es la necesidad de tener todos los requisitos al principio ya que lo normal es que el cliente no tenga perfectamente definidas las especificaciones surgiendo nuevos requisitos a lo largo de las diferentes etapas de desarrollo. Según este modelo hay que tenerTODOS los requisitos en la primera etapa no pudiendose llevar a cabo los requisitos que surgan una vez acabada la etapa de especificación.
- Es normal cometer errores en alguna de las etapas del proceso de desarrollo. Según este modelo cada vez que se identifique algún error cometido hay que volver a la etapa anterior y rehacer el trabajo.
- Por último, no se tiene el producto software hasta el final del proceso de desarrollo, por lo que el cliente no verá los resultados hasta la última fase. Además la mayoría de errores producidos en el análisis se descubren al final.
Así que este enfoque de desarrollo solo debería seguirse si tenemos muy claro las especificaciones desde el primer momento y sabemos que los requisitos no van a ser cambiantes.

El Modelo en V
El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. Como se muestra en la Figura 3, la codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.
La unión mediante líneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble información. Por un lado sirve para indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos en las pruebas correspondientes.
Por lo tanto el modelo en V hace más explícita parte de las iteraciones y repeticiones de trabajo que están ocultas en el modelo en cascada. Mientras el foco del modelo en cascada se sitúa en los documentos y productos desarrollados, el modelo en V se centra en las actividades y la corrección.
Ventajas y desventajas  del Modelo en “V”
Ventajas:

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario
Prototipos

Un prototipo es una versión preliminar de un sistema de información con fines de demostración o evaluación.

Es un método menos formal de desarrollo.El prototipeo es una técnica para comprender las especificaciones.Un prototipo puede ser eliminado.Un prototipo puede llegar a ser parte del producto final.

Construcción de Prototipos

Identificación de Requerimientos.Diseño Rápido.Utilizar el Prototipo.Revisar y Mejorar.


Ventajas:
Útiles cuando los requerimientos son cambiantes.
Cuando no se conoce bien la aplicación.
Cuando el usuario no se quiere comprometer con los requerimientos.
Cuando se quiere probar una arquitectura o tecnología.
Cuando se requiere rapidez en el desarrollo.

Desventajas:
No se conoce cuando se tendrá un producto aceptable.
No se sabe cuantas iteraciones serán necesarias.
Da una falsa ilusión al usuario sobre la velocidad del desarrollo.
Se puede volver el producto aún y cuando no este con los estándares.

El Modelo de Espiral

El modelo en espiral del proceso del software que originalmente fue propuesto por Boehm (1988), El modelo en espiral es una de las metodologías más recomendables para el desarrollo y creación de un programa, ya que consta de pocas etapas o fases, las cuales se van realizando en una manera continua y cíclica.
La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones:
Angular: Indica el avance del proyecto del software dentro de un ciclo.
Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Cada ciclo de la espiral se divide en 4 etapas:

DEFINICION DE OBJETIVOS:

Se definen los objetivos específicosSe identifican las restricciones del procesos y el productoSe identifican los riesgos del proyecto, dependiendo de los riesgos, se planean estrategias alternativas.EVALUACION Y REDUCCION DE RIESGOS:

Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto.
Se definen los pasos para reducir dichos riesgos.

DESARROLLO Y VALIDACION:
 Se elige un modelo para el desarrollo del sistema. Por ejemplo, si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos.
El modelo de cascada es el mas apropiado para el desarrollo si el mayor riesgo identificado es la integración de los subsistemas.

PLANEACION:
 El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral. 


ventajas
Entre sus ventajas están que al pasar a otro nivel se debe preguntar si se sigue, se repite o se anula el proyecto con esto nos evitamos errores y despilfarro de tiempo y dinero. Otra ventaja es que antes de que ocurra un problema nosotros podemos actuar y controlarlo.


Desventajas:
  • Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto.
  • Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.

Desarrollo Incremental


El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.

Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
El Modelo Incremental se puede ver aquí en forma grafica:
- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
- El usuario se involucra más.
- Difícil de evaluar el coste total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Pipeline
La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior.
Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).
También es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del usuario por medio de una interfaz alfanumérica.
Características
- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.
- El usuario se involucre más.
- Difícil de evaluar el costo total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Ventajas:
- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
- También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.
- El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
- Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.
Desventajas:
- El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
- Requiere de mucha planeación, tanto administrativa como técnica.
- Requiere de metas claras para conocer el estado del proyecto.





sábado, 24 de noviembre de 2012

Ingeniería de software



Ingeniería de software
Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software.1 Es la aplicación de la ingeniería al software, ya que integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería.2
Se pueden citar otras definiciones enunciadas por prestigiosos autores:
  • Ingeniería de software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
  • Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software (Bohem, 1976).
  • Ingeniería de software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).


Ingeniería de software

Es el conjunto de los programas de cómputo, procedimientos, reglas,documentación y datos asociados que forman parte de las operaciones de un sistema de computación. [Std. 729, IEEE]
El software no son solo programas, sino todos los documentos asociados y la configuracion de datos que se necesitan para hacer que estos programas operen de manera correcta. Un sistema de software consiste en diversos programas independientes, archivos de configuracion que se utilizan para ejecutar estos programas, un sistema de documentacion que describe la estructura del sistema, la documentacion para el usuario que explica como utilizar el sistema y sitios web que permitan a los usuarios descargar la informacion de productos recientes. [Sommerville, 2004]
El software de computadora es el producto que los ingenieros de software construyen y despues mantienen en el largo plazo. El software se forma con (1) las instrucciones (programas de computadora) que al ejecutar se proporcionan las caracteristicas, funciones y el grado de desempeño deseados; (2) las estructuras de datos que permiten que los programas manipulen informacion de manera adecuada; y (3) los documentos que describen la operacion y uso de los programas. [Pressman, 2005]


Ingeniería de software

La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos (software).
Esta disciplina trasciende la actividad de programación, que es la actividad principal a la hora de crear un software. El ingeniero de software se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.
La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.


Ingeniería de software

El término ingeniería de software abarca al grupo de métodos, técnicas y herramientas que se utilizan en la producción del software, más allá de la actividad principal de programación.
El término "ingeniería" es una referencia directa a la ingeniería civil, una referencia al estudio de la construcción. En programación se aplica el mismo principio que en la construcción de un edificio: poner simplemente ladrillos y cemento no es suficiente. La construcción de un edificio consta de diversos pasos antes de comenzar con la fase de construcción, tales como el diseño arquitectónico, la albañilería, la fontanería, el diseño eléctrico, y durante este período se calculan los presupuestos y los plazos.
Por lo tanto, la ingeniería de software requiere la gestión de proyectos para que se pueda desarrollar una aplicación en el plazo previsto y con el presupuesto establecido que sea satisfactoria para el cliente (el concepto de calidad).

Ingeniería de software

Ingeniería de softwarees el área de la ingenieríaque ofrece métodos y técnicas para desarrollar y mantener software.
Esta ingeniería trata con áreas muy diversas de la informáticay de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a infinidad de áreas: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet, Intranet, etc.
Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:
  • Ingeniería de software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
  • Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software (Bohem, 1976).
  • Ingeniería de software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
  • Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).


Ingeniería de software

La Ingeniería de Software es la ciencia encargada de  estudiar los procesos, métodos y herramientas para desarrollar y mantener software de calidad