Afronding SO2. Systeemontwikkeling 2 (SO2) College 2. College : maandag, 13:45-15:30. College Vandaag. Volgende College 8 maart 2004.

Transcriptie

1 Systeemontwikkeling 2 (SO2) College 2 Jozef Hooman (A6006) jozef.hooman@embeddedsystems.nl (hooman@cs.kun.nl) 16 February 2004 Jozef Hooman 1 Afronding SO2 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 16 February 2004 Jozef Hooman 2 College : maandag, 13:45-15: februari 2004 Sheets in pdf op WWW februari 2004 A maart 2004 A maart 2004 A april 2004 A april 2004 A mei 2004 A mei 2004 A0002 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) 16 February 2004 Jozef Hooman 3 16 February 2004 Jozef Hooman 4 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 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 5 16 February 2004 Jozef Hooman 6 SO2 College 2 1

2 ROPES Example Iterative Development Build embedded communication protocol following 7-layer ISO standard 16 February 2004 Jozef Hooman 7 16 February 2004 Jozef Hooman 8 Example: develop early prototypes ROPES process 16 February 2004 Jozef Hooman 9 16 February 2004 Jozef Hooman February 2004 Jozef Hooman February 2004 Jozef Hooman 12 SO2 College 2 2

3 Unified Modeling Language UML Most current methods, including ROPES, use UML to describe various views on software using mainly visual notations Development of the UML the Unified Modeling Language 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). 16 February 2004 Jozef Hooman February 2004 Jozef Hooman 14 Most methods contain some class diagram: Hotel address : string / numberofrooms : Integer m infloor : integer m axfloor : integer totalr ent() : real +hotel +hotel 1 /sleepsin * Guest nam e : string age : integer sex : {male, female} * +room * +guests Room num berofbeds : integer rent : real color : C olor paint(newcolor : Color) +room BathRoom usage : integer uses(g : Guest) HotelRoom floorn um ber : Integer room N um ber : Integer Development of the UML the Unified Modeling Language 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. 16 February 2004 Jozef Hooman February 2004 Jozef Hooman 16 UML: mainly visual modeling language for specifying, constructing, visualizing and documenting software-intensive systems. Example 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 16 February 2004 Jozef Hooman February 2004 Jozef Hooman 18 SO2 College 2 3

4 An actor is someone or some thing that must interact with the system under development 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 Registrar Professor Actors are examined to determine their needs Registrar -- maintain the curriculum Professor -- request roster Student -- maintain schedule Billing System -- receive billing information from registration Student Billing System Maintain Curriculum Request Course Roster Maintain Schedule 16 February 2004 Jozef Hooman February 2004 Jozef Hooman 20 Documenting Use Cases 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 16 February 2004 Jozef Hooman 21 Maintain Curriculum -- Flow of Events 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 February 2004 Jozef Hooman 22 Use case diagrams are created to visualize the relationships between actors and use cases Student Maintain Schedule Request Course Roster Professor 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 Billing System Maintain Curriculum Registrar 16 February 2004 Jozef Hooman February 2004 Jozef Hooman 24 SO2 College 2 4

5 Sequence Diagram A sequence diagram displays object interactions arranged in a time sequence Collaboration Diagram A collaboration diagram displays object interactions organized around objects and their links to one another : Student registration form registration manager math 101 math 101 section 1 1: set course info 2: process course form : CourseForm 1: fill in info 2: submit 3: add course(joe, math 01) : Registrar 3: add course 4: are you open? 5: are you open? 6: add (joe) 7: add (joe) acourse : Course themanager : CurriculumManager 4: new course 16 February 2004 Jozef Hooman February 2004 Jozef Hooman 26 June 96: UML 0.9 Oct 96: UML 0.91 History of UML 1996: Object Management Group (OMG) coordinates definition of UML standard. Contributors: IBM, Oracle, DEC, HP, Unisys, I-Logix, ObjecTime, PLATINUM, SAP, Sterling Software,... UML development Jan. 1997: UML 1.0 Sept. 1997: UML 1.1 with contribution from new partners, clarification semantics June 1999: UML : UML 1.4, minor revision Added in 2002: Action Language 2004: UML 2.0, major revision 16 February 2004 Jozef Hooman February 2004 Jozef Hooman 28 Almost all current CASE tools claim UML compatibility, e.g. Rational Rose, Rose Real-Time, ARTiSAN, Rhapsody,TogetherJ, Argo UML Many industries use UML and UML-based development Philips Medical System, Oce, Chess, ICT, Philips Semiconductors, NLR, ASML,., web-development, UML tool support: Rational Rose 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 February 2004 Jozef Hooman 30 SO2 College 2 5

6 16 February 2004 Jozef Hooman February 2004 Jozef Hooman 32 UML-based development 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 16 February 2004 Jozef Hooman 33 Waterfall Process Assumptions 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 Waterfall Process Limitations 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 16 February 2004 Jozef Hooman 35 An Iterative Development Process... 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 SO2 College 2 6

7 An Incremental Development Process... 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 16 February 2004 Jozef Hooman 37 Goals and Features of Each Iteration 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 Jozef Hooman 38 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 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 Jozef Hooman February 2004 Jozef Hooman 40 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 16 February 2004 Jozef Hooman 41 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 SO2 College 2 7

8 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. Meest belangrijke SDRF s Software Development Risk Factors 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 Ongeschikt projectmanagement Gebrek aan overwicht Te grote druk op het volgen van de planning Complexe projectorganisatie Te veel externe partijen Te veel externen. 16 February 2004 Jozef Hooman February 2004 Jozef Hooman 44 Stappenplan risico analyse en management (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 16 February 2004 Jozef Hooman 45 Stappenplan risico analyse en management (2) 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) 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 (3) Stappenplan risico analyse en management (4) nr Risico gebied Oorzaak Maatregel Kans Effect Risico Status En omschrijving * 001 De performance van het systeem Hardware is te langzaam. Tijdens het opzetten van de levert een niet werkbare situatie op. Software is niet goed getunned. technische infrastructuur dient Databases zijn te groot. rekening te worden gehouden met de eisen die door ERP- LEVERANCIER aan de hardware (server, netwerk, PC s, etc.) worden gesteld. De performance van het systeem zal uitgebreid getest moeten worden. 002 Er bestaat onduidelijkheid over de Geen duidelijke scope. De procesmodellen gewenste gewenste werkwijze, de scope en de Procesmodellen zijn niet situatie worden duidelijk door de toepassing van ERP-pakket gedetailleerd genoeg. projectleiding gecommuniceerd aan Projectplan niet duidelijk. de medewerkers. Daarbij wordt de Slecht functionerende scope en fasering (wat in de projectorganisatie. implementatie, wat in de nazorgfase) duidelijk aangegeven. Projectleiding bewaakt dat scope niet wordt aangepast gedurende het traject, en dat discussies tijdig worden afgerond. 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 nr Risico gebied En omschrijving 003 Tijdens de implementatie blijken onvoorziene non-fits tussen de gewenste en de geboden functionaliteit van ERP-pakket. 012 Binnen het bedrijf is onvoldoende acceptatie van de wijzigingen door de implementatie Oorzaak Maatregel Kans Effect Risico Status * Extra informatie komt naar boven Tijdens de ontwerpfase kunnen de gedurende de ontwerpfase. prioriteiten ten aanzien van de te Verandering van inzicht door meer implementeren basisfunctionaliteit inzicht van de kerngebruikers in het worden bepaald, waarbij pakket ERP-pakket. 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. Andere personen dan mensen die De medewerkers van Klant moeten werkzaam zijn bij Klant bepalen de het gevoel hebben dat het hun processen. systeem is. De veranderde processen hebben Stellen de opdrachtgever op de een te diepe persoonlijke impact hoogte, zodat hij coorigerende maatregelen kan nemen. 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 Jozef Hooman February 2004 Jozef Hooman 48 SO2 College 2 8