Prepararsi per lavoro di laboratorio

Leggi il materiale della lezione sull'argomento “Modelli del ciclo di vita del software. Fasi del ciclo di vita secondo GOST 19.102-77. Enunciazione del problema" della disciplina "Sviluppo e standardizzazione di PS e IT".

1. Studiare le sezioni rilevanti nelle pubblicazioni.

Parte teorica. Sviluppo termine di paragone

Compito tecnicoè un documento che formula i principali obiettivi di sviluppo, i requisiti per un prodotto software, determina i termini e le fasi di sviluppo e regola il processo dei test di accettazione. Sia i rappresentanti del cliente che i rappresentanti dell'appaltatore sono coinvolti nello sviluppo dei termini di riferimento. Questo documento si basa sulle esigenze iniziali del cliente, sull'analisi della tecnologia avanzata, sui risultati della ricerca scientifica, sulla ricerca pre-progetto, sulla previsione scientifica, ecc.

L'ordine di sviluppo delle specifiche tecniche

Lo sviluppo delle specifiche tecniche viene eseguito nella sequenza seguente. In primo luogo, stabiliscono un insieme di funzioni da svolgere, nonché un elenco e le caratteristiche dei dati iniziali. Quindi viene determinato un elenco di risultati, le loro caratteristiche e le modalità di presentazione.

Successivamente, specificano l'ambiente per il funzionamento del software: configurazione e parametri specifici mezzi tecnici, la versione del sistema operativo utilizzato ed eventualmente le versioni e le impostazioni di altri software installati con i quali interagirà il futuro prodotto software.

Nei casi in cui il software sviluppato raccolga e memorizzi alcune informazioni o sia incluso nella gestione di un qualsiasi processo tecnico, è inoltre necessario regolare in modo chiaro le azioni del programma in caso di interruzioni di apparecchiature e di alimentazione.

1. Disposizioni generali

1.1. I termini di riferimento sono redatti secondo GOST 19.106-78 su fogli di formato A4 e A3 secondo GOST 2.301-68, di norma, senza compilare i campi del foglio. I numeri di fogli (pagine) sono apposti nella parte superiore del foglio sopra il testo.

1.2. Il foglio di approvazione e il frontespizio sono redatti secondo GOST 19.104-78. La parte informativa (estratto e contenuto), il foglio di registrazione delle modifiche potrebbero non essere inclusi nel documento.

1.3. Per apportare modifiche e integrazioni al background tecnico nelle fasi successive dello sviluppo di un programma o di un prodotto software, viene rilasciato un addendum ad esso. Il coordinamento e l'approvazione dell'integrazione al capitolato avviene con le stesse modalità previste per il capitolato.

1.4. Il mandato dovrebbe contenere le seguenti sezioni:

Introduzione;

Nome e ambito;

base per lo sviluppo;

Scopo dello sviluppo;

Requisiti tecnici al programma o al prodotto software;

Indicatori tecnici ed economici;

Fasi e fasi di sviluppo;

Procedura per il controllo e l'accettazione;

Applicazioni.

A seconda delle caratteristiche del programma o del prodotto software, è consentito chiarire il contenuto delle sezioni, introdurre nuove sezioni o combinarne alcune. Se necessario, è consentito includere le domande nel capitolato.

2.1.L'introduzione dovrebbe includere breve descrizione l'ambito del programma o del prodotto software, nonché l'oggetto (ad esempio il sistema) in cui dovrebbe essere utilizzato. Lo scopo principale dell'introduzione è dimostrare la rilevanza di questo sviluppo e mostrare quale posto occupa questo sviluppo tra quelli simili.

2.2 Nella sezione "Nome e ambito" indicare il nome, una breve descrizione dello scopo del programma o prodotto software e l'oggetto in cui il programma o prodotto software viene utilizzato.

2.3 Nella sezione "Base per lo sviluppo" devono essere indicati:

Il documento (documenti) sulla base del quale viene effettuato lo sviluppo. Tale documento può essere un piano, un ordine, un contratto, ecc.;

L'organizzazione che ha approvato questo documento e la data della sua approvazione;

Nome e (o) simbolo temi di sviluppo.

2.4. La sezione Scopo di sviluppo dovrebbe indicare lo scopo funzionale e operativo del programma o del prodotto software.

2.5. La sezione "Requisiti tecnici per il programma o il prodotto software" dovrebbe contenere le seguenti sottosezioni:

requisiti di prestazione;

Requisiti di affidabilità;

Condizioni operative;

Requisiti per la composizione e parametri dei mezzi tecnici;

Requisiti per la compatibilità delle informazioni e del software;

Requisiti per l'etichettatura e l'imballaggio;

Requisiti per il trasporto e lo stoccaggio;

Requisiti speciali.

2.5.1 La sottosezione "Requisiti per le caratteristiche funzionali" dovrebbe indicare i requisiti per la composizione delle funzioni svolte, l'organizzazione dei dati di input e output, le caratteristiche temporali, ecc.

2.5.2 Nella sottosezione "Requisiti di affidabilità", devono essere indicati i requisiti per garantire un funzionamento affidabile (garantire un funzionamento stabile, controllo delle informazioni di input e output, tempo di ripristino dopo un guasto, ecc.).

2.5.3 Nella sottosezione "Condizioni di esercizio" devono essere indicate le condizioni di esercizio (temperatura dell'aria ambiente, umidità relativa, ecc. per i tipi di supporto dati selezionati) in base alle quali devono essere garantite le caratteristiche specificate, nonché il tipo di servizio, importo richiesto e qualifiche del personale.

2.5.4 Nella sottosezione "Requisiti per la composizione e parametri dei mezzi tecnici" indicare la composizione richiesta dei mezzi tecnici, indicando la loro specifiche.

2.5.5 Nella sottosezione "Requisiti per le informazioni e la compatibilità dei programmi", devono essere indicati i requisiti per le strutture informative in ingresso e in uscita e i metodi di soluzione, i codici sorgente, i linguaggi di programmazione. Ove necessario, le informazioni ei programmi dovrebbero essere protetti.

2.5.6 Nella sottosezione "Requisiti di etichettatura e confezionamento", nel caso generale, sono indicati i requisiti per l'etichettatura del prodotto software, le opzioni di confezionamento e le modalità di confezionamento.

2.5.7 Nella sottosezione "Requisiti per il trasporto e la conservazione" del prodotto software devono essere indicate le condizioni per il trasporto, i luoghi di conservazione, le condizioni di conservazione, le condizioni di immagazzinamento, i periodi di conservazione nelle varie condizioni.

2.5.8. Nella sezione "Indicatori tecnici ed economici" dovrebbero essere indicati: efficienza economica stimata, fabbisogno annuo stimato, vantaggi economici dello sviluppo rispetto ai migliori campioni o analoghi nazionali ed esteri.

2.6 Nella sezione "Fasi e fasi di sviluppo", le fasi di sviluppo necessarie, le fasi e il contenuto del lavoro (un elenco di documenti di programma che devono essere sviluppati, concordati e approvati), nonché, di regola, lo sviluppo termini e determinare gli esecutori testamentari.

2.7 Nella sezione "Procedura di controllo e accettazione" le tipologie di prove e Requisiti generali accettare il lavoro.

2.8 Negli allegati al capitolato, se necessario, prevedere:

Elenco delle ricerche e di altri lavori a sostegno dello sviluppo;

Schemi algoritmici, tabelle, descrizioni, giustificazioni, calcoli e altri documenti che possono essere utilizzati nello sviluppo;

Altre fonti di sviluppo.

Nei casi in cui il cliente non apporti alcun obbligo previsto dal capitolato, nell'apposito luogo dovrà essere indicato “Nessun obbligo”.

Esempi dello sviluppo di termini di riferimento sono forniti nelle appendici B e C.

domande di prova

1. Fornire il concetto di modello ciclo vitale SU.

2. Indica le fasi di sviluppo del software.

3. Cosa includono la dichiarazione del problema e la ricerca pre-progetto?

4. Elencare i requisiti funzionali e operativi per il prodotto software.

5. Elencare le regole per lo sviluppo del mandato.

6. Denominare le sezioni principali del mandato.

Annesso A

Opzioni attività

I lavori di laboratorio n. 1-5 vengono eseguiti per la stessa opzione.

1. Sviluppare un modulo software "Contabilità dei progressi degli studenti". Il modulo software è progettato per registrare tempestivamente i progressi degli studenti in una sessione da parte del preside, dei vice presidi e del personale del preside. Le informazioni sullo stato di avanzamento degli studenti devono essere conservate durante l'intero periodo degli studi e utilizzate nella preparazione degli attestati dei corsi seguiti e dei supplementi ai diplomi.

2. Sviluppare un modulo di programma "File personali degli studenti". Il modulo software è progettato per ottenere informazioni sugli studenti da parte dei dipendenti dell'ufficio del preside, del comitato sindacale e dell'ufficio del personale. Le informazioni devono essere conservate durante l'intero periodo di formazione degli studenti e utilizzate nella preparazione di certificati e relazioni.

3. Sviluppare un modulo software "Soluzione di problemi di ottimizzazione combinatoria". Il modulo dovrebbe contenere algoritmi per trovare un ciclo di lunghezza minima (problema del commesso viaggiatore), trovare il percorso più breve e trovare lo spanning tree minimo.

4. Sviluppare un modulo software "Elaborazione matrice". Il modulo dovrebbe contenere algoritmi per trovare somme e prodotti di elementi di matrice per righe e colonne, nonché per calcolare i valori medi, minimi e massimi nella matrice.

5. Sviluppare un'applicazione Windows "Organizer". L'applicazione è progettata per registrare, memorizzare e cercare indirizzi e numeri di telefono individui e organizzazioni, nonché orari, riunioni, ecc. L'applicazione è progettata per qualsiasi utente di computer.

6. Sviluppare un'applicazione Windows "Calculator". L'applicazione è destinata a qualsiasi utente e dovrebbe contenere tutte le operazioni aritmetiche (rispetto alle priorità) e preferibilmente (ma non obbligatorie) alcune funzioni matematiche.

7. Sviluppare un modulo software "Dipartimento", contenente informazioni sul personale del dipartimento (nome, posizione, titolo accademico, discipline, carico di lavoro, lavoro sociale, lavoro part-time, ecc.). Il modulo è destinato all'uso da parte dei dipendenti del dipartimento del personale e dell'ufficio del preside.

8. Sviluppare un modulo software "Laboratorio", contenente informazioni sul personale del laboratorio (nome, sesso, età, stato civile, presenza di figli, posizione, titolo accademico). Il modulo è destinato all'uso da parte dei dipendenti del comitato sindacale e del dipartimento del personale.

9. Sviluppare un modulo di programma "Lavaggio a secco". Al momento della registrazione al servizio viene compilata una domanda, che indica il nome del titolare, la descrizione del prodotto, il tipo di servizio, la data di ricezione dell'ordine e il costo del servizio. Al termine del lavoro, viene stampata una ricevuta.

10.Sviluppare un modulo software "Contabilità delle violazioni delle regole traffico". Per ogni vettura (e il suo proprietario) viene memorizzato nel database un elenco di violazioni. Per ogni violazione vengono registrati la data, l'ora, il tipo di violazione e l'importo della sanzione. Quando tutte le multe sono state pagate, l'auto viene rimossa dal database.

11. Sviluppare un modulo software "File scheda di un'officina", destinato all'uso da parte dei dipendenti dell'agenzia. Il database contiene informazioni sulle auto (marca, cilindrata, data di rilascio, ecc.). Quando si riceve un ordine di acquisto, viene effettuata una ricerca opzione adatta. In caso contrario, il cliente viene inserito nella base clienti e notificato quando viene visualizzata un'opzione.

12. Sviluppare un modulo software "File tessera degli abbonati ATS". Il file della scheda contiene informazioni sui telefoni e sui loro proprietari. Corregge gli arretrati di pagamento (abbonato e a tempo). Si ritiene che sia già stato introdotto il pagamento orario delle telefonate locali.

13. Sviluppare un modulo software "Avtokassa", contenente informazioni sulla disponibilità di posti sulle linee di autobus. Il database dovrebbe contenere informazioni sul numero del volo, la rotta, il conducente, il tipo di autobus, la data e l'ora di partenza, nonché i prezzi dei biglietti. Quando viene ricevuta una domanda per i biglietti, il programma cerca un volo adatto.

14. Sviluppare un modulo software "Bookshop", contenente informazioni sui libri (autore, titolo, editore, anno di pubblicazione, prezzo). L'acquirente compila una domanda per i libri di cui ha bisogno, se non ce ne sono viene inserito nel database e avvisato quando i libri necessari arrivano in negozio.

15. Sviluppare un modulo software "Parcheggio". Il programma contiene informazioni sulla marca dell'auto, il suo proprietario, la data e l'ora di ingresso, il costo del parcheggio, gli sconti, gli arretrati di pagamento, ecc.

16. Sviluppare un modulo del programma "Agenzia di reclutamento", contenente informazioni sui posti vacanti e curricula. Il modulo software è progettato sia per trovare un dipendente che soddisfi i requisiti dei dirigenti dell'azienda, sia per trovare un lavoro adatto.

LABORATORIO #1

Fasi di sviluppo del software in un approccio strutturale alla programmazione. Fase "Termini di riferimento"

Obbiettivo: Familiarizzare con le regole per scrivere le specifiche tecniche.

Preparazione per il lavoro di laboratorio

Leggi il materiale della lezione sull'argomento “Modelli del ciclo di vita del software. Fasi del ciclo di vita secondo GOST 19.102-77. Enunciazione del problema" della disciplina "Sviluppo e standardizzazione di PS e IT".

Studiare le sezioni rilevanti nelle pubblicazioni.

Parte teorica. Sviluppo di specifiche tecniche

Compito tecnicoè un documento che formula i principali obiettivi di sviluppo, i requisiti per un prodotto software, determina i termini e le fasi di sviluppo e regola il processo dei test di accettazione. Sia i rappresentanti del cliente che i rappresentanti dell'appaltatore sono coinvolti nello sviluppo dei termini di riferimento. Questo documento si basa sui requisiti iniziali del cliente, sull'analisi dei risultati tecnologici avanzati, sui risultati della ricerca scientifica, sugli studi pre-progetti, sulle previsioni scientifiche, ecc.

L'ordine di sviluppo delle specifiche tecniche

Lo sviluppo delle specifiche tecniche viene eseguito nella sequenza seguente. In primo luogo, stabiliscono un insieme di funzioni da svolgere, nonché un elenco e le caratteristiche dei dati iniziali. Quindi viene determinato un elenco di risultati, le loro caratteristiche e le modalità di presentazione. Successivamente, viene specificato l'ambiente operativo del software: la configurazione e i parametri specifici dell'hardware, la versione del sistema operativo utilizzato ed, eventualmente, le versioni e i parametri di altro software installato con cui il futuro prodotto software interagirà. Nei casi in cui il software sviluppato raccolga e memorizzi alcune informazioni o sia incluso nella gestione di un qualsiasi processo tecnico, è inoltre necessario regolare in modo chiaro le azioni del programma in caso di interruzioni di apparecchiature e di alimentazione. 1. Disposizioni generali

I termini di riferimento sono redatti secondo GOST 19.106-78 su fogli di formato A4 e A3 secondo GOST 2.301-68, di norma, senza compilare i campi del foglio. I numeri di fogli (pagine) sono apposti nella parte superiore del foglio sopra il testo. Il foglio di approvazione e il frontespizio sono redatti secondo GOST 19.104-78. La parte informativa (estratto e contenuto), il foglio di registrazione delle modifiche potrebbero non essere inclusi nel documento. Per apportare modifiche e integrazioni al background tecnico nelle fasi successive dello sviluppo di un programma o di un prodotto software, viene rilasciato un addendum ad esso. Il coordinamento e l'approvazione dell'integrazione al capitolato avviene con le stesse modalità previste per il capitolato. Il mandato dovrebbe contenere le seguenti sezioni:

introduzione; nome e ambito;

base per lo sviluppo; scopo di sviluppo; requisiti tecnici per il programma o il prodotto software; indicatori tecnici ed economici; stadi e stadi di sviluppo; procedura di controllo e accettazione; applicazioni.

A seconda delle caratteristiche del programma o del prodotto software, è consentito chiarire il contenuto delle sezioni, introdurre nuove sezioni o combinarne alcune. Se necessario, è consentito includere le domande nel capitolato. 2. Contenuto delle sezioni

L'introduzione dovrebbe includere una breve descrizione dell'ambito del programma o del prodotto software, nonché l'oggetto (ad esempio il sistema) in cui dovrebbe essere utilizzato. Lo scopo principale dell'introduzione è dimostrare la rilevanza di questo sviluppo e mostrare quale posto occupa questo sviluppo tra quelli simili. Nella sezione "Nome e ambito" indicare il nome, una breve descrizione dello scopo del programma o prodotto software e l'oggetto in cui il programma o prodotto software viene utilizzato. Nella sezione Basi per lo sviluppo è opportuno indicare:

documento (documenti) sulla base del quale viene effettuato lo sviluppo. Tale documento può essere un piano, un ordine, un contratto, ecc.; l'organizzazione che ha approvato il presente documento e la data della sua approvazione; nome e (o) simbolo dell'argomento di sviluppo. 2.4. La sezione Scopo di sviluppo dovrebbe indicare lo scopo funzionale e operativo del programma o del prodotto software. 2.5. La sezione "Requisiti tecnici per il programma o il prodotto software" dovrebbe contenere le seguenti sottosezioni:

requisiti di prestazione; requisiti di affidabilità; Condizioni d'uso; requisiti per la composizione e parametri dei mezzi tecnici;

requisiti per la compatibilità delle informazioni e del software;

requisiti per l'etichettatura e l'imballaggio; requisiti per il trasporto e lo stoccaggio; requisiti speciali.

La sottosezione "Requisiti per le caratteristiche funzionali" dovrebbe indicare i requisiti per la composizione delle funzioni svolte, l'organizzazione dei dati di input e output, le caratteristiche temporali, ecc. La sottosezione "Requisiti di affidabilità" dovrebbe indicare i requisiti per garantire un funzionamento affidabile (assicurando funzionamento stabile, controllo delle informazioni di input e output, tempo di ripristino dopo un guasto, ecc.). La sottosezione “Condizioni operative” deve indicare le condizioni operative (temperatura dell'aria ambiente, umidità relativa, ecc. per i tipi di supporto dati selezionati) in base alle quali devono essere fornite le caratteristiche specificate, nonché il tipo di servizio, il numero richiesto e qualifiche del personale. Nella sottosezione "Requisiti per la composizione e parametri dei mezzi tecnici" indicare la composizione richiesta dei mezzi tecnici con l'indicazione delle loro caratteristiche tecniche. Nella sottosezione “Requisiti per le informazioni e la compatibilità dei programmi”, devono essere indicati i requisiti per le strutture informative in ingresso e in uscita e i metodi di soluzione, i codici sorgente e i linguaggi di programmazione. Ove necessario, le informazioni ei programmi dovrebbero essere protetti. Nella sottosezione “Requisiti di etichettatura e imballaggio”, nel caso generale, sono indicati i requisiti per l'etichettatura del prodotto software, le opzioni e le modalità di imballaggio. Nella sottosezione “Requisiti per il trasporto e l'immagazzinamento” devono essere indicate le condizioni per il trasporto, i luoghi di immagazzinamento, le condizioni di immagazzinamento, le condizioni di immagazzinamento, i periodi di immagazzinamento nelle varie condizioni del prodotto software.

2.5.8. Nella sezione "Indicatori tecnici ed economici" dovrebbero essere indicati: efficienza economica stimata, fabbisogno annuo stimato, vantaggi economici dello sviluppo rispetto ai migliori campioni o analoghi nazionali ed esteri.

Nella sezione "Fasi e fasi di sviluppo", le fasi di sviluppo necessarie, le fasi e il contenuto del lavoro (un elenco di documenti di programma che devono essere sviluppati, concordati e approvati), nonché, di norma, i tempi di sviluppo e determinano gli esecutori testamentari. Nella sezione "Procedura di controllo e accettazione" devono essere indicati i tipi di prove ei requisiti generali per l'accettazione dei lavori. Negli allegati al capitolato, se necessario, fornire:

un elenco di ricerche e altri lavori a sostegno dello sviluppo; schemi di algoritmi, tabelle, descrizioni, giustificazioni, calcoli e altri documenti che possono essere utilizzati nello sviluppo; altre fonti di sviluppo.

Nel caso in cui i requisiti previsti dal capitolato non siano presentati dal cliente, nell'apposito luogo dovrà essere indicato “Nessun requisito”. Esempi dello sviluppo di termini di riferimento sono forniti nelle appendici B e C.

Ordine di lavoro

Sviluppare termini di riferimento per un prodotto software in base alla propria versione (vedere le opzioni nell'Appendice A) Preparare il lavoro in conformità con GOST 19.106-78. Utilizzare MS Office per la registrazione. Invia e proteggi il tuo lavoro.

Protezione del rapporto di laboratorio

Il rapporto di lavoro del laboratorio deve essere redatto sulla base del STP e consiste dei seguenti elementi strutturali:

frontespizio; parte di testo; applicazione: sviluppata dai termini di riferimento per il prodotto software.

La parte di testo della relazione dovrebbe includere i seguenti elementi:

l'obiettivo; ordine di esecuzione.

La relazione consolidata sul lavoro di laboratorio consiste nel presentare i risultati al docente sotto forma di file e nel dimostrare le competenze acquisite in risposta alle domande del docente.

domande di prova

Fornire il concetto di un modello del ciclo di vita del software. Indica le fasi di sviluppo del software. Cosa includono la dichiarazione del problema e la ricerca pre-progetto? Elencare i requisiti funzionali e operativi per il prodotto software. Elencare le regole per lo sviluppo delle specifiche tecniche. Denominare le sezioni principali dei termini di riferimento.

Bibliografia

Bedrina S.L., Sviluppo e standardizzazione di software. - Vladivostok: casa editrice VSUES, 2006. Blagodatskikh V.A., Volnin V.A., Poskakalov K.F. Standardizzazione dello sviluppo del software. - M: Finanza e statistica, 2003. GOST 19.102-77 ESPD. Fasi di sviluppo

Annesso A

Opzioni attività

I lavori di laboratorio n. 1-5 vengono eseguiti per la stessa opzione.

Sviluppare un modulo software "Contabilità dei progressi degli studenti". Il modulo software è progettato per registrare tempestivamente i progressi degli studenti in una sessione da parte del preside, dei vice presidi e del personale del preside. Le informazioni sullo stato di avanzamento degli studenti devono essere conservate durante l'intero periodo degli studi e utilizzate nella preparazione degli attestati dei corsi seguiti e dei supplementi ai diplomi. Sviluppare un modulo di programma "File personali degli studenti". Il modulo software è progettato per ottenere informazioni sugli studenti da parte dei dipendenti dell'ufficio del preside, del comitato sindacale e dell'ufficio del personale. Le informazioni devono essere conservate durante l'intero periodo di formazione degli studenti e utilizzate nella preparazione di certificati e relazioni. Sviluppare un modulo software "Soluzione di problemi di ottimizzazione combinatoria". Il modulo dovrebbe contenere algoritmi per trovare un ciclo di lunghezza minima (problema del commesso viaggiatore), trovare il percorso più breve e trovare lo spanning tree minimo. Sviluppare un modulo software "Elaborazione matrice". Il modulo dovrebbe contenere algoritmi per trovare somme e prodotti di elementi di matrice per righe e colonne, nonché per calcolare i valori medi, minimi e massimi nella matrice. Sviluppare un'applicazione Windows "Organizer". L'applicazione è progettata per registrare, archiviare e cercare indirizzi e numeri di telefono di individui e organizzazioni, nonché orari, riunioni, ecc. L'applicazione è progettata per qualsiasi utente di computer. Sviluppa un'applicazione Calcolatrice di Windows. L'applicazione è destinata a qualsiasi utente e dovrebbe contenere tutte le operazioni aritmetiche (rispetto alle priorità) e preferibilmente (ma non obbligatorie) alcune funzioni matematiche. Sviluppare un modulo software "Dipartimento", contenente informazioni sul personale del dipartimento (nome, posizione, titolo accademico, discipline, carico di lavoro, lavoro sociale, lavoro part-time, ecc.). Il modulo è destinato all'uso da parte dei dipendenti del dipartimento del personale e dell'ufficio del preside. Sviluppare un modulo software "Laboratorio", contenente informazioni sul personale del laboratorio (nome, sesso, età, stato civile, presenza di figli, posizione, titolo accademico). Il modulo è destinato all'uso da parte dei dipendenti del comitato sindacale e del dipartimento del personale. Sviluppare un modulo di programma "Lavaggio a secco". Al momento della registrazione al servizio viene compilata una domanda, che indica il nome del titolare, la descrizione del prodotto, il tipo di servizio, la data di ricezione dell'ordine e il costo del servizio. Al termine del lavoro, viene stampata una ricevuta. Sviluppare un modulo software "Contabilità delle violazioni delle regole del traffico". Per ogni vettura (e il suo proprietario) viene memorizzato nel database un elenco di violazioni. Per ogni violazione vengono registrati la data, l'ora, il tipo di violazione e l'importo della sanzione. Quando tutte le multe sono state pagate, l'auto viene rimossa dal database. Sviluppare un modulo software "File scheda di un negozio di automobili", destinato all'uso da parte dei dipendenti dell'agenzia. Il database contiene informazioni sulle auto (marca, cilindrata, data di rilascio, ecc.). Quando viene ricevuta una richiesta di acquisto, viene ricercata un'opzione adatta. In caso contrario, il cliente viene inserito nella base clienti e notificato quando viene visualizzata un'opzione. Sviluppare un modulo software "File tessera degli abbonati ATS". Il file della scheda contiene informazioni sui telefoni e sui loro proprietari. Corregge gli arretrati di pagamento (abbonato e a tempo). Si ritiene che sia già stato introdotto il pagamento orario delle telefonate locali. Sviluppare un modulo software "Avtokassa", contenente informazioni sulla disponibilità di posti sulle linee di autobus. Il database dovrebbe contenere informazioni sul numero del volo, la rotta, il conducente, il tipo di autobus, la data e l'ora di partenza, nonché i prezzi dei biglietti. Quando viene ricevuta una domanda per i biglietti, il programma cerca un volo adatto. Sviluppare un modulo software "Bookstore", contenente informazioni sui libri (autore, titolo, editore, anno di pubblicazione, prezzo). L'acquirente compila una domanda per i libri di cui ha bisogno, se non ce ne sono viene inserito nel database e avvisato quando i libri necessari arrivano in negozio. Sviluppare un modulo software "Parcheggio". Il programma contiene informazioni sulla marca dell'auto, il suo proprietario, la data e l'ora di ingresso, i costi di parcheggio, gli sconti, gli arretrati di pagamento, ecc. Sviluppare un modulo software per l'agenzia di reclutamento contenente informazioni sulle offerte di lavoro e sui curricula. Il modulo software è progettato sia per trovare un dipendente che soddisfi i requisiti dei dirigenti dell'azienda, sia per trovare un lavoro adatto.

Nota. Quando sviluppi un programma, non limitarti alle funzioni fornite nella variante, aggiungi alcune delle tue funzioni. È obbligatorio utilizzare approcci strutturali e modulari alla programmazione.

Allegato B

Esempio 1 Sviluppare termini di riferimento per un prodotto software progettato per dimostrare visivamente agli scolari i grafici delle funzioni di un argomento y= f(X). Il programma in fase di sviluppo deve calcolare la tabella dei valori e costruire un grafico di funzioni su un determinato segmento secondo una determinata formula e modificare il passaggio dell'argomento e i confini del segmento. Inoltre, il programma deve ricordare le formule inserite.

1. Introduzione

Questo termine di riferimento si applica allo sviluppo di un programma per l'ordinamento di un array unidimensionale utilizzando i metodi bolla, selezione diretta, Shell e ordinamento rapido, destinato all'uso da parte degli studenti delle scuole superiori durante lo studio di un corso di informatica scolastica. 2. Fondazione per sviluppo

Il programma è sviluppato sulla base del curriculum del Dipartimento di Informatica e Software sistemi informatici". Titolo di lavoro:

"Programma di ordinamento di array unidimensionali".

Esecutore testamentario: società BcstSoft. Collaboratori: ist.

3. Appuntamento Il programma è destinato all'uso da parte degli scolari durante lo studio dell'argomento "Elaborazione di array unidimensionali" nel corso "Informatica". 4. Requisiti per il programma o il prodotto software 4.1. requisiti di prestazione 4.1.1. Il programma dovrebbe fornire la capacità di svolgere le seguenti funzioni:

inserire la dimensione dell'array e l'array stesso; array e archiviazione di memoria; scelta del metodo di smistamento; visualizzazione di una descrizione testuale del metodo di ordinamento; output del risultato di ordinamento.

4.1.2. Dati iniziali:

dimensione dell'array, data come numero intero; Vettore.

Organizzazione dei dati di input e output.

L'input proviene dalla tastiera. L'output viene visualizzato sullo schermo e, se necessario, stampato.

Requisiti di affidabilità

Fornire il controllo delle informazioni di input. Prevedere il blocco delle azioni errate dell'utente quando si lavora con il sistema.

Requisiti per la composizione e parametri dei mezzi tecnici.

Il sistema deve essere eseguito su personal computer compatibili con IBM. Configurazione minima:

tipo di processore Pentium o superiore; la quantità di memoria ad accesso casuale 32 MB o più; la quantità di spazio libero sul disco rigido è di 40 MB.

Configurazione consigliata:

tipo di processore Pentium II 400; la quantità di memoria ad accesso casuale 128 MB; la quantità di spazio libero sul disco rigido è di 60 MB.

4.4. Requisiti di compatibilità software.
Il programma deve essere eseguito con la famiglia di sistemi operativi Win 32 (Windows 95/98/2000/ME/XP, ecc.).

I moduli software sviluppati devono essere autodocumentanti, ovvero i testi del programma devono contenere tutti i commenti necessari. Il programma sviluppato dovrebbe includere informazioni di base sul funzionamento del programma, descrizioni dei metodi di smistamento e suggerimenti per gli studenti. La documentazione di accompagnamento dovrebbe includere:

Nota esplicativa su cinque fogli, contenenti una descrizione dello sviluppo. Guida utente.

Allegato B

Esempio 2 Sviluppare termini di riferimento per lo sviluppo del "Modulo per il sistema automatizzato per il controllo operativo della spedizione della fornitura di calore agli edifici dell'Istituto di Mosca".

1. introduzione

Il lavoro viene svolto nell'ambito del progetto "Sistema automatizzato di controllo operativo della spedizione della fornitura di calore elettrico degli edifici dell'Istituto di Mosca". 2. Fondazione per sviluppo

La base per questo lavoro è il contratto n. 1234 del 10 marzo 2003.

Titolo di lavoro:

"Modulo del sistema automatizzato per il controllo operativo della spedizione della fornitura di calore degli edifici dell'Istituto di Mosca".

Interpreti: OJSC "Laboratorio di creazione di software".

Compagni: no.

3. Scopo dello sviluppo Creazione di un modulo per il monitoraggio e l'adeguamento operativo dello stato dei parametri principali della fornitura degli edifici dell'Istituto di Mosca. 4. Requisiti tecnici 4.1. requisiti di prestazione. 4.1.1. La composizione delle funzioni svolte. Il software sviluppato dovrebbe fornire:

raccolta e analisi delle informazioni sui consumi di calore, caldo e acqua fredda secondo SA-94 contatori di calore in tutte le prese di calore; raccolta e analisi delle informazioni dai dispositivi di controllo per i sistemi di riscaldamento e condizionamento dell'aria come RT1 e RT2 (sviluppo del Dipartimento di SMME e TC); analisi preliminare delle informazioni al fine di trovare i parametri entro limiti accettabili e segnalazione quando i parametri superano i limiti di tolleranza;

emettere raccomandazioni su ulteriori lavori;

visualizzazione dello stato attuale da parte di una serie di parametri - ciclicamente costantemente (funzionamento 24 ore su 24), mantenendo la frequenza di monitoraggio di altri parametri; visualizzazione delle informazioni sul consumo di liquido di raffreddamento:

corrente, simile alle letture dei contatori; con accumulo per l'ultimo giorno, settimana, mese - sotto forma di grafico orario per informazioni per il giorno e la settimana; consumo giornaliero - per informazioni per il mese.

Per i dispositivi di controllo della ventilazione di mandata, le informazioni attuali devono contenere il numero del sistema di alimentazione e tutti i parametri visualizzati sul proprio indicatore. A richiesta si effettuano adeguamenti interni. Al termine del periodo di rendicontazione, il sistema deve archiviare i dati. 4.1.2. Organizzazione dei dati di input e output. I dati iniziali entrano nel sistema sotto forma di valori di sensori installati nei locali dell'istituto. Questi i valori vengono visualizzati sul computer del mittente. Dopo aver analizzato le informazioni ricevute, l'operatore della sala di controllo imposta i parametri necessari per i dispositivi che regolano il riscaldamento e la ventilazione nei locali. È inoltre possibile impostare automaticamente alcuni parametri per i dispositivi di controllo. La modalità principale di utilizzo del sistema è il lavoro quotidiano. 4.2. requisiti di affidabilità. Per garantire l'affidabilità, è necessario verificare la correttezza dei dati ricevuti dai sensori. 4.3. Condizioni operative e requisiti per la composizione e parametri dei mezzi tecnici. Per il funzionamento del sistema deve essere assegnato un operatore responsabile. I requisiti per la composizione e i parametri dei mezzi tecnici sono specificati nella fase della progettazione preliminare del sistema. 4.4. Requisiti per informazioni e compatibilità software. Il programma deve essere eseguito su piattaforme Windows 98/NT/2000.

4.5. Requisiti per il trasporto e lo stoccaggio.

Il programma viene consegnato su un supporto dati laser. La documentazione del programma è fornita in formato elettronico e cartaceo. 4.6. Requisiti speciali:

il software deve avere un'interfaccia user-friendly progettata per le qualifiche dell'utente (in termini di alfabetizzazione informatica); per l'entità del progetto, i compiti dovrebbero essere risolti per fasi, mentre i moduli software creati in momenti diversi dovrebbero prevedere la possibilità di espandere il sistema ed essere compatibili tra loro, quindi la documentazione per l'operativa adottata il software dovrebbe contenere informazioni complete richiesto ai programmatori per lavorarci; linguaggio di programmazione - a scelta dell'appaltatore, dovrebbe fornire la possibilità di integrare il software con alcuni tipi di apparecchiature periferiche (ad esempio contatore SA-94, ecc.).

5. Requisiti per la documentazione del software I principali documenti che regolano lo sviluppo dei programmi futuri dovrebbero essere i documenti del Sistema unificato di documentazione del programma (ESPD): manuale dell'utente, manuale dell'amministratore, descrizione dell'applicazione. 6. Indicatori tecnici ed economici L'efficacia del sistema è determinata dalla facilità d'uso del sistema per il monitoraggio e la gestione dei principali parametri di fornitura di calore ai locali dell'Istituto di Mosca, nonché dai vantaggi economici ottenuti dall'implementazione del complesso hardware e software. 7. Procedura per il controllo e l'accettazione Dopo che l'Appaltatore ha trasferito un modulo funzionale separato del programma al Cliente, quest'ultimo ha il diritto di testare il modulo entro 7 giorni. Dopo il collaudo, il Cliente dovrà accettare l'opera per questa fase o indicare per iscritto il motivo del rifiuto di accettazione. In caso di motivato rifiuto, l'Appaltatore si impegna a modificare il modulo.

1. Termini di riferimento per la fornitura di apparecchiature per lo sviluppo dell'infrastruttura informatica dei vigili del fuoco e del servizio di pronto intervento. Oggetto del contratto statale

   Compito tecnico

   per la fornitura di apparecchiature per lo sviluppo dell'infrastruttura informatica dei vigili del fuoco e del servizio di pronto intervento.

2. Termini di riferimento per un complesso di opere di progettazione e costruzione

   Compito tecnico

   2.1. L'esecuzione dei lavori ai sensi del presente mandato implica l'esecuzione da parte dell'Appaltatore dell'intera gamma di rilievo, progettazione e lavori di costruzione per la ricostruzione (attrezzamento, riqualificazione) dell'impianto di costruzione chiavi in ​​mano, incl.

3. Termini di riferimento per l'attuazione del lavoro sulla creazione di un sito di fogli

   Compito tecnico

   requisiti di RD 50-34.698-90 “Linee guida. Tecnologie dell'informazione. Un insieme di standard e linee guida per sistemi automatizzati.

4. Termini di riferimento per lo svolgimento di un'indagine sulle condizioni tecniche dei condomini per riparazioni importanti. Sistema a bassa corrente. Comunicazione, allarme, sicurezza

   Compito tecnico

   Il sistema di allarme antincendio automatico, così come il sistema di allarme e di controllo dell'evacuazione, è parte integrante dei sistemi di supporto vitale degli edifici.

5. Mandato Lotto n. 1 Fornitura di letteratura straniera per la biblioteca di SevKavgtu

   Compito tecnico

   Modalità di determinazione del prezzo del contratto: il prezzo del contratto deve comprendere tutte le spese del Fornitore relative all'adempimento del contratto, comprese le spese di consegna, scarico della letteratura nei locali della biblioteca, pagamento dell'IVA e pagamento

6. Termini di riferimento per la documentazione di un'asta aperta in formato elettronico n. 624-ea per il diritto di concludere

   Compito tecnico

   2. Requisiti per la durata e (o) l'ambito di fornitura delle garanzie di qualità del prodotto: il periodo di garanzia per il prodotto consegnato deve essere di almeno 24 mesi dalla data di messa in servizio.

In questo articolo ho cercato di considerare in dettaglio il problema dello sviluppo dei Termini di Riferimento. L'argomento è vecchio quanto il problema. Ma è ancora spesso risolto "come va".
Come disse Henry Shaw, "Sono le piccole cose che ci preoccupano di più: è più facile schivare un elefante che una mosca".

Sviluppo di specifiche tecniche. Che cos'è, perché è necessario, da dove iniziare e come dovrebbe essere?

Di cosa tratta questo articolo?

Spesso mi viene chiesto: "Come sviluppare un compito tecnico per un sistema automatizzato?". Un argomento simile viene costantemente discusso in vari forum. Questa domanda è così ampia che è impossibile rispondere in poche parole. Pertanto, ho deciso di scrivere un lungo articolo su questo argomento. Durante il lavoro sull'articolo, mi sono reso conto che non avrebbe funzionato mettere tutto in un articolo, perché. risulterà sotto le 50 pagine e ho deciso di suddividerlo in 2 parti:

• Nella prima parte" Sviluppo di specifiche tecniche. Che cos'è, perché è necessario, da dove iniziare e come dovrebbe apparire? Cercherò di rispondere in dettaglio alle domande dell'argomento, di considerare la struttura e lo scopo del capitolato d'oneri e di fornire alcune raccomandazioni sulla formulazione dei requisiti.
• Seconda parte " Sviluppo di specifiche tecniche. Come formulare i requisiti? sarà interamente dedicato all'identificazione e alla formulazione dei requisiti per sistema informativo.

Per prima cosa è necessario capire qual è realmente la domanda di interesse per coloro che si chiedono "Come sviluppare i termini di riferimento?" Il fatto è che l'approccio allo sviluppo delle specifiche tecniche dipenderà molto dagli scopi per cui ciò viene fatto e anche da chi verrà utilizzato. Di quali opzioni sto parlando?

• 
  Un'organizzazione commerciale ha deciso di implementare un sistema automatizzato. Non dispone di un proprio servizio informatico e ha deciso di farlo: l'interessato deve sviluppare il capitolato e consegnarlo a un'organizzazione terza per lo sviluppo;
• Un'organizzazione commerciale ha deciso di implementare un sistema automatizzato. Dispone di un proprio servizio IT. Abbiamo deciso di fare questo: sviluppare un Termini di riferimento, quindi coordinarlo tra il servizio IT e le parti interessate e implementarlo per conto nostro;
• La struttura statale ha deciso di avviare un progetto informatico. Qui è tutto così fangoso, molte formalità, contraccolpi, tagli, ecc. Non prenderò in considerazione questa opzione in questo articolo.
• Un'azienda IT è impegnata in servizi per lo sviluppo e/o l'implementazione di sistemi automatizzati. Questo è il massimo caso difficile, perché devi lavorare in una varietà di condizioni:
  • Il cliente ha i propri specialisti con le proprie opinioni e hanno requisiti specifici per i Termini di riferimento;
  • I termini di riferimento sono sviluppati per i nostri sviluppatori (al cliente non importa);
  • I termini di riferimento sono sviluppati per il trasferimento all'appaltatore (ovvero un gruppo di programmatori esterni al personale dell'azienda o un singolo specialista);
  • C'è un malinteso tra le aziende e il cliente in merito al risultato ottenuto, e l'azienda si pone più e più volte la domanda: “Come dovrebbero essere sviluppati i Termini di Riferimento?”. Quest'ultimo caso può sembrare un paradosso, ma è vero.
  • Sono possibili anche altre opzioni meno comuni;

Penso che ora il lettore dovrebbe avere delle domande:

• Perché i Termini di riferimento non possono essere sviluppati sempre allo stesso modo?
• Ci sono standard, metodi, raccomandazioni? Dove trovarli?
• Chi dovrebbe sviluppare i Termini di riferimento? Questa persona ha bisogno di avere qualche conoscenza speciale?
• Come capire se i termini di riferimento sono scritti bene o meno?
• A spese di chi dovrebbe essere sviluppato ed è necessario?

Questa lista potrebbe essere infinita. Parlo in modo così sicuro perché mi occupo di sviluppo software professionale da 15 anni e la questione dei Termini di riferimento si apre in qualsiasi team di sviluppatori con cui devo lavorare. Le ragioni di ciò sono diverse. Sollevando il tema dello sviluppo dei Termini di Riferimento, sono ben consapevole che non potrò presentarlo al 100% per tutti coloro che sono interessati all'argomento. Ma proverò, come si suol dire, a "mettere tutto sugli scaffali". Chi ha già familiarità con i miei articoli sa che non uso il "copia-incolla" del lavoro di altre persone, non ristampa i libri di altre persone, non cito standard multipagina e altri documenti che tu stesso puoi trovare su Internet, spacciandoli per i tuoi pensieri brillanti. Basta digitare nel motore di ricerca "Come sviluppare i termini di riferimento" e potrai leggere molti articoli interessanti, ma, purtroppo, ripetuti molte volte. Di norma, coloro a cui piace essere intelligenti sui forum (prova a cercare dopo tutto!), Non hanno mai creato termini di riferimento sensati e citano continuamente i consigli GOST su questo argomento. E coloro che affrontano seriamente la questione di solito non hanno tempo per sedersi sui forum. A proposito, parleremo anche di GOST. Nel corso degli anni del mio lavoro, ho visto molte varianti di documentazione tecnica compilate sia da singoli specialisti che da eminenti team e società di consulenza. A volte svolgo anche queste attività: dedico tempo a me stesso e cerco informazioni su un argomento di interesse da fonti insolite (un po' di intelligenza). Di conseguenza, ho dovuto vedere la documentazione su mostri come Gazprom, Russian Railways e molte altre società interessanti. Ovviamente mi attengo alla politica di riservatezza, nonostante il fatto che questi documenti mi provengano da fonti pubbliche o dall'irresponsabilità dei consulenti (diffondono informazioni su Internet). Pertanto, dico subito: non condivido informazioni riservate che appartengono ad altre società, indipendentemente dalle fonti di accadimento (etica professionale).

Che cos'è un compito tecnico?

La prima cosa che faremo ora è capire che tipo di animale è questo, i "Termini di riferimento".

Sì, esistono infatti GOST e standard in cui si tenta di regolare questa parte dell'attività (sviluppo software). C'era una volta, tutti questi GOST erano rilevanti e utilizzati attivamente. Ora ci sono opinioni diverse sulla rilevanza di questi documenti. Alcuni sostengono che i GOST siano stati sviluppati da persone molto lungimiranti e siano ancora rilevanti. Altri dicono che sono irrimediabilmente obsoleti. Forse qualcuno ora ha pensato che la verità è da qualche parte nel mezzo. Risponderei con le parole di Goethe: “Dicono che tra due opposte opinioni stia la verità. In nessun caso! Tra loro c'è un problema". Quindi, non c'è verità tra queste opinioni. Perché i GOST non rivelano i problemi pratici dello sviluppo moderno e chi li critica non offre alternative (specifiche e sistemiche).

Si noti che il GOST chiaramente non fornisce nemmeno una definizione, dice solo: “Il TOR per la NPP è il documento principale che definisce i requisiti e la procedura per la creazione (sviluppo o ammodernamento - ulteriore creazione) di un sistema automatizzato, in conformità con cui viene effettuato lo sviluppo della centrale nucleare e la sua accettazione al momento della messa in atto."

Se qualcuno si chiede di quali GOST sto parlando, eccoli qui:

• GOST 2.114-95 un sistema documentazione progettuale. Specifiche;
• GOST 19.201-78 Sistema unificato di documentazione del programma. Compito tecnico. Requisiti per contenuto e design;
• GOST 34.602-89 Informatica. Set di standard per i sistemi automatizzati. Termini di riferimento per la creazione di un sistema automatizzato.

Una definizione molto migliore è presentata su Wikipedia (la verità su TK in generale, e non solo per il software): “ Compito tecnicoè il documento di progettazione originale tecnico oggetto. Compito tecnico stabilisce lo scopo principale dell'oggetto in fase di sviluppo, le sue caratteristiche tecniche e tattiche e tecniche, gli indicatori di qualità e i requisiti tecnici ed economici, le istruzioni per completare le fasi necessarie di creazione della documentazione (progettuale, tecnologica, software, ecc.) e la sua composizione, come nonché requisiti speciali. In tutte le aree di attività esiste un'attività come documento di partenza per la creazione di qualcosa di nuovo, che differisce per nome, contenuto, ordine di esecuzione, ecc. (ad esempio, un'attività di progettazione in costruzione, un'attività di combattimento, i compiti a casa, un contratto per opera letteraria eccetera.)"

E quindi, come risulta dalla definizione, lo scopo principale del capitolato è di formulare requisiti per l'oggetto in via di sviluppo, nel nostro caso, per un sistema automatizzato.

È il principale, ma l'unico. È ora di affrontare la cosa principale: mettere tutto "sugli scaffali", come promesso.

Cosa devi sapere sui requisiti? Deve essere chiaro che tutti i requisiti devono essere suddivisi per tipologia e per proprietà. Ora impareremo come farlo. Per separare i requisiti per tipo, GOST ci aiuterà. L'elenco dei tipi di requisiti che viene presentato è un buon esempio di quali tipi di requisiti dovrebbero essere considerati. Per esempio:

• requisiti di funzionalità;
• Requisiti di sicurezza e diritti di accesso;
• Requisiti per la qualificazione del personale;
• …. Eccetera. Puoi leggere su di loro nel menzionato GOST (e di seguito li considererò anche un po 'più in dettaglio).

Penso che sia ovvio per te che requisiti di funzionalità ben formulati sono la chiave per un Termini di riferimento di successo. Sono questi requisiti che sono dedicati alla maggior parte dei lavori e dei metodi di cui ho parlato. I requisiti di funzionalità rappresentano il 90% della complessità dello sviluppo del mandato. Tutto il resto è spesso "mimetizzazione" che viene messa su questi requisiti. Se i requisiti sono formulati male, non importa quale bel camuffamento ci metti, un progetto di successo non funzionerà. Sì, formalmente tutti i requisiti saranno soddisfatti (secondo GOST J), il TOR è stato sviluppato, approvato e firmato e sono stati ricevuti soldi per questo. E allora? E poi inizia il divertimento: cosa fare? Se questo è un progetto sull'ordine statale, allora non ci sono problemi: c'è un budget tale che non entrerà in nessuna tasca, tutto sarà chiarito nel processo di attuazione (se esiste). Questo è esattamente il modo in cui vengono segati la maggior parte dei budget dei progetti sugli ordini statali (hanno acceso "TK", hanno unito dieci milioni, ma non hanno iniziato a realizzare il progetto. Tutte le formalità sono state soddisfatte, non c'erano colpevoli, una nuova macchina vicino la casa. Bellezza!). Ma stiamo parlando organizzazioni commerciali dove viene contato il denaro ed è necessario un risultato diverso. Pertanto, affrontiamo la cosa principale, come sviluppare Termini di riferimento utili e funzionanti.

Ho detto dei tipi di requisiti, ma per quanto riguarda le proprietà? Se i tipi di requisiti possono essere diversi (a seconda degli obiettivi del progetto), allora con le proprietà tutto è più semplice, ce ne sono 3:

1. Il requisito deve essere comprensibile;
2. Il requisito deve essere specifica;
3. Il requisito deve essere testato;

Inoltre, l'ultima proprietà è impossibile senza le due precedenti, cioè è una sorta di "cartina di tornasole". Se il risultato di un requisito non può essere verificato, allora non è chiaro o non è specifico. Pensaci. È nel possesso di queste tre proprietà di requisiti che risiedono competenza e professionalità. In effetti, tutto è molto semplice. Quando lo capisci.

Su questa storia su cosa sia un Termini di Riferimento, si potrebbe completare e passare alla cosa principale: come formulare i requisiti. Ma non è tutto così veloce. C'è un altro punto estremamente importante:

• in quale lingua (in termini di complessità di comprensione) dovrebbero essere scritti i termini di riferimento?
• Dovrebbe essere descritta la specifica di varie funzioni, algoritmi, tipi di dati e altre cose tecniche?
• E cos'è il design tecnico, che, tra l'altro, è menzionato anche nei GOST e in che modo è correlato ai Termini di riferimento?

C'è una cosa molto insidiosa nelle risposte a queste domande. Ecco perché spesso sorgono controversie sulla sufficienza o assenza della necessaria indicazione dei requisiti, sulla comprensibilità del documento da parte del Committente e degli Appaltatori, sulla ridondanza, sul formato di presentazione, ecc. E dov'è il confine tra il capitolato d'oneri e il progetto tecnico?

Compito tecnico- trattasi di un documento basato su requisiti formulati in un linguaggio comprensibile (normale, familiare) per il Cliente. In questo caso, può e deve essere utilizzata una terminologia di settore comprensibile per il Cliente. Non dovrebbero esserci vincoli con le caratteristiche dell'implementazione tecnica. Quelli. nella fase TK, in linea di principio, non importa su quale piattaforma verranno implementati questi requisiti. Anche se ci sono delle eccezioni. Se stiamo parlando dell'implementazione di un sistema basato su un prodotto software esistente, allora tale associazione può aver luogo, ma solo a livello di schermate, moduli di segnalazione, ecc. analista di affari. E non certo un programmatore (a meno che non combini questi ruoli, questo succede). Quelli. questa persona dovrebbe parlare con il Cliente nella lingua della sua attività.

Progetto tecnicoè un documento destinato all'attuazione tecnica dei requisiti formulati nel capitolato d'oneri. Proprio questo documento descrive strutture di dati, trigger e procedure memorizzate, algoritmi e altre cose che saranno richieste specialisti tecnici. Non è affatto necessario che il cliente approfondisca questo aspetto (potrebbe non comprendere tali termini). Il progetto tecnico sì Architetto di sistema(Qui, la combinazione di questo ruolo con il programmatore è abbastanza normale). O meglio, un gruppo di specialisti guidati da un architetto. Più grande è il progetto, più persone lavorano sui Termini di riferimento.

Cosa abbiamo in pratica? È divertente vedere quando il regista viene portato per l'approvazione dal Termini di riferimento, che è pieno di terminologia tecnica, descrizioni dei tipi di dati e dei loro valori, struttura del database, ecc. Lui, ovviamente, cerca di capire, poiché è necessario per affermare, cercando di trovare parole familiari tra le righe e non perdere i requisiti della filiera. Quale, situazione familiare? E come finisce? Di norma, tale TOR viene approvato, quindi attuato, e nell'80% dei casi poi non corrisponde affatto al fatto del lavoro svolto, perché molte cose hanno deciso di cambiare, rifare, frainteso, pensato male, ecc. eccetera. E poi inizia la serie di consegna. "Ma qui non è il modo in cui ne abbiamo bisogno", ma "non funzionerà per noi", "è troppo complicato", "è scomodo", ecc. Familiare?! Quindi lo so, ho dovuto riempire i dossi a tempo debito.

Quindi cosa abbiamo in pratica? Ma in pratica, abbiamo un confine sfumato tra i Termini di Riferimento e il Progetto Tecnico. Fluttua tra TK e TP in vari modi. E questo è male. E si scopre così perché la cultura dello sviluppo è diventata debole. Ciò è in parte dovuto alla competenza degli specialisti, in parte al desiderio di ridurre budget e scadenze (dopotutto, la documentazione richiede molto tempo - questo è un dato di fatto). C'è un altro fattore importante che influenza l'uso del disegno tecnico come documento separato: il rapido sviluppo di strumenti di sviluppo rapido, nonché metodologie di sviluppo. Ma questa è una storia a parte, dirò alcune parole al riguardo di seguito.

Un altro piccolo ma importante punto. A volte i Termini di riferimento sono chiamati piccoli requisiti, semplici e comprensibili. Ad esempio, per affinare la ricerca di un oggetto in base ad alcune condizioni, aggiungere una colonna al report, ecc. Questo approccio è abbastanza giustificato, perché complicare la vita. Ma non viene utilizzato su grandi progetti, ma su miglioramenti minori. Direi che questo è più vicino alla manutenzione del prodotto software. In questo caso, i Termini di riferimento possono anche descrivere uno specifico soluzione tecnica attuazione del requisito. Ad esempio, "Per apportare tale e tale modifica all'algoritmo", indicando una procedura specifica e una modifica specifica per il programmatore. Questo è il caso in cui il confine tra il mandato e i progetti tecnici è completamente cancellato, perché non c'è fattibilità economica per gonfiare le scartoffie dove non è necessario e si crea un documento utile. Ed è giusto.

Hai davvero bisogno di una specifica tecnica? E il progetto di ingegneria?

Sono surriscaldato? È possibile anche senza termine di paragone? Immagina forse (più precisamente, si verifica), e questo approccio ha molti seguaci e il loro numero è in aumento. Di norma, dopo che i giovani specialisti hanno letto libri su Scrum, Agile e altre tecnologie di sviluppo rapido. In effetti, queste sono tecnologie meravigliose e funzionano, solo che non dicono letteralmente "non c'è bisogno di svolgere compiti tecnici". Dicono “un minimo di scartoffie”, soprattutto inutili, più vicine al Cliente, più specifiche e risultati più rapidi. Ma nessuno ha annullato la fissazione dei requisiti, ed è chiaramente indicato lì. È lì che i requisiti vengono fissati in base alle tre meravigliose proprietà di cui ho parlato sopra. È solo che la coscienza di alcune persone è organizzata in modo tale che se qualcosa può essere semplificato, semplifichiamolo per completare l'assenza. Come disse Einstein " Rendilo il più semplice possibile, ma non più semplice di così". . Parole d'oro vanno con tutto. Così che Compito tecnico necessario, altrimenti non vedrai un progetto di successo. Un'altra domanda è come comporre e cosa includere lì. Alla luce delle metodologie di sviluppo rapido, è necessario concentrarsi solo sui requisiti e tutto il "camuffamento" può essere scartato. Fondamentalmente, sono d'accordo con questo.

E il progetto tecnico? Questo documento è molto utile e non ha perso la sua rilevanza. Inoltre, spesso è semplicemente impossibile farne a meno. Soprattutto quando si tratta di esternalizzare il lavoro di sviluppo, ad es. sul principio dell'esternalizzazione. Se ciò non viene fatto, c'è il rischio di imparare molto su come dovrebbe essere il sistema che hai in mente. Il cliente dovrebbe conoscerlo? Se vuole perché no, ma insistere e affermare questo documento non è necessario, si tratterà solo e interferirà con il lavoro. È quasi impossibile progettare un sistema nei minimi dettagli. In questo caso, dovrai apportare continuamente modifiche al Progetto Tecnico, che richiede molto tempo. E se l'organizzazione è pesantemente burocratizzata, in genere lascia lì tutti i nervi. È proprio questo tipo di riduzione del design che viene discusso nelle moderne metodologie di sviluppo rapido, che ho menzionato sopra. A proposito, sono tutti basati sul classico approccio XP (programmazione estrema), che ha già circa 20 anni. Quindi redigere un Regolamento di riferimento di alta qualità, comprensibile per il Cliente, e utilizzare il Progetto Tecnico come documento interno per la relazione tra l'architetto di sistema e i programmatori.

Un dettaglio interessante sulla progettazione tecnica: alcuni strumenti di sviluppo disposti secondo il principio dell'orientamento alla materia (come 1C e simili) suggeriscono che la progettazione (intendendo il processo di documentazione) è richiesta solo per zone difficili, dove è richiesta l'interazione tra interi sottosistemi. Nel caso più semplice, ad esempio, per creare un libro di consultazione, un documento, sono sufficienti solo i requisiti aziendali correttamente formulati. Ciò è dimostrato dalla strategia aziendale di questa piattaforma in termini di specialisti della formazione. Se guardi il biglietto d'esame di uno specialista (è così che si chiama, e non un "programmatore"), vedrai che ci sono solo requisiti aziendali lì e come implementarli in un linguaggio di programmazione è compito di uno specialista. Quelli. quella parte del compito che il progetto tecnico è destinato a risolvere, lo specialista deve risolvere "nella testa" (si tratta di compiti di media complessità), e qui e ora, seguendo determinati standard di sviluppo e progettazione, che sono ancora una volta formata dalla società 1C per la sua piattaforma. Quindi, su due specialisti, il cui risultato del lavoro sembra lo stesso, uno può superare l'esame e il secondo no, perché. standard di sviluppo gravemente violati. Cioè, si presume ovviamente che gli specialisti debbano avere qualifiche tali da poter progettare da soli compiti tipici, senza coinvolgere architetti di sistema. E questo approccio funziona.

Continuiamo lo studio della domanda: "Quali requisiti dovrebbero essere inclusi nel capitolato?"

Formulazione dei requisiti per il sistema informativo. Struttura dei termini di riferimento

Mettiamo subito in chiaro: si parlerà della formulazione dei requisiti per un sistema informativo, ad es. presupponendo che il lavoro di sviluppo dei requisiti aziendali, di formalizzazione dei processi aziendali e di tutte le precedenti attività di consulenza sia già stato completato. Naturalmente, in questa fase possono essere eseguiti alcuni perfezionamenti, ma solo perfezionamenti. Il progetto di automazione in sé non risolve i problemi aziendali: tienilo a mente. Questo è un assioma. Per qualche ragione, alcuni manager stanno cercando di confutarlo, credendo che se acquistano il programma, l'ordine arriverà in un affare caotico. Ma dopo tutto, un assioma è un assioma che non richiede prove.

Come per qualsiasi attività, la formulazione dei requisiti può (e dovrebbe) essere suddivisa in fasi. Tutto ha il suo tempo. Questo è un duro lavoro intellettuale. E, se viene trattato con attenzione insufficiente, il risultato sarà appropriato. Secondo le stime degli esperti, il costo per lo sviluppo dei Termini di riferimento può essere del 30-50%. Sono della stessa opinione. Anche se 50 è forse troppo. Dopotutto, i Termini di riferimento non sono l'ultimo documento ad essere sviluppato. Dopotutto, ci deve essere anche il design tecnico. Questa variazione è dovuta a diverse piattaforme di automazione, approcci e tecnologie utilizzate dai team di progetto durante lo sviluppo. Ad esempio, se stiamo parlando di sviluppo in un linguaggio classico come il C++, allora la progettazione tecnica dettagliata è indispensabile. Se stiamo parlando dell'implementazione di un sistema sulla piattaforma 1C, la situazione con il design è leggermente diversa, come abbiamo visto sopra (sebbene, quando si sviluppa un sistema da zero, sia progettato secondo lo schema classico).

Nonostante la dichiarazione dei requisiti sia la parte principale del capitolato e in alcuni casi diventi l'unica sezione del TOR, dovresti prestare attenzione al fatto che si tratta di un documento importante e dovrebbe essere redatto di conseguenza. Da dove cominciare? Prima di tutto, devi iniziare con il contenuto. Componi il contenuto e quindi inizia a srotolarlo. Personalmente, faccio questo: prima delineo il contenuto, descrivo gli obiettivi, tutte le informazioni introduttive e poi mi occupo della parte principale: la formulazione dei requisiti. Perché non viceversa? Non lo so, per me è più comodo. In primo luogo, questa è una parte del tempo molto più piccola (rispetto ai requisiti) e in secondo luogo, mentre descrivi tutte le informazioni introduttive, ti sintonizzi sulla cosa principale. Bene, a chi piace. Nel tempo, svilupperai il tuo modello di Termini di riferimento. Per cominciare, consiglio di prendere come contenuto esattamente quello descritto in GOST. È fantastico per i contenuti! Quindi prendiamo e iniziamo a descrivere ogni sezione, senza dimenticare le raccomandazioni per le seguenti tre proprietà: comprensibilità, specificità e testabilità. Perché insisto così tanto su questo? Maggiori informazioni su questo nella prossima sezione. E ora propongo a tutto tatto di passare attraverso quei punti del TK che sono raccomandati in GOST.

1. Informazione Generale;
2. scopo e obiettivi di creazione (sviluppo) del sistema;
3. caratteristiche degli oggetti di automazione;
4. requisiti di sistema;
5. composizione e contenuto del lavoro sulla creazione del sistema;
6. procedura per il controllo e l'accettazione del sistema;
7. requisiti per la composizione e il contenuto del lavoro per preparare l'oggetto di automazione per la messa in funzione del sistema;
8. requisiti di documentazione;
9. fonti di sviluppo.

Totale, 9 sezioni, ognuna delle quali è anche suddivisa in sottosezioni. Prendiamoli in ordine. Per comodità, presenterò tutto sotto forma di tabella per ogni articolo.

Sezione 1. Informazioni generali.

	Cosa farne in pratica
nome completo del sistema e relativo simbolo;	Qui tutto è chiaro: scriviamo come si chiamerà il sistema, il suo nome breve
cifra dell'argomento o cifra (numero) del contratto;	Questo non è rilevante, ma è possibile specificare se necessario.
il nome delle imprese (associazioni) dello sviluppatore e del cliente (utente) del sistema e dei loro dettagli;	indicare chi (quali organizzazioni) lavorerà al progetto. Puoi anche specificare i loro ruoli. In genere puoi eliminare questa sezione (piuttosto formale).
un elenco dei documenti in base ai quali viene creato il sistema, da chi e quando tali documenti sono stati approvati;	Informazioni utili. Qui dovresti indicare la documentazione normativa e di riferimento che ti è stata fornita per familiarizzare con una determinata parte dei requisiti
date previste per l'inizio e il completamento dei lavori per la creazione del sistema;	Auguri di tempismo. A volte ne scrivono nel TOR, ma più spesso queste cose sono descritte nei contratti di lavoro
informazioni sulle fonti e sulle modalità di finanziamento dell'opera;	Allo stesso modo, come nel paragrafo precedente sulla tempistica. Più rilevante per gli ordini del governo (per i dipendenti statali)
la procedura per formalizzare e presentare al cliente i risultati del lavoro sulla creazione del sistema (le sue parti), sulla fabbricazione e regolazione di singoli mezzi (hardware, software, informazioni) e complessi software e hardware (software e metodologici) di il sistema.	Non vedo la necessità di questo paragrafo, tk. gli adempimenti per la documentazione sono formulati separatamente e, oltre a ciò, esiste un'intera sezione separata "Procedura di controllo e accettazione" del sistema.

Sezione 2. Scopo e obiettivi della creazione (sviluppo) del sistema.

	Cosa farne in pratica
Scopo del sistema	Da un lato, l'appuntamento è semplice. Ma vorrei essere specifico. Se scrivi qualcosa come "automazione di alta qualità del controllo dell'inventario nell'azienda X", puoi discutere il risultato a lungo una volta completato, anche indipendentemente dalla buona formulazione dei requisiti. Perché Il cliente può sempre dire che intendeva qualcos'altro per qualità. In generale, i nervi possono rovinarsi molto a vicenda, ma perché? È meglio scrivere immediatamente qualcosa del genere: "Il sistema è progettato per mantenere i registri di magazzino nell'azienda X in conformità con i requisiti fissati in questo Termini di riferimento".
Gli obiettivi della creazione di un sistema	Obiettivi: questa è sicuramente una sezione importante. Se lo accendiamo, allora dobbiamo essere in grado di formulare questi obiettivi. Se hai difficoltà con la formulazione degli obiettivi, è meglio escludere del tutto questa sezione. Un esempio di obiettivo non riuscito: "Garantire una rapida burocrazia da parte del manager". Cos'è veloce? Questo può quindi essere dimostrato all'infinito. Se questo è importante, allora è meglio riformulare questo obiettivo come segue: "Il responsabile delle vendite dovrebbe essere in grado di emettere un documento" Vendita di merci "di 100 righe in 10 minuti". Un tale obiettivo può apparire se, ad esempio, il manager attualmente dedica circa un'ora a questo, il che è troppo per questa azienda ed è importante per loro. In questa formulazione, l'obiettivo si interseca già con i requisiti, il che è del tutto naturale, perché. quando si espande l'albero degli obiettivi (cioè suddividendoli in obiettivi correlati più piccoli), ci avvicineremo già ai requisiti. Pertanto, non dovresti lasciarti trasportare. In generale, la capacità di identificare gli obiettivi, formularli, costruire un albero di obiettivi è un argomento completamente separato. Ricorda la cosa principale: se sai come - scrivi, se non sei sicuro - non scrivere affatto. Cosa succede se non stabilisci obiettivi? Lavorerai secondo i requisiti, questo è spesso praticato.

Sezione 3. Caratteristiche degli oggetti di automazione.

Sezione 4 Requisiti di sistema

	Cosa farne in pratica
Requisiti generali di sistema. GOST decifra l'elenco di tali requisiti: requisiti per la struttura e il funzionamento del sistema; requisiti per il numero e le qualifiche del personale del sistema e le modalità del suo lavoro; indicatori di destinazione; requisiti di affidabilità; Requisiti di sicurezza; requisiti di ergonomia ed estetica tecnica; requisiti di trasportabilità per AS mobili; requisiti operativi, Manutenzione, riparazione e stoccaggio di componenti di sistema; requisiti per la protezione delle informazioni da accessi non autorizzati; requisiti per la sicurezza delle informazioni in caso di incidenti; requisiti per la protezione dall'influenza di influenze esterne; requisiti per la purezza del brevetto; requisiti per la standardizzazione e l'unificazione;	Nonostante il fatto che la principale, ovviamente, sarà la sezione con requisiti specifici (funzionali), anche questa sezione può avere Grande importanza(e nella maggior parte dei casi lo ha). Cosa può essere importante e utile: Requisiti di qualificazione . È possibile che il sistema in fase di sviluppo richieda la riqualificazione di specialisti. Può essere come gli utenti sistema futuro e gli specialisti IT che saranno necessari per supportarlo. Un'attenzione insufficiente a questo problema spesso si trasforma in problemi. Se le qualifiche del personale esistente sono palesemente insufficienti, è meglio prescrivere i requisiti per l'organizzazione della formazione, il programma di formazione, i termini, ecc. Requisiti per la protezione delle informazioni da accessi non autorizzati. Non ci sono commenti qui. Questi sono esattamente i requisiti per il controllo dell'accesso ai dati. Se tali requisiti sono pianificati, devono essere scritti separatamente, nel modo più dettagliato possibile secondo le stesse regole dei requisiti funzionali (comprensibilità, specificità, testabilità). Pertanto, questi requisiti possono essere inclusi nella sezione con i requisiti funzionali. Requisiti per la standardizzazione. Se esistono standard di sviluppo applicabili al progetto, possono essere inclusi nei requisiti. Di norma, tali requisiti sono avviati dal servizio informatico del Cliente. Ad esempio, la società 1C ha requisiti per la progettazione del codice del programma, la progettazione dell'interfaccia, ecc.; Requisiti per la struttura e il funzionamento del sistema. Qui possono essere descritti i requisiti per l'integrazione dei sistemi tra loro, viene presentata una descrizione dell'architettura generale. Più spesso, i requisiti di integrazione sono individuati in generale in una sezione separata o anche in un Termini di riferimento separato, perché questi requisiti possono essere piuttosto complessi. Tutti gli altri requisiti sono meno importanti e possono essere tralasciati. A mio avviso, non fanno che appesantire la documentazione e sono di scarsa utilità pratica. Ed è molto difficile descrivere i requisiti per l'ergonomia sotto forma di requisiti generali, è meglio trasferirli in quelli funzionali. Ad esempio, può essere formulato il requisito "Ottieni informazioni sul prezzo di un prodotto premendo un solo pulsante". Questo, a mio avviso, è ancora più vicino a specifici requisiti funzionali, sebbene si riferisca all'ergonomia.
Requisiti per le funzioni (compiti) svolte dal sistema	Eccolo, il punto principale e chiave che determinerà il successo. Anche se tutto il resto è fatto perfettamente e questa sezione è su "3", il risultato per il progetto sarà al massimo "3" o anche il progetto fallirà. Questi sono quelli di cui ci occuperemo più in dettaglio nel secondo articolo. È a questo punto che si applica la “regola delle tre proprietà dei requisiti” di cui ho parlato.
Requisiti per i tipi di garanzie GOST distingue i seguenti tipi: Matematico informativo Linguistico Software Tecnico metrologico Organizzativo metodico Altro…	A prima vista, può sembrare che questi requisiti non siano importanti. Questo è vero per la maggior parte dei progetti. Ma non sempre. Quando descrivere questi requisiti: Non è stata presa alcuna decisione su quale lingua (o piattaforma) verrà sviluppato; Il sistema è soggetto ai requisiti di un'interfaccia multilingue (ad esempio, russo/inglese) Per il funzionamento del sistema è necessario creare un'unità separata o assumere nuovi dipendenti; Affinché il sistema funzioni, il Cliente deve subire modifiche nei metodi di lavoro e tali modifiche devono essere specificate e pianificate; Si suppone l'integrazione con alcune apparecchiature e ad essa vengono imposti requisiti (ad esempio, certificazione, compatibilità, ecc.) Altre situazioni sono possibili, tutto dipende dagli obiettivi specifici del progetto.

Sezione 5. Composizione e contenuto del lavoro sulla creazione del sistema

Sezione 6. Procedura per il controllo e l'accettazione del sistema

Cosa farne in pratica

Tipologie, composizione, ambito e modalità di collaudo del sistema e dei suoi componenti (tipi di collaudo secondo le norme vigenti applicabili al sistema in via di sviluppo); Requisiti generali per l'accettazione del lavoro per fasi (elenco delle imprese e organizzazioni partecipanti, luogo e tempi), la procedura per concordare e approvare la documentazione di accettazione;

Ma anche la presenza di requisiti verificabili potrebbe non essere sufficiente al momento della consegna del sistema, se la procedura di accettazione e trasferimento dei lavori non è chiaramente esplicitata. Ad esempio, una trappola comune: il sistema è fatto, è perfettamente funzionante, ma il Cliente, per qualche motivo, non è pronto a lavorarci. Questi motivi possono essere qualsiasi: una volta, gli obiettivi sono cambiati, qualcuno ha smesso, ecc. E dice: “Dato che non stiamo ancora lavorando nuovo sistema, quindi non possiamo essere sicuri che funzioni. Quindi impara a identificare correttamente le fasi del lavoro, i modi per verificare i risultati di queste fasi. Inoltre, tali metodi dovrebbero essere chiari al Cliente sin dall'inizio. Se sono fissati a livello di Termini di riferimento, puoi sempre contattarli se necessario e completare il lavoro con il trasferimento.

Sezione 7. Requisiti per la composizione e il contenuto del lavoro per preparare l'oggetto di automazione per la messa in funzione del sistema

	Cosa farne in pratica
Portare le informazioni in ingresso nel sistema (secondo i requisiti per il supporto informativo e linguistico) in una forma idonea ad essere elaborata tramite un computer;	Un punto molto importante. Ad esempio, affinché il sistema funzioni come previsto, potrebbe essere necessario utilizzare qualsiasi industria o directory e classificatori tutti russi. Queste directory devono in qualche modo apparire nel sistema, essere aggiornate e utilizzate correttamente. Potrebbero esserci altre regole per l'inserimento delle informazioni adottate dall'azienda (o previste). Ad esempio, le informazioni sul contratto venivano inserite come riga di testo in una forma arbitraria, ma ora il numero è richiesto separatamente, la data separatamente, ecc. Ci possono essere molte di queste condizioni. Alcuni di essi possono essere percepiti con la resistenza del personale, quindi è meglio registrare tutti questi casi a livello di requisiti per l'ordine di inserimento dei dati
Modifiche da apportare all'oggetto automazione Creazione delle condizioni per il funzionamento dell'oggetto automazione, in base alle quali è garantita la conformità dell'impianto realizzato ai requisiti contenuti nel TOR	Eventuali modifiche che potrebbero essere necessarie. Ad esempio, l'azienda non ha la rete locale, un parco computer obsoleto su cui il sistema non funzionerà. Forse alcuni le informazioni necessarie elaborato su carta, e ora deve essere inserito nel sistema. In caso contrario, alcuni moduli non funzioneranno, ecc. Forse qualcosa è stato semplificato, ma ora deve essere preso in considerazione in modo più dettagliato, quindi qualcuno deve raccogliere informazioni secondo determinate regole. Questo elenco può essere lungo, guarda il caso specifico del tuo progetto.
Realizzazione di suddivisioni e servizi necessari al funzionamento del sistema; Tempi e procedure per il personale e la formazione del personale	Ne abbiamo già parlato prima. Forse il sistema è in fase di sviluppo per una nuova struttura o tipo di attività che prima non esisteva. Se non c'è personale appropriato, e anche addestrato, il sistema non funzionerà, non importa quanto competentemente non sia costruito.

Sezione 8 Requisiti di documentazione

Cosa farne in pratica

Un elenco di set e tipi di documenti da sviluppare concordato dallo sviluppatore del sistema e dal cliente

Avere una documentazione completa è una parte importante del risultato. Sappiamo tutti che documentare qualcosa è un duro lavoro. Pertanto, è necessario discutere in anticipo con il Cliente quali tipi di documentazione verranno sviluppati, come appariranno (contenuti e preferibilmente esempi). Considera come verranno presentate le guide per l'utente. Forse il Cliente ha accettato gli standard aziendali, quindi è necessario contattarlo. Ignorare i requisiti di documentazione molto spesso porta alle conseguenze più inaspettate sui progetti. Ad esempio, tutto è fatto e tutto funziona. Gli utenti sanno anche come lavorare. Non eravamo affatto d'accordo sulla documentazione e non parlavamo. E all'improvviso, alla consegna dell'opera, uno dei vertici del Committente, che non ha nemmeno partecipato al progetto, ma partecipa all'accettazione dell'opera, ti chiede: “Dove sono i manuali d'uso?” E inizia a convincerti che non era necessario concordare sulla disponibilità dei manuali utente, questo "di per sé" sarebbe implicito. E basta, non vuole prendere il tuo lavoro. A spese di chi svilupperete delle linee guida? Molte squadre si sono già innamorate di questo gancio.

Sezione 9 Fonti di sviluppo

	Cosa farne in pratica
Dovrebbero essere elencati documenti e materiali informativi (studio di fattibilità, relazioni sui lavori di ricerca completati, materiali informativi su sistemi analogici nazionali, esteri, ecc.), sulla base dei quali è stato sviluppato il TOR e che dovrebbero essere utilizzati nella creazione del sistema.	Ad essere onesti, è più vicino ai testi. Soprattutto quando parlano dell'effetto economico e di altre cose che sono quasi impossibili da calcolare oggettivamente. Quelli. Se è possibile, allora sarà più probabile sulla carta, puramente teoricamente. Pertanto, è meglio fare riferimento semplicemente al rapporto di indagine, ai requisiti delle persone chiave.

Quindi, abbiamo considerato tutte le sezioni che possono essere incluse nei Termini di Riferimento. “Può”, non “Deve” proprio perché qualsiasi documento deve essere sviluppato per ottenere un risultato. Pertanto, se per te è ovvio che alcune sezioni separate non ti avvicineranno al risultato, allora non ne hai bisogno e non devi perdere tempo su di esso.

Ma senza la cosa principale: i requisiti funzionali, non un solo Termini di riferimento con competenza è completo. Voglio notare che in pratica si incontrano tali Termini di Riferimento, e come! Ci sono figure che sapranno diluire le acque in tutte le sezioni, descrivere i requisiti generali in termini generali, e il documento risulta essere molto pesante, e ci sono molte parole intelligenti, e anche al Cliente potrebbe piacere esso (cioè lo approverà). Ma potrebbe non essere possibile lavorarci sopra, ad es. c'è poco uso pratico per esso. Nella maggior parte dei casi, tali documenti nascono quando devi ottenere molti soldi appositamente per i Termini di riferimento, e devi farlo in fretta e senza entrare nei dettagli. E soprattutto se si sa che le cose non andranno oltre, o lo faranno persone completamente diverse. In generale, solo per lo sviluppo del bilancio, in particolare dello Stato.

Nel secondo articolo parleremo solo della sezione 4 “Requisiti di sistema”, e nello specifico formuleremo i requisiti per ragioni di chiarezza, specificità e testabilità.

Perché i requisiti dovrebbero essere chiari, specifici e verificabili.

Perché la pratica mostra: all'inizio, la maggior parte delle specifiche tecniche che vengono sviluppate dagli specialisti o si rivelano non richieste (non corrispondono alla realtà), o diventano un problema per chi dovrebbe implementarle, perché Il cliente inizia a manipolare termini e requisiti non specifici. Darò alcuni esempi di quali frasi ho incontrato, a cosa ciò ha portato, e quindi cercherò di dare consigli su come evitare tali problemi.

Tipo di requisito

Formulazione errata