Beruflich Dokumente
Kultur Dokumente
Al momento de definir software podríamos verlo como una herramienta que nos sirve para
agilizar nuestro trabajo, en los juegos que usamos en Facebook, las aplicaciones de nuestro
Smartphone, todo lo que usamos en la computadora fue creado por un equipo de desarrollo,
pequeño, grande, distribuido o local, pero la pregunta que nos plantearemos es: Que hay
detrás de este herramienta, como se construyó esta aplicación Es claro que hay un gran
trabajo detrás de cada botón, detrás de cada información que mandamos a guardar.
Como todo proyecto el software tiene un ciclo para desarrollarse y consta de una serie de
pasos que se van completando en diferentes tiempo; este ciclo de desarrollo de software
depende directamente de la metodología que utilizamos para este desarrollo, y no es más que
una serie de pasos/tareas que tenemos que seguir como en cualquier otro proyecto, no hay
nada escondido, nada mágico excepto la gran mente del equipo de desarrollo y las creaciones
para tener una experiencia única al utilizar la aplicación o el paquete de software.
Antes de entrar en más detalle, debemos mencionar que las metodologías para el desarrollo
del software son independiente de la tecnología que usemos para el desarrollo del mismo.
Dentro de los ciclos más conocidos se utilizan: waterfall, test driven development, agile
methodologies, el día de hoy describiremos scrum que pertenece a las metodologías agiles.
Marco teórico
Se define como “un conjunto de etapas parcialmente ordenadas con la intención de lograr
un objetivo, en este caso, la obtención de un producto de software de calidad”. El proceso
de desarrollo de software “es aquel en que las necesidades del usuario son traducidas en
requerimientos de software, estos requerimientos transformados en diseño y el diseño
implementado en código, el código es probado, documentado y certificado para su uso
operativo”. Concretamente “define quién está haciendo qué, cuándo hacerlo y cómo alcanzar
un cierto objetivo” [Jacobson 1998].
Desde sus inicios en la década de 1940, escribir software ha evolucionado hasta convertirse
en una profesión que se ocupa de cómo crear software y maximizar su calidad. La calidad
puede referirse a cuán mantenble es el software, su estabilidad, velocidad, usabilidad,
comprobabilidad, legibilidad, tamaño, costo, seguridad y número de fallas o "bugs", así como,
entre muchos otros atributos, a cualidades menos medibles como elegancia, concisión y
satisfacción del cliente. La mejor manera de crear software de alta calidad es un problema
separado y controvertido cubriendo el diseño de software, principios para escribir código,
llamados "mejores prácticas", así como cuestiones más amplias de gestión como tamaño
óptimo del equipo de trabajo, el proceso, la mejor manera de entregar el software a tiempo
y tan rápidamente como sea posible, la "cultura" del lugar de trabajo, prácticas de
contratación y así sucesivamente. Todo esto cae bajo la rúbrica general de ingeniería de
software.
El término ingeniería del software apareció por primera vez en la década de 1950 y principios
de los años 1960. Los programadores siempre habían sabido sobre ingenieros civiles,
eléctricos y de computadores y debatían qué podría significar la ingeniería para el software.
Historia
El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960
para desarrollar a gran escala funcional de sistemas de negocio en una época de grandes
conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de
información en una muy deliberada, estructurada y metódica, reiterando cada una de las
etapas del ciclo de vida. Los sistemas de información en torno a las actividades resueltas
pesadas para el procesamiento de datos y rutinas de cálculo.
Kendall y Kendall
I. Identificación del problema, oportunidades y objetivos. II. Determinación de los
requerimientos de información. III. Análisis de las necesidades del sistema. IV. Diseño del
sistema recomendado. V. Desarrollo y documentación del software. VI. Pruebas y
mantenimiento del sistema. VII. Implantación y evaluación del sistema.
James Senn
I. Ciclo de vida y desarrollo del sistema. II. Desarrollo por análisis estructurado III. Prototipo
del sistema.
Llorens Fabregas
I. Requerimientos. II. Análisis/Diseño. III. Construcción. IV. Pruebas. V. Producción y
mantenimiento.
Jonas Montilva
I. Definir el proyecto. II. Análisis del contexto. III. Definición de los requerimientos. IV.
Diseño preliminar. V. Diseño detallado.
Roger Pressman
I. Análisis de los requerimientos del Software. II. Diseño. III. Generación de código. IV.
Pruebas. V. Mantenimiento;
EVOLUCIÓN DE LA INGENIERÍA DEL SOFTWARE
Con el transcurso de los años se han desarrollado recursos que conforman la ingeniería del
software, es decir, herramientas y técnicas de especificación, diseño e implementación del
software: la programación estructurada, la programación orientada a objetos, las
herramientas CASE, la documentación, los estándares, CORBA, los servicios web, el
lenguaje UML, etc.
En combinación con las herramientas, también se han hecho esfuerzos por incorporar los
métodos formales al desarrollo de software, argumentando que si se probaba formalmente
que los productos software hacían lo que se les requería, la industria del software sería tan
predecible como lo son otras ramas de la ingeniería.
1970
Programación estructurada sol desde 1969
Programación estructurada Jackson desde 1975
1980
Structured Systems Analysis and Design Methodology (SSADM) desde 1980
Structured Analysis and Design Technique (SADT) desde 1980
Ingeniería de la información (IE/IEM) desde 1981
1990
Rapid application development (RAD) desde 1991.
Programación orientada a objetos (OOP) a lo largo de la década de los 90's
Virtual finite state machine (VFSM) desde 1990s
Dynamic Systems Development Method desarrollado en UK desde 1995.
Scrum (desarrollo), en la última parte de los 90's
Rational Unified Process (RUP) desde 1999.
Extreme Programming(XP) desde 1999
Nuevo milenio
Enterprise Unified Process (EUP) extensiones RUP desde 2002
Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thórisson
Agile Unified Process (AUP) desde 2005 por Scott Ambler
Programación al tiro desde 2018
Aunque los modelos generalmente son realistas y están pensado para avanzar en la
construcción del software de una manera iterativa e incremental, algunas de las características
negativas dentro de estos enfoques son los altos costos de implementar cualquier cambio y
el no ofrecer una buena solución para proyectos que operan en un entorno extremadamente
incierto.
1948
Desarrollo de Kanban
El ingeniero Taiichi Ohno comienza a desarrollar Kanban en Japón dentro de Toyota.
1951
Desarrollo del primer método incremental e interativo: IIDD
Desarrollo del método Desarrollo y Diseño Interativo e Incremental (Iterative and
Incremental Design and Development, IIDD). Éste método se puede considerar como el
primero en el que se define el desarrollo incremental e iterativo y precursor de los que
vendrían después.
Entre los primeros en adoptarlo se encuentra el Departamento de Defensa de los EEUU.
William Deming el difusor del concepto de la Calidad Total, contribuyó a su expansión a
través de la divulgación del "Planificar, Hacer, Analizar y Actuar"
1955
Aplicación del IIDD al desarrollo de Software
Se comienza a utilizar el método Integrativo e incremental en la industria del software con
éxito consiguiendo aumentar la satisfacción del usuario y eliminando problemas en la gestión.
1970
Primera definición del modelo de desarrollo en cascada
Winston Royce publica el artículo "Administrando el desarrollo de sistemas de software
grandes", artículo al que se le suele atribuir la primera descripción del modelo de desarrollo
en cascada. Todavía no tenía definido su nombre ni todas las fases por las cuales lo
conocemos.
1976
Primera definición del modelo de desarrollo en cascada
Thomas Bell y T.A. Thayer utilizan por primera vez la palabra Cascada (waterfall) para el
Modelo de Desarrollo definido para proyectos grandes.
1978
Primera publicación del libro"The Toyota Production System"
Primera publicación del libro en "The Toyota Production System" de Taiichi Ohno donde
se describe el método Lean Manufacturing, revolución de Toyota en la cadena de producción
1986
Primer uso del término SCRUM en sistemas de producción
El primer registro del uso del término SCRUM como analogía del Rugby en el desarrollo. Se
realizó en el artículo “The New Product Development Game.” de la Harvard Business
Review.
Los autores, Hirotaka Takeuchi y Ikujiro Nonaka, aplicaron estas metodologías en empresas
como Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and Hewlett-Packard.
1995
Programación por parejas (Pair Programming)
Jim Coplien y Larry Constantine introducen la idea de Programación por Parejas (Pair
Programming) de forma independiente.
1995
Creación del Método de Desarrollo de Sistemas Dinámicos (DSDM)
Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development
Method o DSDM, 1995).
1995
Publicación del "The SCRUM Development Process"
Jeff Sutherland y Ken Schwaber popularizan Scrum con su artículo "The SCRUM
Development
Process" en la conferencia OOPSLA de Texas.
2002
Scrum alliance
Ken Schwaber, Mike Cohn y Esther Derby fundan la Scrum Alliance.
2002
Creación del Planning Poker
James Grenning inventa el Planning Poker.
2003
Lean Software Development
Mary and Tom Poppendieck publican el libro Lean Software Development adaptación de las
técnicas Lean Manufacturing al desarrollo de software.
2005
Agile Unified Process
Propuesto por Scott Ambler es una versión simplificada del Rational Unified Process (RUP).
El Agile Unified Process describe de forma sencilla como desarrollar sistemas de negocio
utilizando técnicas ágiles u conceptos de RUP que todavía son válidos.
El crecimiento del uso del navegador, corriendo en el lenguaje HTML, cambió la manera en
que estaba organizada la visualización y la recuperación de la información. Las amplias
conexiones de red condujeron al crecimiento y la prevención de virus informáticos
internacionales en computadores con MS Windows, y la gran proliferación de correo basura
se convirtió en una cuestión de diseño importante en sistemas de correo electrónico,
inundando canales de comunicación y requiriendo de precalificación semiautomatizada.
Sistemas de búsqueda de palabra clave evolucionaron en buscadores web, y muchos sistemas
de software tuvieron que ser rediseñados, para la búsqueda internacional, dependiendo de las
técnicas de posicionamiento en buscadores (SEO). Fueron necesarios sistemas de traducción
de lenguaje natural humano para intentar traducir el flujo de información en múltiples
idiomas extranjeros, con muchos sistemas de software siendo diseñados para uso
multilenguaje, basado en conceptos de diseño de traductores humanos. Típicas bases de
usuarios de computadora con frecuencia pasaron de cientos o miles de usuarios a muchos
millones de usuarios internacionales.
MÉTODOS
Un método de ingeniería de software es un enfoque estructurado para desarrollar software
cuyo objetivo es facilitar la producción de productos software de alta calidad a un coste
razonable. Indican cómo construir técnicamente el software. Los métodos abarcan un amplio
espectro de tareas que incluyen: planificación y estimación de proyectos, análisis de los
requerimientos del sistema y del software, diseño de procedimientos algorítmicos,
codificación, prueba y mantenimiento.
A lo largo de los años se han ido desarrollando una gran cantidad de metodologías para
desarrollar software, a menudo vinculadas a algún tipo de organización, que además
desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo
documentada en algún tipo de documentación formal.
Programación estructurada
Técnica en la cual la estructura de un programa tan solo emplea tres estructuras lógicas de
control: secuencia, selección e iteración. La programación estructurada se basa en el teorema
del programa estructurado demostrado por Böhm-Jacopini, el cual establece que cualquier
programa con una entrada y una salida exclusivamente es equivalente a un programa que
contiene solamente las estructuras lógicas mencionadas anteriormente.
Esta nueva forma de programar que dio lugar a programas fiables y eficientes, que además
estaban escritos de manera que facilitaba su comprensión posterior.
Smalltalk fue desarrollado en Xerox PARC por Alan Kay, entre otros, en la década de los 70.
Smalltalk introdujo el término POO para representar el uso de objetos y mensajes como la
base de la computación. Smalltalk fue diseñado para ser un sistema completamente dinámico
en el cual las clases se podrían crear y modificar en tiempo de ejecución en lugar de
estáticamente.
Las características de orientación a objetos han sido agregadas a muchos lenguajes a lo largo
de los años, incluyendo Ada, BASIC, Fortran, Pascal, entre otros. La adición de estas
características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a
menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código.
Extreme Programming
Enfoque formulado por Kent Beck en 1999, que se diferencia de las metodologías
tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la
previsibilidad. Sus defensores consideran que ser capaz de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista
que definir todos los requisitos al comienzo e invertir esfuerzos después en controlar los
cambios.
El reparto de costes entre las distintas fases del proceso de desarrollo es difícil de determinar
dado los distintos modelos de proceso existentes. Sin embargo, en dependencia del modelo
que se adopte, al menos el 60% del coste total se emplea en la actividad de evolución del
sistema. La estimación de este porcentaje es pesimista, ya que la tasa de crecimiento de
nuevos productos software es mucho mayor que la tasa de productos software que quedan
en desuso (no tienen que ser mantenidos), por lo que el número de operaciones de
mantenimiento que se realizan sigue aumentando. El proceso de diseño software debería,
por tanto, tener en cuenta la posterior evolución del sistema.
Las características deseables de un proceso de desarrollo software son:
Claridad: El proceso de desarrollo es claro cuando se entiende con facilidad.
Visibilidad: Un proceso de desarrollo es visible cuando sus actividades producen
resultados claros identificables externamente.
Facilidad de soporte: Exige disponer de herramientas CASE (Computer-Aided
Software Engineering) que den soporte a todas o alguna de las actividades del
proceso de desarrollo.
Fiabilidad: Un proceso de desarrollo es fiable cuando es capaz de detectar posibles
errores.
Facilidad de mantenimiento: Requiere capacidad para incorporar nuevos requisitos o
modificar alguno o algunos de los existentes.
Rapidez: Un proceso software es rápido cuando se puede obtener, a partir de la
especificación, una implementación del sistema en un tiempo reducido.
Modelo evolutivo
En este modelo se entrelazan las actividades de especificación, desarrollo y validación.
Inicialmente, se desarrolla rápidamente un sistema inicial a partir de una especificación muy
abstracta. El sistema se va refinando con la información que van suministrando los clientes
y/o usuarios hasta que se obtiene un sistema final que satisfaga todas las necesidades
previstas. El sistema final obtenido puede rediseñarse para producir otro más robusto y más
fácil de mantener. En la figura 9 se esquematiza este modelo.
Existen dos tipos de procesos de desarrollo evolutivos:
Prototipado desechable: Su objetivo es entender los requisitos del cliente. El resultado del
proceso es la especificación del sistema (el prototipo se deshecha).
Los principales problemas de este modelo son: escasa visibilidad; los continuos cambios que
hacen que los sistemas desarrollados estén deficientemente estructurados; y la necesidad de
disponer, en muchos casos, de un equipo de desarrollo altamente calificado. Estos problemas
hacen que la aplicación de este modelo se suela limitar a sistemas interactivos de tamaño
pequeño o mediano. La deficiente estructura dificulta las tareas de mantenimiento de ahí que
se suela aplicar a sistemas con una vida corta y a partes de grandes sistemas, especialmente a
sistemas de inteligencia artificial y a interfaces de usuario.
Modelo transformacional
Se basa en disponer de una especificación formal del sistema y en transformar, con métodos
matemáticos, esta especificación en una implementación. Si las transformaciones que se
aplican son correctas es posible asegurar que el sistema construido satisface la especificación,
es decir, es posible obtener programas correctos por construcción.
Las ventajas que desde un punto de vista económico puede producir este modelo
actualmente empiezan a ser estudiadas en profundidad. Prácticamente no existe experiencia
sobre el empleo de este modelo, si bien, se están haciendo numerosos estudios e
investigaciones para posibilitar su uso.
Modelo en espiral
Desarrollado por Boehm en el año 1988 con el objetivo de reunir las ventajas de los modelos
de proceso software en cascada y de prototipado. Se incluye el análisis de riesgo como una
parte importante del proceso de desarrollo software.
El modelo tiene la forma de una espiral en la que cada vuelta representa cada una de las fases
en las que se estructura el proceso software y está organizada en cuatro sectores:
Con relación a los proyectos que se desarrollan con mayor envergadura, hay si se toma el
sentido de basarse en una metodología de desarrollo y se empieza a buscar cual sería la más
apropiada para dicho caso. A fin de cuenta no encontramos muchas veces la meas adecuada
y se termina por hacer un diseño propio de metodología, por supuesto no está mal siempre
y cuando sirva para alcanzar el objetivo.
Muchas veces se realiza el diseño del software de manera rígida, tal cual como el cliente lo
solicito, de esa manera cuando el cliente en la "etapa de prueba" solicita un cambio se hace
muy difícil de realizarlo, pues si se hace altera las cosas que no se habían previsto, y este es
uno de los factores que atrasan el proyecto y crea incomodidad al desarrollador y en muchas
oportunidades no llegan a cumplir con el cambio solicitado, esto conlleva malestar en el
cliente puesto que no se sido tomado en cuenta su pedido; para evitar estos incidentes se
debe llegar a un acuerdo formal con el cliente al inicio del proyecto de manera que no
perjudique el desarrollo del mismo.
Muchas veces los usuarios finales se dan cuenta que dejaron de mencionar algunas cosas y lo
manifiestan en la etapa inicial del proyecto cuando se le muestra el prototipo del mismo.
Fases
RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en número
variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas
actividades.
• Inicio
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general
de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.
• Elaboración
En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura
base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso
seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.
Durante el desarrollo, se usan las funciones del lenguaje de programación elegido para crear
archivos de código fuente que contienen la serie requerida de instrucciones que ejecutará el
equipo.
• Construcción
El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben
clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones
realizados por los usuarios y se realizan las mejoras para el proyecto.
Con una revisión del código por parte de pares y gerentes se realizan dos tareas vitales. En
primer lugar, reúne los puntos de vista y las opiniones de varios desarrolladores que pueden
ofrecer enfoques alternativos, señalar errores desapercibidos o sugerir mejoras al código.
Esto ayuda a optimizar la eficiencia y el rendimiento de los códigos. En segundo lugar, ayuda
a ampliar el conocimiento de todos los miembros del equipo al compartir experiencia, lo cual
mejora el desempeño de todo el equipo con el tiempo.
Sin embargo, las herramientas y entornos de desarrollo modernos como Visual Studio
incluyen características que permiten a los miembros del equipo recorrer el código mirando
los valores de las variables y observando cómo cambian. Esto hace que la localización de
errores sea un proceso mucho más fácil y más lógico. Otras características y herramientas
que proporcionan una lista de los procedimientos de código que se ejecutan y la forma en
que el procesador del equipo informático los maneja, ayudan al equipo a localizar errores.
Además, el equipo puede agregar instrumentación (como código para escribir eventos en
archivos de registro) que supervisará el código mientras se ejecuta y ayudará a localizar
errores.
También es común que durante las pruebas de aceptación el cliente solicite cambios en
características de la aplicación a fin de ajustar el software exactamente a sus requisitos. El
desarrollador implementará estos cambios, generalmente según una revisión de los requisitos
y un estudio detallado del impacto que los cambios pueden tener sobre el resto del software.
Un buen diseño original que separe correctamente las responsabilidades de cada componente
facilitará la implementación de cambios sin afectar otras partes de la aplicación.
Algunos desarrolladores trabajan solos o en grupos pequeños, mientras que otros trabajan
en equipos organizados grandes. Como individuo o en un equipo pequeño, el desarrollador
puede ser responsable de todas las tareas del ciclo de vida de desarrollo, incluidos diseño,
pruebas, implementación y mantenimiento. En los equipos grandes normalmente hay grupos
separados responsables del diseño, pruebas, implementación y mantenimiento, y así el
desarrollador se centrará más en la tarea central de escribir código.
Los equipos más grandes por lo general operan de forma estructurada para poder administrar
y supervisar el ciclo de vida de desarrollo y el proceso de desarrollo. Existen muchos
enfoques distintos para administrar el desarrollo de software en un equipo, incluido el ciclo
tradicional orientado al diseño que se basa en tareas planeadas previamente que se siguen una
a otra (el enfoque de “cascada”) y el enfoque más orientado a comentarios donde la
planeación se ejecuta en paralelo con tareas de desarrollo según la información regular del
cliente (el enfoque “ágil”). En la figura 6 se muestran estos dos enfoques principales para el
desarrollo de software.
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
Se refiere a determinar 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
Consiste en comprobar 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 qué
condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal
inexperto no consideraría.
Documentación
Todo lo concerniente 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, o bugs. 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.
Importancia
Actualmente la transición que estamos viviendo hacia una sociedad del conocimiento ha
cambiado profundamente las relaciones entre las personas, empresas y gobiernos: las
empresas usan la red para comunicarse con los clientes, utilizan también herramientas de
gestión del conocimiento para hacer más eficientes, los gobiernos mejoran su presencia en
Internet y los servicios a los ciudadanos a través de la red, los usuarios usan las herramientas
para sus relaciones personales, etc. Se va de forma imparable hacia una sociedad altamente
interconectada donde el eje fundamental es la información.
Está compuesto por un conjunto de instrucciones que el usuario realiza para ejecutar una
función específica. Normalmente los programadores escriben en un lenguaje en el que todos
pueden entender y que después es traducido al lenguaje binario el único que las máquinas
entienden. El conjunto de órdenes en el lenguaje que todos trabajan se llaman código fuente.
Si no se accede al código solo se puede usar el programa, no se puede ver cómo está hecho
o introducir comentarios. Un ejemplo muy utilizado es el de la receta de cocina, en el que el
código fuente son las instrucciones que permite confeccionar un plato. Sin la receta solo se
pude degustar el plato, pero no se sabe si se le añade algo vaya en contra de algunos de esos
ingredientes ya que se desconocen su composición y proporción. En este sentido, el código
fuente juega un papel fundamental en la manera como se debe entender el software.
Se podrían poner varios ejemplos para entender dicha importancia. A finales de los 90 se
pudo ver en todo el mundo la preocupación por parte de empresa y gobiernos por las
consecuencias que podían tener el llamado efecto 2000. El famoso error informático era
debido al hecho de que muchos programas almacenaban la parte de la fecha correspondiente
al año utilizando únicamente dos dígitos, de tal manera, que después del año 99 (el 1999)
podíamos pasar al año 00 (¿año 2000 o año 1900?)
Causando todo tipo de errores en el cálculo de período de tiempo.
Es por eso, el software tiene un papel muy importante en la sociedad sobre manera garantizar
métodos trasparentes en sus diferentes fases de producción y explotación.
HERRAMIENTAS
Suministran un soporte automático o semiautomático para los métodos. Cuando se integran
las herramientas de forma que la información creada por una herramienta pueda ser usada
por otra, se establece un sistema para el soporte del desarrollo del software llamado ingeniería
de software asistido por computadora (Computer Aided Software Engineering o CASE).
Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos
proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el
año 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la
que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar
con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban
todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos
utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el
mercado de diversas herramientas más específicas para cada fase del ciclo de vida del
software. Por ejemplo, algunas herramientas CASE son MagicDraw (diseño), ArchE
(arquitectura) o MetaEdit (desarrollo).
Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se
pueden clasificar teniendo en cuenta los siguientes parámetros:
Conclusiones
Así que ahora ya sabes muy bien cómo funciona cada una de las metodologías básicas y de
los procesos o fases que conlleva cada una de ellas, así como las metodologías ágiles y las
ventajas de utilizarlas, por supuesto que hoy en día son las más usadas. Sin embargo algunas
metodologías existentes actualmente que no son tan famosas, están basadas en estas
principalmente, razón por la cual no se les hace mucha mención. De cualquier forma, al final
del día, tanto tu, como tu equipo de desarrollo de sistema, deberán hacer el análisis inicial y
determinar bajo que esquema quieren empezar a desarrollar. Si formas parte de una agencia
de desarrollo de software, todo dependerá del tipo y tamaño de software que el cliente
requiera, si no es así, entonces solamente deberás elegir uno para establecer cierto orden en
tus procesos o tomar fases de varios procesos como el de cascada y prototipos y crear tu
propia metodología, pues esto es precisamente lo que muchos hacen.
Fuentes bibliográficas
https://comunidad.iebschool.com/rnemtz/2013/05/16/introduccion-al-desarrollo-del-
software/
file:///D:/Descargas/art%C3%ADculo_redalyc_475748670010.pdf
https://es.wikipedia.org/wiki/Historia_de_la_ingenier%C3%ADa_del_software
https://histinf.blogs.upv.es/2010/12/28/ingenieria-del-software/
https://es.wikiversity.org/wiki/Metodolog%C3%ADas_pesadas_de_desarrollo_software
http://www.laboratorioti.com/2014/02/17/historia-de-las-metodologias-agiles/
https://es.wikiversity.org/wiki/Metodolog%C3%ADas_pesadas_de_desarrollo_software
https://okhosting.com/blog/metodologias-del-desarrollo-de-
software/#En_que_consisten_las_Metodologias_de_Desarrollo_de_Software
https://www.monografias.com/trabajos39/desarrollo-del-software/desarrollo-del-
software2.shtml#metodol
https://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
https://es.slideshare.net/juanpabloov18/desarrollo-de-software-orienta-a-objetos
https://www.academia.edu/5130339/MODELO_CARACTERISTICAS_VENTAJAS_DESVENTAJAS_
CASCADA
http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm