1.0 Introduccion Al MPDS

INTRODUCCIÓN AL PROCESO
DE DESARROLLO DE
SOFTWARE
SAMIR MIDEROS
SEBASTIAN SOLANO
¿Qué es Software?
■ Según el IEEE “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”. Dicho en otras
palabras, no es más que todos los programas o aplicaciones que integran
un computador y que le permiten realizar tareas específicas. El software
le da instrucciones al hardware de la forma como debe realizar una tarea.
¿Cómo es el proceso de Software?
Es un conjunto de personas, estructuras de organización, reglas, políticas, actividades y sus
procedimientos, componentes de software, metodologías, y herramientas utilizadas o creadas
específicamente para definir, desarrollar, ofrecer un servicio, innovar y extender un producto
de software.
Un proceso de software efectivo habilita a la organización a incrementar su productividad al
desarrollar software:
■ Permite estandarizar esfuerzos, promover reuso, repetición y consistencia entre proyectos.
■ Provee la oportunidad de introducir mejores prácticas de la industria.
■ Permite entender que las herramientas deben ser utilizadas para soportar un proceso.
Establece la base para una mayor consistencia y mejoras futuras.
Un proceso de software mejora los esfuerzos de mantenimiento y soporte:
■ Define cómo manejar los cambios y liberaciones a sistemas de software existentes.
■ Define cómo lograr la transición del software a la operación, y cómo ejecutar los esfuerzos
de operación y soporte.
■ Necesitamos un proceso de software cuya funcionalidad esté probada en la práctica, y
personalizado para que cumpla con nuestras necesidades específicas.
Modelos de procesos
■ Actualmente existe una gran variedad de modelos para procesos de Software.
Podemos entenderlos más fácilmente si los clasificamos en dos tipos: genéricos y
específicos.
Fases y etapas
Análisis de requisitos
■ Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras
que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere
de habilidad y experiencia en la ingeniería de software para reconocer requisitos
incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el
cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema,
cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo,
se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades
que participarán en el desarrollo del software. La captura, análisis y especificación de
requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran
medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de
trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de
Requisitos. La IEEE Std. 830-1998 normaliza la creación de las Especificaciones de
Requisitos Software (Software Requirements Specification).
Diseño y arquitectura
■ Determina cómo funcionará de forma general sin entrar en detalles. Consiste en

incorporar consideraciones de la implementación tecnológica, como el hardware, la red,
etc. Se definen los casos de uso para cubrir las funciones que realizará el sistema, y se
transforman las entidades definidas en el análisis de requisitos en clases de diseño,
obteniendo un modelo cercano a la programación orientada a objetos.
Programación
■ Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de
software, pero no es necesariamente la porción más larga. La complejidad y la duración
de esta etapa está íntimamente ligada al o a los lenguajes de programación utilizados.
Pruebas y testeos
■ Se comprueba que el software realice correctamente las tareas indicadas en la
especificación. Una técnica de prueba es probar por separado cada módulo del software, y
luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena
práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la
programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe
hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de
pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema
de pruebas, de esta forma se evalúa que la documentación]entregada sea de calidad, que los
procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las
cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas
conformada por programadores con experiencia, personas que saben sin mayores
indicaciones en que condiciones puede fallar una aplicación y que pueden poner atención
en detalles que personal inexperto no consideraría.
Documentación
■ Todo lo que se refiere a la documentación del propio desarrollo del software y de la

gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales
de usuario, manuales técnicos, etc; todo con el propósito de eventuales
correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
Mantenimiento
■ Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos.
Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de
2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña
parte de este trabajo consiste en arreglar errores. La mayor parte consiste en extender el
sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la Ingeniería
civil, Arquitectura y trabajo de construcción es dar mantenimiento.
■ Se puede decir que con la mejora continua garantiza la calidad del producto, ya que el
estarla aplicando día con día es la mejor decisión que puede llegar a tener cualquier
empresa, porque de esta manera evita grandes problemas en la elaboración o desarrollo de
los productos. Esto es fundamental para todas las empresas ya que se vuelven
competitivas, con mayor productividad y eficiencia. No hay que olvidar que la mejora se
da porque el cliente es el rey y hay que satisfacer todas y cada una de sus necesidades
siempre garantizando la calidad.
Flujos de proceso
■ Lineal
■ Interactivo
■ Evolutivo
■ Paralelo

1.0 Introduccion Al MPDS

Cargado por

Copyright:

Formatos disponibles

1.0 Introduccion Al MPDS

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

1.0 Introduccion Al MPDS

Cargado por

Copyright:

Formatos disponibles

INTRODUCCIÓN AL PROCESO

■ Según el IEEE “Es el conjunto de los programas de cómputo,

■ Determina cómo funcionará de forma general sin entrar en detalles. Consiste en

■ Todo lo que se refiere a la documentación del propio desarrollo del software y de la

También podría gustarte