Sei sulla pagina 1di 32

ANLISIS DEL PROYECTO DE

SOFTWARE


La ingeniera de software comienza
con una serie de tareas de modelado
que conducen a una especificacin de
requisitos y a una representacin
completa del diseo del software que
se construir.

Anlisis



Es la primera representacin tcnica de un sistema.

Cuando se detecten problemas y fallas en est fase es necesario agregarle los
siguientes objetivos:
Los productos del anlisis deben tener una elevada facilidad de
mantenimiento.
Los problemas de gran tamao deben tratarse con un modelo efectivo de
particin.
Deben utilizarse grficas cuando sea posible.
Diferenciar entre consideraciones lgicas (esenciales) y fsicas (de
implementacin).

Anlisis de requisitos: Genera las especificacin de caractersticas
operacionales de software; indica la interfaz del software con otro elementos
del sistema, y establece las restricciones que debe tener el software.

PUNTO CLAVE

El modelo de anlisis y la especificacin de
requisitos proporciona un medio para evaluar la
calidad una vez que el software est construido.













El diseo abarca un conjunto de principios, conceptos y prcticas
que conducen al desarrollo de un sistema o producto de alta
calidad.

En palabras de Mitch Kapor, el diseo Es el lugar donde una
persona se puede parar con un pie en dos mundos el mundo de
la tecnologa y el de la gente y los propsitos humanos e intentar
unirlos

El diseo crea una representacin o modelo del software, pero a
diferencia del anlisis , el modelo de diseo proporciona detalles
acerca de las estructuras de datos, las arquitecturas, las
interfaces y los componentes del software que son necesarios
para implementar el sistema



Por qu es importante el diseo?

Permite al ingeniero de software modelar el sistema o
producto que se va a construir. Este modelo puede
evaluarse en relacin con su calidad y mejorarse antes
de generar cdigo, de realizar pruebas y de que los
usuarios finales se vean involucrados a gran escala. El
diseo es el sitio en el que se establece la calidad del
software

Documentacin



La documentacin en un proyecto
es muy importante ya que
es la nica forma tangible
de representar al software
y su proceso.

Los documentos estandarizados
tienen una apariencia, estructura
y calidad consistentes y, por lo tanto,
son ms fciles de leer y de comprender.



Existen tres tipos de estndares de documentacin:

1. Estndares del proceso de documentacin. Definen
el proceso a seguir para la produccin del
documento.

2. Estndares del documento. Gobiernan la estructura y
presentacin de los documentos.

3. Estndares para el intercambio de documentos.
Aseguran que todas las copias electrnicas de los
documentos sean compatibles.



4.2 Construccin: codificacin, pruebas y
evaluacin, manual del usuario, manual tcnico

Construccin:
Es la creacin detallada
de software operativo.

Los principios fundamentales de la
construccin de software son:

Minimizar la complejidad
Anticipar los cambios
Pensar en la verificacin posterior
Aplicar estndares



Codificacin

La escritura del cdigo fuente es el principal esfuerzo de construccin de
software.

Aplicar tcnicas para crear cdigo fuente comprensible
Manejar condiciones de error
Prevenir brechas de seguridad a nivel de cdigo
Uso eficiente de recursos escasos
Organizar el cdigo fuente
Documentar el cdigo



Pruebas y evaluacin

La prueba del sistema debe centrarse en establecer que el sistema
satisface sus requerimientos funcionales y no funcionales, y no se
comporta de forma inesperada. Inevitablemente, los defectos en los
componentes que no se han detectado durante las primeras etapas de
las pruebas se descubren durante las pruebas del sistema.

El proceso de pruebas del software tiene dos objetivos distintos:

1. Para demostrar al desarrollador y al cliente que el software satisface
sus requerimientos.

2. Para descubrir defectos en el software en que el comportamiento de
ste es incorrecto, no deseable o no cumple su especificacin





La evaluacin de proyectos es "un instrumento o
herramienta que genera informacin, permitiendo
emitir un juicio sobre la conveniencia y
confiabilidad de la estimacin preliminar del
beneficio que genera el Proyecto en estudio".





Se trata de una gua que ayuda a entender el funcionamiento de
algo. Es un documento de comunicacin tcnica que busca
brindar asistencia a los sujetos que usan un sistema o servicio.

Pasos para elaborar el manual de usuario

1. Portada: De que se trata el documento y quin lo elaboro?
2. Introduccin: Describe el uso del documento, para qu sirve?
y de qu habla?
3. Anlisis y requerimientos del sistema (qu se ocupa para
poder instalarlo y usarlo?)
4. Explicacin del funcionamiento: Se debe poner paso a paso y
con pantallas bien explicadas cmo funciona el programa
5. Glosario



Debe ser escrito de tal manera, que cualquier persona pueda
entenderlo con la menor dificultad posible.

Es recomendable, detallar todos aquellos pasos que se llevan a
cabo para usar el programa.

Especificar los alcances y las limitaciones que tiene el programa.
Un buen punto de partida para un manual de usuario, es hacer de
cuenta que las personas que lo van a leer no tienen el ms
mnimo conocimiento sobre computadores.




Manual Tcnico


Este documento contiene toda la informacin sobre los
recursos utilizados por el proyecto, llevan una
descripcin muy bien detallada sobre las caractersticas
fsicas y tcnicas de cada elemento. Por ejemplo:
caractersticas de procesadores, velocidad, dimensiones
del equipo, garantas, soporte, proveedores y equipo
adicional.
Su extensin depende de la cantidad de recursos y
equipo utilizado y generalmente se presenta en forma
de fichas tcnicas en donde se describe en cada una las
caractersticas de cada recurso.



Elaboracin del manual tcnico


Un manual tcnico es aquel que va dirigido a un pblico con
conocimientos tcnicos sobre algn rea, mientras que, por
ejemplo, un manual de usuario va dirigido a un pblico ms
general, el cual no necesariamente debe tener conocimientos
especficos en el rea de inters.

En este caso el manual tcnico, debe incluir:

Paradigma de programacin seleccionado y sus beneficios.
Lenguaje de programacin seleccionado y sus beneficios
frente a otros lenguajes.
Estandarizacin de cdigo utilizada.
Diseo del sistema.

La medicin es un elemento clave en cualquier proceso
de ingeniera. Las medidas se emplean para
comprender mejor los atributos de los modelos que se
crean y evaluar la calidad de los productos de la
ingeniera o de los sistemas que se construyen.




Se debe medir el software para:

Indicar la calidad del producto.
Evaluar la productividad del agente que
desarrolla el producto.
Evaluar los beneficios en trminos de
productividad y calidad mediante el uso de
nuevos mtodos y herramientas de ingeniera de
software.
Establecer una lnea de base para la estimacin.
Ayudar a justificar el uso de nuevas herramientas
o de formacin adicional.



Una mtrica de software es cualquier tipo de medida relacionada
con un sistema, proceso o documentacin de software.

Ejemplo:

Las medidas que se utilizan para calcular el tamao de un
producto en lneas de cdigo, que mide la claridad de un prrafo
en un texto; el nmero de fallos encontrados en un producto
software entregado; y el nmero de personas/da requeridas para
desarrollar un componente del sistema.





AT&T, Hewlett-Packard (HP), y Nokia han introducido programas
de mtricas que recogen medidas en sus procesos de gestin de
calidad. El enfoque fue recoger medidas de los defectos en los
programas y en los procesos de verificacin y de validacin.







Indicador

Son datos esencialmente cuantitativos, que nos permiten
darnos cuanta de cmo se encuentran las cosas en relacin
con algn aspecto de la realidad que nos interesa conocer.
Los Indicadores pueden ser medidas, nmeros, hechos,
opiniones o percepciones que sealen condiciones o
situaciones especficas.







Mtricas de proceso

Las mtricas del proceso se recopilan en el curso de todos proyectos y
durante largos periodos. Su objetivo es proporcionar un conjunto de
indicadores de proceso que conduzcan a la mejora de los procesos de
software a largo plazo.






Mtricas de proyecto

Las mtricas del proyecto permiten que un gestor de proyecto de software:

1) Valore el estado de un proyecto en curso
2) Rastree los riesgos potenciales
3) Descubra las reas problema antes de que se vuelvan crticas
4) Ajuste el flujo de trabajo o las tareas
5) Evale la habilidad del equipo del proyecto para encontrar la calidad de
los productos de trabajo del software

La finalidad de estas mtricas es doble. Primero, se emplean para
minimizar el tiempo de desarrollo haciendo los ajustes necesarios para
evitar demoras y reducir los problemas y riesgos potenciales. Segundo,
se utilizan para valorar la calidad del producto sobre una base actual y,
cuando es necesario, modificar el enfoque tcnico para mejorar la calidad.



Mtricas orientadas a punto de funcin

La mtrica de punto de funcin (PF) , se usa de manera
efectiva como medio para medir la funcionalidad que entrega
un sistema.

El PF se emplea para:
1. Estimar el costo o el esfuerzo requerido para disear,
codificar y probar el software.
2. Predecir el nmero de errores que se encontraran durante
la prueba.
3. Pronosticar el nmero de componentes, de lneas de cdigo
proyectadas, o ambas, en el sistema implementado.





Mtricas orientadas al tamao

Estas mtricas preceden de la normalizacin de las
medidas de calidad o productividad considerando el
tamao del software que se ha producido.

Las mtricas orientadas al tamao son ampliamente
utilizadas, aunque no se aceptan como la mejor forma
de medir el proceso del software. La mayor parte de la
controversia gira en torno al uso de lneas de cdigo
(LDC) como medida clave.





Si una organizacin de software mantiene registros simples es
factible crear una tabla de medidas orientadas al tamao, como
se muestra en la siguiente figura:





Mtricas para la calidad del software




Un buen ingeniero de software (y los buenos gestores de
ingeniera de software) debe medir si se logra la alta calidad.

Aunque existen muchas medidas de la calidad del software, la
correccin, la facilidad de mantenimiento, la integridad y la
facilidad de uso ofrecen indicadores tiles para el equipo del
proyecto.



Correccin. Un programa debe operar correctamente o
proporcionar poco valor para los usuarios. La correccin es el
grado en el que el software desempea la funcin para la que fue
creado.

Facilidad de mantenimiento. Es la sencillez con la que un
programa puede corregirse si se encuentra un error, adaptarse si
su entorno cambia, o mejorar si el cliente desea un cambio en los
requisitos.

Integridad. Mide la habilidad de un sistema para resistir ataques
(tanto accidentales como intencionales) a su seguridad.

Facilidad de uso. Un programa que no es fcil de usar est
condenado al fracaso, incluso si las funciones que realiza son
valiosas .
4.5. Implementacin y mantenimiento:
entrega, retroalimentacin del cliente.

Implementacin: Es la actividad durante la cual los
desarrolladores traducen el diseo a cdigo.

Mantenimiento: Es el proceso de mejora y optimizacin del
software as como tambin correccin de los defectos.







Entrega



Proporciona el conjunto de actividades necesarias para
llevar a cabo las entregas software y de documentacin
asociada a un proyecto, desde la formalizacin de la
entrega hasta la revisin y validacin de la misma, con
la finalidad de homogeneizar todas las entregas
software y facilitar su revisin y tratamiento.





Retroalimentacin del cliente





La retroalimentacin del cliente es una parte crtica del sistema de gestin de la
calidad, y por lo tanto debe recibir una atencin adecuada durante una auditora
de tercera parte. La retroalimentacin del cliente es uno de los indicadores
primarios de desempeo que puede ser utilizado para juzgar la eficacia general
del SGC. Por lo tanto, es importante para el auditor verificar que:

1. Las entradas a este proceso incluya datos relevantes, representativos y
confiables.

2. Estos datos se analicen eficazmente.

3. La salida de este proceso proporcione informacin til para la revisin por la
direccin y otros procesos del SGC, para aumentar la satisfaccin del cliente y
llevar hacia la mejora continua.

Potrebbero piacerti anche