Presentation is loading. Please wait.

Presentation is loading. Please wait.

RISK ASSESSMENT. Risk Assessment Definition: “Risk…merely identifies the undesirable events that might take place during the project” [Jalote, 1998] Three.

Similar presentations


Presentation on theme: "RISK ASSESSMENT. Risk Assessment Definition: “Risk…merely identifies the undesirable events that might take place during the project” [Jalote, 1998] Three."— Presentation transcript:

1 RISK ASSESSMENT

2 Risk Assessment Definition: “Risk…merely identifies the undesirable events that might take place during the project” [Jalote, 1998] Three Types: Cost risk Performance Risk Schedule Risk

3 Risk Assessment Major Risks Encountered in SD Vague Requirements Costs and Schedule Estimation Hidden Costs Communication Breakdowns Poor Architecture Personnel Shortfalls

4 Software Development- A320 Blunder

5 Risk Assessment

6 Risk Reduction Prototyping Simulation Benchmarking References, Off-the-Shelf Components Questionnaires Analytic Modeling

7 Design Techniques Standardizing Specification Techniques UML Modeling Language SCR/A7-E Specification Technique

8 Design Techniques Top Down Functional Decomposition Information Hiding Object Oriented Design

9 Modern Software Development Move to OO Designs Formal Modeling Languages Emphasis on Documentation

10 Role of Discrete Mathematics Formal languages for testing systems

11 Spiral Model Case Study Purpose: Experimental validation of this approach The case study involved extending USC’s Integrated Library System to access multimedia archives, including films, maps, and videos.

12 What were they trying to build/show? The Integrated Library System is a Unix- based, text-oriented, client-server system designed to manage the acquisition, cataloging, public access, and circulation of library material. The study’s specific goal was to evaluate the feasibility of using the spiral model to build applications written by USC graduate student teams.

13 Cycles of the Spiral Model Cycle 0. Determine the feasibility of an appropriate family of multimedia applications. Cycle 1. Develop life-cycle objectives (LCO milestone), prototypes, plans, and specifications for individual applications and verify the existence of at least one feasible architecture for each application. Cycle 2. Establish a specific, detailed life-cycle architecture (LCA milestone), verify its feasibility, and determine that there are no major risks in satisfying the plans and specifications. Cycle 3. Achieve a workable initial operational capability (IOC milestone) for each project

14 Results From the 16 projects in the first semester, the clients selected five applications for development according to the library’s commitment to sustain them after the second semester (IOC). Four are now transitioning to library operations, and the fifth has good prospects for transition after refinement this summer. The librarians were delighted with the final presentations.

15 Lessons Learned The most important outcome of product definition is not a rigorous specification, but a team of stakeholders with enough trust and shared vision to adapt effectively to unexpected changes. Don’t finish negotiations before prototyping. If you do, the agreements destabilize once the clients see the prototypes. For projects of this size, using a single cycle each for the LCO and LCA milestones was about right.

16 Software Development as a Business Process

17 State of the Market Today: The Frenzy, The Freeze, And After Freeze In Technology Decisions State Of The Market Today Frenzy Of Technology Spending Dot-com Boom Infrastructure Boom Click-And-Mortar Race Dot-com Bust Infrastructure Crash Click-And-Mortar Survival Real E-Business Build Resilient IT Strategic New Initiatives Strong Economy Internet Euphoria Time-to-market Demands Quick Buying Decisions Weak ROI Models Weak Economy Shrinking Revenues Focus on IT Cost Control Business Outlook Unclear Projects Frozen / On Hold US: Slow Recovery EU: Flat Market Challenging Stock Market Selective Projects Decision Cycles Improving Focus on ROI Justification Growing Demand For Outsourcing

18 The 1980 Letter to The CEO of Ericsson* The component-based development approach used for AKE/AXE will evolve into a world standard Go further in three steps 1983: a standard method including a modeling language and a process, supported by a first generation tool-set 1985: the modeling language becomes a formal executable language 1990: expert system on top of software process and development tool; “end-user programming” * Björn Svedberg

19 Component-Based Architectures Originated 1967-70 at Ericsson for real-time, distributed systems: blocks a k o components, design code executables run-time objects interfaces based on signals, functions crossed blocks -- or realized as collaborations among blocks Components have become the standard. No new development paradigm to replace components in sight!

20 Modeling Languages 1967-70: The AKE/AXE modeling language: block diagrams collaboration diagrams sequence diagrams state transition diagrams (state overviews, activity diagrams, concurrent states) 1974-82: the first object modeling standard SDL adopts those techniques nicknamed ‘The Ericsson Language’ In parallel Entity-Relationship modeling emerged 1987: Objectory modeling language combined SDL and ER technologies, added Use Cases and Multi-Modeling. 1996: The Unified Modeling Language based on Objectory, Booch and OMT from 1991 plus many other modeling ideas The standard modeling language UML 2.0 a major new release, followed by more...

21 Development Process 1967-70 The AKE/AXE method functional spec’s software architecture description functional descr’s, block descriptions, separate from interface (signal) descriptions functional tests and system test 1987-95 The Objectory Process engineered process to facilitate specializations and instantiations (projects) use cases drive the business track, the system track and the user track 1996-2000: The Rational Unified Process iterative development architecture-centric tool support for process engineering and process instantiations de-facto standard for e-development

22 Future of Software We have the standard modeling language We have a standard development process What next? A Software Component Marketplace Quality from the Beginning Give Soul to Software Process A Complete UML Based Software Platform

23 A Software Component Marketplace A component industry including Component factories provide ‘components’ System Integrators reuse these ‘components’ ‘Components’ are component systems used to build families of application systems We need a standard for playing on this marketplace How to design for reuse How to design with reuse

24 Reuse of all models, that is of everything architecture -- most important but just a fraction of what is reusable use cases, analysis, design, implementation and test user interface models, business models, etc. Reuse of technology process with tools projects guidelines Reuseable Assets

25 The Reuse Initiative: e- Development Accelerator Reusable Frameworks Reuse Standards Automation Open UML-based standard expressing how to document and produce reusable assets. Technology or domain specific reusable assets with associated guidelines on usage. Tool support for creating, managing, and reusing software assets.

26 Component System Component System Component System Application System Application System Application System Component System Component System Layered System Architecture Car Sales Management Customer profile Order management Shopping cart Credit card authorization Object persistency mechanism Examples of reusable object Application-general layer Middleware layer Application-specific layer System-software layer Component System Component System

27 Quality from the Beginning We have lost two generations of developers who think they just need to debug at the end, when they instead shouldn’t introduce any defects along the way. An attitude problem “bugs are nice, defects are bad” “some developers make the dirt, others (customers) clean up” Process change verify and test along the way -- activity-based verification there is no test model, test artifacts are part of all models New tools generate test cases from requirements, analysis, design...

28 Activity-Based Verification Whatever you do, you are not done until you have verified that you did what you wanted to do. Introduce verification on activities Each activity-artifact pair needs a Verification Case Each Verification Case has a corresponding Verification Step Test Cases are specializations of Verification Cases, related to the executable system

29 Software Process Comes Alive Development steps The process at your fingertips The process gets soul the third step 20 years ago a software engineering breakthrough technology

30 The Process at Your Fingertips Rational Unified Process (RUP) My Unified Process My Project My tasks Is specialized to Is enacted as And to

31 Process gets soul: people may be humans StaticDynamic Structured Re-Invent Generic Long-Term Learn Creative Reuse Streamlined and Personalized Short-Term Do Traditional processes hold static rules and regulations, but lacks “soul” and adaptive capabilities. They appeal to structured reasoning, but not to the creative (lateral) spirit.

32 Software Components, but… Autonomous Pro-Active Encapsulate Knowledge as Rules Adaptive Agents Agent (in software)

33 Each Developer has its Own Personal Agent Personal Agent (for Joe) Joe (Developer) Individuals play roles in software development www. jaczone.com

34 Every Role in RUP is Matched to One Agent System Analyst Role Agent (for System Analyst) Agent System www. jaczone.com

35 Personal Agents and Role Agents Personal Agent (for Joe) Joe (Developer) Role Agent (for System Analyst) Role Agent (for Business-Process Analyst) Agent System Since a developer can play many roles his/her personal agent may collaborate with several role agents

36 Specialist Agents Rule agents Reuse agents suggest candidate patterns, frameworks, etc Workflow agents suggest micro-activities based on state Conversation agents for conversational modeling Model completion agents Round-trip modeling agents between all kinds of models Evaluation agents Broker agents www. jaczone.com

37 A Complete UML Based Platform An executable UML a programming language (or a set of PL’s) Java, C++ become superfluous combines graphical and program-like syntax Semantics of changes -- functional and structural -- defined by UML language defined configuration and version management Removing seams (or gaps) between UML and operating systems and database mgmt systems computer architectures An executable UML a programming language (or a set of PL’s) Java, C++ become superfluous combines graphical and program-like syntax Semantics of changes -- functional and structural -- defined by UML language defined configuration and version management Removing seams (or gaps) between UML and operating systems and database mgmt systems computer architectures "Function Distribution in Computer System Architectures”, Harold “Bud” Lawson, 1976 "Function Distribution in Computer System Architectures”, Harold “Bud” Lawson, 1976

38 Every Layer of Components described in UML Systemware components operating systems database management systems Middleware components Customer relationship management Content management Change management Application general components Subscriber management Digit analysis node Route data

39 Trend: Focus moves upwards Use cases generate test cases and input to analysis Analysis will generate implementation; design will become superfluous Req.tsImpl.Test Analysis Design More “generation”=work elimination Now Tomorrow

40 Tomorrow, Life will be Much Better! We have UML, RUP and tools Eventually we will get a Component Industry We will do things right from the beginning Process will get soul -- developers are people and people are humans We will get rid of seams and gaps between levels Summary

41 Readings by Ivar Jacobson Unified Software Development Process Jacobson, Booch, Rumbaugh, Addison Wesley Longman (1999) Object-Oriented Software Development--A Use Case Driven Approach (Addison Wesley) Ivar Jacobson, Addison Wesley Longman (1992) The Object Advantage: Business Process Reengineering with Objects (Addison Wesley) Ivar Jacobson, Addison Wesley Longman (1994) Software Reuse: Architecture, Process and Organization for Business Success (Addison Wesley) Ivar Jacobson, Addison Wesley Longman (1997) The Road to the Unified Software Development Process Ivar Jacobson, Stefan Bylund, Cambridge University Press, 2000

42 Special readings Software Reuse: Architecture, Process and Organization for Business Success (Addison Wesley) Ivar Jacobson, Addison Wesley Longman (1997) Function Distribution in Computer System Architectures, Harold “ Bud” Lawson (1976)


Download ppt "RISK ASSESSMENT. Risk Assessment Definition: “Risk…merely identifies the undesirable events that might take place during the project” [Jalote, 1998] Three."

Similar presentations


Ads by Google