|
------------------------------------
Date: 06.05.2004 perjantai klo 12.15 - 16.00
Kevään ohtu-projektien demotilaisuuden ajat
löytyvät nyt osoitteesta
http://www.cs.helsinki.fi/group/ohtu/k-2004/demopaiva.html
Olen tehnyt sijoittelun sellaiseksi, että
rinnakkaisryhmät ovat peräkkäin. Vain silloin,
jos jokin ryhmä ei _missään nimessä_ voi pitää
esitystään varattuna aikana, harkitsen aikataulun
muuttamista. Käytännössä tämä ehto toteutuu vain silloin,
jos yksikään ryhmän jäsenistä ei pääse kyseiseen
aikaan pitämään demoa.
Juha Taina taina@cs.helsinki.fi
--
Jokaiselle ryhmälle on varattu 20 minuuttia esiintymisaikaa,
josta noin viisi minuuttia on varattu yleisön kysymyksille.
Utelaiaille tiedoksi: Keväällä 2004 on kokeiltu
rinnakkaisryhmiä, missä kahdelle ryhmälle on annettu sama
aihe. Tämän vuoksi ohjelmassa kolmella aiheella on kaksi
tekijäryhmää.
12:15 Avaus
12:20 njc2 NJC-lehden toimituksen julkaisuväline
njc1 NJC-lehden toimituksen julkaisuväline
koski Koksi-konekielisimulaattori
13:20 malan Koksi-konekielisimulaattori
kotkat Merikotkatietokannan web-käyttöliittymä
hali2 Merikotkatietokannan web-käyttöliittymä
14:20 assari Trainer-ohjelmiston tehtävätyypit ja analyysi
dht DHT-toteutus GNUnet p2p-ympäristöön
ohtur6 Ohjelmistojen esimerkkituoteperheen toteutus
15:20 Tilaisuus päättyy
------------------------------------
Date: 23.04.2004 perjantai klo 14.00 - 16.00
Kutsu Malan coren katselmointiin
--------------------------------
Katselmointi tapahtuu koululla huomenna perjantaina
klo 1415 ja 1600 välillä ja kestää noin tunnin.
Katselmointi keskittyy malan.core
-pakkauksen alla oleviin luokkiin ja niiden
yhteistoimintaan.
Työnjako
--------
Kalle: Processor, CU
Alberto: ALU, CoreComponent, CoreContext
Sami: MMU, Memory, MemoryItem
Menettelytapa
--------------
Kaikki ottavat CVS:stä itselleen koko coren lähdekoodin ja
syventyvät oman osa-alueensa toimintaan. Lähdekoodi on hyvä lukea myös oman
osa-alueen ulkopuolelta, jotta saa käsityksen koko osajärjestelmästä.
Huomioitavat asiat ovat jokseenkin samat kuin compilerin katselmoinnissa,
eli koodin siisteys, bugit (erilaisilla syötteillä), yleiset
rakenneratkaisut, suunnittelumallit, ratkaisevasti paremmat
lähestymistavat ja pyörän uudelleenkeksimiset.
Katselmointi etenee samaan tyyliin kuin compilerin tarkastuksessa,
eli esittelen coren toimintaa lähtien todennäköisesti CoreComponent
ja CoreContext-luokista edeten Processor-luokan kautta CU:n, MMU:n,
ALU:un ja Memoryyn. Kun olen käynyt luokan läpi,
pitäisi siitä vastaavan henkilön esittää sitä koskevat muistiinpanonsa.
Koska core sisältää useita eri luokkia, joiden välillä kontrolli
liikkuu käskyn suorituksen aikana, katselmoinnissa sallittakoon
viittaaminen myös käsiteltävänä olevaan
luokkaan liittyviin muihin luokkiin.
Muuta
-----
Tuo mukanasi printattu versio lähdekoodista.
------------------------------------
Date: 8.04.2004 torstai klo 18.00 - 19.00
Katselmointi malan.compiler paketille järjestetään koululla
torstaina kello 18:00. Katselmointi keskittyy
malan.compiler.MalanCompiler luokkaan, ja tarkentuu metodeihin firstPass
ja secondPass.
Lähestymistapaa on muutettu tänään, ja kaikkien tulee lukea
erityisesti tämä firstPass. Lähestymistavan muuttaminen johtui tarpeesta
saada kontrollia syötteen tutkimiseen.
Kääntäjä on tällähetkellä tuollainen 650 riviä pitkä. Siitä tärkeää
tavaraa on 478 riviä. Tähän on siis laskettu vain MalanCompiler luokan
sisältö. Ja tähän on myös laskettu laaja kommentointi, joka
toivottavasti auttaa teitä katselmoimaan työtäni.
Työnjako
--------
Alberto: firstPass
Jukka: secondPass
Sami: firstPass
Käytäntö
--------
Kaikki teistä syventyy koodiin ja tutkii itselleen annetun osa-alueen
erityisen tarkkaan. Muita osa-alueita tulee tarkastaa myös, mutta niihin
ei tarvitse kiinnittää sen suurempaa huomiota.
Huomioitavia asioita ovat koodin siisteys, bugit (erilaisilla
syötteillä..), yleiset rakenneratkaisut, suunnittelumallit,
ratkaisevasti paremmat lähestymistavat, pyörän uudelleenkeksimiset..
Katselmointi etenee tahdissa jolla esittelen koodia, ja sen
toimintaa. Koetan tuoda koodista esiin tärkeät kohdat, ja suuret
rakenteet, jotta ohjelmaa olisi helpompi ymmärtää. Kun olen esitellyt
jonkun osa-alueen katselmoijat esittävät kysymyksiä ja kommentteja,
perustuen niihin havaintoihin mitä ovat tehneet ennen tilaisuutta ja
tilaisuuden aikana.
------------------------------------
Works for next reunion 12.3.2004.
Invitation to Formal inspection of the Malan
Design document
Date:
12.03.2004 Friday, 14:30-16:00, Room C477
People:
Malan group: Kalle Kärkkäinen, Sami Sierla,
Alberto Marquinez (absent), Jukka Forsgren,
Jianling Zhang
Group instructor:
Antti Tevanlinna
Inspection target:
Malan design document
Roles:
Moderator:
Antti Tevanlinna (Acts as a chairman)
Organizer:
Jianling Zhang
Reader:
Jianling Zhang (Gives overview of the document)
Inspector of section 2 (UML overview diagram),
3.1 (malan.ui), 3.2 (malan.web) and
3.3 (malan.localization): Jukka Forsgren
Inspector of section 3.4 (malan.event),
3.5 (malan.input) and
3.8 (malan.core): Kalle Kärkkäinen
Inspector of section 3.6 (fi.hu.cs.ttk91),
3.7 (malan.interface) and
3.9 (malan.compiler): Sami Sierla
Inspector of section 1 (abstract),
4 (testing) and 5 (references): Jianling Zhang
Secretary:
Jianling Zhang (writes down the corrections)
Schedule:
14:30-14:35 Moderator starts the inspection
14:35-14:40 Organizer gives an overview of the document
14:40-14:55 Jukka Forsgren
14:45-15:10 Kalle Kärkkäinen
15:10-15:25 Sami Sierla
15:25-15:40 Jianling Zhang
15:40-15:50 Secretary reads the findings of inspection
15:50-15:55 Group decides how to proceed
15:55-16:00 Moderator ends the inspection
Goal and guidelines:
1. Goal of inspection is to find and report
omissions and mistakes in the design document,
so that found errors can be fixed to improve
the product quality.
2. Document is gone through every section (Main section
is section 3).
3. Try to locate incomplete or missing functionality
4. Try to locate wrong or unwanted functionality
5. Meet the schedule
6. Do NOT stop to argue about the problems that are
found (because it wastes time)
7. Do NOT try to find new solutions (it should be done
formally outside the inspection)
8. Do NOT stop to read the document (you should
have read it already)
9. Inspectors should be well prepared (see the
instructions below)
10. Report also minor faults so that they get recorded
11. Do NOT add invaluable and irrelevant information
to the reported errors
Inspectors:
1. Read the design document carefully (~30 minutes)
2. Read the checklist (~10 minutes)
3. Use the checklist during second reading of your
own section (~30 minutes)
3. Inspectors should prepare to go through their own
section with the following algorithm presented by Antti:
for every section do
inspector gives an overview of the section and its general
quality (2 minutes)
moderator asks for reported error count from inspectors
#remaining time is divided to faults
for every inspector fault do
report fault
end for
for secretary fault do
write down fault
end for
end for
------------------------------------
Works for next reunion 9.3.2004.
Agenda:
14:15 Event Manager (Kalle, jukka (core part), sami (ui part))
14:30 Input Manager (jukka(core), sami (ui))
14:45 UI (Sami)
15:00 implementation timetable (kalle & everyone)
15:30 I take my leave
------------------------------------
Works for next reunion 2.3.2004.
Document was decided to review requeriment distributed
new works for the next meeting:
Kalle assumed to clarify localitation.
To Jukka input was delegated to him to manager definition.
To Sami element was delegated to him event and
the interface of the Web.
It was decided to divide the meetings in two days:
Tuesday 14.00 - 16.00 and
Fridays 14,00 16.00
------------------------------------
Kalle decided to prepare for the meeting of day 12.3.2004.
- Review requeriments design (Alberto organizes the event).
- to review the time table.
- repasart SWOT.
------------------------------------
Date: 24.02.2004 tiistai klo 14.00 - 16.00
Meetings agenda:
14:15 - 14:30
Jianling explains test case specification template
14:30 - 14:45
Alberto explains the design document
14:45 - 15:00
Jukka explains the malan core
15:00 - 15:15
Sami explains the user interface draft
15:15 - 15:30
Alberto explains the compiler design
15:30 - 16:00
Designs and documents are commented briefly
Decisions about designs are made.
* Is this design good enough
* meets the requirements
* is simple (does not put the timetable at risk)
* shows 'good design'
* use of design patterns
* KISS
* next steps about the design
* improvement suggestions
------------------------------------
Date: 21.2.2004
- Suunniteludokumentin luonnos on jo sivuillamme.
- Pitää ilmoittaa Kallelle tiistain kokouksesta.
------------------------------------
Date: 20.02.2004 tiistai klo 14.00 - 16.00
Kokous
Esityslista:
- Puheenjohtaja: Jukka Forsgren.
- Jokainen esittää vuorollaan alkuviikon sovitut
- osioiden rajapintojen dokumentit,
- UML-luokkakaaviot ja dokumentit tarkastettavaksi,
Ensi viikolle:
- Sopia ensi viikolle metodien kuvaukset,
Suunnittelu- ja toteutusdokumentit.
------------------------------------
Date: 17.02.2004 tiistai klo 14.00 - 16.00
Poikkeuksellinen kokous
Esityslista:
Puheenjohtaja: Jukka Forsgren.
Esitellään jokaisella omasta alueesta. Silloin pitää sopia sisäiset
rajapinnat luokkien välissä. Pitää olla valmiina
UML-luokkakaavio ja dokumentti.
Käydään läpi sekventiaali UML-kaavio, ja pitää olla selvillä
luokkien väliset suhteet sekä miten data liikkuu.
------------------------------------
Invitation to Formal inspection of the
Malan Requirements Analysis document
------------------------------------
Date:
12.2.2004 Thursday, 1430-1600, Room C477
People:
Customer: Teemu Kerola
Malan group: Kalle Kärkkäinen, Sami Sierla, Alberto Marquinez,
Jukka Forsgren, Jianling Zhang
Group instructor: Antti Tevanlinna
Other: Juha Taina
Inspection target:
Malan Requirements Analysis document
Roles:
Moderator: Antti Tevanlinna (sees that the schedule and timetable of the
meeting is met, acts as a chairman)
Author:
Jukka Forsgren (Owner of the document)
Reader:
Jukka Forsgren (Gives overview of the document)
Inspector of section 2 (Requirements): Alberto Marquinez
Inspector of section 3 (Functions): Kalle Kärkkäinen
Inspector of section 4 (UI): Sami Sierla
Inspector of section 5 (Ext Interfaces): Jianling Zhang
Secretary: Jukka Forsgren (writes down the corrections)
Schedule:
1430-1435: Moderator starts the inspection
1435-1440: Author gives an overview of the document
1440-1455: Alberto Marquinez
1445-1510: Kalle Kärkkäinen
1510-1525: Sami Sierla
1525-1540: Jianling Zhang
1540-1550: Secretary reads the findings of inspection
1550-1555: Group decides how to proceed
1555-1600: Moderator ends the inspection
Goal and guidelines:
1. Goal of inspection is to find and report omissions and mistakes
in the Requirements document, so that found errors can be repaired
afterwards, increasing product quality.
2. Document is gone through systematically (from start to end, section by
section)
3. Try to locate incomplete requirements or missing functionality
4. Try to locate wrong requirements or unwanted functionality
5. Meet the schedule
6. Do NOT stop to argue about the problems that are found (because it wastes
time)
7. Do NOT try to find new solutions (it should be done formally outside the
inspection)
8. Do NOT stop to read the document (you should have read it already)
9. Inspectors should be well prepared (see the instructions below)
10. Report also minor faults so that they get recorded
11. Do NOT add invaluable and irrelevant information to the reported errors
Inspectors:
1. Read the Requirements document carefully (~15 minutes)
2. Read the checklist (~10 minutes)
3. Use the checklist during second reading of your own section (~30 minutes)
3. Inspectors should prepare to go through their own section with the
following algorithm presented by Antti:
for every section do
inspector gives an overview of the section and its general quality
(2 minutes)
moderator asks for reported error count from both inspector and
the client
#remaining time is divided to faults
for every inpector fault do
report fault
end for
for every client fault do
report fault
end for
end for
####################################################################
Checklist for the Inspection of
Malan Requirements Analysis document
------------------------------------
General:
-------
1. Write an overview of the section delegated to you
2. Count total number of errors found in your section
(based on the next checklist)
3. Prepare to present both of them in the inspection tomorrow
Checklist:
---------
You can replace the "requirement" in the following checklist with
"function", "UI element" or "External interface". Some questions may not be
entirely relevant for every section and inspector.
1. Is each requirement stated clearly, concisely, and unambiguously?
(write down items that do not meet this criteria)
2. Are there ambiguous or implied requirements?
(write down items that do not meet this criteria)
3. Are there conflicting requirements?
(write down items that do not meet this criteria)
4. Are there requirements that contain an unnecessary design details?
(write down items that do not meet this criteria)
5. Do requirements exhibit a clear distinction between functions, data and
user interface?
(write down items that do not meet this criteria)
6. Do requirements define all the information to be displayed to users?
(write down items that do not meet this criteria)
7. Do requirements address system and user response to error conditions?
(write down items that do not meet this criteria)
####################################################################
|