Jozef Hooman
Afronding SO2
Systeemontwikkeling 2 (SO2) College 2
Voorwaarden: • Voldoende serieuze deelname aan GiPHouse • Aanwezigheid college, actieve deelname Eindcijfer wordt bepaald aan de hand van: • Eindverslag voor college met reflextie op GiP activiteiten gerelateerd aan literatuur (met name software ontwikkelings proces) • Mondelinge evaluatie
Jozef Hooman (A6006) http://www.cs.kun.nl/~hooman/so2/
[email protected] (
[email protected])
16 February 2004
Jozef Hooman
1
16 February 2004
College : maandag, 13:45 - 15:30 1. 2. 3. 4. 5. 6. 7. 8.
3 februari 2004 16 februari 2004 8 maart 2004 22 maart 2004 5 april 2004 19 april 2004 10 mei 2004 24 mei 2004
16 February 2004
3
Volgende College – 8 maart 2004 Alle 4 GiP projecten geven presentatie over: • Globale idee requirements, stake holders, business case, actors, use cases • Risico analyse • Keuze software ontwikkelproces (hoe produkt maken en waarom zo) Tijd: ca 10 minuten per project, daarna evaluatie 16 February 2004
SO2 College 2
Jozef Hooman
2
College Vandaag • ROPES, met name proces en requirements (paper op WWW) • UML notatie, met name voor requirements (link naar tutorial op WWW) • RUP, iterative, incremental (Pressman H 2) • Risico management (Pressman H 6, WWW) • RUP – evaluation tool Rational (WWW)
Sheets in pdf op WWW A0002 A0002 A0002 A0013 A0013 A0002 A0002
Jozef Hooman
Jozef Hooman
5
16 February 2004
Jozef Hooman
4
Iterative, incremental development, related to Spiral Model of Boehm, is used in ROPES Rapid Object-Oriented Process for Embedded Systems from Bruce Powel Douglass (I-Logix)
16 February 2004
Jozef Hooman
6
1
Jozef Hooman
Example Iterative Development
ROPES
16 February 2004
Build embedded communication protocol following 7-layer ISO standard
Jozef Hooman
7
16 February 2004
Jozef Hooman
8
ROPES process
Example: develop early prototypes
16 February 2004
Jozef Hooman
9
16 February 2004
Jozef Hooman
10
16 February 2004
Jozef Hooman
11
16 February 2004
Jozef Hooman
12
SO2 College 2
2
Jozef Hooman
Development of the UML the Unified Modeling Language
Unified Modeling Language UML Most current methods, including ROPES, use UML to describe various views on software using mainly visual notations
16 February 2004
• ‘89-’94: more than 50 modeling languages for Object Oriented analysis and design. Including methods of Grady Booch Jim Rumbaugh (OMT - Object Modeling Technique), Ivar Jacobson (OOSE Object Oriented Software Engineering) . Jozef Hooman
13
Most methods contain some class diagram: H otel ad d re s s : s tring / n u m b erOfR oo m s : In te g er m in Flo or : in teg er m a xFloo r : in te g er
*
1
p ain t(n e wCo lor : Co lor)
tota lR e nt() : rea l
+hotel
+room /sleepsin *
*
+room
+guests
G uest
16 February 2004
0 ..1
0..1
BathRoom
n am e : s tring a ge : in teg er s ex : {m ale , fe m ale }
us age : integer us es (g : G ues t)
Jozef Hooman
15
SO2 College 2
Jozef Hooman
16 February 2004
Jozef Hooman
16
Example
UML: mainly visual modeling language for specifying, constructing, visualizing and documenting software-intensive systems. 16 February 2004
14
• Oct’94: at Rational Software, Grady Booch (Booch’93) and Jim Rumbaugh (OMT) start unification of their methods. • Oct’95: draft 0.8 of Unified Method, Ivar Jacobson (OOSE) joins Rational, aiming at Unified Modeling Language.
flo o rN um be r : In te g er roo m N um b e r : I nt e ger
n um ber OfBe d s : i nt eg er re nt : re al colo r : C olo r
Jozef Hooman
Development of the UML the Unified Modeling Language
HotelR oom
Room
+hotel
16 February 2004
The ESU University wants to computerize the registration system – The Registrar sets up the curriculum for a semester • One course may have multiple course offerings – Students select 4 primary courses and 2 alternate courses – Once a student registers for a semester, the billing system is notified so the student may be billed for the semester – Students may use the system to add/drop courses for a period of time after registration – Professors use the system to receive their course offering rosters – Users of the registration system are assigned passwords which are used at logon validation 17
16 February 2004
Jozef Hooman
18
3
Jozef Hooman
• A use case is a pattern of behavior the system exhibits – Each use case is a sequence of related transactions performed by an actor and the system in a dialogue
• An actor is someone or some thing that must interact with the system under development
• Actors are examined to determine their needs – Registrar -- maintain the curriculum – Professor -- request roster – Student -- maintain schedule – Billing System -- receive billing information from registration
Registrar Professor
Student Billing System Maintain Curriculum 16 February 2004
Jozef Hooman
19
• A flow of events document is created for each use cases – Written from an actor point of view • Details what the system must provide to the actor when the use cases is executed • Typical contents – How the use case starts and ends – Normal flow of events – Alternate flow of events – Exceptional flow of events
Jozef Hooman
21
• Use case diagrams are created to visualize the relationships between actors and use cases
Professor Maintain Schedule
Billing System
Jozef Hooman
20
• This use case begins when the Registrar logs onto the Registration System and enters his/her password. The system verifies that the password is valid (E-1) and prompts the Registrar to select the current semester or a future semester (E-2). The Registrar enters the desired semester. The system prompts the professor to select the desired activity: ADD, DELETE, REVIEW, or QUIT. • If the activity selected is ADD, the S-1: Add a Course subflow is performed. • If the activity selected is DELETE, the S-2: Delete a Course subflow is performed. • If the activity selected is REVIEW, the S-3: Review Curriculum subflow is performed. • If the activity selected is QUIT, the use case ends. • ... 16 February 2004
Jozef Hooman
22
• Use case diagram presents an outside view of the system • Interaction diagrams describe how use cases are realized as interactions among societies of objects • Two types of interaction diagrams – Sequence diagrams – Collaboration diagrams
Request Course Roster Student
Maintain Schedule
Maintain Curriculum -- Flow of Events
Documenting Use Cases
16 February 2004
16 February 2004
Request Course Roster
Maintain Curriculum Registrar
16 February 2004
SO2 College 2
Jozef Hooman
23
16 February 2004
Jozef Hooman
24
4
Jozef Hooman
Sequence Diagram
Collaboration Diagram
• A sequence diagram displays object interactions arranged in a time sequence
: Student
registration form
registration manager
math 101
• A collaboration diagram displays object interactions organized around objects and their links to one another 1: set course info 2: process
math 101 section 1
course form : CourseForm
1: fill in info 2: submit
3: add course
: Registrar
3: add course(joe, math 01) 4: are you open? 5: are you open? 6: add (joe)
7: add (joe)
theManager : CurriculumManager
aCourse : Course 4: new course
16 February 2004
Jozef Hooman
25
16 February 2004
History of UML
Jozef Hooman
• Jan. 1997: UML 1.0 • Sept. 1997: UML 1.1 with contribution from new partners, clarification semantics • June 1999: UML 1.3 • 2001: UML 1.4, minor revision Added in 2002: Action Language • 2004: UML 2.0, major revision 27
Almost all current CASE tools claim UML compatibility, e.g. Many industries use UML and UML-based development • Philips Medical System, Oce, Chess, ICT, Philips Semiconductors, NLR, ASML, …., web-development, …
SO2 College 2
Jozef Hooman
16 February 2004
Jozef Hooman
28
UML tool support: Rational Rose
• Rational Rose, Rose Real-Time, ARTiSAN, Rhapsody,TogetherJ, Argo UML
16 February 2004
26
UML development
• June’96: UML 0.9 • Oct’96: UML 0.91 • 1996: Object Management Group (OMG) coordinates definition of UML standard. Contributors: IBM, Oracle, DEC, HP, Unisys, I-Logix, ObjecTime, PLATINUM, SAP, Sterling Software, ... 16 February 2004
Jozef Hooman
29
• Use case view: Use case diagram, Sequence diagram, State/activity diagram. • Logical view: Class diagram, OCL, State diagram, Sequence diagram. • Implementation diagrams: Component diagram, Deployment diagram.
16 February 2004
Jozef Hooman
30
5
Jozef Hooman
16 February 2004
Jozef Hooman
31
Jacobson, Booch and Rumbaugh defined a unified software development process, the Rational Unified Process (RUP) Basically, iterative, incremental development, similar to spiral model Different from waterfall process Jozef Hooman
33
• Big Bang Delivery Theory • The proof of the concept is relegated to the very end of a long singular cycle. Before final integration, only documents have been produced • Late deployment hides many lurking risks: – technological (well, I thought they would work together...) – conceptual (well, I thought that' s what they wanted...) – personnel (took so long, half the team left) – user doesn' t get to see anything real until the very end, and they always hate it – system testing doesn' t get involved until later in process
SO2 College 2
Jozef Hooman
32
• Requirements are known up front before design • Requirements rarely change • Users know what they want, and rarely need visualization • Design can be conducted in a purely abstract space, or trial rarely leads to error • The technology will all fit nicely into place when the time comes • The system is not so complex 16 February 2004
Jozef Hooman
34
An Iterative Development Process...
Waterfall Process Limitations
16 February 2004
Jozef Hooman
Waterfall Process Assumptions
UML-based development
16 February 2004
16 February 2004
35
• Recognizes the reality of changing requirements Caspers Jones’s research on 8000 projects: 40% of final requirements arrived after the analysis phase, after development had already begun • Promotes early risk mitigation, by breaking down system into mini-projects and focusing on the riskier elements first • Allows to “plan a little, design a little, and code a little” • Encourages all participants, including testers, integrators, and technical writers to be involved earlier on • Allows to correct errors sooner and put into practice lessons learned in the prior iteration • Focuses on component architectures, not final big bang deployments 16 February 2004
Jozef Hooman
36
6
Jozef Hooman
An Incremental Development Process...
Goals and Features of Each Iteration
• Allows for software to evolve, not be produced in one huge effort • Allows software to improve, by giving enough time to the evolutionary process itself • Forces attention on stability, for only a stable foundation can support multiple additions • Allows the system (a small subset of it) to actually run much sooner than with other processes • Allows interim progress to continue through the stubbing of functionality • Allows for the management of risk, by exposing problems earlier on in the development process
• The primary goal of each iteration is to slowly chip away at the risk facing the project, namely: – performance risks – integration risks (different vendors, tools, etc.) – conceptual risks (ferret out analysis and design flaws) • Perform a “miniwaterfall” project that ends with a delivery of something tangible in code, available for scrutiny by the interested parties, which produces validation or correctives • Each iteration is risk-driven • The result of a single iteration is an increment--an incremental improvement of the system, yielding an evolutionary approach
16 February 2004
16 February 2004
Jozef Hooman
37
The First Iteration • The first iteration is usually the hardest – Requires the entire development environment and most of the development team to be in place – Many tool integration issues, team-building issues, staffing issues, etc. must be resolved • Teams new to an iterative approach are usually overly-optimistic • Be modest regarding the amount of functionality that can be achieved in the first iteration – Otherwise, completion of the first iteration will be delayed, – The total number of iterations reduced, and – The benefits of an iterative approach reduced 16 February 2004
Jozef Hooman
39
16 February 2004
SO2 College 2
Jozef Hooman
41
38
There Is No Silver Bullet • Remember the main reason for using the iterative life cycle: – You do not have all the information you need up front – Things will change during the development period • You must expect that – Some risks will not be eliminated as planned – You will discover new risks along the way – Some rework will be required; some lines of code developed for an iteration will be thrown away – Requirements will change along the way
16 February 2004
Risk Management “If you don’t actively attack the risks, they will actively attack you” – Tom Gilb Identify risks: • Technology risks • People risks • Organizational risks • Tools risks • Requirements risks • Estimation risks
Jozef Hooman
Jozef Hooman
40
Risk analysis Estimate for each risk: • Probability, e.g. low, medium, high • Impact, e.g. negligible, marginal, critical, catastrophic If possible qualify impact of risk concerning: cost, performance, schedule, support Overall risk, e.g. none, low, moderate, high is derived from probability and impact 16 February 2004
Jozef Hooman
42
7
Jozef Hooman
Meest belangrijke SDRF’s Software Development Risk Factors
Risk Planning and Monitoring Define strategies to deal with risks, e.g. reorganize, training, trace requirements, … Next monitor the risks, discuss, re-plan, adapt strategies, etc.
• • • • • • • • • • • • •
16 February 2004
Jozef Hooman
43
Stappenplan risico analyse en management •
•
16 February 2004
001
002
Risico gebied En omschrijving De performance van het systeem levert een niet werkbare situatie op.
Maatregel
Hardware is te langzaam. Software is niet goed getunned. Databases zijn te groot.
Tijdens het opzetten van de 1 technische infrastructuur dient rekening te worden gehouden met de eisen die door ERPLEVERANCIER aan de hardware (server, netwerk, PC’s, etc.) worden gesteld. De performance van het systeem zal uitgebreid getest moeten worden. De procesmodellen gewenste 1 situatie worden duidelijk door de projectleiding gecommuniceerd aan de medewerkers. Daarbij wordt de scope en fasering (wat in de implementatie, wat in de nazorgfase) duidelijk aangegeven. Projectleiding bewaakt dat scope niet wordt aangepast gedurende het traject, en dat discussies tijdig worden afgerond.
Er bestaat onduidelijkheid over de Geen duidelijke scope. gewenste werkwijze, de scope en de Procesmodellen zijn niet toepassing van ERP-pakket gedetailleerd genoeg. Projectplan niet duidelijk. Slecht functionerende projectorganisatie.
Kans
(3)
Effect Risico 5
44
(2)
Als een risico wordt geconstateerd hierop gelijk anticiperen (gebruik risico formulieren)
•
Hoelang laat “men” een project doorgaan? 16 February 2004
Jozef Hooman
46
Stappenplan risico analyse en management
(4)
Status *
5 nr
003
5
Jozef Hooman
•
45
Oorzaak
• • • •
Ongeschikt projectmanagement Gebrek aan overwicht Te grote druk op het volgen van de planning Complexe projectorganisatie Te veel externe partijen Te veel externen ………….
Het inschatten van de risico’s – Impact – Kans dat een risico zich voordoet – Wat gebeurt er als een risico zich voordoet – U.S. Air force gebruikt Risk exposure RE = P x C (P = kans, C = kosten als risico zich voordoet) Het evalueren van de risico’s Vaststellen voor welke risico’s een Risk Mitigation and Management Plan voor wordt opgesteld. (RMMM)
• •
Jozef Hooman
• • •
Stappenplan risico analyse en management •
Stappenplan risico analyse en management nr
16 February 2004
(1)
Twee ingangen: – Voorspelbare risico’s, vanuit verleden – Onvoorspelbare risico’s, nieuwe Het identificeren van risico’s – Lijsten en creativiteit gebruiken – Actoren analyse – Software risk components: • Performance aansluiting requirements, fit for use • Cost onzekerheid dat projectbudget wordt gehaald • Support mate waarin software onderhouden kan worden • Schedule halen van de planning – Impact: • Catastrophic • Critical • Marginal • Negligible
Schuivende gebruikerswensen/eisen Niet beschikbare kerngebruikers Afhankelijkheid beperkte groep mensen Project manager niet beschikbaar Geen continuïteit in project bemensing Gebrek aan commitment vanuit management Te veel papierwerk Te groot en complex project Gebrek aan kennis en ervaring met het software product Gebrek aan externe ondersteuning Incorrecte begroting Gebrek aan gebruikersondersteuning Te veel interfaces
Risico gebied En omschrijving Tijdens de implementatie blijken onvoorziene ‘non-fits’ tussen de gewenste en de geboden functionaliteit van ERP-pakket.
Oorzaak
Maatregel
Extra informatie komt naar boven gedurende de ontwerpfase. Verandering van inzicht door meer inzicht van de kerngebruikers in het pakket ERP-pakket.
Tijdens de ontwerpfase kunnen de 1 prioriteiten ten aanzien van de te implementeren basisfunctionaliteit worden bepaald, waarbij functionaliteit die niet strikt noodzakelijk is voor het behalen van de geformuleerde projectdoelstelling in overleg met de stuurgroep mogelijk in het nazorg cq optimalisatie-traject wordt gerealiseerd. Tijdens de totaalimplementatie zijn slechts ERP-scripts, work-arounds of aanpassingen in bestaande processen of werkwijzen toelaatbaar. Nieuw Maatwerk moet worden vermeden en brengt de ‘golive’ datum in gevaar. De medewerkers van Klant moeten 5 het gevoel hebben dat het hun systeem is. Stellen de opdrachtgever op de hoogte, zodat hij coorigerende maatregelen kan nemen.
5
012
1 = kleine kans of gering effect, 5 = grote kans of groot effect
Binnen het bedrijf is onvoldoende acceptatie van de wijzigingen door de implementatie
* AZ = actueel, zelf actie ondernemen AA = actueel, anderen actie NAZ = niet actueel, zelf actie NAA = niet actueel, anderen actie
Andere personen dan mensen die werkzaam zijn bij Klant bepalen de processen. De veranderde processen hebben een te diepe persoonlijke impact
Kans
Effect Risico
5
5
5
25
Status *
1 = kleine kans of gering effect, 5 = grote kans of groot effect
* AZ = actueel, zelf actie ondernemen AA = actueel, anderen actie NAZ = niet actueel, zelf actie NAA = niet actueel, anderen actie
16 February 2004
SO2 College 2
Jozef Hooman
47
16 February 2004
Jozef Hooman
48
8
