Modele de dezvoltare software

 
 Modelele industriale de dezvoltare software au fost inventate și îmbunătățite pe parcursul a peste 40 de ani de programatorii din întreaga lume. Următoarele modele au fost stabilite și sunt folosite cel mai frecvent în software development:
  • Agile 
  • Iterative model 
  • RUP
  • Scrum
  • Spiral model
  • Waterfall model
  • XP
  • V-Model
  • Incremental model
  • Prototype model
Metoda Agile 

Unul din modele cum este Agile este axat pe mulțumirea clientului prin livrarea cât mai rapida a softwareului ce corespunde cu  nevoile celui ce cumpăra sau folosește acest software.
Principiile de baza a modelului Agile sunt:

  • Satisfacerea clientului prin livrarea unui software util
  • Cerintele venite de la client sunt bine venite chiar si in ultimul moment al dezvoltarii software
  • Softwareul funcțional este livrat le interval de săptămâni nu luni
  • Software-ul funcțional este principala măsura a progresului
  • Dezvoltarea continua capabila sa mențină un ritm crescut
  • Cooperare zilnica intre oamenii de afaceri ai programatori
  • Comunicarea fata in fata este cea mai buna forma de comunicație , dacă se poate toți sa lucreze în aceeași locație
  • Proiectele sunt construite in jurul indivizilor foarte motivați și de încredere
  • Atentia continua la datele tehnice perfecte si a designului cat mai bun
  • Simplitate
  • Echipe care se autorganizeaza
  • Adaptare rapida la schimbări

In concluzie aceasta metoda se poate folosi pentru dezvoltarea de software pentru PC-uri unde se impune un timp cat mai scurt de livrare.
Pentru detalii vizitați :http://en.wikipedia.org/wiki/Agile_software_development
Data viitoare o sa discutam despre Iterative model.

Standardizarea


Standardul este un anumit fel de metodă, măsură, unitate de valori, criterii, mai mult sau mai puțin recunoscute pe plan național sau internațional. Astfel se poate vorbi de stanardizarea unor poduse, metode, norme mai ales în domeniul tehnic.

Standardizarea pentru automotive se face de organizația Automotive SPICE iar din această organizație fac parte următoarele firme : AUDI AG, BMW Group, Daimler AG, Fiat Auto S.p.A., Ford Werke GmbH, Jaguar, Land Rover, Dr. Ing. h.c. F. Porsche AG, Volkswagen AG și Volvo Car Corporation.

Citez de pe siteul lor : 

The Automotive SPICE® Process Assessment Model will be used to perform conformant assessments of the software process capability of automotive suppliers in accordance with the requirements of ISO/IEC 15504-2: 2003.

The Automotive SPICE® Process Assessment Model is based on ISO/IEC 15504-5: 2006.” 

ISO/IEC 15504, este cunoscut ca SPICE (Software Process Improvement and Capability Determination),care este un „framework for the assessment of processes”  dezvoltat de Joint Technical Subcommittee between ISO (International Organization for Standardization) si IEC (International Electrotechnical Commission).

 Sper că v-am trezit un pic interesul despre standardizarea proceselor software.


În următorul post o să trec în registru toatele metodele de dezvoltare software.

Linkuri utile

Cateva linkuri foarte utile pentru cei interesati de inspectii, review-uri, calitate si procesul de dezvoltare software:

http://satc.gsfc.nasa.gov/Documents/fi/gdb/fitext.txt
http://www.ife.tugraz.at/datashts/Quality/selspig.pdf
http://satc.gsfc.nasa.gov/audit/audgb.txt
http://satc.gsfc.nasa.gov/GuideBooks/cmpub.html

spor la citit 🙂

Review detaliat

Code Review

Definitie:
„Making mistakes is human and we are human” => din cauza asta avem nevoie sa ne revizuim din cand in cand munca. Din experienta va spun ca in cod apar cele mai multe defecte de obicei intr-un proiect software (cam 40 % din total). Si tot din experienta va spun ca fara un codereview bun aceste erori ajung la client in proportie de 20%.
Regulile de code review se pot stabili in interiorul companiei dar si adoptand regulile MISRA (http://www.misra.org.uk/).

Cel mai bine este sa se adopte in prima faza regulile MISRA iar apoi regulile particulare din interiorul companiei.
In primul „release” codereview-ul TREBUIE executat de catre o persoana foarte experimentata urmand in detaliu regulile si urmand firul procesului de la specificatii pana la implementare si integrarea in sistem.

Pentru o pagina A4 de cod printat in general se petrece in medie intre 30 min. si o ora de citire si intrelegere logica a codului. Deci e nevoie de mult timp dar merita , erorile gasite se vor elimina din primul sample iar in continuare clientul va avea un produs pe gustul lui.

Codereview-ul merita efortul , va spun din experienta nu e doar o chestie teoretica citita prin cartile de specialitate.

Codereview-ul se poate face si de catre o firma specializata cu oameni foarte experimentati dar asta costa.

Cel mai bine sa fie facut „in house” si in detaliu.

Succes.

Depistarea si rezolvarea problemelor

Depistarea si rezolvarea problemelor este o parte dintr-un proiect care nu ar trebui sa exista , cateodata este un cosmar sa descoperi probleme cu cateva zile sau chiar ore inainte de release.
Ideea cea mai importanta sa se actioneze cu calm si sange rece fara panica. Nu exista nimic pe lumea asta care nu mai poate fi reparat (aici ma refer la creeatiile oamenilor implicit a inginerilor 🙂 ). Deci daca totul e specificat cum ar trebui sa fie si este revizuit atunci se poate rezolva usor.
Primu pas dupa ce se gaseste o problema este documentarea si apoi reproducerea ei pe un sistem real sau simulat (e de recomendat real).
Al doilea pas este cautare de solutii si alegerea celei mai bune rezolvari cu putinta. Solutia romaneasca cu sarma si/sau sfoara/scotch nu este admisa :).
Dupa aplicarea rezolvarii se intocmeste o documentatie unde se precizeaza motivul problemei (motivul poate fi chiar si neatentia sau neglijenta) si masurile luate astfel incat sa nu mai apara la urmatorul proiect.
Apoi in ultima faza cu rezolvarea si cu documentatia se merge la client. De obicei clientul este intelegator daca se explica logic cauza erorii.

Cam atat pentru azi .
O zi buna in continuare

Link util

In linkul de mai jos gasiti mare parte din spusele mele si ceva in plus de catre un profesionist al conducerii proiectelor :
http://www.malotaux.nl/nrm/English/index.htm

Acum doi ani am sustinut un program de pregatire impreuna cu domnul Niels Malotaux si in urma cursul am sustinut un examen si am obtinut un certificat.
Spor la citit.

Inspectia si imbunatatirea continua

Inspectia si imbunatatirea continua a fost prima data introdusa de catre japonezi la uzinele Honda si Toyota. Aceasta procedura implica o verificarea si corectare a muncii permanenta de catre cei implicati in proces. In general inspectia se realizeaza de persoane mai experimentate si care iti pot da o parere pertinenta despre proiectul care se desfasoara.
Procesul de inspectie se compune din 3 etape :
Prima etapa este pregatirea documentatiei si planificarea sedintelor de discutii
Etapa a doua este inspectia propriuzisa care se face citind temeinic toate documentele pe care le are la dispozitie inspectorul.
Etapa a treia este sedinta de inspectie in care se noteza intr-un document tot ce s-a gasit in neregula pe perioada de inspectie.

Imbunatatirea continua se realizeaza de fapt in momentul in case se realizeaza si inspectia. Cei care fac inspectia vin cu idei de imbunatire a proiectului si procesului in sine.
Chiar daca pare o chestie banala acest proces de inspectie si imbunatatire continua aduce foarte multe beneficii si ajuta la repararea unor erori inca din stadiul de dezvoltare.

Cam atat pentru azi.
O zi buna.
PS : un feedback de la cititori mi-ar fi foarte util , sa stiu daca are vreun inteles ce am scris eu aici

Planul si urmarirea proiectului

Viata unui proiect incepe intotdeauna cu primul pas stabilirea planului, iar apoi urmarirea indeaproape a planului stabilit. Din punct de vedere al desfasurarii proiectului acest lucru este destul de simplu in unele situatii dar si foarte complicat. Pentru taskurile simple e destul de simplu de verificat si de bifat taskul dar pentru taskurile mai complicate acest lucru e destul de complicat daca nu ai o experienta destul de consistenta in domeniul respectiv. Cel mai grav este cand taskul nu se poate realiza si proiectul de opreste si intarzie din cauza asta. Acest fapt trebuie discutat cu persoane cu mai multe experienta si apoi replanificat, iar in cel mai rau caz sa se plateasca o alta firma sa rezolve problema .
Soutiile exista pentru iesirea din blocaj doar ca trebuie actionat cu calm si cu rabdare. Pas cu pas se rezolva toate taskurile iar in final se finalizeaza toate etapele proiectului.
Din punctul meu de vedere urmarirea proiectelor este foarte importanta si indispensabile .

In concluzie proiectul trebuie urmarit indeaproape .
o zi buna .

Modelul de lucru in V (V-Model)

Modelul in V este principala metoda de lucru in automotive. Mai jos am adaugat o imagine foarte sugestiva despre acest model.

In principiu se incepe cu specificatiile de la client in prima faza in V-Model, procesul incepe de sus din stanga iar apoi se trece pe rand prin toate fazele. Criteriul de iesire dintr-o faza si de intrare in alta faza este revizuirea si corectia muncii. Prin aceasta revizuire se asigura o cat mai buna intelegere si corectitudine a proiectului in orice moment al lui.
In faza doi se clasifica cerintele si se realizeaza si o revizuirea a lor impreuna cu clientul.
Faza trei este crearea arhitectura sistemului ce sta la baza proiectului.
Faza a patra contine designul detaliat a proiectului.
Faza a cincea este crearea efectiva a codului (in cazul software-lui) sau a proiectului in sine in cazul altor domenii (de exemplu crearea unui produs nou care porneste de la zero).
Faza a sasea este testarea temeinica. Testarea se va face pe unitati functionale.
Faza a saptea este testul de integrare in sistem pentru proiectele cu mai multe unitati functionale.
Faza a opta si ultima din modelul V este testul de sistem. In faza aceasta sistemul ar trebui sa fie complet functional iar dupa corectia eventualelor defecte se poate livra catre client.

Cam aceasta este modelul V dupa care lucrez in momentul de actual . Metoda a fost inventata de catre armata SUA si a fost apoi adoptata de firmele din Germania si apoi din toata lumea. In prima faza insa acest model a fost foarte ineficient dar s-a ajuns la concluzia ca acest model trebuie parcurs de mai multe ori in faze diferite de maturitatea a produsului realizat . Numarul de faze ar putea fi de la 3 pana la 5 faze in care se parcurge V-ul.

Cam atat pentru azi . Maine o sa prezint o schema a subproceselor din acest model.

O zi buna.

Pentru detalii vizitati : http://en.wikipedia.org/wiki/V-Model

Cerintele clientilor

De obicei toti clientii sunt foarte mofturosi si greu de multumit . Sunt mai multe strategii in acest sens pentru ai „linistii” . Una din strategii este stabilirea prin contract asupra modificarilor ce trebuiesc facute de-a lungul desfasurarii contractului . In acest domeniu este bine sa implicati un negociator abil si un specialist in contracte .

Daca totul a fost stabilit atunci se pot trasa termene de predare si se vor crea cerinte scrise pentru orice vrea clientul. Toate cerintele urmeaza sa fie numerotate cu un numar unic astfel incat sa nu se poata confunda cu orice alta cerinta. Daca o cerinta se va anula atunci numarul respectiv nu va mai fi folosit.

Stabilirea cerintelor si analiza lor este poate cel mai important pas in inceperea unui proiect, cel putin asa consider eu.

Pe parcusul proiectului clientul se poate razgandi asupra unei cerinte si sa o inlocuiasca cu ceva nou , in cazul acesta se revine la contractul semnat si se face o evaluare a costurilor. Se merge pe principiu vrei ceva nou neplanificat atunci platesti. Asta va implica renegocierea termenele de livrare si timpului de executie .

Cam atat pentru azi . In urmatorul post o sa spun cateva lucruri despre modelul german si cel american de lucru V-Model. Acest model il folosesc si este unul dintre cele mai competitive din lume. Se foloseste in automotive , aeronautica si multe alte domenii importante.

O zi buna.