Asmeninis programų kūrimo procesas

3 paskaita

2012-03-23 / 2012-04-13

Andrius Adamonis

PSP struktūra

PSP1Size estimating

Test report

PSP0Current processBasic measures

TSPTeam building

Risk managementProject planning and tracking

PSP2Code review

Design review

PSP2.1

Design templates

PSP1.1Task planning

Schedule planning

PSP0.1Coding standard

Process improvement proposalSize measurement

Processdiscipline andmeasurement

Estimatingand

planning

Qualitymanagementand design

TeamSoftwareProcess

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

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.

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?

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

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ą

PĮ projekto planavimo veiklos

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

Planavimas

• Ar įtikinau, kad planuoti reikia?

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)

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

Programos dydžio nustatymas

• Pavyzdžių pavyzdžiai:

– Klasės

– Lentelės

– Formos

– Skriptai

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)

Dydžių lentelė – pavyzdys

Vardas ElementųKlasės dydis

LOC LOC/elementui Dydiseach-char 3 18 6 VSstring_read 3 18 6...each_line 3 31 10,33333333 S..string_manager 4 82 20,5 M...list_clip 4 89 22,25string_decrementor 10 230 23 L..character 3 87 29Converter 10 558 55,8 VL

Dydžių lentelė – pavyzdys

KategorijosControlDisplayFileLogicPrintText

PROBE

– 3. Įvertinti perpanaudojamų dalių apimtis

• Dalys imamos iš bibliotekos

– 4. Įvykdyti apimties (dydžio) vertinimo procedūrą

Met. Dydis Laikas Apr.

A Estimated proxy size and actual development size

Estimated proxy size and actual development time

kor. >= 70%

B Planned and actual program size

Planned and actual time

kor. >= 70%

C b0 = 0, b1 = actual/planned

arba b0 = 0, b1 = 1.0

b0 = 0, b1 = actual/planned

arba b0 = 0, b1 = 1.0

kažkiek duom.

D nėra duom.

PROBE

– 5. Įvykdyti laiko vertinimo procedūrą

• analogiškai

– 6. Nustatyti tikslumo intervalą

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

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

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

Priedai

Funkcinių taškų analizė

• Function point analysis

• http://conferences.embarcadero.com/article/32094

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.

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)

FPA

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.

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.

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.

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.

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.