What is the best choice among process models to address tight schedules and cost of the software precisely?
Dipende dai modelli di processo che stai scegliendo. Il modello a spirale offre infatti un lavoro migliore di molti a lavorare nei limiti di un programma predefinito e offre una buona visibilità dei progressi e un sovraccarico ridotto.
Nel suo libro Rapid Development, Steve McConnell identifica 10 diversi modelli di processo: Pure Waterfall, Code and Fix, Spiral, Modified Waterfalls (che include alcune varianti), Prototyping evolutivo, Staged Delivery, Delivery evolutivo, Design-to-Schedule , Design-to-Tools e utilizzo del software Off-the-Shelf (senza sviluppo: acquisto e integrazione del software esistente).
Tra i suoi 10 modelli, Design-to-Schedule, Design-to-Tools e Software Off-the-Shelf sono i migliori per adattarsi a un programma predefinito. Cascata pura, spirali, cascate modificate e consegna graduale fanno un buon lavoro. Spirale, Design-to-Tools e Delivery evolutivo sono i migliori nella gestione dei costi e nella visibilità.
Design-to-Tools e Design-to-Schedule non sono molto comuni quando si parla di metodologie di progettazione ad alto livello. L'idea alla base di Design-to-Tools consiste nel progettare e implementare solo cose che sono già supportate da strumenti come librerie, generatori di codice e così via. Guadagni velocità concentrandoti sull'integrazione, ma perdi il controllo sulle funzionalità poiché non implementi nuove funzionalità. Design-to-Schedule è come una versione progressiva, ma non sai quante versioni verranno effettivamente realizzate.
Se dovessi scegliere un modello comunemente discusso, probabilmente andrei con Spiral Model. Ma dipende da quale sia l'insieme completo di modelli di processo tra cui scegliere.
What should be the best choice among different process models for development of any general software, such as library information system or inventory management system?
Non c'è una scelta migliore singolare - ogni progetto di sviluppo è diverso. Facendo riferimento al Rapid Development di Steve McConnell, egli classifica i suoi modelli di ciclo di vita in varie categorie - lavorando con requisiti poco chiari, lavorando con architetture scarsamente comprensibili, capacità di produrre sistemi altamente affidabili, gestione dei rischi, visibilità del cliente, visibilità del management, sofisticazione del team di sviluppo, e altri. E questo è solo un modo per dividerlo.
What are the best best areas of application of V-shape model?
Esistono diverse rappresentazioni del modello V. Wikipedia identifica due comuni: Das V-Modell (comunemente trovato in Germania) , che è una metodologia di gestione del progetto che include la gestione e il controllo della qualità e la mappatura più comunemente utilizzata tra le attività di test del software e le attività del ciclo di vita.
Il modello V in realtà non è un modello di ciclo di vita proprio. È spesso raffigurato come una cascata, ma le stesse attività di sviluppo sul lato sinistro si trovano in quasi ogni progetto: ci sono sempre requisiti, architettura, design e codice. Il lato destro del V esegue il test delle attività su questi. Ad esempio, il tuo codice si associa ai test unitari, le tue mappe di progettazione di basso livello ai test di integrazione, i tuoi requisiti software si mappano ai test di verifica e convalida del software, i tuoi requisiti di sistema si mappano alla verifica e alla convalida del sistema e il tuo concetto di operazioni viene testato effettivamente operativo il sistema software nel suo ambiente di distribuzione.
Non importa in che forma entrano queste attività e uscite. I requisiti possono essere una User story o una specifica dei requisiti del software. In entrambi i casi, una volta raggiunto un requisito stabile, è possibile utilizzare tale requisito per iniziare a pianificare le specifiche di accettazione. Allo stesso modo, ogni volta che hai un'idea del codice che stai scrivendo, puoi iniziare a scrivere test unitari.