2 psci proiectare material

8/20/2019 2 PSCI Proiectare Material

1/46

1

INTRODUCERE ÎNPROCESUL DE

PROIECTARE ALSISTEMELOR EMBEDDED


2/46

2

PRINCIPALE OBIECTIVEALE METODOLOGIEI DE PROIECTARE

ofer ă posibilitatea păstr ării unei istorii / înregistr ări arezultatelor etapelor proiectării (utilă pentru documentare,

testare funcţională, depanare) permite dezvoltarea sau folosirea unor unelte de

proiectare asistat ă de calculator, şi desf ăşurarea în paralel

a proiectării pentru diferite componente. simplifică comunicarea dintre membrii unei echipe de

proiectare.


3/46

3

ELEMENTE SPECIFICEPROIECTĂRII EmS

• Deciziile luate la proiectare se bazează pe re-utilizarea unor componente ale proiectelor dejaexistente

• Strânsa interacţiune dintre hardware şi software.Programatorii trebuie să înţeleagă partea hardware iar proiectanţii de hardware trebuie să înţeleagă partea

software• Utilizarea de blocuri funcţionale → fiecare proiectant

este responsabil atât de hardware cât şi de software

pentru o funcţiune, sau pentru un set de funcţiuni


4/46

4

ETAPE PROIECTARE

• Deciziile luate la un anumit pas al proiectării sunt bazate pe estimarea a ce

se va întâmpla mai târziu• Dacă estimările sunt inadecvate, trebuie să ne întoarcem şi să îndreptăm

deciziile noastre iniţiale, ţinând cont de noile evenimente

• La fiecare etapă a proiectării se adaugă detalii:√ analiza proiectului la fiecare pas pentru a determina cum se

îndeplinesc specificaţiile

√ rafinarea proiectului pentru a adăuga elemente de detaliu

√ verificarea proiectul pentru a fi siguri că îndeplineşte toate

obiectivele sistemului


5/46

PRINCIPALELE ETAPE ÎNPROCESUL DE PROIECTARE AL EmS

•Definirea cerinţelor produsului•Elaborare specificaţii funcţionale

•Crearea proiectului arhitectural•Furnizare versiune arhitecturalăfinalã

Etapa 1: Crearea arhitecturii

Etapa 2: Implementarea arhitecturii

Etapa 3: Testarea sistemului

•Implementare module•Verificare şi punere la punct

•Implementarea şi integrareasistemului

•Verificare şi testare sistem în diferitefaze de implementare

Etapa 4: Furnizarea prototipului

5


6/46

6

Et.1: Creareaarhitecturii

Definirea cerinţelor

produsului

Analiza preliminarã a

cerinţelor

Crearea proiectuluiarhitectural

Furnizare versiunearhitecturalã

Incorporarefeedback

Dezvoltareaversiune

arhitecturalã

Verificare şi feedback

Furnizareversiune arh.

finalã

Elaborare specificaţiifuncţionale

Et. 2: Implementareaarhitecturii

Imple-mentareasistemului

Incorporarefeedback

Et. 3: Testareasistemului

Verificareşi testaresistem

Etapa 4: Furnizareaprototipului

Furnizare prototipsistem


7/46

7


DEFINIREA PROBLEMEI ŞI A

CERINŢELOR PRODUSULUI• Definirea produsului descrie ce va fi şi ce va face acesta

• Definirea cerinţelor este primul pas al procesului, fiind cheia succesului în proiectarea sistemelor electronice: documentaţia

• Documentaţia descrie ce veţi construi

– Spune oamenilor de marketing ce produs vor avea de vândut, iargrupului de ingineri cum să implementeze produsul.

• Rezultatul acestei faze va fi o definire simplă a problemei, din punctul devedere al utilizatorului (beneficiarul)

– Se va descrie problema, dar nu se vor sugera soluţii• DA: Mi şcarea vorbitorului nu va fi stânjenit ă de cablul microfonului

• NU: Se va folosi un microfon wireless


8/46

8


CINE DEFINEŞTE CERINŢELE ?

• Într-o companie foarte mare, definirea cerinţelorva fi f ăcută de către departamentul demarketing, sau un client important

• Într-o companie mică schiţa de definire acerinţelor se poate face de către inginerii softwareşi hardware

• Pentru un proiecte mici, proiectantul defineştecerinţele


9/46

9


CE TREBUIE DEFINIT CA CERINŢE ?

• CERINŢE FUNCŢIONALE – Intr ări şi ieşiri (interfaţa cu utilizatorul şi mediul) – Funcţii şi constrângeri de timp

• CERINŢE NE-FUNCŢIONALE – Performanţă.

– Costuri.

– Consumul de putere.

– Dimensiune fizică şi greutatea.

– Fiabilitate, siguranţă în funcţionare, mentenabilitate


10/46

EXEMPLU DE FORMULAR DE

CERINŢE TIPICE


• Nume

• Scop• Intr ări / Ieşiri către lumea externă – Tipul datelor

– Caracteristicile generale ale datelor

– Tipuri de dispozitive de interfa ţă cu utilizatorul

• Func ţ ii . Intr ări→ FUNCŢII→ Ieşiri

• Performan ţă

• Costuri de fabrica ţ ie. Apreciere grosier ă, sau limită maximă.

• Putere. Apreciere grosier ă, sau limită maximă (baterii / reţea ?)

• Dimensiune / greutate fizică

10


11/46

11


REZUMAT CERINŢE

Fază RezultateDefinirea problemei de proiectare şi elaborare cerinţe• Cercetare, analiză piaţă • Consultare utilizator. Culegere de informaţii

generale de la clienţi (utilizatori sau beneficiari)

• Cerinţe funcţionale şi nefuncţionale

• Cercetare

⇒ Definirea corectă a problemei⇒ Propunere cerinţe⇒ Document (formular) de cerinţe⇒ Crearea unui plan de testare


12/46

12

EXEMPLU: Hart ă GPS

lat: 40 13 lon: 32 19

I-78

S c o t c h R o a

d

Poziţia utilizatoruluiîn latitudine /

Poziţia curentă autilizatorului

Prelucrat după Wayne Wolf, Computers as Components, Academic Press, London 2001


13/46

13


• Este un dispozitiv portabil care afişează pentru utilizator o hartă a terenului din jurul poziţiei curente a utilizatorului.

• Harta afişează modificările corespunzătoareschimbării poziţiei utilizatorului, sau ale

dispozitivului de afişare a hăr ţii.• Harta mobilă obţine poziţia sa de la GPS


14/46

14

Hartă GPS: Cerin ţ e ini ţ iale

Funcţionalitate: proiectat pentru utilizare în trafic auto şi scopuri similare; nu pentru utilizare nautică, sau aviaţie, care necesită funcţiuni şi baze de date

mai specializate. Sistemul va afişa / indica principalele drumuri şi alte punctede reper disponibile în bazele de date topografice standard.Interfaţa cu utilizatorul: Ecranul va avea cel puţin rezoluţia de 400 x 600 pixeli.

Dispozitivul va fi controlat prin maximum trei butoane. La apăsarea butoanelor pe ecran se deschide un meniu pentru a permite utilizatorului să selecteze funcţiile de control ale sistemului.

Performanţă: Harta se va rula lent pe ecran. După alimentare, afişarea cadruluiiniţial pe ecran se va face în cel mult o secundă, iar sistemul va fi capabil să verifice şi să afişeze poziţia sa în cel mult 15 secunde.

Cost: Costul de vânzare maxim 500$. (aproximativ de 5 ori costulcomponentelor).

Dimensiune / greutate: Dispozitivul se va potrivi confortabil în palma mâinii.

Consum de putere: Funcţionare pentru cel puţin 8 ore cu 4 baterii AA.


15/46

15

Formular de cerinţe Name GPS moving map

Purpose Consumer-grade moving map for driving

Inputs Power button, two control buttons

Outputs Back-lit LCD display 400 X 600

Functions Uses 5-receiver GPS system; three user-

selectable resolutions; displays currentlatitude and longitude

Performance Updates screen within 0.25 seconds uponmovement

Manufacturing cost $100 cost-of-goods- sold

Power 100 mW

Physical size/weight no more than 2” X 6” (5cm x 15 cm), 12ounces (340 g)



16/46

16


ELABORAREA SPECIFICAŢIILOR

• Specificaţiile reprezintă o descriere func ţ ional ă detaliat ă ce respectă cerinţele. Nu indică modul de implementare.

• Uşurează în ţ elegerea cerin ţ elor şi urmăresc îndeplinirea cerin ţ elor întimpul activit ăţ ilor de proiectare.

• U şureaz ă munca de proiectare şi înl ătur ă eventualele greşeli , repetărisau omisiuni ale unor funcţii⇒ reluări ale proiectării

• Specificaţiile sunt deosebit de importante pentru proiecte complexe, ceimplică un colectiv de cercetare ⇒ sarcinile de proiectare pentru fiecare persoană din grup.

• Presupun o analiz ă (internă ) a concep ţ iilor de proiectare enun ţ ate, pentru a verifica dacă specificaţiile cerute sunt posibil de implementat

– re-utilizarea unor păr ţi din alte proiecte anterioare permite asigurareasuccesului noului proiect (funcţional şi ca timp de terminare)



17/46

17


ELABORAREA SPECIFICAŢIILOR

• Specificaţiile pot fi privite ca un contract între beneficiar şi proiectant

• Documentele cu cerinţe şi specificaţii pot fi folosite pentru creareaunui plan de testare. Documentul de cerinţe defineşte ce estenevoie a fi testat.

• Pentru proiecte mari testarea poate fi f ăcută de un inginer detestare independent de colectivul de proiectare, care elaborează un plan de testare pe baza cerinţelor.

• Separarea analizei cerinţelor şi specificaţiilor este necesar ă adesea

– diferenţe mari între modul cum beneficiarii pot descrie sistemul şi ceeace au nevoie arhitecţii pentru a proiecta sistemul.

– beneficiarii pot avea aşteptări nerealiste cu privire la ceea ce se poateface cu bugetul alocat de ei.



18/46

18


ELABORAREA SPECIFICAŢIILOR • Complexitatea şi formalismul specificaţiilor depind de tipul companiei

proiectante şi de dimensiunea produsului final.• Se poate realizeaza o modelare (de obicei de tip O.O:) a specificaţiilor în

scopul proiectării arhitecturii şi ulterior a proiectării componentelor.

– Modelele sunt reprezentări conceptuale ale funcţionalităţii sistemului.Modelul este constituit din obiecte funcţionale şi reguli pentrucompunerea acestor obiecte.

• Descrierea grafică a specificaţiilor OO

– fie într-un limbaj de modelare (de ex. UML), – sau prin definirea şi desenarea unor diagrame de analiză conceptuală a

sistemului care cuprind:• componentele cheie ale sistemului,

• funcţiile de bază ale fiecărei componente,• interacţiunea – căile de comunicare între aceste componente şi• lista serviciilor oferite utilizatorului sistemului.


19/46

19

Exemplu diagramă conceptuală pentru

servicii bancare simple (Alistair Cockburn)

Servicii mica bancă: Verificare cont

Păstrare bani în cont

Verificare stocuri

Împrumuturi


20/46

20

Exemplu diagramă conceptuală

Casier

Depozit (Seif)

Calculator

Masă

Realizează tranzacţia

Păstrează banii

Furnizează o suprafaţă plată pentru completat cereri

tranzacţii

Păstrează înregistr ărileşi balan ele

$

Interogare balanţă Detalii tranzacţie

Client


21/46

21

REZUMAT SPECIFICAŢII

Fază Rezultate

Elaborare Specificaţii

Descriere de detaliu a comportării sistemului.

O descriere detaliat ă , precisă , clar ă şi f ăr ă

ambiguit ăţ i a cerinţelor Descriere funcţii şi interacţiune componente

sistem

Modelarea funcţionalităţii sistemului

Analiza concepţiilor de proiectare - revizie

Document specificaţii

Finalizarea descrierii modelul

funcţional Crearea unui plan de testare


22/46

22

EXEMPLU: Hart ă GPS • Lista de specificaţii pentru harta de navigare GPS va include

câteva componente: – ce date se recepţionează de la constelaţia de sateliţi GPS;

– datele hăr ţii afişate;

– interfaţa cu utilizatorul; – operaţii ce trebuie realizate pentru a satisface cerinţele

utilizatorului;

– operaţii în fundal (ne-evidente) cerute pentru a păstrasistemul în funcţiune, cum ar fi de exemplu funcţionareareceptorului GPS.


23/46

23


Wolf realizeaz ă descrierea func ţ ional ă prin modelare în

UML (Unified Modeling Language)

UML:

- este un limbaj vizual care poate capta în mod sugestiv

specificaţiile

- umbreşte distincţiile dintre hw şi sw

- modelează comportarea sistemului- este un generator automat de cod, putând genera cod

HDL sau C++ pentru implementarea proiectului.


24/46

24

Un obiect “Display” în notaţia UML

d1: Display

pixels: array[] of pixelselementsmenu_items

pixels is a2-D array

comment

object name

class name

attributes

Un obiect include un set de atribute care definesc starea sa internă. Atunci când seimplementează într-un limbaj de programare, aceste atribute devin de obicei variabile,

sau constante păstrate într-o structur ă de date.


25/46

25

O clasă în nota

ţia UML

Display

pixels

elementsmenu_items

mouse_click()draw_box

operations

class name

atributes

Operaţiile (metode înC++) determină modulcum obiectul

interacţionează cu restullumii


26/46

26

O specificaţie de maşină de stare UML (pentru o

operaţie a display-ului)

regionfound

got menuitem

calledmenu item

foundobject

object

highlighted

start state

stop state

mouse_click(x,y,button)/find_region(region)

region = menu/which_menu(i)

call_menu(I)

region = drawing/find_object(objid)

highlight(objid)


27/46

27

Secvenţa operaţiilor în timp descrisă prin diagrama secvenţială

m: Mouse d1: Display u: Menu

mouse_click(x,y,button)which_menu(x,y,i)

call_menu(i)

time

lifeline



28/46

28

PROIECTARE ARHITECTURALĂ

• Arhitectura este o reprezentare abstractă a implementăriisistemului şi indică structura sistemului în termenii

componentelor mari şi interconexiunile dintre acestea.• La nivel arhitectural, componentele hardware şi software suntreprezentate ca o compoziţie de elemente ce interacţionează.

• Detalii de implementare (HW & SW) sunt abstractizate,

conţinând doar informaţia de comportament şi de inter-relaţie între componente.

• O arhitectur ă embedded include elemente interne alesistemului, elemente externe ce interacţionează cu sistemul, proprietăţile fiecărui element individual şi relaţiile deinteracţiune între elemente

• În această etapă se face partiţionarea implementării funcţiilor

între hardware şi software.



29/46

29

IMPORTANŢA ARHITECTURII

• Indică cum se vor implementa func ţ iile sistemului, descrise înspecificaţii.

• Arhitectura este un mijloc eficient pentru în ţ elegerea proiectului EmS,constituind documentul ce defineşte infrastructura proiectului ,diferitele op ţ iuni de proiectare, constrângerile de proiectare. Planularhitectural are capacitatea de a comunica rapid şi corect modul de

proiectare către alte persoane cu sau f ăr ă pregătire tehnică, constituindtotodată baza (fundaţia) activităţii de planificare a proiectării unuidispozitiv.

• Permite analiza şi testarea calit ăţ ii unui dispozitiv• Permite definirea unor modalit ăţ i de reducere a costurilor de

proiectare-construcţie şi estimarea corect ă a riscurilor implicate deimplementarea diverselor elemente

• Permite reutilizarea cunoaşterii→ scăderea în viitor a costurilor



30/46

30

PROIECTARE ARHITECTURALĂ

Proiectarea arhitecturală include:Definirea componentelor sistemului. Este o estimare ce ţine deexperienţă şi de cunoaşterea caracteristicilor componentelor hardware şi

software propuse.Specificaţii hardware / software (există opţiunea între a cumpăra şi aconstrui prin for ţe proprii). În cazul UML: modelare grafică a obiectelorcomponente. Obiectele corespund pieselor reale HW şi SW ale

proiectului.Alegerea procesoruluiAlegerea limbajului de programare

Evaluarea sistemuluiProiectare hardwareProiectare firmwareIntegrare



31/46

31

DE ŢINUT CONT

• Este important de ţinut minte că hardware reprezintă un cost recurent(repetat), ce se repetă pentru fiecare sistem vândut.

• Software reprezintă un cost ne-recurent. Trebuie dezvoltat o singur ă dată, darnu apare ca şi cost pe unitatea de produs, decât dacă este o taxă de licenţă de plătit.

• Alegerea variantei de implementare hardware:

– Cu microprocesoare, microcontrollere discrete şi cablaj imprimat – înaceeaşi carcasă, System in Package

– Sistem distribuit.

– Un-sistem-pe-un-chip (System-on-chip = SOC). Proiecte SOC pe bază de nuclee IP

– ASIC, bazat tot pe nuclee IP dar pentru aplicaţii specifice şi în numărextrem de mare. Sunt tot SoC, full custom design.

ALEGEREA PROCESORULUIEtapa 1: Crearea arhitecturii


32/46

32

ALEGEREA PROCESORULUI

• Numărul de pini de IO necesari - Pini grupaţi în porturi de IO, restricţii, capabilităţicurenţi mari

• Interfeţe necesare• Cerinţe memorie RAM

– numărul de variabile plus suma tuturor bufferelor interne, structuri FIFO, şidimensiunea stivei

– intern / extern, restricţii de utilizare, SFR, moduri de adresare – eficienţă compiler.

• Cerinţe memorie ROM – suma codului de program plus toate tabelele necesare a fi incluse într-o memorie

nevolatilă – regulă bazată pe experienţă: ocupare în propor ţie de maxim 80%

– Testare compilator ales→ por ţiuni de cod pentru a determina dimensiuneaacestuia după compilare / asamblare – dimensiunea codului depinde limbajul de programare ales pentru dezvoltare – dacă se folosesc operaţii în virgulă mobilă, iar procesorul nu are inclus un co-

procesor matematic⇒ cod mare.



33/46

33


• Număr de întreruperi cerut• Consideraţii real-time• Mediul de dezvoltare. Funcţiuni principale ale unui mediu integrat de

dezvoltare (IDE - Integrated Development Environment), ce rulează peun calculator desktop (de exemplu un PC).: – dezvoltarea programelor utilizator (de obicei în limbaj C şi / sau

asamblare) într-o fereastr ă de editare.

– compilator şi editor de legături – depanarea şi punerea la punct a programelor prin debugger – asamblor pentru rutinele scrise în asamblare – simulator pentru rularea programelor (inclusiv pas cu pas prin

debugger) şi urmărirea conţinutului registrelor interne, a memoriei, a porturilor de IO, a circuitelor timer / counter, etc.

– transferul codului (program executabil) către memoria locală (flash,EEPROM) a microcontrollerului



34/46

34


– Investiţii anterioare ale companiei (IDE), principii economice.

• Necesităţi de viteză de prelucrare. – În cazul cel mai dezavantajos al mai multor întreruperi aflate în curs

de servire procesorul trebuie să funcţioneze respectând specificaţiilede proiectare.

– Lungimea buclelor de interogare suficient de scurtă ca să nu se piardă niciodată un octet de la o intrare de date serială, sau de laoricare altă interfaţă.

– Frecvenţa de ceas a procesorului nu trebuie confundată cu frecvenţa

oscilatorului de ceas. – Setul de instrucţiuni este de asemenea foarte important. În unele

aplicaţii arhitectura RISC poate fi o capcană.



35/46

35


• ROM-ability – Flash

– EPROM

– OTP

– ROM.

• Costuri

• In Circuit programming

• Arhitectura memoriei

• Cerinţe de putere• Cerinţe de mediu – Unele aplicaţii impun ca MP să lucreze la game extreme de

temperatur ă şi radiaţie.



36/46

36

DEZVOLTAREA VERSIUNII

ARHITECTURALE

• Proiectarea componentelor hardware şi software• Integrarea sistemului prin conectarea componentelor

proiectate.

• Verificare şi obţinere de informaţii de feedback • Inspecţia unui proiect se face de către o alt ă persoană

decât proiectantul (detectarea omisiunilor, erorilor).

Inspecţia se face pe baza unor prezent ări scrise sau oraledin partea proiectantului.



37/46

37

DEZVOLTAREA VERSIUNIIARHITECTURALE

• Documentarea:

– detectarea uşoar ă a componentelor care conduc laneconformităţi cu cerinţele

– comunicarea dintre membrii unei echipe

– elaborarea rapoartelor cu privire la proiect – elaborarea documentaţiei finale a proiectului,

– reutilizarea componentelor proiectului pentru alte

proiecte, modificare, upgrade.• Elaborarea unui plan pentru integrarea şi testarea

componentelor



38/46

38

REZUMAT:

ARHITECTURA ŞI INTEGRAREProiecte la nivel de sistem.

Structura sistemului în termeniicomponentelor mari şiinterconexiunile dintre acestea.Modul de implementare afuncţiilor şi modul de

implementare a componentelor • Alegerea procesorului• Alegerea limbajului• Definirea blocurilor majore

hardware şi software• Opţiune între cumpărare sau

construire prin for ţe proprii.• Partiţionare: Blocuri

funcţionale, Hw / SW

REZULTATE

• Specificaţii pt. blocurifuncţionale• Alegere MCU/CPU• Alegere limbaj

• Revizie de proiectare asistemului


39/46

39

EXEMPLU: Hart ă GPS Diagrama bloc ce define şte arhitectura pentru harta mobil ă

Receptor GPS

Maşină decăutare

Dispozitivde redare

Interfaţă utilizatorDatabase

Display


40/46

40

HARDWARE

ReceptorGPS

CPU

Panou I/O

Display FrameBuffer

Memorie

Magistrală


41/46

41

SOFTWARE

Poziţie Căutare în bază date Redare

TimerInterfaţă utilizator

Pixeli

2. Implementarea arhitecturii


42/46

42

IMPLEMENTAREA SISTEMULUI• Implementarea hardware şi software

• Proiectare de detaliu componente şi construcţie – Pentru software asta înseamnă proiectarea de detaliu, scriere şi

depanare a codului

– Pentru hardware înseamnă proiectarea de detaliu, realizarea proiectului prototipului şi testarea circuitelor.

• Implementare nucleu MCU

• Construcţie şi testare alte blocuri funcţionale ale arhitecturii. Dacă la

proiect lucrează o singur ă persoană, atunci blocurile funcţionale suntcompletate secvenţial. Dacă există mai mulţi proiectanţi acestea se potrezolva în paralel.

2. Implementarea arhitecturii


43/46

43

IMPLEMENTAREA SISTEMULUI• Sarcinile presupuse pentru fiecare bloc funcţional includ proiectare

hardware de detaliu şi construc ţ ie, proiectare software de detaliu şiconstruc ţ ie şi apoi integrarea hardware-software şi testarea

• Pot exista interdependen ţ e între proiectarea hardware şi software.Partea hardware nu poate fi testată până când o parte din software nu

este gata, iar software nu poate fi testat până când partea din proiectulhardware nu este gata

• În mod tipic se construieşte hardware şi se testează minimal mai întâi.Apoi majoritatea efortului se concentrează pe scrierea de software şitestarea software pe hardware.

• Documentarea sistemului

3. Testarea sistemului


44/46

44

VERIFICARE ŞI TESTARE• Scop: verificare, testare, încorporare de informaţii de feedback pentru

corectarea neconformităţilor • Revizii:

– Reviziile sunt demonstra ţ ii, inspec ţ ii ale schemelor şi inspec ţ ii alecodului

– Revizia trebuie f ăcută de specialişti independenţi, familiari cu proiectul(CERINŢE) şi tehnologiile, care să ajute la detectarea erorilor

– Se pot detecta omisiuni, erori• Testarea produsului final este o continuare a activităţilor de testare din

timpul proiectării, acestea put-nd fi urmărite conform documentaţieielaborate la proiectare arhitecturală

• Testare publică - un proiect preliminar este distribuit unor beneficiarde la care se aşteaptă feedback (“beta testing ”). Reacţia de la clienţi poate duce nu numai la detectarea unor erori, schimbarea codului, darşi la schimbarea unor specificaţii. Nu e recomandată întotdeauna în

domeniul EmS.

4. Furnizare prototip


45/46

45

FURNIZARE PRODUS FINAL ŞI

MENTENANŢĂ• Prototipul final şi integrarea constituie ultima fază a proiectării.

• Este faza în care toate blocurile funcţionale sunt înglobate şi seconstruieşte prototipul hardware final . De asemenea modulelesoftware sunt combinate, iar codul este revizuit pentru a rula ca oaplicaţie de sine stătătoare pe prototip. Unele din componentelehardware şi software au fost deja construite şi testate pe un sistem dedezvoltare, înainte de această fază

• În funcţie de complexitatea sistemului de dezvoltare utilizat această ultimă fază poate fi un pas uşor de realizat, sau poate fi o operaţiecomplexă.

• În mediul competitiv actual multe din deciziile luate la proiectare se bazează pe re-utilizarea unor componente ale proiectelor dejaexistente. Astfel că ciclul de via ţă al unui proiect continuă şi după

produc ţ ie şi el poate include mentenan ţ a produsului, raportarea bug-

urilor şi arhivarea.

4. Furnizare prototip


46/46

46

FURNIZARE PRODUS FINAL ŞI

MENTENANŢĂ• Documentare:

– Importantă atât pentru componentele hardware, dar şi maiimportantă pentru cele software. Permite detectarea uşoar ă acomponentelor care conduc la neconformit ăţ i cu cerinţele, permitecomunicarea dintre membrii unei echipe, elaborarea rapoartelorcu privire la proiect, elaborarea documenta

ţ iei finale a proiectului,

permite reutilizarea componentelor proiectului pentru alte proiecte.

– Pentru software toate informaţiile referitoare la etapele anterioare,de la punerea problemei, elaborarea algoritmului şi a schemeilogice (eventual diversele versiuni succesive indicând evoluţia

programului) – Sursa programului (cu comentarii suficiente pentru a se corela cu

schema logică), eventuale eşantioane de date de intrare / ieşire,

dacă este cazul

2 psci proiectare material

Documents