Inventarisatie systemen & applicaties, een methode?

[Mujo]

Ik heb de opdracht om een kleine inventarisatie te doen van de applicaties + systemen bij een
bedrijf. Hieronder vallen bijvoorbeeld:

- een klantapplicatie (CRM)
- een alarmmeldingen applicatie + systeem
- een personeelsadministratie applicatie
- een webshop
- portal (SharePoint) en natuurlijk
- database (MS SQL)

Nu wil ik een gerichte methodiek gaan gebruiken om het hele boeltje in kaart te gaan brengen.
Ik heb gekeken naar IEEE standaarden, maar dat is me erg vaag.

Verder ben ik door een vriend gewezen op een aantal onderdelen van OpenUP (community afgeleide
van Rational Unified Processing/RUP).

Waarmee hebben jullie ervaring en kunnen jullie me adviseren in deze?

[Janoz]

Wat ik niet begrijp is hoe je een software ontwikkelingsproces techniek denkt in te zetten bij de inventarisatie van een bestaande inrichting.

[Mujo]

Janoz schreef op vrijdag 12 oktober 2007 @ 10:35:
Wat ik niet begrijp is hoe je een software ontwikkelingsproces techniek denkt in te zetten bij de inventarisatie van een bestaande inrichting.

Ik vermoedde al dat hier opmerkingen over zouden komen. Ik werd dus inderdaad gewezen op
enkele onderdelen van OpenUP (waaronder dus het opstellen van specificaties & vereisten). Nou heb ik dat bekeken, maar het is inderdaad gewoon bedoeld voor applicatieontwikkeling en wat ik zoek is een methode om te inventariseren (hoe heet het, wat doet het en hoe is dit gestructureerd) en functionele/technische eisen op te stellen.

Herstel: welke beproefde methode kunnen jullie mij adviseren voor een invetarisatietraject?

[ Voor 7% gewijzigd door Mujo op 12-10-2007 11:27 ]

[Verwijderd]

Ik denk dat het ook uitmaakt WAT je precies in kaart wilt brengen. Wil je de datastromen in kaart brengen? Of wil je alleen uit systeembeheer oogpunt kijken welke servers je draait... Wat is het DOEL van je inventarisatie, dan kom je denk ik al een heel eind.

Als ik een beetje mag gokken zou ik kiezen voor een deployment diagram. Hiermee modelleer je welke componenten je in je totale systeem hebt (het lijstje dat je noemt), en op welke hardware dit draait. Ook geef je dmv lijnen/pijlen aan welke systemen afhankelijk zijn van elkaar.

[Mujo]

Dat lijkt er inderdaad op ja.
- Wat doen de afzonderlijke applicaties (wat moeten ze doen/functioneel/door wie).
- Wat vereisen de applicaties (requirements)
- Van welke andere applicaties zijn de afhankeling (bijv. SQL)
- Hoe ziet de structuur uit per applicatie (databasevelden, naam, type)
- Welke applicaties dienen uiteindelijk met elkaar te kunnen communiceren en hoe

Doel van de inventarisatie (fase1) is om dus per applicatie te weten te komen wat het is, wat het nu doet,
wat het straks moet doen (al dan niet in combinatie met de andere software) en hoe dit vorm gegeven
kan worden (fase 2, de boel aan elkaar knopen)

/edit: ik ga me sowieso even verder verdiepen in dat Deployment Diagram

[ Voor 30% gewijzigd door Mujo op 12-10-2007 13:19 ]

[Verwijderd]

Als ik zo zie wat je allemaal opsomt kom je er inderdaad niet met één type diagram. Op zich is het wel aan te raden een boek over UML erbij te pakken, of google, of wat dan ook.
Volgens mij is de strekking van je opdracht dat je de boel moet integreren op de een of andere manier. Dit is in mijn ogen weldegelijk een soort van software ontwikkeling, alleen zal je niet heel veel hoeven programmeren (omdat je de meeste componenten al hebt). Je kan dus best naar RUP of OpenUP kijken om het proces van detaillering er uit te vissen.

Aangezien je ook moet modelleren welke handelingen er precies gedaan kunnen worden (en door wie) zou ik vanuit UML oogpunt ook een use-case diagram aanraden. Op wikipedia staat onder UML een hele hoop over welke diagrammen je waarvoor het beste kunt gebruiken.

In 't kort: staar je niet blind op één soort diagram of techniek, sommige 'fases' in je model vereisen gewoon een andere view op het systeem

[Mujo]

Bedankt Tedkees. UML is al weer even geleden voor me, maar use-cases en sequence diagrams zijn mij niet vreemd.
Dat OpenUP stukje over detaillering moet ik verder uitspitten.

[MisterBlue]

Zoals ik het zie heb je methodiek min of meer al: hoe heet het, wat doet het en hoe is dit gestructureerd? Gewoon een paar vragen beantwoorden en in een tabel plaatsen.

Ik zou echter wel de vragen vanuit de gebruiker stellen:
- wie gebruikt het
- en waarvoor

Dan krijg je in wezen een use cases, maar ik zou me in het begin niet teveel op diagrammen e.d. focussen. Als je tabelletje hebt ingevuld of aan het invullen bent kom je waarschijnlijk tot betere inzichten over hoe je het verder kan structureren, wat je nog meer wilt toevoegen.

Let ook op wie het gaat lezen. Je kunt wel een deployment diagram maken maar als de lezer het niet begrijpt heb je alleen een communicatie barriere opgeworpen.

[Mujo]

MisterBlue schreef op zaterdag 13 oktober 2007 @ 17:45:
Zoals ik het zie heb je methodiek min of meer al: hoe heet het, wat doet het en hoe is dit gestructureerd? Gewoon een paar vragen beantwoorden en in een tabel plaatsen.

Ik zou echter wel de vragen vanuit de gebruiker stellen:
- wie gebruikt het
- en waarvoor

Dan krijg je in wezen een use cases, maar ik zou me in het begin niet teveel op diagrammen e.d. focussen. Als je tabelletje hebt ingevuld of aan het invullen bent kom je waarschijnlijk tot betere inzichten over hoe je het verder kan structureren, wat je nog meer wilt toevoegen.

Let ook op wie het gaat lezen. Je kunt wel een deployment diagram maken maar als de lezer het niet begrijpt heb je alleen een communicatie barriere opgeworpen.

Hmm, dat laatste is zeker waar. Bedankt.