Software Engineering The Multiview Approach And Wisdm


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Engineering The Multiview Approach And Wisdm

  1. 1. WEB Information System Development Methodology 1
  2. 2. Information Systems Set of interacting components (people, procedures, technologies) that  together collect, process, store and distribute information  to support control, decision-making and management in organizations. 2
  3. 3. Information Systems Key components of Information Systems  Organizations  Human  Technologies 3
  4. 4. Information Systems WEB-based IS Computer-based IS Paper-based IS 4
  5. 5. Why IS Development Methodologies  Average completion time for IS projects: 1.5 -5 years  68% of projects overrun schedules  65% exceed budgets  75% face major redesign after initial implementation Solution lies in better and more professional approaches to development. 5
  6. 6. Why IS Development Methodologies  A methodical approach to software development results in fewer defects and, therefore, ultimately provides shorter delivery times and better value. Remember: Goal => High quality High quality = project timeliness Less rework! 6
  7. 7. Some Terminologies  Software development methodology  Software development process  Software development model  Software life-cycle  Software process model 7
  8. 8. What is IS Development Methodology  A collection of procedures, techniques, tools and documentation aids which helps the system developers in their effort to implement a new information system. Software Engineering tools methods process model a “quality” focus 8
  9. 9. IS Development Methodologies A methodology consists of phases, themselves consisting of sub-phases, which • help developers plan, manage, control and evaluate IS projects, • guide developers in their choice of techniques at each stages of the projects. 9
  10. 10. Benefits of IS Development Methodologies  Subdivision of complex process into small tasks.  Facilitation of project management and control.  Providing a framework for applying techniques.  Skill specialization and division of labor  Standardization, improving productivity and quality. 10
  11. 11. The General Process Model  There are a lot of process models, and many companies adopt their own, but all have very similar patterns. The general, basic model is shown below: 11
  12. 12. Requirements • Business requirements are gathered in this phase. • Who is going to use the system? • How will they use the system? • What data should be input into the system? • What data should be output by the system? • This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work. 12
  13. 13. Design • The software system design is produced from the results of the requirements phase. • This is where the details on how the system will work is produced. • Architecture, including hardware and software, communication, software design are all part of the deliverables of a design phase. 13
  14. 14. Implementation • Code is produced from the deliverables of the design phase during implementation, and this is the longest phase of the software development life cycle. • For a developer, this is the main focus of the life cycle because this is where the code is produced. • Implementation my overlap with both the design and testing phases. • Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase. 14
  15. 15. Testing • During testing, the implementation is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase. • Unit tests and system/acceptance tests are done during this phase. • Unit tests act on a specific component of the system, while system tests act on the system as a whole 15
  16. 16. Life-Cycle of a Software Feasibility Requirements Design Coding Testing Operations Maintenance 16
  17. 17. Umbrella Activities  Software project management  Software quality assurance  Software configuration management  Reusability management  Risk management 17
  18. 18. IS Process Models  Waterfall model  Evolutionary model  Iterative/incremental model  Spiral model  V-model  Prototyping  Agile software development  Cleanroom Software Engineering  Component Assembly Model  Rational Unified Process 18
  19. 19. Waterfall model Waterfall • Systematic stepwise refinement of a complex problem into smaller and smaller problems. 19
  20. 20. Waterfall model • Requirements analysis and definition • System and software design • Implementation and unit testing • Integration and system testing • Operation and maintenance 20
  21. 21. Waterfall model  The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be completed before moving onto the next phase. 21
  22. 22. Waterfall model problems  Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.  Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.  Few business systems have stable requirements. 22
  23. 23. Evolutionary development Evolutionary • System is developed using a prototype and refined through user feedbacks. • Changes is seen as the norm of the model. 23
  24. 24. Evolutionary development Qu ick p lan Quick Com m unicat ion plan requirements Mo d e lin g Modeling Qu ick d e sig n Quick design Deployment Deployment De live r y delivery & Const r uct ion & Fe e dback Construction feedback of of prototype pr ot ot ype 24
  25. 25. Evolutionary development 25
  26. 26. Evolutionary development  Exploratory development • Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.  Throw-away prototyping • Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed. 26
  27. 27. Evolutionary development  Problems • Lack of process visibility; • Systems are often poorly structured; • Special skills may be required.  Applicability • For small or medium-size interactive systems; • For parts of large systems (e.g. the user interface); • For short-lifetime systems. 27
  28. 28. Iterative Development Iterative / incremental • System is developed in chunks of functionality. • The overall system is developed incrementally. 28
  29. 29. Iterative Development increment # n Co m m u n i c a t i o n Pla nning M ode ling analy s is Co n s t ru c t i o n des ign c ode De p l o y m e n t t es t d e l i v e ry fe e dba c k deliv ery of increment # 2 nt h increment Co m m u n i c a t i o n Pla nning M ode ling analy s is Co n s t ru c t i o n des ign c ode De p l o y m e n t t es t d e l i v e ry fe e dba c k deliv ery of increment # 1 2nd increment Co m m u n i c a t i o n Pla nning M ode ling analy s is Co n s t ru c t i o n des ign c ode De p l o y m e n t t es t d e l i v e ry deliv ery of fe e dba c k 1st increment project calendar t ime 29
  30. 30. Iterative Development Advantages  Generates working software quickly and early during the software life cycle.  More flexible – less costly to change scope and requirements.  Easier to test and debug during a smaller iteration.  Easier to manage risk because risky pieces are identified and handled during its iteration.  Each iteration is an easily managed milestone. Disadvantages  Each phase of an iteration is rigid and do not overlap each other.  Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle. 30
  31. 31. Spiral model 31
  32. 32. V-Model 32
  33. 33. Web Design and Development 33
  34. 34. Developments in Information Systems:  Information systems are entering a new phase, moving beyond the traditional automation of routine organizational processes and towards the existing of critical tactical and strategic enterprise processes.  Development of such systems needs to concentrate on organizational aspects , delivering systems that are closer to the culture of organizations and the wishes of individuals. 34
  35. 35. Where are we with web application design methods? • It’s a relatively new area, most significant work only emerged from 1993 onwards • Very much in the infancy stages • No one solid method has emerged • Few approaches have been severely tested • We have most methods and technique components we need in existence for a web method, in almost all cases though they have just not been integrated • So, currently we need to work around the issue by forming ‘hybrid’ methods that share and borrow techniques 35
  36. 36. Web Methodology Disciplines Software Multimedia Engineering Hypertext Human-Computer Information Interaction Engineering Web Engineering Testing Requirements Engineering Project Modelling System Analysis Management and Simulation and Design 36
  37. 37. Special features of Web Projects  Network intensiveness  Concurrency  Unpredictable load  Performance.  Availability  Data driven.  Content sensitive.  Continuous evolution  Immediacy  Security  Aesthetics 37
  38. 38. Alternatives for WEB IS acquisition  In-house development  Outsourcing • Development of IS • Application service providers 38
  39. 39. A strategy to Web IS development  Introduce WISDM to • offer a methodology for the socio-technical view; • illustrate a socio-technical framework.  Use the RUP as powerful generic framework that can be flexibly taylored and extended by special techniques to suit the particular project.  Introduce various techniques to complement RUP activities in order to better address the specific features of Web-IS such as • User-orientation, broad view on requirements, specific architectural patterns, graphic design, navigation, etc. 39
  40. 40. The Multiview Approach and WISDM  Multiview‘s fundamental assumption: An IS methodology that relies overmuch on an engineering approach and technical rationality is, by itself, an insufficient foundation for IS development.  Foundations of Multiview: Needs of computer artefacts, organizations and individuals need to be considered jointly!  Major concern of Multivies: Negotiation between technological, organizational, and human aspects of IS development. 40
  41. 41. WISDM CHANGE AGENTS Multiple Would-be developers perspectives: of an information •Technical (T) system •Organizational (O) •Personal (P) IS DEVELOPMENT METHODS ANALYSIS Organizational Information Analysis Analysis TECHNICAL WISDM - Web IS Value Requirements SOCIO Development creation specification Methodology (emergent) Work Technical History Design Design User HCI Software satisfaction User interface model DESIGN SITUATION 41
  42. 42. WISDM as emerging methodology from the Multiview framework Humans Organisation Technology ANALYSIS Organizational Information Analysis Analysis TECHNICAL Value creation Requirements SOCIO (human activity systems) specification Work Technical Design Design User HCI Software satisfaction model User interface Situation DESIGN Developers 42
  43. 43. WISDM Methods matrix and role of the analyst  There is no a priori ordering of the five apects of the WISDM matrix  Essential aspect: Analyst works on the joint basis of the three (T, O, P) perspectives. 43
  44. 44. Organizational Analysis ANALYSIS Organizational Information Analysis Analysis TECHNICAL Value creation Requirements SOCIO (human activity systems) specification Work Technical Design Design User HCI Software satisfaction model User interface DESIGN 44
  45. 45. Organizational Analysis  Business (strategy) • What business is the Organization in? • What are the products and services?  Products and services • What are the sources of revenue? • What are the benefits to the business actors?  Who are the customers?  Who are the competitors?  Marketing strategy (How to compete) • What is the organization’s marketing strategy? 45
  46. 46. Work design ANALYSIS Organizational Information Analysis Analysis TECHNICAL Value creation Requirements SOCIO (human activity systems) specification Work Technical Design Design User HCI Software satisfaction model User interface DESIGN 46
  47. 47. Sociotechnical design  Foundation: Genuine participation: involves users, managers, developers, and others who influence each other‘s plans policies and decisions, thus affecting future outcomes.  Measure user satisfaction and quality. 47
  48. 48. Quality workshop, WebQual Category WebQual 4.0 Questions Usability 1. I find the site easy to learn to operate 2. My interaction with the site is clear and understandable 3. I find the site easy to navigate 4. I find the site easy to use 5. The site has an attractive appearance 6. The design is appropriate to the type of the site 7. The site conveys a sense of competency 8. The site creates a positive experience for me Information 9. Provides accurate information 10. Provides believable information 11. Provides timely information 12. Provides relevant information 13. Provides easy to understand information 14. Provides information at the right level of detail 15. Presents the information in an appropriate format Service 16. Has a good reputation Interaction 17. It feels safe to complete transactions 18. My personal information feels secure 19. Creates a sense of personalization 20. Conveys a sense of community 21. Makes it easy to communicate with the organization 22. I feel confident that goods/services will be delivered as promised Overall 23. My overall view of this website (Vidgen, Tab. 7-4) 48
  49. 49. Quality workshop, WebQual 49
  50. 50. Technical Development ANALYSIS Organizational Information Analysis Analysis TECHNICAL Value creation Requirements SOCIO (human activity systems) specification Work Technical Design Design User HCI Software satisfaction model User interface DESIGN 50
  51. 51. Information Analysis  Elements of the analysis model • Data model • Flow model • Class model • Behavior model 51
  52. 52. Technical Design  Elements of the design model • Data design • Architectural design • Component design • Interface design • Aesthetic design • Navigation design 52
  53. 53. The Rational Unified Process  RUP is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2002.  It has an underlying object-oriented model, using Unified Modeling Language (UML).  RUP is based on a set of six key principles: • Adapt the process • Balance stakeholder priorities • Collaborate across teams • Demonstrate value iteratively • Elevate the level of abstraction • Focus continuously on quality 53
  54. 54. Rational Unified Process Model Phase iteration Inception Elaboration Construction Transition  Inception : Establish the business case for the system.  Elaboration : Develop an understanding of the problem domain and the system architecture.  Construction : System design, programming and testing.  Transition : Deploy the system in its operating environment. 54
  55. 55. RUP Phases • Inception is concerned with determining the scope and purpose of the project; • Elaboration focuses requirements capture and determining the structure of the system; • Construction's main aim is to build the software system; • Transition deals with product installation and rollout. 55
  56. 56. RUP Phases Project Phases Inception Elaboration Construction Transition 1 2 3 4 5 6 7 8 Iterations within Requirements each phase Design Implementation Test Size of square Workflows relative to time spent on workflows 56
  57. 57. RUP Phases Sample incep- transi- UP Disciplines elaboration construction tion tion Business Modeling Requirements Design Implementation ... ... 57
  58. 58. RUP Phases accept ance t est cust omer use cust omer evaluat ion coding component t est Release sof t war e incr ement refact oring design model cont ent analysis model archit ect ure cont ent navigat ion business analysis int erf ace it erat ion formulat ion f unct ion it erat ion plan conf igurat ion 58
  59. 59. 6 UP Best Practices that particularly apply to web-based systems  Develop iteratively  Manage and trace requirements  Utilize component architectures  Model visually  Verify quality  Control changes 59
  60. 60. WUP – Complementing the RUP For each phase: Inputs for each phase and iteration of the RUP UP–activities Web–specific activities 60
  61. 61. WUP – Initial tasks  Discuss the topic of your web application and corresponding visions with stakeholders.  Decide which techniques/views (from the RUP or web-specific) may be useful in your special case.  Make a gross plan for the whole development cycle.  Make a detailed plan for the next phase.  Keep to RUP‘s phase structure and workflows but vary the specific techniques and views found relevant. 61
  62. 62. Technical Development An Object-Oriented Technique (UML) User System Model requirements • Use Case diagram • Activity diagram • Interaction Diagrams • Sequence diagram • Collaboration diagram • Class diagram • State diagram • Component diagram • Deployment diagram 62
  63. 63. Technical Development 63
  64. 64. Unified Modeling Language (UML) Object Oriented Analysis and Design The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non- software systems. 64
  65. 65. Use Case Diagram • A use case is a set of scenarios that describing an interaction between a user and a system. • A use case diagram displays the relationship among actors and use cases. • The two main components of a use case diagram are use cases and actors. 65
  66. 66. Use Case Diagram 66
  67. 67. Sequence Diagrams Interaction diagrams model the behavior of use cases by describing the way groups of objects interact to complete the task. The two kinds of interaction diagrams are sequence and collaboration diagrams. They demonstrate how the objects collaborate for the behavior. 67
  68. 68. Sequence Diagrams 68
  69. 69. Sequence Diagram 69
  70. 70. Collaboration Diagram 70
  71. 71. Collaboration Diagram 71
  72. 72. Class Diagrams Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects 72
  73. 73. Class Diagrams 73
  74. 74. State Diagrams • State diagrams are used to describe the behavior of a system. • State diagrams describe all of the possible states of an object as events occur. • Each diagram usually represents objects of a single class and track the different states of its objects through the system. 74
  75. 75. State Diagrams 75
  76. 76. Activity Diagrams • Activity diagrams describe the workflow behavior of a system. • Activity diagrams are similar to state diagrams because activities are the state of doing something. • The diagrams describe the state of activities by showing the sequence of activities performed. • Activity diagrams can show activities that are conditional or parallel. 76
  77. 77. Activity Diagrams 77
  78. 78. Deployment Diagrams • The deployment diagram contains nodes and connections. • A node usually represents a piece of hardware in the system. • A connection depicts the communication path used by the hardware to communicate and usually indicates a method such as TCP/IP. 78
  79. 79. Combined deployment and component diagram • The diagram shows two nodes which represent two machines communicating through TCP/IP. • Component2 is dependant on component1, so changes to component 2 could affect component1. • The diagram also depicts component3 interfacing with component1. 79
  81. 81. Design Document (example) TABLE OF CONTENTS Executive Summary IV 1. INTRODUCTION 2. DESIGN OF THE FOOD SYSTEM 2.1 Modular Structure of the System 2.2 Menu Structures 2.3 Modules detailed design 2.3.1 Create Class (Module 1.2.1) 2.3.2 Update Class (Module 1.2.2) ….. 2.4 System Topology 2.5 Solutions for additional Requirements 2.6.1 Error handling 2.6.2 Database catalog design 2.6.3 Connections to other systems 2.6 Data dictionary 3. INTERFACE DESIGN 4. CONCLUSION 81
  82. 82. Web Design Pyramid user Interface design Aesthetic design Content design Navigation design Architecture design Component design technology 82