Buenas Practicas de Software

APUNTES DE APOYO PARA PREPARAR EL 2DO EXAMEN BPS
I. Buenas prácticas y marcos de trabajo.

II. Mejores prácticas en la gestión de los requerimientos de software.
III. Mejores prácticas para la ingeniería de diseño.
IV. Mejores prácticas para los modelos de prueba de software.
II. Mejores prácticas en la gestión de los requerimientos de software.

2.1- Criterios para la identificación de requerimientos
2.1.1 Contacto con el usuario o cliente
2.1.2 Herramientas para la obtención de requisitos de línea base
2.1.3 Proceso de revisión de requisitos
2.1.4 Documentación efectiva de requisitos
2.1.5 Análisis de capacidades para el desarrollo
2.1.6 Planeación del proyecto
2.1.7 Seguimiento de requisitos
2.1.8 Proceso de gestión de cambios
2.1.9 Proceso de gestión de versiones
2.1.10 Marcos de referencia y estándares
2.2 Estudio de casos de éxito
Introducción.
La primera etapa del proceso de desarrollo de Software es la Ingeniería de

Requerimientos. En esta fase se definen y especifican los requerimientos de los
clientes y usuarios.
Las actividades involucradas en la Ingeniería de Requerimientos son:

la obtención, el análisis, la especificación, la validación y la administración de los
requerimientos de software.
Los requerimientos de software se definen como las necesidades de los clientes,

los servicios que el usuario desea que proporcione el sistema y las restricciones
sobre las que el software debe operar.
El resultado del proceso de requerimientos es la base para el diseño, la

implementación y la evaluación del software.
A pesar de los avances recientes en la Ingeniería de Software, en la actualidad

existe una gran cantidad de desarrolladores que no hacen uso de los
procedimientos y actividades que proporciona la Ingeniería de Software en el
desarrollo de sistemas.
Esto afecta particularmente a la Ingeniería de Requerimientos ya que si no se

descubren y especifican todos los requerimientos del sistema en desarrollo, podría
conducir a la entrega de un producto de software incompleto (sin satisfacer
completamente las necesidades de los clientes), con defectos y poco funcional.
Esto podría provocar también el abandono de los proyectos de software en pleno

proceso de desarrollo o que estos sean entregados con retrasos y a costos mayores
a los estimados.
La Ingeniería de Requerimientos es una etapa de la Ingeniería de Software en

donde muchos proyectos no siguen un proceso bien definido. A pesar de que existe
mucha literatura de procesos, métodos y herramientas para esta etapa, en la
mayoría de los proyectos actuales, se le da poca importancia a la definición, análisis
y validación de los requerimientos y a su consecuente documentación.
Además, los proyectos resultantes no tienen una clara definición y distinción entre
los requerimientos y el diseño. Es decir, no distinguen claramente entre lo que se
quiere construir y la forma en como se debe construir el software.
En muchos de los casos, los problemas que se encuentran en el desarrollo de un
proyecto o producto de software provienen de la Ingeniería de Requerimientos.
Por esta razón, es importante definir de forma clara cual es el proceso y los métodos
que definen a esta fase de la Ingeniería de Software.
Concepto de requerimientos.
Un Requerimiento (o requisito) es una característica del sistema o una descripción

de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito
del sistema.
Al iniciar un proyecto, ¿cuál es la primera actividad? Tenemos que comunicarnos.
• Saber lo que el usuario quiere, cómo lo quiere, cuándo y porqué.
Al hablar de necesidades, en términos más técnicos, estamos hablando de

requerimientos.
La comunicación es la base para la obtención de los requerimientos, pero es

también la principal fuente de error:
Identifiquemos algunos de ellos….
• Falta de procedimientos y guías formales.

• Falta de participación del usuario.
• Mala interpretación de las necesidades.
• Falta de comunicación
La ingeniería de requerimientos es el proceso de transformación de los

requerimientos de los clientes, ya sean hablados o escritos, en especificaciones
precisas, no ambiguas consistentes y completas. También se encarga de establecer
y mantener los cambios de requerimientos entre clientes y el equipo.
Importancia de la IR permite:
• Mantener una estructura en las necesidades del proyecto.

• Disminuyes costos y retrasos.
• Mejorar la calidad del software.
• Mejorar la comunicación.
• Evitar rechazos de clientes o usuarios finales
2.1.2. Herramientas para la obtención de requisitos de línea base.
Existen herramientas que han sido desarrolladas específicamente para utilizarlas

en las técnicas de gestión de requisitos y dominar cualquier tarea asociada con los
requisitos.
El uso de este tipo de herramientas permite mejorar la calidad del desarrollo de un

proyecto, automatizar procesos de la Ingeniería de Requisitos, proporcionar un
mayor control en el mantenimiento de los requisitos y añadir un beneficio
significativo reduciendo posibles errores durante el desarrollo de un proyecto, lo que
implica en una reducción de costos.
Las herramientas de Gestión de Requisitos se caracterizan por tener las siguientes propiedades:
• Gestión de requisitos y atributos basados en los modelos de información

• Organización de requisitos
• Configuración y gestión de versión en los requisitos
• Definición de línea base de los requisitos
• Acceso y gestión multiusuario
• Gestión de la trazabilidad
• Consolidación de los requisitos obtenidos
• Gestión de cambios
• Análisis de impacto
Las diferentes herramientas de gestión de requisitos que están disponibles en el

mercado poseen una estructura similar. En general, las herramientas de gestión de
requisitos tienen una interfaz de usuario que puede ser utilizada para acceder a
todas las funciones necesarias para llevar a cabo las diversas tareas de la gestión
de requisitos, almacenando los datos gestionados en una base de datos,
permitiendo su visualización y edición por medio de un editor integrado.
A continuación, se muestra una breve lista de herramientas de gestión de requisitos

que pueden ser de ayuda para documentar, analizar, rastrear, priorizar y trazar los
requisitos.
Requirements Management Tool Company
IBM Rational DOORS IBM Rational

Visure Requirements Visure Solutions
Reqtify Dassault Systèmes
Jama Jama Software
Accept 360 Accept Software
Gatherspace Gatherspace
RequisitePro IBM Rational
MagicDraw No Magic
2.1.3 Proceso de revisión de requisitos.
Es un proceso manual que involucra a distintas personas. Ellos verifican el

documento de requerimientos en cuanto a anomalías y omisiones.
• Informales
o Los desarrolladores deben tratar los requerimientos con tantos
stakeholders como sea posible.
• Formal
o El equipo de desarrollo debe conducir al cliente, explicándole las
implicaciones de cada requerimiento
o Antes de una revisión formal, es conveniente realizar una revisión
informal.
Nota. Un stakeholder es el público de interés para una empresa que permite su

completo funcionamiento. Con público, me refiero a todas las personas u
organizaciones que se relacionan con las actividades y decisiones de una empresa
como: empleados, proveedores, clientes, gobierno, entre otros.
Stakeholder es una palabra del inglés que, en el ámbito empresarial, significa
‘interesado’ o ‘parte interesada’, y que se refiere a todas aquellas personas u
organizaciones afectadas por las actividades y las decisiones de una empresa
2.1.4 Documentación efectiva de requisitos.

El documento de requerimientos de software, es el lugar donde se da descripción a

las características y requisitos de un software, producto, programa o conjunto de
programas. Los requisitos se expresan en lenguaje natural, sin consideraciones ni
términos técnicos.
La especificación de requisitos de software es el resultado del levantamiento de

información con el usuario o cliente del producto. Son un método para una
comunicación más concisa y clara entre los encargados de desarrollar el software y
el área de negocio o clientes que usaran el producto.
El modelo para elaborar un documento de requerimientos de software debe

contener la descripción de la funcionalidad de la aplicación, relación con sistemas
externos y requerimientos no funcionales como de rendimiento, disponibilidad,
tiempos de respuesta, mantenibilidad entre otros.
2.1.5- Análisis de capacidades para el desarrollo.
La fase de análisis y planificación consta de dos partes bien diferenciadas.
La primera se realiza antes de empezar el desarrollo, es donde se intenta hacer la

primera traducción de la idea que se tiene a algo más estructurado. Esta fase a su
vez consta de pasos que van consiguiendo aportar más detalle a los requerimientos
y, de esta forma, conseguir unas estimaciones más aproximadas.
Una vez se comienza el desarrollo del producto, la fase de análisis y planificación

se convierten en algo que hay que realizar de forma constante. Al empezar a escribir
código pueden surgir nuevas dudas, problemas, etc., que requieren volver a ser
analizados y planificados. El cliente puede requerir hacer cambios sobre lo que está
viendo, y esto no debe suponer un problema. Nosotros estamos para eso, pero,
obviamente, esto puede afectar al plan inicialmente establecido y hay que ser
disciplinado, realizar los pasos y alertar de cualquier posible cambio en las fechas
de finalización.
El proceso de planificación tiene como entrada las características del programa a

desarrollar.
Como salida tiene dos cifras: estimación de costes y estimación de tiempo. En este
artículo no se incluye nada sobre presupuestos, cada cual puede realizar los
presupuestos como considere oportuno, pero para poder establecer un coste, sí es
necesario determinar el tiempo que va a llevar desarrollar una aplicación.
Y como puedes comprobar, ambas cifras se consideran estimaciones. Nadie puede

exigir unas cifras 100% exactas y, su variabilidad, dependerá en gran medida de
que no se introduzcan cambios por parte del cliente en los requerimientos
2.1.6 Planeación del proyecto.
La Planificación del proyecto es el conjunto de actividades con las cuales comienza

la gestión de proyectos software.
La planificación del desarrollo de software es comúnmente utilizado para

representar quizás de manera grafica o virtual la forma en la que se desempeñara
dicho software, siempre y cuando cada uno de los pasos y restricciones sean
reglamentariamente seguidas
La estimación se inicia con una descripción del ámbito del producto. El problema se
descompone en un conjunto de problemas de menor tamaño y cada uno de éstos
se estima guiándose con datos históricos y con la experiencia.
El objetivo primordial es hacer estimaciones razonables de recursos, costos y una
planificación temporal.
Las estimaciones involucran un periodo de tiempo y deben ser actualizadas a

medida que avanza el proyecto
2.1.7 Seguimiento de requisitos
En pocas palabras, las herramientas de seguimiento de requisitos son mecanismos

que eliminan las conjeturas de los proyectos, reemplazando las suposiciones y la
ambigüedad con hechos y certeza. Al utilizar estas herramientas durante el proceso
de desarrollo de un producto y convertirlo en parte del flujo de trabajo diario de una
operación, puede asegurarse de que dicho producto funcione exactamente como
se supone que debe hacerlo.
El procesador de textos y las hojas de cálculo son una herramienta de seguimiento

de requisitos muy básica, ya que se pueden utilizar para registrar y realizar un
seguimiento de los datos. Sin embargo, pueden volverse difíciles e imposibles de
escalar a medida que el proceso de seguimiento de los requisitos se realiza
manualmente y cuando comienza a trabajar con una gran cantidad de requisitos o
sistemas más complicados. Aquí es donde entran en juego herramientas más
especializadas y avanzadas
Sería fantástico si las partes interesadas del proyecto pudieran comprender

automáticamente todos los aspectos de un producto y todos los vínculos entre todos
los elementos del proyecto. En un mundo ideal, los analistas que se especializan en
negocios también tendrían una comprensión integral de la tecnología. Todos
preferiríamos que los clientes acudan a nosotros sabiendo exactamente lo que
quieren y tengan la capacidad de articularlo sin ambigüedades.
Desafortunadamente, marcar todas estas casillas no es un lujo que la mayoría de
la gente tenga la mayor parte del tiempo, razón por la cual los requisitos de
seguimiento son tan cruciales.
El seguimiento manual de los requisitos no solo puede ser tedioso, sino que,
lamentablemente, los humanos son falibles y propensos a cometer errores. Esto no
solo es cierto cuando se trata de registrar datos, sino que también es relevante en
la etapa de construcción. Los requisitos de seguimiento pueden mejorar la precisión
y la responsabilidad en ambos aspectos.
Los requisitos de seguimiento son multifacéticos y vienen con una serie de

beneficios en cada etapa de la creación y operación del producto. Debido a que le
permiten rastrear datos de manera más eficiente y con menos molestias, problemas
como;
• ¿Cómo sabemos cuántos requisitos se han implementado?

• ¿Cómo sabemos cuántas pruebas son suficientes?
• ¿Cuál es el impacto del cambio de requisitos?
• ¿Hemos reunido todos los requisitos?
• ¿Qué porcentaje del producto / software está representado por requisitos?
• ¿Qué tan lejos se está alejando el proyecto de los requisitos "reales" del
cliente?
• Como puedo generar requerimientos de trazabilidad?
• ¿Cómo demostrar la trazabilidad total de los requisitos para aprobar las
certificaciones estándar?
• ¿Cómo evitar que los requisitos de mala calidad perjudiquen el rendimiento
del equipo? Etc.
Los requisitos de seguimiento almacenan automáticamente todos los datos con los
que está trabajando, por lo que puede usarlos como referencia más adelante. Esto
puede ayudarlo a crecer y mejorar constantemente, lo que lo lleva a un escalado
más fluido y a un mejor producto.
2.1.8 Proceso de gestión de cambios.
La gestión del cambio en un proyecto de implementación de un software son todas

las acciones encaminadas a minimizar el impacto negativo de la adopción de un
nuevo sistema en la empresa.
El principal problema es que un cambio de software no es simplemente un cambio

de sistema informático. El software es el soporte vital de las operaciones y procesos
de la empresa moderna e integrado junto con otras aplicaciones han de ser reflejo
del modelo de negocio de la empresa. Es a su vez un repositorio de datos
interconectados sobre entidades y transacciones. En definitiva un software
constituye el sistema nervioso de una empresa a través del cual fluye la información
que necesita para realizar sus funciones.
Por si fuera poco cada vez que una empresa se plantea un proceso de cambio de
software, lo lógico es aprovechar para hacer un rediseño de los procesos de trabajo
en la empresa, eliminando los procesos innecesarios y optimizando todos aquellos
que ofrezcan un margen razonable para la mejora. Muchas veces estos cambios
vienen acompañados de reestructuraciones a nivel de personal. Esto implica que
el trabajo de muchas personas se verá afectado.
En definitiva cuando en una empresa se rumorea que va a haber un cambio de

software, el personal se asusta, ya que entiende que van a ocurrir importantes
cambios que pueden amenazar su status quo
La planificación, la mejor herramienta para gestionar el cambio.
El enfoque metodológico más adecuado es aprovechar el conocimiento disponible

sobre cambios y conflictividad para trazar una serie de acciones que adaptadas a la
casuística particular de cada proyecto permitan controlar la aparición de resistencias
y conflictos. El objetivo es incorporar al proyecto al mayor número de profesionales
posibles y ayudarles a que este sirva para favorecer su desarrollo profesional.
No podemos olvidar que el mejor software con la mejor adaptación posible a las
necesidades de una empresa se convertirá en un absoluto fracaso si no logramos
involucrar al equipo de profesionales de la empresa en su uso, adopción y
expansión
2.1.9 Proceso de gestión de versiones.
La gestión de versiones se refiere al proceso de planificar, diseñar, programar,

probar, implementar y controlar las versiones de software. Asegura que los
equipos encargados de la versión entreguen de manera eficiente las
aplicaciones y actualizaciones requeridas por la empresa, manteniendo al
mismo tiempo la integridad del entorno de producción existente.
En el competitivo, dinámico y fluido mundo de la empresa y la informática, la

entrega de versiones a medias sería lo último que desearía. La empresa
moderna es un entorno verdaderamente dinámico; y no todos estos cambios se
producen al mismo ritmo. Las organizaciones de TI necesitan una forma de
organizar estos innumerables cambios.
La gestión de versiones y la implementación es uno de los principales procesos
de la sección de transición de servicios del marco de la Biblioteca de
Infraestructura de Tecnologías de Información (ITIL). El ITIL es el marco más
adoptado para la gobernanza de los productos y servicios tecnológicos. Ayuda
a las organizaciones a ofrecer sus productos y servicios de una forma orientada
a la calidad, centrada en el cliente y consciente de los costos
Para que una versión sea considerada un éxito, es necesario que cumpla con
los siguientes objetivos:
• Implementado a tiempo.
• Implementado dentro del presupuesto.
• Su impacto en los usuarios actuales es escaso o nulo.
• Satisface las necesidades de los usuarios actuales y nuevos, los avances
tecnológicos y/o las exigencias de la competencia
2.1.10 Marcos de referencia y estándares.
El marco de referencia o marco referencial es un texto que identifica y expone los

antecedentes, las teorías, las regulaciones y/o los lineamientos de un proyecto de
investigación, de un programa de acción o de un proceso.
Los estándares o metodologías definen criterios de desarrollo que tienen como

objetivo principal producir software confiable de alta calidad
Los estándares de calidad de software hacen parte de la ingeniería de software,

utilización de estándares y metodologías para el diseño, programación, prueba y
análisis del software desarrollado, con el objetivo de ofrecer una mayor con abilidad,
mantenibilidad en concordancia con los requisitos exigidos.
2.1.1.- Contacto con el usuario o cliente
Si los requerimientos se enfocan a describir las necesidades del cliente, entonces

es lógico que para recabarlos haya que obtener la información de primera mano.
Esto es, mediante entrevistas con el cliente u obteniendo la documentación que

describa la manera que el cliente desea como funcione el sistema de software.
Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada

cambio involucra un costo. Por eso es necesario tener archivada una copia de la
documentación original del cliente, así como cada revisión o cambio que se haga a
esta documentación.
Diagrama de procesos básicos para obtener los requerimientos:
Obtener y Analizar información de las necesidades del cliente
Para hacer una correcta identificación de los clientes y poder realizar un análisis de
manera asertiva se pueden implementar una serie de técnicas de acuerdo al cliente
con el que se esté tratando.
Definición del alcance
La definición del alcance tiene como propósito describir y delimitar claramente las
necesidades del cliente, las cuales pretenden ser cumplidas con el proyecto.
Es importante para la definición del alcance la identificación de los siguientes

aspectos:
o Los entregables que hacen parte del alcance. Se recomienda describir y listar
los entregables finales, principalmente los que deben ser aprobados por el
cliente.
o Los tipos de datos que están en el alcance y fuera de él. Los “tipos de datos”
se refieren a la categoría del negocio de los entregables tales como datos
financieros, datos de ventas, datos de los empleados, etc.
o Las fuentes de datos (bases de datos) que están en el alcance y fuera de él.
Esto es similar a los tipos de datos, excepto que ahora se está refiriendo a
los datos agregados tales como base de datos de clientes, Contabilidad
general, sistema de facturación y cobranza, etc.
o Áreas involucradas en el alcance y fuera de él. En algunos casos, las áreas
involucradas en el proyecto ayudan a delimitar el alcance.
o Condiciones fuera del alcance. Se recomienda como punto de claridad y
contraste al describir entregables que no serán creados, qué organizaciones
no serán impactadas, qué facilidades y funciones no serán incluidas, entre
otros aspectos.
Fuentes de información claves
Cualquier información creada anteriormente debe ser usada como base para definir
el alcance de manera mas detallada. Si por alguna razón no se cuenta con suficiente
información para la definición del alcance, se debe buscar apoyo con el patrocinador
para reunir información adicional.
Si se tienen objetivos del proyecto, se recomienda tenerlos en cuenta para ayudar

a afinar el alcance. Por definición, se deben crear uno o más entregables para
cumplir cada objetivo, y definir los entregables del proyecto es uno de los aspectos
principales del alcance del proyecto.
Para tener una buena definición de requerimientos es necesario realizar una buena
identificación de los mismos, posterior a esto es importante definirlos de manera
detallada, donde se involucre la información aportada por los usuarios
Para realizar una correcta definición de los requerimientos del proyecto y que éstos
satisfagan las necesidades verdaderas del cliente, se deben tener en cuenta las
siguientes actividades:
Definición de Requerimientos
Para realizar con éxito la definición de los requerimientos es importante conseguir

que los requerimientos sean claramente definidos para minimizar la ambigüedad de
los requerimientos, para esto es importante tener en cuenta lo siguiente:
o Definir los requerimientos teniendo en cuenta la información identificada

con la perspectiva del usuario.
o Reutilizar requerimientos, revisando proyectos ya finalizados para ver si
contienen material potencialmente reutilizable. La ventaja de esta
reusabilidad es que, una vez que un requisito ha sido especificado
satisfactoriamente para un producto y que el producto ha tenido éxito, el
requerimiento no tendrá que volverse a inventar, podrá ser utilizado las
veces que se desee teniendo en cuenta los derechos de autor.
o Se debe documentar los requerimientos de una forma clara y correcta. En

la mayoría de los proyectos se observa que la documentación de los
requerimientos puede parecer una tarea tediosa, pero es la única manera
de asegurar que la esencia de los requisitos ha sido capturada
correctamente, y que esto pueda ser probado.
Como se vió en el tema uno y con el enfoque de éste capítulo, analizaremos la

Clasificación de requerimientos:
• Requerimientos Funcionales:
o Estos requerimientos se utilizan para determinar que hará el Software,
definiendo las relaciones de su operación y su implementación, sin
olvidar que deben ser explícitos también en lo que el sistema no debe
hacer y que validaciones se deben realizar, teniendo en cuenta cual
será el comportamiento del sistema.
o Los Requerimientos funcionales se pueden dividir en dos puntos de
vista: El primero tiene relación con el usuario, donde se identifica la
relación del usuario con el sistema desde el punto de vista del mismo;
El segundo tiene relación con el sistema dando respuesta al usuario,
es decir desde el punto de vista de lo que realiza el sistema.
o Para un desarrollador de sistemas es natural dar interpretaciones de
un requerimiento ambiguo con el fin de simplificar su implementación.
Sin embargo, a menudo no es lo que el cliente desea. Se tienen que
estipular nuevos requerimientos y se deben hacer cambios al sistema,
retrasando la entrega de éste e incrementando el costo. En principio,
la especificación de requerimientos funcionales de un sistema debe
estar completa y ser consistente con lo solicitado por el usuario.
• Requerimientos no funcionales.
o Estos requerimientos se basan en las restricciones de los servicios o
funciones ofrecidos por el sistema. Incluyen restricciones de tiempo,
sobre el proceso de desarrollo, estándares, usabilidad, portabilidad,
entre otros.
o Los Requerimientos funcionales son los requerimientos que no se
refieren directamente a las funciones específicas que entrega el
sistema, sino a las propiedades emergentes de éste como la fiabilidad,
la respuesta en el tiempo y la capacidad de almacenamiento.
o Los requerimientos no funcionales surgen de la necesidad del usuario,
debido a las restricciones en el presupuesto, a las herramientas
utilizadas, a las políticas de la organización, a la necesidad de
interoperabilidad con otros sistemas de software o hardware o a
factores externos como los reglamentos de seguridad, las políticas de
privacidad, etcétera.
o Los dos tipos de requerimientos especificados son de gran
importancia para el desarrollo de una aplicación en software, por lo
tanto siempre deben ser escritos con claridad, contener la mayor
especificación de las necesidades expuestas por el cliente, esto con
el fin de tener un soporte base desde el cual se trabajaran y no
presentar ambigüedades en la definición y el resultado del producto.
La figura a continuación muestra los inconvenientes que se pueden
presentar cunado no se hace una identificación correcta de los
requerimientos.
Las organizaciones actuales utilizan múltiples herramientas para el apoyo de la

identificación de los requerimientos, sin pensar si son las más convenientes para el
proyecto que se esté desarrollando, por lo tanto a continuación se encontraran las
técnicas que apoyen una correcta identificación de los requerimientos para los
proyectos de desarrollo de software.
Técnicas utilizadas para la identificación de requerimientos:
• Técnicas generales para la identificación de requerimientos.

• Técnicas específicas para la identificación de requerimientos.
• Técnicas para identificar requisitos funcionales y no funcionales.
• Técnicas de investigación de los atributos de las necesidades de los clientes
• Técnicas generales para la identificación de requerimientos.
Las técnicas agrupadas como generales son las que permiten investigar aspectos
generales para posteriormente ser especificados con un mayor detalle con el apoyo
de técnicas más específicas. Estas técnicas son más abiertas y requieren ser
adecuadamente orientadas para cubrir la información que se requiere capturar, es
importante que para sacar el mayor provecho de estas técnicas se debe tener un
dialogo lo más abierto posible entre las organizaciones de desarrollo de software y
las empresas cliente
Entrevista
Estas técnicas son muy utilizadas para la recolección de opiniones, criterios o

descripciones sobre diferentes actividades. Se lleva a cabo mediante
conversaciones estructuradas donde es fundamental que la relación con el cliente
este basada en la confianza para dar a conocer la información de la manera mas
detallada.
Antes de iniciar una entrevista es importante tener en cuenta los siguientes Tips a
tener en cuenta, no es obligación realizarlas todas pero si es recomendable estudiar
cuales son las que más se aplica para cada organización o cada proyecto.
1.- Estudiar el tipo de personas a las cuales se les realizará la entrevista.
2.- Estudiar como será el entorno donde se llevara a cabo la entrevista para
identificar que tan confortables estarán las personas y así obtener la información
de la manera más eficiente.
3.- Estudiar como es la manera de hablar de las personas individualmente o en

un equipo de trabajo.
4.- Verificar que las personas tengan la disponibilidad para dar a conocer las
necesidades que posterior a esto se puedan convertir en requerimientos.
5.- Revisar como es la relación del cliente con la organización que realizará la
identificación de los requerimientos, esto con el fin de facilitar el trabajo y la
disposición de ambas partes.
6.- Entender que es importante obtener la mayor información para la definición

de los requerimientos, teniendo en cuenta que nada es obvio para las
organizaciones de desarrollo de software.
Lluvia de ideas
Esta técnica es abierta y se utiliza para explorar necesidades iniciales con la ayuda
de la identificación de ideas de todas las personas que hacen parte del equipo de
apoyo para la identificación de los requerimientos. Es utilizada para investigar
nuevos servicios o necesidades que no son claramente identificadas.
Algunos Tips para tener en cuenta cuando se realice una lluvia de ideas:
1.- Escoger un sitio tranquilo que permita que las personas involucradas se
sientan cómodas y dispuestas para dar a conocer sus ideas.
2.- Tomar la iniciativa para iniciar una reunión enfocada en la confianza.
3.- Tomar nota de las ideas que las personas expresan en los equipos de trabajo.
Tener una preparación sobre el tema que se va a desarrollar en la lluvia de ideas.
Cuestionarios
Esta técnica puede ir dirigida a un público específico o general, lo que permite

obtener una información mayor, ya que se tiene la posibilidad de involucrar más
personas para el desarrollo de los cuestionarios y que estos tengan diferentes
puntos de vista. Lo importante es tener en cuenta que se debe tener un mayor
cuidado en la selección de los encuestados y de la forma en que se pregunta para
obtener respuestas concretas y confiables.
• Técnicas específicas para la identificación de requerimientos.

Las técnicas agrupadas como especificas son las que permiten complementar las
técnicas generales, para así obtener mayor detalle y eliminar ambigüedad en la
información inicial
Observación
Esta técnica permite obtener información directa sobre la forma en que se realizan
las actividades. Es una técnica que sirve para revisar que no existen omisiones o
interpretaciones erróneas sobre el proceso que se realiza. Hay que tener en cuenta
que se debe utilizar si el cliente lo permite y si el proyecto así lo amerita.
Escenarios
Esta técnica permite conocer el comportamiento del producto ante determinados

eventos considerando los datos, acciones y excepciones que se pueden presentar.
El análisis de casos de uso es un ejemplo de aplicación de esta técnica.
• Técnicas para identificar requisitos funcionales y no funcionales.
Ya que los requerimientos de sistemas de software se clasifican en funcionales y no

funcionales, se deben tener en cuenta las siguientes técnicas para la identificación
correcta.
Identificación de Requerimientos funcionales
Los requerimientos funcionales son declaraciones de los servicios que proveerá el

sistema, de la manera en que éste reaccionará a entradas particulares. En algunos
casos, los requerimientos funcionales de los sistemas también declaran
explícitamente lo que el sistema no debe hacer.
Muchos de los problemas de la ingeniería de software provienen de la imprecisión

en la especificación de requerimientos. Para un desarrollador de sistemas es natural
dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su
implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen
que estipular nuevos requerimientos y se deben hacer cambios al sistema,
retrasando la entrega de éste e incrementando el costo.
En principio, la especificación de requerimientos funcionales de un sistema debe

estar completa y ser consistente. La compleción significa que todos los servicios
solicitados por el usuario están definidos. La consistencia significa que los
requerimientos no tienen definiciones contradictorias.
En la práctica, para sistemas grandes y complejos, es imposible cumplir los

requerimientos de consistencia y compleción. La razón de esto se debe
parcialmente a la complejidad inherente del sistema y parcialmente a que los
diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias
son obvias cuando los requerimientos se especifican por primera vez. Los
problemas emergen después de un análisis profundo. Una vez que éstos se hayan
descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida,
se deben corregir en el documento de requerimientos.
Identificación de Requerimientos no funcionales
Son aquellos requerimientos que no se refieren directamente a las funciones

específicas que entrega el sistema, sino a las propiedades emergentes de éste
como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De
forma alternativa, definen las restricciones del sistema como la capacidad de los
dispositivos de entrada/salida y la representación de datos que se utiliza en la
interface del sistema.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las

restricciones en el presupuesto, a las políticas de la organización, a la necesidad de
interoperabilidad con otros sistemas de software o hardware o a factores externos
como los reglamentos de seguridad, las políticas de privacidad, entre otros.
Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus

implicaciones.
• Requerimientos del producto. Especifican el comportamiento del producto; como

los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta
memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema
sea aceptable; los de portabilidad y los de usabilidad.
• Requerimientos organizacionales. Se derivan de las políticas y procedimientos
existentes en la organización del cliente y en la del desarrollador: estándares en los
procesos que deben utilizarse; requerimientos de implementación como los
lenguajes de programación o el método de diseño a utilizar, y los requerimientos de
entrega que especifican cuándo se entregará el producto y su documentación.
• Requerimientos externos. Se derivan de los factores externos al sistema y de su

proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen
la manera en que el sistema interactúa con los otros sistemas de la organización;
los requerimientos legales que deben seguirse para asegurar que el sistema opere
dentro de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema
para asegurar que será aceptado por el usuario.
En la práctica, la especificación cuantitativa de requerimientos es difícil. A los

clientes no les es posible traducir sus metas en requerimientos cuantitativos; para
algunas de éstas, como las de mantenimiento, no existen métricas que se puedan
utilizar; el costo de verificar de forma objetiva los requerimientos no funcionales
cuantitativos es muy alto.
En principio, los requerimientos funcionales y no funcionales se diferencian en el

documento de requerimientos. En la práctica, esto es difícil. Si un requerimiento no
funcional se declara de forma separada a los funcionales, algunas veces es difícil
ver la relación entre ellos. Si se declaran con los requerimientos funcionales, es
difícil separar las condiciones funcionales y no funcionales e identificar los
requerimientos que se refieren al sistema como un todo. Se debe hallar un balance
apropiado que dependa del tipo de sistema a especificar. Sin embargo, los
requerimientos que claramente se refieren a las propiedades emergentes del
sistema se deben resaltar. Esto se hace colocándolos en una sección aparte o
diferenciándolos, de alguna forma, de los otros requerimientos del sistema.
Aspectos a tener en cuenta en la identificación de requerimientos funcionales y no

funcionales
Requerimientos básicos: se estructura su identificación al buscar respuestas a

preguntas como:
• ¿Cuál es el proceso básico de la empresa?

• ¿Qué datos utiliza o produce este proceso?
• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
• ¿Qué controles de desempeño utiliza?
Siempre se debe comenzar con lo básico. Cuando se hacen preguntas y se reciben

respuestas, se proporcionan antecedentes sobre detalles fundamentales
relacionados con el sistema y que sirven para describirlo.
Las siguientes preguntas son de utilidad para adquirir la comprensión necesaria:
• ¿Cuál es la finalidad de la actividad dentro de la empresa?

• ¿Qué pasos se siguen para realizarla?
• ¿Dónde se realizan estos pasos?
• ¿Quiénes los realizan?
• ¿Cuánto tiempo tardan en efectuarlos?
• ¿Con cuánta frecuencia lo hacen?
• ¿Quiénes emplean la información resultante?
Identificación de elementos
Durante esta, se debe identificar muy claramente los siguientes elementos:

• Procesos
• Flujos de datos entre procesos
• Datos de cada flujo de datos
• Bases de datos
• Datos de las bases de datos
Preguntas generales:
• ¿Cuántos empleados laboran para la organización en el área(s) que se pretende

desarrollar el sistema; o sea, cuántos tienen relación directa con el proyecto
• ¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?
• ¿Existen obstáculos o influencias de tipo político que afectan la eficiencia del
sistema?
• ¿Existen manuales de procedimientos, políticas o lineamientos de desempeño
documentados oficial o no oficialmente?. Si los hay, ¿Se cumplen en forma cabal
en el 100% de las ocasiones?, es decir, ¿se respetan dichos procedimientos?
• ¿Existen métodos para evadir el sistema?, ¿Por qué se presentan?
• ¿Qué áreas necesitan un control específico?
• ¿Qué criterios se emplean para medir y evaluar el desempeño?
• Técnicas de investigación de los atributos de las necesidades de los clientes
En realidad, quien conoce sus necesidades es el cliente y, consecuentemente, lo

que se hace es preguntarle a él sobre cada una de ellas, con el objeto de clasificar
y ponderar su importancia.
Este proceso de investigación debe ser suficientemente inteligente para conseguir
respuestas que permitan elevar realmente el nivel de competitividad de la solución
buscada.
En definitiva, se recomienda escuchar y entender lo que los estudiosos de la calidad

llaman la voz del cliente.
Bajo una perspectiva de innovación proactiva, para la identificación de necesidades,

se requieren métodos en los cuales el cliente pueda compartir su esfera de
conocimientos de aplicación con mayor riqueza y detalle que en los simples
informes de reclamación. Entre estos métodos están:
Grupos focales
Los grupos focales se conforman reuniendo a un grupo seleccionado de clientes,

conjuntamente con un moderador que va a conducir un debate de grupo sobre una
serie de aspectos y cuestiones concretas en las que se focaliza la discusión. Esta
técnica de investigación alcanza mayor profundidad que la encuesta y que los
informes anteriores.
En la reunión se establece, de por sí, una relación de afinidad por la que todas las
respuestas giran en torno a la situación a analizar. El contexto de uso y aplicación
del producto y las características que se estudian van quedando claros para todos,
más si desde el principio el moderador tiene la habilidad de exponer el propósito de
la reunión con nitidez.
Se elimina, pues, uno de los problemas de la encuesta. Al mismo tiempo, se

consigue más información y de mayor calidad que en los informes. Primero, porque
se cuenta con expertos elegidos e identificados, que pueden matizar y contrastar
las respuestas entre ellos, aportando puntos de vista específicos de sus ámbitos de
aplicación y segundo, porque en todo momento se pueden aclarar dudas y
profundizar en el tema hasta lograr su total comprensión.
La habilidad para conducir el debate, sugerir y plantear los temas, atemperar las
discusiones sobre aspectos banales y centrarla en los relevantes, es una cuestión
que va a determinar la cantidad y calidad de la información a obtener.
Entrevista individual
Una técnica de investigación más eficaz que la anterior es la entrevista individual

entre un experto del cliente y un entrevistador cualificado del equipo de análisis.
Esta tiene alguna ventaja adicional sobre el grupo focal, como el que se pueden
matizar, en un ambiente de mayor privacidad, los aspectos con mayores atributos
de impacto.
Si el moderador, en el caso de los grupos focales, era importante, el entrevistador

juega aquí un papel crítico. No sólo tiene que dominar las técnicas de la entrevista,
como el saber preguntar, el crear un clima de cooperación, sino que, además debe
reunir la experiencia y dominio suficiente sobre el tema a discutir para generar en el
cliente una motivación positiva, en el sentido de que se está tratando de descubrir
los conocimientos de uso del producto que pueden realmente incidir en
innovaciones que mejoren el rendimiento de su actividad y su satisfacción.
Análisis contextual
En la medida en que el conocimiento del cliente cobra importancia para el diseño

del nuevo requerimiento, la comprensión de los detalles y particularidades de uso
comienza a ser vital para la innovación proactiva.
Con esta técnica, lo que se hace es, no sólo pedir al cliente que cuente su
experiencia de uso y responda a las sagaces y hábiles preguntas de los métodos
anteriores, sino que se le solicita, además, ver cómo utiliza el producto para
comprender el por qué de su necesidad y discutir sobre el terreno cada uno de los
detalles y particularidades de uso. En esta técnica de análisis, la colaboración del
cliente pasa de contar y relatar su experiencia y opinión, desde luego en sus
expresiones y en sus propios términos, a dejar ver al fabricante cómo realmente se
construye esa opinión y se acumula esa experiencia.
Clientes piloto
Un método de investigación más sofisticado es utilizar clientes piloto. Clientes de

alto prestigio y conocimiento que pueden ofrecer un formidable campo de pruebas
para el nuevo producto. Claro está que no es fácil encontrar este tipo de clientes
piloto, pero también es claro que los beneficios de esta técnica son elevados. Si el
cliente es un colaborador más a la hora de descubrir atributos de impacto y de
mejorar los de rendimiento, se está contando realmente con una ayuda
especializada, con una opinión experta, que aconseja y valida diseños, que
contrasta y mide rendimientos y que, de alguna manera, se involucra en el
desarrollo.
Arthur D. Little llama a este tipo de clientes «lead adopters» y señala algunas
condiciones que deben cumplir con ese papel de cliente piloto. En primer lugar, se
espera que sean empresas exigentes en aquellos aspectos del producto que se
quiere verificar. Se está solicitando que sean más exigentes que la media de los
demás clientes, para estar seguros de que el proceso trata con rigor y profundidad,
incluso con severidad, las características a estudiar.
En segundo lugar, se les pide liderazgo en el producto, es decir, se trata de clientes

de reconocido prestigio por su conocimiento y experiencia en su campo de actividad.
Se induce, pues, que su potencial para aplicar el nuevo producto y sugerir cambios,
corregir defectos o completar características, es elevado.
Con la aplicación de esta técnica se busca dar el primer paso hacia la tendencia
actual de integración de la empresa en amplias redes de cooperación. En la red,
clientes y proveedores colaboran, no sólo en la generación de valor, sino también
en su gestión, contribuyendo a crear estructuras operativas eficaces, consistentes
y dinámicas con las que afrontar la creciente diversidad y dificultad de los mercados.
Mejores prácticas para el diseño y desarrollo de software
El poder identificar y transferir las mejores prácticas al interior de una organización

es crítico para poder obtener una ventaja competitiva y es por ello que se ha
convertido en una de las técnicas de administración más prominentes a partir de la
segunda mitad de los años noventa.
Una práctica es un método o técnica utilizada para llevar a cabo una parte de un
proceso y describe cómo se realiza. Las mejores prácticas son aquellas técnicas o
métodos que permiten incrementar la satisfacción del cliente al incorporar su uso en
nuestro proceso.
Los siguientes conceptos están enfocados en las mejores prácticas en el análisis,
diseño y las relacionadas a los requerimientos.
Participación activa de los clientes. Los clientes deben proveer información de

manera regular, tomar decisiones de manera constante e involucrarse activamente
en el proceso de desarrollo a través de herramientas y técnicas que faciliten su
inclusión.
Visualización de los requerimientos. Al principio de un proyecto ágil es necesario

invertir algún tiempo para identificar el alcance del proyecto y crear la pila inicial de
requerimientos organizados por prioridad.
Información de una única fuente. Se obtiene al capturar la información en un lugar

únicamente.
Visualización de la arquitectura. Al principio de un proyecto ágil es necesario un

modelado inicial de la arquitectura desde un nivel de abstracción alto para identificar
una estrategia que permita la implementación de la solución.
Documentar continuamente. Elaborar documentación entregable a través del ciclo

de vida del producto de forma paralela a la creación de la solución.
Ver más allá del modelado. Algunas veces los requerimientos que tienen una mayor
prioridad son complejos, lo cual motiva que se inviertan esfuerzos para explorarlos
antes de comenzar su desarrollo para reducir el riesgo general del desarrollo.
Múltiples modelos. Cada tipo de modelo tiene sus fortalezas y debilidades. Un

desarrollador efectivo necesitará contar con una variedad de modelos en su caja
mental de herramientas que le permitan aplicar el modelo adecuado en la forma
más apropiada para la situación actual.
Gestión de requerimientos Adoptar modelos inclusivos. Para facilitar la participación

activa de los clientes con el modelado y la documentación, es necesario reducir las
barreras idiomáticas evitando utilizar términos técnicos y utilizando herramientas
simples como notas adheribles.
Tomar una primera aproximación amplia. Es mejor intentar plasmar la idea general
en lugar de enfocarse en algún aspecto particular del sistema, esto permite obtener
un conocimiento general del sistema.
Tratar de definir la totalidad de los requerimientos al inicio del proyecto suele fallar
debido a dos razones principales:
§ Cuando los clientes reciben la indicación de plasmar todos sus

requerimientos en papel al inicio del proyecto intentan definir tantos
requerimientos potenciales como les es posible sin saber si realmente serán
necesarios.
§ Los clientes saben que si no lo hacen ahora será muy difícil agregarlos
después debido a la práctica común de evitar realizar cambios en etapas
avanzadas del proyecto.
Tratar los requerimientos como una pila priorizada. Se ubican los requerimientos en
una pila ordenados por prioridad de acuerdo a cuando deben implementarse,
decisión que debe tomarse en conjunto con el cliente. En caso de requerirse un
cambio a un requerimiento debe tratarse como un nuevo requerimiento y agregarse
a la pila.
Los requerimientos que se encuentran al principio de la pila deben estar bien

detallados y en los del final el detalle debe ser escaso.
Preferir requerimientos ejecutables sobre documentación estática. En la manera

posible, especificar los requerimientos en forma de “pruebas de usuario” que
puedan ejecutarse y diseñar como si fueran pruebas de desarrollo ejecutables, en
lugar de documentación “estática” no ejecutable.
Reconocer que existe una amplia variedad de clientes. Incluso entre los miembros
de una misma empresa es común que haya puntos en los que no exista un acuerdo
sobre lo que se espera del sistema. Por ello es necesario definir a la persona que
servirá de intermediario entre el cliente y el equipo de desarrollo, y que funcionará
como la fuente oficial de información y priorización.
Requerimientos independientes de la plataforma. Los requerimientos deben ser

independientes de la plataforma para que puedan conservar su simpleza y claridad.
Más pequeño es mejor. Los pequeños requerimientos, características e historias de

usuario son más fáciles de estimar y de desarrollar que aquellos que son grandes,
además de que son más fáciles de priorizar y por tanto de manejar.
Trazabilidad. Se refiere a la capacidad de conocer la relación de un requerimiento

hacia todos los artefactos que afecta: modelos de análisis, modelos arquitectónicos,
modelos de diseño, código fuente y casos de prueba. La trazabilidad debe verse
reflejada en una matriz, lo que permite analizar el impacto que tendría en el sistema
un cambio de requerimiento.
Explicar las técnicas. Todo el equipo debe tener un entendimiento básico de una
técnica de modelado, incluyendo los clientes. Por ejemplo, el tomar unos momentos
para explicar qué es una tarjeta CRC y por qué se utiliza, puede ayudar a facilitar el
proceso.
Adoptar la terminología de los clientes. No debemos insistir en que los clientes sean
capaces de entender terminología técnica del desarrollo. Para ellos se está
construyendo el sistema, por tanto, es su terminología la que debemos utilizar para
el modelado del sistema. Un artefacto útil para consolidar está práctica es elaborar
y mantener un glosario de términos de negocio.
Análisis y diseño
Los diseños ágiles se van construyendo, no se definen por completo al inicio. El
diseño general del sistema se construye conforme avanza el desarrollo del proyecto
cambiando y evolucionando constantemente.
Los modelos de diseño son apenas lo suficientemente buenos. No es necesario

modelar cada detalle en los modelos ya que no es necesario que se encuentren
completos, los detalles se refinan durante el proceso de codificación.
Cada modelo puede ser utilizado para diversos propósitos. Cada modelo puede ser
utilizado para diversos propósitos, por ejemplo un caso de uso puede usarse para
modelar la naturaleza esencial de un proceso o para modelar un proceso a detalle.
Los diseñadores también deben codificar. Cuando el modelo desarrollado por

alguien más se entrega a otra persona para codificarlo hay un riesgo significativo de
que no capte sus detalles adecuadamente. Separar las funciones del diseño y la
codificación es riesgosa, es mejor contar con especialistas en el equipo que puedan
diseñar y codificar.
Probar con código. Nunca debe asumirse que un diseño funciona, sino que debe
probarse codificándolo para determinar si funciona.
La retroalimentación es importante. Nunca debe olvidarse que es necesario buscar

activamente retroalimentación sobre el trabajo que se realiza. Esto permite mejorar
el sistema.
Utilizar herramientas de generación de código. En caso de que exista la posibilidad

de que a partir del diseño se genere automáticamente código, esa posibilidad debe
aprovecharse.
El diseño es importante y debe realizarse todos los días. Es de suma importancia

pensar en lo que se va a construir. A través del diseño es posible obtener una idea
general y plasmarla antes de lanzarse a la construcción.
Analizar detenidamente el ambiente de implementación. Esto es importante porque

permite determinar cuestiones como la portabilidad que tendrá el sistema, lo cual
limita la elección de tecnologías para el desarrollo del proyecto.
Documentar las partes complicadas del sistema. A través de la documentación
generada debemos poder entender el funcionamiento del sistema, así como las
razones que sustentan las decisiones de diseño
Para un proyecto de desarrollo de software, se debe tener en cuenta las

siguientes prácticas:
1.- Definición de requisitos. Alcance del proyecto.
Se debe conocer que se tiene que construir y para qué va a servir, sin embargo, la
mayor parte de los clientes no saben realmente que es lo que quieren y mucho
menos como implementarlo en un desarrollo.
Vale la pena sentarse con el cliente y los usuarios finales de la aplicación y definir
a donde se quiere llegar y como lo haremos.
Es muy importante redactar un documento de alcance y que todos los participantes

del proyecto (programadores, analistas, jefes de proyecto, cliente que solicita el
desarrollo y usuarios finales que harán uso de la aplicación) estén totalmente de
acuerdo.
El análisis de unos requisitos y la redacción de un documento de alcance nos evitará

más de un dolor de cabeza durante y en la finalización del proyecto.
2.- Dividir los desarrollos en fases o entregables.
Una vez redactado un alcance, es conveniente separar en proyecto en secciones o

fases que permitan al cliente ir viendo resultados durante el desarrollo.
Si un proyecto tiene una duración de 10 meses, no podemos tener al cliente sin ver
nada durante los 10 meses de desarrollo, hay que ir mostrando los resultados, cosa
que también nos servirá para ir realizando determinados ajustes y no llegar al final
del proyecto y el cliente nos haga cambiar más de la mitad de los desarrollos.
Dividir el proyecto en fases, sprint o secciones nos permitirá marcarnos objetivos en

periodos cortos e ir mostrando los resultados.
3.- Elección de un IDE que se adapte a tus necesidades.
Dependiendo del lenguaje de programación que vayamos a utilizar, será

conveniente el uso de un Entorno de Desarrollo integrado (IDE) u otro, ya que cada
IDE está enfocado a uno o varios lenguajes de programación.
Por ejemplo, si vamos a programar en java, sería conveniente hacer uso de los IDE
NetBeans o Eclipse, si vamos a hacerlo en Python podemos hacer uso de Atom o
Visual Studio Code, si vamos a hacer un desarrollo en php o html podemos hacer
uso de PhpStorm.
Si, por el contrario, queremos hacer uso de un IDE que pueda servirnos para varios
lenguajes de programación, podemos hacer uso de alguno que permita importar
librerías y funciones de algún lenguaje concreto como es sublimetext.
4.- Estandarizar las reglas del desarrollo.
Cuando vamos a comenzar con los desarrollos hay que definir nuestra forma de
trabajar: La forma de llamar y definir las funciones, las variables, el nombre de los
ficheros, atributos, etc. En un buen código se distinguen fácilmente estos elementos.
Un código que no sigue alguna normalización resulta más complicado de mantener.
5.- DRY: Dont repeat yourself.
No repitas código, modulariza tus desarrollos. Repetir partes de código a lo largo de

un desarrollo solo sirve para dificultar el mantenimiento y aumentar la probabilidad
de cometer errores.
Agrupa en funciones las operaciones que se repitan, y aíslala del resto del código,
el esfuerzo necesario para el mantenimiento del código disminuirá. Si estos trozos
de código son requeridos por otros ficheros, no solo elimínalos del flujo natural, si
no que colócalo en un fichero aparte y accesible por todos los elementos del código.
6.- No inventes.
Si ya se disponen de módulos y librerías ya testeadas y optimizadas, no pierdas el

tiempo en un desarrollo. Los IDE actuales disponen de librerías que te ayudarán en
tus desarrollos.
7.- Comenta tu código.
Para facilitar las modificaciones y mantenimiento, pero recuerda, un buen código es

aquel que no necesita comentarios. Redacta sentencias simples e intenta elaborar
una solución sencilla y corta. Cuanto más corta sea, menos errores se producirán y
más fácil será localizarlos y solventarlos.
8.- Divide y vencerás.
Divide los desarrollos complejos en varios más sencillos. Enrocarse en buscar una
solución que abarque todas las posibilidades o funcionalidades te va a hacer perder
mucho el tiempo. Divide el desarrollo en funcionalidades y prográmalas atendiendo
a su función principal y a la integración con el resto.
9.- Testeo de código.
Realizarás muchas pruebas durante el desarrollo del software y sobre todo al final
de este. Prepara una batería de pruebas que puedas ejecutar en cualquier
momento. Muchas veces el ajuste de algunos elementos provoca alguna
incongruencia con otros, con tu batería de pruebas debes poder detectar esto.
10.- Optimización.
No todas las instrucciones y módulos necesitan la misma capacidad de

procesamiento intenta utilizar siempre las más sencillas.
11.- Seguridad.
Durante el desarrollo de nuestro software tenemos que tener en cuenta los

siguientes puntos:
• El acceso a los ficheros (tanto de forma física, como permisos).

• La posibilidad de modificar el código en la misma ejecución o la inyección sql.
• Desbordamiento de buffer al hacer uso de un array sin tamaño controlado.
• Formateo de los datos de entrada (en formularios).
• Actualización del IDE y las funciones. Una función obsoleta puede originar
un agujero de seguridad en nuestro código.
• Uso de contraseñas en el código. Las contraseñas deben estar cifradas y en
la base de datos.
12.- Documentación.
Durante los desarrollos intenta documentar todo lo que haces para facilitar el
entendimiento del desarrollo y funcionamiento del software al personal del proyecto
y futuras personas que trabajen en é
Fin de tema………

Buenas Practicas de Software

Cargado por

Información del documento

Título original

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

Buenas Practicas de Software

Cargado por

Copyright:

Formatos disponibles

APUNTES DE APOYO PARA PREPARAR EL 2DO EXAMEN BPS

I. Buenas prácticas y marcos de trabajo.

II. Mejores prácticas en la gestión de los requerimientos de software.

La primera etapa del proceso de desarrollo de Software es la Ingeniería de

Las actividades involucradas en la Ingeniería de Requerimientos son:

Los requerimientos de software se definen como las necesidades de los clientes,

El resultado del proceso de requerimientos es la base para el diseño, la

A pesar de los avances recientes en la Ingeniería de Software, en la actualidad

Esto afecta particularmente a la Ingeniería de Requerimientos ya que si no se

Esto podría provocar también el abandono de los proyectos de software en pleno

La Ingeniería de Requerimientos es una etapa de la Ingeniería de Software en

Un Requerimiento (o requisito) es una característica del sistema o una descripción

Al iniciar un proyecto, ¿cuál es la primera actividad? Tenemos que comunicarnos.

• Saber lo que el usuario quiere, cómo lo quiere, cuándo y porqué.

Al hablar de necesidades, en términos más técnicos, estamos hablando de

La comunicación es la base para la obtención de los requerimientos, pero es

Identifiquemos algunos de ellos….

• Falta de procedimientos y guías formales.

La ingeniería de requerimientos es el proceso de transformación de los

• Mantener una estructura en las necesidades del proyecto.

Existen herramientas que han sido desarrolladas específicamente para utilizarlas

El uso de este tipo de herramientas permite mejorar la calidad del desarrollo de un

• Gestión de requisitos y atributos basados en los modelos de información

Las diferentes herramientas de gestión de requisitos que están disponibles en el

A continuación, se muestra una breve lista de herramientas de gestión de requisitos

Requirements Management Tool Company

IBM Rational DOORS IBM Rational

Reqtify Dassault Systèmes

Jama Jama Software

Accept 360 Accept Software

RequisitePro IBM Rational

2.1.3 Proceso de revisión de requisitos.

Es un proceso manual que involucra a distintas personas. Ellos verifican el

Nota. Un stakeholder es el público de interés para una empresa que permite su

2.1.4 Documentación efectiva de requisitos.

El documento de requerimientos de software, es el lugar donde se da descripción a

La especificación de requisitos de software es el resultado del levantamiento de

El modelo para elaborar un documento de requerimientos de software debe

2.1.5- Análisis de capacidades para el desarrollo.

La fase de análisis y planificación consta de dos partes bien diferenciadas.

La primera se realiza antes de empezar el desarrollo, es donde se intenta hacer la

Una vez se comienza el desarrollo del producto, la fase de análisis y planificación

El proceso de planificación tiene como entrada las características del programa a

Y como puedes comprobar, ambas cifras se consideran estimaciones. Nadie puede

2.1.6 Planeación del proyecto.

La Planificación del proyecto es el conjunto de actividades con las cuales comienza

La planificación del desarrollo de software es comúnmente utilizado para

Las estimaciones involucran un periodo de tiempo y deben ser actualizadas a

2.1.7 Seguimiento de requisitos

En pocas palabras, las herramientas de seguimiento de requisitos son mecanismos

El procesador de textos y las hojas de cálculo son una herramienta de seguimiento

Sería fantástico si las partes interesadas del proyecto pudieran comprender

Los requisitos de seguimiento son multifacéticos y vienen con una serie de

• ¿Cómo sabemos cuántos requisitos se han implementado?

2.1.8 Proceso de gestión de cambios.

La gestión del cambio en un proyecto de implementación de un software son todas

El principal problema es que un cambio de software no es simplemente un cambio

En definitiva cuando en una empresa se rumorea que va a haber un cambio de

La planificación, la mejor herramienta para gestionar el cambio.

El enfoque metodológico más adecuado es aprovechar el conocimiento disponible

2.1.9 Proceso de gestión de versiones.

La gestión de versiones se refiere al proceso de planificar, diseñar, programar,

En el competitivo, dinámico y fluido mundo de la empresa y la informática, la