Analyses

Gebruik de 522 IT checklisten van ITpedia, met in totaal 22028 vragen.

Zoek in de omschrijvingenOmschrijvingAantal vragen
IT projectfaseringBestaat uit meerdere checklisten
Application Services Library (ASL)Bestaat uit meerdere checklisten
ContinuïteitBestaat uit meerdere checklisten
KwaliteitsattributenBestaat uit meerdere checklisten
Functies in de automatiseringBestaat uit meerdere checklisten
WebdesignBestaat uit meerdere checklisten
Of zoek naar een woord: Fulltekst

Laatst gebruikt: Rapportage acceptatietest op: 2017-02-25 17:12 Checklist
Toezenden van eerdere beoordelingen per e-mail.
E-mailadres:

SISp 2.1 De requirements fase

Inleiding requirements fase Nu het projectplan definitief is starten we in SISp2 met het vaststellen van de exacte eisen en wensen die aan het standaard software pakket worden gesteld. In deze fase zullen de eisen en wensen van zowel de opdrachtgever als alle verdere belanghebbende,  ondubbelzinnig worden beschreven. Deze eisen en wensen worden ook wel requirements […]

Van Wim Hoogenraad op 19 december 2016 | Analyses, Methoden | Aanvullen?
Tags:,
Checklisten: Geen

Is het strafbaar om je systeem slecht te beveiligen?

Vraag: Het is strafbaar om binnen te dringen in een geautomatiseerd werk, zoals een computer of een netwerk. Maar is het ook strafbaar om je systeem slecht te beveiligen zodat het onnodig makkelijk is voor anderen om binnen te dringen? Antwoord: Nee, dat is niet strafbaar. Binnendringen is strafbaar, net als het vernielen van gegevens […]

Van Arnoud Engelfriet op 21 januari 2014 | Analyses, Juridisch | Aanvullen?
Tags:,
Checklisten: 4

De snelste methode om te profiteren van een Enterprise Social Network

Als de organisatie het idee heeft opgevat om een sociaal netwerk in de zetten voor alle interne en externe communicatie, hoe ga je dat aanpakken? In een eerder artikel hebben we aangegeven dat we een roadmap hebben opgesteld als een plan van aanpak, welke elementen van belang zijn voor een succesvolle implementatie van een Enterprise […]

Van Pointer Networks op 30 maart 2013 | Analyses, Methoden, Organisatie | Aanvullen?
Tags:,
Checklisten: Geen

Wie heeft er ervaring met standaard software?

Tot nu toe is er nog geen artikel over standaard software op ITpedia verschenen. Het wordt de hoogste tijd dat we eens wat aandacht aan dit onderwerp schenken. Voor we hier over een artikel gaan schrijven willen we graag eerst uw ervaringen met de selectie en implementatie van standaard software verzamelen. Daarom hebben we een kleine […]

Van Wim Hoogenraad op 17 december 2012 | Analyses, ITpedia | Aanvullen?
Tags:,
Checklisten: Geen

Informatiebeveiliging verbetert niet door een ISMS

Veel organisaties zuchten onder de last van hun informatiebeveiliging. Het Information Security Management Systeem (ISMS) is, met name bij ISO 27001 en NEN 7510, vaak de heilige graal en vergaande bureaucratie zijn dienaar. Op het gebied van information security management wordt echter helaas meestal te veel gedaan. Een eenvoudige situatie vereist een eenvoudige oplossing. Maar […]

Social intranet: organisatiecultuur grootste uitdaging

Door Floor van Riet van Sabel Online Integratie van social media op intranet was dé trend van 2010. Maar ondanks veel geëxperimenteer, zijn er geen grote doorbraken gemeld. Sterker nog, 2011 was het jaar van de stilstand. Dit jaar willen veel organisaties investeren in interne socialmediatoepassingen. Wat kunnen ze dan het beste doen? In dit […]

10 tips om usability te borgen in agile projecten

Enige tijd geleden is een verkenning gedaan naar de impact van een agile projectaanpak op usability c.q. user experience. Een belangrijke conclusie was dat agile werken, gegeven de juiste omstandigheden, kansen biedt om op een andere manier dan gebruikelijk usability te waarborgen. Dit vergt natuurlijk wel een omschakeling van de gemiddelde user experience designer. Gelukkig wijst Jeff Patton de […]

Van administrator op 27 maart 2012 | Adviezen, Analyses, Methoden, Technieken | Aanvullen?
Tags:, ,
Checklisten: 2

Rechtsgeldigheid van e-mail

Héél, héél veel vragen krijg ik over de rechtsgeldigheid van e-mail. Die variëren van “heb ik een contract als er in e-mail ‘akkoord’ staat” tot “kan ik met deze e-mail aangifte doen van bedreiging/stalking/smaad”. Nou, heel kort: ja, e-mail is rechtsgeldig – behalve in een paar uitzonderlijke gevallen. En, als ik zo vrij mag zijn, […]

Van Arnoud Engelfriet op 27 februari 2012 | Analyses, Juridisch | Aanvullen?
Tags:,
Checklisten: Geen

Top 11 van de grootste vertragers van ICT projecten

In dit artikel staan de 11 grootste factoren van vertraging van projecten beschreven. Voor een uitgebreide analyse van deze en andere vertragingsfactoren zie McConnell en Goldratt (McConnell, 1996, Goldratt, 2002). Functionaliteitenaanwas Functionaliteiten aanwas is het fenomeen dat naarmate het project vordert, er steeds nieuwe functionaliteiten bij bedacht en gevraagd worden. Hierdoor komt de software nooit […]

Van administrator op 13 februari 2012 | Achtergronden, Analyses, Knelpunten | Aanvullen?
Tags:,
Checklisten: 3

Waterval versus cyclisch projectmanagement

Het 6-fasenmodel is een watervalmodel. Dat wil zeggen dat de fases na elkaar plaatsvinden. Net zoals je niet omhoog kan zwemmen tegen een waterval in, kan je in het pure watervalmodel na het doorlopen van een fase ook niet meer terug. Het is niet wenselijk als in de realisatiefase besloten wordt om het ontwerp aan […]

De zes fasen van een project

Project organisatie

Het model dat hier besproken wordt, vormt de basis voor veel projectmanagementmethodes. In latere hoofdstukken zal nader ingegaan worden op een model dat speciaal geschikt is voor ICT gerelateerde projecten. Om een project in zo goed mogelijke banen te leiden, is het nuttig het project op te delen in fasen. Door het faseren van het […]

Combi`s van gesloten en open software

Door: Fred Teunissen De werelden van Microsoft en andere aanbieders van ‘gesloten’ software en die van Linux en open source applicaties staan niet meer zo lijnrecht tegenover elkaar als een tijdje geleden. Er kunnen nu bruggen worden geslagen. Door combinaties te maken van open en gesloten software kunt u twee vliegen in één klap slaan: […]

Van administrator op 27 december 2011 | Adviezen, Analyses | Aanvullen?
Tags:, , ,
Checklisten: 3

De business bepaalt de ict-strategie

‘Zij die goed zijn in de uitvoering van een strategie’, schreef de Chinese filosoof Sun Tzu, ‘buigen de strategieën van anderen probleemloos om.’ Dit fundamentele principe verklaart mede waarom sommige CIO’s meer succes hebben dan anderen in het uitvoeren van strategie. De tijden dat de ict-afdeling het monopolie had op de ict van de organisatie […]

Van administrator op 12 december 2011 | Achtergronden, Analyses | Aanvullen?
Tags:,
Checklisten: 3

Gevolgen van slecht management bij offshore software ontwikkeling

Onervaren? management bij offshore? software ontwikkeling Succes van offshore outsourcing gebonden aan offshore management capaciteiten Bij het overhevelen van bedrijfsactiviteiten en -onderdelen naar lage lonen landen rekent men zich al snel rijk. Anderzijds schrikt men terug voor de complexe problemen en impact die offshore IT outsourcing heeft op de gehele organisatie. Gemis aan ervaring bij offshore management […]

Van administrator op 28 november 2011 | Analyses, Knelpunten | 4 aanvullingen
Tags:, ,
Checklisten: 2

SISp 2.2 Soorten requirements

In de SISp methode verdelen we de requirements in een aantal categorieën.  Deze categorieën hebben we nodig om later een goede keuze te kunnen maken.

De categorieën:

* Business requirements,
De wens van de organisatie is de start van het project. Definieer deze wens(en) duidelijk en ondubbelzinnig.

* User requirements,
Welke wensen heeft de gebruikersorganisatie, de mensen die er echt mee moeten werken, t.a.v. het systeem.  Deze wensen zullen een stuk gedetailleerder zijn dan de business wensen. Wat moet het systeem precies doen en wat moeten de gebruikers er mee kunnen.

* Software requirements,
De software requirements gaan dieper in op de user requirements en worden opgedeeld in functionele en niet functionele eisen.

* Technische randvoorwaarden
Aan welke eisen moet het systeem voldoen. Moet het kunnen draaien op een bepaald platform, gebruik maken van een specifieke database  of communiceren via bepaalde protocollen? Software requirements omvatten de technische kaders van dit project.
Zorg ervoor dat je bij het vastleggen van de requirements onderscheid maakt tussen deze categorieën.

Business requirements

Bij het vaststellen van de business requirements gaan we opzoek naar de doelstellingen die de opdrachtgever, de business heeft gedefinieerd.
De business requirements zijn richtinggevend. Ze beantwoorden de vraag welk doel het aan te schaffen pakket moet invullen.
Voorbeelden hiervan zijn;
* Alle medewerkers willen toegang hebben tot actuele relatiegegevens (hogere efficiëntie)
* Management wil dat klanten zelf bestellingen via de webshop kunnen doen (minder doorlooptijd, tevreden klanten)
* Management wil dat inkomende post niet meer kwijt raakt (minder risico, hogere omzet)

User requirements

De user requirements zeggen iets over wat de gebruiker met het system moet kunnen doen. De activiteiten en processen die de gebruikers met het pakket moeten uitvoeren. Veel user requirements kunnen worden geput uit procesbeschrijvingen en werkinstructies.
Voorbeelden van user requirements zijn;
* Kan relatiegegevens ophalen uit relatiesysteem en overnemen in een document
* Het poststuk moet gelokaliseerd kunnen worden met behulp van statussen.
* Het systeem moet een management informatie genereren.
* Het systeem moet een ontvangstbevestiging mailen aan de klant die een bestelling heeft gedaan.
Het is van belang dat iedere user requirement te herleiden is naar een business requirement. Is dat niet zo, dan is het geen requirement.

Software requirements

De software requirements gaan in op details.  Ze beschrijven ondubbelzinnig wat het systeem moet kunnen doen.  Deze requirements zijn bij software ontwikkeling nog veel gedetailleerder, in de context van de SISp methode, dus bij de selectie van een standaardpakket kan worden volstaan met globalere beschrijvingen van de software requirements. We hoeven niet in te gaan attribuut beschrijvingen en datastructuren. Deze zijn immers al in het pakket aanwezig en hoeven niet geprogrammeerd te worden.
Bij het vastleggen van de software requirements is het van belang onderscheid te maken tussen functionele en niet functionele requirements.

Functionele requirements

Functionele requirements beschrijven de concrete functies die een systeem moet kunnen uitvoeren. Zonder deze functies zal het systeem niet onze doelstelling kunnen vervullen en wordt het uitgesloten voor selectie.
Voorbeeld van functionele requirements:
* Het systeem moet na iedere bestelling een ontvangstbevestiging versturen met informatie over de bezorgtermijn.
* Het systeem moet een overzicht met openstaande bestellingen genereren.
* Het systeem moet een overzicht met voorraadinformatie genereren.

Niet  functionele requirements

Niet functionele requirements beschrijven de kwaliteitseisen die aan het hele systeem worden gesteld. Ze zijn minder gedetailleerd dan functionele eisen.
Ze beschrijven niet WAT het systeem moet doen, maar HOE het systeem moet werken.  Hier komen onder andere zaken als performance, onderhoud, veiligheid en betrouwbaarheid aan de orde. Maar het kunnen ook  eisen zijn die voortvloeien uit wet/regelgeving.
Voorbeeld van niet functionele eisen:
* De gebruiker wil een gebruikersvriendelijk systeem.
* De gebruiker wil dat de schermen binnen 3 seconden worden geladen.
* Het systeem moet alle binnenkomend bestanden controleren op virussen.

Randvoorwaarden

In de randvoorwaarden worden de technische kaders beschreven voor het aan te schaffen pakket. Hier worden minimaal de volgende aspecten beschreven:
* Op welk operating system moet de software kunnen draaien.
* Welke drivers/api´s  gebruikt het systeem
* Zijn er eisen t.a.v. de gebruikte browser
* Op welke database moet de software kunnen draaien
* Wat zijn de eisen ten aanzien van uitwisselingsprotocollen


-- Printbare PDF-versie --