Software Engineering Projecten: Project Managers Info

• Zie ook algemene SEP informatie.
• Projectmanager (PM) faciliteert optimaal functioneren van het team, opdat zij op tijd en binnen budget een kwaliteitsproduct afleveren. PM zorgt voor het opstellen, onderhouden en bewaken van de werkplannen (wie doet wat wanneer). PM lost geen technische problemen op, maar houdt natuurlijk wel zicht op de grote lijn. PM smeedt en motiveert het team. PM mag (moet) delegeren (en dan controleren).
• Twee-wekelijkse PM-bijeenkomsten (circa 3 kwartier; buiten project om; in het begin eventueel wekelijks)
  • Met alle PMs gezamenlijk en een docent
  • Niet te verwarren met voortgangsbesprekingen (die vallen wel binnen het project)
  • Doelen:
    • Algemene (management) problemen bespreken en samen oplossen
    • Toelichting m.b.t. ESA SE Standaard
    • Specifieke methoden per fase (bijv. werkverdelen, specificatie, ontwerp, testen, ...)
• `Volledige' ESA SE Standaard gebruiken. Niet die voor `kleine projecten', want dat is alleen voor ervaren teams.
• Unity-of-command principe aanhouden: Iedereen rapporteert aan precies één persoon. De enige uitzondering hierop is de kwaliteitsmanager die, desgewenst, ook rechtstreeks aan de directie rapporteert.
• Eén persoon in team als klantcontact aanwijzen.
• Twee-wekelijkse voortgangsbesprekingen met directie (circa 20 minuten),
  • meteen vanaf het begin
  • zoveel mogelijk in HG 6.05 verroosteren
  • met agenda, schriftelijk voorgangsrapport, notulen
• Alle uren verantwoorden (ook van adviseurs en reviewers), dus niet eerst wat aanmodderen.
• Alle te bespreken documenten worden op papier aangeleverd, bij voorkeur met genummerde regels (per 5): agenda's, voortgangsrapporten, te reviewen documenten, etc.
• Externe reviews
  • Met melding vooraf op schrift door ext. reviewers (geeft ook verplichting om die info samen te vatten voor verg.).
  • Hierbij dienen ten minste aanwezig te zijn:
    • één afgevaardigde van de directie (deze treedt niet op als reviewer, maar ontvangt wel alle stukken),
    • drie adviseurs (niet de eigen adviseur),
    • alsmede bij UR/R, SR/R en SVVP/AT/R een afgevaardigde van de klant.
  • Zeer tijdig roosteren (incl. reservedata), in overleg met alle betrokkenen.
    UR/R: 21 jan. (uitloop naar 28 jan.)
    SR/R: 18 feb. (uitloop naar 25 feb.)
    Vertraging kost punten
• Alle directieleden dienen de goedgekeurde documenten te ontvangen (let m.n. op diegenen die niet bij een externe review zitten).
• Watervalmodel gebruiken. Geeft nettere structuur bij korte doorlooptijd; incrementeel of evolutionair ontwikkelen leidt gauw tot hacken.
• UML (notatie) gebruiken. Dit is bij Object-geöriënteerd Programmeren behandeld.
• Prototype(s) laten bouwen in SR fase, m.n. om user-interface vorm te geven en voor gebieden waar het team minder ervaring mee heeft. Het user interface prototype moet gedemonstreerd worden aan de klant en beschreven worden in de SRD ("screenshots" met toelichting, m.n. koppeling aan logische model). Code van prototype niet hergebruiken, wel opnemen in configuratiemanagementsysteem.
• Acceptatietest zeer tijdig roosteren in overleg met alle betrokkenen. Leg eigen deadline ruim vóór de harde deadline. Klant moet erbij zijn en neemt uiteindelijke beslissing over acceptatie.
• De adviseur moet betrokken worden bij intern overleg en interne reviews.
• Houd rekening met tenminste één audit. Audits worden tijdig aangekondigd.
• Voorzieningen:
  • Zie ook SEP Middelen.
  • Tijdig aanvraag indienen voor wat ontbreekt, houd rekening met afwijzing.
  • Print- en kopieerkosten zijn voor het team, eventueel via een `pot' en kostenadministratie de lasten eerlijk delen.