Seminar 06


Published on

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

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Seminar 06

  1. 1. From formalised method to method-in-action: The rational and political role of methods Kulveer Singh U4557928
  2. 2. Discussion Papers <ul><li>The fiction of methodological development: a field study of information system development (R11) </li></ul><ul><li>Coordination in Software Development (R17) </li></ul><ul><li>Formalized system development methodologies: a critical perspective (R46) </li></ul><ul><li>System dynamics in software project management: towards the development of a formal integrated framework (R75) </li></ul><ul><li>The utilization of information system development methodology in practice (R112) </li></ul>
  3. 3. The fiction of methodological development: a field study of information system development (R11) Joe Nandhakumar David E. Avison
  4. 4. The fiction of methodological development: a field study of information system development <ul><li>Objectives </li></ul><ul><li>Explores the process of information system development in large organization </li></ul><ul><li>Paper argues that </li></ul><ul><ul><li>Traditional IS development methodologies are considered primarily as a necessary fiction to present an image of control or to provide a symbolic status </li></ul></ul><ul><ul><li>Methodologies are too mechanistic to use in detail in day-to-day organizational system development activities </li></ul></ul><ul><li>Paper also illustrate use of an “ecological” research approach to IS development </li></ul>
  5. 5. IS development process <ul><li>Avision and Fitzgerald,1995 </li></ul><ul><ul><li>Argued that most of the literature work described showed concerned describing about the particular methodologies </li></ul></ul><ul><ul><ul><li>How project is to be broken into discrete stages </li></ul></ul></ul><ul><ul><ul><li>How task is to be carried out in each stage </li></ul></ul></ul><ul><ul><ul><li>How tools are to be used in each stage to achieve the specifies deliverables </li></ul></ul></ul><ul><ul><li>They argued the development of new methodologies are focussed to be technological driven </li></ul></ul><ul><ul><li>Some focus was also given on expanding the scope of existing methodologies to address further stages and life cycle such as strategy & planning phase in Information Engineering </li></ul></ul><ul><ul><li>Some methodologies are also developed by combining the two methodologies in order to overcome the drawback of each other </li></ul></ul><ul><ul><ul><li>Eg: Multiview </li></ul></ul></ul>
  6. 6. Continued… <ul><li>Hirschheim and Klein (1989) </li></ul><ul><ul><li>Identified that there are four “ideal” type of IS development practices </li></ul></ul><ul><ul><ul><li>Functionalist </li></ul></ul></ul><ul><ul><ul><li>Social Relativist </li></ul></ul></ul><ul><ul><ul><li>Radical Structuralist </li></ul></ul></ul><ul><ul><ul><li>Radical humanist </li></ul></ul></ul><ul><ul><li>Also identified four main roles of IS developer </li></ul></ul><ul><ul><ul><li>System Expert </li></ul></ul></ul><ul><ul><ul><li>Facilitator </li></ul></ul></ul><ul><ul><ul><li>Labour Partisan </li></ul></ul></ul><ul><ul><ul><li>Emancipator/social therapist </li></ul></ul></ul>
  7. 7. Research Study <ul><li>Development process of executive information system (EIS) in large multinational manufacturing company (LMC) </li></ul>
  8. 8. Research findings <ul><li>Research results mainly highlighted </li></ul><ul><ul><li>Nature of IS development process </li></ul></ul><ul><ul><li>Use of IS development methodologies </li></ul></ul>
  9. 9. Implication for IS development methodologies <ul><li>Traditional methodologies are too mechanistic to be used in detail </li></ul><ul><li>Methodologies were seen primarily as a fiction to present an image of management control or reflects symbolic status </li></ul><ul><li>Social control factors has significant influence on developer’s work practices </li></ul>
  10. 10. Conclusion <ul><li>Formal methodologies are too mechanistic to be much of use in detailed during the day to day organizational developer’s activities. </li></ul><ul><li>The traditional IS development methodologies act as a necessary fiction to provide an image of control or symbolic status to IS projects. </li></ul><ul><li>Approach of using participants observation provided an effective mean of understanding the complex social process of IS development </li></ul>
  11. 11. Coordination in Software Development  (1995) (R17) Robert E. Kraut Lynn A. Streeter
  12. 12. Software Development (SD) <ul><li>“ The process of analysing needs, designing solutions, writing programs, testing them, and implementing them to solve the problems of individuals and organizations.” </li></ul>
  13. 13. Software Crisis and Coordination Problem <ul><li>“ [Software] is unreliable, delivered late, unresponsive to change, inefficient, and expensive and has been for the past 20 years” </li></ul><ul><li>Even today, problems with software systems are common and highly-publicized occurrences. </li></ul>
  14. 14. <ul><li>Coordination has been defined as the direction of “individuals” efforts toward achieving common and explicitly recognized goals” and “the integration or linking together of different parts of an organization to accomplish a collective set of tasks” </li></ul><ul><li>Why Coordination Problem? </li></ul><ul><ul><li>Large Software Systems </li></ul></ul><ul><ul><li>Software Complexity </li></ul></ul><ul><ul><li>Ineffective Communication </li></ul></ul><ul><ul><li>Less Informal Communication and Interaction </li></ul></ul>Software Crisis and Coordination Problem
  15. 15. What is Needed- Coordination <ul><li>Common Definition/ Common View </li></ul><ul><ul><li>5 W’s (Why, When, What…) and 1H (How) </li></ul></ul><ul><li>Share Information </li></ul><ul><li>Mesh Activities </li></ul>
  16. 16. Characteristics of Software Development <ul><li>Scale </li></ul><ul><ul><li>Small Software development projects </li></ul></ul><ul><ul><li>Large Software development projects </li></ul></ul><ul><ul><ul><li>large projects are more successful if a single, often exceptional, individual with both application domain knowledge and software knowledge guides and coordinates the project. </li></ul></ul></ul><ul><ul><ul><ul><li>Impossible: Size measurement is in millions or yeas </li></ul></ul></ul></ul>
  17. 17. Characteristics of Software Development
  18. 18. Characteristics of Software Development <ul><li>Uncertainty </li></ul><ul><ul><li>Means the unpredictability of both software and the task that software engineer performs. </li></ul></ul><ul><ul><li>Most software systems have no existing prototype, applications or systems. </li></ul></ul><ul><ul><li>Specifications of the software functionality change over time. (User demands and Physical Changes) </li></ul></ul><ul><ul><li>Specification are incomplete. </li></ul></ul><ul><ul><li>Different beliefs- 5 W and 1 H </li></ul></ul>
  19. 19. Characteristics of Software Development <ul><li>Interdependence </li></ul><ul><ul><li>Large size project have thousands of modules which requires perfect mesh. </li></ul></ul><ul><li>Informal communication </li></ul><ul><ul><li>The combination of large size, uncertainty and interdependence requires special coordination technique. </li></ul></ul><ul><ul><li>Formal and Informal communication. </li></ul></ul>
  20. 20. A survey Study of Coordination In Software Development <ul><li>Surveyed- Intergroup coordination practice across 65 projects in one large software development company. </li></ul><ul><li>Focused Factors </li></ul><ul><ul><li>Coordination Practice Used </li></ul></ul><ul><ul><li>Structural characteristics of projects that might interact with the practicality and utility of various coordination techniques. </li></ul></ul><ul><ul><li>Success of projects on several dimensions. </li></ul></ul>
  21. 21. A survey Study of Coordination In Software Development <ul><li>Research site </li></ul><ul><ul><li>Software development division of a research and development company </li></ul></ul><ul><ul><ul><li>5000 managers </li></ul></ul></ul><ul><ul><ul><li>Analyst, Software engineers, Programmers, Testers, documentation specialist. </li></ul></ul></ul><ul><ul><ul><li>In general- Waterfall model and standard development environment, code reviews and quality programs </li></ul></ul></ul>
  22. 29. Discussion <ul><li>Formal and Informal Interpersonal Communication </li></ul><ul><ul><li>Helps in sharing of information </li></ul></ul><ul><ul><li>Achieving coordination </li></ul></ul><ul><ul><li>Cope uncertainty </li></ul></ul><ul><ul><li>Minimise managerial and technical problems </li></ul></ul><ul><ul><li>Promote help etc </li></ul></ul>
  23. 30. Implications <ul><li>Can draw- Practical and theoretical implications </li></ul><ul><ul><li>Personal communication is important for coordination but expensive. </li></ul></ul><ul><ul><li>Need of technological assistance </li></ul></ul><ul><ul><li>Deleterious effects </li></ul></ul><ul><li>Leads to </li></ul><ul><ul><li>Work overload </li></ul></ul><ul><ul><li>More time spent with neighbours </li></ul></ul>
  24. 31. Formalized system development methodologies: a critical perspective (R46) Brian Fitzgerald
  25. 32. Formalized system development methodologies: a critical perspective <ul><li>Objective </li></ul><ul><ul><li>Paper discusses arguments and pressures which support use of methodologies </li></ul></ul><ul><ul><li>Paper also identifies number of arguments and pressures which question the value of methodology in practice </li></ul></ul><ul><ul><li>Critical perspective shows that increased adoption of methodologies to address the problem in system development is by no mean proven </li></ul></ul>
  26. 33. Argument and Pressures in favour of formalized methodologies
  27. 34. Argument and Pressures in favour of formalized methodologies
  28. 35. Critical consideration of formalized methodologies
  29. 36. System dynamics in software project management: towards the development of a formal integrated framework (R75) AG Rodrigues TM Williams
  30. 37. System Dynamics in software project management: towards the development of a formal integrated framework <ul><li>Objectives </li></ul><ul><ul><li>Traditional software project management approach vs. System Dynamic (SD) </li></ul></ul><ul><ul><li>Paper discusses about the conceptual integrated model SYDPIM to incorporate the system dynamics in software project management </li></ul></ul>
  31. 38. Traditional Software Project Management <ul><li>Software management comprises the several functions responsible to keep the project within time, cost and quality. </li></ul><ul><li>Paper mainly focus on three functions of project control: </li></ul><ul><ul><li>Estimating </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Monitoring Progress </li></ul></ul><ul><li>Approaches followed </li></ul><ul><ul><li>Network models developed on the basis of WBS </li></ul></ul><ul><ul><li>Process Definition Diagram (PDD) </li></ul></ul><ul><ul><li>Rapid Application Development (RAD) </li></ul></ul>
  32. 39. Problem & Limitation of Tradition Approach <ul><li>Main cause highlighted for the drawback of traditional technique is strategic area such as </li></ul><ul><ul><li>Political/social environment </li></ul></ul><ul><ul><li>Legal agreements </li></ul></ul><ul><ul><li>Human factors (Soft factors) </li></ul></ul><ul><li>These traditional network based models failed to cope with the higher level of complex problems </li></ul><ul><li>Need of new approach arises and System Dynamics (SD) came into existence. </li></ul><ul><ul><li>Based on the holistic view of managerial problems and focused on the human aspect of the system’s behavior </li></ul></ul>
  33. 40. Conceptual integrated framework <ul><li>Network model </li></ul><ul><ul><li>Top-down process </li></ul></ul><ul><ul><li>Management problems at operational level </li></ul></ul><ul><ul><li>Focus on detailed logic of project work structure and resource requirement </li></ul></ul><ul><li>SD model </li></ul><ul><ul><li>Bottom-Up approach </li></ul></ul><ul><ul><li>Managerial problems at strategic level </li></ul></ul><ul><ul><li>Focused more on capturing general aspects of the project behavior </li></ul></ul><ul><li>Therefore, integrated framework is to be developed considering the benefits of both model. </li></ul>
  34. 41. System Dynamics Project Management Integrated Model (SYDPIM)
  35. 42. System Dynamics Project Management Integrated Model (SYDPIM) <ul><li>SYDPIM considered both levels strategic and operational management to support </li></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><ul><li>Focus was given on estimating future results and performing risk analysis </li></ul></ul></ul><ul><ul><li>Monitoring </li></ul></ul><ul><ul><ul><li>Focus on diagnosing the past behavior of the project </li></ul></ul></ul><ul><li>Strategic level – high level SD strategic model (SDSM) is consider which covers the whole project life cycle and captures major software development milestone </li></ul><ul><li>Operational level – complex model SDOM is considered which covers individual life cycle of each phase in detail </li></ul>
  36. 43. Definition of SD model structure <ul><li>SD Model is based on four basic principles: </li></ul><ul><ul><li>Dual life cycle of management and engineering </li></ul></ul><ul><ul><li>Breakdown of projects into major sub-tasks </li></ul></ul><ul><ul><li>Dual life cycle of work and defect within the engineering process </li></ul></ul><ul><ul><li>Single high level project management and human resource management function </li></ul></ul>
  37. 44. Critical issues for application of SYDPIM <ul><li>Availability of accurate data which is required for </li></ul><ul><ul><li>Defining two project model behavior </li></ul></ul><ul><ul><li>Calibrating the SD model </li></ul></ul><ul><li>Range of application for SYDPIM </li></ul><ul><ul><li>Size and complexity of the project </li></ul></ul><ul><ul><li>Type of software development process </li></ul></ul>
  38. 45. Conclusion <ul><li>Traditional software project management and analysis tools has proven to be inadequate due to failure in capturing both human factor and project interaction and feedback effects. </li></ul><ul><li>SD emerged as the possible solution offering both aspects in analysis </li></ul><ul><li>It is needed to embed into the framework of traditional project management </li></ul><ul><li>Conceptual integrated framework SYDPIM is introduced which uses SD models at both strategic and operational management level. </li></ul><ul><li>Author considered that integrated tools provides a powerful support for managing major software engineering projects. </li></ul>
  39. 46. The Utilization of Information System Development Methodologies in Practice (R112) Karlheinz Kautz Bo Hansen Dan Jacobsen
  40. 47. The Utilization of Information System Development Methodologies in Practice <ul><li>Objectives of the paper </li></ul><ul><ul><li>Study people and their actions within an organizational context i.e. how developers use ISD methodologies in practices. </li></ul></ul><ul><ul><li>Case Study – Danish Software Development Company </li></ul></ul>
  41. 48. Practical use of ISD <ul><li>There is disparity between the way methods are formally described in literature and the way they are used in practice </li></ul><ul><ul><li>As a symbol to support the fiction of system development as a controllable process </li></ul></ul><ul><ul><li>Adoption of techniques of the method but, without adoption of the philosophy on which the method is built </li></ul></ul><ul><ul><ul><li>Unclear mission </li></ul></ul></ul><ul><ul><ul><li>Lack of management support </li></ul></ul></ul><ul><ul><ul><li>Organizational culture – hostile </li></ul></ul></ul><ul><ul><ul><li>Doubts about methodology – usability & validity </li></ul></ul></ul><ul><ul><ul><li>Insufficient training and insecurity </li></ul></ul></ul><ul><ul><ul><li>No systematic monitoring </li></ul></ul></ul><ul><ul><ul><li>No participation of the methodology users in the decision making </li></ul></ul></ul>
  42. 49. Practical use of ISD <ul><li>Productivity of developer and quality of developed system was also effected due to </li></ul><ul><ul><li>Limited domain knowledge </li></ul></ul><ul><ul><li>Fluctuating requirements </li></ul></ul><ul><ul><li>Communication breakdowns </li></ul></ul><ul><li>System development process and methods do not support any learning about domain, understanding the fluctuating behaviour and impact of environment and organizational context </li></ul>
  43. 50. Danish Software Company <ul><li>2300 employees of which 620 are system developers </li></ul><ul><li>Founded in 1972 by National Association of Local Authorities in Denmark </li></ul><ul><li>Deliver software solutions mainly to public sector and limited to private sectors </li></ul><ul><li>System development is primarily directed towards product development and adjustment </li></ul><ul><li>Two groups of projects </li></ul><ul><ul><li>New development project </li></ul></ul><ul><ul><li>Maintenance projects </li></ul></ul>
  44. 51. Danish Software Company <ul><li>New development projects </li></ul><ul><ul><li>Building of new system but, in actual it is renewal and re-implementation of projects </li></ul></ul><ul><ul><li>Divided into smaller chunks to renew gradually part by part </li></ul></ul><ul><li>Method Support Department </li></ul><ul><ul><li>Helps in guiding the projects in their development </li></ul></ul><ul><ul><li>Arranges training courses </li></ul></ul><ul><ul><li>Buying help </li></ul></ul><ul><ul><li>Provide system architect </li></ul></ul><ul><ul><ul><li>Helps in securing the system complies with the technical standards of the company </li></ul></ul></ul><ul><ul><ul><li>Provide suggestion in framing product architecture </li></ul></ul></ul><ul><ul><ul><li>Also collect feedback for system architecture </li></ul></ul></ul>
  45. 52. Investigated Projects <ul><li>Project A : Re-implementation of Administrative System </li></ul><ul><ul><li>System is in use for 20 years therefore constitute a large part of public sector users of Denmark </li></ul></ul><ul><ul><li>As project is redeveloped all the functionality is know except some serious changes in legislation </li></ul></ul><ul><li>Project was divided into 3 layers </li></ul><ul><ul><li>Back-end system </li></ul></ul><ul><ul><li>Process layer </li></ul></ul><ul><ul><li>Dialogue components </li></ul></ul><ul><li>Development work is to be carried out using the following tools: </li></ul><ul><ul><li>CASE tools </li></ul></ul><ul><ul><li>Web-development tools </li></ul></ul><ul><ul><li>Mainframe programming tool – (for developers) </li></ul></ul>
  46. 53. Continued… <ul><li>Project B: Replacement project that renew and enhance large administrative project </li></ul><ul><ul><li>It was used by staff and personnel management by private and public sector </li></ul></ul><ul><ul><li>Replacement will take place in form of pilot operation where new and old system will run parallel </li></ul></ul><ul><ul><li>Project uses so-called architecture paradigm for specification of the system </li></ul></ul><ul><ul><li>According to the paradigm system is described in five perspectives: </li></ul></ul><ul><ul><ul><li>Product perspective </li></ul></ul></ul><ul><ul><ul><li>Architecture perspective </li></ul></ul></ul><ul><ul><ul><li>Development perspective </li></ul></ul></ul><ul><ul><ul><li>Operation perspective </li></ul></ul></ul><ul><ul><ul><li>Delivery perspective </li></ul></ul></ul>
  47. 54. Continued… <ul><ul><li>While defining the technical platform it was decided not to use CASE tool and accompanying method for component based development </li></ul></ul><ul><ul><li>Large parts of the functionality are programmed with the help of rule-based development tools </li></ul></ul><ul><ul><li>For communicating the development UML diagrams were used </li></ul></ul><ul><li>Project C: Redevelop a specific part of another administrative system used by public sector </li></ul><ul><ul><li>Based on classical client-server architecture </li></ul></ul><ul><ul><li>Applied CASE tools and accompanied method </li></ul></ul><ul><ul><li>Prototyping function to facilitate communication with the customers </li></ul></ul>
  48. 55. Finding of the study <ul><li>Practical use of system development methodologies are influenced by five factors and processes </li></ul><ul><ul><li>Universality </li></ul></ul><ul><ul><ul><li>Idea of using one methodology applicable universally to all is not shared among the respondent </li></ul></ul></ul><ul><ul><ul><li>Reasons were </li></ul></ul></ul><ul><ul><ul><ul><li>Problem with sequential development method due to large size and complexity of the project </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Different tools an platform demand different methodologies </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Inappropriate development tools were chosen for the application methods and techniques </li></ul></ul></ul></ul>
  49. 56. Continued… <ul><li>Confidence </li></ul><ul><ul><li>Developers needed feedback to see whether they are on right track of development </li></ul></ul><ul><ul><li>Developers wanted to have more comments from user-side rather then assuming the user requirement themselves. </li></ul></ul><ul><ul><li>It also showed the symbolic use of methodologies in order to fetch the management’s goodwill </li></ul></ul><ul><li>Experience </li></ul><ul><ul><li>Developers experience in regards to system development process and domain knowledge is also the influencing factor for utilizing method </li></ul></ul>
  50. 57. Continued… <ul><ul><li>A pragmatic use of methodology is seen during the development by experienced developers </li></ul></ul><ul><ul><ul><li>They characterized methodology as a set of toolbox where appropriate techniques and methods can be found instead of characterizing as a general adoption of underlying philosophy </li></ul></ul></ul><ul><ul><ul><li>This type of behavior can lead to the implication on adopting new methodologies </li></ul></ul></ul><ul><li>Co-determination </li></ul><ul><ul><li>Use of methodology is also related to the developer’s desire for involvement and management co-operation with respect to policy and decision making </li></ul></ul>
  51. 58. Continued… <ul><li>Introduction </li></ul><ul><ul><li>Methodology introduction always plays a major role in its adoption. </li></ul></ul><ul><ul><li>Certain level of training and education is required to get comfortable with the methodology </li></ul></ul><ul><li>Lesson learnt </li></ul><ul><ul><li>Methodology are adjusted in action; no universally applicable methodology exists </li></ul></ul><ul><ul><ul><li>Varying complexity of information system </li></ul></ul></ul><ul><ul><ul><li>Varying experience of developers </li></ul></ul></ul><ul><ul><li>Symbolic utilization of methodologies </li></ul></ul><ul><ul><ul><li>It act as a mean to provide comfort and confidence </li></ul></ul></ul>
  52. 59. Continued… <ul><li>Methodology utilization moved towards incremental methodologies </li></ul><ul><ul><li>Due to the rapid change in application domain and business environment, traditional life cycle approaches are not appropriate to use </li></ul></ul><ul><ul><ul><li>Large and complex size of system tends developer to divide the project in smaller parts </li></ul></ul></ul><ul><ul><ul><li>This also provides a sense of control and comfort as there is continuous deliverances of prototyping </li></ul></ul></ul><ul><li>Methodology adoption depends on management support, explications and co-operation </li></ul><ul><ul><li>Lack of clear mission statement and resources can lead to poor introduction of methodology </li></ul></ul>
  53. 60. Conclusion <ul><li>The extensive empirical study helped in identifying five inter-related theme of factors and processes affecting the use of methodologies </li></ul><ul><li>Result of this study defines the framework for the future research to get deeper understanding of information system development and the utilization of methodologies. </li></ul>
  54. 62. <ul><li>Thank You </li></ul>