1.2 tarjoaa useita esimerkkejä (sekä positiivisia että negatiivisia), jotka osoittavat ohjelmistojen vaikutuksen yhteiskuntaamme.
ohjelmistojen käytöllä yhteiskunnassamme on useita sekä myönteisiä että kielteisiä vaikutuksia. Siinä missä myönteiset näkökohdat voivat olla erittäin hyödyllisiä, kielteiset seikat antavat meille jonkinlaisen kainalosauvan. Yleensä ohjelmistoa ei ole suunniteltu ”satuttamaan” meitä millään tavalla, vaan pikemminkin tekemään asioista helpompia ja tehokkaampia meille.
1.3 esimerkiksi E-pankki on täydellinen esimerkki ohjelmistosta, joka tekee elämästämme paljon helpompaa. Kaikki paitsi fyysisesti nostaa rahaa pankista voidaan tehdä verkossa. Voit jopa tallettaa palkkasekkisi nyt yksinkertaisesti ottamalla siitä kuvan älypuhelimellasi. Haittapuolena on, että samaa teknologiaa voidaan käyttää varastaa luottokortin numerot ja henkilöllisyys, jos se joutuu vääriin käsiin. Sama anti-security ohjelmisto.
on ihmisiä, joille maksetaan hyvin, että he murtautuvat paikalliseen pankkiin ja varastavat heiltä vain todistaakseen pankille, että heidän on päivitettävä verkkoturvansa. Pankit ovat useimmiten kiitollisia tällaisista tunkeutumisista. Tätä samaa ohjelmistoa voitaisiin kuitenkin käyttää rikollisiin tarkoituksiin, joihin pankki ei olisi niin mielissään. Ohjelmisto voi olla sekä erittäin hyödyllinen että erittäin vaarallinen riippuen siitä, kuka sitä käyttää ja miten.
1.4 monet nykyaikaiset sovellukset muuttuvat usein – ennen kuin ne esitellään loppukäyttäjälle ja sen jälkeen, kun ensimmäinen versio on otettu käyttöön. Ehdottaa muutamia tapoja rakentaa ohjelmistoja pysäyttää heikkeneminen muutoksen vuoksi.
ennen kaikkea ohjelmistosovellusten pitäisi olla ylläpidettävissä. Tarkoittaen, että se on suunniteltava niin, että muutoksia voidaan tehdä melko helposti sovelluksen kasvaessa. Yksi tapa minimoida muutoksesta johtuva huononeminen on mahdollistaa automaattisten päivitysten sisäänrakennettu. Otetaan esimerkiksi Windows-käyttöjärjestelmä: siinä on mahdollisuus sallia automaattinen päivitys tarvittaville turvallisuus-ja palomuurialustoille, jotta järjestelmä on aina ”ajan tasalla.”Koska aikaisempia sovelluksia päivitetään jatkuvasti, on tärkeää rakentaa uusia ohjelmistoja, joilla on samat ominaisuudet.
1.5 tarkastellaan kohdassa 1.1.2 esitettyjä seitsemää ohjelmistoluokkaa. Uskotko, että samaa lähestymistapaa ohjelmistotekniikkaan voidaan soveltaa jokaiseen? Selitä vastauksesi.
miljoonat ohjelmistoinsinöörit ympäri maailmaa tekevät kovasti töitä yhdessä tai useammassa näistä kategorioista. Joissakin tapauksissa rakennetaan uusia järjestelmiä, mutta monissa muissa korjataan, mukautetaan ja tehostetaan nykyisiä sovelluksia. Tämän vuoksi yksittäisille luokille saatetaan vaatia erilaista lähestymistapaa ohjelmistotekniikkaan. Monet ohjelmat, että ohjelmistoinsinöörit työskentelevät ovat erittäin vanhoja, ja edelleen päivitetään. Siksi on järkevää, että et käyttäisi samaa lähestymistapaa olemassa olevalle ohjelmalle, jota käyttäisit uudelle ohjelmalle.
1.6 Kuvassa 1.3 asetetaan kolme ohjelmistotekniikan kerrosta sellaisen kerroksen päälle, jonka nimi on ”a quality focus.”Tämä tarkoittaa organisaation laatuohjelmaa, kuten total quality management. Tee vähän tutkimusta ja kehittää pääpiirteittäin Keskeiset opinkappaleet yhteensä laadunhallintaohjelman.
TQM voidaan määritellä sellaisten aloitteiden ja menettelyjen hallinnoinniksi, joilla pyritään saavuttamaan laadukkaiden tuotteiden ja palvelujen toimittaminen. TQM: n määrittelyssä voidaan yksilöidä useita keskeisiä periaatteita, kuten:
- Executive Management-Ylin johto pitäisi toimia tärkein kuljettaja TQM ja luoda ympäristö, joka varmistaa sen menestys.
- koulutus-työntekijöiden tulisi saada säännöllistä koulutusta laadun menetelmistä ja käsitteistä.
- asiakaslähtöisyys-laadun parantamisen pitäisi parantaa asiakastyytyväisyyttä.
- päätöksenteko-laadukkaat päätökset tulee tehdä mittausten perusteella.
- menetelmät ja välineet – asianmukaisten menetelmien ja välineiden avulla varmistetaan, että vaatimustenvastaisuudet tunnistetaan, mitataan ja niihin reagoidaan johdonmukaisesti.
- jatkuva parantaminen-yritysten olisi jatkuvasti pyrittävä parantamaan valmistus-ja laatumenettelyjä.
- yrityskulttuuri-yrityskulttuurin tulisi pyrkiä kehittämään työntekijöiden kykyä työskennellä yhdessä laadun parantamiseksi.
- työntekijöiden osallistuminen-työntekijöitä olisi kannustettava ennakoivaan laatuun liittyvien ongelmien tunnistamiseen ja ratkaisemiseen.
1.7 onko ohjelmistotekniikka sovellettavissa, kun WebApps rakennetaan? Jos näin on, miten se voidaan muuttaa mukautumaan ainutlaatuisia ominaisuuksia WebApps?
ohjelmisto on juurtunut syvälle lähes jokaiseen elämämme osa-alueeseen. Ohjelmistotekniikka on sovellettavissa, kun uusia ohjelmia rakennetaan, ja kun olemassa olevia ohjelmia päivitetään – mukaan lukien WebApps. WebApps ovat yksi useista erillisistä ohjelmistoluokista. Ja vielä, voidaan väittää, että WebApps ovat erilaisia. Yksi tärkeimmistä muutoksista, että WebApps kysyntä on saatavuus. Käyttäjät suosittu WebApps usein vaatia pääsyä 24/7/365 perusteella. Toinen ainutlaatuinen ominaisuus WebApps on niiden jatkuva kehitys.
toisin kuin perinteiset sovellusohjelmistot, jotka kehittyvät useiden suunniteltujen, aikajärjestyksessä tapahtuvien julkaisujen aikana, verkkosovellukset kehittyvät jatkuvasti. Kun se tulee ohjelmistotekniikan sovelletaan WebApps, monet äänet on kuultava. Ulkoasua WebApp on kiistaton osa valituksen, joka lopulta määrittää sovellusten menestys.
1.8 ohjelmistojen yleistyessä yleisölle (viallisten ohjelmien takia) aiheutuvat riskit tulevat yhä merkittävämmäksi huolenaiheeksi. Kehitä tuomiopäivän mutta realistinen skenaario, jossa tietokoneohjelman epäonnistuminen voisi aiheuttaa suurta vahinkoa (joko taloudelliselle tai inhimilliselle).
yksi ensimmäisistä traagisista mutta realistisista skenaarioista, joka tulee mieleen, on tiettyjen ohjelmien epäonnistuminen lentokoneessa. Lentokoneiden suurimmilla tietokoneohjelmilla on sama riski epäonnistua kuin muillakin ohjelmilla, ja niillä voi olla katastrofaalisia seurauksia. Esimerkiksi lentokoneen korkeuden havaitsevan sensorin avulla lentäjä voi tietää, kuinka monta jalkaa kone on maanpinnan yläpuolella. Ohjelma on tarpeen erityisesti silloin, kun sääolosuhteet voivat heikentää lentäjien näkyvyyttä kiitotielle.
kun lentokone aloittaa kunnon ja valmistautuu laskeutumaan, lentäjä ohjaa näiden ohjelmien avulla koneen turvalliseen laskeutumiseen. Jos tämä ohjelma epäonnistuisi ja sää haittaisi lentäjien näkyvyyttä, lentäjä ei välttämättä tiedä, kuinka kaukana maanpinnan yläpuolella hän todellisuudessa on. Lento-onnettomuuksia tapahtuu koko ajan, ja satoja matkustajia kuolee joka vuosi – enimmäkseen koneen epäonnistuneiden ohjelmien ja mittareiden vuoksi.
1.9 kuvaile prosessikehys omin sanoin. Kun sanomme, että puitetoimia voidaan soveltaa kaikkiin hankkeisiin, tarkoittaako tämä sitä, että kaikkiin hankkeisiin sovelletaan samoja työtehtäviä koosta ja monimutkaisuudesta riippumatta? Selittää.
ohjelmistosuunnitteluprosessi ei tapahdu vain taianomaisesti ilman jonkinlaista järjestystä ja organisaatiosuunnittelua. Prosessikehys luo pohjan suunnitteluprosessille käyttämällä pientä määrää toimintoja, jotka soveltuvat kaikkiin projekteihin. Prosessikehyksen vaiheittainen algoritmi koostuu viidestä toiminnosta: viestintä, suunnittelu, mallinnus, Rakentaminen, ja käyttöönotto. Kaikki ohjelmat niiden koosta ja monimutkaisuudesta riippumatta noudattavat näitä toimintoja tässä järjestyksessä. Vaikka ohjelmistoprosessin yksityiskohdat ovat kunkin ohjelman osalta varsin erilaiset, kehyksessä mukana olevat tehtävät pysyvät samoina.
1.10 Sateenvarjotoimintaa esiintyy koko ohjelmistoprosessin ajan. Sovelletaanko niitä mielestänne tasaisesti koko prosessiin vai keskittyvätkö ne yhteen tai useampaan toimintakehykseen?
yleensä kattotoimintaa sovelletaan koko ohjelmistoprojektin ajan ja se auttaa ohjelmistotiimiä hallitsemaan ja hallitsemaan edistymistä, laatua, muutosta ja riskejä. Koska ohjelmistosuunnitteluprosessi ei ole jäykkä kuuri, jota ohjelmistotiimin on noudatettava tarkasti, prosessissa on paljon sopeutumisvaraa.
vaikka koko prosessin kattavaa toimintaa sovelletaan yleisesti kaikkiin prosessin osa-alueisiin, suunnittelun tulee olla ketterää ja mukautuvaa; se on ominaista ongelmalle, projektille, tiimille ja organisaatiokulttuurille. Tämän vuoksi yhtä hanketta varten hyväksytty prosessi voi erota huomattavasti toista hanketta varten hyväksytystä prosessista, ja jotkin toiminnot voivat keskittää toimintansa yhdelle tai useammalle alueelle.