http___www.informatika.buzdo.com_s800-razvoj-programske-potpore.htm_1.xml
1.1 1.2 1.3 2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.1 4.2 4.3 5.1 6.1 6.2 7.1 7.2 7.3 7.4 7.5 8.1 8.2 8.3 8.4 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9 10.10 10.11 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9
In Chapter 3.4.3 already mentioned phases of software development. Conditional nature of the program by way of dealing with certain phases of which the digital computer specific stages of the writing and recording of one of the language processor, and is illustrated in Chapter 6.2. the example shown in the following subchapter. Which of language processors to use depends on the type of problems they solve and the opportunities and the type of DCS which will be applied. Therefore, there are no strict rules. Sample tasks will be resolved on a PC computer with QBASIC or VISUAL BASIC language processor, and for carrying purposes or processing student population will use the tools that may use some of the database server as DELPHI. One of the top software program for monitoring of large firms and institutions, LOTUS-NOTES, it is very effective but also very expensive solution. In Chapter 3.4.3 has already been noted that there are two basic groups of language processors with respect to the creation of the executive code execution mode executable. Briefly: COMPILER and INTERPRETER. To shift some reading source code compiler is used to create executable file (.exec or .com type) from the source code, then translates source code into executable (binary) version that can then be applied to test results, and if you notice an error condition program must be corrected in the source code, which then needs to be translated again and a new executable file and run it again and test. Interpreter done differently. Translates instructions one at a time directly from the source code in real time and perform translations. Translated result is nowhere preserved. Changes in the source code may be immediately and can be carried out during the execution of the program created. Consecutive interpreting instructions certainly gives significantly slower results with its processing speed, but it is easier to debug. Some language processors, as Quick BASIC, have a peculiarity and interpretation of the source code and its translation into executable file. But no matter which of the language processor is applied, the process of creating the final results in stages and seen his creations are similar. Number of phases and their application depends on the 'school of programming', and the simple view of their importance sequence is described in the next chapter. Stages of software development are presented in the following sections through a few examples, but no display solution with the use of one language processor. Every day in life we encounter problems that bring us and we need to resolve in a way that we have chosen as the most appropriate, whether it be something completely new, or part of a routine that will take the already-known knowledge and solutions. One example is the preparation of daily meals for the family, when our moms for example feast prepared cakes. The following table explains the procedure compared with the previously mentioned 7 phases of software development in Chapter 3.4.3. The above example is an illustration of how approach solving any task. The following example shows the first four stages of problem solving in a number system conversion. The first three stages are well-defined set of data requirements and their inter-relationship and include a description of actions that lead to the final solution and is called an algorithm. The algorithm is a procedure for parsing problems (tasks) into precise little steps. Flowchart is a graphical representation of the algorithm in which the sequence of actions and their relationship to each showing interconnected geometric figures and standardized graphic symbols to beginning, end, order, decision, and more. It should be borne in mind that in computing the parameters or variables in the programming process for the initial values typically have size ' 0 ', for example, the first field in the data matrix, or the upper left pixel in the graphical representation and the like. It has already been stated that the stages described only one possible example of how to approach problem solving and programming firms have their own procedures developed by their principles and requirements, usually described through a number of steps in relation to the previously described example. The seven stages of the basic structure of the sort that does not have to be the rule, but it can serve as a basis for the establishment of a complex developmental structures. Complex developmental structure favors the development teams and in itself will contain links between individual teams or members within the team in order to coordinate actions and insights of the participants in the development of software in the results of the individual members of the team or the teams. The development of software is not a trivial job. Errors are possible in the design and the programming code. That one error correction (bug) may lead to more new to their number gradually decreased and was reduced to a minimum before the disclosure of the results. So the whole process is recursive, the current phase is possible to return to the previous order to perceived shortcomings. When the final product is almost always disclosed it is subsequently found to have some kind of failure. Not popular to disclose that he corrected a omission (bug), but marketing sounds much nicer it is executed UPDATE, as some kind of upgrade or something. Not .. but .. 'Update' is a 'patch' that the manufacturer usually offers free. In this sense the term is similar to the upgrade, which includes the new features of the product (with the tacit patched bugs of course) and that something needs to recharge. The process of describing any product in the development of software must be well documented. There is no place for fear that someone else will clip on to use this document, because it will not give anyone the creator. Indeed, descriptions and hints (remark) just the creator of software serve to remind us what he was doing, because after a few months surely forget 'some tiny details that only he understands'. The seemingly simple job installing the operating system on your computer there are a number of settings that need to be set to make the system more efficient and effective protection. The procedure is described in the document, which is commonly known as a to-do list (making process), which contains over one hundred actions described in detail. The list is usually made up of three columns: a number of actions, a description of the procedure to be performed to carry out the action and markings execution / non-execution of action (check mark). It allows you to be without a big 'remembering' the next day to continue with the list, which is up one point made the previous day and so on until the conclusion of the implementation of the actions described. The list can not be created in one day, but it is a document that is dynamically changes according to the needs and that is 'embedded' experience one or more of the creators of the list. Quality leaf justification will show only after a year of its regular updates. Thus, the list - yes, but its public disclosure - NO. Procedures described in the Appendix i.) only the thin part of one of these lists. Nothing's worse disgrace and respect the user supplied program support from eternal correcting bugs. Certainly reduces the quality documentation procedure for their removal, and facilitate the implementation of additional software options, which, over time, the need for their product, as for example the extension of certain legal regulations changes in accounting programs. Software Support creates no 'overnight' and that it can take years of time until they 'matured' for final use. For example, one can take any program support and track its progress through the descriptions complement the different versions of the documentation that is often named 'Changelog ...' or 'What's new ...'. Need some time to reach the client software version 1.0 :-). Popularly called people 'developer' is just one of the people who participate in the preparation of program support. Depending on the type of the same team that will be a mathematician, an economist, a builder ... Teamwork has significantly increased in comparison to the individuality of this business. The importance of the team in the testing phase of software is a very important item and is usually performed as specified in Chapter 6.2.2; some of the descriptions QBASIC programming tool.
1.1 1.2 2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.1 4.2 4.3 5.1 6.1 6.2 7.1 7.2 7.3 7.4 7.5 8.1 8.2 8.3 8.4 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9 10.10 10.11 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9
U poglavlju 3.4.3. već su navedene faze razvoja programske potpore. Karakter programa uslovljava način rješavanja po pojedinim etapama od kojih je za digitalno računalo specifična etapa pisanja i unošenja programa jednim od jezičkih procesora, a ilustrirana je u poglavlju 6.2. prema primjeru iz narednog podpoglavlja. Kojim se od jezičkih procesora koristiti ovisi o vrsti problema koji se riješava te o mogućnostima i vrsti DRS na kojoj će se primjeniti. Stoga tu nema strogih zakonitosti. Jednostavnije zadaće rješavati će se na PC-računala s QBASIC ili VISUAL BASIC jezičkim procesorom, a za knjigovodstvene svrhe ili obradu studentske populacije koristiti će se alati koji mogu uporabiti neki od poslužitelja baze podataka kao DELPHI. Jedna od vrhunskih programski potpora za praćenje rada velikih firmi i ustanova, LOTUS-NOTES, vrlo je učinkovito ali i vrlo skupo rješenje. U poglavlju 3.4.3 navedeno je da postoje dvije osnovne grupe jezičkih procesora s obzirom na kreiranje izvršnog koda i sam način izvršavanja izvršnog koda. Ukratko: KOPAJLERI i INTERPRETERI. Za prevodjenje nekog napisanog izvornog koda služi Kompajler (prevodioc) koji stvara izvršivu datoteku (.exe ili .com tipa) od izvornog koda, znači prevodi izvorni kod u izvršivu (binarnu) verziju koja se potom može primijeniti i testirati rezultat, i ako se primijeti greška u radu programa moraju se ispraviti u izvornom kodu, kojeg potom opet treba prevesti i novu izvršivu datoteku te opet je pokrenuti i testirati. Interpreter to radi drugačije. Prevodi se jedna po jedna instrukcija izravno iz izvornog koda u realnom vremenu i po prevođenju izvršava. Prevedeni rezultat nigdje se ne čuva. Izmjene u samom izvornom kodu mogu se odmah provjeriti a mogu se vršiti i za vrijeme samog izvršavanja kreiranog programa. Uzastopno prevođenje instrukcija sigurno daje značajno sporije rezultate glede brzine obrade podataka, ali je otklanjanje grešaka jednostavnije. Poneki jezički procesori, kao QuickBASIC, imaju osobitost i interpretiranja izvornog koda i njegovog prevođenja u izvršivu datoteku. No bez obzira koji se od jezičkih procesora primjeni, postupak kreiranja konačnog rezultata sagledan u etapama njegove kreacije je sličan. Broj etapa i način njihove primjene ovisi od 'škole programiranja', a najjednostavniji prikaz njihovog slijeda značaja opisan je u narednom poglavlju. Etape razvoja programske potpore prikazane su u narednim poglavljima kroz nekoliko primjera, ali bez prikaza riješenja s uporabom jednog od jezičkih procesora. Svakodnevno se u životu susrećemo s problemima koji nam se nameću i koje moramo riješiti na način koji smo odabrali kao najpogodniji, bilo da je to nešto posve novo ili rutinski dio za koji ćemo iskoristiti već poznata saznanja i rješenja. Jedan od svakodnevnih primjera je priprema objeda za porodicu, kada naše mame na primjer za blagdan spremaju kolače. U narednoj tablici objašnjen je taj postupak u usporedbi s već prije navedenih 7 faza razvoja programske potpore u poglavlju 3.4.3. Navedeni primjer je ilustracija kako pristupiti rješavanju bilo kojeg zadatka. U narednim primjerima prikazane su prve četiri faze rješavanja problema pretvorbe u brojevnim sustavima. Prve tri faze su skup dobro definiranih podataka, uvjeta te njihove međusobne povezanosti i podrazumijevaju opis akcija koje vode ka konačnom rješenju i nazivaju se algoritam. Algoritam je postupak raščlanjivanja problema (zadatka) u precizne sitne korake. Dijagram tijeka je grafički prikaz algoritma u kojem se redoslijed akcija i njihova međusobna veza prikazuje međusobno povezanim geometrijskim likovima, odnosno standardiziranim grafičkim simbolima za početak, kraj, naredbu, odluku i drugo. Treba imati na umu da u informatici parametri ili varijable tijekom postupka programiranja obično za početnu vrijednosti imaju veličinu ' 0 ' za npr. prvo polje u matrici podatka ili gornji lijevi piksel u grafičkom prikazu i slično. Već je prije navedeno da su opisane faze samo jedan od mogućih primjera kako pristupiti rješavanju zadaće, te da programerske firme imaju svoje postupke razvijene prema njihovim načelima i potrebama, najčešće opisane kroz više koraka u odnosu na prethodno opisani primjer. Navedenih sedam faza su nekakva temeljna struktura koja ne mora biti pravilo, ali može poslužiti kao osnova za uspostavu složenije razvojne strukture. Složenija razvojna struktura pogoduje razvojnim timovima i u sebi će sadržavati sprege između pojedinih timova ili članova unutar tima u svrhu koordinacije postupaka i uvida učesnika u razvoju programske potpore u rezultate rada pojedinih članova tima ili samih timova. Razvoj programske potpore nije trivijalan posao. Moguće su pogreške u dizajnu i samom programskom kodu. Tako ispravka jedne pogreške (bug-a) može dovesti do više novih da bi se postupno njihov broj smanjivao i sveo na najmanju moguću mjeru prije objelodanjivanja rezultata. Dakle, cijeli postupak je rekurzivan, iz trenutne faze moguć je povratak u prethodne da bi se uočeni nedostaci uklonili. Kad se gotov proizvod objelodani gotovo uvijek se naknadno ustanovi da ima nekakvih propusta. Nije popularno objelodaniti da je ispravljen nekakav propust (bug), već marketinški puno ljepše zvuči da je izvršen UPDATE, kako nekakva dogradnja ili slično. Nije .. nego .. 'Update' je 'zakrpa' koji proizvođač obično nudi besplatno. U navedenom smislu sličan je termin UPGRADE, koji podrazumijeva nove osobitosti proizvoda (uz prešutno zakrpane bug-ove naravno) i za koje treba nešto i nadoplatiti. Postupak opisivanja bilo kojeg proizvoda u razvoju programske potpore mora biti kvalitetno dokumentiran. Tu nema mjesta strahu da će netko drugi uradak po takvom dokumentu iskoristiti, jer ga tvorac neće nikome dati. Dapače, opisi i naznake (remark) upravo kreatoru programske potpore služe da se podsjeti što je radio, jer će nakon par mjeseci sigurno zaboraviti 'neke male sitne detalje koje samo on razumije'. U naizgled najjednostavnijem poslu instalacije operativnog sustava na računalo postoji niz postavki koje treba podesiti da bi sustav bio učinkovit i djelotvorno zaštićen. Postupak se opisuje u dokumentu koju se uobičajeno naziva TO-DO lista (postupak izrade), koji sadrži više od stotinu u tančine opisanih radnji. Lista je uobičajeno sastavljena od tri stupca: redni broj radnje, opis postupka koji treba provesti da bi se radnja izvršila i oznake izvršenja / neizvršenja radnje (kvačica). To omogućava da se bez velikih 'prisjećanja' sutradan nastavi postupak prema listi koji je do jedne točke prethodnog dana izvršen i tako do zaključenja provedbe svih opisanih radnji. Lista se ne može izraditi za jedan dan, već je to dokument koji se dinamički mijenja prema potrebama i u koji je 'ugrađeno' iskustvo jednog ili više kreatora liste. Kvalitetna lista svoju opravdanost pokazati će tek nakon cijele godine njenog redovnog ažuriranja. Dakle, lista - DA, ali njeno javno objavljivanje - NE. Opisani postupci u prilozima pod i.) samo su šturi dio jedne od takvih lista. Nema gore stvari i bruke glede isporučene programske potpore korisniku od vječitog ispravljanja bug-ova. Kvalitetna dokumentacija sigurno smanjuje postupak otklanjanja istih, i olakšava implementaciju dodatnih programskih rješenja za koja se je tijekom vremena nametnula potreba za njihovu izradu, kao što je na primjer dogradnja zbog promjene neke zakonske regulative u knjigovodstvenim programima. Programska potpora ne stvara se 'preko noći' i ponekad treba i koja godina vremena dok ne 'sazre' za konačnu uporabu. Za primjer može se uzeti bilo koja programska potpora i pratiti njen razvoj kroz opise nadopuna pojedinih verzija u dokumentu koji obični ima naziv 'Changelog...' ili 'What's new...'. Treba malo vremena da programska potpora dosegne verziju 1.0 :-). Popularno nazvana osoba 'programer' samo je jedna od osoba koja učestvuje u izradi programske potpore. Ovisno o vrsti iste u timu koji je radi biti će matematičar, ekonomista, građevinac ... Timski rad sve je izraženiji u odnosu na individualnost u tom poslu. Važnost tima u fazi testiranja programske potpore veoma je važna stavka i uobičajeno se obavlja kako je navedeno u poglavlju 6.2.2; dio opisa programerskog alata QBASIC.