Witam

Zapraszam do dyskusji na temat procedury tworzenia programów
komputerowych jaką można zastosować indywidualnie oraz w niewielkich
zespołach. Interesujące też by były wypowiedzi osób które mają
doświadczenie z dużymi projektami (jak wtedy zmieniają się procedury
wytwarzania programów).

Ja głęboko wierzę w sens takiej dyskusji, gdyż z moich doświadczeń
zawodowych wynika, że uprawianie partyzantki przy programowaniu jest na
porządku dziennym w polskich firmach. Co jakiś czas wracam do poszukiwań
skutecznych a przy tym indywidualnie wykonalnych metod tworzenia
oprogramowania. Dlatego by zacząć dyskusję przedstawię obecny kształt
procedury tworzenia programów nad którą pracuję. Proszę o sugestie wraz
z uzasadnieniem (czyli apeluję żeby była to konstruktywna dyskusja).

Podstawowym założeniem niniejszej procedury wytwarzania oprogramowania
są 2 fundamentalne zasady inżynierskie: "metoda pojedynczych kroków"
(rozwiązywanie jednego problemu na raz) oraz "modularyzacja" (czyli
zamykanie problemów i funkcji w odrębnych blokach).

Procedura tworzenia programów komputerowych:
1. Określenie co ma robić program (zebranie wymagań, przypadki użycia,
zwrotny opis systemu (do weryfikacji przez klienta), identyfikacja i
redukcja ryzyka)
2. Zdefiniowanie elementów składowych programu (biblioteki zewnętrzne,
moduły wewnętrzne (ogólnie), zastosowanie wzorców projektowych do modułów)
3. Określenie funkcji elementów składowych (bibliotek, modułów
(szczegółowo), diagram klas (zastosowanie zasad OOP* i wzorców
projektowych))
4. Analiza przewidywanego działania i współdziałania elementów
składowych (diagramy stanów i sekwencji, oraz testy bibliotek,
prototypowanie, identyfikacja i redukcja ryzyka)
5. Ocena łatwości rozbudowy programu i ocena spójności elementów
składowych (spr. spełnienia zasad OOP*, identyfikacja i redukcja ryzyka)
6. Zdefiniowanie parametrów funkcji realizowanych przez elementy
składowe (wartości prawidłowe i nieprawidłowe parametrów)
7. Wykonanie programu (projekt UI, projekt relacyjnej bazy (lub plików),
kodowanie)
8. Analiza pracy programu (stopień realizacji zadań, testy funkcjonalne,
optymalizacja (UI i profilowanie), wycieki pamięci)
9. Zrobić instalatory, stronkę domową z płatnościami i kasować kapuchę!

Na podstawie:
a) procedury budowy prototypu piramidy z tomu 9 "Monografii 1/5" prof
Jana Pająka
b) "Head First - Object Oriented Analysys and Design"

* zasady OOP (Obiektowo Orientowane Projektowanie) - ściąga z tych
zasad: brak duplikacji kodu, enkapsulacja, operowanie na interfejsach
zamiast na implementacji, preferowanie kompozycji zamiast dziedziczenia,
atomowa odpowiedzialność klas, klasy otwarte na rozbudowę ale zamknięte
na modyfikacje, sensowne dziedziczenie

do góry

OPisales w zasadzie metode "Waterfall". Nie mowie ze to zla metoda, ale bardzo
niemodna ostatnio ;-)

RW

do góry

On Fri, 17 Feb 2012 13:58:07 +0100, szyk <s...@o...pl> wrote:

>Witam
>
>Zapraszam do dyskusji na temat procedury tworzenia programów
>komputerowych jaką można zastosować indywidualnie oraz w niewielkich
>zespołach. Interesujące też by były wypowiedzi osób które mają
>doświadczenie z dużymi projektami (jak wtedy zmieniają się procedury
>wytwarzania programów).
>

Nooo... Bierze sie komputer z jakimis toolami i pisze....

Taka dyskusja ma mniej wiecej taki sam sens jak dyskusja pod haslem
"procedura tworzenia powiesci"

A.L.

do góry

szyk <s...@o...pl> napisał(a):

> Ja głęboko wierzę w sens takiej dyskusji, gdyż z moich doświadczeń
> zawodowych wynika, Ĺźe uprawianie partyzantki przy programowaniu jest na
> porządku dziennym w polskich firmach.

Wybacz ze nie wprowadzam nic konstruktywnego. Chcialem tylko potwierdzic.
Czesto obserwuje ze program jest juz ukonczony a projekt jest jeszcze
niezgodny z programem :D

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

W dniu 2012-02-17 16:15, A.L. pisze:
> On Fri, 17 Feb 2012 13:58:07 +0100, szyk<s...@o...pl> wrote:
>
>> Witam
>>
>> Zapraszam do dyskusji na temat procedury tworzenia programów
>> komputerowych jaką można zastosować indywidualnie oraz w niewielkich
>> zespołach. Interesujące też by były wypowiedzi osób które mają
>> doświadczenie z dużymi projektami (jak wtedy zmieniają się procedury
>> wytwarzania programów).
>>
>
> Nooo... Bierze sie komputer z jakimis toolami i pisze....
>
> Taka dyskusja ma mniej wiecej taki sam sens jak dyskusja pod haslem
> "procedura tworzenia powiesci"

Kiedyś opowiadałeś o procedurze budowania solvera do konkretnego
równania cząstkowego. I nie było tak źle, nawet ciekawie:)

pzdr
bartekltg

do góry

On Fri, 17 Feb 2012 16:42:38 +0100, bartekltg <b...@g...com>
wrote:

>W dniu 2012-02-17 16:15, A.L. pisze:
>> On Fri, 17 Feb 2012 13:58:07 +0100, szyk<s...@o...pl> wrote:
>>
>>> Witam
>>>
>>> Zapraszam do dyskusji na temat procedury tworzenia programów
>>> komputerowych jaką można zastosować indywidualnie oraz w niewielkich
>>> zespołach. Interesujące też by były wypowiedzi osób które mają
>>> doświadczenie z dużymi projektami (jak wtedy zmieniają się procedury
>>> wytwarzania programów).
>>>
>>
>> Nooo... Bierze sie komputer z jakimis toolami i pisze....
>>
>> Taka dyskusja ma mniej wiecej taki sam sens jak dyskusja pod haslem
>> "procedura tworzenia powiesci"
>
>Kiedyś opowiadałeś o procedurze budowania solvera do konkretnego
>równania cząstkowego. I nie było tak źle, nawet ciekawie:)
>
>pzdr
>bartekltg

Przypomnij o co szlo, bo nie pamietam...

A.L.


P.S. Nie wiem o co OP chodzi. O projetktwanie systemu, projektowanie
programu, pisanie kodu, testowanie, czy co?

do góry

W dniu 2012-02-17 16:48, A.L. pisze:
> On Fri, 17 Feb 2012 16:42:38 +0100, bartekltg<b...@g...com>
> wrote:

>>> Nooo... Bierze sie komputer z jakimis toolami i pisze....
>>>
>>> Taka dyskusja ma mniej wiecej taki sam sens jak dyskusja pod haslem
>>> "procedura tworzenia powiesci"
>>
>> Kiedyś opowiadałeś o procedurze budowania solvera do konkretnego
>> równania cząstkowego. I nie było tak źle, nawet ciekawie:)
>>
>> pzdr
>> bartekltg
>
> Przypomnij o co szlo, bo nie pamietam...

Złościłeś się na kogoś wklepującego równania bezpośrednio
w C. Skalarnie, po współrzędnych. Twierdzięłś, że porządnie
używa się X do zamanipulowania równaniami, Y do przetworzenia
ich na kod i czegoś innego ro zrobienia/wykorzystania samego
silnika liczącego.
Też szczegółow nie pamiętam, a zapamiętałem, bo byłem świeżo po
zmuszaniu matalba do stworzenia wlasnego solvera;)

> P.S. Nie wiem o co OP chodzi. O projetktwanie systemu, projektowanie
> programu, pisanie kodu, testowanie, czy co?

Pewnie o wszytko. Takie 'opowiedzcie mi o analizie matematycznej' ;)

pzdr
bartekltg

do góry

On Fri, 17 Feb 2012 13:58:07 +0100, szyk <s...@o...pl> wrote:

>* zasady OOP (Obiektowo Orientowane Projektowanie) - ściąga z tych
>zasad: brak duplikacji kodu, enkapsulacja, operowanie na interfejsach
>zamiast na implementacji, preferowanie kompozycji zamiast dziedziczenia,
>atomowa odpowiedzialność klas, klasy otwarte na rozbudowę ale zamknięte
>na modyfikacje, sensowne dziedziczenie

Tak na marginesie, polecam ksiazke

Skunk Works: A Personal Memoir of My Years of Lockheed
Ben R. Rich, Leo Janos

To tak ogolnie na pemat projektowania.

A tak powaznie, to model Kolegi pachnie mi "waterfall model". Tak sie
od dawna nie robi. Programy sie raczej pisze iteracyjnie. Trudno od
samego poczatku na przyklad zdecydowac na temat modularyzacji jak nie
wiacomo dokaldnie do program bedzie robil i jak. Czesto wiele rzeczy
nei wiadomo na poczatku, i musza byc "dotarte" przez budowe wielu
prototypow.

Proponuje jednak poczytac o "agile"

A.L.

do góry

On Friday, February 17, 2012 4:36:42 PM UTC, A. L. wrote:

> Proponuje jednak poczytac o "agile"
>
> A.L.

Byl o tym bardzo pouczajacy flejm na tej grupie pare tygodni (?) temu.

RW

do góry

On 17/02/2012 16:36, A.L. wrote:
> On Fri, 17 Feb 2012 13:58:07 +0100, szyk<s...@o...pl> wrote:
>
>> * zasady OOP (Obiektowo Orientowane Projektowanie) - ściąga z tych
>> zasad: brak duplikacji kodu, enkapsulacja, operowanie na interfejsach
>> zamiast na implementacji, preferowanie kompozycji zamiast dziedziczenia,
>> atomowa odpowiedzialność klas, klasy otwarte na rozbudowę ale zamknięte
>> na modyfikacje, sensowne dziedziczenie
>
> Tak na marginesie, polecam ksiazke
>
> Skunk Works: A Personal Memoir of My Years of Lockheed
> Ben R. Rich, Leo Janos
>
> To tak ogolnie na pemat projektowania.
>
> A tak powaznie, to model Kolegi pachnie mi "waterfall model". Tak sie
> od dawna nie robi. Programy sie raczej pisze iteracyjnie. Trudno od

zastanawiam skąd to się bierze, u początkujących (moje wrażenie sądząc
po początu wątku), w 21 wieku. Nauka ze starych podręczników? Procedura
do własnych studenckich projektów?


B.

do góry