ENGENHARIA SOFTWARE

1.      Temi tok faktorizasaun-faktorizasaun mosu iha tempo kotuk engenharia software:

a.       La konsege organizasaun atu prediksaun tempo esforso no folin ba mudansa software.

b.      Kualidade software nebe produsaun la diak ou diak.

c.       Halo mudansa tetu folin software no hardware

d.      Aumenta uluk importante hosi software

e.       Mundansa teknologi software

f.       Mudansa teknologi hardware

g.      Nescesidade nebe aumenta hasoru hardware

h.      Nescessidade sei hardware nebe boot liu no kompleks

2.      Hasoru buat sira nebe hetan sai sasan tetu iha hili lingua pemrogram. Type ou lalaok hosi problema bisnis, tekniko ou nebe seluk tan?

a.       Difisil hosi problema nebe hasoru

b.      Hatene lingua pemrogram nebe hosi programmer

c.       Type ou lalaok halo data ou dadus, ou modelu batch processing ou online processing

d.      Hakarak lingua pemrogram nebe ita nian

e.       Hakarak program-program pustaka (libtary) nebe iha no hetan mudansa hosi lingua nebe sei hili

f.       Hatene hosi lingua pemrograam nebe mak sei uza

g.      Modelu hosi lingua pemrogram, compiler ou interpreter

h.      Halo lingua pemrogram karik iha mudansa-mudansa foun

i.        Halo mudansa hosi lingua pemrogram iha modifikasaun program sei akontese mudansa

j.        Konfigurasaun ssoftwaare no system software nebe uza ona.

3.      Jelaskan apa yang dimaksud dengan

a.      Programming in the large

In  software  development,  programming  in  the large can involve programming by larger  groups  of  people  or  by  smaller  groups  over  longer  time periods.  Either of these conditions  will  result  in  large, and hence complicated, programs that can be challenging for maintainers to understand.

With programming in the large, coding managers place emphasis on partitioning work into  modules with precisely-specified interactions. This requires careful planning and careful documentation.

With  programming  in the large, program changes can become difficult.^[2] If a change operates  across module boundaries, the work of many people may need re-doing. Because of this,  one  goal  of  programming  in  the  large involves setting up modules that will not need altering in the event of probable changes. This is achieved by designing modules so they have high cohesion and loose coupling.

Programming  in  the  large  requires  abstraction - creating  skills.   Until   a   module becomes   implemented  it  remains  an  abstraction.  Taken  together,  the abstractions should create  an  architecture  unlikely  to  need  change.  They  should  define interactions that have precision and demonstrable correctness.

b.      Programming in the small

In software development, programming in the small describes the activity of writing a  small  program.  Small  programs  are  typified by being small in terms of their source code size,  are  easy  to  specify, quick to code and typically perform one task or a few very closely related  tasks  very well.

Programming  in  the  small  can involve programming by individuals or small groups over  short  time periods and may involve less formal practices (for instance less emphasis on documentation  or  testing),  tools  and programming languages (e.g. the selection of a loosely typed scripting language in preference to a strictly typed programming language).

Programming  in  the  small  can  also  describe  an  approach  to  making  a prototype software  or  where  rapid   application   development   is   more    important   than stability or correctness.

In   computer   science    terms,   programming   in the small   deals  with short-lived programmatic behavior, often executed as a single ACID transaction and which allows access to local logic and resources such as files, databases, etc.