Lees hier de samenvatting en de meest belangrijke oefenvragen van Syllabus

• 1 Inleiding

• 1.1.2 Programmeren

  Dit is een preview. Er zijn 2 andere flashcards beschikbaar voor hoofdstuk 1.1.2
  Laat hier meer flashcards zien

• Welke programmeertalen lenen zich tot het programmeren van de verschillende soorten software?

  • Phyton, PHP en de oudere taal Javascript lenen zich goed voor het bouwen van web toepassingen. HTML is de basis voor web toepassingen, maar is eerder een declaratieve programmeertaal.
    
  • c, Java, C#, C++ bereiken een breder veld van toepassingen, zoals business solutions, games of zelfs besturingssystemen.
  • T-SQL is de taal om met gegevens in databases te werken.
  • Je hebt ook specifiekere programmeertalen zoals Shell (script taal), R (voor statische toepassingen), Prolog (voor logische toepassingen)

• 1.1.3 Programmeur

  Dit is een preview. Er zijn 2 andere flashcards beschikbaar voor hoofdstuk 1.1.3
  Laat hier meer flashcards zien

• Welke rollen zijn geen synoniemen van programmeur en waarom?

  Lead developer, software architect, software designer, omdat de inhoud van deze rollen fundamenteel verschillen met die van een programmeur.

• 1.1.4 Scope

  Dit is een preview. Er zijn 2 andere flashcards beschikbaar voor hoofdstuk 1.1.4
  Laat hier meer flashcards zien

• Welke soorten vereisten kan een scope hebben?

  • Functionele: Ik wil de app kunnen gebruiken om een bestelling te plaatsen
    
  • Esthetische: Ik wil een groot lettertype hebben om goed te kunnen lezen
  • Technische: De app moet werken op een Apple en Android smartphone

• 1.2 Wat is analyse?

  Dit is een preview. Er zijn 1 andere flashcards beschikbaar voor hoofdstuk 1.2
  Laat hier meer flashcards zien

• Maak een eenvoudige voorstelling van het proces om complexe softwaresystemen te bouwen.

  Analysis > Design >   Implementation of Development >Deployment
  Modelling Modelling                                                                     Modelling

• 1.2.2 Terminologie

• Welke 4 termen komen we in de praktijk tegen en welke zijn verweven met elkaar?

  • Object Oriented Analysis
    
  • Object Oriented Design
  • Object Oriented Development
  • Object Oriented Modelling

  Analyse en ontwerp zijn erg sterk met elkaar verweven en de competenties zijn niet altijd eenduidig terug te brengen tot  één van  beiden, maar tot  combinatie van beiden.

• 1.3 Graduaat programmeren versus Object Oriented Analysis

  Dit is een preview. Er zijn 1 andere flashcards beschikbaar voor hoofdstuk 1.3
  Laat hier meer flashcards zien

• Waarom is Object Oriented Analysis belangrijk?

  In de praktijk zal een developer vaak in contact komen met de resultaten van een object georiënteerde analyse (of design). Zijn/haar rol is om de opgeleverde resultaten (deliverables) uit de analyse en design fase, om te zetten naar een softwaresysteem. Zoals vermeld, zullen de resultaten uit de analyse de developer helpen om het “wat” te begrijpen. En de aangeleverde documenten en informatie uit het design het “hoe”.

• 2 Bouwen van (complexe) softwaresystemen

• 2.1.3.1 Wijzigingen

• Kunnen er nog wijzigingen aangebracht worden tijdens het project?

  De eisen en wensen gedurende het traject kunnen wijzigen, zeker als er sprake is van een langlopend project. Er kunnen tijdens de ontwikkeling van het nieuwe systeem wel degelijk wijzigingen aan de scope aangebracht worden. Maar dat gebeurt in onderling overleg met goedkeuring van de extra kosten of vertraging. Vaak leeft bij (beslissingsnemers van) de business, het idee dat ze alleen maar een vage opdracht moeten geven, en dat ze nadien wel horen wanneer het klaar is en dat alles precies werkt zoals het in hun hoofd zit.

• 2.1.4 Beheren van het proces

• Welke zaken moeten worden geordend, uitgevoerd en op elkaar afgestemd worden?

  • Groot team van developers (wie heeft welke kennis, wie krijgt welke taken, wie is wanneer beschikbaar, …)
  • Groot aantal medewerkers bij de business, met allemaal hun eigen ideeën, kennis, ervaring en visie op het probleem.
  • Groot aantal vereisten (scope). Waar je vaak door de bomen het bos niet meer kan zien.
  • Groot aantal bestaande systemen die moeten gekoppeld worden aan je nieuwe software.
  • Groot aantal externe factoren waar je rekening mee moet houden. Bijvoorbeeld ICT-projecten die parallel worden uitgevoerd en een impact (zouden) kunnen hebben.
  • …

• 2.2 Historiek van falende projecten

• Wat kunnen oorzaken zijn van falende projecten?

  • Te laat opgeleverd, waardoor bepaalde doelstellingen of gerelateerde initiatieven in het gedrang komen.
  • Te veel fouten. Waardoor gebruikers steeds vast komen te zitten, en gefrustreerd raken.
  • Budget wordt (ruimschoots) overschreden.
  • Niet opgeleverd volgens de verwachtingen. Met andere woorden de software doet niet wat deze zou moeten doen.
  • Opgeleverd, maar het originele probleem werd eigenlijk niet verholpen of gewoon verschoven.
  • De software wordt bijvoorbeeld niet, nauwelijks of inefficiënt gebruikt.

• 2.2.1 Oorzaken

  Dit is een preview. Er zijn 2 andere flashcards beschikbaar voor hoofdstuk 2.2.1
  Laat hier meer flashcards zien

• Hoeveel procent van de projecten faalt?

  70%