Vorbe de duh din cartea „The Mythical Man-Month”

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you. 

More software projects have gone awry for lack of calendar time
than for all other causes combined. Why is this cause of disaster
so common?

First, our techniques of estimating are poorly developed. More
seriously, they reflect an unvoiced assumption which is quite untrue,
i.e., that all will go well.

Second, our estimating techniques fallaciously confuse effort
with progress, hiding the assumption that men and months are
interchangeable.

Third, because we are uncertain of our estimates, software
managers often lack the courteous stubbornness of Antoine’s chef.

Fourth, schedule progress is poorly monitored. Techniques
proven and routine in other engineering disciplines are considered
radical innovations in software engineering.

Fifth, when schedule slippage is recognized, the natural (and
traditional) response is to add manpower. Like dousing a fire with
gasoline, this makes matters worse, much worse. More fire requires
more gasoline, and thus begins a regenerative cycle which
ends in disaster.

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