Resource management
Questo permette al Project Manager di monitorare quanto manca allo sviluppo di un determinato componente e le classi, e come è progredito lo sviluppo. (a condizione i membri del team mantengono le loro figure professionali)
Effort management
Sforzo richiesto per completare un determinato dettaglio.
Es.: Eseguire lo unt testing: 2 ore
Risk Management
Rischi che comporta eseguire un determinato task.
Es.: Questo task comporto una lunga lavorazione e le tecnonogie potrebbero cambiare nel frattempo.
Metrics
Metriche d'impatto.
Es.: La complessità (di tipo: "Cambiamento"): Un cambiamento futuro può avere un grosso impatto sul progetto. (Peso: 2)
NOTE
- Su project gant view, c'è il report view per visualizzare i assieme i task assegnati ad un lavoratore, al dissopra o al disotto di una certa soglia di completamento
- Distinguere difetti di manutenzione da difetti di implementazione
- TASK: Rappresenta un lavoro in corso! (quindi non è un requisito).
- FEATURE: Una funzionalità è una serie di requisiti correlati che consentono all'utente di soddisfare un obiettivo o una necessità aziendali. (Cosa il sistema è in grado di fare)
E' una funzionalità richiesta, l'elemento grafico, viene creato come indice di soddisfazione di un requisito (sono utilizzate nei diagrammi dei requisiti)
Es.:
Requisito=Utilizzare il pattern MVP
Feature=Nell'architettura è usato il pattern MVP - REQUIREMENT: Una dichiarazione di un bisogno del cliente o di un obiettivo o di una condizione o capacità che un prodotto deve possedere per soddisfare tale necessità o obiettivo. (Cosa il sistema può fare)
Maintenance
Gli elementi di manutenzione si applicano a livello di elemento (modello corrente), li applichiamo a livello di progetto (sistema corrente) solamente se hanno implicazioni più ampie per il progetto o identificano (ad esempio) un attore, attività o azione che richiede ulteriore definizione, o anche per allegarvi la documentazione relativa.
Nota: Differenziamo i problemi e difetti di implementazione (nel compito svolto), dai problemi e difetti task o cambiamenti per manutenzione (nel requisito, nella responsabilità).
Un difetto (Defect) può essere considerato come un fallimento, perché non viene soddisfatto un requisito (responsabilità) per l'elemento modello corrente.
Es.:E’un errore che si verfica solamente cambiando un input. Per esempio, se invece di scrivere "a >= 0", il programmatore ha erroneamente scritto "a > 0" in una istruzione, si può avere un malfunzionamento solo quando viene eseguita quell'istruzione mentre la variabile "a" vale zero.
Un difetto non crea un problema ma fa vedere qualcosa di inappropriato, incongruente ai requisiti.
Infatti su uno unit test che durante la fase di manutenzione non va a buon fine noi apriamo un defect e non un issue.
Un cambiamento (change) può essere considerato come un cambiamento nel requisito (responsabilità) per l'elemento modello corrente.
Un problema (Issue) registra un fattore di rischio che può influire sul progetto in fase di esecuzione per l'elemento modello corrente.
Es.:E’un problema (errore) software, che si verifica sempre passando per una determinata condizione
Un task, è un mezzo per registrare i lavori in corso e i lavori straordinari per l'elemento modello corrente.
Gli elementi di manutenzione di livello sistema, vengono linkati al modello, elemento che ha generato il problema (responsabile) con una relazione "Realization"
Project task list
E' una TODO list per elencare dei task di progetto che non sono gestiti altrove.
Può essere utilizzato per monitorare le cose, come ad esempio le richieste di incontri.
Usato per registrare problemi a livello di progetto da risolvere per non compromettere l'intero andamento.
Es.: Il materiale non è stato fornito in tempo e quindi adesso non possiamo proseguire e dobbiamo trovare un altra strada.
Bookmarks
Sono dei triangolini rossi sopra gli elementi modello. Si creano selezionando l'elemento e premendo "Shift" + "SpaceBar"
Requisiti da model wizard
Funzionali
- Business Rules: Regole ferree (che si possono applicare in vari contesti)
- Features: Realizzando i requisiti (io di solito elimino tale package e aggiungo le "Fearures" del diagramma dei requisiti)
- User interface: Disegno delle interfacce grafiche
Non funzionali
- Performance: Criteri misurabili del sistema, che governano la velocità generale e la reattività
- Scalability: Criteri relativi ai limiti causati dalla dimensione del sistema
- Security: Criteri di accesso ai dati e ai sistemi fisici
- Persistence: Criteri relativi alla memorizzazione di informazioni
- Transport: Criteri di definizione di vincoli e condizioni inerenti la trasmissione di informazioni tra i nodi (Es.: Reti: protocollo e qualità della comunicazione)
Defect e risoluzione
Per prima cosa creo un "Defect" e collego, tramite relazione "Dependency", l'oggetto che ne è afflitto con esso.
Poi creo un "Change" e collego, tramite relazione "Trace", il "Defect" con esso.
Sul "Change", descrivo il lavoro da effettuare per poter corregger il difetto e poi gli assegno la risorsa che dovrà lavorarci.
Dopo creo (su di esso) i "Testing" che dovranno essere verificati affinché il difetto possa essere considerato corretto.
In questo modo ottengo la notazione del difetto e ciò che è stato fatto per correggerlo
