Vajad kellegagi rääkida?
Küsi julgelt abi LasteAbi
Logi sisse

Tarkvaratehnika (0)

1 Hindamata
Punktid

Esitatud küsimused

  • Mis on tarkvaratehnika?
  • Mis on süsteem?
  • Mis on süsteemitehnika?
  • Mis on tarkvara arendusprotess e tarkvaraprotsess?
  • Millises situatsioonis teie rakendust kasutavad?
  • Mis on tarkvarasüsteemi arhitektuur?
  • Milline osa süsteemist on suurima muutumise tõenäosusega?
  • Milliste osade disainimist võib edasi lükata ilma märkimisväärsete mõjudeta?
  • Millised on võtme-eeldused ja kuidas neid kontrollida?
  • Mis võib põhjustada süsteemi ümber disainimise?
  • Milline arhitektuur kataks kõige paremini kasutajate vajadusi ?
  • Kuidas täita kujuteldava süsteemi nõudeid ?
  • Kuidas otsustada milline arhitektuuri strateegia on sobilik ?
  • Kuidas hinnata nõuete täitmisel tehtavate kompromisside mõjusid ?
  • Millistele eeldustele tugineb arhitektuur ?
  • Milliseid nõudeid arhitektuur katab ?
  • Mis on selle arhitektuuri võtme riskid ?
  • Milliste meetmetega leevendada riske ?
  • KUIDAS ARGUMENTE VÄHENDADA?
  • MILLAL KOMMENTAARE KASUTADA?
  • Milleks hallata?
  • Kes selle siia tegi?
  • Mis on tarkvaratehinka?
  • Kuidas struktureerib FURPS raamistik nõuete kogumiku?
  • Millised on põhilised testide tüübid?
  • Mis on XP põhiväärtused?
  • Mis on nõuete inseneeria ?
  • Mis on agiilse arhitektuuri loomise omadused?
  • Mida kasulikku saab eesmärgi mudeli kasutamisest?

Tarkvaratehnika

1. Loeng

Kvaliteetse tarkvara atribuudid:


  • Teostab ettenähtud funktsionaalsust
  • Hooldatav – Tarkvara peab arenema, et vastata muutuvatele vajadustele.
  • Usaldusväärne – Töökindlus ja turvalisus.
  • Vastuvõetav – Kasutajad on aktsepteerinud selle. Tarkvara on neile arusaadav, kasutatav ja ühilduv teiste süsteemidega.

    Mis on tarkvaratehnika?

    Tarkvaratehnika on tiimide poolt rakendatav distsipliin tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara, mis rahuldab kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel.
    Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähenemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale .
    Tarkvaraarendus on nõrgem termin, kus tingimata ei kasutata protsesse, tööriistu, standardeid jne

    Mis on süsteem?

    Üksteisega ühendatud olemite või komponentide hulk, mis moodustavad keerulise terviku või täidavad koos keerulist funktsiooni.
    Süsteem võib sisaldada tarkvara, mehhaanilist , elektrilist ja elektroonilist riistvara ja olla opereeritud inimeste poolt.
    Süsteemi komponentide omadused ja käitumine sõltuvad teistest süsteemi komponentides.

    Süsteemide kategooriad

    Tehnilised süsteemid – Süsteemid, mis sisaldavad riist- ja tarkvara nind kus kasutajaid ja kasutusprotsesse ei käsitleta süsteemi osadena. Tehniline süsteem ei ole iseendast teadlik.
    Sotsio -tehnilised süsteemid – Süsteemid, mis sisaldavad nii tehnilisi süsteeme kui ka inimesi, kes kasutavad tehnilisi süsteeme ja suhtlevad nendega ning kasutusprotsesse. Süsteem, mis koosneb riistvarast, tarkvarast ja inimestest.
    Sotsio-tehniliste süsteemide omadused:
    1) Süsteemi kui terviku omadused sõltuvad selle komponentidest ja nende seostest.
    2) Süsteem ei anna sama sisendi puhul alati sama väljundit. (Mittemääratud käitumine)

    Mis on süsteemitehnika?

    Sotsio-tehniliste süsteemide spetsifitseerimise, kavandamise, realiseerimise, valideerimise, installeerimise ja hooldamise protsess.

    Tarkvararakenduste liigid

    Kohalikud ( stand -alone) rakendused , nt. MS Office ja fotode mainupuleerimise süsteemid
    Interaktiivsed transaktsioonipõhised rakendused, nt. pangarakendused ja e-kaubanduse rakendused
    Mähisrakendused (embedded control systems), nt. ABS - pidureid ja mikrolaineahju kontrollivad süsteemid
    Andmetöötlusrakendused ( batch processing systems), nt. arvete ja palgaarvestuse süsteemid
    Meelelahutusrakendused, nt. mängud
    Modelleerimis- ja simulatsioonirakendused
    Andmekogumisrakendused (data collection systems),nt. keskkonna kohta andmeid koguvad süsteemid
    Süsteemide süsteemid (systems of systems)
    Mobiilirakendused
    REST-i / WS-i põhised rakendused
    Video ja heli streamimis rakendused

    Mis on tarkvara arendusprotess e tarkvaraprotsess?

    Tarkvaraprotsess on sammude jada, mille eesmärgiks on tarkvara arendamine ja evolutsioon
    Tegevused tarkvaraprotsessis:
  • Spetsifitseerimine – Mida süsteem peab tegema ja mis on piirangud tema arendamisel?
  • Arendamine
  • Valideerimine
  • Evolutsioon – Tarkvarasüsteemi muutmine vastavatale muutuvatele nõudmistele

    Tarkvaraprotsessi mudel

    Tarkvaraprotsessi lihtsustatud esitus teatud vaatepunktist.
  • Protsessikeskne
  • Andmekeskne
  • Rollikeskne
    Mudelite näited:
  • Kosk
  • Iteratiivne arendamine
  • Komponendipõhine

    Professionaalse vastutuse aspektid


  • Konfidentsiaalsus – Tarkvarainsener peab respekteerima oma tööandja ja klientide konfidentsiaalsust, sõltumata sellest, kas formaalne leping konfidentsiaalsuse kohta on alla kirjutatud
  • Kompetents – Tarkvarainsener ei tohi anda väära ettekujutust oma kompetentsist. Ta ei tohi võtta teadlikult vastu tööd, mis on väljaspool tema kompetentsi .
  • Intellektuaalne omand – Tarkvarainsener peab olema teadlik kohalikest seadustest ja määrtustest, mis sätestavad intellektuaalse omandi kasutamise näiteks patentide ja kopeerimisõiguste näol.
  • Arvuti väärkasutus – Tarkvarainsener ei tohi kasutada oma tehnilisi oskusi teiste inimeste arvutite väärkasutamiseks.

    2. loeng - Tarkvarasüsteemi elutsükkel ja arendusprotsess

    „No silver bullet“ – Ükski tehnoloogia või praktika ei too kaasa võitu üle 10x arendusajas,-rahas või funktsionaalsuses
    Tarkvaraprobleemi lahendamine varajastes disainietappides on 100 korda odavam kui hilisemates .
    Tarkvaraprojekti ajagraafikut saab tihendada maksimaalselt 25% võrra.
    Hooldus on 2x kallim kui arendus.
    Inimestevahelised erinevused on kõige suurem produktiivsuse mõjutaja.
    Tarkvara maksab rohkem kui riistvara.
    15% tarkvara arendamisest on programmeerimine, ülejäänu on toetav , abistav ja korraldav töö.
    Tarkvarasüsteemi koodirida maksab 3x rohkem kui üksiku programmi koodirida. – „Diseconomy of scale “.
    60% tarkvara vigadest on leitavad inimliku läbivaatuse korras.
    Pareto printsiip – 80% tootlikkusest tuleb 20% tegijatelt.

    3.Loeng – Tarkvarasüsteemi nõuete inseneeria

    Mis on nõue - This is inevitable as requirements may serve a dual function : May be the basis for a bid for a contract – therefore must be open to interpretation ; May be the basis for the contract itself – therefore must be defined in detail

    Nõuete tüübid

    User requirements - Statements in natural language plus diagrams of the services the system provides and its operational constraints . Written for customers.
    System requirements - A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

    Mis on nõuete inseneeria

    The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed .

    Kes milliseid nõudeid loeb

    Kasuataja nõuded – client managers, system end- users , client engineers, contractor managers, system architects
    Süsteemi nõuded – system end-users, client engineers, system architects, software developers

    Functional requirements

    Statements of services the system should provide , how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do.
    - Describe functionality or system services.
    - Depend on the type of software, expected users and the type of system where the software is used.
    - Functional user requirements may be high-level statements of what the system should do.
    - Functional system requirements should describe the system services in detail.

    Non-functional requirements

    Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. May apply to the system as a whole as well as to individual features or services.
    - These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.
    - Process requirements may also be specified mandating a particular IDE, programming language or development method .
    - Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.
    - Non-functional requirements may affect the overall architecture of a system rather than the individual components .
    - A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required .

    Mitte-funktsionaalsete nõuete mõõtühikud

    Kiirus, suurus, aeg, kasutamise kergus, usaldatavus , robustsus.

    Quality goal

    A quality goal expresses some quality aspect of how the functional goal should be achieved

    Software requirement document


    - The software requirements document is the official statement of what is required of the system developers.
    - Should include both a definition of user requirements and a specification of the system requirements.
    - It is NOT a design document. As far as possible, it should set on WHAT the system should do rather than HOW it should do it.

    Nõuete esitamise viisid

    Natural language, Structured natural language, for example user stories and scenarios, Graphical notations, for example, use cases , activity diagrams, and goal models, Mathematical specifications, for example, in the Z language

    Kasutuslood (user stories)

    Üldkuju: As a user playing some role , I must be able to perform some activities [in order to achieve some goal]

    Scenarios

    Scenarios are structured descriptions of how a system can be used.
    They should include:
    - A description of the starting situation;
    - A description of the normal flow of events ;
    - A description of what can go wrong ;
    - Information about other concurrent activities;
    - A description of the state when the scenario finishes.

    Use cases


    - Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.
    - A set of use cases should describe all possible interactions with the system.

    Nõuete protsessid

    Requirements discovery - Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.
    Requirements classification and organisation - Groups related requirements and organises them into coherent clusters.
    Prioritisation and negotiation - Prioritising requirements and resolving requirements conflicts.
    Requirements specification - Requirements are documented and input into the next round of the spiral .

    4. loeng - Süsteemi nõuete esiletoomine ja analüüs

    Analüütik vastutab selle eest, et tellija saab süsteemi, mida vajab
    Nõuete kogumine - (Loodava) Infosüsteemi kirjeldamine erinevatest aspektidest
    Nõuete kogumiku alusel koostatakse süsteem ja vajalikud lisatulemid.

    Nõude kolm baasomadust

    – Ühene kontrollitavus – küsimusele „kas nõue on täidetud?“ peab saama võimalikult üheselt vastata “jah” või “ei”
    – Kerge kontrollitavus – nõude kontroll ei tohi võtta palju aega
    – Sõnastuse lihtsus ja lühidus – nõude sisutekst ei tohiks olla pikem kui ~30 sõna

    Nõuete kogumiku moodustamisel on eesmärgiks

    – Ühtlane kaetus – nõuete hulk peab ühtlaselt ja piisava tihedusega katma kogu arendatavat teemat.
    – Piisav hulk – nõuete hulk peab olema piisavalt suur, et katta kõik oluline. Aga mitte liiga detailne !
    Struktuurne jaotus – nõuete kogumik peaks olema hierarhiliselt struktureeritud.

    FURPS+

    Functionality (funktsionaalsus) - Kirjeldus, kuidas süsteem peaks käituma kasutajapoolsete või teisest süsteemist pärinevate sisendite peale.
    Usability ( kasutatavus ) - Sobivus kasutaja mõttemudeliga: millised kasutajad ja millises situatsioonis teie rakendust kasutavad?
    Reliability (käideldavus) – lubatavate vigade arv ja nende tõsidus, kui palju jääb vigade tekkimise vahele aega, kui kiiresti vead lahendatakse
    Performance (jõudlus)
    Supportability (toetus) – kui palju raha peab kulutama, et asja töös hoida, testitavus, konfigureeritavus, laiendatavus, lokaliseeritavus.
    + ( disain , tehnilise realiseerimise piirangud, liideste piirangud, majutuse piirangud jms)

    Prototüüpimise plussid

    Lahendus mõeldakse detailides läbi
    Lõppkasutaja saab „proovida“ funktsionaalsust enne realisatsiooni
    Tellijal ja täitjal ühine nägemus lõpptulemusest
    Tellija ja täitja saavad täpsemalt kokku leppida projekti skoobis ning vahetulemites
    Mis on lihtsam ja mis keerulisem funktsionaalsus
    Selgemalt saab eraldada, mis on muudatus , mis on puudujääk ja mis täitja viga
    Selgem ülevaade kui palju projektist valmis on

    Prototüüpimise viisid

    Seinatehnika ja prototüübikaust – paber, pliiats või tahvel või fotoaparaat .
    Passiivsed kuvad eraldi dokumentides (failides) - Olemasolev rakendus ja „ Paint “, Excel, Visio , jne
    Infosüsteemi prototüüplahendused – Prototüübimootorid, Lihtsamad HTML või klient - server rakendused

    5. loeng – Mudelid ja modelleerimine

    What is a model?

    A hypothetical , Simplified description of a complex entity or process.
    “A model should be as complex as it needs , but not more complex”, David Lorge Parnas
    What features

    UML:

    The Unified Modeling Language (UML) is a general-purpose modeling language in the field of software engineering , which is designed to provide a standard way to visualize the design of a system.

    Tarkvaraprotsessi etapid


  • Nõuete esiletoomine ja analüüs
  • Kavandamine e disain
  • Arhitektuuriline
  • Detailne
  • Realiseerimine
  • Testimine
  • Hooldus ja evolutsioon

    RUP:

    The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation , a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the unified process.

    RUP-i faaside selgitused

    Inception: äriline analüüs
    Elaboration: nõuete analüüs, arhitektuuriline disain, arendusplaan
    Construction: detailne kavandamine, realiseerimine ja testimine
    Transition: süsteemi käitamine

    Käitumise analüüsi kohta peaks vaatama erinevaid jooniseid alates 5. loeng slaid 25


    Süsteemi tuleb modelleerida õigete abstraktsioonitasemete ja vaatepunktide kontekstis.

    6. loeng: Tarkvarasüsteemi arhitektuuri kavandamine

    Mis on tarkvarasüsteemi arhitektuur?

    Kirjelduse selle kohta, kuidas tarkvarasüsteem on organiseeritud.
    Süsteemi illustratsioon, mis aitab aru saada süsteemi käitumisest (Software Engineering Institute http://www.sei.cmu.edu/ ).
    Süsteemi arhitektuur on struktuuride kogum, mis aitavad mõista süsteemi, hõlmates tarkvara elemente, seoseid nende vahel ja elementide ning seoste omadusi (wikipedia).
    Arhitektuur on vundament millele tarkvara ehitatakse. Arhitektuuri mudel defineerib vundamendi visiooni ( agile modeling).
    Tarkvara arhitektuuri kontseptsioon on pärit Edsger Dijkstra 1968 ja David Lorge Parnase 1970.-ndate aastate uurimistöödest.

    Arhitektuuriline disain

    Tarkvarasüsteemi disainiprotsessi osa, mille käigus määratakse kindlaks tarkvarasüsteemi moodustavad alamsüsteemid ja nendevahelise kontrolli ja kommunikatsiooni raamistik .
    Tulemuseks on tarkvarasüsteemi arhitektuuri kirjeldus.

    Arhitektuurse disaini otsused

    Is there a generic architecture that can be used?
    How will the system be distributed?
    What architectural styles are appropriate?
    What approach will be used to structure the system?
    How will the system be decomposed into modules?
    What control strategy should be used?
    How will the architectural design be evaluated?
    How should the architecture be documented?

    Arhitektuurse disaini otsused ja mitte-funktsionaalsed nõuded

    Arhitektuurse disaini otsuseid juhivad mittefunktsionaalsed nõuded:
    Performance
    Localise critical operations and minimise communications. Use large rather than fine - Grain components.
    Security
    Use a layered architecture with critical assets in the inner layers.
    Safety
    Localise Safety - critical features in a small number of sub-systems.
    Availability
    Include redundant components and mechanisms for fault tolerance.
    Maintainability
    Use fine - grain, replaceable components.

    MVC arhitektuur


    MVC-arhitektuuri eelised ja puudused

    Eelised:
    Allows the data to change independently of its representation and vice versa. Supports presentation of the same data in different ways with changes made in one representation shown in all of them.
    Puudused:
    Can involve additional code and code complexity when the data model and interactions are simple .

    Kihiline arhitektuur


    Kihilise arhitektuuri eelised ja puudused

    Eelised:
    Allows replacement of entire layers so long as The interface is maintained. Redundant facilities (e.g.,authentication) can be provided in each layer to increase the dependability of the system.
    Puudused:
    In practice , providing a clean separation between layers is often difficult and a high - level layer may have to interact directly with lower -level layers rather than through the layer immediately below it. Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer.

    Repositooriumi arhitektuur


    Repositooriumi arhitektuuri eelised ja puudused

    Eelised:
    Components can be independent —they do not need to know of the existence of other components. Changes made by one component can be propagated to all components. All data can be managed consistently (e.g., backups done at the same time) as it is all in one place .
    Puudused:
    The repository is a single point of failure so problems in the repository affect the whole system. May be inefficiencies in organizing all communication through the repository. Distributing the repository across several computers may be difficult.

    Klient-server arhitektuur


    Klient - Server arhitektuuri eelised ja puudused

    Eelised:
    The principal advantage of this model is that servers can be distributed across a network . General functionality (e.g., a printing service) can be available to all clients and does not need to be implemented by all services.
    Puudused:
    Each service is a single point of failure so susceptible to denial of service attacks or server failure. Performance may be unpredictable because it depends on the network as well as the system. May be management problems if servers are owned by different organizations.

    Multi-tier client- server architectures

    In a ‘ multi - tier client– server’ architecture, the different layers of the system, namely presentation, data management, application processing, and database, are separate processes that may execute on different processors.
    This avoids problems with scalability and performance if a thin-client two-tier model is chosen, or problems of system management if a fat-client model is used.

    N-Tier klient-server arhitektuuri eelised ja puudused

    Eelised:
    hallatavus
    skaleeritavus
    paindlikus
    kättesaadavus
    Puudused:
    So mainstream

    Peer-to-peer architectures

    Peer to peer (p2p) systems are decentralised systems where computations may be carried out by any node in the network.
    The overall system is designed to take advantage of the computational power and storage of a large number of networked computers.
    Most p2p systems have been personal systems but there is increasing business use of this technology.

    Torude ja filtrite arhitektuur

    Eelised:
    Easy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformations is straightforward. Can be implemented as either a sequential or concurrent system.
    Puudused:
    The format for data transfer has to be agreed upon between communicating transformations. Each transformation must parse its input and unparse its output to the agreed form. This increases system overhead and may mean that it is impossible to reuse functional transformations that use incompatible data structures .

    Komponentidel põhinev arhitektuur

    Eelised:
    Laiendatav: uusi komponente saab lisada vastavalt vajadusele
    Asendatav: komponente on kerge asendada
    Paindlik ja skaleeritav
    Taaskasutatav
    Kapseldatud ja sõltumatud osad
    Puudused:
    Keerukus
    Kommunikatsioon


    Siinipõhine arhitetkuur (ESB)

    Eelised:
    Kommunikatsioon
    Nõrgalt seotud komponendid
    Puudused:
    Single-point-of-failure

    Teenusepõhine arhitektuur (SOA)

    Eelised:
    autonoomne
    nõrgalt seotud
    jagatakse lepingut ja skeemi, mitte sisemisi klasse
    leitavus
    Erinevad platvormid
    Puudused
    tehniline keerukus, eriti WSDL-i ja SOAP -i puhul

    Arhitektuuri disain

    Ära üle inseneeri . Ära tee eeldusi , mida ei saa kontrollida.
    • Mis on fundamentaalsed osad arhitektuurist , mille valesti tegemine on väga suure riskiga süsteemile?
    • Milline osa süsteemist on suurima muutumise tõenäosusega?
    • Milliste osade disainimist võib edasi lükata ilma märkimisväärsete mõjudeta?
    • Millised on võtme-eeldused ja kuidas neid kontrollida?
    • Mis võib põhjustada süsteemi ümber disainimise?

    ADD(Attribute Driven Design)

    ADD töötati välja Carnegie Mellon Ülikooli pool
    Väljakutsed:
    Milline arhitektuur kataks kõige paremini kasutajate vajadusi ?
    Kuidas täita kujuteldava süsteemi nõudeid ?
    Kuidas otsustada, milline arhitektuuri strateegia on sobilik ?
    Kuidas hinnata nõuete täitmisel tehtavate kompromisside mõjusid ?


    ADD on rekursiivne

    1. osa taktika
    Kontrolli, et nõuded oleks piisavad .
    Vali süsteemi osa, mida komponentideks lahutada
    Identifitseeri arhitektuuri juhtivad nõuded
    Vali kontseptsioon, mis täidab juhtivad nõuded
    2. osa dokumenteerimine
    Algväärtusta arhitektuuri elemendid ja jaota vastutused
    Defineeri elementide liidesed
    Verifitseeri ja viimistle nõudeid ning määra nende pealt piirangud elementidele.
    Korda samme kõikide süsteemi osade kohta

    ADD KASU:

    Nõuete vahelised kompromissid tulevad varajases staadiumis välja, mis aitab luua luua parima arhitektuuri nõuete katmiseks.

    Arhitektuuri testimine

    Küsi endalt:
    Millistele eeldustele tugineb arhitektuur ?
    Milliseid nõudeid arhitektuur katab ?
    Mis on selle arhitektuuri võtme riskid ?
    Milliste meetmetega leevendada riske ?
    Mil moel on see arhitektuur edasiminek viimase kandidaadi/baas arhitektuuri suhtes ?


    Agiilne praktika

    Arhitektidel on alandlikkust tunnistada et nad ei oska vee peal käia.
    Arhitektid osalevad aktiivselt arendustegevuses. Nad on meeskonna konsultandid.
    Arhitektidel on alandlikkust tunnistada, et nad ei oska tulevikku ennustada. Küll aga on nad enesekindlad selles, et homseid probleeme saab lahendada homme .
    Arhitektuur tekib iteratiivselt koos arendusega.
    Dokumenteeri nii palju kui on vaja kommunikatsiooniks.
    Mudeleid kommunikeeritakse avalikult kõigile osapooltele, ka poolikuid, et saada tagasisidet.
    Arhitektuuri kontrollitakse eksperimentidega.

    7. Loeng - Architecture of software systems

    Key questions of software architecture

    Regardless of the method used, it must respond to certain key questions .
    Ability to move up and down the abstraction layers
    The reasons :
    • Complexity management
    Hard problems are usually solved one abstraction level up
    • Determining the sphere of influence
    Support complexity management
    Complexity increases exponentially in relation to system size . Fundamentally, three options:
    • Extract more value from the same number of elements
    • Lower the slope of complexity growth
    • Increase the ability to cope with complexity
    Allow to describe functional structure of a system - Can we use the framework to think of nontechnical things?
    Support financial decisions - Architecture determines financial viability of a product or service

    Cost and Architecture


    8. loeng - Tarkvarasüstemi kvaliteet ja testimine

    Väga lühidalt on kvaliteet toote vastavus nõuetele. Keerukate toodete puhul tuleb vastavuse hindamisel arvesse võtta ka toote loomise protsessi.
    Tarkvara kvaliteet = toode + nõuded + protsessid
    Tarkvara lõpptulemus sõltub kogu arendusprotsessist:
    • sealhulgas vajadustele vastavast riistvarast
    • tarkvara arenduse meetoditest ja vahenditest
    • projekti- ja kvaliteedihaldusest
    • organisatsioonist
    • standarditest

    Tarkvaratoode koosneb

    • Arenduse käigus hangitud infotehnoloogiavahendid: riistvara, standardtarkvara, sideseadmed.
    • Arenduse käigus tehtud töö: täitja arendatud tarkvara (sealhulgas lähtekood, objektkood, täitmiskood jm); installatsioonid, kohandamised, muudatused; andmehõive.
    • Muudatused tellija organisatsioonis, protsessides, töökorralduses...
    • Metoodika: tulemuste kasutamine; tulemuste edasiarendamine; uute arenduste tegemine.
    • Projektdokumentatsioon kasutamise kohta (kasutajajuhendid); objektsüsteemi (nt organisatsioon, mille jaoks tarkvara arendatakse) kohta; loodavate objektide kohta (programmi/testimise dokumentatsioon ); installeerimise ja seadistamise kohta; arenduse (sh testimise) kohta.
    • Teadmised projekti tulemuste kasutamisest; objektsüsteemist (süsteemianalüüs või vajalikud muudatused seadusandluses); projektist; arendusest.
    • Õigused tööks, arendamiseks , levitamiseks.
    • Vahendid hoolduseks, muudatusteks, arenduseks.

    Tarkvara nõuded

    Funktsionaalne nõue - Vastavad küsimusele: „Mida peab tarkvara tegema?“ (Ärinõudmised, ärireeglid, standardid )
    Mittefunktsionaalne nõue – Vastab küsimusele: „Kuidas tarkvara peab vajalikke funktsioone täitma?“ (Süsteemsed nõudmised ja piirangud, Tõhusus, turvalisus, töökindlus, kasutajaliides jne)
    Testitav /Mittetestitav nõue
    Reaalne/Ebareaalne nõue – Nõue võib olla testitav, kuid ebareaalne, ebamõistlik, ebapiisavalt spetsifitseeritud jne
    Kokkuvõtvalt hea nõue võiks olla : Üheselt mõistetav, Selge ja lühike, Realiseeritav, Sõltumatu, Vajalik

    Testimine

    Testimist võib laias mõttes määratleda ka kui kõikidest elutsükli tegevustest (nii staatilistest kui ka dünaamilistest) koosnevat protsessi, mis puudutab tarkvara ja sellega seotud toodete planeerimist, ettevalmistust ja hindamist ning mille eesmärk on kindlaks teha toodete vastavus spetsifitseeritud nõuetele, näidata et nad vastavad eesmärgile ning leida defekte.
    Efektiivseks testimiseks ei piisa vaid süsteemist, on vaja ka teada nõudeid ja protsesse.

    Testimise meetodeid

    Dünaamiline testimine – testimine, mille käigus testitavat tarkvara käivitatakse
    Staatiline testimine (static testing ) – süsteemi või komponendi (koodi või dokumendi) testimine ilma testitavat tulemit käivitamata (Läbivaatuse (review), Staatiline analüüs (static analysis ))
    Valge kasti testimine - Testijal on juurdepääs sisemistele andmestruktuuridele ja algoritmidele (ja koodile , mida rakendatakse). Testija püüab süstemaatiliselt läbida programmi mingeid osasid, näiteks lauseid , harusid, teid.
    Valge kasti testimine sisaldab:
    -- Rakendusliideste (API) testimine – rakendust testitakse avalike ja privaatsete rakendusliideste kaudu
    -- Vigade süstimine – koodi ulatuse parandamine kontrollides, kas tarkvara töötab vigade lisamisel
    -- Staatiline testimine – valge kasti testimine hõlmab kogu staatilist testimist
    Musta kasti testimine – Testimine kohtleb tarkvara kui "musta kasti", teadmata midagi selle sisemisest teostusest.
    Musta kasti testimismeetodite hulka kuuluvad:
    -- Spetsifikatsiooni põhine testimine
    -- Juhuslikud sisendid ja lisatud vead
    -- Uurimuslik testimine
    -- Piirväärtuste analüüs
    -- Suitsu testimine
    -- Kasutusmugavuse testimine
    Halli kasti testimine – Testimisel on olemas juurdepääs sisemistele andmestruktuuridele ja algoritmidele testjuhtumite koostamisel, kuid testimine viiakse läbi kasutaja või musta kasti tasemel. Halli kasti testimise alla kuulub andmebaasi muutmine, sest tavaliselt ei saa kasutaja väljaspool testitavat süsteemi andmeid muuta.

    Testimise tasandid


    Ühiktestimine - Ühiktestimisel vastab üks test konkreetsele koodi osale, tavaliselt funktsioonile. Objektorienteeritud keskkonnas testitakse klasside tasemel ja minimaalsesse testi kaasatakse ka konstruktorid ja destruktorid. Ühiktestimisega ei saa tagada terve tarkvaratoote õigsust. Pigem kontrollitakse sellega, kas erinevad tarkvara osad töötavad üksteisest eraldi.
    Lõimumise testimine – Kontrollitakse, kas komponentide vahelised liidesed vastavad tarkvara disainile. Tarkvara komponente võib integreerida järk-järgult või ühekorraga. Tavaliselt eelistatakse viimast, sest nii saab kiiremini leida ja parandada vigu liidestes. Selline testimine paljastab defektid liidestes ja vastastikustes toimetes integreeritud komponentide (moodulite) vahel.
    Süsteemi testimine – Testitakse täielikult integreeritud süsteemi, et kinnitada süsteemi nõuetele vastavust. Musta kasti testimine.

    Teisi testimise viise

    Süsteemi integratsiooni testimine – Kinnitatakse, et süsteem on integreeritud mistahes välise või kolmanda osapoole süsteemiga, mis on määratletud süsteemi nõuetes.
    Regressioonitestimine – Eesmärgiks on otsida vigu pärast koodi olulist muutmist .
    Vastuvõtu testimine – Vastuvõtu testimine võib tähendada kahte asja:
    1. Viiakse läbi proovitest, et kontrollida, kas uus tarkvara komponent on vastuvõetav peamisse testimise protsessi, näiteks enne lõimumis- või regressioonitesEmist.
    2. Kliendi tehtud testimist, tihti tema enda arenduskeskkonnas ja riistvaral, nimetatakse kasutaja vastuvõtu testimiseks.

    Testimise tüübid

    Funktsionaalne testimine
    • Riskipõhine – Riskipõhise testimise idee on testida esmalt tootega seotud kriitilisi riske.
    Uuriv testimine – Uuriv testimine on mitteformaalne tarkvara testimise tehnika, mille puhul testija hindab testide kavandamist nende täitmise käigus ja kasutab saadud informatsiooni uute ja paremate testide projekteerimiseks
    • Suitsu testimine – Suitsutestimisel täidetakse alamhulk kõigist testidest selgitamaks, kas põhilised funktsioonid töötavad.
    Ekspertteadmiste põhine – Kogenud arendaja või testija oskab tõenäolisi vea kohti ette aimata.
    Mittefunktsionaalne testimine - Jõudlustestimine ja koormustestimine
    Stabiilsuse testimine – Stabiilsuse testimine kontrollib, kas tarkvara on võimeline pidevalt töötama kindla ajaperioodi jooksul.
    Kasutatavuse testimine – Kasutuse katsetamine on vajalik, et kontrollida, kas kasutajaliidest on lihtne kasutada ja mõista.
    Turvalisuse testimine
    Destruktiivne testimine - Destruktiivsel testimisel üritatakse tekitada tõrkeid tarkvaraprogrammis või käivituskeskkonnas, et testida selle robustsust.

    Testimise tsükkel

    Nõuete analüüs - Katsetamine peaks algama tarkvaraarenduse elutsükli nõuete faasis.
    Testimise planeerimine – Testimise strateegia, plaani ja testimiskeskkonna loomine.
    Testide arendamine - Tarkvara testimiseks kasutatavate protseduuride, stsenaariumite, testjuhtumite, andmekogude ja skriptide loomine.
    Testide täitmine
    Testide aruandlus – Kui on testitud , siis testijad teevad aruande ja annavad teada kas tarkvara on valmis väljastamiseks.
    Testitulemuste või vigade analüüs – Seda teeb arendusmeeskond tavaliselt koos kliendiga, et otsustada, milliseid vigu tuleks parandada, millised tagasi lükata ja milliseid vigu parandada millalgi tulevikus.
    Vigade uuesti testimine
    Regressioonitestimine
    • Testimise lõpetamine - Kui katse vastab lõpetamise kriteeriumitele, siis tegevused nagu väljundi püüdmine, õppetunnid, tulemused, logid ja projektiga seotud dokumendid arhiveeritakse ja neid kasutatakse viitena tulevastes projektides.

    Testimise maht

    Ideaalselt peaks testimise maht sõltuma tarkvarale esitatud nõuetest - testitakse seni, kuni need on rahuldatud. Praktiliselt tehakse nii vaid tõesti kriitiliste rakenduste korral.

    Testimise lõpetamine

    • Kõik ekvivalentsiklassid (piirjuhud) peavad olema testitud
    • Testimine peab vastama haruadekvaatsuse kriteeriumile
    • Olulisemad andmekombinatsioonid peavad olema testitud
    • Andmepõhise testimise piirjuhud peavad olema testitud
    • V% lisatud vigadest peavad olema avastatud
    • Tarkvara töökindlus peab olema P%

    9. loeng – Tarkvara testimine, praktiline vaade


    Igas hilisemas faasis on vea parandamise hind suurem kui varasemates.

    10. loeng – Agiilne tarkvaratehnika


    Kanbani ideoloogia

    Lean ”– Keskendu sellele, Mida klient vajab
    Don’t build features that nobody needs right now
    Don’t write more specs than you can code
    Don’t write more code than you can test
    Don’t test more code than you can deploy
    Väldi Inimeste või ressursside ülekoormamist
    Väldi Ebaühtlast töökoormust
    Väldi Tegevusi ,Mis ei lisa väärtust

    Minimal Marketable Feature (MMF)

    A minimal marketable feature (MMF) is a chunk of functionality that delivers a subset of the customer’s requirements, and that is capable of returning value to the customer when released as an independent entity
    Think of it this way: Gather up all the stories that share the same SO THAT clause representing the GOAL — That is your MMF!

    Kanbani võimalikud eelised Scrumi ees

    Lihtsus!
    Puudub suurte backlogide haldamine
    Puudub “time boxingSprint Backlogide jaoks
    Puuudub Arendamise edukuse hindamine ja mõõtmine

    Scrum vs. Kanban

    Kanban limits WIP per workflow state, while Scrum limits WIP per iteration
    Scrum Board is reset between each iteration
    Scrum prescribes Crossfunctional teams, while Kanban could have specialised teams
    Scrum backlog items must fit in a Sprint, while Kanban can have long running items
    Kanban daily meetings( optional ) focuses on changes on the board, while Scrum focuses on assignments of each person (yesterday, today , problems)
    Scrum estimates and measures progress, while this is optional in Kanban
    Kanban prescribes only 2 things: WIP limit , Kanban board

    Kokkuvõte Agiilsest tarkvaratehnikast

    Agiilsed tarkvara organiseerimise meetodid → probleemvaldkonna esialgne liigendamine on kriitilise tähtsusega!
    Ka analüüs peab toimuma iteratiivselt!
    Organiseeri tarkvaraarendus eesmärgipõhiselt, kus kasutuslood kirjeldavad ärieesmärkide realiseerimist
    Üldiselt hõlmab üks Sprint mitut ärieesmärki
    Kasutuslood võib omakorda jaotada ülesanneteks-Taskideks
    Kanbanis on oluline Pull-põhimõte
    Kanbanis üldiselt Ärieesmärk = MMF

    11. loeng – Extreme programming

    Working software is the primary measure of progress.
    Welcome changing requirements, even late in development.
    Extreme programming - a software-development discipline that organises people to produce higher -quality software more productively

    How it works (atleast in codeborne):

    customer describes problem, we give rough estimate, we agree on: hourly price , approximate scope or time
    storytelling – customer + the whole team
    Iteration meeting - every week (the time between iteration meetings can vary up to 2 weeks) preferably with client, story details are discussed, customer defines priority
    demo of added functionality
    daily work - stand-up meeting, open workspace
    development - pair programming, test-driven development, refactoring
    no big design up front (BDUF), simple desing(just enough design)
    collective code ownership, automated acceptance tests
    deliver - continuous integration, continuous deployment
    customer collaboration - frequent discussions, immediate feedback
    speed - sustainable pace, estimates -> velocity
    realease - ASAP
    improve - continuous learning , retrospective

    XP VALUES

    improve communication
    seek simplicity
    get feedback
    proceed with courage

    12. loeng – Disain

    FOUR ELEMENTS OF SIMPLE DESIGN

    1. Passes all tests
    2. No duplication
    3. Expresses intent
    4. Small

    Clean code

    Muutujate, meetodite ja klasside nimed peaksid väljendama seda, mida vastav element seal koodis tähendab/teeb. NIMI PEAB AITAMA MÕISTA SISU JA KONTEKSTI
    CORRECT ENGLISH ONLY, PLEASE !
    • Sõna-sõnalt tõlge ei pruugi anda õiget ingliskeelset vastet
    • Kasutage õiged antud valdkonna termineid, uurige valdkonna ekspertidelt, mis on õiged terminid
    • Grammatika ja õigekiri!
    • Sõnastikud, õigekirjakontrollijad, Google
    • Proovige, kas koodi saab lugeda nagu lauseid tekstis?
    Stabiilsus - ÜKS TERMIN SAMA MÕISTE JAOKS
    HEA FUNKTSIOON
    • lühike
    • vähe trepiastmeid /indentation/
    • tegeleb ainult ühe asjaga (üks abstraktsiooni tase)
    • “Functions should do one thing . They should do it well. They should do it only.”
    FUNKTSIOONI ARGUMENDID
    • “Less is more” – mida vähem, seda parem
    • Ideaalne funktsioon ei võta ühtegi argumenti, Ühe ja kahe argumendiga on ka OK, Kolm on üldjuhul juba liiga palju
    KUIDAS ARGUMENTE VÄHENDADA?
    • Selle asemel, et järjest edasi anda ühte argumenti, tehke klassi tasemel väli
    • Kui funktsioon vajab rohkem kui 2 argumenti, siis võib-olla peaks need omaette klassi tõstma?
    • Vältige üksikuid boolean argumente (lippe)
    VÄLTIGE KÕRVALMÕJUSID - Funktsioon, mis on definitsiooni (nime) järgi read-only, ei tohi muuta olekut
    KOMMENTAARID ON PAHAD
    • Kommentaarid valetavad: Neid ei saa koodiga siduda, Neid ei saa automaatselt muuta, Neid ei saa testida, Nad jäävad “ajast maha”
    • Tõde on ainult koodis!
    • Ära kasuta kommentaari, kui sa saaksid kasutada funkstiooni või muutujat
    MILLAL KOMMENTAARE KASUTADA?
    • Legal comments
    • Warning of consequences
    • TODO comments
    • Amplification
    • javadocs in public APIs
    THE BOY SCOUT RULE - Leave the campground cleaner than you found it

    Objektorienteeritud disain

    ABSTRACT CLASSES - Kirjelda tegevuste järjekord , jäta vabaks implementatsioon
    DEPENDENCY INJECTION, INVERSION OF CONTROL
    • Klass ei lähe ise “ otsima ” omale vajalike ressursse vaid need antakse talle ette.
    • Selgem disain
    • Lihtsam testida
    COMPOSITION OVER INHERITANCE
    • Inheritance is for “is-a” relationships:
    • Composition is for “ consists -of”, “contains”, “uses”, “has” relationships:
    • Composition means decoupling – independence of each other's changes
    IMMUTABLE OBJECTS
    • An immutable object is an object whose state cannot be modified after it is created
    • Lihtsustab programmeerimist
    • Võimaldab kompilaatoril/virtuaalmasinal koodi optimeerida
    DISAINI MUSTRID
    • Tüüplahendused objektorienteeritud disainis olulistele ja tihti esile kerkivatele probleemidele
    • Kogenumate arendajate oskuste ja kogemuste süstematiseeritud kataloog
    • Lihtsustab arendajate suhtlemist – “me kasutame Strategy mustrit”

    13. loeng - Arenduse infrastruktuur ja konfiguratsioonihaldus

    Inimesed

    • Oluliseim komponent
    • Suhted ja suhtlemine on nagu õli, mis paneb kogu masinavärgi tööle
    Tööriistad üksi tööd ei tee
    • Klient, testija, arendaja

    Nõuded

    Milleks hallata?

    • Muutuvad ajas
    • Ununevad
    • Olulisus muutub
    • Tekivad ja kaovad
    • Folkloor
    • Ebakõlad/vead
    • Progressi jälgimine

    Planeerimine

    • Alusta väga üldisest
    • Planeerimine ei ole ainult kuupäevad, millal asi peab valmis olema
    • Nõuete olemasolu/puudumine annab plaanidele uue mõõtme
    • Resursside olemasolu/puudumine
    Plaane tuleb ümber vaadata ja muuta vastavalt olukorrale
    • Plaan on realistlik kuni 2 nädalat ette

    Versioonihaldus

    • Ajalugu. Seotus nõuetehaldusega
    • Muudab arenduse paindlikumaks.
    • Meeskonnatöö
    • Ausaamise, milline lähtekood on hetkel toodangus
    • Kes selle siia tegi?

    Build/Deploy

    Continuous integration:

    • Kompileerib vajadusel koodi
    • Koodianalüsaator?
    • Paigaldab rakenduse
    • Käivitab unit testid
    • Käivitab funktsionaalsed (UI) testid
    • Väldi käsitööd. Sellega kaasnevad vead.
    • Kasuta seda tulemust, mis sa continuous integration vahenditega juba valmis tegid.
    • Kui ei saa siis tee selgeks, miks ei saa. Elimineeri need põhjused ja kasuta ikka.
    • Kui siis ka ei saa siis kasuta vähemalt samu build skripte.
    • ... muudmoodi liigub asi kontrollimatuse suunas.

    Testimine

    • Unit test
    • Acceptance test
    • Regression test
    • Jõudlustest

    PS! Siin tasub seda slide showd kindlasti vaadata, tekivad paremad seosed.


    14. loeng – Scrum ja Kanban in practise

    Tarkvaraarendus põhimõtted

    • Customer Satisfaction
    • Satisfaction
    • Suprises
    • Eliminate waste
    • Amplify learning
    • Empower The team
    • Build Integrity in
    • See The whole
    • !Decide as late as possible
    • !Deliver as fast as possible

    15. Loeng - Tarkvarasüsteemi evolutsioon ja hooldus

    Mis on tarkvaratehinka?

    Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale

    Tarkvara arenduskulud

    Kulud sõltuvad arendatava süsteemi tüübist ja süsteemile esitatud nõudmistest nagu näiteks jõudlus ja töökindlus

    A spiral model of development and evolution

    Evolution vs. Maintenance

    Software maintenance is viewed as a process different from evolution because:
    In many cases maintenance is performed by a different organisation. Maintenance involves extra process activities, such as program understanding

    Evolution and servicing

    Evolution - The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system.
    Servicing - At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and changes to reflect changes in the software’s environment. No new functionality is added.

    Evolution processes

    Software evolution processes depend on: The type of software being maintained; The development processes used; The skills and experience of the people involved; Proposals for change are the driver for system evolution.
    Should be linked with components that are affected by the change, thus allowing the cost and impact of the change to be estimated.
    Change identification and evolution continues throughout the system lifetime.

    Urgent change requests

    Urgent changes may have to be implemented without going through all stages of the software engineering process
    Põhjusteks võib tuua seda, kui on tekkinud viga, mis vajab kiiret lahendust , või kui süsteemi tehtud muudatused on tekitanud mingi kriitilise vea. Kui ärilised muudatrused nõuavad kiiret programmaatilist muudatust.

    Agile methods and evolution

    - Agile methods are based on incremental development so the transition from development to evolution is a seamless one.
    - Automated regression testing is particularly valuable when changes are made to a system.
    - Changes may be expressed as additional user stories.

    Handover problems


    Where the development team have used an agile approach but the evolution team is unfamiliar with agile methods and prefer a plan-based approach or vice versa.

    Program evolution dynamics

    Program evolution dynamics is the study of the processes of system change.
    The first law: Change is inevitable
    - The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements!
    - Systems are tightly coupled with their environment. When a system is installed in an environment it changes that environment and therefore changes the system requirements.
    - Systems MUST be changed if they are to remain useful in an environment.
    LEHMAN'S LAWS (MA EI TEA KAS NEID PEAB PÄHE AJAJAMA, AGA SIIN NAD ON)

    Software maintenance


    - Modifying a program after it has been put into use.
    - The term is mostly used for changing custom software. Generic software products are said to evolve to create new versions.
    - Maintenance does not normally involve major changes to the system’s architecture.
    - Changes are implemented by modifying existing components and adding new components to the system.

    Types of maintenance


    - Maintenance to repair software faults
    - Maintenance to adapt software to a different operating environment
    - Maintenance to add to or modify the system’s functionality

    Maintenance costs


    - Usually greater than development costs
    - Affected by both technical and non-technical factors.
    - Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult.
    - Ageing software can have high support costs

    Maintanance cost factors

    Team stability - if the staff stays the same, then the cost reduces
    Contractual responsibility - The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change.
    Staff skills – staff knowledge and experience
    Program age and structure

    16.loeng – Tarkvaraprotsessi organisatsioonist

    Suurem jagu juhtidest teavad, kuidas tööd tehakse, kuid ei tea, kuidas tööd juhtida. Mõeldakse rohkem tehnilistest asjadest kui inimestest.
    Vigade tegemine - Vigade tegemist tuleks julgustada, sest sellest õpib
    Juhid peavad ka mõistma töötajaid, mitte tegema ainult omakeskis otsuseid.
    Kui töötaja ära läheb, siis palkame uue ja veel parema!
    Kui lubada olla inimestel erilised, siis on nad lojaalsemad.
    Keskmine tarkvaraarendaja kulutab umbes 5% ajast enda arendamise peale
    Kvaliteet on vahend saavutamaks kõrgemat tootlikkust
    Kvaliteediga on seotud ka arendaja ensehinnang nii et, sel juhul on kvaliteedile pürgimine hea asi.
    See seadus kehtib üllatavalt paljudes organisatsioonides - Telefon, E-mail, IM hajutab keskendumisvõimet

    Seitse punkti, mis arvatakse, et toimivad, aga tegelikult on vastupidi

    Praktiliselt võtta nende punktide vastaspunktid ja siis saad teemale pihta.
    1. Leitud on mingi uus nipp millega soovitakse tootlikust mitmekordistada
    2. Teised firmad kasutavad mingit tarkvara ja sellega on tootlikus tõusnud 200%.
    3. Me jääme tehnoloogiast maha!
    4. Programmeerimiskeele vahetamine annab meile suure eelise.
    5. Tegemata asjade pärast tuleks tootlikust kahekordistada
    6. Automatiseerime tarkvaratootmise täielikult!
    7. Inimesed töötavad paremini kui panna nad pinge alla.

    Eksamiküsimused


  • Kvaliteetse tarkvara funktsionaalsed ja mittefunktsionaalsed atribuudid
    Teostab ettenähtud funktsionaalsust
    Hooldatav – Tarkvara peab arenema, et vastata muutuvatele vajadustele.
    Usaldusväärne – Töökindlus ja turvalisus.
    Vastuvõetav – Kasutajad on aktsepteerinud selle. Tarkvara on neile arusaadav, kasutatav ja ühilduv teiste süsteemidega.
  • Erinevate tarkvarasüsteemide nõuete kirjeldamine. Nt netipank, mobiiliapp jne. Nõuete vastavus nõuete kolmele olulisele omadusele
  • Üheselt kontrollitav
  • Lihtsalt kontrollitav
  • Selge, lühike, konkreetne kirjeldus / selgitus . Alla 30 sõna enamasti.
  • Erinevate arhitektuuride positviised ja negatiivsed omadused ja nende arhitektuuride kasutusvaldkonnad.
    Need tasub lugeda järjest läbi 6. loeng: Tarkvarasüsteemi arhitektuuri kavandamine alt
  • Mudeli olemus ja mudelite klassifitseerimine
    Protsessi lihtsustatud esitus teatud vaatepunktist.
    Protsessikeskne
    Andmekeskne
    Rollikeskne
    Mudelite näited:
    Kosk
    Iteratiivne arendamine
    Komponendipõhine
    Läbi vaadata 5. loeng – Mudelid ja modelleerimine
  • Tarkvarasüsteemi kvaliteediatribuudid nii lõppkasutaja, arendaja kui ka äri vaatenurgast. Igaühe mõju süsteemi arhitektuuriotsustele.
    INFOKS:
    Arhitektuurse disaini otsuseid juhivad mittefunktsionaalsed nõuded:
    Performance
    Localise critical operations and minimise communications. Use large rather than fine - Grain components.
    Security
    Use a layered architecture with critical assets in the inner layers.
    Safety
    Localise Safety - critical features in a small number of sub-systems.
    Availability
    Include redundant components and mechanisms for fault tolerance.
    Maintainability
    Use fine - grain, replaceable components.
  • Testitasemete teooria ja erinevate tasemete kirjeldused
  • Unit testimine
  • Integration testimine
  • System testimine
  • UAT
    PS! Regressioonitestimist tehakse alati kui jooksutatakse ka enne selle featur-i arendamist olemas olnud teste .
    LOE LÄHEMALT: Testimine
  • Clean Code põhimõtted ja erinevatele reeglitele vastavus
    LOE LÄHEMALT: 12. loeng – Disain
  • Tarkvara arendusraamistike (XP, Scrum, Kanban, RUP jne) elemendid ja nende kirjeldused
    LOE LÄHEMALT: 11. loeng – Extreme programming
    Ja
    10. loeng – Agiilne tarkvaratehnika
  • Olulised protsessid ja tegevused IT-teenuse toetamise juures.
    Software evolution processes depend on: The type of software being maintained; The development processes used; The skills and experience of the people involved; Proposals for change are the driver for system evolution.
    Should be linked with components that are affected by the change, thus allowing the cost and impact of the change to be estimated.
    Change identification and evolution continues throughout the system lifetime.
  • Tsentraalse ja hajutatud mudeliga versioneerimise vahendid ja erinevused nende kahe mudeli vahel.
    Tsentraalne : SVN, CVS
    Hajutatud: GIT, Mercurial
    Erinevus ongi nende arhitektuuris/arhitektuurist tulenevalt. Samuti erinevad käsud nendega ümber käimiseks.
  • Loetle tarkvarainseneri professionaalse vastutuse neli aspekti ja selgita neid.
    Konfidentsiaalsus – Tarkvarainsener peab respekteerima oma tööandja ja klientide konfidentsiaalsust, sõltumata sellest, kas formaalne leping konfidentsiaalsuse kohta on alla kirjutatud
    Kompetents – Tarkvarainsener ei tohi anda väära ettekujutust oma kompetentsist. Ta ei tohi võtta teadlikult vastu tööd, mis on väljaspool tema kompetentsi.
    Intellektuaalne omand – Tarkvarainsener peab olema teadlik kohalikest seadustest ja määrtustest, mis sätestavad intellektuaalse omandi kasutamise näiteks patentide ja kopeerimisõiguste näol.
    Arvuti väärkasutus – Tarkvarainsener ei tohi kasutada oma tehnilisi oskusi teiste inimeste arvutite väärkasutamiseks.
  • Kuidas struktureerib FURPS+ raamistik nõuete kogumiku? Too näited panga veebi-iseteeninduskeskkonna jaoks erinevat tüüpi nõuete kohta FURPS+ järgi?
    Functionality (funktsionaalsus) - Kirjeldus, kuidas süsteem peaks käituma kasutajapoolsete või teisest süsteemist pärinevate sisendite peale.
    Usability (kasutatavus) - Sobivus kasutaja mõttemudeliga: millised kasutajad ja millises situatsioonis teie rakendust kasutavad?
    Reliability (käideldavus) – lubatavate vigade arv ja nende tõsidus, kui palju jääb vigade tekkimise vahele aega, kui kiiresti vead lahendatakse
    Performance (jõudlus)
    Supportability (toetus) – kui palju raha peab kulutama, et asja töös hoida, testitavus, konfigureeritavus, laiendatavus, lokaliseeritavus.
    + (disain, tehnilise realiseerimise piirangud, liideste piirangud, majutuse piirangud jms)
  • Loetle „Agile Manifesto“ neli põhiprintsiipi ja selgita neid.
  • Millised on põhilised testide tüübid? Selgita iga tüüpi.
    Sama nagu küsimus 6 pm. Allpool on täpselt välja toodud veel tüüpe.
  • Võrdle Kanbani ja Scrumi metodoloogiaid.
    Kanban limits WIP per workflow state, while Scrum limits WIP per iteration
    Scrum Board is reset between each iteration, Kanban’s is not.
    Scrum prescribes Cross -functional teams, while Kanban can have specialised teams.
    Scrum backlog items must fit in a Sprint, while Kanban can have long running items.
    Kanban daily meetings(optional) focuses on changes on the board (in the flow of the process / on the board), while Scrum focuses on assignments of each person (yesterday, today, problems)
    Scrum estimates and measures progress, while this is optional in Kanban.
    Kanban prescribes only 2 things: WIP limit, Kanban board. „Pure Scrum“ has more things that it prescribes, but it is not mandatory to follow all of them.
    Scrum has roles: Product Owner , Scrum Master, Team Member , while Kanban has no prescribed roles.
  • Milleks kasutatakse versioneerimise märgendeid ja harusid. Too näited mõlema kohta.
    Märgendeid: Et väärtuslikku infot hoida branch-i juures. Enamasti on see release info versiooni kohta.
    Harusid: Et erinevad tiimid või sama tiim saaks feature-id või lihtsalt erinevaid versioone arendada ilma, et peaksid peaharu solkima.
  • Mis on XP põhiväärtused?
    improve communication
    seek simplicity
    get feedback
    proceed with courage
    respect
  • Kanbani põhiväärtused
    • Customer Satisfaction
    • Eliminate waste
    • Amplify learning
    • Empower The team
    • Build Integrity in
    • See The whole
    • !Decide as late as possible
    • !Deliver as fast as possible
  • Mis on nõuete inseneeria ?
    The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
  • What are Functional requirements ?
    Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do.
    - Describe functionality or system services.
    - Depend on the type of software, expected users and the type of system where the software is used.
    - Functional user requirements may be high-level statements of what the system should do.
    - Functional system requirements should describe the system services in detail.
  • What are Non-functional requirements ?
    Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. May apply to the system as a whole as well as to individual features or services.
    - These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.
    - Process requirements may also be specified mandating a particular IDE, programming language or development method.
    - Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.
    - Non-functional requirements may affect the overall architecture of a system rather than the individual components.
    - A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required.
  • Nõuete loomise protsessi osad
    Requirements discovery - Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.
    Requirements classification and organisation - Groups related requirements and organises them into coherent clusters.
    Prioritisation and negotiation - Prioritising requirements and resolving requirements conflicts.
    Requirements specification - Requirements are documented and input into the next round of the spiral.
  • RUP-i faaside selgitused
    Inception: äriline analüüs
    Elaboration: nõuete analüüs, arhitektuuriline disain, arendusplaan
    Construction: detailne kavandamine, realiseerimine ja testimine
    Transition: süsteemi käitamine
  • Mis on tarkvarasüsteemi arhitektuur?
    Kirjeldus selle kohta, kuidas tarkvarasüsteem on organiseeritud.
    Süsteemi illustratsioon, mis aitab aru saada süsteemi käitumisest (Software Engineering Institute http://www.sei.cmu.edu/ ).
    Süsteemi arhitektuur on struktuuride kogum, mis aitavad mõista süsteemi, hõlmates tarkvara elemente, seoseid nende vahel ja elementide ning seoste omadusi (wikipedia).
    Arhitektuur on vundament millele tarkvara ehitatakse. Arhitektuuri mudel defineerib vundamendi visiooni (agile modeling).
  • Mis on agiilse arhitektuuri loomise omadused?
    Arhitektidel on alandlikkust tunnistada et nad ei oska vee peal käia.
    Arhitektid osalevad aktiivselt arendustegevuses. Nad on meeskonna konsultandid.
    Arhitektidel on alandlikkust tunnistada, et nad ei oska tulevikku ennustada. Küll aga on nad enesekindlad selles, et homseid probleeme saab lahendada homme.
    Arhitektuur tekib iteratiivselt koos arendusega.
    Dokumenteeri nii palju kui on vaja kommunikatsiooniks.
    Mudeleid kommunikeeritakse avalikult kõigile osapooltele, ka poolikuid, et saada tagasisidet.
    Arhitektuuri kontrollitakse eksperimentidega.
  • Key questions of software architecture
    Ability to move up and down the abstraction layers
    The reasons:
    • Complexity management
    • Hard problems are usually solved one abstraction level up
    • Determining the sphere of influence
    Support complexity management
    Complexity increases exponentially in relation to system size. Fundamentally, three options:
    • Extract more value from the same number of elements
    • Lower the slope of complexity growth
    • Increase the ability to cope with complexity
    Allow to describe functional structure of a system - Can we use the framework to think of nontechnical things?
    Support financial decisions - Architecture determines financial viability of a product or service
  • Testimise meetodid
    Dünaamiline testimine – testimine, mille käigus testitavat tarkvara käivitatakse
    Staatiline testimine (static testing) – süsteemi või komponendi (koodi või dokumendi) testimine ilma testitavat tulemit käivitamata (Läbivaatuse (review), Staatiline analüüs (static analysis))
    Valge kasti testimine - Testijal on juurdepääs sisemistele andmestruktuuridele ja algoritmidele (ja koodile, mida rakendatakse). Testija püüab süstemaatiliselt läbida programmi mingeid osasid, näiteks lauseid, harusid, teid.
    Valge kasti testimine sisaldab:
    -- Rakendusliideste (API) testimine – rakendust testitakse avalike ja privaatsete rakendusliideste kaudu
    -- Vigade süstimine – koodi ulatuse parandamine kontrollides, kas tarkvara töötab vigade lisamisel
    -- Staatiline testimine – valge kasti testimine hõlmab kogu staatilist testimist
    Musta kasti testimine – Testimine kohtleb tarkvara kui "musta kasti", teadmata midagi selle sisemisest teostusest.
    Musta kasti testimismeetodite hulka kuuluvad:
    -- Spetsifikatsiooni põhine testimine
    -- Juhuslikud sisendid ja lisatud vead
    -- Uurimuslik testimine
    -- Piirväärtuste analüüs
    -- Suitsu testimine
    -- Kasutusmugavuse testimine
    Halli kasti testimine – Testimisel on olemas juurdepääs sisemistele andmestruktuuridele ja algoritmidele testjuhtumite koostamisel, kuid testimine viiakse läbi kasutaja või musta kasti tasemel. Halli kasti testimise alla kuulub andmebaasi muutmine, sest tavaliselt ei saa kasutaja väljaspool testitavat süsteemi andmeid muuta.
  • Testimise tüübid
    Funktsionaalne testimine
    • Riskipõhine – Riskipõhise testimise idee on testida esmalt tootega seotud kriitilisi riske.
    • Uuriv testimine – Uuriv testimine on mitteformaalne tarkvara testimise tehnika, mille puhul testija hindab testide kavandamist nende täitmise käigus ja kasutab saadud informatsiooni uute ja paremate testide projekteerimiseks
    • Suitsu testimine – Suitsutestimisel täidetakse alamhulk kõigist testidest selgitamaks, kas põhilised funktsioonid töötavad.
    Ekspertteadmiste põhine – Kogenud arendaja või testija oskab tõenäolisi vea kohti ette aimata.
    Mittefunktsionaalne testimine - Jõudlustestimine ja koormustestimine
    Stabiilsuse testimine – Stabiilsuse testimine kontrollib, kas tarkvara on võimeline pidevalt töötama kindla ajaperioodi jooksul.
    Kasutatavuse testimine – Kasutuse katsetamine on vajalik, et kontrollida, kas kasutajaliidest on lihtne kasutada ja mõista.
    Turvalisuse testimine
    Destruktiivne testimine - Destruktiivsel testimisel üritatakse tekitada tõrkeid tarkvaraprogrammis või käivituskeskkonnas, et testida selle robustsust.
  • Testimise tsükkel
    Nõuete analüüs - Katsetamine peaks algama tarkvaraarenduse elutsükli nõuete faasis.
    Testimise planeerimine – Testimise strateegia, plaani ja testimiskeskkonna loomine.
    Testide arendamine - Tarkvara testimiseks kasutatavate protseduuride, stsenaariumite, testjuhtumite, andmekogude ja skriptide loomine.
    Testide täitmine
    Testide aruandlus – Kui on testitud, siis testijad teevad aruande ja annavad teada kas tarkvara on valmis väljastamiseks.
    Testitulemuste või vigade analüüs – Seda teeb arendusmeeskond tavaliselt koos kliendiga, et otsustada, milliseid vigu tuleks parandada, millised tagasi lükata ja milliseid vigu parandada millalgi tulevikus.
    Vigade uuesti testimine
    Regressioonitestimine
    • Testimise lõpetamine - Kui katse vastab lõpetamise kriteeriumitele, siis tegevused nagu väljundi püüdmine, õppetunnid, tulemused, logid ja projektiga seotud dokumendid arhiveeritakse ja neid kasutatakse viitena tulevastes projektides.
  • XP põhiväärtused
  • Hoolduse tüübid, maksumus ja selle faktorid
    Types of maintenance
    - Maintenance to repair software faults
    - Maintenance to adapt software to a different operating environment
    - Maintenance to add to or modify the system’s functionality
    Maintenance costs
    - Usually greater than development costs
    - Affected by both technical and non-technical factors.
    - Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult.
    - Ageing software can have high support costs
    Maintanance cost factors
    Team stability - if the staff stays the same, then the cost reduces
    Contractual responsibility - The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change.
    Staff skills – staff knowledge and experience
    Program age and structure
  • 06.01 olnud küsimused (ülejäänud peaks materjalis pm olemas olema):
  • Mida kasulikku saab eesmärgi mudeli kasutamisest?
  • Kui on hinnatud koos bug fixidega 1000h projektile, kui palju peaksid küsima testide jaoks.
  • Projekt on ületamas tähtaega. Management pakub lisaressurssi juurde. Sina projektijuhina pead otsuse tegema. Too 3 erinevat otsust välja ja kirjuta, mis neis on head või halba.

  • Vasakule Paremale
    Tarkvaratehnika #1 Tarkvaratehnika #2 Tarkvaratehnika #3 Tarkvaratehnika #4 Tarkvaratehnika #5 Tarkvaratehnika #6 Tarkvaratehnika #7 Tarkvaratehnika #8 Tarkvaratehnika #9 Tarkvaratehnika #10 Tarkvaratehnika #11 Tarkvaratehnika #12 Tarkvaratehnika #13 Tarkvaratehnika #14 Tarkvaratehnika #15 Tarkvaratehnika #16 Tarkvaratehnika #17 Tarkvaratehnika #18 Tarkvaratehnika #19 Tarkvaratehnika #20 Tarkvaratehnika #21 Tarkvaratehnika #22 Tarkvaratehnika #23 Tarkvaratehnika #24 Tarkvaratehnika #25 Tarkvaratehnika #26 Tarkvaratehnika #27 Tarkvaratehnika #28 Tarkvaratehnika #29 Tarkvaratehnika #30 Tarkvaratehnika #31 Tarkvaratehnika #32 Tarkvaratehnika #33 Tarkvaratehnika #34 Tarkvaratehnika #35 Tarkvaratehnika #36 Tarkvaratehnika #37 Tarkvaratehnika #38 Tarkvaratehnika #39 Tarkvaratehnika #40 Tarkvaratehnika #41 Tarkvaratehnika #42 Tarkvaratehnika #43 Tarkvaratehnika #44 Tarkvaratehnika #45 Tarkvaratehnika #46 Tarkvaratehnika #47 Tarkvaratehnika #48 Tarkvaratehnika #49 Tarkvaratehnika #50 Tarkvaratehnika #51 Tarkvaratehnika #52 Tarkvaratehnika #53 Tarkvaratehnika #54 Tarkvaratehnika #55 Tarkvaratehnika #56 Tarkvaratehnika #57 Tarkvaratehnika #58 Tarkvaratehnika #59 Tarkvaratehnika #60 Tarkvaratehnika #61 Tarkvaratehnika #62 Tarkvaratehnika #63 Tarkvaratehnika #64 Tarkvaratehnika #65 Tarkvaratehnika #66 Tarkvaratehnika #67 Tarkvaratehnika #68 Tarkvaratehnika #69 Tarkvaratehnika #70 Tarkvaratehnika #71 Tarkvaratehnika #72
    Punktid Tasuta Faili alla laadimine on tasuta
    Leheküljed ~ 72 lehte Lehekülgede arv dokumendis
    Aeg2015-09-21 Kuupäev, millal dokument üles laeti
    Allalaadimisi 36 laadimist Kokku alla laetud
    Kommentaarid 0 arvamust Teiste kasutajate poolt lisatud kommentaarid
    Autor MaksimA Õppematerjali autor

    Sarnased õppematerjalid

    Tarkvaratehnika 3 variant
    12
    pdf

    Tarkvaratehnika 3 variant

    programming(all production code is pair programmed), continuous learning(take time to improve team's skills), retrospective(look back and improve) 3 вещи в рукводстве проекта(?)3 фактора при разработке квалитетного ПО Too välja 3 kvaliteetse tarkvarasüsteemi atribuuti (üks kliendi, üks arendaja, üks äri vaatest) ning selgita, kuidas nad mõjutavad arhitektuurilise kavandamise valikut. Hooldatavus: Tarkvara peab arenema, et vastata muutuvatele vajadustele; Usaldusväärsus: Tarkvara peab olema töökindel; Efektiivsus: Tarkvara ei tohi raisata süsteemi ressursse; Vastuvõetavus: Tarkvara peab olema aktsepteeritud kasutajate poolt, kelle jaoks ta on loodud. See tähendab, et tarkvara peab olema arusaadav, kasutatav ja ühilduv teiste süsteemidega

    Tarkvaratehnika
    Tarkvara kokkuvõte inglise keeles
    36
    doc

    Tarkvara kokkuvõte inglise keeles

    analoogsete projektidega. Protsessid on praktikas läbiproovitud, dokumenteeritud, kohustuslikud, on läbi viidud opposed ja treeningud. On loodud tingimused protsesside edasiseks täiustamiseks. Paneme tähele, et tunduvalt on vähenenud sõltuvus üksikisikust, mis tõsisemate ettevõtmiste korral (nt. finantsinstitutsioonid) on turvalisuse seisukohalt äärmiselt oluline. 3. tase – Defined – määratletud. Sellel tasemel on kehtestatud ja dokumenteeritud organisatsiooni standardprotsess tarkvara arendamiseks. Organisatsiooni standardprotsess sisaldab nii tarvaratehnika-kui ka juhtimisprotsesse, mis on terviklikult integreeritud. Organisatsiooni standardprotsessi haldamiseks on moodustatud tarkvaratehnika protsesside grupp; on evitatud kogu organisatsiooni hõlmav õppe- ja treeningprogramm, et tagada kõigi töötajate ja juhtide vastavad teadmised ja oskused. Organisatsiooni standardprotsessi kohandatakse vastavalt

    Tehnoloogia
    Tarkvaratehnika kordamisküsimused
    210
    pdf

    Tarkvaratehnika kordamisküsimused

    TARKVARATEHNIKA KORDAMISKÜSIMUSED     1. Mis on tarkvaratehnika?  Software engineering    ! ​“Engineers Australia” definitsioon: ​ Tarkvaratehnika ​on tiimide poolt rakendatav distsipliin  tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara mis rahuldab  kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel.    IEEE definitsioon: Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava  lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see  tähendab, inseneriteaduste rakendamine tarkvarale.     Tarkvaraarendus ​ on nõrgem termin, kus tingimata ei kasutata protsesse, tööriistu,  standardeid, jne. Tarkvaraarendus on progemine + konfigursatsiooni haldus.    Tarkvaratehnika ei ole ainult programmi kirjutamine, vaid teemad hõlmavad ka kvaliteeti,  ajakavasid,

    Tarkvaratehnika
    Tarkvaratehnika konspekt eksamiks
    62
    pdf

    Tarkvaratehnika konspekt eksamiks

    Tarkvaratehnika konspekt. Tarkvaratehnika Tarkvaratehnika e. tarkvara inseneeria on professionaalsele tarkvaraarendusele suunatud distsipliin, mis tegeleb sellega, kuidas organiseerida tarkvaraarendust, arvestades organisatsiooniliste ja rahaliste piirangutega. Tarkvaratooted koosnevad valjatöötatud programmidest ja nende dokumentatsioonist. Tarkvaratehnika eesmärgiks on kuluefektiivne tarkvaraarendus kogu tarkvara elukaare ulatuses. Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale. Tarkvaratehnika „point“: Tarkvaratehnika on suunatud professionaalsele tarkvaraarendusele. Tarkvaratehnika ei tegele tarkvaraarenduse endaga vaid sellega, kuidas organiseerida tarkvaraarendust. Tarkvaratehnika vajadus - kõrgenenud nõudmised: suuremad süsteemid, keerulisemad süsteemid, kiiremini arendatavad süsteemid. Insener suuda

    Tarkvaratehnika
    IT arhitektuur
    44
    doc

    IT arhitektuur

    1.The Conceptual Architecture identifies the high-level components of the system, and the relationships among them. Its purpose is to direct attention at an appropriate decomposition other system without delving into details. Moreover, it provides a useful vehicle for communicating the architecture to non-technical audiences, such as management, marketing, and users. Logical Architecture In Logical Architecture, the externally visible properties of the components are made precise and unambiguous through well-defined interfaces and component specifications, and key architectural mechanisms are detailed. The Logical Architecture provides a detailed "blueprint" from which component developers and component users can work in relative independence. Logical Architecture. Model System Behavior Execution Architecture An Execution Architecture is created for distributed or concurrent systems. The process view shows the mapping of components onto the processes of the physical system, with atte

    It arhitektuur
    Introduction of SCM
    40
    doc

    Introduction of SCM

    INTRODUCTION OF SUPPLY CHAIN MANAGEMENT (SCM) A supply chain is a network of facilities and distribution options that performs the functions of procurement of materials, transformation of these materials into intermediate and finished products, and the distribution of these finished products to customers. Supply chains exist in both service and manufacturing organizations, although the complexity of the chain may vary greatly from industry to industry and firm to firm. Supply chain management is typically viewed to lie between fully vertically integrated firms, where the entire material flow is owned by a single firm and those where each channel member operates independently. Therefore coordination between the various players in the chain is key in its effective management. Cooper and Ellram [1993] compare supply chain management to a well-balanced and well-practiced relay team. Such a team is more competitive when each player knows how to

    Kategoriseerimata
    IT Strateegia IT Ettevõttele
    24
    pdf

    IT Strateegia IT Ettevõttele

    Table of Contents 1. Background ..............................................................................................................................2 2. Business Plan............................................................................................................................2 2.1. Mission..............................................................................................................................2 2.2. Values ...............................................................................................................................2 2.3. SWOT Analysis of the Organization ................................................................................2 2.4. Opportunities ....................................................................................................................3 2.5. Primary Processes ........................................................................................

    Informaatika
    Thesis Kivimaa August 2022
    140
    pdf

    Thesis Kivimaa August 2022

    Thesis “How is it possible to calculate IT security effectiveness?” Kristjan Kivimaa August 2022 1 Abstract In IT Security world, there is lack of available, reliable systems for measuring security levels/posture. They lack the range of quantitative measurements and easy and fast deployment, and potentially affects companies of all sizes. Readily available security standards provide qualitative security levels, but not quantitative results – that would be easily comparable. This deficiency makes it hard for companies to evaluate their security posture accurately. Absence of security metrics makes it complicated for customers to select the appropriate measures for particular security level needed. The research question for this research project is – “How is it possible to calculate IT security effectiveness?”. The aim of this research is to use this reference m

    Infotehnoloogia




    Meedia

    Kommentaarid (0)

    Kommentaarid sellele materjalile puuduvad. Ole esimene ja kommenteeri



    Sellel veebilehel kasutatakse küpsiseid. Kasutamist jätkates nõustute küpsiste ja veebilehe üldtingimustega Nõustun