Models

1. Models Object-Oriented Software EngineeringCS350

2. Types of Models • Prototypes • Watefall • Spiral

3. Prototyping • 1960s and 1970s • Monolithic development cycle • Building the entire program first • Then working out inconsistencies between design and implementation • Led to higher software costs and poor estimates of time and cost • Called the "Slaying the (software) Dragon" technique

4. Prototyping Process • Identify basic requirements • Determine basic requirements including the input and output information desired • Details, such as security, can typically be ignored • Develop Initial Prototype • The initial prototype is developed that includes only user interfaces • Review • The customers, including end-users, examine the prototype and provide feedback on additions or changes • Revise and Enhance the Prototype • Using feedback both specifications and prototype can be improved • Negotiation about what is within the scope of the contract/product may be necessary • Repeat steps #3 and #4 as needed

5. Dimensions of Prototypes • Horizontal prototypes • Vertical prototypes

6. Horizontal Prototype • User interface prototype • Provides a broad view of an entire system or subsystem • Focuses on user interaction more than low-level system functionality • Useful for: • Confirmation of user interface requirements and system scope • Demonstration version of the system to obtain buy-in from the business • Develop preliminary estimates of development time, cost and effort

7. Vertical Prototype • More complete elaboration of a single subsystem or function • Useful for obtaining detailed requirements for a given function, with the following benefits: • Refinement database design • Obtain information on data volumes and system interface needs, for network sizing and performance engineering • Clarifies complex requirements by drilling down to actual system functionality

8. Types of Prototyping • Throwaway (Rapid) prototyping • Evolutionary prototyping • Incremental prototyping • Extreme prototyping

9. Throwaway Prototyping • Write preliminary requirements • Design the prototype • User experiences/uses the prototype, specifies new requirements • Repeat if necessary • Write the final requirements • Develop the real products

10. Throwaway Prototyping • “Close-ended prototyping” • Creation of a model that will eventually be discarded rather than becoming part of the final delivered software • After preliminary requirements, a simple working model is constructed • Involves creating a working model of various system parts at a very early stage • Usually quite informal • Most important factor is speed • Model becomes starting point from which users can re-examine expectations and clarify requirements • Then the prototype model is 'thrown away'

11. Throwaway Prototyping • Can be done quickly • Quick feedback may enable early refinement • Can be extremely cost effective • Nothing at this point to redo • Cost of “fixes” grows exponentially with time • Speed is crucial in implementing a throwaway prototype, given limited budget of time and money • Ability to construct interfaces that the users can test • By seeing the interface, user can more easily grasp how the system will work

12. Throwaway Prototyping • More effective manner to deal with user requirements-related issues • Greater enhancement to software productivity overall • Ignores issues of evolvability, maintainability, and software structure • Requirements can be identified, simulated, and tested far more quickly and cheaply • Prototypes can be classified according to the fidelity, interaction and timing

13. Evolutionary Prototyping • “Breadboard prototyping” • Main goal is to build a very robust prototype in a structured manner and constantly refine it • System is continually refined and rebuilt • Acknowledges that we do not understand all the requirements • Builds only those that are well understood

14. Evolutionary Prototyping • This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase. • To be useful, system must evolve through use • A product is never "done" • System defined using where we are now • Assumptions made about the way business will be conducted and the technology base used • Plan is enacted to develop the capability • Sooner or later, something resembling the envisioned system is delivered

15. Evolutionary Prototyping • As opposed to Throwaway Prototypes, they are functional systems • May be used on an interim basis until the final system is delivered • Not unusual to put an initial prototype to practical use while waiting for a more developed version • User may decide that a 'flawed' system is better than no system at all

16. Evolutionary Prototyping • Developers can focus on developing parts of the system they understand • To minimize risk, developer does not implement poorly understood features • Users detect opportunities for new features and give requests to developers • Developers use requests to change the software-requirements specification, update the design, recode and retest

17. Incremental Prototyping • Final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.

18. Extreme Prototyping • Used especially for developing web applications • Three phases: • Static prototype that consists mainly of HTML pages • Screens are programmed and fully functional using a simulated services layer • Services are implemented

19. Advantages of Prototyping • Reduced time and costs • Can improve the quality of requirements and specifications provided to developers • Early determination of what the user really wants can result in faster and less expensive software • Improved and increased user involvement • Requires user involvement • Provides better and more complete feedback and specifications • Prevents many misunderstandings and miss-communications • Can result in final product that has greater tangible and intangible quality

20. Disadvantages of Prototyping • Insufficient analysis • Can distract developers from properly analyzing the complete project • Can lead to overlooking better solutions • May not scale well • User confusion of prototype and finished system • Think that a prototype is a final system • Expect the prototype accurately models performance of final system • Become attached to included features removed for final system

21. Disadvantages of Prototyping • Developer misunderstanding of user objectives: • May assume that users share their, without understanding wider commercial issues • May commit delivery before reviewing user requirements • Developer attachment to prototype: • Become attached to prototypes they have spent a great deal of effort producing

22. Disadvantages of Prototyping • Excessive development time of the prototype • May try to develop a prototype that is too complex • Users can become stuck in debates over details of the prototype • Expense of implementing prototyping • Start up costs for building a development team focused on prototyping may be high • Many companies tend to jump into prototyping without appropriately retraining workers

23. Disadvantages of Prototyping • High expectations for productivity with insufficient effort behind the learning curve • Overlooked need for developing corporate and project specific underlying structure to support the technology

24. Best projects to use prototyping • Analysis and design of on-line systems, especially for transaction processing • Systems with little user interaction, such as batch processing • Systems that mostly do calculations • Designing human-computer interfaces

25. Methods • Dynamic systems development • Operational prototyping • Evolutionary rapid development • Scrum

26. Dynamic Systems Development (DSDM) • Framework for delivering business solutions that relies heavily upon prototyping as a core technique • ISO 9001 approved • Prototypes intended to be incremental

27. Dynamic Systems Development (DSDM) • Prototypes may be throwaway or evolutionary • Evolutionary prototypes may be evolved horizontally or vertically • Evolutionary prototypes can evolve into final systems

28. Dynamic Systems Development (DSDM) • Four recommended prototypes categories: • Business prototypes • Usability prototypes • Performance and capacity prototypes • Capability/technique prototypes

29. Dynamic Systems Development (DSDM) • Prototype life-cycle: • Identify prototype • Agree to a plan • Create the prototype • Review the prototype

30. Operational Prototyping • Proposed by Alan Davis as a way to integrate throwaway and evolutionary prototyping with conventional system development

31. Operational Prototyping • Methodology: • Evolutionary prototype is constructed and made into a baseline using conventional development strategies • Baseline copies are sent to multiple customer sites along with a trained prototyper • Prototyper watches the user at the system • User problems, new feature ideas, or new requirements are logged by prototyper • After user session, prototyper constructs a throwaway prototype from baseline system • User evaluates new system; prototyper removes ineffective new changes • Prototyper writes feature-enhancement requests and forwards them to development team • Development team produces a new evolutionary prototype using conventional methods

32. Evolutionary Systems Development • Class of methodologies that attempt to formally implement Evolutionary Prototyping • Ex. Systemscraft

33. Evolutionary Rapid Development (ERD) • Developed by the Software Productivity Consortium • Composes software systems based on • Reuse of components • Use of software templates • Architectural template • Continuous evolution of system highlighted by evolvable architecture

34. Evolutionary Rapid Development (ERD) • Use of small artisan-based teams • Integrating software and systems engineering disciplines • Working multiple, often parallel short-duration timeboxes • Frequent customer interaction • Key to success • Parallel exploratory analysis and development of features, infrastructures and components • Adoption of leading edge technologies

35. Evolutionary Rapid Development (ERD) • Frequent scheduled and ad hoc meetings with the stakeholders • Demonstrations of system capabilities to solicit • Frequent releases (e.g., betas) • Design framework based on existing published or de facto standards • System organized for evolving a set of capabilities that includes considerations for performance, capacities, and functionality

36. Evolutionary Rapid Development (ERD) • Architecture • Defined in terms of abstract interfaces that encapsulate services and implementation (e.g., COTS applications) • Serves as a template for guiding development of more than a single instance of the system • Allows for multiple application components to implement services

37. Evolutionary Rapid Development (ERD) • Structured to use demonstrated functionality rather than paper products to communicate stakeholder needs and expectations • Timeboxes: fixed periods of time in which specific tasks (e.g., developing a set of functionality) must be performed • To prevent development from degenerating into a "random walk," long-range plans are defined to guide the iterations • Each iteration is conducted in the context of long-range plans • Once an architecture is established, software is integrated and tested on a daily basis

38. Scrum • Agile method for project management • First described by Takeuchi and Nonaka

39. Tools • Efficient prototyping requires • Proper tools • Staff trained to use those tools • Can vary from individual tools to complex integrated CASE tools • CASE tools are often developed or selected by the military or large organizations • Object oriented tools are being developed (Ex. LYMB, GE Research and Development Center)

40. Tools • Screen generators, design tools & Software Factories • Application definition or simulation software • Requirements Engineering Environment

41. Screen Generators, Design Tools & Software Factories • Screen generating programs enable prototypers to show users screens for non-functional • Human Computer Interfaces (HCI) can sometimes be the critical part of the development effort • Software Factories • Code Generators • Allow you to model domain model and then drag and drop the UI • Enable you to run prototype and use basic database functionality • Can use UI Controls that will later be used for real development

42. Application Definition or Simulation Software • Enable users to rapidly build lightweight, animated simulations of another computer program, without writing code • Allows both technical and non-technical users to experience, test, collaborate and validate the simulated program • Provides reports such as annotations, screenshot and schematics • One can also use software to simulate real-world software programs for computer based training, demonstration, and customer support

43. Requirements Engineering Environment • Under development at Rome Laboratory since 1985 • Provides an integrated toolset for rapidly representing, building, and executing models of critical aspects of complex systems • Currently used by the Air Force to develop systems

44. Requirements Engineering Environment • An integrated set of tools that allows systems analysts to rapidly build functional, user interface, and performance prototype models of system components • Modeling activities performed to gain greater understanding of complex systems and • Lessen impact that inaccurate requirement specifications have on cost and scheduling

45. Requirements Engineering Environment • Models can be • Constructed easily • At varying levels of abstraction or granularity • Composed of three parts • Proto, a CASE tool designed to support rapid prototyping • Rapid Interface Prototyping System (RIP), a collection of tools that facilitate the creation of user interfaces • A graphical user interface to RIP and proto intended to be easy to use

46. Waterfall Model

47. Spiral Model