2- amaliy ishda keltirilgan komponentlar diagrammalaridan foydalangan holda ob'ektli yondashuv bilan dastur ishlab chiqing

O‘ZBEKISTON RESPUBLIKASI AXBOROT TEXNOLOGIYALARI VA KOMMUNIKATSIYALARINI RIVOJLANTIRISH VAZIRLIGI

MUHAMMAD AL‑XORAZMIY NOMIDAGI TOSHKENT AXBOROT TEXNOLOGIYALARI UNIVERSITETI

Axborot texnologiyalarining dasturiy ta’minoti kafedrasi

Dasturiy ta’minot qurilmasi va evolyutsiyasi fanidan

3-Amaliy ish.
Bajardi: 310-18 guruh talabasi Mamatov Rashid

Tekshirdi: Sharipov Bahodir Oqilovich

Toshkent – 2021

3- AMALIY ISH

Ishning maqsadi: 2- amaliy ishda keltirilgan komponentlar diagrammalaridan foydalangan holda ob'ektli yondashuv bilan dastur ishlab chiqing.
Dastlabki ma'lumotlar (vazifa):

1. 2- amaliy ishda keltirilgan komponentlar diagrammasidan foydalanish asosida dastur ishlab chiqishning nazariy materiali bilan tanishish.

2. Qo'llanmada taklif qilingan komponentlar diagrammalarining misollarini ko'rib chiqing.

3. Loyihalashtirilgan ob'ekt komponentlari uchun dastur tuzing.

4. Ish yuzasidan hisobot tayyorlash.

1. 
   Protectsystemfromsomeonelogsintothesystemwithfakeidentity.
   

2. 
   Protect attacks likeDDOS.
   

3. 
   Find out if someone’s identity wasstolen.
   

These are kind of true but do not capture the essence.

What do we want to protect using the software security? Using software security we protect against,

1. 
   DataLoss
   

2. 
   Disruption ofService
   

3. 
   DataLeak
   

4. 
   DataInconsistency
   

Data Loss

This basically means that sensitive data is lost due to security breach. In other words due to a vulnerability in the system someone cracked the system and made an important data disappeared.
A common example is attacker gains access to the main Database and deletes records.
Disruption of Service

This is when the system activity is disrupted due to attackers actions. In this case it may be nothing to do with system data but system go down. The bottom line is the attacker wants the system to stop working. The common example for this is executing a denial of serviceattack which overloads the system makes it go down. In other means group of attackers can orchestrate huge load of traffic to the system makes its infrastructure overloaded and in turn makes it go down.

Data Leak
This occurs when the sensitive data is stolen and made it available to unauthorized recipients such as credit card information, contact details. Imagine your own credit card details are in the hands of some hackers.
Data Inconsistency
This occurs when data is manipulated by unauthorized attackers and become inconsistent. Attackers can impersonate as someone else and perform unauthorized actions.
Software Security Terminology
There are few common terminologies we must be familiar with.

1. 
   Threat-Aneventifhappens,willleadtoasecurityincidentthatwe discussed earlier. e.g SQLinjection.
   

2. 
   Attack-Anactualexecutionofthreatbyanattacker(s).e.gexecution of SQL Injection, DDOSattack.
   
3. 
   Vulnerability-Aprobleminthesystemthatcanbeusedbyattacker toexecuteanattackandmakethesystemcompromised.e.gerrorin firewallconfigurationsthatexposesinternalservicetothepublic.
   
4. 
   Authentication -Establishing the identity of a user. Determiningwho you are whether a human or a machine but need to establish the identity before accessing the system. e.g Username and password, Face id,Fingerprint.
   
5. 
   Authorization-Establishingwhatagivenuserisallowedtodointhe system.e.gParticularusercancreatearecordbutcannotdelete.
   

There are many more terms in this domain, but above most basic few terminologies that we should know.

Who is responsible for the Security?
Is there a specific role that is the sole owner of the security aspect of the system? Lets look at a typical organizational chart.

1. 
   CIO (or CTO)-We have CIO who is responsible for all the IT aspect ofthecompany.Makessureeveryoneisawareofsecurity.IfCIOnot highlighting it, no one will invest time onit.
   
2. 
   CISO -A new role in modern era. The chief informationsecurity officer is responsible for setting the security strategy inthe
   

company’sIT.IfthereisnotCISO,othersshouldcollectivelyfillthe role.Basicallyheshoulddefinethestrategyandwhatshouldbedone overall.

3. 
   IT Services -They are typically responsible for the server starting frominstallingoperatingsystems,upgradingthem(Patchoperating systemsvulnerabilities),settingupthenetwork,setupfirewallsetc.
   
4. 
   Architect-Designsecurearchitecture.Architectureshouldbesecure in the firstplace.
   
5. 
   ProjectManager-Maynotbeatechnicalrole,butshouldmakesure these aspects are part of the work plan and actuallyimplemented.
   
6. 
   DevelopmentManager/EngineeringManager-He/Sheisresponsible for training the developers. As the most senior developer around should have rich experience developing secure systems and to provide guidance to the juniordevelopers.
   
7. 
   Developer -They must develop securecode.
   

8. 
   QA -They should conduct security relatedtesting.
   

2. SoftwareMeasurements

In most environments, measurement is an established, routine, customary part of daily practice. Many products are bought and sold based on what they weigh or what they measure. Measurement of software has not progressed to the point where there are established, routine, customary measures of software that are used in the daily

development, purchase or sale of software. The oft quoted LordKelvin said [4]:

“When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of science.”

What measurements are appropriate for information technology? If the field is narrowed, what measurements are appropriate for software?

Grady and Caswell [5] state that “A software metric defines a standard way of measuring some attribute of the software development process. For example, size, cost, defects, communications, difficulty, and environment are all attributes. Examples of attributes in the physical world are mass, length, time, and the like.” This definition limits metrics to the software development process but it does connect the concept of metric to specific attributes of the software product. Some attributes, like size and time, certainly are easier to measure and more easily correlate to the physical world of metrology than defects ordifficulty.

There are a large number of different types of metrics that are used for the software development process. Steve McConnell includes a table of “Useful Metrics” in his handbook on software construction that includes [6]:

Size:	total lines of code written, total comment lines, total data declarations, total blank lines.
Productivity:	work-hours spent on the project, work-hours spent on each routine, number of times each routine changed, dollars spent on project, dollars spent per line of code, dollars spent perdefect.
Defect Tracking:	severity of each defect, location of each defect, way in which each defect is corrected, person responsible for each defect, number of lines affected by each

	defect correction, work hours spent correcting each defect, average time required to find a defect, average time required to fix a defect, attempts made to correct each defect, number of new errorsresulting from defectcorrection.
Overall Quality:	total number of defects, number of defects in each routine, average defects per thousand lines of code, mean time between failures, compiler-detected errors
Maintainability:	number of parameters passed to each routine, number of local variables used by each routine, number of routines called by each routine, number of decision points in each routine, control-flow complexity in each routine, lines of code in each routine, lines of comments in each routine, number of data declarations in each routine, number of blank lines in each routine, number of gotos in each routine, number of input/output statements in each routine.

Peng and Wallace [7] summarize metrics related to software error analysis in the following categories:

Metrics for all phases:	problem metrics, cost and effort metrics, change metrics, fault metrics.
Requirements metrics:	primitive size metrics, requirements traceability, completeness, fault-days number and function points.
Design metrics:	size (primitive size metrics, number of modules), fault (primitive fault metrics), complexity (primitive

complexity metrics, coupling, cohesion, structural fan-in/fan-out, information flow metric), design inspection (staff hours per major defect detected, defect density), test related (test related primitives).

Implementation metrics:

size (lines of code, halstead software science metrics), control structure (number of entries/exits per module, cyclomatic complexity), data structure (amount of data, live variables, variable scope, variable spans), test (primitive defect/error/fault metrics, fault density, defect age, defect response time, defect cost, defect removal efficiency, primitive test case metrics, statement coverage, branch coverage, path coverage, data flow coverage, test coverage), failure (mean time to failure, failure rate, cumulative failure profile).

McConnell’s table and Peng and Wallace’s list certainly suggest that there are a large number of metrics which can be used for software measurement. However, computer scientists and software engineers cannot usually even agree on what is important to measure, how to measure, or why we are measuring. Since the scientific process usually requires asking a question first, why are we trying to measure software” If we don’t know the why then the what and how are meaningless.