Developer tools noodzakelijk?

[R.G]

Hey Allemaal en een Goede morgen.

Momenteel ben ik bezig met de opleiding Applicatie Ontwikkelaar op het roc van twente.
nu heb ik een nieuwe opdracht gekregen (soort van eindopdracht, niet de echte eindopdracht)
ik vraag niet jullie hulp voor het maken van de applicatie maar de voorbereiding.

ik ben bijvoorbeeld Visio spuugzat, vind het niet fijn werken.
voordat je begint met programmeren
ga je eerst met de klant praten (interviewen)
daarna ga je een use case bouwen.
daarna ga je een stroom diagram bouwen.
daarna ga je een database bouwen en testen.
daarna ga je de applicatie schrijven.
de opdracht bevindt zich hier:
*nietrelevant*

nu is mijn vraag:
weet iemand wat leuke programma's
waarmee ik gemakkelijk een stroom diagram,use cases en databases kan maken?

als mijn manier van aanpak fout is, wijs me op me fouten, dan leer ik daar van en maak ik ze niet weer in de toekomst

alvast bedankt voor jullie tijd

mvg R.G

[ Voor 2% gewijzigd door RobIII op 07-12-2010 09:49 ]

[RobIII]

En wat heb je zelf al gezocht/gevonden/etc? Waarom hanteer je onze Quickstart niet even? Verder zijn we hier niet vies van zo nu en dan een hoofdletter aan 't begin van een zin of wat interpuctie her-en-der om het verhaal wat leesbaarder te maken. Ook een enter na elke zin is onnodig; het forum zorgt zelf wel voor tekstomloop waar dat nodig is Oh, en het is wel handig als je topictitel een beetje strookt met je vraag in het topictitel:

Titel: Developer tools noodzakelijk?

R.G schreef op dinsdag 07 december 2010 @ 09:46:
nu is mijn vraag:
weet iemand wat leuke programma's
waarmee ik gemakkelijk een stroom diagram,use cases en databases kan maken?

Scheelt verwarring

[ Voor 75% gewijzigd door RobIII op 07-12-2010 09:56 ]

[R.G]

Hey Robll

was even bezig met een flowchart in paint
klopt wordt vaak gewezen op de spelling(punten,hoofdletters) , maakt dat zo veel uit?

Heb rond gezocht naar programma's maar de meesten kosten al meteen geld ( is ook wel logisch) maar toch.
waar maakt u gebruik van?

ik zal zo even de quickstart even doorlezen.

[AzzKickah]

R.G schreef op dinsdag 07 december 2010 @ 09:58:

klopt wordt vaak gewezen op de spelling(punten,hoofdletters) , maakt dat zo veel uit?

Op een medium waar de communicatie uitsluitend middels schrift geschiedt maakt dat vrij veel uit, ja.

Of vind jij het makkelijk om een verhaal zonder punten en kommas aan een stuk door te lezen zodat je zelf elke keer moet nadenken van goh hoe loopt die zin waar houdt die zin op waar begint de volgende en dat leid je weer af van het lezen moet je weer denken wordt het niet overzichtelijker op of vind je deze laatste zin van mijn post wel lekker handig weglezen zo zonder punten en kommas en andere leestekens ik niet namelijk en ik denk de rest van het forum ook niet jij wel?

[RobIII]

R.G schreef op dinsdag 07 december 2010 @ 09:58:
klopt wordt vaak gewezen op de spelling(punten,hoofdletters) , maakt dat zo veel uit?

Wat denk je zelf, als je er steeds op gewezen wordt?
Verder is het gewoon een kwestie van fatsoen; als je wil dat wij moeite voor je doen dan is het minst wat je kan doen zélf een beetje moeite te doen je topic (en reacties) leesbaar te maken. En onder die eigen moeite verstaan we dus ook een aantal andere zaken die beschreven staan in de Quickstart waar ik je al naar verwees

R.G schreef op dinsdag 07 december 2010 @ 09:58:
Heb rond gezocht naar programma's maar de meesten kosten al meteen geld (is ook wel logisch) maar toch.

Er zijn zat gratis en/of OS alternatieven maar als je geen specifieke eisen stelt/hebt dan wordt het nogal lastig om te beoordelen welke software voldoet aan je eisen, niet? "weet iemand wat leuke programma's" is dan ook geen nuttige/zinnige vraag. Stel een lijst van eisen, must-haves en nice-to-haves op en leg eventuele software die je vindt langs die lijst. De software die aan de meeste criteria voldoet is de winnaar. Simple as that. Lijkt wel Idols

Dan nog even dit: Ik heb net even door je programma-eisen gekeken; hoe verklaar je een eis als: 'dit alles in een leuke Database'?

[ Voor 14% gewijzigd door RobIII op 07-12-2010 10:05 ]

[Sv3n]

http://jude.change-vision...eb/product/community.html

Ik weet dat deze applicatie op sommige HBO's gebruikt wordt. Maar als je zoekt op UML tooling lijkt me dat je toch wel meer moet kunnen vinden?

[R.G]

update:
smartdraw 2010
edraw max10

[jip_86]

Ik ben zelf erg te spreken over software ideas modeler.
Gratis voor niet commercieel gebruik. Ontwikkelaar is behoorlijk actief. Als je een foutje aandraagt kan het zomaar de volgende week al opgelost zijn in een nieuwe versie. Suggesties voor verbeteringen word ook snel op gereageerd.
http://www.softwareideas.net/

[H!GHGuY]

Een goeie gratis tool voor UML is StarUML.
Databases zou je als static diagram kunnen modelleren.

[jip_86]

StarUML is ook een goede inderdaad. Daar word helaas niet echt meer wat aan gedaan.

[Zoijar]

Ik gebruikte altijd Rational Rose, maar ik heb geen idee of dat nog bestaat.

[leuk_he]

Een tool die begint bij de stroomdiagrammaen en tot de applicatie bouwen is Oracle designer (kun je voor opleiding wel gratis gebruiken)

Er zijn vast wel meer case tools te vinden waar het allemaal geintegreerd is.

Echter zo'n case tools heeft een stevige leercurve, en is ook niet in 10 minuten geinstalleerd. Want wellicht zit er aan je opdracht ook een tijdsbeperking. (zoniet, dan zou dat moeten, want in real live is dat wel degelijk een limiteerende factor.)

Dat geld voor de meeste betere tools die hier genoemd worden overigens.

[Avalaxy]

R.G schreef op dinsdag 07 december 2010 @ 09:46:

ga je eerst met de klant praten (interviewen)

Als het goed is is dat iets wat je regelmatig doet, en niet alleen aan het begin (aangenomen dat je een iterative software development techniek gebruikt zoals RUP.

Verder begrijp ik niet echt waar je heen wilt... Je wilt een goede gratis UML tool hebben?

[Verwijderd]

Vorig jaar gebruikte ik hier StarUml voor. Het programma is ook modulair. Dus als je bepaalde functies mist kan je even kijken bij extensions ofzo

[R.G]

Hey Allemaal

top jullie reacties, ga meteen even kijken, ben net thuis
ik heb voor de opdracht max 10 weken, ben net maandag begonnen.
het eindresultaat laat ik natuurlijk zien

ik heb dit nog gevonden
een online flowchart maker http://www.drawanywhere.com/ (werkt leuk )

zijn jullie allemaal applicatie ontwikkelaars?
zijn jullie het niet zat om elke dag weer code in te kloppen?


geen idee, of ik dit wil gaan doen als fulltime job
denk het wel

[Avalaxy]

Ik snap het niet helemaal goed... Je bent bijna klaar met je opleiding als 'applicatie ontwikkelaar' maar je hebt eigenlijk geen flauw benul waar je het over hebt

[leuk_he]

Avalaxy schreef op dinsdag 07 december 2010 @ 17:23:
Ik snap het niet helemaal goed... Je bent bijna klaar met je opleiding als 'applicatie ontwikkelaar' maar je hebt eigenlijk geen flauw benul waar je het over hebt

http://www.roc.nl/default.php?fr=details&id=835

is toch 2 tot 4 jaar..

[u_nix_we_all]

De tools waar jij om vraagt kunnen je helpen met je werk, maar gaan het werk niet voor je doen, ze kunnen je slechts ondersteunen. Ik denk dat je het meeste leert door niet direct op zoek te gaan naar tools, begin eens met e.e.a. op een kladblok te doen.

Verder vind ik het eigenlijk vrij bot om het toch nog te presteren een post te maken waarin vrijwel alle hoofdletters ontbreken. Als jij die moeite niet wilt doen, is het vrij bot om van anderen te verwachten wel moeite voor jou te doen.

[RobIII]

R.G schreef op dinsdag 07 december 2010 @ 17:13:

Wat was hier niet duidelijk aan:

RobIII schreef op dinsdag 07 december 2010 @ 10:02:
Verder is het gewoon een kwestie van fatsoen; als je wil dat wij moeite voor je doen dan is het minst wat je kan doen zélf een beetje moeite te doen je topic (en reacties) leesbaar te maken. En onder die eigen moeite verstaan we dus ook een aantal andere zaken die beschreven staan in de Quickstart waar ik je al naar verwees

Wil je, nogmaals, dus even op je poststijl letten?

R.G schreef op dinsdag 07 december 2010 @ 17:13:
zijn jullie allemaal applicatie ontwikkelaars?

Ja, alle 150.000+ gebruikers op dit forum ja...

R.G schreef op dinsdag 07 december 2010 @ 17:13:
zijn jullie het niet zat om elke dag weer code in te kloppen?

Iedereen is het wel eens zat. Dat heb je als pizzabakker of burgerflipper of advocaat of hersenchirurg ook. En als je het vaak genoeg zat bent moet je eens gaan kijken naar een andere carrière. Het feit dat je 't al beu bent (of impliceert te zijn) nog voordat je überhaupt begonnen bent aan je carrière betekent weinig goeds... En dan sluit ik me aan bij:

u_nix_we_all schreef op dinsdag 07 december 2010 @ 17:34:
De tools waar jij om vraagt kunnen je helpen met je werk, maar gaan het werk niet voor je doen, ze kunnen je slechts ondersteunen.

Als je denkt met sleuren-en-pleuren jezelf Applicatie Ontwikkelaar te kunnen / mogen noemen dan heb je 't (wat mij betreft althans) behoorlijk mis.

[ Voor 48% gewijzigd door RobIII op 07-12-2010 18:49 ]

[R.G]

Hey

Ehm deze opleiding kon je in 1 jaar doen als je al van programmeren af wist.
Ik probeer er nu 2 jaar over te doen?

@ avalazy , waar heb ik gezegd dat ik bijna klaar ben??

zelf moet ik nog 3 grote opdrachten hoor
dit is er 1 van.
en natuurlijk toetsen en andere vakken..

mvg R.G

[iBasch]

Op de hogeschool Leiden gebruiken wij Visual Paradigm. Geloof dat er een gratis community (non-commercial) edition is, maar ik gebruik de hogeschool-licentie.
Ik zou gewoon verschillende dingen uitproberen, kijk wat voor jou het lekkerst werkt.

[R.G]

Hey

Momenteel maak ik gebruik van dit:http://www.drawanywhere.com/

Het is online , werkt snel en het wordt voor je bewaard, dus overal waar je internet acces hebt, kan je bij je charts, het is ook nog gratis

Ik ga zeker weten ook kijken naar de tools die jullie me sturen

Bedankt

mvg R.G

[Killemov]

R.G schreef op dinsdag 07 december 2010 @ 09:46:
...
voordat je begint met programmeren
ga je eerst met de klant praten (interviewen)
daarna ga je een use case bouwen.
daarna ga je een stroom diagram bouwen.
daarna ga je een database bouwen en testen.
daarna ga je de applicatie schrijven.
de opdracht bevindt zich hier:
[mbr]*nietrelevant*[/mbr]
...

Dit is een zeer formele, stricte en rigide manier van software ontwikkelen. Dit is ook precies waarom grote projecten voor met name de (semi-)overheid ofwel vreselijk over het budget gaan of op 80% compleet alsnog worden gekilled. Er moet een aanbesteding worden geschreven en vervolgens komen zowel de opdrachtgever als de aannemer in een spagaat over kosten en specificaties. De opdrachtgever bedoelt vaak iets ruimer en de aannemer interpreteert meestal nauwer. Ruimte om te schakelen is er nauwelijks

Het is niet voor niets dat er zoveel mogelijkheden voor rapid prototyping zijn. (Gebruikte persoonlijk vaak Delphi en tegenwoordig Eclipse + Jigloo + ... of html.) In de basis even snel wat schermpjes en een databeestje in elkaar draaien om vervolgens met betrokken personen binnen de organisatie van de opdrachtgever wat te sparren over de applicatie werkt naar mijn ervaring veel efficienter. Men heeft het vaak over creeren van draagvlak voor de uitrol van een applicatie. Hoe kun je die beter krijgen dan door de eindgebruikers inspraak te geven tijdens het ontwikkelingsproces?

Uiteraard ligt het toch wel iets genuanceerder als er geld (transacties) of levens (kerncentrale, hartbewaking) met de applicatie gemoeid zijn. Maar dan nog kan ervoor worden gekozen om alleen kleine doch cruciale delen helemaal uit te specificeren ipv het geheel.

[CodeCaster]

Killemov schreef op woensdag 08 december 2010 @ 00:12:
[...]

Dit is een zeer formele, stricte en rigide manier van software ontwikkelen. Dit is ook precies waarom grote projecten voor met name de (semi-)overheid ofwel vreselijk over het budget gaan of op 80% compleet alsnog worden gekilled. Er moet een aanbesteding worden geschreven en vervolgens komen zowel de opdrachtgever als de aannemer in een spagaat over kosten en specificaties. De opdrachtgever bedoelt vaak iets ruimer en de aannemer interpreteert meestal nauwer. Ruimte om te schakelen is er nauwelijks

Het is niet voor niets dat er zoveel mogelijkheden voor rapid prototyping zijn. (Gebruikte persoonlijk vaak Delphi en tegenwoordig Eclipse + Jigloo + ... of html.) In de basis even snel wat schermpjes en een databeestje in elkaar draaien om vervolgens met betrokken personen binnen de organisatie van de opdrachtgever wat te sparren over de applicatie werkt naar mijn ervaring veel efficienter. Men heeft het vaak over creeren van draagvlak voor de uitrol van een applicatie. Hoe kun je die beter krijgen dan door de eindgebruikers inspraak te geven tijdens het ontwikkelingsproces?

Uiteraard ligt het toch wel iets genuanceerder als er geld (transacties) of levens (kerncentrale, hartbewaking) met de applicatie gemoeid zijn. Maar dan nog kan ervoor worden gekozen om alleen kleine doch cruciale delen helemaal uit te specificeren ipv het geheel.

Zo zwart-wit is het natuurlijk niet. Bij een gemiddeld CMS in PHP kun je nog bakkeleien met de opdrachtgever of de nieuwsbriefmodule nog binnen het budget valt, maar als je een administratief systeem gaat bouwen kun je maar beter vooraf precies bepalen wat je gaat maken.

[Exirion]

CodeCaster schreef op woensdag 08 december 2010 @ 00:21:
Zo zwart-wit is het natuurlijk niet. Bij een gemiddeld CMS in PHP kun je nog bakkeleien met de opdrachtgever of de nieuwsbriefmodule nog binnen het budget valt, maar als je een administratief systeem gaat bouwen kun je maar beter vooraf precies bepalen wat je gaat maken.

Wat hij waarschijnlijk bedoelt is dat dit "development by the book" is. Zoals je alles uit boekjes eerst moet leren en het vervolgens in de praktijk nooit meer letterlijk zo zal doen.

De best ideeen worden op bierviltjes geschetst en kort uitgewerkt waarbij een paar ervaren collega's aan een half woord genoeg hebben om elkaar te begrijpen. Mensen die lerende zijn, en zoeken naar de magische tool die al het werk uit handen neemt, zijn verkeerd bezig.

[FragFrog]

Killemov schreef op woensdag 08 december 2010 @ 00:12:
Dit is een zeer formele, stricte en rigide manier van software ontwikkelen. Dit is ook precies waarom grote projecten voor met name de (semi-)overheid ofwel vreselijk over het budget gaan of op 80% compleet alsnog worden gekilled.

Pardon? Nee, bedrijven die dat niet doen zijn daar juist de oorzaak van. Zoals al gezegd kun je bij een min of meer kant-en-klaar CMS nog wel een extra module erin gooien, maar bij grote projecten kun je niet vooraf zeggen "ja we gaan wel bouwen, en zodra je opmerkingen hebt hoor ik het wel". Als je niet vooraf precies helder hebt wat er moet komen krijg je een niet te onderhouden organische bende aan code (hoe vaker een onderdeel aangepast wordt hoe slechter de kwaliteit doorgaans door alle hacks etc die erin geplaatst zijn - en tijd om het volledig te herschrijven is er in de praktijk nooit).

De reden waarom die projecten vervolgens gigantisch uitlopen en belachelijk duur worden is dat er continue vanaf de opdrachtgever op- en aanmerkingen komen waardoor het product nooit af is. En dan begint het gedonder wie die aanpassingen moet betalen. Natuurlijk, voor kleine onderdelen wil het prima werken om snel een prototype in elkaar te flansen, wat screenies te fabriceren en eens met de klant om de tafel te gaan of dat ongeveer was wat hij wilde. Maar op die basis kun je geen grote projecten aannemen. Heb al eens voor een bedrijf gewerkt wat failliet ging omdat hun voornaamste opdrachtgever op die manier binnengehaald was en een project van een half jaar uiteindelijk anderhalf jaar heeft gekost - zonder extra betaling - omdat alles origineel veel en veel te vaag omschreven was.

[Killemov]

FragFrog schreef op woensdag 08 december 2010 @ 02:27:
...
Als je niet vooraf precies helder hebt wat er moet komen krijg je een niet te onderhouden organische bende aan code.
...
De reden waarom die projecten vervolgens gigantisch uitlopen en belachelijk duur worden is dat er continue vanaf de opdrachtgever op- en aanmerkingen komen waardoor het product nooit af is.
...

Dus wordt er eerst helemaal tot in den treure gespecificeerd (aanbesteding + offertes!) om vervolgens TOCH van de specificatie af te wijken (uitloop + vergaderingen + betalingskwesties). En "volgens het boekje" dus geen mogelijkheden om te schakelen.

Verder mag de overheid zeer terughoudend worden wat betreft megalomane IT projecten en zou er meer met COTS producten gewerkt moeten worden. Goed voorbeeld voor beide argumenten: De OV-Chipkaart. Een systeem dat op vele plaatsen al succesvol in gebruik is en dat wij, Hollanders, dachten wel eens even beter te kunnen implementeren.

Het zuigt natuurlijk dat de toko waar je voor werkt failliet gaat omdat er geen goede afspraken zijn gemaakt. Een flexibel doel voor een fixed price gaat maar zelden werken. Ik heb persoonlijk meer ervaring met hoe het fout kan lopen als er wel strict volgens het watervalmodel wordt ontwikkeld.

Op een komische noot (Dat is mijn ding), ter illustratie: Treeswing

[R.G]

Hey Allemaal

ten eerste: " wow wat een info"
bedankt ik vind het interessant

ten 2e hier misschien vind iemand het leuk.
je mag het beoordelen het is nog een klad versie wordt beter en een beginnetje?
*laat het beoordelen van je huiswerk maar aan je leraar over

mvg R.G

[ Voor 20% gewijzigd door RobIII op 08-12-2010 13:38 ]

[FragFrog]

Killemov schreef op woensdag 08 december 2010 @ 04:15:
Dus wordt er eerst helemaal tot in den treure gespecificeerd (aanbesteding + offertes!) om vervolgens TOCH van de specificatie af te wijken (uitloop + vergaderingen + betalingskwesties). En "volgens het boekje" dus geen mogelijkheden om te schakelen.

Tja, dat het gebeurt wil ik best geloven, maar dat is eerder de schuld van het bedrijf wat het implementeert. Juist daarom zijn uitgebreide en correcte specificaties belangrijk: dan heb je een stok achter de deur om te zeggen: nee, dit zit niet bij de originele factuur in en als je het wel wilt komt dat na de eerste oplevering.

Daarmee wil ik niet beweren dat je ook tijdens het ontwikkelproces niet flexibel moet zijn, en als iets ook op een betere manier opgelost kan worden, al kost het wat meer tijd, moet dat ook mogelijk zijn. Maar je voorkomt een hoop gezeur achteraf door goed voorbereid te zijn voor je daadwerkelijk begint met ontwikkelen.

Zo zat ik recentelijk bij een bedrijf wat ook applicaties maakt voor de overheid, voordat ik ook maar een letter code geschreven had was er precies duidelijk wat er gebouwd ging worden, TO's en FO's goedgekeurd, etc. Producten werden daar nagenoeg altijd op tijd en binnen budget afgeleverd. Dat alle overheidsprojecten falen is dan ook een grote overdrijving - je hoort het natuurlijk ook alleen als het fout is gegaan, niet als het goed gaat

[RobIII]

R.G schreef op woensdag 08 december 2010 @ 12:13:
Hey Allemaal

ten eerste: " wow wat een info"
bedankt ik vind het interessant

ten 2e hier misschien vind iemand het leuk.
je mag het beoordelen het is nog een klad versie wordt beter en een beginnetje?
*laat het beoordelen van je huiswerk maar aan je leraar over

mvg R.G

Ik heb je nu vaak genoeg op je schrijfstijl gewezen. Als jij die kleine moeite niet eens wil nemen zie ik niet waarom wij nog moeite in jouw topic moeten steken. Daarbij gaan wij je huiswerk niet nakijken; dat mag je leraar doen.

[ Voor 5% gewijzigd door RobIII op 08-12-2010 13:41 ]