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