1 / 31

Asmeninis programų kūrimo procesas

Asmeninis programų kūrimo procesas. 3 paskaita 2012-03-23 / 2012-04-13 Andrius Adamonis. PSP struktūra. Planavimas. Programinės įrangos industrijoje dažnai PĮ kūrimo planai yra netikslūs

kamala
Download Presentation

Asmeninis programų kūrimo procesas

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Asmeninis programų kūrimo procesas 3 paskaita 2012-03-23 / 2012-04-13 Andrius Adamonis

  2. PSP struktūra

  3. Planavimas • Programinės įrangos industrijoje dažnai PĮ kūrimo planai yra netikslūs • Nedaugelis įmonių turi procesą, užtikrinantį, kad planai yra išbaigti, kruopščiai peržiūrėti ir tinkamai aprobuoti • Vadovybė aiškiai gali pasakyti, kada naujai pradedamas projektas turi būti baigtas, tačiau nelabai ką apie kitus tikslus. Tas sukuria iliuziją, kad terminai yra svarbiausia. Tačiau projekto komanda turi išsiaiškinti ir įgyvendinti ir kitus tikslus, tuo pačiu išlaikydama pageidaujamus darbo atlikimo terminus

  4. Planavimas • Kai vadovybė nori, kad projektas būtų atliktas, iš tiesų jie nori, kad jis būtų atliktas dabar ir be jokių sąnaudų. Visa kita yra kompromisas. • Norint su vadovais suderinti datas, kurioms reikalavimai gali būti ir labai agresyvūs, reikalingas planas, parodantis, ką ir kada reikia atlikti. • Galų gale, kadangi vadovai nori plano ir tvarkaraščio, kurį komanda yra pajėgi įgyvendinti, su jūsų pateiktu pagrįstu planu ji sutiks.

  5. Planavimas • Užsakovas plane ieškos: • Kas įsipareigojama? • Ar bus pagaminta tai, ko reikia? Kokie tarpiniai kokybės ir įgyvendinimo patikrinimo taškai? • Kaip galima stebėti įgyvendinimo eigą? • Ar galima įvertinti atliekamą darbą? Ar galima atskirti gerai valdomą darbą nuo blogai valdomo?

  6. Planavimas • Plane tikimės rasti: • Darbo apimtį • Kokio dydžio yra darbas ir kiek laiko jį atlikti užtruks • Darbo atlikimo struktūrą • Kokia tvarka atliksime darbą; ką darysime pirma, ką po to • Darbo atliktumo būseną • Kaip žinosime, kiek darbo jau esame atlikę; ar baigsime laiku ir ar kaštai neviršys planuotų • Galimybę įsivertinti • Ar geras buvo planas; ar buvo akivaizdžių klaidų; kokių klaidų reikėtų išvengti ateityje ir kitą sykį suplanuoti geriau

  7. PĮ projekto planavimas • Žingsniai: • 1. Darbo apibrėžimas (statement of work) • 2. Suskaidyti projektus, didesnius nei kelios dienos, į smulkesnes užduotis ir įvertinti kiekvienos dydį atskirai • 3. Palyginti įverčius su istoriniais duomenimis iš ankstesnių panašių darbų • 4. Dokumentuoti įverčius • 5. Jei keičiasi reikalavimai, keisti ir planą

  8. PĮ projekto planavimo veiklos

  9. Plano valdymo aspektai • Reikalavimų išaugimas • Requirements creep / Scope creep • Vertinimo ir planavimo įrankiai • Darbo apibrėžimas • Statement of Work / SoW • Individualiam darbui nebūtinas, bet kartais reikia

  10. Planavimas • Ar įtikinau, kad planuoti reikia?

  11. Planavimo duomenys • Kaip gauti duomenis planui paruošti? • Kokie yra pirmieji žingsniai prieš rengiant planą? • Dydžio vertinimo atraminis principas – lyginti su ankstesnių projektų rezultatais • Pirmas žingsnis – parengti eskizinį projektą (conceptual design) • Toliau naudojame pavyzdžiais pagrįstą vertinimą (proxy-based estimating)

  12. Programos dydžio nustatymas • Pavyzdžiais pagrįstas įvertinimas • Proxy-Based estimation • Gero pavyzdžio (proxy) kriterijai: • Pavyzdžio dydis koreliuoja su pastangų, reikalingų programai sukurti, apimtimi • Pavyzdžio dydis lengvai automatiškai išmatuojamas • Turi būti lengva vizualizuoti • Lengvai adaptuojamas projekto reikmėms

  13. Programos dydžio nustatymas • Pavyzdžių pavyzdžiai: • Klasės • Lentelės • Formos • Skriptai

  14. PROBE • PROxy-Based Estimation • 1. Pasidaryti koncepcinį dizainą = suskaidyti programos projektą į smulkesnes dalis • Smulkios dalies pavyzdys: masyvo įvedimas iš komandinės eilutės • 2. Kiekvienai naujai daliai: parinkti pavyzdžių iš istorinių duomenų bazės • Pagal proxy tipus • Vertinti, kiek bus elementų (pvz. klasės metodui) • Vertinti, kokio stambumo bus elementai (VS, S, M, L, VL)

  15. Dydžių lentelė – pavyzdys

  16. Dydžių lentelė – pavyzdys

  17. PROBE • 3. Įvertinti perpanaudojamų dalių apimtis • Dalys imamos iš bibliotekos • 4. Įvykdyti apimties (dydžio) vertinimo procedūrą

  18. PROBE • 5. Įvykdyti laiko vertinimo procedūrą • analogiškai • 6. Nustatyti tikslumo intervalą

  19. PSP1.0 procesas • Įeitys (Input criteria): • Uždavinio aprašymas • PSP1 projekto plano suvestinė (PPS) • Dydžio vertinimo forma (DVF) • Istoriniai numatytų ir aktualių dydžių duomenys • LFF ir DFF, Laikrodis (gali ir nebūti) • Defektų standartas ir Kodavimo standartas • Veiklos: • 1. Planning – Planavimas • 2. Development – Kūrimas • 3. Postmortem – Užbaigimas • Rezultatai (Output criteria): • Ištestuota programa • Užpildyta projekto plano forma (PPS) • Užpildyta DVF • Užpildyta Testavimo ataskaita • Užpildyti LFF ir DFF

  20. PSP1.0 procesas - Development • Įeitys: • Dokumentuoti reikalavimai • Numatomas laikas (paskirstytas per fazes) ir dydis PPS formoje • LFF, DFF • Defektų standartas ir Kodavimo standartas • Veiklos: • 1. Projektas – projekto parengimas • 2. Kodavimas – programos kodo pagal projektą parašymas, vadovaujantis Kodavimo standartu • 3. Kompiliavimas – programos kompiliavimas, kol nelieka kompiliavimo klaidų • 4. Testavimas – programos testų vykdymas, kol nelieka klaidų testuose • Rezultatai: • Ištestuota programa, griežtai atitinkanti Kodavimo standartą • Užpildyti LFF ir DFF

  21. PSP1.0 procesas - Postmortem • Įeitys: • Uždavinio aprašymas • Dokumentuoti reikalavimai • Užpildytos LFF & DFF • Ištestuota programa • Veiklos: • 1. Defektų aprašymas • 2. Defektų duomenų patikrinimas • 3. Dydžio apskaita – suskaičiuoti ir įrašyti programos dydžius į PPS bei PDF • 4. Laiko apskaita – perkelti suminius iš LFF į PPS • Rezultatai: • Ištestuota programa, griežtai atitinkanti Kodavimo standartą • Užpildytos projekto plano forma (PPS), Programos dydžių forma (PDF) ir Testavimo ataskaita • Užpildyti LFF ir DFF • Užpildyta Proceso gerinimo pasiūlymo (PGP) forma, įvardinanti proceso trūkumus, pagerinimo pasiūlymus, išmoktas pamokas

  22. Priedai

  23. Funkcinių taškų analizė • Function point analysis • http://conferences.embarcadero.com/article/32094

  24. FPA - žingsniai • 1. Determine the type of count. • 2. Identify the scope and boundary of the count. • 3. Determine the unadjusted FP count. • 4. Determine the Value Adjustment Factor. • 5. Calculate the Adjusted FP Count.

  25. FPA – skaičiuojami elementai • Data Functions: • Internal logical files (ILF) • External interface files (EIF) • Transactional Functions: • External Inputs (EI) • External Outputs (EO) • External Inquiries (EQ)

  26. FPA

  27. FPA - ILF • Samples of things that *can* be ILFs include: • Tables in a relational database. • Flat files. • Application control information, perhaps things like user preferences that are stored by the application. • LDAP data stores.

  28. FPA - EIF • An external interface file (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application counted. This means an EIF counted for an application must be in an ILF in another application." • Again, think of this as data that your application needs and uses, but does not maintain.

  29. FPA - EI • An external input (EI) is an elementary process that processes data or control information that comes from outside the application boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system. • Examples of EIs include: • Data entry by users. • Data or file feeds by external applications.

  30. FPA - EO • An external output (EO) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external output is to present information to a user through processing logic other than, or in addition to, the retrieval of data or control information . The processing logic must contain at least one mathematical formula or calculation, create derived data maintain one or more ILFs or alter the behavior of the system. • Examples of EOs include: • Reports created by the application being counted, where the reports include derived information.

  31. FPA - EQ • An external inquiry (EQ) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information from an ILF of EIF. The processing logic contains no mathematical formulas or calculations, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered. • Examples of EQs include: • Reports created by the application being counted, where the report does not include any derived data. • Other things known as "implied inquiries", which unfortunately, are a little out of scope for this paper.

More Related