Power Designer 15 : Now in Beta

I'm a great fan of system modelling, and therefore I am a great fan of a good system modeling tool.
Among the best imho. is PowerDesigner from Sybase and now its out in its most recent and 15th edition which is out there available in the first public Beta.

Check it out:
http://www.sybase.com/detail?id=1056477

Adobe "Thermo"

Both before and after Adobe MAX Europe 2007 we have discussed which role Thermo is going to play in the integration between the graphics department and the development department.
To clarify a couple of things Narciso Jaramillo has posted some of his thoughts on his blog which are worth reading if interested in the emergence of Thermo.

Check it out:
http://www.rictus.com/muchado/2007/10/07/thoughts-on-thermo/

Note:
Narciso is part of the Adobe Flex Team.

Adobe "Thermo"

Adobe's upcoming new design tool, codenamed "Thermo" enables designers and developers to create working application prototypes, design application transitions/motion, and transform static UI mockups into declarative MXML source.

Adobe Thermo:
http://labs.adobe.com/wiki/index.php/Thermo

The Daily Motivator : 10 Ways for a Web Worker to Achieve Work-Life Balance

Som en af de der hyppigt ligger i toppen af den ugentlige inddaterings-summering i det firma jeg er tilknyttet tager jeg mig den frihed at dele denne artikel med jer.

Det er helt almindelig viden, men da det efterhånden er påvist udover nogen tvivl at produktiviteten (for slet ikke at nævne livskvaliteten) sænkes såfremt man glemmer at udøve fysisk udfoldelse samt at have et ikke-arbejdsrelateret liv gør det vel ikke noget at minde os selv og hinanden om det en gang imellem.

http://webworkerdaily.com/2007/09/14/10-ways-for-a-web-worker-to-achieve-work-life-balance/

Indhold i en af vores standard RUP iterationer

Nedenstående er det overordnede format for iterationer vi arbejder med på et RUP projekt.

1. Assessment og eventuel tilpasning af processen.
2. Vurdering af use cases fra foregående iteration om de skal videreimplementeres i denne implementation.
3. Planlægning af iteration.
4. Implementation af eventuelle kritiske rester fra foregående iteration.
5. Implementation af use cases for iteration.
6. Etablering af baseline (executable, codebase og database ).
7. Review af iterationens resultater.
8. Opdatering af prioriteter samt krav baseret på resultatet af review.

Vi arbejder fortrinsvist med iterationer af 2 ugers varighed og vi oplever at ovenstående giver en god sammenhæng i en iteration og 2 ugers iterationerne giver en gunstig rytme på vores projekter.

Strategi for Test

Jeg kunne godt ønske mig (og jeg kunne faktisk også forestille mig at det kunne være formålstjenligt) at få nogle faste rutiner lagt ind i den løbende test-disciplin...
Det kunne måske være noget i stil med:

1. Funktions test (Med udgangspunkt i de funktionelle krav testes systemet fra brugerens perspektiv).
2. Sikkerheds test (test af systemet udfra de konkret definerede krav til sikkerhed for det enkelte system såfremt der er specielle hensyn og så selvfølgelig de helt almindelige krav der er til den givne applikationstype (For en generel webapplication: SQL-Injection, URL-modification, osv)).
3. Load test (der bekræfter at systemet understøtter de lovede load).

Tilbage ville så være følgende test, der i så fald kunne afvikles som en del af den afsluttende transition:

1. Chrash-Recovery-Continue test (Test af hvilken load-belastning der bringer systemet i knæ, hvilken tilstand systemet er i når crashet er sket samt om systemet kommer til sig selv igen og hvis ikke, hvilke handlinger der kræves for at bringe systemet tilbage i drift).

Afslutningvist ville kunden derefter forestå afvikling af en accept-test, som egentlig bare ville indeholde samtlige ovenstående test. Denne accepttest ville derfor være en ren formssag da de allerede var blevet afviklet under det forudgående udviklingsforløb.

Afslutningsvist for denne email vil jeg lige dele nogle af mine premisser for de ovenstående tanker:
• En test-strategi (uanset sin udformning og indhold) er et must-have for ethvert projekt !
• Samtlige test-former kan med den forhåndværende tool-support automatiseres (ja, sågar funktionstest bliver efterhånden med stor fordel automatiseret).
• Der er en absolut og direkte sammenhæng mellem kvaliteten af test og kundens tilfredshed. Denne sammenhæng korresponderes af kvaliteten af systemet (systemets levedygtighed, systemets vedligeholdelses-dygtighed, osv).
• Test betragftes som en overvejende regressiv aktivtet og derfor ikke-kreativt hvilket er med til at gøre det til en uattraktiv disciplin blandt de fleste mennesker. Dette er ikke sandt, testing kan sagtens gøres kreativt.
• Test giver frihed til kreativitet da man ikke er nødt til at basere sine beslutninger på antagelser (antagelser har det med at være forkerte).
• Der er meget få mennesker der synes det er interessant at teste, men at de trods alt findes, Denne type udvikler/projektmand er uundværlig og personer vi skal lede konkret efter i forbindelse med optagelse af nye medarbejdere, eller alternativt selv skabe i egne rækker ved feks. at automatisere test-aktiviteterne og derved gøre det mere attraktivt at give test-discplinen noget opmærksomhed.
• Test af et system er det eneste eksisterende synonym for at et system beviseligt virker. Da den videnskabelige metode i sin grundform er baseret på (lettere simplificeret og omskrevet til formålet): ide --> eksperimentering --> vurdering --> konklusion betyder det at vi uden test arbejder i modstrid med den videnskabelige metodes grundtese og derfor i modstrid med stamfaderen til alle best practice’s og alle moderne processer samt metoder... imho. ikke en særlig god ide :-)

This post was published to The Cynical Corner at 11:27:19 31-08-2007