TEMA 1 - INTRODUCCI

El terme "Enginyeria del programari" naix a finals dels anys 60, tenint com a objectiu: millorar les
prctiques de programaci, que havien demostrat no ser fiables a llarg terme. Enlloc de generar
programari a mida per un producte, es comena a programar de manera genrica per a un mercat ms
ampli. A va facilitar que ms de un grup de persones fora capa de treballar i mantindre un projecte,
perqu s'usaven biblioteques comuns, i va redur la quantitat de temps dedicada a corregir errors.
L'enginyeria del programari surt dons com a disciplina per millorar la qualitat del maquinari i programari
en totes les etapes de la creaci i manteniment de un producte informtic. A ms, aquest producte deu
proporcionar una soluci real al problema, i que puga resoldre's en un temps i usant una quantitat de
recursos factible. Una definici acceptable de "Enginyeria del programari" seria aquesta:
L'establiment i s de principis d'enginyeria robustos, orientats a obtenir programari econmic que siga
fiable i funcione de manera eficient sobre mquines reals" - Bauer, 1969.
Com a conclusi, podem considerar que L'Inginyeria del Programari comprn:
Mtodes: Indiquen com s'ha de construir el programari, des de la planificaci fins el
desenvolupament del sistema.
Eines: Entorn on es desenvolupar el programari, facilita totes les fases de la creaci i
manteniment del programari.
Processos: Uneix els mtodes amb les eines. Defineix les directrius a seguir per portar a terme el
projecte.
L'objectiu dels enginyers s obtenir mtodes senzills per resoldre problemes complexos. Per aconseguirho, s'ha d'aplicar teories, mtodes i ferramentes tenint en compte el temps i els recursos.
Cal reconeixer aquestes caracterstiques del programari:
Es desenvolupa, mentre que el maquinari es fabrica.
Falla tan sols degut a errors durant la fase de desenvolupament.
No pot funcionar de manera allada, necessita formar part de un sistema.
Un sistema informtic s un conjunt d'elements relacionats entre si que funcionen per acomplir una
determinada tasca. Els sistemes que comprenen maquinari i programari son sistemes informtics.
Entre les qualitats ms destacables del programari, tenim quatre atributs:
Ha de ser mantenible. Cal documentar-lo i permetre poder aplicar canvis al codi amb facilitat.
Ha de ser fiable. Qualsevol problema introdut donar ms problemes a lo llarg del temps.
Ha de ser eficient. Cal usar una quantitat mnima de recursos del sistema.
Ha de proporcionar una interfcie adequada.
Finalment, el programari es classifica de la segent manera:
Programari de sistemes. Desenvolupat per gestionar altres productes de programari.
Programari de desenvolupament. Qualsevol programari orientat a facilitar la creaci de nou codi.
Programari de aplicacions. Tot aquell que proporciona solucions a negocis o necessitats humanes.
Programari cientfic. Facilita el desenvolupament d'avanos cientfics o permet estudiarlos.
Programari encastat. Proporciona control sobre qualsevol aparell electrnic allat.
Depenent de les caracterstiques de la seva distribuci, desenvolupament i portabilitat, tenim:
Programari estndard. D's general, tal com els processadors de text o fulles de clcul.
Legacy software. Algunes empreses funcionen amb un software fet a mida per a elles.
Programari lliure. Es tracta de programari gratut i de codi lliure, que permet l'aportaci d'altres.
Open World Computing. Programari que es puga usar en diferents dispositius i localitzacions.

Expliqueu que significa que una soluci siga viable, de qualitat i a l'abast.
Una soluci s viable, de qualitat i a l'abast quan resol un problema usant una quantitat de temps i
recursos raonable, usant mtodes de treball fiables que permetran desenvolupar aquesta amb mtodes
comuns i ben coneguts; tot a usant tecnologies ja disponibles o basades en tecnologies existents
provades efectives.

TEMA 1 - PROCESSOS
Per desenvolupar programari seguim determinats processos. Aquests son alguns exemples:

PROCS GENRIC
Aquest comprn cinc activitats per definir qualsevol projecte: Comunicaci, Planificaci,
Modelitzaci, Construcci i Posada en marxa. En aquest model la planificaci es porta a terme
durant tot el projecte, mentres que es porten a terme la resta d'etapes,
desde la definici de requisits fins a la posada en marxa.

Planificaci
Cal estimar i planificar les tasques. L'estimaci ens permet considerar els recursos necessaris per
desenvolupar el sistema. Una vegada de manera aproximada l'abast del projecte, podem elaborar una
planificaci temporal d'aquest.

Definici de requisits
Cal arribar a una definici especfica i realista. Tenim que identificar i definir els requisits que ens
permetran aconseguir l'objectiu del programa salvant les restriccions que ens imposen els recursos dels
que disposem. Aquesta tasca es part de l'activitat de Comunicaci.

Anlisi
Cal convertir els requisits del programa en una especificaci que permeta dissenyar codi. Aquest deu ser
capa de suplir totes les necessitats del programa, i s preferible que puga ser extensible. Definim QU
realitza el sistema.

Disseny
Especifiquem com i de quina forma manipulem les dades que fan funcionar el programa. Quina i com
es mostra la informaci als usuaris i com aquests interactuen amb ella. Tamb la distribuci per capes
que s'utilitzar, incloent com es comunica i emmagatzema l'informaci. Dissenyem tots els components
que conformen l'aspecte i infrastructura del sistema. Definim COM realitzar les tasques.

Construcci i posada en marxa

Aquesta etapa comprn des de la part de desenvolupament fins a la de prova i lliurament del producte.
Cal installar el maquinari, que deur ser adequat per al programari que desenvolupem; tamb cal
realitzar totes les connexions necessries i inicialitzar tots els servicis perqu estiguen preparats per a
funcionar.

MODELS DEL PROCS

Cal seguir un model adequat per desenvolupar el projecte de manera fiable. Aquest ens guarantir que el
producte final siga de qualitat, i el seu desenvolupament siga el ms gil possible. Elegirem el model
depenent de les caracterstiques del nostre producte i la demanda de mercat.

El model en cascada
Aquest model tradicional est considerat obsolet actualment. Depen de tindre una definici clara dels
requisits al inici del projecte. Cada pas s depenent del anterior, el que significa que errors en les
primeres fases del projecte sern molt difcils de solucionar a mesura que avanem. Els resultats no son
visibles fins les fases finals.

Desenvolupament de prototips
Podem desenvolupar parts del sistema allades per comprovar la seva funcionalitat, aixina desenvolupem
les rees que ens interessen en qualsevol ordre. Desenvolupem un prototip rpidament, el provem i
anem suplint les caracterstiques que necessita. Aconseguim centrar el desenvolupament en les rees
que ens pareixen ms interessants i obtenim una visi del producte final desde el primer moment.

El model en espiral
Aquesta es basa en els dos models anteriors. Definim quatre activitats: Planificaci, Anlisi de risc,
Enginyeria i Avaluaci. En cada iteraci desenvolupem versions del programari cada volta ms completes.
En les primeres etapes podem usar prototips per anar dibuixant el sistema; en les ltimes, podem optar
pel cicle de vida clssic. En cada fase de Anlisi decidim si seguir o no desenvolupant el projecte.

El model unificat (UP)

Consta de les quatre etapes del model anterior. En cada fase prestem ms atenci a diverses
consideracions a l'hora de portar a terme el projecte.

Processos gils
Sorgeixen com a millor manera de treballar front als antics processos de desenvolupament. La
metodologia de treball prioritza les segents caracterstiques: Interacci amb el programa, sobre els
processos i ferramentes; programari extensament documentat; colaboraci amb el client, sobre
negociaci de un contracte; resposta al canvi sobre el seguiment de un pla. Entre aquestes metodologies
es pot destacar la programaci extrema (XP). Per aplicar aquests mtodes es necessita un equip
collaboratiu amb gran capacitat d'organitzaci, i un cap capa de solucionar conflictes i dirigir a l'equip.

TEMA 2 - GESTI DEL PROJECTE

Analitzem la part de gesti del projecte, en la que s'intenta organitzar de manera ms eficient possible
les tasques a realitzar. Cal diferenciar:

Producte de programari: El resultat de portar a terme el procs de programari.

Procs de programari: Activitats estructurals que s'han de realitzar per desenvolupar programari.

PROJECTES DE PROGRAMARI
Un projecte es un conjunt d'activitats i tasques amb els quals assolim un objectiu, de manera que
implique un treball no immediat a un termini relativament llarg. Cualsevol projecte busca millorar un
producte o servei i est condicionat per els recursos dels que es disposa.

Inici del projecte

Es dona una fase de comunicaci en la que s'alerta de una necessitat o una oportunitat de negoci. Es dona
dons un contacte entre enginyer i l'interessat, i s'estableixen les necessitats i objectius del producte.
S'hi poden donar diversos llocs de partida a l'hora d'iniciar un projecte: Si cal mantindre sistemes a mig o
llarg termini, necessitat de nou programari, millores en el programari existent, etc...

Definir objectius i abast

Una vegada identificats els objectius cal definir l'abast del producte. D'aquest parmetre depn la
complexitat i l'estructura del projecte. Totes aquestes consideracions es tenen en compte durant la
definici de requisits i la resta de desenvolupament del projecte. Cal determinar tres aspectes per dur a
terme la definici de requisits: Quines rees usen el programari i amb qu interactuen; On
s'identifiquen les funcions que cobreix el programar; Quins altres productes de programari actual es
substitueixen o s'integren en el nou producte.

Identificar restriccions
Cada projecte conta amb unes restriccions que poden ser imposades per qualsevol de les dues parts, o
incls externament. Aquestes restriccions poden limitar l'abast del projecte e incls l'assoliment dels
objectius proposats. L'enginyer s qui t que aconsellar als usuaris entre les necessitats factibles i el
que es vol.

Avaluar alternatives
Cal decidir, en funci dels recursos, quin cam triar per a desenvolupar el projecte. Hi han diverses
alternatives que poden o no ser adequades, i comporten un cost i relaci benefici/risc. Cal usar
ferramentes com clculs del retornament de la inversi per decidir quina triar.

Gesti del risc

Els riscos que comporta el desenvolupament d'un projecte depenen de l'entorn d'implantaci, els
usuaris, el producte i l'equip de desenvolupament. Cal prendre mesures per minimitzar o eliminar
aquestos riscos, de lo contrari poden posar en perill l'xit del projecte.

Gesti de projectes
Per gestionar un projecte portem a terme tres activitats:

Direcci: Ordena i supervisa totes les activitats, assigna recursos i resol conflictes.

Control: Supervisa que el projecte seguixca la lnea acordada, ajustant-se a la planificaci.

Planificaci: Estableix el calendari d'activitats en funci dels recursos.

PLANIFICACI DEL PROJECTE

Defineix les necessitats econmiques, de recursos humans, tecnolgics i temps. Cal estimar el temps
que necessitem per portar a terme el projecte.

Activitats de la planificaci del projecte

Existeixen estandards per planificar projectes. Aquestos inclouen definir objectius, identificar tasques i el
seu repartiment en temps/recursos, relacions entre activitats... El resultat final de l'etapa de
planificaci d'un projecte comporta un resum de totes aquestes variables a concretar.

Estimaci de projectes de programari

Per estimar la durada del projecte ens basarem en la durada d'altres projectes similars. Es pot fer el
mateix per conixer els recursos que anem a necessitar. Aquest clcul no s exacte per ens permet fernos una idea de la durada/cost del projecte abans de comenar-lo.

Tcniques de suport a la planificaci

Per representar la planificaci del projecte usarem diagrames de Gantt i de descomposici de treball
(WBS). El diagrama de Gantt indica les activitats a realitzar de manera si son solapades o en parallel i
la durada de cadascuna. El WBS visualitza jerrquicament l'estructura de les activitats seguint l'ordre
Fase > Activitat > Tasca.

TEMA 3
INVESTIGAR ELS REQUISITS DEL SISTEMA
Si el sistema que volem desenvolupar es senzill, podem conixer quins son els requisits preguntant als
usuaris, per si es ms complicat, cal organitzar reunions i mecanismes per debatir l'especificaci de
requisits.
Cal conixer el negoci i el context per al qual estem desenvolupant el sistema, per tal de millorar o
eliminar aspectes deficitaris. Per fer-ho podem usar diverses tcniques.

Recopilar documents existents

Permet identificar dades d'entrada i d'eixida del sistema que poden formar part dels requisits. Cal
analitzar l's dels documents, detectant la seva utilitat i carncies per desenvolupar nous en el futur.

Observar el funcionament del sistema

Podem usar aquesta tcnica per identificar necessitats en un SI, per exemple la falta de documentaci o
fiabilitat d'aquesta. No hi ha que intervindre en el treball de l'usuari per obtindre una visi real del seu
treball. Mitjanant l'observaci podem identificar els punts forts i febles d'un SI.

TCNIQUES D'INVESTIGACI DE REQUISITS

Les tcniques segents s'usen per recopilar informaci, per tamb poden servir per
definir necessitats u objectius inicials.

Entrevistes
Les entrevistes tenen com avantatge el contacte personal amb el futur usuari, i ens permet obtindre
l'opini d'una persona que podrem valorar en major o menor mesura. Per fer una entrevista productiva
hem de tindre clar un gui a seguir, la relaci de l'usuari amb l'empresa, i resumir el contingut d'aquesta
per tal de poder consultarla rpidament ms endavant.

Qestionaris
Podem utilitzarlos quan volem obtindre resposta d'un gran nombre de persones sobre algn aspecte.
Proporcionen informaci ms objectiva i sn ms rpids de realitzar que les entrevistes.

Fonts externes
Quan ens trobem amb un entorn nou i no podem obtindre l'informaci de cap dels mtodes anteriors,
podem recurrir a consultar altres fonts com llibres o publicacions dels sectors en els que estem
interessats.

Desenvolupament conjunt d'aplicacions

Es coneix com JAD i consisteix en juntar un grup d'enginyers per desenvolupar un projecte. Tots els
requisits con revisats pels participants simultniament, fent un s ms efectiu del temps. s una manera
atractiva per resulta complicat organitzar aquestes reunions.

Documentar els requisits del sistema

Determinar tots els requisits s essencial perqu el document que els recull s la base per al
desenvolupament del sistema. Tamb serveix per a validar si el programari s'ajusta a all que es volia
aconseguir. Per elaborarlo es necessita el treball conjunt dels usuaris i l'enginyer.

Diagrames de casos d's

UML s un llenguatge que permet visualitzar i documentar un producte de programari. Disposa de
diferents models per representar cada fase de desenvolupament del sistema. El model de casos d's s el
mes representatiu de UML per representar el comportament del sistema.

Elements dels diagrames de casos d's

Disposem d'actors, casos d's i relacions:

Un actor es un rol que pot assumir un grup de persones o dispositius fsics.

Un cas d's representa una seqncia d'accions que executa el sistema per produr un resultat
d'inters per a un actor.

Una relaci representa la connexi entre actor i cas d's. Les relacions poden ser dirigides i
indicar en quin sentit flueix l'informaci.

Com fer el diagrama de casos d's

Identifiquem els actors i els missatges necessaris entre l'actor i el SI.

Identifiquem la funcionalitat que proporciona el SI cap als usuaris. Definim els casos d's.

Dibuixem el diagrama i describim els casos d's i els actors.

Validem amb els usuaris competents.

VALIDAR I VERIFICAR REQUISITS

Validar consisteix en validar si el que est desenvolupat s correcte, i verificar que s'est cobrint el que
els usuaris volen del programari. Cal comprobar que cada requisit siga consistent amb els objectius,
estiga dins l'abast del projecte, siga necessari, s'haja especificat amb un nivell d'abstracci adequat
amb la resta, etc.